draft-ietf-core-coap-pubsub-03.txt   draft-ietf-core-coap-pubsub-04.txt 
Network Working Group M. Koster Network Working Group M. Koster
Internet-Draft SmartThings Internet-Draft SmartThings
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: August 16, 2018 J. Jimenez Expires: September 6, 2018 J. Jimenez
Ericsson Ericsson
February 12, 2018 March 05, 2018
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-pubsub-03 draft-ietf-core-coap-pubsub-04
Abstract Abstract
The Constrained Application Protocol (CoAP), and related extensions The Constrained Application Protocol (CoAP), and related extensions
are intended to support machine-to-machine communication in systems are intended to support machine-to-machine communication in systems
where one or more nodes are resource constrained, in particular for where one or more nodes are resource constrained, in particular for
low power wireless sensor networks. This document defines a publish- low power wireless sensor networks. This document defines a publish-
subscribe broker for CoAP that extends the capabilities of CoAP for subscribe broker for CoAP that extends the capabilities of CoAP for
supporting nodes with long breaks in connectivity and/or up-time. supporting nodes with long breaks in connectivity and/or up-time.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. CoAP Pub/sub Operation with Resource Directory . . . . . . . 18 5. CoAP Pub/sub Operation with Resource Directory . . . . . . . 18
6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 19 6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 19
7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 19 7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 21 9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 21
9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 21 9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 21
9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 21 9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 21
9.4. Response Code value '4.29' . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] supports The Constrained Application Protocol (CoAP) [RFC7252] supports
machine-to-machine communication across networks of constrained machine-to-machine communication across networks of constrained
devices. CoAP uses a request/response model where clients make devices. CoAP uses a request/response model where clients make
requests to servers in order to request actions on resources. requests to servers in order to request actions on resources.
Depending on the situation the same device may act either as a server Depending on the situation the same device may act either as a server
or a client. or a client.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
Simple Discovery or through a Resource Directory MUST use the link Simple Discovery or through a Resource Directory MUST use the link
relation rt=core.ps. A broker MAY advertise its supported content relation rt=core.ps. A broker MAY advertise its supported content
formats and other attributes in the link to its pub/sub API. formats and other attributes in the link to its pub/sub API.
A CoAP pub/sub Broker MAY offer a topic discovery entry point to A CoAP pub/sub Broker MAY offer a topic discovery entry point to
enable Clients to find topics of interest, either by topic name or by enable Clients to find topics of interest, either by topic name or by
link attributes which may be registered when the topic is created. link attributes which may be registered when the topic is created.
Figure 4 shows an example of a client looking for a topic with a Figure 4 shows an example of a client looking for a topic with a
resource type (rt) of "temperature" using Discover. The client then resource type (rt) of "temperature" using Discover. The client then
receives the URI of the resource and its content-format. A pub/sub receives the URI of the resource and its content-format. A pub/sub
broker wishing to advertize topic discovery MUST use the relation broker wishing to advertise topic discovery MUST use the relation
rt=core.ps.discover in the link. rt=core.ps.discover in the link.
A CoAP pub/sub Broker MAY expose the Discover interface through the A CoAP pub/sub Broker MAY expose the Discover interface through the
.well-known/core resource. Links to topics may be exposed at .well- .well-known/core resource. Links to topics may be exposed at .well-
known/core in addition to links to the pub/sub API. Figure 5 shows known/core in addition to links to the pub/sub API. Figure 5 shows
an example of topic discovery through .well-known/core. an example of topic discovery through .well-known/core.
The DISCOVER interface is specified as follows: The DISCOVER interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
skipping to change at page 11, line 25 skipping to change at page 11, line 25
URI of the created topic, including all of the created path segments, URI of the created topic, including all of the created path segments,
returned via the Location-Path option. returned via the Location-Path option.
A Broker MAY accept PUBLISH operations using the POST method. If a A Broker MAY accept PUBLISH operations using the POST method. If a
broker accepts PUBLISH using POST it shall respond with the 2.04 broker accepts PUBLISH using POST it shall respond with the 2.04
Changed status code. Changed status code.
A Broker MAY perform garbage collection of stored representations A Broker MAY perform garbage collection of stored representations
which have been delivered to all subscribers or which have timed out. which have been delivered to all subscribers or which have timed out.
A Broker MAY retain at least one most recently published A Broker MAY retain at least one most recently published
representation to return in response to SUBSRCIBE and READ requests. representation to return in response to SUBSCRIBE and READ requests.
A Broker MUST make a best-effort attempt to notify all clients A Broker MUST make a best-effort attempt to notify all clients
subscribed on a particular topic each time it receives a publish on subscribed on a particular topic each time it receives a publish on
that topic. An example is shown in Figure 10. If a client publishes that topic. An example is shown in Figure 10. If a client publishes
to a broker with the Max-Age option, the broker MUST include the same to a broker with the Max-Age option, the broker MUST include the same
value for the Max-Age option in all notifications. A broker MUST use value for the Max-Age option in all notifications. A broker MUST use
CoAP Notification as described in [RFC7641] to notify subscribed CoAP Notification as described in [RFC7641] to notify subscribed
clients. clients.
The PUBLISH interface is specified as follows: The PUBLISH interface is specified as follows:
skipping to change at page 17, line 33 skipping to change at page 17, line 33
| | Read | | | Read |
| | --------------- GET /ps/topic1 -------------> | | | --------------- GET /ps/topic1 -------------> |
| | | | | |
| | <----------- 2.05 Content "1033.3" ---------- | | | <----------- 2.05 Content "1033.3" ---------- |
| | | | | |
Figure 12: Example of READ Figure 12: Example of READ
4.7. REMOVE 4.7. REMOVE
A CoAP pub/sub broker MAY allow clientsremove a topics from the A CoAP pub/sub broker MAY allow clients to remove topics from the
broker using the CoAP Delete method on the URI of the topic. The broker using the CoAP Delete method on the URI of the topic. The
CoAP pub/sub Broker MUST return "2.02 Deleted" if the removal is CoAP pub/sub Broker MUST return "2.02 Deleted" if the removal is
successful. The broker MUST return the appropriate 4.xx response successful. The broker MUST return the appropriate 4.xx response
code indicating the reason for failure if the topic can not be code indicating the reason for failure if the topic can not be
removed. When a topic is removed for any reason, the Broker SHOULD removed. When a topic is removed for any reason, the Broker SHOULD
return the response code 4.04 Not Found and remove all of the return the response code 4.04 Not Found and remove all of the
observers from the list of observers as per as per [RFC7641] observers from the list of observers as per as per [RFC7641]
Section 3.2. If a topic which has sub-topics is removed, then all of Section 3.2. If a topic which has sub-topics is removed, then all of
its sub-topics MUST be recursively removed. its sub-topics MUST be recursively removed.
skipping to change at page 19, line 44 skipping to change at page 19, line 44
7. Simple Flow Control 7. Simple Flow Control
Since the broker node has to potentially send a large amount of Since the broker node has to potentially send a large amount of
notification messages for each publish message and it may be serving notification messages for each publish message and it may be serving
a large amount of subscribers and publishers simultaneously, the a large amount of subscribers and publishers simultaneously, the
broker may become overwhelmed if it receives many publish messages to broker may become overwhelmed if it receives many publish messages to
popular topics in a short period of time. popular topics in a short period of time.
If the broker is unable to serve a certain client that is sending If the broker is unable to serve a certain client that is sending
publish messages too fast, the broker MUST respond with Response Code publish messages too fast, the broker SHOULD respond with Response
4.29, "Too Many Requests". This Response Code is like HTTP 429 "Too Code 4.29, "Too Many Requests" [I-D.keranen-core-too-many-reqs] and
Many Requests" but uses the Max-Age Option in place of the "Retry- set the Max-Age Option to indicate the number of seconds after which
After" header field to indicate the number of seconds after which to the client can retry. The broker MAY stop creating notifications
retry. The broker MAY stop creating notifications from the publish from the publish messages from this client and to this topic for the
messages from this client and to this topic for the indicated time. indicated time.
If a client receives the 4.29 Response Code from the broker for a If a client receives the 4.29 Response Code from the broker for a
publish message to a topic, it MUST NOT send new publish messages to publish message to a topic, it MUST NOT send new publish messages to
the broker on the same topic before the time indicated in Max-Age has the broker on the same topic before the time indicated in Max-Age has
passed. passed.
8. Security Considerations 8. Security Considerations
CoAP pub/sub re-uses CoAP [RFC7252], CoRE Resource Directory CoAP pub/sub re-uses CoAP [RFC7252], CoRE Resource Directory
[I-D.ietf-core-resource-directory], and Web Linking [RFC5988] and [I-D.ietf-core-resource-directory], and Web Linking [RFC5988] and
skipping to change at page 21, line 37 skipping to change at page 21, line 37
o Description: Section 4 of [[This document]] o Description: Section 4 of [[This document]]
o Reference: [[This document]] o Reference: [[This document]]
o Notes: None o Notes: None
9.3. Response Code value '2.07' 9.3. Response Code value '2.07'
o Response Code: 2.07 o Response Code: 2.07
o Description: Add No Content response to GET to the existing o Description: No Content
definition of the 2.07 response code.
o Reference: [[This document]] o Reference: [[This document]]
o Notes: The server sends this code to the client to indicate that o Notes: The server sends this code to the client to indicate that
the request was valid and accepted, but the responce may contain the request was valid and accepted, but the response may contain
an empty payload. It is comparable to and may be proxied with the an empty payload. It is comparable to and may be proxied with the
http 204 No Content status code. HTTP 204 No Content status code.
9.4. Response Code value '4.29'
o Response Code: 4.29
o Description: This error code is used by a server to indicate that
a client is making too many requests on a resource.
o Reference: [[This document]]
o Notes: None
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit
Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran
Selander, Mikko Majanen, and Olaf Bergmann for their contributions Selander, Mikko Majanen, and Olaf Bergmann for their contributions
and reviews. and reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.keranen-core-too-many-reqs]
Keranen, A., "Too Many Requests Response Code for the
Constrained Application Protocol", draft-keranen-core-too-
many-reqs-00 (work in progress), March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- RFC2119, March 1997, <https://www.rfc-editor.org/info/
editor.org/info/rfc2119>. rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/
DOI 10.17487/RFC6570, March 2012, <https://www.rfc- RFC6570, March 2012, <https://www.rfc-editor.org/info/
editor.org/info/rfc6570>. rfc6570>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- RFC7252, June 2014, <https://www.rfc-editor.org/info/
editor.org/info/rfc7252>. rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641, DOI 10.17487/
DOI 10.17487/RFC7641, September 2015, <https://www.rfc- RFC7641, September 2015, <https://www.rfc-editor.org/info/
editor.org/info/rfc7641>. rfc7641>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-09 (work in
progress), March 2018.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-12 (work in progress), October 2017. resource-directory-13 (work in progress), March 2018.
[I-D.palombini-ace-coap-pubsub-profile] [I-D.palombini-ace-coap-pubsub-profile]
Palombini, F., "CoAP Pub-Sub Profile for Authentication Palombini, F., "CoAP Pub-Sub Profile for Authentication
and Authorization for Constrained Environments (ACE)", and Authorization for Constrained Environments (ACE)",
draft-palombini-ace-coap-pubsub-profile-01 (work in draft-palombini-ace-coap-pubsub-profile-02 (work in
progress), September 2017. progress), March 2018.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-06 (work in progress), October 2016.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
DOI 10.17487/RFC5988, October 2010, <https://www.rfc- RFC5988, October 2010, <https://www.rfc-editor.org/info/
editor.org/info/rfc5988>. rfc5988>.
Authors' Addresses Authors' Addresses
Michael Koster Michael Koster
SmartThings SmartThings
Email: Michael.Koster@smartthings.com Email: Michael.Koster@smartthings.com
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 23 change blocks. 
55 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/