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

Abstract

There has been much interest in "Internet of Things (IoT)" and multiple standards are under development that utilize the RESTful architectural style. In REST, IoT devices need to understand each other's resources, both the semantic meaning and syntactic form, to interact properly. For interoperability among different standards, it is of help 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 IANA to register new Internet media types & 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 September 19, 2016.

Copyright Notice

Copyright (c) 2016 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 OIC resource model Internet media type
• 3.2. New OIC resource model in JSON Internet media type
• 3.3. New OIC resource model in CBOR Internet media type
• 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 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 [OICSPEC] and certification for IoT devices [OCF].

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 the resource through representations 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], [OCF] 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 be able to 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 [OICSPEC], [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, client and server need to determine which resource model each other follows in the first place. The client should be aware of whether its corresponding server adopts oneM2M or OIC model and vice versa.

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 alliance such as oneM2M, IPSO, OIC specifies resource model in a different way. 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 datapath and separate attribute to indicate resource type (object type in IPSO terminology) [OICSPEC], [oneM2M-TS0001], [RFC6690]. Under this framework, a smart light in OIC may be represented in JSON as below:

			{
				"rt": "oic.r.switch.binary",
				"if": "oic.if.a oic.if.baseline",
				"n": "myRoomLightSwitch",
				"value": false
			}
			
			{
				"rt": "oic.r.light.brightness",
				"if": "oic.if.a oic.if.basline",
				"n": "myRoomLightBrightness",
				"brightness": 70
			}

		  

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

2.2. A scheme to exchange resource model information

IoT devices, i.e. client and server, need to understand the resource model which their corresponding device supports to be able to interoperate with each other.

For the initial step, it will help interoperability if IoT devices indicated the resource model they supported. 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 a 3rd party.

This document presents a scheme for CoAP endpoints, client and server, to exchange 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, potentially with content-encoding, is acceptable and the server returns the payload in the preferred resource model if available. The Content-Format Option indicates the resource model which the payload follows.

Third, a known resource is used as an entry point for resource model exchange. Resource discovery in CoRE is accomplished through a well-known resource "/.well-known/core". OIC relies on a knwon resource URI "/oic/res" for initial discovery. Any client that wants to discover OIC resources uses this URI to discover other OIC resources. A client sends a CoAP GET request targeting the known resource URI with Accept Option and servers respond with Content-Format Option.

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 [OICSPEC].

OIC is currently developing resource model for IoT services (e.g. smart home) and strives to align with other standard bodies such as oneM2M or IPSO, so that OIC devices can interoperate with the devices following different standards. For this purpose, OIC prepares 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 OIC requests from IANA the new Internet media types as below.

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

3. IANA Considerations

3.1. New OIC resource model Internet media type

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: OIC vertical applications (e.g. Smart Home)

Additional information:

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

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

Intended usage: COMMON

Author(s): JinHyeock Choi

Change controller:

3.2. New OIC resource model in JSON Internet media type

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: OIC vertical applications (e.g. Smart Home)

Additional information:

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

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

Intended usage: COMMON

Authors: JinHyeock Choi

Change controller:

3.3. New OIC resource model in CBOR Internet media type

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

Type name: application

Subtype name: vnd.oic

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: OIC vertical applications (e.g. Smart Home)

Additional information:

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

Person email address to contact for further information:

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

Intended usage: COMMON

Authors: JinHyeock Choi

Change controller:

4. Security Considerations

TBD

5. Acknowledgements

TBD

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses