Network Working Group J. Jimenez Internet-Draft Intended status: Informational H. Tschofenig Expires: November 25, 2016 D. Thaler May 24, 2016 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 draft-iab-iotsi-workshop-00.txt Abstract This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIWS], which took place in Santa Clara, CA, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and standards developing organizations to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 25, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Jimenez, et al. Expires November 25, 2016 [Page 1] Internet-Draft IOTSI May 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5 5. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Runtime Discovery . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Appendix A: Program Committee . . . . . . . . . . . . . . . . 9 9. Appendix B: Accepted Position Papers . . . . . . . . . . . . 9 10. Appendix C: List of Participants . . . . . . . . . . . . . . 12 11. Informative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The investigated topics often require coordinated efforts of many organizations and industry bodies to improve an identified problem. One of the targets of the workshops is to establish communication between relevant organizations, specially when the topics are out of the scope for the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF. Increasing interoperability in the area of Internet of Things (IoT) has been a top priority for many standards organizations and pariticularly the lower layers of the Internet protocol stack have received a lot of attention. Also at the application layer, such as with CoAP and HTTP, there is a trend in reusing RESTful design patterns. However, data exchanged on top of these application layer protocols there is still a lot of fragmentation and the same degree of increase in interoperability has not been observed. Jimenez, et al. Expires November 25, 2016 [Page 2] Internet-Draft IOTSI May 2016 Thus, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state-of-the-art and to identify communality and gaps. o The different perceived state of the art on data and information models. o The lack of an encoding-independent standardization of the information, the so-called information model. o The strong relationship with the underlying communication pattern, such as remote procedure calls (RPC), publish/subscribe or RESTful designs. o Identifying which similar concepts groups have develop in parallel, specially those that would require only slight modifications to solve interoperability. o Identifying how existing data models can be mapped against each other to offer inter working. o Identifying common use cases for cooperation and harmonization. 2. Terminology The first roadblock to semantic interoperability is the lack of a common vocabulary to start the discussion. There is a need to align between participating organizations on a common set of basic terms. [RFC3444] does a start by separating conceptual models for designers or Information Models (IMs) and concrete detailed definitions for implementors or Data Models (DMs). There are concepts that are undefined in that RFC and elsewhere, such as the interaction with the resources of an endpoint or Interaction Model. Therefore the three "main" common models that could be identified were: Information Model (IM) it defines an environment at the highest level of abstraction, they express the desired functionality. They can be defined informally (e.g. in plain English) or more formally (e.g. UML, Entity-Relationship Diagrams, etc.). Implementation details are hidden. Data Model (DM) it defines concrete data representations at a lower level of abstraction, including implementation and protocol- specific details. Some examples are: SNMP Management Information Base (MIBs), W3C Thing Description (TD) Things, YANG models, LWM2M Schemas, OCF Schemas and so on. Jimenez, et al. Expires November 25, 2016 [Page 3] Internet-Draft IOTSI May 2016 Interaction Model (IN) it defines how data is accessed and retrieved from the endpoints, being therefore tied to the specific communication pattern that the system has (e.g. REST methods, Publish/Subscribe operations or RPC-calls). Another identified terminology issue is the semantic meaning overload that some terms have. Meaning will vary depending on the context the term is used. Some examples of such terms are: semantics, models, encoding, serialization format, media types or encoding types. Due to time constraints no concrete terminology was agreed upon, however work will continue within each organization to create various terminology documents, see [IOTSIGIT]. 3. Architecture Architectures follow different design patterns, some are REST- oriented with clear methods to find and manipulate resources on endpoints with almost no state kept between them. Others are more Publish/Subscribe-oriented that focus on the flow of information based on the topics of the information that is being shared. Others are RPC-like requiring to know beforehand the set of parameters that are accessed, requiring to generate code both on the client and server side, they are tightly coupled and service-oriented. Thing-hub-cloud things talk to a hub, which talks back to them and to the cloud. There is a spectrum of emphasis on the hub vs. the cloud. For some the hub is simply an access point; for others it is a critical place for control loops and ALGs. Meta Thing some things are actually virtual, like an alarm composed of clock, lights, and thermostat. Nearby things some things may be geospatially related even if they are not on the same network or within the same administrative domain. Current data models and definitions for "things" often focus on defining actual physical devices and representing their state. That focus should perhaps be shifted into a more holistic or user-oriented perspective, defining abstract concepts as well. On the other a lot of focus is placed on human interaction with physical devices while IoT will be more oriented to interaction between "things" instead. Those things should be designed to be multiple-purpose, keeping in mind that solutions should be open-ended to facilitate new usages and new future domains of operation. this pattern has already happened, devices that were intended for one purpose end up being used for a different one given the right context ((e.g. smart phone led light Jimenez, et al. Expires November 25, 2016 [Page 4] Internet-Draft IOTSI May 2016 turned out to be a heartrate monitor). IoT domain is currently missing insights into what user actually expect. 4. What Problems to Solve Although the workshop focused on a specific problem it became obvious from the position papers that various organizations, industry groups and individuals attempted to solve different problems. At least the following goals have been described: o Formal Languages for Documentation Purposes Standardization organizations are in the need for a more formal description of their information and data models in order to simplify review, and publication. For example, the Open Mobile Alliance (OMA) used an XML schema [LWM2M-Schema] to describe their object definitions (i.e., data model) as XML instance documents. These XML documents offer an alternative way of describing objects compared to the tabular representation found in the specification itself. The XML files of standardized objects are available for download at [OMNA]. Furthermore, a tool is offered to define new objects and resources. The online editor tool can be found at [OMA-Editor]. o Formal Languages for Code Generation Formal data and information modelling languages for use by developers to enable code generation. For example, the Allseen Visual Studio Plugin [Allseen-Plugin] offers a wizzard to generate code based on the formal description of the data model. Another example of a data modelling language that can be used for code generation is YANG. A popular tool to help with code generation of YANG modules is pyang [PYANG]. o Debugging Support Ability to allow debugging tools to implement generic object browsers by utilizing the standardized information and data model. Example: NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer]. o Translation The ability for gateways and other similar devices to dynamically translate (or map) one data model to another one. An example of this idea can be found in [UDI]. o Runtime Discovery Jimenez, et al. Expires November 25, 2016 [Page 5] Internet-Draft IOTSI May 2016 Allow IoT devices to exchange information, potentially along with the data exchange, to discover meta-data about the data and, potentially, even a self-describing interaction model. An example of such an approach has been shown with HATEOS [HATEOS]. 5. Translation One of the targets of interoperability is to create translators between the data models. There are analogies with gateways back in 1985 when they were used to translate between network protocols, eventually IP took over providing interoperability, however we lost some of the features provided by those other protocols. The creation of an equivalent "hub/s" that offer translation between the different data models or data semantics seems one of the ways forward. Some lose of expressiveness due to the translation between models seems also unavoidable. When it comes to translation two different distinctions appear: translating data between data models and translating data models. The first one implies doing the translation at runtime while the second performs one translation between the data models one time, like translating a YANG model to a RAML/JSON one. Indeed, for every IM multiple DMs could be translated. In a sense these distinctions affect as to when the translation is performed. It can be done at "design time" when the information model is done, it can be done at runtime for a concrete data model and it can be done depending n the actual serialization. Yet another distinction will appear depending on the requirements from the application protocols, RPC-style ones might require a slightly different DM than REST ones for similar operations, for example SNMP-traps could be similar to CoAP-Observations but not quite the same. It is easier to translate between systems that follow the same architecture/design pattern than across architectures, full translation might not even be possible (e.g. stateless vs stateful systems). Translation of models script to translate XML to YANG Translation of serialized data, on a hub in order to normalize it to other data model. 6. Runtime Discovery Runtime changes are doing after design and at compile time. Discovery, is it devices or data items on devices. A lot of people think about devices but also abstract entities. To do discovery one question is "how much must "be shared before time. The meta-data has Jimenez, et al. Expires November 25, 2016 [Page 6] Internet-Draft IOTSI May 2016 also two possible notions, is it instance specific (e.g. location of the thing) or does it have to do with the model itself? Need to handle change in the environment. Replace things without manual configuration, change control flow, etc. at runtime. Few things (vocabulary) is shared a priori. Drives the application runtime, "Engine of application state", we needs self-describing interaction models. Ravi: nothing prevents HATEOAS + data model Ari: And OMA LwM2M uses SenML Matthias: these are complementary approaches. It is to point out that it is also about Interaction Models. Of course DM are needed to convey data. Interaction model You get one entry point (in CoAP it is the RD) and the client tries to perform discovery in order to find and follow links in order to discover capabilities. You submit forms to interact with them. This way you can create processes that span over multiple devices involved in the process. If later one you find that you need something else, you can add new functionality at runtime, next client that comes along will have the same logic but see different capabilities of functionality and therefore use it. Parts of the information have to be shared a priori. The process is incremental, but once discovered, you don't need to perform the same operation every time, you can go to the bookmark. The following are examples of all those in HTML. Jimenez, et al. Expires November 25, 2016 [Page 7] Internet-Draft IOTSI May 2016 // Links (Anchors) with human-readable information More information // Templated Links to perform a query with a parameter.
// Embedded Links which are used to embed other resources.