Network Working Group M. Koster Internet-Draft ARM Limited Intended status: Standards Track A. Keranen Expires: January 5, 2015 J. Jimenez Ericsson July 4, 2014 Message Queueing in the Constrained Application Protocol (CoAP) draft-koster-core-coapmq-00.txt Abstract The Constrained Application Protocol, CoAP, and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines publish- subscribe message queuing functionality for CoAP that extends the capabilities for supporting nodes with long breaks in connectivity and/or up-time. 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 5, 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 Koster, et al. Expires January 5, 2015 [Page 1] Internet-Draft Message Queueing in CoAP July 2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. RD Server with associated CoAP-MQ Broker . . . . . . . . 4 3.2. Client Endpoint . . . . . . . . . . . . . . . . . . . . . 5 3.3. Server Endpoint . . . . . . . . . . . . . . . . . . . . . 5 3.4. Publish-Subscribe Topics . . . . . . . . . . . . . . . . 5 4. CoAP-MQ Registration and discovery . . . . . . . . . . . . . 6 4.1. Register PubSub Endpoint . . . . . . . . . . . . . . . . 6 4.2. Unregister Endpoint . . . . . . . . . . . . . . . . . . . 7 5. CoAP-MQ Functions and Interactions . . . . . . . . . . . . . 7 5.1. Client Role Endpoint Functions . . . . . . . . . . . . . 8 5.1.1. Client Endpoint PUBLISH to CoAP-MQ broker . . . . . . 8 5.1.2. Client Endpoint SUBSCRIBE, Broker PUBLISH . . . . . . 8 5.1.3. Client Endpoint GET from CoAP-MQ Broker . . . . . . . 9 5.2. Server Role Endpoint Functions . . . . . . . . . . . . . 9 5.2.1. CoAP-MQ broker SUBSCRIBES to Server Role EP . . . . . 10 5.2.2. CoAP-MQ Broker Publishes to Server Role Endpoint . . 10 5.2.3. CoAP-MQ Broker GET from Server Role Endpoint . . . . 11 6. Enabling Multiple Publishers . . . . . . . . . . . . . . . . 11 6.1. Creating a Topic . . . . . . . . . . . . . . . . . . . . 11 6.2. Publishing a Topic from Multiple Publishers . . . . . . . 12 6.3. Subscribing to a topic with multiple publishers . . . . . 12 7. Sleep-Wakeup Operation and Message Queueing . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Resource Type value 'core.pubsub.client' . . . . . . . . 14 9.2. Resource Type value 'core.pubsub.server' . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Constrained Application Protocol (CoAP) [6] supports machine to machine communication across networks of constrained devices. One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging Koster, et al. Expires January 5, 2015 [Page 2] Internet-Draft Message Queueing in CoAP July 2014 energy from their environment. These devices spend most of their time in a sleeping state with no network connectivity. Devices may also have limited reachability due to certain middle- boxes, such as Network Address Translators (NATs) or firewalls. Such devices must communicate using a client role, whereby the endpoint is responsible for initiating communication. This document specifies the means for nodes with limited reachability to communicate using simple extensions to CoAP and the CoRE Resource Directory [4]. The extensions enable publish-subscribe communication using a Message Queue (MQ) broker node that enables store-and-forward messaging between two or more nodes. The mechanisms specified in this document are meant to address key design requirements from earlier CoRE drafts covering sleepy node support and mirror server. 2. Terminology The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this specification are to be interpreted as described in [1]. This specification requires readers to be familiar with all the terms and concepts that are discussed in [8] and [2]. Readers should also be familiar with the terms and concepts discussed in [6] and [4]. The URI template format, see [3], is used to describe the REST interfaces defined in this specification. The following entities are used in this specification: CoAP Message Queue (CoAP-MQ) Service A service provided by a node or system where CoAP messages sent by one endpoint to another are queued (stored) by intermediate node(s) and forwarded only when suitable, e.g., when the message recipient endpoint is not sleeping. CoAP-MQ Broker A server node capable of storing messages to and from other nodes and able to match subscriptions and publications in order to route messages to right destinations. CoAP-MQ Endpoint An endpoint that implements the MQ function set defined in Section 5. A CoAP-MQ endpoint has two potential roles, CoAP-MQ client and CoAP-MQ server This specification makes use of the following additional terminology: Koster, et al. Expires January 5, 2015 [Page 3] Internet-Draft Message Queueing in CoAP July 2014 CoAP Message Queue (CoAP-MQ) Service A service provided by a node or system where CoAP messages sent by one endpoint to another are queued (stored) by intermediate node(s) and forwarded only when suitable, e.g., when the message recipient endpoint is not sleeping. CoAP-MQ Broker A server node capable of storing messages to and from other nodes and able to match subscriptions and publications in order to route messages to right destinations. CoAP-MQ function set A group of well-known REST resources that together provide the CoAP-MQ service. CoAP-MQ Endpoint An endpoint that implements the CoAP-MQ function set. A CoAP-MQ endpoint has two potential roles, CoAP-MQ client and CoAP-MQ server. Publish-Subscribe (pub-sub) A messaging paradigm where messages are published (e.g., to a broker) and potential receivers can subscribe to receive the messages. Topic In Publish-Subscribe systems a topic is a unique identifying string for a particular item or object being published and/or subscribed to. 3. Architecture 3.1. RD Server with associated CoAP-MQ Broker Figure 1 shows an example architecture of a CoAP-MQ capable service. A Resource Directory service accepts registrations and registration updates from one or more endpoints and hosts a resource discovery service for one or more web application clients. State information is updated from the endpoints to the CoAP-MQ broker. Web clients subscribe to the state of the endpoint from the CoAP-MQ broker, and publish updates to the endpoint state through the CoAP-MQ broker. The CoAP-MQ broker performs a store-and-forward function between web clients and the CoAP-MQ capable endpoints. The CoAP-MQ broker is also responsible for acting as a proxy, returning the last published value to web clients or other endpoints on behalf endpoints that are sleeping. Koster, et al. Expires January 5, 2015 [Page 4] Internet-Draft Message Queueing in CoAP July 2014 Endpoints Service Applications +------+ | | +- register -> | RD | <- discover -+ +------+ | | | | +--------+ | | --+ +------+ +-- | Web | | EP | | Client | | | <-+ +------+ +-> | app | +------+ | | CoAP | | +--------+ | EP | +-- pub/sub -> | MQ | <- pub/sub --+ | app | +------+ |Broker| +--------+ +------+ Figure 1: CoAP MQ Architecture 3.2. Client Endpoint Client endpoints initiate all interactions with the RD and MQ broker. If the endpoint is an actuator it will need to either use CoAP Observe [I-D.ietf-core-observe] or periodically poll the MQ broker to check for updates. A CoAP-MQ client endpoint MUST use CoAP PUT operations to update its state on the MQ broker. An endpoint SHOULD update the RD periodically to indicate that it is still alive even if it has no pending data updates. Endpoints can operate in the client role even if not directly reachable from the CoAP-MQ broker or RD server. 3.3. Server Endpoint Server endpoint interactions require the CoAP-MQ broker to perform the client role, initiating interaction with the server endpoint. The CoAP-MQ broker MAY then use PUT operations to update state at the server endpoint, and MAY use GET or GET+Observe to subscribe to resources at the endpoint. Server mode endpoints are required to be reachable from the CoAP-MQ broker. In a network containing both client and server endpoints, client endpoints MAY subscribe to server endpoints directly, in broker-less configurations, using RD or core- link-format metadata in .well-known/core to discover the CoAP-MQ capabilities and using GET+Observe to subscribe to the desired topics. 3.4. Publish-Subscribe Topics Topic are strings used to identify particular resources and objects in publish-subscribe systems. Topics are conventionally formed as a hierarchy, e.g. "/sensors/weather/barometer/pressure". Koster, et al. Expires January 5, 2015 [Page 5] Internet-Draft Message Queueing in CoAP July 2014 Implementations are free to map topics to resources, reusing existing resource addressing schemes. 4. CoAP-MQ Registration and discovery An endpoint wishing to use a CoAP-MQ broker registers with an RD server that advertises a service having the the "core.mq" attribute. This indicates that there is a CoAP-MQ broker at the location returned by the discovery query as shown in Figure 2. The endpoint registers topics using the "rt=core.pubsub.client" or "core.pubsub.server" (or both) attributes to indicate intention to use CoAP-MQ and which roles are supported. A server that implements a CoAP_MQ broker MAY advertize this capability by registering the rt="core.mq" with an associated Resource Directory. If a server advertizes as a CoAP-MQ Broker, it MUST support the transactions described in section 5 of this document. As server that implements the CoAP-MQ Broker MAY also implement sleeping endpoint and message queueing support referred to in Section 6 of this document. 4.1. Register PubSub Endpoint Figure 2 shows the flow of the registration operation. Discovery proceeds as per CoRE Resource Directory[I-D.ietf-core-resource- directory-01]. When an endpoint wishes to use CoAP-MQ, it discovers the rt="core.mq" attribute at the RD service associated with the CoAP-MQ broker and registers its CoAP-MQ resources with the RD server by registering topics having the rt="core.pubsub" attribute. Topics are created using an initial POST operation to the registered topic or any valid sub-topic. For example, if the registered topic is "/sensors/weather", the sub-topic "/sensors/weather/barometer" is created using a POST to "/mq/sensors/weather/barometer". An implementation MAY mix CoAP-MQ resources and CoAP REST resources on the same endpoint. Endpoint registration proceeds as per normal RD registration. Koster, et al. Expires January 5, 2015 [Page 6] Internet-Draft Message Queueing in CoAP July 2014 EP MQ RD | MQ DISCOVERY | | | -------- GET /.well-known/core?rt=core.mq --- | ------> | | | | | <-------- 2.05 Content "; rt=core.mq"--- | ------- | | | | | | | | TOPIC REGISTRATION | | | ---POST /rd ";rt=core.pubsub.xx"--- | ------> | | | | | <-------- 2.01 Created Location: /rd/1234 --- | ------- | | | | | | | | FIRST PUBLISH | | | ---------------- POST /mq/0/... ------------> | | | | | | <--------------- 2.01 Created---------------- | | | | | Figure 2: Discovery and Registration 4.2. Unregister Endpoint CoaAP-MQ endpoints indicate the end of their registration tenure by either explicitly unregistering, as in Figure 3, or allowing the lifetime of the previous registration to expire. EP MQ RD | | | | UNREGISTER | | | ---------------- DELETE /rd/1234 ------------ | ------> | | | | | <-------- 2.02 Deleted Location: /rd/1234 --- | ------- | | | | | | | Figure 3: Unregister Endpoint 5. CoAP-MQ Functions and Interactions This section describes the transaction flows and interactions between CoAP-MQ endpoints and CoAP-MQ brokers. Client endpoint functions are used by endpoints implementing the client role, for example to enable sleep/wakeup and partial connectivity. Server role endpoint functions are used by enpoints implementing the server role, for Koster, et al. Expires January 5, 2015 [Page 7] Internet-Draft Message Queueing in CoAP July 2014 example always on, reachable, endpoints. An endpoint implementation MAY support both client role and server role at an endpoint. A CoAP- MQ broker MUST implement support for both client role and server role endpoints. 5.1. Client Role Endpoint Functions This section describes the transaction flows and interactions between CoAP-MQ endpoints and CoAP-MQ brokers where the endpoint supports the client role. A client registering the "core.pubsub.client" attribute MUST support the client role endpoint functions and interactions described in this section. 5.1.1. Client Endpoint PUBLISH to CoAP-MQ broker Client endpoint PUBLISH updates to CoAP-MQ broker. EP MQ RD | | | | | | | PUBLISH | | | --------------- PUT /mq/0/... --------------> | | | | | | | | | <--------------- 2.04 Changed---------------- | | | | | | | | Figure 4: Client Role PUBLISH from EP to Broker 5.1.2. Client Endpoint SUBSCRIBE, Broker PUBLISH Client mode endpoint subscribes to the topic at the CoAP-MQ broker using GET+Observe. Published updates to the CoAP-MQ broker are published to the Endpoint using Observe response tokens. Client endpoint MAY update actuator or resource based on received values associated with responses. A CoAP-MQ broker MUST publish updates to subscribed endpoints upon receiving published updates on the associated topics. Koster, et al. Expires January 5, 2015 [Page 8] Internet-Draft Message Queueing in CoAP July 2014 EP MQ RD | | | | | | | SUBSCRIBE | | | ----- GET /mq/0/... Observe: Token:XX ------> | | | | | | PUBLISH | | | <---------- 2.05 Content Observe:10---------- | | | | | | PUBLISH | | | <---------- 2.05 Content Observe:12---------- | | | | | | PUBLISH | | | <---------- 2.05 Content Observe:15---------- | | | | | | | | Figure 5: Client Role Endpoint SUBSCRIBE, Broker PUBLISH to Endpoint 5.1.3. Client Endpoint GET from CoAP-MQ Broker Client mode endpoint MAY issue GET to topic without Observe as needed to obtain last published state from the CoAP-MQ broker. EP MQ RD | | | | | | | | | | --------------- GET /mq/0/... --------------> | | | | | | | | | <--------------- 2.05 Content --------------- | | | | | | | | Figure 6: Client EP GET from CoAP-MQ Broker 5.2. Server Role Endpoint Functions This section describes the transaction flows and interactions between CoAP-MQ endpoints and CoAP-MQ brokers where the endpoint supports the server role. An endpoint registering the "core.pubsub.server" attribute MUST support these functions and interactions. Koster, et al. Expires January 5, 2015 [Page 9] Internet-Draft Message Queueing in CoAP July 2014 5.2.1. CoAP-MQ broker SUBSCRIBES to Server Role EP The server mode endpoint requires the CoAP-MQ broker to act as a client and subscribe to a resource on the endpoint using GET + Observe. A CoAP-MQ broker MAY subscribe to topics registered by a server role endpoint at any time. A CoAP-MQ broker MUST subscribe to a topic registered by a server role endpoint upon receiving a subscription on the associated topic. A CoAP-MQ broker MUST forward state updates received from a publishing endpoint to all endpoints subscribed on the associated topic.Figure 7 shows the flow of a CoAP- MQ Broker subscribing to a server role endpoint. EP MQ RD | | | | | | | SUBSCRIBE | | | <------ GET /0/... Observe: Token:XX -------- | | | | | | PUBLISH | | | ---------- 2.05 Content Observe:10----------> | | | | | | PUBLISH | | | ---------- 2.05 Content Observe:12----------> | | | | | | PUBLISH | | | ---------- 2.05 Content Observe:15----------> | | | | | | | | Figure 7: Broker SUBSCRIBE to Server Role EP 5.2.2. CoAP-MQ Broker Publishes to Server Role Endpoint CoAP-MQ broker MUST update server mode endpoint using PUT when upon receiving updates published on the associated topics. Endpoint server MAY update actuator or resource upon receiving published state updates from the broker. Koster, et al. Expires January 5, 2015 [Page 10] Internet-Draft Message Queueing in CoAP July 2014 EP MQ RD | | | | | | | PUBLISH | | | <--------------- PUT /0/... ----------------- | | | | | | | | | ---------------- 2.04 Changed---------------> | | | | | | | | Figure 8: Broker PUBLISH to Server Role EP 5.2.3. CoAP-MQ Broker GET from Server Role Endpoint CoAP-MQ broker MAY issue GET without Observe as needed to obtain state update from the server role endpoint. EP MQ RD | | | | | | | | | | <---------------- GET /0/... ---------------- | | | | | | | | | ---------------- 2.05 Content --------------> | | | | | | | | Figure 9: Broker GET from Server Role Endpoint 6. Enabling Multiple Publishers 6.1. Creating a Topic After registration of the EP in the RD and discovering the CoAP-MQ function, a designated EP acting as publisher for a particular topic is responsible for creating such topic. To do so, it will have to register the new topic in the RD and create it on the MQ function by doing a first publication as shown in Figure 2. After the topic has been created in the CoAP-MQ broker, the broker will be responsible of hosting this resource and to queue messages published on it as explained in Section 5 Koster, et al. Expires January 5, 2015 [Page 11] Internet-Draft Message Queueing in CoAP July 2014 6.2. Publishing a Topic from Multiple Publishers After the topic has been registered in the RD and is created in the CoAP-MQ broker, any device with the right access permissions can publish on that topic by using the topic field. For example in the following diagram, both EP1 and EP2 update the same topic that EP3 has previously subscribed to. After the topic has been created in the CoAP-MQ Broker, the broker will be responsible of hosting this resource and to queue messages published on it as explained in Section 5 EP1 EP2 MQ | | PUBLISH | | -------------- PUT /mq/0/TOPIC1 ------------> | | | | | <--------------- 2.04 Changed---------------- | | | | | | PUBLISH | | | ------ PUT /mq/0/TOPIC1 ------------> | | | | | | <------- 2.04 Changed---------------- | | | | Figure 10: Multiple CoAP-MQ EPs PUBLISH to Broker 6.3. Subscribing to a topic with multiple publishers Subscription to this topic is the same as in Section 5, since it acts as any other resource. Following the previous example, if EP3 is subscribed to the shared topic, it should receive two updates from both EP1 and EP2. Koster, et al. Expires January 5, 2015 [Page 12] Internet-Draft Message Queueing in CoAP July 2014 EP3 MQ | SUBSCRIBE | | ------- GET /mq/0/TOPIC1 Observe -----------> | | | | PUBLISH | | <----------- 2.05 Content EP1 -------------- | | | | PUBLISH | | <----------- 2.05 Content EP2 -------------- | | | Figure 11: CoAP-MQ Endpoint SUBSCRIBE to Broker 7. Sleep-Wakeup Operation and Message Queueing A CoAP-MQ broker MAY implement support for sleeping endpoints and queueing of messages as provided for in [7] 8. Security Considerations CoAP-MQ re-uses CoAP [6], CoRE Resource Directory [4], and Web Linking [8] and therefore the security considerations of those documents also apply to this specification. Additionally, a CoAP-MQ broker and the endpoints SHOULD authenticate each other and enforce access control policies. A malicious EP could subscribe to data it is not authorized to or mount a denial of service attack against the broker by publishing a large number of resources. The authentication can be performed using the already standardized DTLS offered mechanisms, such as certificates. DTLS also allows communication security to be established to ensure integrity and confidentiality protection of the data exchanged between these relevant parties. Provisioning the necessary credentials, trust anchors and authorization policies is non-trivial and subject of ongoing work. The use of a CoAP-MQ broker introduces challenges for the use of end- to-end security between the end device and the cloud-based server infrastructure since brokers terminate the exchange. While running separate DTLS sessions from the EP to the broker and from broker to the web application protects confidentially on those paths, the client/server EP does not know whether the commands coming from the broker are actually coming from the client web application. Similarly, a client web application requesting data does not know whether the data originated on the server EP. For scenarios where end-to-end security is desirable the use of application layer security is unavoidable. Application layer security would then provide a guarantee to the client EP that any request originated at the client web application. Similarly, integrity protected sensor Koster, et al. Expires January 5, 2015 [Page 13] Internet-Draft Message Queueing in CoAP July 2014 data from a server EP will also provide guarantee to the client web application that the data originated on the EP itself. The protected data can also be verified by the intermediate broker ensuring that it stores/caches correct request/response and no malicious messages/ requests are accepted. The broker would still be able to perform aggregation of data/requests collected. Depending on the level of trust users and system designers place in the CoAP-MQ broker, the use of end-to-end encryption may also be envisioned. The CoAP-MQ broken would then only be able to verify the request/response message/commands and store-and-forward without being able to inspect the content. The solution for providing application layer security will depend on the utilized data encoding. For example, with a JSON-based data encoding the work from the JOSE working group could be re-used. Distribution of the credentials for accomplishing end-to-end security might introduce challenges if previously unknown parties need to exchange data. 9. IANA Considerations This document registers two attribute values in the Resource Type (rt=) registry established with RFC 6690 [2]. 9.1. Resource Type value 'core.pubsub.client' o Attribute Value: core.pubsub.client o Description: Section X of [[This document]] o Reference: [[This document]] o Notes: None 9.2. Resource Type value 'core.pubsub.server' o Attribute Value: core.pubsub.server o Description: Section Y of [[This document]] o Reference: [[This document]] o Notes: None 10. Acknowledgements Hannes Tschofenig, Zach Shelby Koster, et al. Expires January 5, 2015 [Page 14] Internet-Draft Message Queueing in CoAP July 2014 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012. [3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012. [4] Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Directory", draft-ietf-core-resource-directory-01 (work in progress), December 2013. [5] Hartke, K., "Observing Resources in CoAP", draft-ietf- core-observe-14 (work in progress), June 2014. [6] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [7] Open Mobile Alliance, "OMA LightweightM2M v1.0", http://technical.openmobilealliance.org/Technical/ technical-information/release-program/current-releases/ oma-lightweightm2m-v1-0, 12 2013. 11.2. Informative References [8] Nottingham, M., "Web Linking", RFC 5988, October 2010. Authors' Addresses Michael Koster ARM Limited Email: Michael.Koster@arm.com Ari Keranen Ericsson Email: ari.keranen@ericsson.com Koster, et al. Expires January 5, 2015 [Page 15] Internet-Draft Message Queueing in CoAP July 2014 Jaime Jimenez Ericsson Email: jaime.jimenez@ericsson.com Koster, et al. Expires January 5, 2015 [Page 16]