< draft-ietf-core-groupcomm-17.txt   draft-ietf-core-groupcomm-18.txt >
CoRE Working Group A. Rahman, Ed. CoRE Working Group A. Rahman, Ed.
Internet-Draft InterDigital Communications, LLC Internet-Draft InterDigital Communications, LLC
Intended status: Informational E. Dijk, Ed. Intended status: Informational E. Dijk, Ed.
Expires: June 1, 2014 Philips Research Expires: June 26, 2014 Philips Research
November 28, 2013 December 23, 2013
Group Communication for CoAP Group Communication for CoAP
draft-ietf-core-groupcomm-17 draft-ietf-core-groupcomm-18
Abstract Abstract
CoAP is a specialized web transfer protocol for constrained devices CoAP is a specialized web transfer protocol for constrained devices
and constrained networks. It is anticipated that constrained devices and constrained networks. It is anticipated that constrained devices
will often naturally operate in groups (e.g., in a building will often naturally operate in groups (e.g., in a building
automation scenario all lights in a given room may need to be automation scenario all lights in a given room may need to be
switched on/off as a group). This document provides guidance for how switched on/off as a group). This document provides guidance for how
the CoAP protocol should be used in a group communication context. the CoAP protocol should be used in a group communication context.
An approach for using CoAP on top of IP multicast is detailed. Also, An approach for using CoAP on top of IP multicast is detailed. Also,
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 1, 2014. This Internet-Draft will expire on June 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5 2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5 2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5
2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6 2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6
2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7 2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7
2.4. Group REST Methods . . . . . . . . . . . . . . . . . . . 8 2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 8
2.5. Messaging and Responses . . . . . . . . . . . . . . . . . 8 2.5. Request and Response Model . . . . . . . . . . . . . . . 8
2.6. Group Member Discovery . . . . . . . . . . . . . . . . . 9 2.6. Member Discovery . . . . . . . . . . . . . . . . . . . . 9
2.7. Configuring Group Memberships in Endpoints . . . . . . . 9 2.7. Membership Configuration . . . . . . . . . . . . . . . . 9
2.7.1. Background . . . . . . . . . . . . . . . . . . . . . 9 2.7.1. Background . . . . . . . . . . . . . . . . . . . . . 9
2.7.2. RESTful Interface . . . . . . . . . . . . . . . . . . 9 2.7.2. Membership Configuration RESTful Interface . . . . . 10
2.8. Multicast Request Acceptance and Response Suppression . . 14 2.8. Request Acceptance and Response Suppression Rules . . . . 15
2.9. Congestion Control . . . . . . . . . . . . . . . . . . . 16 2.9. Congestion Control . . . . . . . . . . . . . . . . . . . 17
2.10. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 17 2.10. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 18
2.11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 18 2.11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 19
3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 18 3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 19
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Network Configuration . . . . . . . . . . . . . . . . . . 19 3.2. Network Configuration . . . . . . . . . . . . . . . . . . 20
3.3. Discovery of Resource Directory . . . . . . . . . . . . . 21 3.3. Discovery of Resource Directory . . . . . . . . . . . . . 22
3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 22 3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 23
3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 25 3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 27
3.6. Commissioning the Network Based On Resource Directory . . 26 3.6. Commissioning the Network Based On Resource Directory . . 28
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 27 4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 29
4.1. Target Network Topologies . . . . . . . . . . . . . . . . 27 4.1. Target Network Topologies . . . . . . . . . . . . . . . . 29
4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 27 4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 30
4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 28 4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 30
4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 28 4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 31
4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 30 4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
5.1. Security Configuration . . . . . . . . . . . . . . . . . 30 5.1. Security Configuration . . . . . . . . . . . . . . . . . 32
5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 31 5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 33
5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 31 5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 33
5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 31 5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 33
5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 31 5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 32 6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 34
6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 32 6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 34
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 36 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 38
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
1.1. Background 1.1. Background
Constrained Application Protocol (CoAP) is a Representational State Constrained Application Protocol (CoAP) is a Representational State
Transfer (REST) based web transfer protocol for resource constrained Transfer (REST) based web transfer protocol for resource constrained
devices operating in an IP network [I-D.ietf-core-coap]. CoAP has devices operating in an IP network [I-D.ietf-core-coap]. CoAP has
many similarities to HTTP [RFC2616] but also has some key many similarities to HTTP [RFC2616] but also has some key
differences. Constrained devices can be large in numbers, but are differences. Constrained devices can be large in numbers, but are
often related to each other in function or location. For example, often related to each other in function or by location. For example,
all the light switches in a building may belong to one group and all all the light switches in a building may belong to one group and all
the thermostats may belong to another group. Groups may be pre- the thermostats may belong to another group. Groups may be pre-
configured before deployment or dynamically formed during operation. configured before deployment or dynamically formed during operation.
If information needs to be sent to or received from a group of If information needs to be sent to or received from a group of
devices, group communication mechanisms can improve efficiency and devices, group communication mechanisms can improve efficiency and
latency of communication and reduce bandwidth requirements for a latency of communication and reduce bandwidth requirements for a
given application. HTTP does not support any equivalent given application. HTTP does not support any equivalent
functionality to CoAP group communication. functionality to CoAP group communication.
1.2. Scope 1.2. Scope
Group communication involves a one-to-many relationship between CoAP Group communication involves a one-to-many relationship between CoAP
endpoints. Specifically, a single CoAP client will simultaneously endpoints. Specifically, a single CoAP client can simultaneously get
get (or set) resource representations from multiple CoAP servers (or set) resources from multiple CoAP servers using CoAP over IP
using CoAP over IP multicast. An example would be a CoAP light multicast. An example would be a CoAP light switch turning on/off
switch turning on/off multiple lights in a room with a single CoAP multiple lights in a room with a single CoAP group communication PUT
group communication PUT request, and handling the potential multitude request, and handling the potential multitude of (unicast) responses.
of (unicast) responses.
The normative protocol aspects of running CoAP on top of IP Multicast The normative protocol aspects of sending CoAP requests on top of IP
and processing the responses are given in [I-D.ietf-core-coap]. The multicast, and processing the (unicast IP) responses are given in
main contribution of this document lies in providing additional Section 8 of [I-D.ietf-core-coap]. The main contribution of this
guidance for several important group communication features. Among document lies in providing additional guidance for key CoAP group
the topics covered are group definition, group resource manipulation, communication concepts. Among the topics covered are group
and group configuration. Also, proxy operation and minimizing definition, group RESTful methods, and group request and response
network congestion for group communication is discussed. Finally, processing (see Section 2). Also, proxy operation and minimizing
specific use cases and deployment guidelines for CoAP group network congestion for group communication is discussed (see
communication are outlined. Section 2). Finally, specific use cases (see Section 3) and
deployment guidelines (see Section 4) for group communication are
outlined.
1.3. Conventions and Terminology 1.3. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The above key words are used to establish a set of guidelines for The above key words are used to establish a set of guidelines for
CoAP group communication. An implementation of CoAP group CoAP group communication. An implementation of CoAP group
communication MAY implement these guidelines; an implementation communication MAY implement these guidelines; an implementation
claiming compliance to this document MUST implement the set of claiming compliance to this document MUST implement the set of
guidelines. guidelines.
This document assumes readers are familiar with the terms and This document assumes readers are familiar with the terms and
concepts that are used in [I-D.ietf-core-coap]. In addition, this concepts that are used in [I-D.ietf-core-coap]. In addition, this
document defines the following terminology: document defines the following terminology:
Group Communication Group Communication
A source node sends a single message which is delivered to A source node sends a single application layer (e.g. CoAP) message
multiple destination nodes, where all destinations are identified which is delivered to multiple destination nodes, where all
to belong to a specific group. The source node itself may be part destinations are identified to belong to a specific group. The
of the group. The underlying mechanism for group communication is source node itself may be part of the group. The underlying
assumed to be multicast based. The network involved may be a mechanisms for CoAP group communication are UDP/IP multicast for
constrained network such as a low-power, lossy network. the requests, and unicast UDP/IP for the responses. The network
involved may be a constrained network such as a low-power, lossy
network.
Reliable Group Communication Reliable Group Communication
Group Communication where for each destination node it is A special case of group communication where for each destination
guaranteed that the node either 1) eventually receives the message node it is guaranteed that the node either 1) eventually receives
sent by the source node, or 2) does not receive the message and the message sent by the source node, or 2) does not receive the
the source node is notified of the non-reception event. message and the source node is notified of the non-reception
event.
Multicast Multicast
Sending a message to multiple destination nodes with one network Sending a message to multiple destination nodes with one network
invocation. There are various options to implement multicast invocation. There are various options to implement multicast
including layer 2 (Media Access Control) and layer 3 (IP) including layer 2 (Media Access Control) and layer 3 (IP)
mechanisms. mechanisms.
IP Multicast IP Multicast
A specific multicast solution based on the use of IP multicast A specific multicast approach based on the use of IP multicast
addresses as defined in "IANA Guidelines for IPv4 Multicast addresses as defined in "IANA Guidelines for IPv4 Multicast
Address Assignments" [RFC5771] and "IP Version 6 Addressing Address Assignments" [RFC5771] and "IP Version 6 Addressing
Architecture" [RFC4291]. Architecture" [RFC4291]. A complete IP multicast solution may
include support for managing group memberships, and IP multicast
routing/forwarding (see Section 2.1).
Low power and Lossy Network (LLN) Low power and Lossy Network (LLN)
A type of constrained IP network where devices are interconnected A type of constrained IP network where devices are interconnected
by low-power and lossy links. The links may be may composed of by low-power and lossy links. The links may be may composed of
one or more technologies such as IEEE 802.15.4, Bluetooth Low one or more technologies such as IEEE 802.15.4, Bluetooth Low
Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT),
and IEEE P1901.2 power-line communication. and IEEE P1901.2 power-line communication.
2. Protocol Considerations 2. Protocol Considerations
2.1. IP Multicast Background 2.1. IP Multicast Background
IP Multicast protocols have been evolving for decades, resulting in IP multicast protocols have been evolving for decades, resulting in
standards such as Protocol Independent Multicast - Sparse Mode (PIM- standards such as Protocol Independent Multicast - Sparse Mode (PIM-
SM) [RFC4601]. IP Multicast is very popular in specific deployments SM) [RFC4601]. IP multicast is very popular in specific deployments
such as in enterprise networks (e.g., for video conferencing), smart such as in enterprise networks (e.g., for video conferencing), smart
home networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV home networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV
deployments. The packet economy and minimal host complexity of IP deployments. The packet economy and minimal host complexity of IP
multicast make it attractive for group communication in constrained multicast make it attractive for group communication in constrained
environments. environments.
To achieve IP multicast beyond link-local scope, an IP multicast To achieve IP multicast beyond link-local scope, an IP multicast
routing or forwarding protocol needs to be active on IP routers. An routing or forwarding protocol needs to be active on IP routers. An
example of a routing protocol specifically for LLNs is the IPv6 example of a routing protocol specifically for LLNs is the IPv6
Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12
skipping to change at page 6, line 7 skipping to change at page 6, line 9
IP multicast is generally classified as an unreliable service in that IP multicast is generally classified as an unreliable service in that
packets are not guaranteed to be delivered to each and every member packets are not guaranteed to be delivered to each and every member
of the group. In other words, it cannot be directly used as a basis of the group. In other words, it cannot be directly used as a basis
for "reliable group communication" as defined in Section 1.3. for "reliable group communication" as defined in Section 1.3.
However, the level of reliability can be increased by employing a However, the level of reliability can be increased by employing a
multicast protocol that performs periodic retransmissions as is done multicast protocol that performs periodic retransmissions as is done
for example in MPL. for example in MPL.
2.2. Group Definition and Naming 2.2. Group Definition and Naming
A group is defined as a set of CoAP endpoints, where each endpoint is A CoAP group is defined as a set of CoAP endpoints, where each
configured to receive multicast CoAP requests that are sent to the endpoint is configured to receive CoAP group communication requests
group's associated IP multicast address. An endpoint MAY be a member that are sent to the group's associated IP multicast address. The
of multiple groups. Group membership of an endpoint MAY dynamically individual response by each endpoint receiver to a CoAP group
change over time. communication request is always sent back as unicast. An endpoint
may be a member of multiple groups. Group membership of an endpoint
may dynamically change over time.
Any CoAP server node SHOULD join the "All CoAP Nodes" multicast group All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast
([I-D.ietf-core-coap], Section 12.8) by default to enable discovery group ([I-D.ietf-core-coap], Section 12.8) by default to enable CoAP
via CoAP multicast. For IPv4, the address is 224.0.1.187 and for discovery. For IPv4, the address is 224.0.1.187 and for IPv6 a
IPv6 a server node joins at least both the link-local scoped address server node joins at least both the link-local scoped address
FF02::FD and the site-local scoped address FF05::FD. IPv6 addresses FF02::FD and the site-local scoped address FF05::FD. IPv6 addresses
of other scopes may also be enabled. of other scopes MAY be enabled.
A Group URI has the scheme 'coap' and includes in the authority part A CoAP group URI has the scheme 'coap' and includes in the authority
either a group IP multicast address or a hostname (e.g., Group Fully part either a group IP multicast address, or a hostname (e.g., Group
Qualified Domain Name (FQDN)) that can be resolved to the group IP Fully Qualified Domain Name (FQDN)) that can be resolved to the group
multicast address. A Group URI also contains an optional CoAP port IP multicast address. A group URI also contains an optional CoAP
number in the authority part. Group URIs follow the CoAP URI syntax port number in the authority part. Group URIs follow the regular
[I-D.ietf-core-coap]. CoAP URI syntax [I-D.ietf-core-coap].
Note: A Group URI is needed to initiate CoAP group communications. Note: A group URI is needed to initiate CoAP group communications.
If a CoAP implementation accepts a CoAP URI as input in the group For CoAP implementations it is recommended to use the URI composition
communications request API, then the parsing method of Section 6.4 of method of Section 6.5 of [I-D.ietf-core-coap] in such way that a CoAP
[I-D.ietf-core-coap] should be used in such way that a CoAP multicast group communication request is generated.
request is generated.
It is recommended, for sending nodes, to use the IP multicast address For sending nodes, it is recommended to use the IP multicast address
literal in a Group URI. In case a Group hostname is used, it can be literal in a group URI. However, in case a group hostname is used,
uniquely mapped to an IP multicast address via DNS resolution (if it can be uniquely mapped to an IP multicast address via DNS
supported). Some examples of hierarchical Group FQDN naming (and resolution (if supported). Some examples of hierarchical group FQDN
scoping) for a building control application are shown below: naming (and scoping) for a building control application are shown
below:
URI authority Targeted group of nodes URI authority Targeted group of nodes
--------------------------------------- -------------------------- --------------------------------------- --------------------------
all.bldg6.example.com "all nodes in building 6" all.bldg6.example.com "all nodes in building 6"
all.west.bldg6.example.com "all nodes in west wing, all.west.bldg6.example.com "all nodes in west wing,
building 6" building 6"
all.floor1.west.bldg6.example.com "all nodes in floor 1, all.floor1.west.bldg6.example.com "all nodes in floor 1,
west wing, building 6" west wing, building 6"
all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036, all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036,
floor1, west wing, floor1, west wing,
building 6" building 6"
Similarly, if supported, reverse mapping (from IP multicast address Similarly, if supported, reverse mapping (from IP multicast address
to Group FQDN) is possible using the reverse DNS resolution technique to Group FQDN) is possible using the reverse DNS resolution technique
([RFC1033]). ([RFC1033]). Reverse mapping is important, for example, in trouble
shooting to translate IP multicast addresses back to human readable
hostnames to show in a diagnostics user interface.
2.3. Port and URI Configuration 2.3. Port and URI Configuration
A CoAP server that is a member of a group listens for CoAP messages A CoAP server that is a member of a group listens for CoAP messages
on the group's IP multicast address, on a specified UDP port. The on the group's IP multicast address, on a specified UDP port. The
default UDP port is the CoAP default port 5683 but a non-default UDP default UDP port is the CoAP default port 5683 but a non-default UDP
port MAY be specified for the group; in which case implementers MUST port MAY be specified for the group; in which case implementers MUST
ensure that all group members are configured to use this same port. ensure that all group members are configured to use this same port.
Multicast based group communication will not work if there is CoAP group communication will not work if there is diversity in the
diversity in the authority port (e.g., different dynamic port authority port (e.g., different dynamic port addresses across the
addresses across the group) or if other parts of the URI such as the group) or if other parts of the group URI such as the path, or the
path, or the query, differ on different endpoints. Therefore, some query, differ on different endpoints. Therefore, some measures must
measures must be present to ensure uniformity in port number and be present to ensure uniformity in port number and resource names/
resource names/locations within a group. All CoAP multicast requests locations within a group. All CoAP group communication requests MUST
MUST be sent using a port number according to one of below options: be sent using a port number according to one of below options:
1. A pre-configured port number. The pre-configuration mechanism 1. A pre-configured port number. The pre-configuration mechanism
MUST ensure that the same port number is pre-configured across MUST ensure that the same port number is pre-configured across
all endpoints in a group and across all CoAP clients performing all endpoints in a group and across all CoAP clients performing
the group requests. the group requests.
2. If the client is configured to use service discovery including 2. If the client is configured to use service discovery including
port discovery, it uses a port number obtained via a service port discovery, it uses a port number obtained via a service
discovery lookup operation for the targeted CoAP multicast group. discovery lookup operation for the targeted CoAP group.
3. Use the default CoAP UDP port (5683). 3. Use the default CoAP UDP port (5683).
For a CoAP server node that supports multicast resource discovery, For a CoAP server node that supports resource discovery, the default
the default port 5683 MUST be supported (Section 7.1 of port 5683 MUST be supported (Section 7.1 of [I-D.ietf-core-coap]) for
[I-D.ietf-core-coap]) for the "All CoAP Nodes" group. the "All CoAP Nodes" group.
All CoAP multicast requests SHOULD operate on URI paths in one of the All CoAP group communication requests SHOULD operate on group URI
following ways: paths in one of the following ways:
1. Pre-configured URI paths, if available. The pre-configuration 1. Pre-configured group URI paths, if available. The pre-
mechanism SHOULD ensure that these paths are pre-configured configuration mechanism SHOULD ensure that these paths are pre-
across all CoAP servers in a group and all CoAP clients configured across all CoAP servers in a group and all CoAP
performing the group requests. Note that clients performing the group requests. Note that
[I-D.ietf-appsawg-uri-get-off-my-lawn] prescribes that any [I-D.ietf-appsawg-uri-get-off-my-lawn] prescribes that any
specification must not constrain, define structure or semantics specification must not constrain, define structure or semantics
for any path component. for any path component.
2. If the client is configured to use default CoRE resource 2. If the client is configured to use default CoRE resource
discovery, it uses URI paths retrieved from a "/.well-known/core" discovery, it uses URI paths retrieved from a "/.well-known/core"
lookup on a group member. The URI paths the client will use MUST lookup on a group member. The URI paths the client will use MUST
be known to be available also in all other endpoints in the be known to be available also in all other endpoints in the
group. The URI path configuration mechanism on servers MUST group. The URI path configuration mechanism on servers MUST
ensure that these URIs (identified as being supported by the ensure that these URIs (identified as being supported by the
group) are configured on all group endpoints. group) are configured on all group endpoints.
3. If the client is configured to use another form of service 3. If the client is configured to use another form of service
discovery, it uses URI paths from an equivalent service discovery discovery, it uses group URI paths from an equivalent service
lookup which returns the resources supported by all group discovery lookup which returns the resources supported by all
members. group members.
4. If the client has received a Group URI through a previous RESTful 4. If the client has received a group URI through a previous RESTful
interaction with a trusted server, for the purpose of the client interaction with a trusted server it can use this URI in a CoAP
using this URI in a request, it can use this URI in a multicast group communication request. For example, a commissioning tool
request. For example, a commissioning tool may instruct a sensor may instruct a sensor device in this way to which target group
device in this way to which target (multicast URI) it should (group URI) it should report sensor events.
report sensor events.
2.4. Group REST Methods 2.4. RESTful Methods
Idempotent methods (i.e., CoAP GET, PUT, and DELETE) SHOULD be used Idempotent CoAP RESTful methods (i.e., GET, PUT, and DELETE) SHOULD
for group communication, with one exception as follows. A non- be used for group communication, with one exception as follows. A
idempotent method (i.e., CoAP POST) MAY be used for group non-idempotent CoAP method (i.e., POST) MAY be used for group
communication if the resource being POSTed to has been designed to communication if the resource being POSTed to has been designed to
cope with the lossy nature of multicast. Note that not all group cope with the unreliable and lossy nature of IP multicast. Note that
members are guaranteed to receive the multicast request, and the not all group members are guaranteed to receive the IP multicast
sender cannot readily find out which group members did not receive request, and the sender cannot readily find out which group members
it. did not receive it.
2.5. Messaging and Responses 2.5. Request and Response Model
All CoAP messages that are sent via multicast MUST be Non- All CoAP requests that are sent via IP multicast MUST be Non-
confirmable. The Message ID in a multicast CoAP message is used for confirmable. The Message ID in an IP multicast CoAP message is used
optional message deduplication as detailed in Section 4.5 of for optional message deduplication as detailed in Section 4.5 of
[I-D.ietf-core-coap]. [I-D.ietf-core-coap].
A server MAY send back a unicast response to the group communication A server MAY send back a unicast response to the CoAP group
request (e.g., response "2.05 Content" to a group GET request) taking communication request (e.g., response "2.05 Content" to a group GET
into account the congestion control rules defined in Section 2.9. request). The unicast responses received by the CoAP client may be a
The unicast responses received by the CoAP client may be a mixture of mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found) codes Found) codes depending on the individual server processing results.
depending on the individual server processing results (see section 8 Detailed processing rules for IP multicast request acceptance and
of [I-D.ietf-core-coap]). unicast response suppression are given in Section 2.8.
A CoAP request sent over IP multicast and any unicast response must
take into account the congestion control rules defined in
Section 2.9.
The CoAP client can distinguish the origin of multiple server The CoAP client can distinguish the origin of multiple server
responses by source IP address of the UDP message containing the CoAP responses by source IP address of the UDP message containing the CoAP
response. In case a CoAP client sent multiple group requests, the response, or any other available unique identifier (e.g. contained in
responses are as usual matched to a request using the CoAP Token. the CoAP payload). In case a CoAP client sent multiple group
requests, the responses are as usual matched to a request using the
CoAP Token.
2.6. Group Member Discovery 2.6. Member Discovery
CoAP Groups, and the membership of these groups, can be discovered CoAP Groups, and the membership of these groups, can be discovered
via the lookup interfaces defined in via the lookup interfaces in the Resource Directory (RD) defined in
[I-D.ietf-core-resource-directory]. An example of doing some of [I-D.ietf-core-resource-directory]. An example of doing some of
these lookups is given in Section 3.6. these RD lookups is given in Section 3.6.
2.7. Configuring Group Memberships in Endpoints 2.7. Membership Configuration
2.7.1. Background 2.7.1. Background
The group membership of a CoAP endpoint may be configured in one of The group membership of a CoAP endpoint may be configured in one of
the following ways. First, the group membership may be pre- the following ways. First, the group membership may be pre-
configured before node deployment. Second, a node may be programmed configured before node deployment. Second, a node may be programmed
to discover (query) its group membership using a specific service to discover (query) its group membership using a specific service
discovery means. Third, it may be configured by another node (e.g., discovery means. Third, it may be configured by another node (e.g.,
a commissioning device). a commissioning device).
In the first case, the pre-configured group information may be either In the first case, the pre-configured group information may be either
an IP multicast address or a hostname (FQDN) which is resolved later an IP multicast address or a hostname (FQDN) which is resolved later
(during operation) to a IP multicast address by the endpoint using (during operation) to an IP multicast address by the endpoint using
DNS (if supported). DNS (if supported).
For the second case, a CoAP endpoint may look up its group membership For the second case, a CoAP endpoint may look up its group membership
using techniques such as DNS-SD and Resource Directory using techniques such as DNS-SD and Resource Directory
[I-D.ietf-core-resource-directory]. The latter case is detailed more [I-D.ietf-core-resource-directory]. The latter case is detailed more
in Section 3.6. in Section 3.6.
In the third case, typical in scenarios such as building control, a In the third case, typical in scenarios such as building control, a
dynamic commissioning tool determines to which group a sensor or dynamic commissioning tool determines to which group a sensor or
actuator node belongs, and writes this information to the node, which actuator node belongs, and writes this information to the node, which
can subsequently join the correct IP multicast group on its network can subsequently join the correct IP multicast group on its network
interface. The information written may again be an IP multicast interface. The information written may again be an IP multicast
address or a hostname. address or a hostname.
2.7.2. RESTful Interface 2.7.2. Membership Configuration RESTful Interface
To achieve better interoperability between endpoints from different To achieve better interoperability between endpoints from different
manufacturers, an OPTIONAL RESTful CoAP interface for configuring manufacturers, an OPTIONAL CoAP membership configuration RESTful
endpoints with relevant group information is described here. This interface for configuring endpoints with relevant group information
interface provides a solution for the third case mentioned above. To is described here. This interface provides a solution for the third
access this interface a client MUST use unicast CoAP methods (GET/PUT case mentioned above. To access this interface a client MUST use
/POST/DELETE) only as it is a method of configuring group information unicast CoAP methods (GET/PUT/POST/DELETE) only as it is a method of
in individual endpoints. configuring group information in individual endpoints.
Also, the (unicast) methods to configure group membership SHOULD use Also, a form of authorization (making use of DTLS-secured CoAP
DTLS-secured CoAP [I-D.ietf-core-coap]. Thus only authorized [I-D.ietf-core-coap]) SHOULD be used such that only authorized
controllers should be allowed by an endpoint to configure its group controllers are allowed by an endpoint to configure its group
membership. membership.
It is important to note that other approaches may be used to It is important to note that other approaches may be used to
configure CoAP endpoints with relevant group information. These configure CoAP endpoints with relevant group information. These
alternate approaches may support a subset or superset of the RESTful alternate approaches may support a subset or superset of the
CoAP interface described in this document. For example, a simple membership configuration RESTful interface described in this
interface to just read the endpoint group information may be document. For example, a simple interface to just read the endpoint
implemented via a classical Management Information Base (MIB) group information may be implemented via a classical Management
approach (e.g. following approach of [RFC3433]). Information Base (MIB) approach (e.g. following approach of
[RFC3433]).
2.7.2.1. CoAP-Group Resource Type and Media Type 2.7.2.1. CoAP-Group Resource Type and Media Type
CoAP endpoints implementing the RESTful interface MUST support the CoAP endpoints implementing the membership configuration RESTful
CoAP group configuration Internet Media Type "application/coap- interface MUST support the CoAP group configuration Internet Media
group+json" (Section 6.2). Type "application/coap-group+json" (Section 6.2).
A resource offering this representation can be annotated for direct A resource offering this representation can be annotated for direct
discovery [RFC6690] using the resource type (rt) "core.gp" where "gp" discovery [RFC6690] using the resource type (rt) "core.gp" where "gp"
is shorthand for "group" (Section 6.1). An authorized client uses is shorthand for "group" (Section 6.1). An authorized client uses
this media type to query/manage group membership of a CoAP endpoint this media type to query/manage group membership of a CoAP endpoint
as defined in the following subsections. as defined in the following subsections.
The group configuration resource and its sub-resources have a JSON- The group configuration resource and its sub-resources have a JSON-
based content format (as indicated by the "application/coap- based content format (as indicated by the "application/coap-
group+json" media type). The resource includes zero or more group group+json" media type). The resource includes zero or more group
membership JSON objects in a format as defined in Section 2.7.2.5. A membership JSON objects in a format as defined in Section 2.7.2.4. A
group membership JSON object contains one or more key/value pairs as group membership JSON object contains one or more key/value pairs as
defined below. It represents a single IP multicast group membership defined below. It represents a single IP multicast group membership
for the CoAP endpoint. for the CoAP endpoint.
Examples of four different group membership objects are: Examples of four different group membership objects are:
{ "n": "All-Devices.floor1.west.bldg6.example.com", { "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" } "a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
{ "n": "sensors.floor2.east.bldg6.example.com" } { "n": "sensors.floor2.east.bldg6.example.com" }
skipping to change at page 11, line 9 skipping to change at page 11, line 27
{ "a": "[ff15::c0a7:15:c00l]" } { "a": "[ff15::c0a7:15:c00l]" }
The OPTIONAL "n" key/value pair stands for "name" and identifies the The OPTIONAL "n" key/value pair stands for "name" and identifies the
group with a hostname, for example a FQDN. The OPTIONAL "a" key/ group with a hostname, for example a FQDN. The OPTIONAL "a" key/
value pair specifies the IP multicast address (and optionally the value pair specifies the IP multicast address (and optionally the
port number) of the group. It contains an IPv4 address (in dotted port number) of the group. It contains an IPv4 address (in dotted
decimal notation) or an IPv6 address. The following ABNF rule can be decimal notation) or an IPv6 address. The following ABNF rule can be
used for parsing the address, referring to the definitions in used for parsing the address, referring to the definitions in
Section 6 of [I-D.ietf-core-coap] and [RFC3986]. Section 6 of [I-D.ietf-core-coap] and [RFC3986].
group-address = IPv4address [ ":" port ] group-address = IPv4address [ ":" port ]
/ "[" IPv6address "]" [":" port ] / "[" IPv6address "]" [":" port ]
If the port number is not provided then it is assumed to be the If the port number is not provided then it is assumed to be the
default CoAP port (5683). In a response, the "a" key/value pair MUST default CoAP port (5683). In a response, the "a" key/value pair
be included if the IP address is known at the time of generating the SHOULD be included if the IP address is known at the time of
response, and SHOULD NOT be included if unknown. If the "a" value is generating the response, and MUST NOT be included if unknown. If the
not provided in a request, the "n" value in the same group membership "a" value is not provided in a request, the "n" value in the same
object SHOULD be a valid hostname that can be translated to an IP group membership object SHOULD be a valid hostname with optional port
multicast address via DNS resolution. At least one of the "n"/"a" number that can be translated to an IP multicast address via DNS
pairs MUST be given per group object. resolution, as follows:
group-name = host [ ":" port ]
If the port number is not provided then it is assumed to be the
default CoAP port (5683). At least one of the "n"/"a" pairs MUST be
given per group object.
After any change on a Group configuration resource, the endpoint MUST After any change on a Group configuration resource, the endpoint MUST
effect registration/de-registration from the corresponding IP effect registration/de-registration from the corresponding IP
multicast group(s) as soon as possible. multicast group(s) as soon as possible.
2.7.2.2. Creating a new multicast group membership (POST) 2.7.2.2. Creating a new multicast group membership (POST)
Method: POST Method: POST
URI Template: /{+gp} URI Template: /{+gp}
Location-URI Template: /{+gp}/{index} Location-URI Template: /{+gp}/{index}
URI Template Variables: URI Template Variables:
gp - Group Configuration Function Set path (mandatory). gp - Group Configuration Function Set path (mandatory).
index - Group index, SHOULD be a string of 1 or 2 alphanumerical index - Group index, SHOULD be a string of 1 or 2 alphanumerical
characters. characters. It MUST be generated as locally unique.
Example: Example:
Req: POST /coap-group Req: POST /coap-group
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
{ "n": "All-Devices.floor1.west.bldg6.example.com", { "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" } "a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
Res: 2.01 Created Res: 2.01 Created
Location-Path: /coap-group/12 Location-Path: /coap-group/12
For the 'gp' variable we recommend use of the path "coap-group" by For the 'gp' variable it is recommended to use the path "coap-group"
default. If the "a" key/value pair is given, this takes priority and by default. If the "a" key/value pair is given, this takes priority
the "n" pair becomes informational. If only the "n" pair is given, and the "n" pair becomes informational. If only the "n" pair is
the CoAP endpoint may perform DNS resolution (if supported) to obtain given, the CoAP endpoint may perform DNS resolution (if supported) to
the IP multicast address from the hostname. obtain the IP multicast address from the hostname.
After any change on a Group configuration resource, the endpoint MUST After any change on a Group configuration resource, the endpoint MUST
effect registration/de-registration from the corresponding IP effect registration/de-registration from the corresponding IP
multicast group(s) as soon as possible. When a POST payload contains multicast group(s) as soon as possible. When a POST payload contains
in "a" a multicast address to which the endpoint is already in "a" an IP multicast address to which the endpoint is already
subscribed, the endpoint MUST re-register to that multicast address. subscribed, no change to that subscription is needed.
2.7.2.3. Deleting a group membership (DELETE)
Method: DELETE
URI Template: /{+location}
URI Template Variables:
location - The Location-Path returned by the CoAP server as a result
of a successful group creation.
Example:
Req: DELETE /coap-group/12
Res: 2.02 Deleted
2.7.2.4. Reading a group membership (GET) 2.7.2.3. Deleting a single group membership (DELETE)
Method: GET Method: DELETE
URI Template 1: /{+location} URI Template: {+location}
URI Template 2: /{+gp}/{index} URI Template Variables:
URI Template Variables: location - The Location-Path returned by the CoAP server as a result
location, gp, index - see earlier definitions of a successful group creation.
Example: Example:
Req: GET /coap-group/12 Req: DELETE /coap-group/12
Res: 2.05 Content Res: 2.02 Deleted
Content-Format: application/coap-group+json
{"n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567"}
2.7.2.5. Reading all group memberships (GET) 2.7.2.4. Reading all group memberships at once (GET)
A (unicast) GET on the CoAP-group resource returns a JSON object A (unicast) GET on the CoAP-group resource returns a JSON object
containing multiple keys and values, the keys being group indices and containing multiple keys and values, the keys being group indices and
the values the corresponding group objects. Each group object is a the values the corresponding group objects. Each group object is a
group membership JSON object that indicates one multicast group group membership JSON object that indicates one IP multicast group
membership. So, the group index is used as a JSON key to point to membership. So, the group index is used as a JSON key to point to
the group membership object, as shown below. the group membership object, as shown below.
Method: GET Method: GET
URI Template: /{+gp} URI Template: /{+gp}
URI Template Variables: URI Template Variables:
gp - see earlier definition gp - see earlier definition
Example: Example:
Req: GET /coap-group Req: GET /coap-group
skipping to change at page 13, line 4 skipping to change at page 13, line 16
Method: GET Method: GET
URI Template: /{+gp} URI Template: /{+gp}
URI Template Variables: URI Template Variables:
gp - see earlier definition gp - see earlier definition
Example: Example:
Req: GET /coap-group Req: GET /coap-group
Res: 2.05 Content Res: 2.05 Content
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
{ "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" }, { "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" },
"11":{ "n": "sensors.floor1.west.bldg6.example.com", "11":{ "n": "sensors.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:25cb]" }, "a": "[ff15::4200:f7fe:ed37:25cb]" },
"12":{ "n": "All-Devices.floor1.west.bldg6.example.com", "12":{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" } "a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
} }
Note: the returned IPv6 address may be a different string from the Note: the returned IPv6 address may be a different string from the
one originally submitted in group membership creation, due to one originally submitted in group membership creation, due to
different choices in IPv6 string representation formatting that may different choices in IPv6 string representation formatting that may
be allowed for the same address. be allowed for the same address (see [RFC5952]).
2.7.2.6. Updating a group memberships (PUT) 2.7.2.5. Reading a single group membership (GET)
Method: PUT Method: GET
URI Template 1: /{+location} URI Template 1: {+location}
URI Template 2: /{+gp}/{index} URI Template 2: /{+gp}/{index}
URI Template Variables: URI Template Variables:
location, gp, index - see earlier definitions location, gp, index - see earlier definitions
Example: (group name and multicast port change) Example:
Req: PUT /coap-group/12 Req: GET /coap-group/12
Res: 2.05 Content
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
{"n": "All-My-Devices.floor1.west.bldg6.example.com", {"n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]"} "a": "[ff15::4200:f7fe:ed37:abcd]:4567"}
Res: 2.04 Changed
2.7.2.7. Creating/updating all group memberships at once (PUT) 2.7.2.6. Creating/updating all group memberships at once (PUT)
A (unicast) PUT with a group configuration media type as payload will A (unicast) PUT with a group configuration media type as payload will
replace all current group memberships in the endpoint with the new replace all current group memberships in the endpoint with the new
ones defined in the PUT request. This operation SHOULD only be used ones defined in the PUT request. This operation SHOULD only be used
to delete or update group membership objects for which the CoAP to delete or update group membership objects for which the CoAP
client, invoking this operation, is responsible. client, invoking this operation, is responsible. The responsibility
is based on application level knowledge. For example, a
commissioning tool will be responsible for any group membership
objects that it created.
Method: PUT
URI Template: /{+gp}
URI Template Variables:
gp - see earlier definition
Example: (replacing all existing group memberships with two new groups)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{ "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" },
"2":{ "a": "[ff15::4200:f7fe:ed37:5678]" }
}
Res: 2.04 Changed
Example: (clearing all group memberships at once)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{}
Res: 2.04 Changed
After a successful PUT on the Group configuration resource, the
endpoint MUST effect registration to any new IP multicast group(s)
and de-registration from any previous IP multicast group(s), i.e. not
anymore present in the new memberships, as soon as possible. Also it
MUST take into account the group indices present in the new resource
during the generation of any new unique group indices in the future.
2.7.2.7. Updating a single group membership (PUT)
A (unicast) PUT with a group membership JSON object will replace an
existing group membership in the endpoint with the new one defined in
the PUT request. This can be used to update the group membership.
Method: PUT Method: PUT
URI Template: /{+gp} URI Template 1: {+location}
URI Template 2: /{+gp}/{index}
URI Template Variables: URI Template Variables:
gp - see earlier definition location, gp, index - see earlier definitions
Example: (replacing all existing group memberships with two new groups) Example: (group name and IP multicast port change)
Req: PUT /coap-group Req: PUT /coap-group/12
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
{ "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" }, {"n": "All-My-Devices.floor1.west.bldg6.example.com",
"2":{ "a": "[ff15::4200:f7fe:ed37:5678]" } "a": "[ff15::4200:f7fe:ed37:abcd]"}
}
Res: 2.04 Changed Res: 2.04 Changed
Example: (clearing all group memberships at once) After a successful PUT on the Group configuration resource, the
Req: PUT /coap-group endpoint MUST effect registration to any new IP multicast group(s)
Content-Format: application/coap-group+json and de-registration from any previous IP multicast group(s), i.e. not
{} anymore present in the new membership, as soon as possible.
Res: 2.04 Changed
2.8. Multicast Request Acceptance and Response Suppression 2.8. Request Acceptance and Response Suppression Rules
CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define
normative behaviors for: normative behaviors for:
1. Multicast request acceptance - in which cases a CoAP request is 1. IP multicast request acceptance - in which cases a CoAP request
accepted and executed, and when not. is accepted and executed, and when not.
2. Multicast response suppression - in which cases the CoAP response 2. IP multicast response suppression - in which cases the CoAP
to an already-executed request is returned to the requesting response to an already-executed request is returned to the
endpoint, and when not. requesting endpoint, and when not.
A CoAP response differs from a CoAP ACK; ACKs are never sent by A CoAP response differs from a CoAP ACK; ACKs are never sent by
servers in response to a multicast CoAP request. This section first servers in response to an IP multicast CoAP request. This section
summarizes these normative behaviors and then presents additional first summarizes these normative behaviors and then presents
guidelines for response suppression. Also a number of multicast additional guidelines for response suppression. Also a number of IP
example applications are given to illustrate the overall approach. multicast example applications are given to illustrate the overall
approach.
To apply any rules for request and/or response suppression, a CoAP To apply any rules for request and/or response suppression, a CoAP
server must be aware that an incoming request arrived via multicast server must be aware that an incoming request arrived via IP
by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542].
For multicast request acceptance, the REQUIRED behaviors are: For IP multicast request acceptance, the REQUIRED behaviors are:
o A server SHOULD NOT accept a multicast request that cannot be o A server SHOULD NOT accept an IP multicast request that cannot be
"authenticated" in some way (cryptographically or by some "authenticated" in some way (cryptographically or by some
multicast boundary limiting the potential sources) multicast boundary limiting the potential sources)
[I-D.ietf-core-coap]. See Section 5.3 for examples of multicast [I-D.ietf-core-coap]. See Section 5.3 for examples of multicast
boundary limiting methods. boundary limiting methods.
o A server SHOULD NOT accept a multicast discovery request with a o A server SHOULD NOT accept an IP multicast discovery request with
query string (as defined in CoRE Link Format [RFC6690]) if a query string (as defined in CoRE Link Format [RFC6690]) if
filtering ([RFC6690]) is not supported by the server. filtering ([RFC6690]) is not supported by the server.
o A server SHOULD NOT accept a multicast request that acts on a o A server SHOULD NOT accept an IP multicast request that acts on a
specific resource for which multicast support is not required. specific resource for which IP multicast support is not required.
(Note that for the resource "/.well-known/core", multicast support (Note that for the resource "/.well-known/core", IP multicast
is required if "multicast resource discovery" is supported as support is required if "multicast resource discovery" is supported
specified in section 1.2.1 of [RFC6690]). Implementers are as specified in section 1.2.1 of [RFC6690]). Implementers are
advised to disable multicast support by default on any other advised to disable IP multicast support by default on any other
resource, until explicitly enabled by an application or by resource, until explicitly enabled by an application or by
configuration.) configuration.)
o Otherwise accept the multicast request. o Otherwise accept the IP multicast request.
For multicast response suppression, the REQUIRED behaviors are: For IP multicast response suppression, the REQUIRED behaviors are:
o A server SHOULD NOT respond to a multicast discovery request if o A server SHOULD NOT respond to an IP multicast discovery request
the filter specified by the request's query string does not match. if the filter specified by the request's query string does not
match.
o A server MAY choose not to respond to a multicast request, if o A server MAY choose not to respond to an IP multicast request, if
there's nothing useful to respond (e.g., error or empty response). there's nothing useful to respond (e.g., error or empty response).
o Otherwise respond to the multicast request. o Otherwise respond to the IP multicast request.
The above response suppression behaviors are complemented by the The above response suppression behaviors are complemented by the
following guidelines. CoAP servers SHOULD implement configurable following guidelines. CoAP servers SHOULD implement configurable
response suppression, enabling at least the following options per response suppression, enabling at least the following options per
resource that supports multicast requests: resource that supports IP multicast requests:
o Suppression of all 2.xx success responses; o Suppression of all 2.xx success responses;
o Suppression of all 4.xx client errors; o Suppression of all 4.xx client errors;
o Suppression of all 5.xx server errors; o Suppression of all 5.xx server errors;
o Suppression of all 2.05 responses with empty payload. o Suppression of all 2.05 responses with empty payload.
A number of group communication example applications are given below A number of CoAP group communication example applications are given
to illustrate how to make use of response suppression: below to illustrate how to make use of response suppression:
o CoAP resource discovery: Suppress 2.05 responses with empty o CoAP resource discovery: Suppress 2.05 responses with empty
payload and all 4.xx and 5.xx errors. payload and all 4.xx and 5.xx errors.
o Lighting control: Suppress all 2.xx responses after a lighting o Lighting control: Suppress all 2.xx responses after a lighting
change command. change command.
o Update configuration data in a group of devices using multicast o Update configuration data in a group of devices using group
PUT: No suppression at all. The client uses collected responses communication PUT: No suppression at all. The client uses
to identify which group members did not receive the new collected responses to identify which group members did not
configuration; then attempts using CoAP CON unicast to update receive the new configuration; then attempts using CoAP CON
those specific group members. Note that in this case the client unicast to update those specific group members. Note that in this
implements a Reliable CoAP Group Communication function using case the client implements a "reliable group communication" (as
additional, non-standardized functions above the CoAP layer. defined in Section 1.3) function using additional, non-
standardized functions above the CoAP layer.
o Multicast firmware update by sending blocks of data: Suppress all o IP multicast firmware update by sending blocks of data: Suppress
2.xx and 5.xx responses. After having sent all multicast blocks, all 2.xx and 5.xx responses. After having sent all IP multicast
the client checks each endpoint by unicast to identify which data blocks, the client checks each endpoint by unicast to identify
blocks are still missing in each endpoint. which data blocks are still missing in each endpoint.
o Conditional reporting for a group (e.g., sensors) based on a URI o Conditional reporting for a group (e.g., sensors) based on a group
query: Suppress all 2.05 responses with empty payload (i.e., if a URI query: Suppress all 2.05 responses with empty payload (i.e.,
query produces no matching results). if a query produces no matching results).
2.9. Congestion Control 2.9. Congestion Control
Multicast CoAP requests may result in a multitude of responses from CoAP group communication requests may result in a multitude of
different nodes, potentially causing congestion. Therefore both the responses from different nodes, potentially causing congestion.
sending of multicast requests, and the sending of the unicast CoAP Therefore both the sending of IP multicast requests, and the sending
responses to these multicast requests should be conservatively of the unicast CoAP responses to these multicast requests should be
controlled. conservatively controlled.
CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks CoAP [I-D.ietf-core-coap] reduces IP multicast-specific congestion
through the following measures: risks through the following measures:
o A server MAY choose not to respond to a multicast request if o A server MAY choose not to respond to an IP multicast request if
there's nothing useful to respond (e.g., error or empty response). there's nothing useful to respond (e.g., error or empty response).
See Section 2.8 for more detailed guidelines on response See Section 2.8 for more detailed guidelines on response
suppression. suppression.
o A server SHOULD limit the support for multicast requests to o A server SHOULD limit the support for IP multicast requests to
specific resources where multicast operation is required. specific resources where multicast operation is required.
o A multicast request MUST be Non-confirmable. o An IP multicast request MUST be Non-confirmable.
o A response to a multicast request SHOULD be Non-confirmable o A response to an IP multicast request SHOULD be Non-confirmable
(Section 5.2.3 of [I-D.ietf-core-coap]). (Section 5.2.3 of [I-D.ietf-core-coap]).
o A server does not respond immediately to a multicast request, but o A server does not respond immediately to an IP multicast request,
SHOULD first wait for a time that is randomly picked within a but SHOULD first wait for a time that is randomly picked within a
predetermined time interval called the Leisure. predetermined time interval called the Leisure.
Additional guidelines to reduce congestion risks defined in this Additional guidelines to reduce congestion risks defined in this
document are: document are:
o A server in an LLN should only support multicast GET for resources o A server in an LLN should only support group communication GET for
that are small. For example, the payload of the response is resources that are small. For example, the payload of the
limited to 5% of the IP Maximum Transmit Unit (MTU) size so it response is limited to approximately 5% of the IP Maximum Transmit
fits into a single link-layer frame in case 6LoWPAN [RFC4944] is Unit (MTU) size so it fits into a single link-layer frame in case
used. 6LoWPAN [RFC4944] is used.
o A server can minimize the payload length in response to a o A server can minimize the payload length in response to a group
multicast GET on "/.well-known/core" by using hierarchy in communication GET on "/.well-known/core" by using hierarchy in
arranging link descriptions for the response. An example of this arranging link descriptions for the response. An example of this
is given in Section 5 of [RFC6690]. is given in Section 5 of [RFC6690].
o A server can also minimize the payload length of a response to a o A server can also minimize the payload length of a response to a
multicast GET (e.g., on "/.well-known/core") using CoAP blockwise group communication GET (e.g., on "/.well-known/core") using CoAP
transfers [I-D.ietf-core-block], returning only a first block of blockwise transfers [I-D.ietf-core-block], returning only a first
the CoRE Link Format description. For this reason, a CoAP client block of the CoRE Link Format description. For this reason, a
sending a multicast CoAP request to "/.well-known/core" SHOULD CoAP client sending an IP multicast CoAP request to "/.well-known/
support core-block. core" SHOULD support core-block.
o A client should use CoAP multicast with the smallest possible o A client should use CoAP group communication with the smallest
multicast scope that fulfills the application needs. As an possible IP multicast scope that fulfills the application needs.
example, site-local scope is always preferred over global scope IP As an example, site-local scope is always preferred over global
multicast if this fulfills the application needs. scope IP multicast if this fulfills the application needs.
More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944]
are given in Section 4.5. are given in Section 4.5.
2.10. Proxy Operation 2.10. Proxy Operation
CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy
to process its CoAP request. For this purpose the client either to process its CoAP request. For this purpose the client either
specifies the request URI as a string in the Proxy-URI option, or it specifies the request group URI as a string in the Proxy-URI option,
specifies the Proxy-Scheme option with the URI constructed from the or it specifies the Proxy-Scheme option with the group URI
usual Uri-* options. This approach works well for unicast requests. constructed from the usual Uri-* options. This approach works well
However, there are certain issues and limitations of processing the for unicast requests. However, there are certain issues and
(unicast) responses to a group communication request made in this limitations of processing the (unicast) responses to a CoAP group
manner through a proxy. communication request made in this manner through a proxy.
A proxy may buffer all the individual (unicast) responses to a group A proxy may buffer all the individual (unicast) responses to a CoAP
communication request and then send back only a single (aggregated) group communication request and then send back only a single
response to the client. However there are some issues with this (aggregated) response to the client. However there are some issues
aggregation approach: with this aggregation approach:
o Aggregation of (unicast) responses to a group communication o Aggregation of (unicast) responses to a CoAP group communication
request in a proxy is difficult. This is because the proxy does request in a proxy is difficult. This is because the proxy does
not know how many members there are in the group, or how many not know how many members there are in the group, or how many
group members will actually respond. Also the proxy does not know group members will actually respond. Also the proxy does not know
how long to wait before deciding to send back the aggregated how long to wait before deciding to send back the aggregated
response to the client. response to the client.
o There is no default format defined in CoAP for aggregation of o There is no default format defined in CoAP for aggregation of
multiple responses into a single response. multiple responses into a single response.
Alternatively, if a proxy follows directly the specification for a Alternatively, if a proxy follows directly the specification for a
CoAP Proxy [I-D.ietf-core-coap], the proxy would simply forward all CoAP Proxy [I-D.ietf-core-coap], the proxy would simply forward all
the individual (unicast) responses to a group communication request the individual (unicast) responses to a CoAP group communication
to the client (i.e., no aggregation). There are also issues with request to the client (i.e., no aggregation). There are also issues
this approach: with this approach:
o The client may be confused as it may not have known that the o The client may be confused as it may not have known that the
Proxy-URI contained a multicast target. That is, the client may Proxy-URI contained a group URI target. That is, the client may
be expecting only one (unicast) response but instead receives be expecting only one (unicast) response but instead receives
multiple (unicast) responses potentially leading to fault multiple (unicast) responses potentially leading to fault
conditions in the application. conditions in the application.
o Each individual CoAP response will appear to originate (IP Source o Each individual CoAP response will appear to originate (IP Source
address) from the CoAP Proxy, and not from the server that address) from the CoAP Proxy, and not from the server that
produced the response. This makes it impossible for the client to produced the response. This makes it impossible for the client to
identify the server that produced each response. identify the server that produced each response.
Due to above issues, a guideline is defined here that a CoAP Proxy Due to above issues, a guideline is defined here that a CoAP Proxy
SHOULD NOT support processing a multicast CoAP request but rather SHOULD NOT support processing an IP multicast CoAP request but rather
return a 501 (Not Implemented) response in such case. The exception return a 501 (Not Implemented) response in such case. The exception
case here (i.e., to process it) is allowed under following case here (i.e., to process it) is allowed under following
conditions: conditions:
o The CoAP Proxy MUST be explicitly configured (whitelist) to allow o The CoAP Proxy MUST be explicitly configured (whitelist) to allow
proxied multicast requests by specific client(s). proxied IP multicast requests by specific client(s).
o The proxy SHOULD return individual (unicast) CoAP responses to the o The proxy SHOULD return individual (unicast) CoAP responses to the
client (i.e., not aggregated). The exception case here occurs client (i.e., not aggregated). The exception case here occurs
when a (future) standardized aggregation format is being used. when a (future) standardized aggregation format is being used.
o It MUST be known to the person/entity doing the configuration of o It MUST be known to the person/entity doing the configuration of
the proxy, or otherwise verified in some way, that the client the proxy, or otherwise verified in some way, that the client
configured in the whitelist supports receiving multiple responses configured in the whitelist supports receiving multiple responses
to a proxied unicast CoAP request. to a proxied unicast CoAP request.
2.11. Exceptions 2.11. Exceptions
Group communication using IP multicast offers improved network CoAP group communication using IP multicast offers improved network
efficiency and latency amongst other benefits. However, group efficiency and latency amongst other benefits. However, group
communication may not always be implementable in a given network. communication may not always be implementable in a given network.
The primary reason for this will be that IP multicast is not (fully) The primary reason for this will be that IP multicast is not (fully)
supported in the network. supported in the network.
For example, if only the RPL protocol [RFC6550] is used in a network For example, if only the RPL protocol [RFC6550] is used in a network
with its optional multicast support disabled, there will be no IP with its optional multicast support disabled, there will be no IP
multicast routing at all. The only multicast that works in this case multicast routing at all. The only multicast that works in this case
is link-local IPv6 multicast. This implies that any CoAP multicast is link-local IPv6 multicast. This implies that any CoAP group
request will be delivered to nodes on the local link only, regardless communication request will be delivered to nodes on the local link
of the scope value used in the IPv6 destination address. only, regardless of the scope value used in the IPv6 destination
address.
3. Use Cases and Corresponding Protocol Flows 3. Use Cases and Corresponding Protocol Flows
3.1. Introduction 3.1. Introduction
The use of CoAP group communication is shown in the context of the The use of CoAP group communication is shown in the context of the
following two use cases and corresponding protocol flows: following two use cases and corresponding protocol flows:
o Discovery of Resource Directory (RD, o Discovery of RD [I-D.ietf-core-resource-directory]: discovering
[I-D.ietf-core-resource-directory]): discovering the local CoAP RD the local CoAP RD which contains links to resources stored on
which contains links to resources stored on other CoAP servers other CoAP servers [RFC6690].
[RFC6690].
o Lighting Control: synchronous operation of a group of o Lighting Control: synchronous operation of a group of
IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights).
3.2. Network Configuration 3.2. Network Configuration
To illustrate the use cases we define two IPv6 network To illustrate the use cases we define two IPv6 network
configurations. Both are based on the topology as shown in Figure 1. configurations. Both are based on the topology as shown in Figure 1.
The two configurations using this topology are: The two configurations using this topology are:
skipping to change at page 21, line 13 skipping to change at page 22, line 13
Figure 1: Network Topology of a Large Room (Room-A) Figure 1: Network Topology of a Large Room (Room-A)
3.3. Discovery of Resource Directory 3.3. Discovery of Resource Directory
The protocol flow for discovery of the CoAP RD for the given network The protocol flow for discovery of the CoAP RD for the given network
(of Figure 1) is shown in Figure 2: (of Figure 1) is shown in Figure 2:
o Light-2 is installed and powered on for the first time. o Light-2 is installed and powered on for the first time.
o Light-2 will then search for the local CoAP RD by sending out a o Light-2 will then search for the local CoAP RD by sending out a
GET request (with the "/.well-known/core?rt=core.rd" request URI) group communication GET request (with the "/.well-known/
to the site-local "All CoAP Nodes" multicast address (FF05:::FD). core?rt=core.rd" request URI) to the site-local "All CoAP Nodes"
multicast address (FF05:::FD).
o This multicast message will then go to each node in subnet-2. o This multicast message will then go to each node in subnet-2.
Rtr-2 will then forward into to the Network Backbone where it will Rtr-2 will then forward it into to the Network Backbone where it
be received by the CoAP RD. All other nodes in subnet-2 will will be received by the CoAP RD. All other nodes in subnet-2 will
ignore the multicast GET because it is qualified by the query ignore the group communication GET request because it is qualified
string "?rt=core.rd" (which indicates it should only be processed by the query string "?rt=core.rd" (which indicates it should only
by the endpoint if it contains a resource of type core.rd). be processed by the endpoint if it contains a resource of type
"core.rd").
o The CoAP RD will then send back a unicast response containing the o The CoAP RD will then send back a unicast response containing the
requested content, which is a CoRE Link Format representation of a requested content, which is a CoRE Link Format representation of a
resource of type core.rd. resource of type "core.rd".
o Note that the flow is shown only for Light-2 for clarity. Similar o Note that the flow is shown only for Light-2 for clarity. Similar
flows will happen for Light-1, Light-3 and the Light Switch when flows will happen for Light-1, Light-3 and the Light Switch when
they are first installed. they are first installed.
The CoAP RD may also be discovered by other means such as by assuming The CoAP RD may also be discovered by other means such as by assuming
a default location (e.g., on a 6LBR), using DHCP, anycast address, a default location (e.g., on a 6LBR), using DHCP, anycast address,
etc. However, these approaches do not invoke CoAP group etc. However, these approaches do not invoke CoAP group
communication so are not further discussed here. (See communication so are not further discussed here. (See
[I-D.ietf-core-resource-directory] for more details). [I-D.ietf-core-resource-directory] for more details).
For other discovery use cases such as discovering local CoAP servers, For other discovery use cases such as discovering local CoAP servers,
services or resources group communication can be used in a similar services or resources, CoAP group communication can be used in a
fashion as in the above use case. For example, Link-Local (LL), similar fashion as in the above use case. For example, Link-Local
admin-local or site-local scoped discovery can be done this way. (LL), admin-local or site-local scoped discovery can be done this
way.
Light CoAP Light CoAP
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
********************************** | | | ********************************** | | |
* Light-2 is installed * | | | * Light-2 is installed * | | |
* and powers on for first time * | | | * and powers on for first time * | | |
********************************** | | | ********************************** | | |
| | | | | | | | | | | | | |
skipping to change at page 22, line 23 skipping to change at page 23, line 34
| | | | | | | | | | | | | |
Figure 2: Resource Directory Discovery via Multicast Request Figure 2: Resource Directory Discovery via Multicast Request
3.4. Lighting Control 3.4. Lighting Control
The protocol flow for a building automation lighting control scenario The protocol flow for a building automation lighting control scenario
for the network (Figure 1) is shown in Figure 3. The network is for the network (Figure 1) is shown in Figure 3. The network is
assumed to be in a 6LoWPAN configuration. Also, it is assumed that assumed to be in a 6LoWPAN configuration. Also, it is assumed that
the CoAP servers in each Light are configured to suppress CoAP the CoAP servers in each Light are configured to suppress CoAP
responses for any multicast CoAP requests related to lighting responses for any IP multicast CoAP requests related to lighting
control. (See Section 2.8 for more details on response suppression control. (See Section 2.8 for more details on response suppression
by a server.) by a server.)
In addition, Figure 4 shows a protocol flow example for the case that In addition, Figure 4 shows a protocol flow example for the case that
servers do respond to a lighting control multicast request with servers do respond to a lighting control IP multicast request with
(unicast) CoAP NON responses. There are two success responses and (unicast) CoAP NON responses. There are two success responses and
one 5.00 error response. In this particular case, the Light Switch one 5.00 error response. In this particular case, the Light Switch
does not check that all Lights in the group received the multicast does not check that all Lights in the group received the IP multicast
request by examining the responses. This is because the Light Switch request by examining the responses. This is because the Light Switch
is not configured with an exhaustive list of the IP addresses of all is not configured with an exhaustive list of the IP addresses of all
Lights belonging to the group. However, based on received error Lights belonging to the group. However, based on received error
responses it could take additional action such as logging a fault or responses it could take additional action such as logging a fault or
alerting the user via its LCD display. In case a CoAP message is alerting the user via its LCD display. In case a CoAP message is
delivered multiple times to a Light, the subsequent CoAP messages can delivered multiple times to a Light, the subsequent CoAP messages can
be filtered out as duplicates, based on the CoAP Message ID. be filtered out as duplicates, based on the CoAP Message ID.
Reliability of CoAP multicast is not guaranteed. Therefore, one or Reliability of IP multicast is not guaranteed. Therefore, one or
more lights in the group may not have received the CoAP control more lights in the group may not have received the CoAP control
request due to packet loss. In this use case there is no detection request due to packet loss. In this use case there is no detection
nor correction of such situations: the application layer expects that nor correction of such situations: the application layer expects that
the multicast forwarding/routing will be of sufficient quality to the IP multicast forwarding/routing will be of sufficient quality to
provide on average a very high probability of packet delivery to all provide on average a very high probability of packet delivery to all
CoAP endpoints in a multicast group. An example protocol to CoAP endpoints in an IP multicast group. An example protocol to
accomplish this using randomized retransmission is the MPL forwarding accomplish this using randomized retransmission is the MPL forwarding
protocol for LLNs [I-D.ietf-roll-trickle-mcast]. protocol for LLNs [I-D.ietf-roll-trickle-mcast].
We assume the following steps have already occurred before the We assume the following steps have already occurred before the
illustrated flows: illustrated flows:
1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to
all devices. The CoAP network is formed. all devices. The CoAP network is formed.
2. Network configuration (application-independent): 6LBRs are 2. Network configuration (application-independent): 6LBRs are
configured with multicast addresses, or address blocks, to filter configured with IP multicast addresses, or address blocks, to
out or to pass through to/from the 6LoWPAN. filter out or to pass through to/from the 6LoWPAN.
3. Commissioning phase (application-related): The IP multicast 3. Commissioning phase (application-related): The IP multicast
address of the group (Room-A-Lights) has been configured in all address of the group (Room-A-Lights) has been configured in all
the Lights and in the Light Switch. the Lights and in the Light Switch.
4. As an alternative to the previous step, when a DNS server is 4. As an alternative to the previous step, when a DNS server is
available, the Light Switch and/or the Lights have been available, the Light Switch and/or the Lights have been
configured with a group hostname which each nodes resolves to the configured with a group hostname which each nodes resolves to the
above IP multicast address of the group. above IP multicast address of the group.
Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software
stack supports sending unicast, multicast or proxied unicast CoAP stack supports sending unicast, multicast or proxied unicast CoAP
requests, including processing of the multiple responses that may be requests, including processing of the multiple responses that may be
generated by a multicast CoAP request. generated by an IP multicast CoAP request.
Light Network Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | *********************** | | | | *********************** | |
| | * User flips on * | | | | * User flips on * | |
| | * light switch to * | | | | * light switch to * | |
| | * turn on all the * | | | | * turn on all the * | |
| | * lights in Room A * | | | | * lights in Room A * | |
skipping to change at page 24, line 34 skipping to change at page 26, line 28
| | |------------------------------->| | | | |------------------------------->| |
| | | | | |--------->| | | | | | |--------->|
| | | | |<--------------------| | | | | |<--------------------|
| | | |<---------| | | | | | |<---------| | |
| | | | | | | | | | | | | |
Figure 4: Lights (Optionally) Respond to Multicast CoAP Request Figure 4: Lights (Optionally) Respond to Multicast CoAP Request
Another, but similar, lighting control use case is shown in Figure 5. Another, but similar, lighting control use case is shown in Figure 5.
In this case a controller connected to the Network Backbone sends a In this case a controller connected to the Network Backbone sends a
CoAP multicast request to turn on all lights in Room-A. Every Light CoAP group communication request to turn on all lights in Room-A.
sends back a CoAP response to the Controller after being turned on. Every Light sends back a CoAP response to the Controller after being
turned on.
Network Network
Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller
| | | | | | | | | | | | | |
| | | | | COAP NON Mcast(PUT, | | | | | COAP NON Mcast(PUT,
| | | | | Payload=lights ON) | | | | | Payload=lights ON)
| | | | | |<-------| | | | | | |<-------|
| | | |<----------<---------| | | | | |<----------<---------| |
|<--------------------------------| | | | |<--------------------------------| | | |
ON | | | | | | ON | | | | | |
| |<----------<---------------------| | | | |<----------<---------------------| | |
| ON ON | | | | | ON ON | | | |
^ ^ ^ | | | | ^ ^ ^ | | | |
*********************** | | | | *********************** | | | |
* Lights in Room-A * | | | | * Lights in Room-A * | | | |
* turn on (nearly * | | | | * turn on (nearly * | | | |
* simultaneously) * | | | | * simultaneously) * | | | |
*********************** | | | | *********************** | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| COAP NON (2.04 Changed) | | | | | COAP NON (2.04 Changed) | | | |
|-------------------------------->| | | | |-------------------------------->| | | |
| | | |-------------------->| | | | | |-------------------->| |
| | COAP NON (2.04 Changed) | |------->| | | COAP NON (2.04 Changed) | |------->|
| |-------------------------------->| | | | |-------------------------------->| | |
| | | | |--------->| | | | | | |--------->| |
| | | COAP NON (2.04 Changed) |------->| | | | COAP NON (2.04 Changed) |------->|
| | |--------------------->| | | | | |--------------------->| | |
| | | | |--------->| | | | | | |--------->| |
| | | | | |------->| | | | | | |------->|
| | | | | | | | | | | | | |
Figure 5: Controller On Backbone Sends Multicast Control Message Figure 5: Controller On Backbone Sends Multicast Control Message
3.5. Lighting Control in MLD Enabled Network 3.5. Lighting Control in MLD Enabled Network
The use case of previous section can also apply in networks where The use case of previous section can also apply in networks where
nodes support the MLD protocol [RFC3810]. The Lights then take on nodes support the MLD protocol [RFC3810]. The Lights then take on
the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2
Routers. In the Ethernet based network configuration, MLD may be Routers. In the Ethernet based network configuration, MLD may be
available on all involved network interfaces. Use of MLD in the available on all involved network interfaces. Use of MLD in the
skipping to change at page 25, line 44 skipping to change at page 28, line 8
support in all nodes in the 6LoWPAN. In current 6LoWPAN support in all nodes in the 6LoWPAN. In current 6LoWPAN
implementations, MLD is however not supported. implementations, MLD is however not supported.
The resulting protocol flow is shown in Figure 6. This flow is The resulting protocol flow is shown in Figure 6. This flow is
executed after the commissioning phase, as soon as Lights are executed after the commissioning phase, as soon as Lights are
configured with a group address to listen to. The (unicast) MLD configured with a group address to listen to. The (unicast) MLD
Reports may require periodic refresh activity as specified by the MLD Reports may require periodic refresh activity as specified by the MLD
protocol. In the figure, LL denotes Link Local communication. protocol. In the figure, LL denotes Link Local communication.
After the shown sequence of MLD Report messages has been executed, After the shown sequence of MLD Report messages has been executed,
both Rtr-1 and Rtr-2 are automatically configured to forward both Rtr-1 and Rtr-2 are automatically configured to forward IP
multicast traffic destined to Room-A-Lights onto their connected multicast traffic destined to Room-A-Lights onto their connected
subnet. Hence, no manual Network Configuration of routers, as subnet. Hence, no manual Network Configuration of routers, as
previously indicated in Section 3.4, is needed anymore. previously indicated in Section 3.4, is needed anymore.
Light Network Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| MLD Report: Join | | | | | | MLD Report: Join | | | | |
| Group (Room-A-Lights) | | | | | Group (Room-A-Lights) | | | |
|---LL------------------------------------->| | | |---LL------------------------------------->| | |
| | | | |MLD Report: Join | | | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)| | | | | |Group (Room-A-Lights)|
| | | | |---LL---->----LL---->| | | | | |---LL---->----LL---->|
skipping to change at page 26, line 41 skipping to change at page 29, line 4
3.6. Commissioning the Network Based On Resource Directory 3.6. Commissioning the Network Based On Resource Directory
This section outlines how devices in the lighting use case (both This section outlines how devices in the lighting use case (both
Switches and Lights) can be commissioned, making use of Resource Switches and Lights) can be commissioned, making use of Resource
Directory [I-D.ietf-core-resource-directory] and its group Directory [I-D.ietf-core-resource-directory] and its group
configuration feature. configuration feature.
Once the Resource Directory (RD) is discovered, the Switches and Once the Resource Directory (RD) is discovered, the Switches and
Lights need to be discovered and their groups need to be defined. Lights need to be discovered and their groups need to be defined.
For the commissioning of these devices, a commissioning tool can be For the commissioning of these devices, a commissioning tool can be
used that defines the entries in the RD. The commissioning tool has used that defines the entries in the RD. The commissioning tool has
the authority to change the contents of the RD and the Light/Switch the authority to change the contents of the RD and the Light/Switch
nodes. DTLS based security is used by the commissioning tool to nodes. DTLS based security is used by the commissioning tool to
modify operational data in RD, Switches and Lights. modify operational data in RD, Switches and Lights.
In our particular use case, a group of three lights is defined with In our particular use case, a group of three lights is defined with
one multicast address and hostname one IP multicast address and hostname
"Room-A-Lights.floor1.west.bldg6.example.com". The commissioning "Room-A-Lights.floor1.west.bldg6.example.com". The commissioning
tool has a list of the three lights and the associated multicast tool has a list of the three lights and the associated IP multicast
address. For each light in the list the tool learns the IP address address. For each light in the list the tool learns the IP address
of the light and instructs the RD with three POST commands to store of the light and instructs the RD with three (unicast) POST commands
the endpoints associated with the three lights as prescribed by the to store the endpoints associated with the three lights as prescribed
RD specification [I-D.ietf-core-resource-directory]. Finally the by the RD specification [I-D.ietf-core-resource-directory]. Finally
commissioning tool defines the group in the RD to contain these three the commissioning tool defines the group in the RD to contain these
endpoints. Also the commissioning tool writes the multicast address three endpoints. Also the commissioning tool writes the IP multicast
in the Light endpoints with, for example, the POST command discussed address in the Light endpoints with, for example, the (unicast) POST
in Section 2.7.2.2. command discussed in Section 2.7.2.2.
The light switch can discover the group in RD and thus learn the The light switch can discover the group in RD and thus learn the IP
multicast address of the group. The light switch will use this multicast address of the group. The light switch will use this
address to send multicast commands to the members of the group. When address to send CoAP group communication requests to the members of
the message arrives the Lights should recognize the multicast address the group. When the message arrives the Lights should recognize the
and accept the message. IP multicast address and accept the message.
4. Deployment Guidelines 4. Deployment Guidelines
This section provides guidelines how IP Multicast based CoAP group This section provides guidelines how IP multicast based CoAP group
communication can be deployed in various network configurations. communication can be deployed in various network configurations.
4.1. Target Network Topologies 4.1. Target Network Topologies
CoAP group communication can be deployed in various network CoAP group communication can be deployed in various network
topologies. First, the target network may be a traditional IP topologies. First, the target network may be a traditional IP
network, or a LLN such as a 6LoWPAN network, or consist of mixed network, or a LLN such as a 6LoWPAN network, or consist of mixed
traditional/constrained network segments. Second, it may be a single traditional/constrained network segments. Second, it may be a single
subnet only or multi-subnet; e.g., multiple 6LoWPAN networks joined subnet only or multi-subnet; e.g., multiple 6LoWPAN networks joined
by a single backbone LAN. Third, a wireless network segment may have by a single backbone LAN. Third, a wireless network segment may have
skipping to change at page 27, line 41 skipping to change at page 30, line 4
all its nodes reachable in a single IP hop (fully connected), or it all its nodes reachable in a single IP hop (fully connected), or it
may require multiple IP hops for some pairs of nodes to reach each may require multiple IP hops for some pairs of nodes to reach each
other. other.
Each topology may pose different requirements on the configuration of Each topology may pose different requirements on the configuration of
routers and protocol(s), in order to enable efficient CoAP group routers and protocol(s), in order to enable efficient CoAP group
communication. To enable all the above target network topologies, an communication. To enable all the above target network topologies, an
implementation of CoAP group communication needs to allow: implementation of CoAP group communication needs to allow:
1. Routing/forwarding of IP multicast packets over multiple hops 1. Routing/forwarding of IP multicast packets over multiple hops
2. Routing/forwarding of IP multicast packets over subnet boundaries 2. Routing/forwarding of IP multicast packets over subnet boundaries
between traditional and constrained (e.g. LLN) networks. between traditional and constrained (e.g. LLN) networks.
The remainder of this section discusses solutions to enable both The remainder of this section discusses solutions to enable both
features. features.
4.2. Networks Using the MLD Protocol 4.2. Networks Using the MLD Protocol
CoAP nodes that are IP hosts (i.e., not IP routers) are generally CoAP nodes that are IP hosts (i.e., not IP routers) are generally
unaware of the specific multicast routing/forwarding protocol being unaware of the specific IP multicast routing/forwarding protocol
used. When such a host needs to join a specific (CoAP) multicast being used. When such a host needs to join a specific (CoAP)
group, it requires a way to signal to multicast routers which multicast group, it requires a way to signal to IP multicast routers
multicast traffic it wants to receive. which IP multicast traffic it wants to receive.
The Multicast Listener Discovery (MLD) protocol [RFC3810] (see The Multicast Listener Discovery (MLD) protocol [RFC3810] (see
Appendix A) is the standard IPv6 method to achieve this; therefore Appendix A) is the standard IPv6 method to achieve this; therefore
this approach should be used on traditional IP networks. CoAP server this approach should be used on traditional IP networks. CoAP server
nodes would then act in the role of MLD Multicast Address Listener. nodes would then act in the role of MLD Multicast Address Listener.
The guidelines from [RFC6636] on tuning of MLD for mobile and The guidelines from [RFC6636] on tuning of MLD for mobile and
wireless networks may be useful when implementing MLD in LLNs. wireless networks may be useful when implementing MLD in LLNs.
However, on LLNs and 6LoWPAN networks the use of MLD may not be However, on LLNs and 6LoWPAN networks the use of MLD may not be
feasible at all due to constraints on code size, memory, or network feasible at all due to constraints on code size, memory, or network
skipping to change at page 28, line 31 skipping to change at page 30, line 41
It is assumed in this section that the MLD protocol is not It is assumed in this section that the MLD protocol is not
implemented in a network, for example due to resource constraints. implemented in a network, for example due to resource constraints.
The RPL routing protocol (see Section 12 of [RFC6550]) defines the The RPL routing protocol (see Section 12 of [RFC6550]) defines the
advertisement of IP multicast destinations using DAO messages and advertisement of IP multicast destinations using DAO messages and
routing of multicast IPv6 packets based on this. It requires the RPL routing of multicast IPv6 packets based on this. It requires the RPL
Mode of Operation (MOP) to be 3 (Storing Mode with multicast Mode of Operation (MOP) to be 3 (Storing Mode with multicast
support). support).
Hence, RPL DAO can be used by CoAP nodes that are RPL Routers, or are Hence, RPL DAO can be used by CoAP nodes that are RPL Routers, or are
RPL Leaf Nodes, to advertise IP multicast group membership to parent RPL Leaf Nodes, to advertise IP multicast group membership to parent
routers. Then, the RPL protocol is used to route multicast CoAP routers. Then, the RPL protocol is used to route IP multicast CoAP
requests over multiple hops to the correct CoAP servers. requests over multiple hops to the correct CoAP servers.
The same DAO mechanism can be used to convey IP multicast group The same DAO mechanism can be used to convey IP multicast group
membership information to an edge router (e.g., 6LBR), in case the membership information to an edge router (e.g., 6LBR), in case the
edge router is also the root of the RPL DODAG. This is useful edge router is also the root of the RPL DODAG. This is useful
because the edge router then learns which IP multicast traffic it because the edge router then learns which IP multicast traffic it
needs to pass through from the backbone network into the LLN subnet. needs to pass through from the backbone network into the LLN subnet.
In 6LoWPAN networks, such selective "filtering" helps to avoid In 6LoWPAN networks, such selective "filtering" helps to avoid
congestion of a 6LoWPAN subnet by IP multicast traffic from the congestion of a 6LoWPAN subnet by IP multicast traffic from the
traditional backbone IP network. traditional backbone IP network.
skipping to change at page 29, line 22 skipping to change at page 31, line 31
addresses the individual nodes are listening to. addresses the individual nodes are listening to.
However, if an IP multicast request originates just outside the MPL However, if an IP multicast request originates just outside the MPL
Domain, the request will not be propagated by MPL. An example of Domain, the request will not be propagated by MPL. An example of
such a case is the network topology of Figure 1 where the Subnets are such a case is the network topology of Figure 1 where the Subnets are
6LoWPAN subnets and per 6LoWPAN subnet one Realm-Local 6LoWPAN subnets and per 6LoWPAN subnet one Realm-Local
([I-D.droms-6man-multicast-scopes]) MPL Domain is defined. The ([I-D.droms-6man-multicast-scopes]) MPL Domain is defined. The
backbone network in this case is not part of any MPL Domain. backbone network in this case is not part of any MPL Domain.
This situation can become a problem in building control use cases. This situation can become a problem in building control use cases.
For example, when the Controller Client needs to send a single CoAP For example, when the Controller Client needs to send a single IP
multicast request to the group Room-A-Lights. By default, the multicast request to the group Room-A-Lights. By default, the
request would be blocked by Rtr-1 and by Rtr-2, and not enter the request would be blocked by Rtr-1 and by Rtr-2, and not enter the
Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The
reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices
in Subnet-1/2 want to listen for IP packets destined to multicast in Subnet-1/2 want to listen for IP packets destined to IP multicast
group Room-A-Lights. group Room-A-Lights.
To solve the above issue, the following solutions could be applied: To solve the above issue, the following solutions could be applied:
1. Extend the MPL Domain. E.g. in above example, include the 1. Extend the MPL Domain. E.g. in above example, include the
Network Backbone to be part of each of the two MPL Domains. Or Network Backbone to be part of each of the two MPL Domains. Or
in above example, create just a single MPL Domain that includes in above example, create just a single MPL Domain that includes
both 6LoWPAN subnets plus the backbone link, which is possible both 6LoWPAN subnets plus the backbone link, which is possible
since MPL is not tied to a single link-layer technology. since MPL is not tied to a single link-layer technology.
2. Manual configuration of edge router(s) as MPL Seed(s) for 2. Manual configuration of edge router(s) as MPL Seed(s) for
specific multicast traffic. E.g. in above example, first specific IP multicast traffic. E.g. in above example, first
configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the
Room-A-Lights multicast group. This step allows any (other) Room-A-Lights IP multicast group. This step allows any (other)
routers on the backbone to learn that at least one node on the routers on the backbone to learn that at least one node on the
backbone link is interested to receive any multicast traffic to backbone link is interested to receive any IP multicast traffic
Room-A-Lights. Second, configure both routers to "inject" any IP to Room-A-Lights. Second, configure both routers to "inject" any
multicast packets destined to group Room-A-Lights into the IP multicast packets destined to group Room-A-Lights into the
(Realm-Local) MPL Domain that is associated to that router. (Realm-Local) MPL Domain that is associated to that router.
Third, configure both routers to propagate any IPv6 multicast Third, configure both routers to propagate any IPv6 multicast
packets originating from within their associated MPL Domain to packets originating from within their associated MPL Domain to
the backbone, if at least one node on the backbone has indicated the backbone, if at least one node on the backbone has indicated
interest to receive such IPv6 packets (for which MLD is used on interest to receive such IPv6 packets (for which MLD is used on
the backbone). the backbone).
3. Use an additional protocol/mechanism for injection of multicast 3. Use an additional protocol/mechanism for injection of IP
traffic from outside an MPL Domain into that MPL Domain, based on multicast traffic from outside an MPL Domain into that MPL
multicast group subscriptions of Forwarders within the MPL Domain, based on IP multicast group subscriptions of Forwarders
Domain. Such protocol is currently not defined in within the MPL Domain. Such protocol is currently not defined in
[I-D.ietf-roll-trickle-mcast]. [I-D.ietf-roll-trickle-mcast].
Concluding, MPL can be used directly in case all sources of multicast Concluding, MPL can be used directly in case all sources of IP
CoAP requests (CoAP clients) and also all the destinations (CoAP multicast CoAP requests (CoAP clients) and also all the destinations
servers) are inside a single MPL Domain. Then, each source node acts (CoAP servers) are inside a single MPL Domain. Then, each source
as an MPL Seed. In all other cases, MPL can only be used with node acts as an MPL Seed. In all other cases, MPL can only be used
additional protocols and/or configuration on how IP multicast packets with additional protocols and/or configuration on how IP multicast
can be injected from outside into an MPL Domain. packets can be injected from outside into an MPL Domain.
4.5. 6LoWPAN Specific Guidelines for the 6LBR 4.5. 6LoWPAN Specific Guidelines for the 6LBR
To support multi-subnet scenarios for CoAP group communication, it is To support multi-subnet scenarios for CoAP group communication, it is
recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD
Router role on the backbone link. If this is not possible then the Router role on the backbone link. If this is not possible then the
6LBR should be configured to act as an MLD Multicast Address Listener 6LBR should be configured to act as an MLD Multicast Address Listener
(see Appendix A) on the backbone link. (see Appendix A) on the backbone link.
5. Security Considerations 5. Security Considerations
skipping to change at page 31, line 8 skipping to change at page 33, line 18
at the CoAP layer for group communication. This is due to the fact at the CoAP layer for group communication. This is due to the fact
that the current DTLS based approach for CoAP is exclusively unicast that the current DTLS based approach for CoAP is exclusively unicast
oriented and does not support group security features such as group oriented and does not support group security features such as group
key exchange and group authentication. As a direct consequence of key exchange and group authentication. As a direct consequence of
this, CoAP group communication is vulnerable to all attacks mentioned this, CoAP group communication is vulnerable to all attacks mentioned
in [I-D.ietf-core-coap] for IP multicast. in [I-D.ietf-core-coap] for IP multicast.
5.3. Threat Mitigation 5.3. Threat Mitigation
The [I-D.ietf-core-coap] identifies various threat mitigation The [I-D.ietf-core-coap] identifies various threat mitigation
techniques for CoAP multicast. In addition to those guidelines, it techniques for CoAP group communication. In addition to those
is recommended that for sensitive data or safety-critical control, a guidelines, it is recommended that for sensitive data or safety-
combination of appropriate link-layer security and administrative critical control, a combination of appropriate link-layer security
control of IP multicast boundaries should be used. Some examples are and administrative control of IP multicast boundaries should be used.
given below. Some examples are given below.
5.3.1. WiFi Scenario 5.3.1. WiFi Scenario
In a home automation scenario (using WiFi), the WiFi encryption In a home automation scenario (using WiFi), the WiFi encryption
should be enabled to prevent rogue nodes from joining. The Customer should be enabled to prevent rogue nodes from joining. The Customer
Premise Equipment (CPE) that enables access to the Internet should Premise Equipment (CPE) that enables access to the Internet should
also have its multicast filters set so that it enforces multicast also have its IP multicast filters set so that it enforces multicast
scope boundaries to isolate local multicast groups from the rest of scope boundaries to isolate local multicast groups from the rest of
the Internet (e.g., as per [RFC6092]). In addition, the scope of the the Internet (e.g., as per [RFC6092]). In addition, the scope of the
IP multicast should be set to be site-local or smaller scope. For IP multicast should be set to be site-local or smaller scope. For
site-local scope, the CPE will be an appropriate multicast scope site-local scope, the CPE will be an appropriate multicast scope
boundary point. boundary point.
5.3.2. 6LoWPAN Scenario 5.3.2. 6LoWPAN Scenario
In a building automation scenario, a particular room may have a In a building automation scenario, a particular room may have a
single 6LoWPAN network with a single Edge Router (6LBR). Nodes on single 6LoWPAN network with a single Edge Router (6LBR). Nodes on
skipping to change at page 32, line 43 skipping to change at page 35, line 5
Optional parameters: None Optional parameters: None
Encoding considerations: 8bit UTF-8. Encoding considerations: 8bit UTF-8.
JSON to be represented using UTF-8 which is 8bit compatible (and most JSON to be represented using UTF-8 which is 8bit compatible (and most
efficient for resource constrained implementations). efficient for resource constrained implementations).
Security considerations: Security considerations:
Denial of Service attacks could be performed by constantly setting Denial of Service attacks could be performed by constantly
the group configuration resource of a CoAP endpoint to different (re-)setting the group configuration resource of a CoAP endpoint to
values. This will cause the endpoint to register (or de-register) different values. This will cause the endpoint to register (or de-
from the related IP multicast group. To prevent this it is register) from the related IP multicast group. To prevent this it is
recommended that DTLS-secured (unicast) CoAP communication be used recommended that a form of authorization (making use of DTLS-secured
for setting the group configuration resource. Thus only authorized CoAP) be used such that only authorized controllers are allowed by an
clients will be allowed by a server to configure its group endpoint to configure its group membership.
membership.
Interoperability considerations: None Interoperability considerations: None
Published specification: (This I-D when it becomes an RFC) Published specification: (This I-D when it becomes an RFC)
Applications that use this media type: Applications that use this media type:
CoAP client and server implementations that wish to set/read the CoAP client and server implementations that wish to set/read the
group configuration resource via 'application/coap-group+json' group configuration resource via 'application/coap-group+json'
payload as described in Section 2.7.2. payload as described in Section 2.7.2.
skipping to change at page 33, line 34 skipping to change at page 35, line 42
Restrictions on usage: None Restrictions on usage: None
Author: CoRE WG Author: CoRE WG
Change controller: IETF Change controller: IETF
7. Acknowledgements 7. Acknowledgements
Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo
Castellani, Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore Castellani, Thomas Fossati, Bjoern Hoehrmann, Matthias Kovatsch,
Loreto, Kerry Lynn, Andrew McGregor, Dale Seed, Zach Shelby, Peter Guang Lu, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Dale Seed,
van der Stok, and Juan Carlos Zuniga for their helpful comments and Zach Shelby, Peter van der Stok, Gengyu Wei, and Juan Carlos Zuniga
discussions that have helped shape this document. for their helpful comments and discussions that have helped shape
this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC [RFC1033] Lottor, M., "Domain administrators operations guide", RFC
1033, November 1987. 1033, November 1987.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
skipping to change at page 34, line 38 skipping to change at page 36, line 49
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010. March 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January Residential IPv6 Internet Service", RFC 6092, January
2011. 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
skipping to change at page 36, line 9 skipping to change at page 38, line 23
September 2013. September 2013.
[I-D.droms-6man-multicast-scopes] [I-D.droms-6man-multicast-scopes]
Droms, R., "IPv6 Multicast Address Scopes", draft-droms- Droms, R., "IPv6 Multicast Address Scopes", draft-droms-
6man-multicast-scopes-02 (work in progress), July 2013. 6man-multicast-scopes-02 (work in progress), July 2013.
Appendix A. Multicast Listener Discovery (MLD) Appendix A. Multicast Listener Discovery (MLD)
In order to extend the scope of IP multicast beyond link-local scope, In order to extend the scope of IP multicast beyond link-local scope,
an IP multicast routing or forwarding protocol has to be active in an IP multicast routing or forwarding protocol has to be active in
routers on an LLN. To achieve efficient multicast routing (i.e., routers on an LLN. To achieve efficient IP multicast routing (i.e.,
avoid always flooding IP multicast packets), routers have to learn avoid always flooding IP multicast packets), routers have to learn
which hosts need to receive packets addressed to specific IP which hosts need to receive packets addressed to specific IP
multicast destinations. multicast destinations.
The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its
IPv4 equivalent IGMP [RFC3376]) is today the method of choice used by IPv4 equivalent IGMP [RFC3376]) is today the method of choice used by
an (IP multicast enabled) router to discover the presence of an (IP multicast enabled) router to discover the presence of IP
multicast listeners on directly attached links, and to discover which multicast listeners on directly attached links, and to discover which
multicast addresses are of interest to those listening nodes. MLD IP multicast addresses are of interest to those listening nodes. MLD
was specifically designed to cope with fairly dynamic situations in was specifically designed to cope with fairly dynamic situations in
which multicast listeners may join and leave at any time. which IP multicast listeners may join and leave at any time.
[RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for [RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for
routers for mobile and wireless networks. These guidelines may be routers for mobile and wireless networks. These guidelines may be
useful when implementing MLD in LLNs. useful when implementing MLD in LLNs.
Appendix B. Change Log Appendix B. Change Log
[Note to RFC Editor: Please remove this section before publication.] [Note to RFC Editor: Please remove this section before publication.]
Changes from ietf-17 to ietf-18:
o Extensive editorial updates based on WGLC comments by Thomas
Fossati and Gengyu Wei.
o Addressed ticket #361: Added text for single membership PUT
section 2.7.2.7 (Updating a single group membership (PUT)).
o Addressed ticket #360: Added text for server duties upon all-at-
once PUT section 2.7.2.6 (Creating/updating all group memberships
at once (PUT)).
o Addressed ticket #359: Fixed requirements text for Section 2.7.2.2
(Creating a new multicast group membership (POST)).
o Addressed ticket #358: Fixed requirements text for Section 2.7.2.1
(CoAP-Group Resource Type and Media Type).
o Addressed ticket #357: Added that "IPv6 addresses of other scopes
MAY be enabled" in section 2.2 (Group Definition and Naming).
o Various editorial updates for improved readability.
Changes from ietf-16 to ietf-17: Changes from ietf-16 to ietf-17:
o Added guidelines on joining of IPv6/IPv4 "All CoAP Nodes" o Added guidelines on joining of IPv6/IPv4 "All CoAP Nodes"
multicast addresses (#356). multicast addresses (#356).
o Added MUST support default port in case multicast discovery is o Added MUST support default port in case multicast discovery is
available. available.
o In section 2.1 (IP Multicast Background), clarified that IP o In section 2.1 (IP Multicast Background), clarified that IP
multicast is not guaranteed and referenced a definition of multicast is not guaranteed and referenced a definition of
skipping to change at page 39, line 31 skipping to change at page 42, line 21
Changes from ietf-08 to ietf-09: Changes from ietf-08 to ietf-09:
o Cleaned up requirements language in general. Also, requirements o Cleaned up requirements language in general. Also, requirements
language are now only used in section 3 (Protocol Considerations) language are now only used in section 3 (Protocol Considerations)
and section 6 (Security Considerations). Requirements language and section 6 (Security Considerations). Requirements language
has been removed from other sections to keep them to a minimum has been removed from other sections to keep them to a minimum
(#271). (#271).
o Addressed final comment from Peter van der Stok to define what "IP o Addressed final comment from Peter van der Stok to define what "IP
stack" meant (#296). Following the lead of CoAP-17, we know refer stack" meant (#296). Following the lead of CoAP-17, we know refer
instead to "APIs such as IPV6_RECVPKTINFO [RFC3542]". instead to "APIs such as IPV6_RECVPKTINFO [RFC 3542]".
o Changed text in section 3.4 (Group Methods) to allow multicast o Changed text in section 3.4 (Group Methods) to allow multicast
POST under specific conditions and highlighting the risks with POST under specific conditions and highlighting the risks with
using it (#328). using it (#328).
o Various editorial updates for improved readability. o Various editorial updates for improved readability.
Changes from ietf-07 to ietf-08: Changes from ietf-07 to ietf-08:
o Updated text in section 3.6 (Configuring Group Membership in o Updated text in section 3.6 (Configuring Group Membership in
 End of changes. 155 change blocks. 
462 lines changed or deleted 533 lines changed or added

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