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: | | ;ct=41;rt="temperature-c";if="sensor",| | ;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 | | 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]