Resource Model Indication with CoAP
draft-jinchoe-resource-model-indication-00

Abstract

There is much interest in "Internet of Things (IoT)" and multiple standards following the REST architectural style are under development. In a RESTful interaction, IoT devices need to understand each other's resource representations, both the semantic meaning and the syntactic form, to interact properly. For interoperability among different standards, it is helpful for CoAP endpoints to indicate the resource models they support. This document presents a scheme for IoT devices to exchange their resource model information and requests from IANA new Internet media types and CoAP Content-Format identifier for resource model indication.

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 January 7, 2016.

Copyright Notice

Copyright (c) 2015 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 (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.

Table of Contents

• 1. Introduction
• 1.1. IoT trend
• 1.2. REST and interoperability
• 1.3. Conventions
• 2. Resource model indication
• 2.1. Different resource models
• 2.2. A scheme to exchange resource model information
• 2.3. Content-Format request for OIC resource model
• 3. IANA Considerations
• 3.1. New Internet media type - application/vnd.oic
• 3.2. New Internet media type: application/vnd.oic+json
• 3.3. New Internet media type: application/vnd.oic+cbor
• 4. Security Considerations
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

1.1. IoT trend

The term "Internet of Things (IoT)" denotes a trend where a large number of devices, i.e sensors and actuators, are embedded in physical world and networked by Internet protocols to provide services such as smart home or connected health. Users can access the networked devices to acquire the real world information (e.g. monitoring heartbeat rate) and control the physical environments (e.g. adjusting room temperature).

IoT gains traction among academia, industry and government circles for its business potential and social impact. Cisco promotes the "Internet of Everything (IoE)", the networked connection of people, process, data, and things [IoE], GE initiates "Industrial Internet", the integration of complex physical machinery with networked sensors and software, to organize the Industrial Internet Consortium [IIC].

IoT requires standardization for interoperability among diverse devices and multiple standards are under development currently. IETF defines network and web transfer protocol (e.g. 6lowpan [RFC6775] and CoAP [RFC6690], [RFC7252]), oneM2M [oneM2M] produces technical specifications for a common M2M Service Layer [oneM2M-TS0001], [oneM2M-TS0004], IPSO Alliance [IPSO] publishes Smart Object Guideline [IPSOSmartObjects] and "Open Interconnect Consortium (OIC)" constructs standards and certification for IoT devices [OIC].

1.2. REST and interoperability

Multitude of IoT standards are based on "Representational State Transfer (REST)", which is a software architecture style with a coordinated set of constraints for the design of components in a distributed hypermedia system [REST]. In REST based IoT, a real world entity is represented as resource in a server, which a client accesses and manipulates through RESTful actions on its representation to interact with the entity, i.e. sensing and controlling the physical environments. Moreover several IoT standards adopt the common network and web transfer protocols. oneM2M, IPSO and OIC all use CoAP and IP/ UDP, [oneM2M-TS0008], [IPSO], [OIC] so any client and server supporting those standards can exchange request and response messages.

However in order to interact properly, it's not sufficient for IoT devices to simply transfer CoAP messages. IoT devices should understand each other's resources and be aware of their semantic meaning and syntactic form. Currently each standard defines its own "resource model" and specifies a different scheme to construct resources from physical entities such as light [OIC], [IPSOFramework], [IPSOSmartObjects], [oneM2M-TS0001]. Hence client and server adopting different standards can't perform meaningful interaction, i.e. the client can't manipulate the resource representation in the server.

For wider interoperability among multiple standards, IoT devices need to understand each other's resource model to process CoAP request and response message properly. To interpret resources correctly, clients and servers need to determine which resource model they support in the first place. The client should be aware of whether its corresponding server adopts oneM2M or OIC model and vice versa. It is also possible for a server to support multiple resource models for the same resource.

CoAP provides a scheme to notify the Content-Format information which CoAP endpoints, i.e. client or server, support. A client can use the CoAP Accept Option to inform a server which Content-Format is acceptable and the server returns the preferred Content-Format if available. The Content-Format Option in a response message indicates the representation format of the payload [RFC7252].

With a similar approach this document presents a way for CoAP endpoints to exchange the resource model information among each other. Also this document requests from IANA new Internet media types and numeric Content-Format identifier indicating resource model for OIC (e.g. application/vnd.oic+json).

1.3. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Resource model indication

2.1. Different resource models

In REST based IoT, a physical or software artefact or concept that needs to be made visible and manipulated is represented as resource. The resource encapsulates and presents the salient aspect of an entity with attributes or properties. For example, the notable feature of a smart light can be represented as "light control" resource with the attributes of "On/off", exposing the power state of the light and "Dimmer", the brightness.

A scheme to construct resource from entity is denoted as "resource model", "data model" or "application profile". Take notice that there is no consensus on terminology, so the terms "resource", "resource type", "attribute" and "property" convey different meanings in different organizations.

Currently several standard bodies or Industrial alliances such as oneM2M, IPSO, OIC specifies resource model in different ways. For example, a smart light can be represented as an IPSO Smart Object in JSON as below:

          {
            "3311": {
              "description": "IPSO light control",
              "instances": {
                "0": {
                  "resources": {
                    "5850": {
                      "description": "On/Off",
                      "value": 0
                    },
                    "5851": {
                      "description": "Dimmer",
                      "value": 70
                    }
                  } 
                }
              }
            }
          } 
     
		  

In the above, "3311" is an "Object ID" defining object type, "0" an "Object Instance", designating one or more instances, "5850", "5851", "Resource ID", defining resource type. Also IPSO embeds resource information in data path so "On/Off" resource has predetermined data path of "3311/0/5850" and "Dimmer" resource datapath of "3311/0/5851" [IPSOSmartObjects].

Whereas other SDOs (e.g. oneM2M or OIC) adopt opaque datapaths and separate attributes to indicate resource type (object type in IPSO terminology) [oneM2M-TS0001], [RFC6690]. Under this framework, a smart light may be represented in JSON as below:

          {
            "rt": "oic.r.lt",
            "on": {
              "description": "On/Off",
              "value": 0
            },
            "dim": {
              "description": "Dimmer",
              "value": 70
            }
          }

		  

Note that the same salient features of a smart light, power on/off and brightness, are turned into two different resources (or resource endpoints).

2.2. A scheme to exchange resource model information

IoT devices, i.e. clients and servers, need to understand the resource model that the corresponding device supports in order to interoperate.

For the initial step, it would help for IoT devices to indicate the resource model(s) that each device supports. Then clients and servers may choose a common resource model for interaction, or in the absence of such a common model, rely on translation between the models, possibly with the assistance of 3rd party intermediary.

This document presents a scheme for CoAP endpoints, clients and servers, to negotiate the resource model they support.

First, the Internet media type and Content-Format identifier are used to indicate a specific resource model. The Internet media types can be defined to indicate the resource models, potentially with content-coding, such as "application/ipso+json", then assigned numeric Content-Format identifiers such as "123123" to minimize payload overhead for CoAP usage.

Second, CoAP Accept and Content-Format Option are used to exchange the Content-Format identifiers indicating the resource models which CoAP endpoints prefer or support. A client includes the CoAP Accept option to inform a server which resource model(s), potentially with content-encoding, are acceptable and the server returns the payload in the preferred resource model if supported. The Content-Format Option indicates the resource model of the payload.

2.3. Content-Format request for OIC resource model

The Open Interconnect Consortium (OIC) is an industry group with the objective of specifying standards and certification for devices involved in the Internet of Things based around CoAP [OIC].

OIC is currently developing resource models for IoT services (e.g. smart home) and strives to align with other standard bodies such as oneM2M/IPSO, so that OIC devices can interoperate with devices following different standards. This document proposes a scheme to exchange resource model information as describes in the previous sections.

The resource mode indication scheme requires new Internet media types and CoAP Content-Format identifiers which can indicate OIC resource models with content encoding. Hence the following new Internet media types are requested from IANA:

• application/vnd.oic
  
• application/vnd.oic+json
  
• applicatoin/vnd.oic+cbor

3. IANA Considerations

3.1. New Internet media type - application/vnd.oic

This specification registers a new Internet media type for OIC resource model, "application/vnd.oic".

Type name: application

Subtype name: vnd.oic

Required parameters: None

Optional parameters: None

Encoding considerations: None

Security considerations: As defined in this specification

Interoperability considerations: None

Published specification: This specification.

Applications that use this media type: Any device supporting the OIC resource models

Additional information:

• Magic number(s): N/A
  
• File extension(s): N/A
  
• Macintosh file type code(s):

Personal & email address to contact for further information: JinHyeock Choi <jinchoe@samsung.com>

Intended usage: COMMON

Authors: TBD

Change controller: IETF

3.2. New Internet media type: application/vnd.oic+json

This specification registers a new Internet media type for OIC resource model, "application/vnd.oic+json".

Type name: application

Subtype name: vnd.oic+json

Required parameters: None

Optional parameters: None

Encoding considerations: JSON

Security considerations: As defined in this specification

Interoperability considerations: None

Published specification: This specification.

Applications that use this media type: Any device supporting the OIC resource models

Additional information:

• Magic number(s): N/A
  
• File extension(s): N/A
  
• Macintosh file type code(s):

Personal & email address to contact for further information: JinHyeock Choi <jinchoe@samsung.com>

Authors: TBD

Intended usage: COMMON

Change controller: IETF

3.3. New Internet media type: application/vnd.oic+cbor

This specification registers a new Internet media type for OIC resource model, "application/vnd.oic+cbor".

Type name: application

Subtype name: vnd.oic+cbor

Required parameters: None

Optional parameters: None

Encoding considerations: CBOR

Security considerations: As defined in this specification

Interoperability considerations: None

Published specification: This specification.

Applications that use this media type: Any device supporting the OIC resource models

Additional information:

• Magic number(s): N/A
  
• File extension(s): N/A
  
• Macintosh file type code(s):

Personal & email address to contact for further information: JinHyeock Choi <jinchoe@samsung.com>

Authors: TBD

Intended usage: COMMON

Change controller: IETF

4. Security Considerations

TBD

5. Acknowledgements

This document results from OIC specification discussion. Ravi Subramaniam provided valuable feedback from the beginning and we are grateful to the other members for their contribution.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses