CoAP Multicast
draft-lucas-coap-multicast-00

Versions: 00                                                            
core                                                         R. Lucas
Internet Draft                             Cisco International Limited
Intended status: Standards Track                    September 13, 2017
Expires: March 17, 2018


                            CoAP Multicast
                  draft-lucas-coap-multicast-00.txt

Abstract

  Multicast is a preferred approach to send a single message to
  multiple recipients but it is typically lossy. CoAP is the choice of
  messaging for IoT. If using multicast to transmit CoAP messages
  there is a risk they get lost and a further risk that sequences of
  messages get disrupted and leave the system in an unknown or
  unpleasant state.

  In the device world we might want to guarantee that a whole sequence
  of commands arrives at the device. For example a sequence to Open,
  Report, Do some action, and Close. It is better that all of these
  messages arrive or all of them do not arrive rather than have some
  of them arrive and to not know which ones failed.

  CoAP messages tend to be small due to constrained resources on the
  recipient devices. Existing frame sizes though are relatively large
  so it is possible to pack these frames with several smaller CoAP
  messages and send them as a group.

  CoAP Multicast proposes the simplest way to do this. It is a device
  independent method and adds no need for encryption channels.


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 April 13th, 2018.



Lucas                     Expires March 17, 2018               [Page 1]


Internet-Draft             CoAP Multicast               September 2017

Copyright Notice

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

1. Introduction

  In the device world we might want to guarantee that a whole sequence
  of commands arrives at the device.

  For example a sequence to Open, Report, Do some action, and Close.
  It is better that all of these messages arrive or all of them do not
  arrive.

  Existing relatively large frame sizes allow smaller CoAP messages to
  be packed together in the same multicast. CoAP Multicast proposes
  the simplest way to pack the frames using a device independent
  method.

  There is no mention or burden added here of encryption or security.

  You can further decide of course to close the lossy reliability loop
  with a clever mechanism to ACK or complete/confirm a transaction but
  that is neither a function of multicast or a task for CoAP multicast
  which simply aims to provide an efficiency boost and a reliability
  boost in its own right by allowing groups of CoAP messages to be
  sent together.

2. Assumptions

  The multicast transport layer returns data frames with known
  lengths.

  The multicast transport layer is not restricted to a maximum data
  frame length OR the maximum data frame length is sufficient for the
  messages that we wish to send.

3. Summary

  Keeping it as simple as possible.

Lucas                  Expires March 17, 2018                 [Page 2]


Internet-Draft             CoAP Multicast               September 2017

  Each multicast frame contains one or more CoAP messages. Multicast
  communication is unreliable so allowing multiple CoAP messages in a
  single multicast frame allows for simple atomic delivery of a set of
  CoAP messages.

  The CoAP multicast frame contains a CBOR array of byte strings.

  Each byte string is a CoAP message.

>> Each CoAP message MUST be marked as non-Confirmable.

>> Each CoAP message SHOULD be idempotent (i.e. probably PUT only).

  The receiver should simply replay each message in turn. No responses
  should be generated because the messages MUST be marked as
  non-confirmable, but if any responses are generated then they should
  be discarded.

4. Conventions used in this document

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

  In this document, these words will appear with that interpretation
  only when in ALL CAPS. Lower case uses of these words are not to be
  interpreted as carrying significance described in RFC 2119.

  In this document, the characters ">>" preceding an indented line(s)
  indicates a statement using the key words listed above. This
  convention aids reviewers in quickly identifying or finding the
  portions of this RFC covered by these keywords.

5. Security Considerations

  None

6. IANA Considerations

  None

7. Conclusions

  None

8. References

8.1. Normative References

  [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
             Application Protocol (CoAP)", RFC 7252,
Lucas                  Expires March 17, 2018                 [Page 3]


Internet-Draft             CoAP Multicast               September 2017

             DOI 10.17487/RFC7252, June 2014,
             <http://www.rfc-editor.org/info/rfc7252>.

  [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
            Representation (CBOR), RFC 7049, DOI 10.17487/RFC7049,
            October 2013, <http://www.rfc-editor.org/info/rfc7049>

8.2. Informative References

  [RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication
            for the Constrained Application Protocol (CoAP)", RFC 390,
            DOI 10.17487/RFC7390, October 2014,
            <http://www.rfc-editor.org/info/rfc7390>.

  [I-D.dijk-core-groupcomm-misc]
            Dijk, E., and A. Rahman, "Miscellaneous CoAP Group
            Communication Topics",
            draft-dijk-core-groupcomm-misc, June 2014,
            https://datatracker.ietf.org/doc/
            draft-dijk-core-groupcomm-misc/
            https://www.ietf.org/archive/id/
            draft-dijk-core-groupcomm-misc-06.txt

9. Acknowledgments

  Parts of this document are a byproduct of the "aSSURE" project,
  partially funded by Innovate UK. It is provided "as is" and without
  any express or implied warranties, including, without limitation,
  the implied warranties of fitness for a particular purpose. The
  views and conclusion contained herein are those of the authors and
  should not be interpreted as necessarily representing the official
  policies or endorsements, either expressed or implied, of the aSSURE
  project or Innovate UK.

Author's Address
  Roger Lucas
  c/o Cisco International Limited
  10, New Square Park
  Bedfont Lakes
  Feltham
  TW14 8HA
  United Kingdom

  Email: iot@hiddenengine.co.uk







Lucas                  Expires March 17, 2018                 [Page 4]