CoAP Multicast
draft-lucas-coap-multicast-00

Document Type Active Internet-Draft (individual)
Last updated 2017-09-13
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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). 
Show full document text