Internet DRAFT - draft-hong-core-coap-endpoint-unit-id
draft-hong-core-coap-endpoint-unit-id
Network Working Group Y-G. Hong
Internet-Draft Y-H. Choi
Intended status: Informational ETRI
Expires: April 30, 2015 D-H. Kim
M-S. Khan
W-Q. JIN
Jeju Nat. Univ.
October 27, 2014
CoAP Endpoint Unit Identification for Multiple Sensor and Actuator in a
Node
draft-hong-core-coap-endpoint-unit-id-01
Abstract
The Constrained Application Protocol (CoAP) is a protocol intended
towards devices which are constrained in terms of memory, processing
and power i.e. small low power sensors, switches and valves etc. The
CoAP allows such devices to interactively communicate over the
Internet. This document is motivated by the concept of a composite
CoAP node, a single CoAP entity which integrates multiple CoAP
resources (sensors, actuators) and the scheme to allow the
identification of individual integrated resources while using the
Unit ID as a new CoAP option. The Unit ID option in the CoAP enables
the usage of composite nodes consisting of multiple sensors and
actuators while having a single IP address for communication. The
integrated resources can be individually or collectively communicated
with and/or controlled using CoAP messages with additional options of
UnitSize and UnitID. The UnitSize is basically a numeric value
indicating the number of sub-resources in a composite CoAP node while
the UnitID option has the string identifiers for the sub-resource(s)
for which the message is intended. These options will enable the
CoAP to communicate and control multiple resources by using single
composite messages i.e. UnitID = "*", efficiently utilize IP
addresses i.e. one IP multiple IDs, reduce communication traffic and
hence conserve power among the CoAP resources.
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/.
Hong, et al. Expires April 30, 2015 [Page 1]
Internet-Draft CoAP Endpoint UnitID option October 2014
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 April 30, 2015.
Copyright Notice
Copyright (c) 2014 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. The use case of multiple CoAP unit identification and control 4
4. IP and Endpoint Unit ID mapping architecture . . . . . . . . 5
5. Benefits of the Endpoint Unit Identification . . . . . . . . 6
6. The Extended CoAP Header . . . . . . . . . . . . . . . . . . 7
7. Procedure of the Endpoint Unit Identification . . . . . . . . 8
7.1. Sub Unit(s) Registration with RD . . . . . . . . . . . . 8
7.2. Sub Unit Lookup in RD . . . . . . . . . . . . . . . . . . 9
7.3. CoAP Client Server Interaction (Single Unit) . . . . . . 10
7.4. CoAP Client Server Interaction (Multiple Units) . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This draft presents a conceptual architecture and design features of
multiple Unit IDs in a node for resource discovery, registration and
lookup. The concept of node ID has been presented in
[I-D.li-coap-nodeid]. This draft presents the idea of nodes having
Hong, et al. Expires April 30, 2015 [Page 2]
Internet-Draft CoAP Endpoint UnitID option October 2014
multiple integrated sensing and/or actuating devices. Each of these
devices is separately identifiable via a Unit ID. The Unit ID for a
given resource must be unique among all the integrated resources in a
single node while the same ID can represent a resource integrated in
another node.
The integrated resources inside a node are separately identified by
node IP and Unit ID together. Every node has an IP address through
which it can communicate with clients or other modules of the system
(Resource Directory). A detailed description of the purpose and
features of Resource Directory have been presented in
[I-D.ietf-core-rd].
+---------+
+-------------------------------->| Sensor | Type=Sensor
| | Node | IP=x.x.x.x
| --+---------+ Function=f1
| +---------+ --
V | | -- +---------+
+--------+ |Resource | -- |Actuator | Type=Actuator
| Client |<----->| |<---------| Node | IP=x.x.x.x
+--------+ |Directory| -- +---------+ Function:f1,f2
| | --
+---------+ --
--+---------+ Type=Composite
|Composite| IP=x.x.x.x
| Node | Function=f1,f2,f3
+---------+ Sub-Units=2
Sub-unit1: Sub-unit2:
Unit ID=sub001 Unit ID=sub002
Type=Sensor Type=Actuator
Function=f1 Function=f2
Figure 1: Endpoint Unit ID and Resource Directory
Figure 1 shows that a node may contain a single or multiple
integrated resources i.e. multiple sensors, multiple actuators or
sensors and actuators in a single node. The nodes register these
resources with the Resource Directory. The Resource Directory
defines its own function sets for discovery, registration and lookup
etc. Once a node had registered all its integrated resources with
the Resource Directory, the clients may lookup single or multiple
resources and may interact with them directly. The Resource
Directory helps in the automated discovery and lookup of resources
Hong, et al. Expires April 30, 2015 [Page 3]
Internet-Draft CoAP Endpoint UnitID option October 2014
while the multi-Unit IDs provide an efficient utilization of a single
IP for interacting with multiple resources.
As described in [RFC7252], there are two entities required for CoAP
communication i.e. CoAP Client and CoAP Server. A CoAP Server may
also act as client and vice versa if both of these entities have
resources to share and require certain resources from each other.
The CoAP server discovers a Resource Directory (RD)
[I-D.ietf-core-rd]. The discovery of RD means finding location of
the register function set in the RD using which a CoAP server may
register the resources which it wants to share.
Once a complete path is obtained for a register function set in the
RD, the CoAP server may then register (publish) resources to the RD.
The CoAP clients then requests the RD to look up for registered
resources. The RD then returns the access paths for the registered
resources according to the request of the client. The returned
resources may include simple or composite resources and the client
can communicate with these resources. If a single CoAP node has
multiple integrated sub devices, then the composite interaction with
the resources is based on Unit-ID(s). The client can interact with
individual sub devices or collectively interact with all the sub
devices of a composite node. It is important to note that the
description and discovery of resources hosted by a constrained web
server is specified by the CoRE Link Format [RFC6690] which is based
on the Web Linking [RFC5988] for the discovery of resources hosted by
an HTTP Web Server.
2. Conventions and Terminology
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].
3. The use case of multiple CoAP unit identification and control
Figure 2 shows the use case scenario for a CoAP composite node which
integrates a light sensor and two switches to control the lights in a
room. The composite node is accessed via a single IP address
assigned to it while the sub-resources of the composite node are
accessed with Unit IDs. The composite node like a normal CoAP
Endpoint, registers its resources in the form of sub units with the
RD. The RD, thus have a single IP address for the composite node and
Unit IDs for the sub units of the composite node.
Hong, et al. Expires April 30, 2015 [Page 4]
Internet-Draft CoAP Endpoint UnitID option October 2014
+-------------+
+------------>| CoAP Client |
| +-------------+
| Discovery A
| & LookUp | CoAP
| | Communication /|
| V --> < | Light001
V +----------------+ --- \|
+---------+ | Composite Node | ---
|Resource | | | --- |--|
| |<-----| Light sensor & |----------> | | LightSensor001
|Directory| | Lights for a | --- +==+
+---------+ | room | ---
+----------------+ --- /|
--> < | Light002
\|
Figure 2: Multiple UnitID based composite CoAP node interaction use
case
A CoAP client performs look up on the RD and gets the required
resource information. Suppose the client wants to interact with the
composite node, the information regarding all its sub units is also
provided to the client by the RD. The client then use this
information (i.e. UnitSize, UnitID) to create CoAP messages in order
to interact with a single or multiple sub units of the composite
node. For example, the user may send a CoAP message with UnitSize=1
and UnitID= "lightSensor001" to request data from the light sensor.
The Composite node will return an ACK message with UnitID parameter
and sensor reading as message payload. The client may also send a
CoAP message with UnitSize=2 and UnitID= "Light001",
UnitID="Light002" options to turn-on or off the lights with a single
message.
4. IP and Endpoint Unit ID mapping architecture
Hong, et al. Expires April 30, 2015 [Page 5]
Internet-Draft CoAP Endpoint UnitID option October 2014
+----------------------------------------------------------+
| |
| Network IP |
| |
+--------|-------------------|-------------------|---------+
| | |
+--------|-------------------|-------------------|---------+
| +------V------+ +------V------+ +------V------+ |
| | Node IP 1 | | Node IP 2 | | Node IP 3 | |
| +-------------+ +-------------+ +-------------+ |
+---|---------|---------|---------|---------|---------|----+
| | | | | |
+---|---------|---------|---------|---------|---------|----+
|+--V---+ +--V---+ +--V---+ +--V---+ +--V---+ +--V---+|
|| Unit | | Unit | | Unit | | Unit | | Unit | | Unit ||
|| ID 1 | | ID 2 | | ID 4 | | ID 1 | | ID 3 | | ID 2 ||
|+------+ +------+ +------+ +------+ +------+ +------+|
+----------------------------------------------------------+
Figure 3: IP address and Endpoint Unit ID mapping architecture
Figure 3 presents a generalized architecture for IP and ID mapping in
the proposed Endpoint Unit ID scenario. The network IP and local IP
addresses are used to access the network of the node and the physical
node respectively. We proposed that a single node may have multiple
integrated resources and each of these resources can be represented
by multiple sub-identifiers (IDs). The sub-identifier for the
integrated resource is called as the Unit ID and a node may have more
than one Unit IDs.
This scheme enables the use of single IP address for communicating
with multiple resources (units) and each resource may be treated as a
separate entity having its own address. Thus the result is efficient
utilization of addressing space by combining the Node IP and Unit ID
pairs. Group registration, lookup etc. and group communication for
CoAP resources have been described in [I-D.ietf-core-rd] and
[I-D.ietf-coap-group] respectively but both these drafts consider
every resource in a group as a unique addressable entity hence no
benefits when it comes to controlling IP address space usage or
communication traffic load.
5. Benefits of the Endpoint Unit Identification
The Unit ID concept for composite endpoint (Node) provides the
following major benefits.
Hong, et al. Expires April 30, 2015 [Page 6]
Internet-Draft CoAP Endpoint UnitID option October 2014
a. A composite node with multiple integrated sub-unit resources
will require only one IP address and using the IP address and Unit
ID pairs, individual resources can be separately accessed without
the need to have a separate IP address for each resource. Thus
the proposed scheme efficiently utilizes IP address space to
represent more devices with lesser number of IP addresses.
b. A single CoAP message with Unit ID parameter may be used to
control sub-devices collectively using special characters. For
example, a given composite endpoint may have sensors and actuators
and all these sub-unit devices can be controlled with a single
message using "*" as the Unit ID parameter value.
c. Using composite messages for Unit ID may also benefit in
reducing traffic flow between client and endpoints (CoAP Server)
and may also help in conserving energy in the constrained devices.
6. The Extended CoAP Header
Figure 4 shows the CoAP message header format. The header for the
CoAP message is all the same with fields such as version, Type, and
Token length etc. The change can be seen in the options section
where the UnitSize field specifies the number of sub-unit integrated
into a single composite node and the UnitID option which can hold a
string ID for UnitID representing a sub-unit in a composite node.
The UnitID field can be repeated multiple times according to the
value of the UnitSize parameter and every time representing a single
string ID for a sub-unit related to a specific composite node.
Hong, et al. Expires April 30, 2015 [Page 7]
Internet-Draft CoAP Endpoint UnitID option October 2014
+-------------------------------------------------------+
| Byte 1 | Byte 2 | Byte 3 | Byte 4 |
+--------------+-------------+--------------------------+
| V | T | Len | Code | Message ID |
+--------------+-------------+-------------+------------+
| Token ( 0 ?8 Bytes ) |
+-------------------------------------------------------+
| Options (if any) |
+-------------------------------------------------------+
/\
////// \\\\\\
//////// \\\\\\\\\
///////// \\\\\\\\\
///// \\\\\
+-----------------------------------------------------------+
| UnitSize | Numeric Value | UnitID | String value |
+-----------------------------------------------------------+
Figure 4: Multi-ID CoAP message format
7. Procedure of the Endpoint Unit Identification
7.1. Sub Unit(s) Registration with RD
Figure 5 shows the sequence of activities involved in the
registration of Endpoint Unit ID nodes with integrated resources in
the RD. In order for a node to register its integrated resources
with the RD, the node uses the RD's registration function set and
sends a CoAP POST message to the RD. The message payload contains
the list of all the Unit IDs associated with the node. The RD
receives the message and checks whether the request is valid. If the
RD receives a valid request from the node, the source IP address and
Port number from the CoAP request parameters or the message source
address portion (default). The RD then extracts the Unit IDs from
the message payload and creates a resource location for all the
resources and returns a response message to the node. If the
registration process is successful then a location URI is returned to
the requesting node so it may update the registration or remove the
location entry thus cancelling the registration of its integrated
resources otherwise an error message is returned mentioning the cause
of the failure.
Hong, et al. Expires April 30, 2015 [Page 8]
Internet-Draft CoAP Endpoint UnitID option October 2014
+-------+ +----+
| Node | | RD |
+-------+ +----+
| |
| POST coap://{rd-ip:port}/rd?ep=node1 |
|--------------------------------------------------->|
| Payload: |
| <unitID001>;ct=41;rt="temperature-c";if="sensor",|
| <unitID002>;ct=41;rt="light-lux";if="sensor" |
| | Receive
| | Request
| IF REQUEST OK? |
| | Store
| | Source IP
| | & port
| |
| | Create
| | resource
| 2.01 Created | location
|<---------------------------------------------------|
| ELSE |
| |
| 4.00 Bad Request / 5.03 Service Unavailable |
|<---------------------------------------------------|
| |
Figure 5: Endpoint Unit ID resource registration with RD
7.2. Sub Unit Lookup in RD
Figure 6 presents the RD based lookup process for Endpoint Unit ID
resources integrated into a single node i.e. single IP address. The
diagram shows a client requesting for a specific type (Temperature)
of resources registered with the RD. For this purpose, it sends GET
request to the RD with the type of resources the client wants to
lookup in the directory. The RD receives the message, checks if the
message is a valid CoAP request and then gets the IPs for all the
registered resources with the resource type value equivalent to the
one requested by the client (Temperature). The RD then creates a
response message with the list of node IP address and resource IDs
and sends it to the client. The client may then choose a specific
resource from this list and communicate with it directly using the
CoAP protocol.
Hong, et al. Expires April 30, 2015 [Page 9]
Internet-Draft CoAP Endpoint UnitID option October 2014
+--------+ +----+
| Client | | RD |
+--------+ +----+
| |
| GET coap://{rd-ip:port}/rd-lookup/res? |
| rt=temperature |
|------------------------------------------->|
| | Receive
| | Request
| IF REQUEST OK? |
| | Lookup all
| | temp resource IDs
| |
|<-------------------------------------------|
| 2.05 Content | return list of
| <coap://{node-ip:port}/node1/unitID001> | unit IDs
| |
| ELSE |
| |
| 4.00 Bad Request / 4.04 Not Found |
|<-------------------------------------------|
| or 5.03 "Service Unavailable" |
Figure 6: RD based resource lookup
7.3. CoAP Client Server Interaction (Single Unit)
Figure 7 shows the interaction among a client and resource (CoAP
Server). As mentioned previously, the client performs lookup on the
RD for a specific resource type and gets the list of all the resource
IDs (node IP and Unit ID) registered with the RD. The following
figure shows the process of client selecting a resource from that
list and communicating with it directly.
Once the client decides to interact with a resource, it gets the
resource complete URI i.e. Node IP address, Port number and Unit ID
if it is a composite node. For a simple resource i.e. sensor or
actuator, the node IP address is used to perform the interaction
between the CoAP client and server while for a composite node i.e.
with multiple integrated resources (multiple unit IDs), the client
creates a Unit ID, Token pair and sends a GET request to the
integrated resource of a node using the complete URI. Here the Token
means the CoAP token sent with a normal GET request. The node (CoAP
Server), checks the request's validity and responds back to the
client with an ACK, consisting of the Token and data from the
integrated resource. The client checks the source of the data by
comparing the Token of the ACK with the stored Unit ID, Token pair.
Hong, et al. Expires April 30, 2015 [Page 10]
Internet-Draft CoAP Endpoint UnitID option October 2014
+--------+ +--------+
| Client | | Server |
+--------+ +--------+
| |
| Select resource |
| (Unit ID) |
| |
| get corresponding |
| IP:Port |
| |
| create Unit ID:Token |
| pair |
| |
| Con[0xbc90] |
| GET coap://{node-ip:port}/node1/unitID001 |
|--------------------------------------------->|
| [Token 0x71] |
| | Receive Request
| |
| ACK[0xbc90] | Get JSON data from
| 2.05 Content | integrated
| {"unit_id":"unitID001", | resources
| "data":"22.5 C"} |
|<---------------------------------------------|
| [Token 0x71] |
| |
| |
| Compare Token |
| with Unit ID |
| |
Figure 7: CoAP based client server interaction (single Unit ID)
7.4. CoAP Client Server Interaction (Multiple Units)
Figure 8 shows the interaction among a client and multiple resources
i.e. multiple Unit IDs. The example shown in the figure suggests
that both Unit IDs belong to a single node but the Unit IDs may also
belong to more than one CoAP nodes. As mentioned previously, the
client performs lookup on the RD for a specific resource type and
gets the list of all the resource IDs (Unit ID) registered with the
RD. The following figure shows the process of client choosing to
interact with multiple unit resources (integrated resources) from the
list provided by the RD.
Hong, et al. Expires April 30, 2015 [Page 11]
Internet-Draft CoAP Endpoint UnitID option October 2014
Once the client selects the resources' complete URI i.e. Node IP
address, Port number and Unit IDs for communication, the client
creates and stores the Unit ID, Token pairs.
+--------+ +--------+
| Client | | Server |
+--------+ +--------+
| |
| Select resources |
| (Multiple Unit IDs) |
| |
| get corresponding |
| IP:Port pairs |
| |
| create Unit ID:Token |
| pairs |
| |
| Con[0xbc90] |
| GET coap://{node-ip:port}/node1?unit_size=2 |
| |
|--------------------------------------------->|
| [Token 0x71] |
| | Receive
| | request
| ACK[0xbc90] | Get
| 2.05 Content | JSON data
| {"node1":[ | from
| {"unit_id":"unitID001","data":"22.5"}, | integratedd
| {"unit_id":"unitID002","data":"1000 LUX"}]} | resources
|<---------------------------------------------|
| [Token 0x71] |
| |
| Compare Token |
| with Unit ID |
| |
Figure 8: CoAP based client server interaction (Endpoint multiple
Unit ID
Here the Token means the CoAP token sent with a normal GET request.
The client then sends a GET request to the integrated resources
belonging to one or more nodes using the complete URIs (Node IP
address, Port number, Unit IDs). The GET request with multiple Unit
IDs also has the Unit size parameter, mentioning the number of
integrated resources from which the client requests data. The node
(CoAP Server), checks the request's validity and responds back to the
Hong, et al. Expires April 30, 2015 [Page 12]
Internet-Draft CoAP Endpoint UnitID option October 2014
client with an ACK, consisting of the Token and data from the
integrated resources. The client checks the source of the data by
comparing the Token of the ACK with the stored Unit ID, Token pairs.
8. Security Considerations
TBD.
9. IANA Considerations
TBD
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
10.2. Informative References
[I-D.ietf-coap-group]
Rahman, A. and E. Dijk, "Group Communication for CoAP", ID
draft-ietf-core-groupcomm-19, June 2014.
[I-D.ietf-core-rd]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", ID draft-ietf-core-resource-directory-01 ,
December 2013.
[I-D.li-coap-nodeid]
Li, K. and G. Wei, "CoAP Option Extension: NodeId", ID
draft-li-core-coap-node-id-option-01 , June 2014.
Authors' Addresses
Hong, et al. Expires April 30, 2015 [Page 13]
Internet-Draft CoAP Endpoint UnitID option October 2014
Yong-Geun Hong
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 6557
Email: yghong@etri.re.kr
Young-hwan Choi
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr
Do-Hyeun Kim
Jeju Nat. Univ.
Jeju
Korea
Phone: +82 64 754 3658
Email: kimdh@jejunu.ac.kr
Mohammad-Sohail Khan
Jeju Nat. Univ.
Jeju
Korea
Phone: +82 64 754 3658
Email: sohail.khan@nwfpuet.edu.pk
Wen-Quan JIN
Jeju Nat. Univ.
Jeju
Korea
Phone: +82 64 754 3658
Email: pluskmk12@live.com
Hong, et al. Expires April 30, 2015 [Page 14]
