[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                               Luyuan Fang
Intended Status: Standards Track                               Microsoft
Expires: September 22, 2016

                                                          March 21, 2016

       Failure Detection Extensions for Publish-Subscribe in CoAP
            draft-fang-core-coap-pubsub-failure-detection-00

Abstract

   This document defines extensions to the Constrained Application
   Protocol Publish/Subscribe function set, to make the protocol
   suitable to address the use case of failure detection in a hyper-
   scale system with millions of endpoints. Specifically, this document
   defines a Last Will mechanism and a scheme to guarantee hot fail-over
   of the pub/sub broker.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (c) 2016 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



Luyuan Fang           Expires <September 22, 2016>              [Page 1]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Pub/Sub Broker for CoAP . . . . . . . . . . . . . . . . . . . .  5
   3. Last Will and Testament . . . . . . . . . . . . . . . . . . . .  6
   4. Pub/Sub Broker Fail-Over  . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     7.2  Informative References  . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8































Luyuan Fang           Expires <September 22, 2016>              [Page 2]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


1. Introduction

   Many new protocols are being specified, and many existing ones are
   evolving, to meet the scalability, functionality, and footprint
   requirements of the Internet of Things (IoT), or Web of Things (WoT).

   These protocols include Constrained Application Protocol (CoAP)
   [RFC7252], the Message Queuing Telemetry Transport (MQTT) protocol
   [MQTT], the Advanced Message Queuing Protocol (AMQP) [AMQP], and the
   Streaming Text Oriented Messaging Protocol (STOMP) [STOMP], among
   others. The Extensible Messaging and Presence Protocol (XMPP)
   [RFC7622] and HTTP/2 [RFC7540] also provide many capabilities that
   make them very suitable to support IoT use cases.

   Although the proliferation of protocols for use in IoT is a clear
   indication that there is no single "silver bullet" protocol that can
   optimally address all the emerging IoT use cases, all these protocols
   are generally designed to provide connectivity to massive numbers of
   rather simple devices, typically resource constrained in terms of
   computing power, battery life, bandwidth, and reachability. As such,
   the design emphasis in these protocols is on scalability, small
   footprint, efficient use of available bandwidth, ease of parsing and
   processing, and client independency. To achieve these design
   objectives, these protocols have introduced several interesting and
   useful concepts to remove limitations in existing protocol and
   provide effective solutions to the new requirements.

   As these protocols continue to mature, extensions are specified to
   increase the scope of their use (and, arguably, perhaps have one
   protocol prevail over others in a sort of "war of protocols" that is
   ensuing). In these extensions, it is often the case that a protocol
   is augmented with some desired characteristics or concepts already
   demonstrated by other protocols. For example, MQTT for Sensor
   Networks (MQTT-SN) [MQTTSN] is a flavor of MQTT that substitutes TCP
   with UDP, to achieve better scalability and lower complexity in
   certain use cases. Directly relevant to this document, recent work in
   IETF [I-D.draft-koster-core-coap-pubsub] is meant to add the
   desirable Publish/Subscribe (pub/sub) message paradigm, which
   distinguishes MQTT, AMQP, and other protocols, to CoAP.

   Because of their desirable characteristics, the usefulness of these
   protocols is not necessarily confined to IoT use cases, but these
   protocol become strong candidates to address any use case where
   scalability, simplicity, and responsiveness are paramount. One of
   such use cases is fault detection in a hyper-scale network with
   millions or tens of millions of endpoints, such as a Data Center
   (DC). In a DC, many fault detection, diagnostics, and fault recovery
   mechanisms are typically deployed. However, as the scale and



Luyuan Fang           Expires <September 22, 2016>              [Page 3]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


   complexity of the DC increases, there is an emerging need to devise
   new light-weight, scalable, device-agnostic, massively distributable,
   reactive mechanisms to assist and complement existing ones.

   The simplicity, efficiency, and scalability of CoAP makes it a
   frontrunner as an interesting solution for the fault-detection use
   case. The addition of the pub/sub paradigm and the corresponding
   introduction of a pub/sub broker for CoAP
   [I-D.draft-koster-core-coap-pubsub] further provide a convenient,
   scalable architecture for fault detection, where the broker can
   rapidly detect the occurrence of faults in the connected clients
   (e.g., nodes in the DC) and propagate the information to interested
   listener in a timely fashion.

   CoAP with pub/sub mechanism is an important ingredient for solving
   the use case, but of course it is not the only one. This document
   further extends the CoAP pub/sub function set with two additional,
   useful mechanisms for this purpose, thus making CoAP an even stronger
   candidate as a lightweight protocol solution for fault detection.

   First, this document specifies a Last Will and Testament (LWT)
   mechanism to be added to the CoAP pub/sub function set. The LWT
   mechanism, which is used in other protocols such as MQTT, is
   explicitly designed to define the behavior of the broker in case of
   unexpected loss of connectivity with a client, as it is indeed the
   case when a fault occurs. The LWT mechanism is most effective when it
   is used in conjunction with some sort of Keep Alive mechanism, which
   should also be defined as part of the specification.

   A well-known shortcoming of the pub/sub paradigm is the fact that the
   broker becomes a single point of failure. Clearly, this problem is
   extremely relevant in the use case at hand, where the broker is a key
   component of the fault detection architecture. This document further
   defines extensions to support redundancy among brokers, and achieve
   hot fail-over in case of failure of the brokers themselves.

1.1. 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 RFC 2119 [RFC2119].

   This document uses terms and concepts that are discussed in
   [RFC5988], [RFC6690], [RFC7252] and
   [I-D.ietf-core-resource-directory]. The URI template format [RFC6570]
   is also used in this specification.

   This specification makes use of the following additional terminology,



Luyuan Fang           Expires <September 22, 2016>              [Page 4]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


   defined in [I-D.draft-koster-core-coap-pubsub]:

   o  Publish-Subscribe (pub/sub):  A messaging paradigm where a
      publisher publishes messages to a broker and interested receivers
      subscribe to the broker to receive messages.  The published
      messages are delivered by the broker to the subscribed receivers.

   o  CoAP pub/sub function set:  A group of REST resources that
      together provide the CoAP pub/sub service.

   o  CoAP pub/sub Broker:  A server node capable of receiving messages
      from publishers and sending messages to subscribed receivers.

   o  CoAP pub/sub Client:  A CoAP client that implements the CoAP
      pub/sub function set.

   o  Topic:  A unique identifier for a particular item being published
      and/or subscribed to.  The broker uses the topics to match
      subscriptions with publications.

   o  CoAP pub/sub Function Set: The interface between a CoAP pub/sub
      Broker and pub/sub Clients.

   In addition, this document uses the following terms.

   Term              Definition
   -----------       --------------------------------------------------
   AMQP              Advanced Message Queuing Protocol
   CoAP              Constrained Application Protocol
   CSP               Cloud Service Provider
   DC                Data Center
   IoT               Internet of Things
   LWT               Last Will and Testament
   MQTT              Message Queuing Telemetry Transport
   MQTT-SN           MQTT for Sensor Networks
   SDN               Software Defined Network
   STOMP             Constrained Application Protocol
   SVR               Server
   WoT               Web of Things
   XMPP              Extensible Messaging and Presence Protocol


2. Pub/Sub Broker for CoAP

   The Pub/Sub Broker architecture and pub/sub function set is defined
   in [I-D.draft-koster-core-coap-pubsub].

   The CoAP pub/sub Broker is a CoAP Server that exposes an interface



Luyuan Fang           Expires <September 22, 2016>              [Page 5]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


   for CoAP clients to perform publish/subscribe interactions. The
   Broker typically has resource to buffer messages that are published
   by the CoAP clients. The Broker matches a published resource/message
   with the interested listener using Topics. Listeners subscribe to
   specific topics to receive information published by specific clients.

   The CoAP pub/sub function set as defined in
   [I-D.draft-koster-core-coap-pubsub] provides the following
   operations.

   o  DISCOVER. Used by CoAP clients to discover CoAP pub/sub Brokers

   o  CREATE. Used by CoAP clients to create a topic.

   o  PUBLISH. Used by CoAP clients to update a specific topic on the
      broker (i.e., publish a message on a topic).

   o  SUBSCRIBE. Used by CoAP clients (listeners) to subscribe to
      topics.

   o  UNSUBSCRIBE. Used by CoAP clients (listeners) to unsubscribe to
      topics.

   o  READ. Used by a CoAP client (listener) to obtain the most recent
      published value on a topic. Useful when a client first joins or
      re-joins the pub/sub system.

   o  REMOVE. Used by a CoAP client to remove an existing topic.

3. Last Will and Testament

   The Last Will and Testament (LWT) mechanism is used to define the
   behavior of the broker in case of unexpected loss of connectivity
   with a client. This may be the result of an error detected by the
   broker, or may be triggered by the client failing to communicate with
   the broker within a Keep Alive.

   In order to implement the LWT mechanism, the CoAP pub/sub function
   set needs to be extended by adding:

   i.  a mechanism to create a WILL topic;

   ii.  a mechanism to specify a WILL message.

   The WILL message is the message that the broker MUST post on the WILL
   topic in case a failure of the corresponding CoAP client is detected.

   These two mechanisms are implemented by modifying the CREATE



Luyuan Fang           Expires <September 22, 2016>              [Page 6]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


   operation in the CoAP pub/sub function set.


4. Pub/Sub Broker Fail-Over

   TBD.

5.  Security Considerations

   TBD.

6.  IANA Considerations

   TBD.

7.  References

7.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570, DOI
              10.17487/RFC6570, March 2012, <http://www.rfc-
              editor.org/info/rfc6570>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <http://www.rfc-editor.org/info/rfc6690>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, DOI
              10.17487/RFC7252, June 2014, <http://www.rfc-
              editor.org/info/rfc7252>.

   [RFC7622]  P. Saint-Andre et al., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", RFC 6122, September
              2015, <https://tools.ietf.org/html/rfc7622>.

   [RFC7540]  M. Belshe et al., "Hypertext Transfer Protocol Version 2
              (HTTP/2)", RFC 7540, May 2015,
              <https://tools.ietf.org/html/rfc7540>.

7.2  Informative References

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, DOI
              10.17487/RFC5988, October 2010, <http://www.rfc-



Luyuan Fang           Expires <September 22, 2016>              [Page 7]


INTERNET DRAFT    Failure Detection Extensions in CoAP    March 21, 2016


              editor.org/info/rfc5988>.

   [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann,
              C., and P. Stok, "CoRE Resource Directory", draft-ietf-
              core-resource-directory-05 (work in progress), October
              2015.

   [I-D.draft-koster-core-coap-pubsub]  M. Koster et al., "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)",draft-koster-core-coap-pubsub-04 (work in
              progress), November 2015.

   [AMQP]    "OASIS Advanced Message Queuing Protocol (AMQP) Version
              1.0", OASIS Standard, October 2012, <http://docs.oasis-
              open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-
              os.html>.

   [MQTT]    "MQTT Version 3.1.1", OASIS Standard, October 2014,
              <http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-
              v3.1.1-os.html>.

   [MQTTSN]   "MQTT For Sensor Networks (MQTT-SN) Protocol Specification
              Version 1.2", November 2013, <http://mqtt.org/new/wp-
              content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf>.

   [STOMP]    "STOMP Protocol Specification, Version 1.2",
              <https://stomp.github.io/stomp-specification-1.2.html>.

Authors' Addresses

   Luyuan Fang
   Microsoft
   15590 NE 31st St
   Redmond, WA 98052
   Email: lufang@microsoft.com
















Luyuan Fang           Expires <September 22, 2016>              [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/