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]
