idnits 2.17.1 draft-fang-core-coap-pubsub-failure-detection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-05 == Outdated reference: A later version (-05) exists of draft-koster-core-coap-pubsub-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Luyuan Fang 3 Intended Status: Standards Track Microsoft 4 Expires: September 22, 2016 6 March 21, 2016 8 Failure Detection Extensions for Publish-Subscribe in CoAP 9 draft-fang-core-coap-pubsub-failure-detection-00 11 Abstract 13 This document defines extensions to the Constrained Application 14 Protocol Publish/Subscribe function set, to make the protocol 15 suitable to address the use case of failure detection in a hyper- 16 scale system with millions of endpoints. Specifically, this document 17 defines a Last Will mechanism and a scheme to guarantee hot fail-over 18 of the pub/sub broker. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Pub/Sub Broker for CoAP . . . . . . . . . . . . . . . . . . . . 5 61 3. Last Will and Testament . . . . . . . . . . . . . . . . . . . . 6 62 4. Pub/Sub Broker Fail-Over . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 67 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Many new protocols are being specified, and many existing ones are 73 evolving, to meet the scalability, functionality, and footprint 74 requirements of the Internet of Things (IoT), or Web of Things (WoT). 76 These protocols include Constrained Application Protocol (CoAP) 77 [RFC7252], the Message Queuing Telemetry Transport (MQTT) protocol 78 [MQTT], the Advanced Message Queuing Protocol (AMQP) [AMQP], and the 79 Streaming Text Oriented Messaging Protocol (STOMP) [STOMP], among 80 others. The Extensible Messaging and Presence Protocol (XMPP) 81 [RFC7622] and HTTP/2 [RFC7540] also provide many capabilities that 82 make them very suitable to support IoT use cases. 84 Although the proliferation of protocols for use in IoT is a clear 85 indication that there is no single "silver bullet" protocol that can 86 optimally address all the emerging IoT use cases, all these protocols 87 are generally designed to provide connectivity to massive numbers of 88 rather simple devices, typically resource constrained in terms of 89 computing power, battery life, bandwidth, and reachability. As such, 90 the design emphasis in these protocols is on scalability, small 91 footprint, efficient use of available bandwidth, ease of parsing and 92 processing, and client independency. To achieve these design 93 objectives, these protocols have introduced several interesting and 94 useful concepts to remove limitations in existing protocol and 95 provide effective solutions to the new requirements. 97 As these protocols continue to mature, extensions are specified to 98 increase the scope of their use (and, arguably, perhaps have one 99 protocol prevail over others in a sort of "war of protocols" that is 100 ensuing). In these extensions, it is often the case that a protocol 101 is augmented with some desired characteristics or concepts already 102 demonstrated by other protocols. For example, MQTT for Sensor 103 Networks (MQTT-SN) [MQTTSN] is a flavor of MQTT that substitutes TCP 104 with UDP, to achieve better scalability and lower complexity in 105 certain use cases. Directly relevant to this document, recent work in 106 IETF [I-D.draft-koster-core-coap-pubsub] is meant to add the 107 desirable Publish/Subscribe (pub/sub) message paradigm, which 108 distinguishes MQTT, AMQP, and other protocols, to CoAP. 110 Because of their desirable characteristics, the usefulness of these 111 protocols is not necessarily confined to IoT use cases, but these 112 protocol become strong candidates to address any use case where 113 scalability, simplicity, and responsiveness are paramount. One of 114 such use cases is fault detection in a hyper-scale network with 115 millions or tens of millions of endpoints, such as a Data Center 116 (DC). In a DC, many fault detection, diagnostics, and fault recovery 117 mechanisms are typically deployed. However, as the scale and 118 complexity of the DC increases, there is an emerging need to devise 119 new light-weight, scalable, device-agnostic, massively distributable, 120 reactive mechanisms to assist and complement existing ones. 122 The simplicity, efficiency, and scalability of CoAP makes it a 123 frontrunner as an interesting solution for the fault-detection use 124 case. The addition of the pub/sub paradigm and the corresponding 125 introduction of a pub/sub broker for CoAP 126 [I-D.draft-koster-core-coap-pubsub] further provide a convenient, 127 scalable architecture for fault detection, where the broker can 128 rapidly detect the occurrence of faults in the connected clients 129 (e.g., nodes in the DC) and propagate the information to interested 130 listener in a timely fashion. 132 CoAP with pub/sub mechanism is an important ingredient for solving 133 the use case, but of course it is not the only one. This document 134 further extends the CoAP pub/sub function set with two additional, 135 useful mechanisms for this purpose, thus making CoAP an even stronger 136 candidate as a lightweight protocol solution for fault detection. 138 First, this document specifies a Last Will and Testament (LWT) 139 mechanism to be added to the CoAP pub/sub function set. The LWT 140 mechanism, which is used in other protocols such as MQTT, is 141 explicitly designed to define the behavior of the broker in case of 142 unexpected loss of connectivity with a client, as it is indeed the 143 case when a fault occurs. The LWT mechanism is most effective when it 144 is used in conjunction with some sort of Keep Alive mechanism, which 145 should also be defined as part of the specification. 147 A well-known shortcoming of the pub/sub paradigm is the fact that the 148 broker becomes a single point of failure. Clearly, this problem is 149 extremely relevant in the use case at hand, where the broker is a key 150 component of the fault detection architecture. This document further 151 defines extensions to support redundancy among brokers, and achieve 152 hot fail-over in case of failure of the brokers themselves. 154 1.1. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 This document uses terms and concepts that are discussed in 161 [RFC5988], [RFC6690], [RFC7252] and 162 [I-D.ietf-core-resource-directory]. The URI template format [RFC6570] 163 is also used in this specification. 165 This specification makes use of the following additional terminology, 166 defined in [I-D.draft-koster-core-coap-pubsub]: 168 o Publish-Subscribe (pub/sub): A messaging paradigm where a 169 publisher publishes messages to a broker and interested receivers 170 subscribe to the broker to receive messages. The published 171 messages are delivered by the broker to the subscribed receivers. 173 o CoAP pub/sub function set: A group of REST resources that 174 together provide the CoAP pub/sub service. 176 o CoAP pub/sub Broker: A server node capable of receiving messages 177 from publishers and sending messages to subscribed receivers. 179 o CoAP pub/sub Client: A CoAP client that implements the CoAP 180 pub/sub function set. 182 o Topic: A unique identifier for a particular item being published 183 and/or subscribed to. The broker uses the topics to match 184 subscriptions with publications. 186 o CoAP pub/sub Function Set: The interface between a CoAP pub/sub 187 Broker and pub/sub Clients. 189 In addition, this document uses the following terms. 191 Term Definition 192 ----------- -------------------------------------------------- 193 AMQP Advanced Message Queuing Protocol 194 CoAP Constrained Application Protocol 195 CSP Cloud Service Provider 196 DC Data Center 197 IoT Internet of Things 198 LWT Last Will and Testament 199 MQTT Message Queuing Telemetry Transport 200 MQTT-SN MQTT for Sensor Networks 201 SDN Software Defined Network 202 STOMP Constrained Application Protocol 203 SVR Server 204 WoT Web of Things 205 XMPP Extensible Messaging and Presence Protocol 207 2. Pub/Sub Broker for CoAP 209 The Pub/Sub Broker architecture and pub/sub function set is defined 210 in [I-D.draft-koster-core-coap-pubsub]. 212 The CoAP pub/sub Broker is a CoAP Server that exposes an interface 213 for CoAP clients to perform publish/subscribe interactions. The 214 Broker typically has resource to buffer messages that are published 215 by the CoAP clients. The Broker matches a published resource/message 216 with the interested listener using Topics. Listeners subscribe to 217 specific topics to receive information published by specific clients. 219 The CoAP pub/sub function set as defined in 220 [I-D.draft-koster-core-coap-pubsub] provides the following 221 operations. 223 o DISCOVER. Used by CoAP clients to discover CoAP pub/sub Brokers 225 o CREATE. Used by CoAP clients to create a topic. 227 o PUBLISH. Used by CoAP clients to update a specific topic on the 228 broker (i.e., publish a message on a topic). 230 o SUBSCRIBE. Used by CoAP clients (listeners) to subscribe to 231 topics. 233 o UNSUBSCRIBE. Used by CoAP clients (listeners) to unsubscribe to 234 topics. 236 o READ. Used by a CoAP client (listener) to obtain the most recent 237 published value on a topic. Useful when a client first joins or 238 re-joins the pub/sub system. 240 o REMOVE. Used by a CoAP client to remove an existing topic. 242 3. Last Will and Testament 244 The Last Will and Testament (LWT) mechanism is used to define the 245 behavior of the broker in case of unexpected loss of connectivity 246 with a client. This may be the result of an error detected by the 247 broker, or may be triggered by the client failing to communicate with 248 the broker within a Keep Alive. 250 In order to implement the LWT mechanism, the CoAP pub/sub function 251 set needs to be extended by adding: 253 i. a mechanism to create a WILL topic; 255 ii. a mechanism to specify a WILL message. 257 The WILL message is the message that the broker MUST post on the WILL 258 topic in case a failure of the corresponding CoAP client is detected. 260 These two mechanisms are implemented by modifying the CREATE 261 operation in the CoAP pub/sub function set. 263 4. Pub/Sub Broker Fail-Over 265 TBD. 267 5. Security Considerations 269 TBD. 271 6. IANA Considerations 273 TBD. 275 7. References 277 7.1 Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 283 and D. Orchard, "URI Template", RFC 6570, DOI 284 10.17487/RFC6570, March 2012, . 287 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 288 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 289 . 291 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 292 Application Protocol (CoAP)", RFC 7252, DOI 293 10.17487/RFC7252, June 2014, . 296 [RFC7622] P. Saint-Andre et al., "Extensible Messaging and Presence 297 Protocol (XMPP): Address Format", RFC 6122, September 298 2015, . 300 [RFC7540] M. Belshe et al., "Hypertext Transfer Protocol Version 2 301 (HTTP/2)", RFC 7540, May 2015, 302 . 304 7.2 Informative References 306 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 307 10.17487/RFC5988, October 2010, . 310 [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, 311 C., and P. Stok, "CoRE Resource Directory", draft-ietf- 312 core-resource-directory-05 (work in progress), October 313 2015. 315 [I-D.draft-koster-core-coap-pubsub] M. Koster et al., "Publish- 316 Subscribe Broker for the Constrained Application Protocol 317 (CoAP)",draft-koster-core-coap-pubsub-04 (work in 318 progress), November 2015. 320 [AMQP] "OASIS Advanced Message Queuing Protocol (AMQP) Version 321 1.0", OASIS Standard, October 2012, . 325 [MQTT] "MQTT Version 3.1.1", OASIS Standard, October 2014, 326 . 329 [MQTTSN] "MQTT For Sensor Networks (MQTT-SN) Protocol Specification 330 Version 1.2", November 2013, . 333 [STOMP] "STOMP Protocol Specification, Version 1.2", 334 . 336 Authors' Addresses 338 Luyuan Fang 339 Microsoft 340 15590 NE 31st St 341 Redmond, WA 98052 342 Email: lufang@microsoft.com