Internet DRAFT - draft-jinchoe-resource-model-indication

draft-jinchoe-resource-model-indication







CoRE Working Group                                              JH. Choi
Internet-Draft                                                   Samsung
Intended status: Standards Track                                G. Bajko
Expires: January 7, 2016                                        MediaTek
                                                              D. Thakore
                                                               CableLabs
                                                            July 6, 2015


                  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.





Choi, et al.             Expires January 7, 2016                [Page 1]

Internet-Draft     Resource Model Indication with CoAP         July 2015


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

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





Choi, et al.             Expires January 7, 2016                [Page 2]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   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



Choi, et al.             Expires January 7, 2016                [Page 3]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   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:














Choi, et al.             Expires January 7, 2016                [Page 4]

Internet-Draft     Resource Model Indication with CoAP         July 2015


             {
               "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
               }
             }






Choi, et al.             Expires January 7, 2016                [Page 5]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   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.





Choi, et al.             Expires January 7, 2016                [Page 6]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   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:

   o  application/vnd.oic

   o  application/vnd.oic+json

   o  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>




Choi, et al.             Expires January 7, 2016                [Page 7]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   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





Choi, et al.             Expires January 7, 2016                [Page 8]

Internet-Draft     Resource Model Indication with CoAP         July 2015


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







Choi, et al.             Expires January 7, 2016                [Page 9]

Internet-Draft     Resource Model Indication with CoAP         July 2015


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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003.

6.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, October 2013.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.






Choi, et al.             Expires January 7, 2016               [Page 10]

Internet-Draft     Resource Model Indication with CoAP         July 2015


   [I-D.ietf-core-links-json]
              Bormann, C., "Representing CoRE Link Collections in JSON",
              draft-ietf-core-links-json-02 (work in progress), July
              2014.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000,
              <http://www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.

   [IPSO]     "IPSO Alliance Home Page",
              <http://www.ipso-alliance.org/>.

   [IPSOFramework]
              Shelby, Z. and C. Chauvenet, "The IPSO Application
              Framework", August 2012, <http://www.ipso-alliance.org/wp-
              content/media/draft-ipso-app-framework-04.pdf>.

   [IPSOSmartObjects]
              "IPSO SmartObject Guideline", September 2014,
              <http://www.ipso-alliance.org/smart-object-guidelines>.

   [OIC]      "Open Interconnect Consortium (OIC) Home Page",
              <http://openinterconnect.org/>.

   [oneM2M]   "oneM2M Home Page", <http://www.onem2m.org/>.

   [oneM2M-TS0001]
              "Functional Architecture", January 2015,
              <http://www.onem2m.org/images/files/deliverables/
              TS-0001-Functional_Architecture-V1_6_1.pdf>.

   [oneM2M-TS0004]
              "Service Layer Core Protocol Specification", January 2015,
              <http://www.onem2m.org/images/files/deliverables/
              TS-0004-Service_Layer_Core_Protocol-V1_0_1.ZIP>.

   [oneM2M-TS0008]
              "CoAP Protocol Binding", January 2015,
              <http://www.onem2m.org/images/files/deliverables/
              TS-0008-CoAP_Protocol_Binding-V1_0_1.pdf>.

   [IIC]      "Industrial Internet Consortium (IIC) Home Page",
              <http://www.industrialinternetconsortium.org/>.

   [IoE]      "Internet of Everything (IoE) Home Page",
              <http://ioeassessment.cisco.com/>.




Choi, et al.             Expires January 7, 2016               [Page 11]

Internet-Draft     Resource Model Indication with CoAP         July 2015


Authors' Addresses

   JinHyeock Choi
   Samsung Electronics Co., Ltd.
   129 Samsung-ro
   Suwon, Gyeonggi  443-742
   Korea

   Email: jinchoe@samsung.com


   Gabor Bajko
   MediaTek USA Inc.
   2860 Junction Ave
   San Jose, CA  95134
   USA

   Email: gabor.bajko@mediatek.com


   D. Thakore
   Cable Television Laboratories, Inc.
   858 Coal Creek Circle
   Louisville, CO  80023
   USA

   Email: d.thakore@cablelabs.com
























Choi, et al.             Expires January 7, 2016               [Page 12]