Network Working Group J. Jimenez
Internet-Draft Ericsson
Intended status: Informational H. Tschofenig
Expires: January 3, 2019 Arm Ltd.
D. Thaler
Microsoft
July 02, 2018

Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
draft-iab-iotsi-workshop-02

Abstract

This document provides a summary of the ‘Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)’, which took place in Santa Clara, California, 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 (SDOs) 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 https://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 January 3, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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

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, especially 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.

With the expansion of the Internet of Things (IoT), interoperability becomes more and more important. Standards Developing Organizations (SDOs) have done a tremendous amount of work to standardize new protocols, and to profile existing protocols.

At the application layer and at the level of solution frameworks, interoperability is not yet mature. Particularly, the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout SDOs.

One common problem is the lack of an encoding-independent standardization of the information, the so-called information model. Another problem is the strong relationship with the underlying communication architecture, such as a Remote Procedure Call (RPC) style design or a RESTful design. Furthermore, groups develop solutions that are very similar on the surface but differ slightly in their standardized outcome, leading to interoperability problems. Finally, some groups favor different encodings for use with various application layer protocols.

Thus, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state-of-the-art and to identify commonality and gaps [IOTSIAG][IOTSIWS]. In particular, the IAB was interested to learn about the following aspects:

2. Terminology

The first roadblock to interoperability at the level of data models is the lack of a common vocabulary to start the discussion. [RFC3444] provides a starting point by separating conceptual models for designers, or “information models”, from concrete detailed definitions for implementers, or “data models”. 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 were identified were:

Information Model

An information model defines an environment at the highest level of abstraction and expresses the desired functionality. Information models 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

A data model defines concrete data representations at a lower level of abstraction, including implementation and protocol-specific details. Some examples are: SNMP Management Information Base (MIB) modules, W3C Thing Description (TD) Things, YANG models, LWM2M Schemas, OCF Schemas, and so on.

Interaction Model

An interaction model 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. The meaning can vary depending on the context in which 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, but work will continue within each organization to create various terminology documents. The participants agreed to set up a github repository [IOTSIGIT] for sharing information.

3. What Problems to Solve

The participants agreed that there is not simply a single problem to be solved, but rather a range. During the workshop the following problems were discussed:

To simplify review and publication, SDOs need formal descriptions of their data and interaction models. Several of them use a tabular representation found in the specification itself, but use a formal language as an alternative way of describing objects and resources for formal purposes. Some examples of formal language use are as follows.

The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML schema [LWM2M-Schema] to describe their object and resource definitions. The XML files of standardized objects are available for download at [OMNA].

The Bluetooth SIG defined Generic Attributes (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on the Bluetooth SIG website at [SIG], and are also defined as XML instance documents.

The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models, and RAML to define interaction models. The standard files are available online at OneIoTa.org.

The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. The standard files are available online on the AllSeen Alliance web site, but both standard and vendor-defined model files can be obtained by directly querying a device for them at runtime.

The World-Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web.

The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. Other SDOs may use various other formats.

Code generation tools that use formal data and information modelling languages are needed by developers. For example, the AllSeen Visual Studio Plugin [AllSeen-Plugin] offers a wizard 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]. An example of a tool that can do code generation for multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests.

Debugging tools are needed that implement generic object browsers, which use standard data models and/or retrieve formal language descriptions from the devices themselves. As one example, the NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can be used to display services and characteristics defined by the Bluetooth SIG. As another example, AllJoyn Explorer [AllJoynExplorer] can be used to browse and interact with any resource exposed by an AllJoyn device, including both standard and vendor-defined data models, by retrieving the formal descriptions from the device at runtime.

The working assumption is that devices need to have a common data model with a priori knowledge of data types and actions. However that would imply that each consortium/organization will try to define their own, causing a major interoperability problem, if not a completely intractable one given the amount of variations, extensions, compositions or versioning changes that will happen on a per data model basis.

Another potential approach is to have a minimal ammount of information on the device to allow for a runtime binding to a specific model, the objective being to require as little prior knowledge as possible.

Moreover, gateways, bridges and other similar devices need to dynamically translate (or map) one data model to another one. Complexity will increase as there are also multiple protocols and schemas that make interoperability harder to achieve.

Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the data exchanged itself. In some cases the metadata not only describes data but also the interaction model as well. An example of such an approach has been shown with HATEOAS [HATEOAS]. Another example is that all AllJoyn devices support such runtime discovery using a protocol mechanism called “introspection”, where the metadata is queried from the device itself [AllSeen].

There are various models, whether deployed or possible, for such discovery. The metadata might be extracted from a specification, or looked up on a cloud repository (e.g., OneIoTa for OCF models), or looked up via a vendor’s site, or obtained from the device itself (such as in the AllJoyn case). The relevant metadata might be obtained from the same place, or different pieces might be obtained from different places, such as separately obtaining information such as (a) syntax information, (b) end-user descriptions in a desired language, and (c) developer-specific comments for implementers.

4. Translation

In an ideal world where organizations and companies cooperate and agree on a single data model standard, there is no need for gateways that translate from one data model to the other one. However, this is far from reality today, and there are many proprietary data models in addition to the already standardized ones. As a consequence, gateways are needed to translate between data models. This leads to (n^2)-n combinations, in the worst case.

There are analogies with gateways back in the 1980s that were used to translate between network layer protocols. Eventually IP took over, providing the necessary end-to-end interoperability at the network layer. Unfortunately, the introduction of gateways leads to the loss of expressiveness due to the translation between data models. The functionality of IP was so valuable in the market that advanced features of other networking protocols became less attractive and were not used anymore.

Participants discussed an alternative which they called a ‘red star’, shown in Figure 1, where data models are translated to a common data model shown in the middle. This reduces the number of translations that are needed down to 2n (in the best case). The problem, of course, is that everyone wants their own data model to be the red star in the center.

   +-----+                                        +-----+
   |     |                                        |     |
   |     |  --                                 -- |     |
   |     |    --                             --   |     |
   +-----+      --                         --     +-----+
                  --                    ---
                    --                --
                      --            --
                        --        --
     ---                  -- A  --                  ---
    /   \                ___/ \___                 /   \
   |     | ---------------',   .'---------------  |     |
    \   /                 /. ^ .\                  \   /
     ---                 /'     '\                  ---   
                        --        --
                      --            --
                    --                --
                  --                    --
                --                        --
       /\     --                            --     /\
      /  \  --                                --  /  \
     /    \                                      /    \
    /      \                                    /      \
   /--------\                                  /--------\

Figure 1: The 'Red Star' in Data/Information Models.

While the workshop itself was not a suitable forum to discuss the design of such translation in detail, several questions were raised:

The participants also addressed the question of when translation should be done. Two use cases were discussed:

a) Design time: a translation between data model descriptions, such as translating a YANG model to a RAML/JSON model, can be performed once, during design time. A single information model might be mapped to a number of different data models.

b) Run time: Runtime translation of values in two standard data models can only be algorithmically done when the data model on one side is algorithmically derived from the data model on the other side. This was called a “derived model”. It was discussed that the availability of runtime discovery can aid in semantic translation, such as when a vendor-specific data model on one side of a protocol bridge is resolved and the translator can algorithmically derive the semantically-equivalent vendor-specific data model on the other side of a protocol bridge, as discussed in [BridgeTaxonomy].

The participants agreed that algorithm translation will generally require custom code, whenever one is translating to anything other than a derived model.

Participants concluded that it is typically easier to translate data between systems that follow the same communication architecture.

5. Dealing with change

A large part of the workshop was dedicated to the evolution of devices and server-side applications. Interactions between devices and services and how their relationship evolves over time is complicated by their respective different interaction models.

The workshop participants discussed various approaches to deal with change. In the most basic case, a developer might use a description of an API and implement the protocol steps. Sometimes the data or information model can be used to generate code stubs. Subsequent changes to an API require changes on the clients to upgrade to the new version, which requires some development of new code to satisfy the needs of the new API.

These interactions could be made machine-understandable in the first place, enabling for changes to happen at runtime. In that scenario, a machine client could discover the possible interactions with a service, adapting to changes as they occur without specific code being developed to adapt to them.

The challenge seems to be to code the human-readable specification into a machine-readable format. Machine-readable languages require a shared vocabulary to give meaning to the tags.

These types of interactions are often based on the REST architectural style. Its principle is that a device or endpoint only needs a single entry point with a host providing descriptions of the API in-band by means of web links and forms.

By defining IoT-specific relation types, it is possible to drive interactions through links instead of hardcoding URIs into a RESTful client, thus making the system flexible enough for later changes. The definition of the basic hypermedia formats for IoT is still work in progress. However, some of the existing mechanisms can be reused, such as resource discovery, forms, or links.

6. Security Considerations

There were two types of security considerations discussed: use of formal data models for security configuration, and security of data and data models in general.

It was observed that the security assumptions and configuration, or “security model”, varies by ecosystem today, making the job of a translator difficult. For example, the types of security principals (e.g., user vs. device vs. application), the use of access control lists (ACLs) vs. capabilities, and what types of policies can be expressed, all vary by ecosystem. As a result, the security model architecture generally dictates where translation can be done.

One approach discussed was whether two endpoints might be able to use some overlay security model, across a translator between two ecosystems, which only works if the two endpoints agree on a common data model for their communication. Another approach discussed was simply having a translator act as a trusted intermediary, which allows the translator to be able to translate between different data models.

One suggestion discussed was potentially adding metadata into either the formal data model language, or accompanying the data values over the wire, tagging the data with privacy levels. However, sometimes even the privacy level of information might itself be sensitive. Still, it was observed that being able to dynamically learn security requirements might help provide better UIs and translators.

7. Collaboration

The participants discussed how best to share information among their various organizations. One discussion was around having joint meetings. One current challenge reported was that organizations were not aware of when and where each others’ meetings were scheduled, and sharing such information could help organizations better collocate meetings. To facilitate this exchange, the participants agreed to add links to their respective meeting schedules from a common page in the IOTSI repository [IOTSIGIT].

Another challenge reported was that organizations did not know how to find each others’ published data models, and sharing such information could better facilitate reuse of the same information model. To facilitate this exchange, this participants discussed whether a common repository might be used by multiple organizations. The OCF’s OneIoTa repository was discussed as one possibility but it was reported that its terms of use at the time of the workshop prevented this. The OCF agreed to take this back and look at updating the terms of use to allow other organizations to use it too, as the restriction was not the intent. Schema.org was discussed as another possibility. In the meantime, the participants agreed to add links to their respective repositories from a common page in the IOTSI repository [IOTSIGIT].

It was also agreed that the iotsi@iab.org mailing list would remain open and available for sharing information between all relevant organizations.

8. Acknowledgements

We would like to thank all paper authors and participants for their contributions, and Ericsson for hosting the workshop.

9. Appendix A: Program Committee

This workshop was organized by the following individuals: Jari Arkko, Ralph Droms, Jaime Jiménez, Michael Koster, Dave Thaler, and Hannes Tschofenig.

10. Appendix B: Accepted Position Papers

11. Appendix C: List of Participants

12. Informative References

[AllJoynExplorer] Microsoft, "AllJoyn Explorer", 2016.
[AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability", 2016.
[AllSeen-Plugin] Rockwell, B., "Using the AllJoyn Studio Extension", 2016.
[BridgeTaxonomy] Thaler, D., "IoT Bridge Taxonomy", 2016.
[HATEOAS] Kovatsch, M., "Semantic Interoperability Requires Self-describing Interaction Models - HATEOAS for the Internet of Things", Proceedings of the IoT Semantic Interoperability Workshop 2016, 2016.
[IOTSIAG] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) - Agenda and Slides", 2016.
[IOTSIGIT] IOTSI, "Github Collaborative Repository", 2016.
[IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) 2016 - Main Page and Position Papers", 2016.
[LWM2M-Schema] OMA, "OMA LWM2M XML Schema", 2018.
[nRF-Sniffer] Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low energy packet sniffer", 2016.
[OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource Registry", 2018.
[OpenDOF] OpenDOF, "The OpenDOF Project", 2015.
[PYANG] Bjorklund, M., "An extensible YANG validator and converter in python", 2016.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003.
[SIG] Bluetooth SIG, "GATT Specifications", 2018.

Authors' Addresses

Jaime Jimenez Ericsson EMail: jaime.jimenez@ericsson.com
Hannes Tschofenig Arm Ltd. EMail: hannes.tschofenig@arm.com
Dave Thaler Microsoft EMail: dthaler@microsoft.com