One document matched: draft-rahman-core-groupcomm-03.txt
Differences from draft-rahman-core-groupcomm-02.txt
CoRE A. Rahman, Ed.
Internet-Draft InterDigital Communications, LLC
Intended status: Informational March 9, 2011
Expires: September 10, 2011
Group Communication for CoAP
draft-rahman-core-groupcomm-03
Abstract
This is a working document intended to trigger discussion and develop
draft language for the CoAP protocol specification in the area of
group communication (including multicast functionality). Engineering
tradeoffs become more challenging in constrained environments,
therefore group communication is considered within the context of
adjacent topics that may impact or be impacted by design choices in
the subject area.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Rahman Expires September 10, 2011 [Page 1]
Internet-Draft Group Communication for CoAP March 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Problem Statement and Scope . . . . . . . . . . . . . . . 4
3. Multicast Solutions . . . . . . . . . . . . . . . . . . . . . 4
3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Group Addressing . . . . . . . . . . . . . . . . . . . 5
3.1.2. Group URIs . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Group Discovery . . . . . . . . . . . . . . . . . . . 5
3.1.4. Group Resource Manipulation . . . . . . . . . . . . . 6
3.1.5. Multicast Transmission Methods . . . . . . . . . . . . 7
3.1.6. Congestion Control . . . . . . . . . . . . . . . . . . 8
3.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 8
4. CoAP Application Group Management . . . . . . . . . . . . . . 9
5. Alternate Group Transmission Methods . . . . . . . . . . . . . 11
5.1. Serial Unicast . . . . . . . . . . . . . . . . . . . . . . 11
6. CoAP Multicast and HTTP Unicast Interworking . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Rahman Expires September 10, 2011 [Page 2]
Internet-Draft Group Communication for CoAP March 2011
1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following are definitions of terminologies used in this draft.
Multicast: A solution based on the use of IP multicast addresses as
defined in "IANA Guidelines for IPv4 Multicast Address Assignments"
[RFC5771] and "IP Version 6 Addressing Architecture" [RFC4291].
Group Communication: One source node sends a CoAP message to more
than one destination node. The source and destination nodes can be
constrained or non-constrained nodes. This may include serial
unicast, multicast, or hybrid unicast-to-multicast solutions.
2. Introduction
2.1. Background
The CoRE working group is chartered to design and standardize a
Constrained Application Protocol (CoAP) for resource constrained
devices and networks [I-D.ietf-core-coap]. The requirements for CoRE
are documented in [I-D.shelby-core-coap-req].
In this draft, we focus and expand discussions on requirements
pertaining to multicast support, including:
REQ 9: CoAP will support a non-reliable IP multicast message to be
sent to a group of Devices to manipulate a resource on all the
Devices simultaneously. The use of multicast to query and
advertise descriptions must be supported, along with the support
of unicast responses.
Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable
multicast using UDP. It defines the unreliable multicast operation
as follows:
"CoAP supports sending messages to multicast destination
addresses. Such multicast messages MUST be Non-Confirmable.
Mechanisms for avoiding congestion from multicast requests are
being considered in [I-D.eggert-core-congestion-control]."
Additional requirements were introduced in [I-D.vanderstok-core-bc]
driven by quality of experience issues in commercial lighting; the
need for large numbers of devices to respond with near simultaneity
Rahman Expires September 10, 2011 [Page 3]
Internet-Draft Group Communication for CoAP March 2011
to a command (multicast PUT), and for that command to be received
reliably (reliable multicast).
2.2. Problem Statement and Scope
In this draft, we expand the scope from unreliable multicast in the
current CoAP requirement to group communication, using either
(reliable or unreliable) multicast or unicast.
Machine-to-Machine (M2M) networks may contain groups of nodes that
are highly correlated (e.g. by type or location). For example, all
smart meters in a region may belong to one group, and all light
switches in a building control system belong to another. Group
communication can increase the efficiency of communication and reduce
bandwidth requirements for a given application.
In the following sections, we address the issues related to group
communication in detail, with proposed solutions and analysis of
impacts to the CoAP protocol and implementations.
3. Multicast Solutions
The classic model of a multicast application is that of a single
source distributing content to many recipients. Multicast solutions
have evolved from "bottom" to "top", i.e., from the network layer (IP
multicast) to application layer multicast. A study published in 2005
identified new solutions in the "middle" (referred to as overlay
multicast) that utilize an infrastructure based on proxies [STUDY1].
Each of these classes of multicast solutions may be compared using
metrics such as link stress and level of host complexity [STUDY2].
The approach adopted here is to begin with IP multicast and present a
complete picture to introduce some key concepts, then expand to cover
more general scenarios such as group management and CoAP-to-HTTP
proxies.
3.1. IP Multicast
IP Multicast protocols have been evolving for decades, resulting in
proposed standards such as Protocol Independent Multicast - Sparse
Mode (PIM-SM) [RFC4601]. Yet, due to various technical and marketing
reasons, IP Multicast is not widely deployed on the Internet, leading
to alternative solutions for applications like interactive gaming and
publish/subscribe. However, the packet economy and minimal host
complexity of IP multicast make it worth investigating for intra-
domain group communication in constrained environments.
Rahman Expires September 10, 2011 [Page 4]
Internet-Draft Group Communication for CoAP March 2011
3.1.1. Group Addressing
The header compression proposal of 6LoWPAN [I-D.ietf-6lowpan-hc]
includes a format to support Unicast-Prefix-based IPv6 Multicast
Addresses such as [RFC3956], which is itself a scheme to simplify the
deployment of PIM-SM [RFC4601]. Since the use of header compression
for CoAP is highly desirable, it should be investigated if addressing
mode can be used for IP multicast.
3.1.2. Group URIs
An approach to map group authorities onto multicast addresses using
DNS was proposed in [I-D.vanderstok-core-bc]. Examples of group URI
naming (and scoping) for a building control application are shown
below. Group URIs MUST follow the approach of the URI structure
defined in [RFC3986].
//all.bldg6... "all nodes in building 6"
//all.west.bldg6... "all nodes in west wing, building 6"
//all.floor1.west.bldg6... "all nodes in floor 1, west wing, etc."
//all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1,
etc."
The authority portion of the URI is used to identify a node (or
group) and the resulting DNS name is bound to a unicast or (or
multicast) address. Each example group URI shown above might be
mapped to a unique multicast IP addresses as defined in [RFC3956].
3.1.3. Group Discovery
CoAP defines a resource discovery capability but, in the absence of a
multicast infrastructure, it is limited to link-local scope; examples
may be found in [I-D.ietf-core-link-format]. A service discovery
capability is required to extend discovery to other subnets and scale
beyond a certain point, as originally proposed in
[I-D.vanderstok-core-bc].
DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a
conventional way to configure DNS PTR, SRV, and TXT records to enable
enumeration of services such as CoAP nodes within subdomains. A
service is specified by a name of the form Instance.Type.Domain,
where the type for CoAP nodes is _coap._udp and the domain is a DNS
domain name that identifies a building zone as in the examples above.
For each CoAP end-point in the zone, a PTR record with the name
_coap._udp is defined and it points to an SRV record having the
Rahman Expires September 10, 2011 [Page 5]
Internet-Draft Group Communication for CoAP March 2011
Instance.Type.Domain name.
All CoAP nodes in a given subdomain may be enumerated by sending a
query for PTR records named _coap._udp to the authoritative server
for that zone. A list of SRV records is returned. Each SRV record
contains the port and host name (AAAA record) of a CoAP node. The IP
address of the node is obtained by resolving the host name. DNS-SD
also specifies an optional TXT record, having the same name as the
SRV record, which can contain "key=value" attributes. This can be
used to store information about the device, e.g. schema=DALI,
type=switch, group=lighting.bldg6, etc.
Another feature of DNS-SD is the ability to specify service subtypes
using PTR records. For example, one could represent all the CoAP
groups in a subdomain by PTR records with the name
_group._sub._coap._udp.
3.1.4. Group Resource Manipulation
Two forms of group resource manipulation must be supported. The
first is push (multicast PUT or MPUT for short) as e.g. "turn off all
the lights simultaneously". Logically, this is similar to publishing
a value to multiple subscribers. The second operation is pull
(multicast GET or MGET), which is essential for discovery during
comissioning and can be illustrated by the example "return all the
resources matching a .well-known URI". MGET should perhaps be
limited in scope to link-local multicast for scaling [TBD: and
possibly for security reasons, e.g. DoS attacks].
Conceptually, the result of a multicast GET or PUT should be the same
as if the client had unicast them serially (that is, a set of {URI,
representation} tuples). Practically, there are major benefits to
solving this problem:
- packet economy on constrained networks
- M2M resource discovery (solves the "chicken-and-egg" problem)
- apparent simultaneity of events (e.g. lighting applications)
For data links (or transports) that don't support IP multicast, a
serial unicast alternative must be provided. In either case it
should be possible to enumerate the members of a group. For links
that do support IP multicast, there are a few implications:
- All multicast requests MUST be sent to the well-known CoAP port
Rahman Expires September 10, 2011 [Page 6]
Internet-Draft Group Communication for CoAP March 2011
- All multicast requests SHOULD operate on /.well-known/core URIs
The justification for these constraints is that all nodes in a given
group (defined over the IP address space) must receive the same
request with high probability. This will not be the case if there is
diversity in the authority port (i.e. a diversity of dynamic port
addresses across the group) or the targeted resource is located at
different paths on different nodes. Extending the definition of
group membership to include port and path discovery is not desirable.
One question is whether the application (or middleboxes) need to be
aware that a request is intended for a group. A separate scheme as
proposed by [ID.goland-http-udp] might be useful (e.g. "corem" vs.
"core"). To the extent that group membership might be implemented as
a list of multicast, serial unicast, or some combination, having a
distinct scheme for group operations might be a useful signal for the
proxy receiving the request to look up the group membership and
replicate serial unicasts as well as multicast packets.
3.1.5. Multicast Transmission Methods
3.1.5.1. Unreliable IP Multicast
The CoRE WG charter specified support of non-reliable multicast. In
the current CoAP protocol design [I-D.ietf-core-coap], unreliable
multicast is realized by the source sending non-confirmable messages.
3.1.5.2. Reliable IP Multicast
[This is a difficult problem. Need to investigate the benefits of
repeating MGET and MPUT requests (saturation) to get "Pretty Good
Reliability". Use the same TID or a new TID for repeated requests?
Carsten suggests the use of bloom filters to suppress duplicate
responses.
Note that non-idempotent operations (POST) cannot be supported
without a *truly* reliable multicast protocol.]
Reliable multicast supports guaranteed delivery of messages to a
group of nodes. The following specifies the requirements as was
proposed originally in [I-D.vanderstok-core-bc]:
Validity - If sender sends a message, m, to a group, g, of
destinations, a path exists between sender and destinations, and the
sender and destinations are correct, all destinations in g eventually
receive m.
Integrity - destination receives m at most once from sender and only
Rahman Expires September 10, 2011 [Page 7]
Internet-Draft Group Communication for CoAP March 2011
if sender sent m to a group including destination.
Agreement - If a correct destination of g receives m, then all
correct destinations of g receive m.
Timeliness - For real-time control of devices, there is a known
constant D such that if m is sent at time t, no correct destination
receives m after t+D.
There are various approaches to achieve reliability, such as
* Destination node sends acknowledgement: in CoAP, multicast
messages are confirmable when reliability is required.
* Route redundancy
* Source node transmits multiple times
3.1.6. Congestion Control
[In the case of MGET or Confirmable MPUT, servers should enforce a
random delay within TIMEOUT before sending responses. More
investigation required.]
CoAP requests may be multicast, resulting multitude of replies from
different nodes, potentially causing congestion.
[I-D.eggert-core-congestion-control] suggests to conservatively
control sending multicast request.
Various means can be implemented to prevent congestion.
Currently in the CoAP protocol, the MAX_RETRANSMIT value is set to 5
by default. It is suggested that two values are used separately for
retransmissions, one for unicast transmission between a single source
and sink. The current value of 5 is used for such transmission.
Another constant is defined for multicast or group communication.
The retransmission value for group transmission should be much lower,
such as 1.
3.2. Overlay Multicast
We define overlay multicast as one that utilizes an infrastructure
based on proxies (rather than an IP router based multicast backbone)
to deliver IP multicast packets to end devices. MLD [RFC3810] has
been selected as the basis for multicast support by the ROLL routing
protocol . Therefore, it is proposed that "IGMP/MLD Proxying"
[RFC4605] be used as an overlay multicast solution for CoAP.
Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an
MLD Proxy function. All CoAP devices that want to join a given IP
Rahman Expires September 10, 2011 [Page 8]
Internet-Draft Group Communication for CoAP March 2011
multicast group would then send an MLD Join to the CoAP (MLD) proxy.
Thereafter, the CoAP (MLD) proxy would be responsible for delivering
any IP multicast message to the subscribed CoAP devices.
Note that the CoAP (MLD) proxy may or may not be connected to an
external multicast backbone. The key function for the CoAP (MLD)
proxy is to distribute CoAP generated multicast packets even in the
absence of router support for multicast.
4. CoAP Application Group Management
Constrained devices can be large in number, but highly correlated to
each other. For example, all the light switches in a building may
belong to one group and all the thermostats belong to another group.
All the smart meters in the same region can belong to one group as
well. Groups may be composed by function; for example, the group
"all lights in building one" may consist of the groups "all lights on
floor one of building one", "all lights on floor two of building
one", etc. Groups may be configured or dynamically formed.
The CoAP protocol needs to support CoAP group management features
independently of any underlying IP multicast support. For example, a
constrained node needs to be able to specify which group it intends
to join using a CoAP request by providing the group address.
The CoAP Proxy node would be responsible for group membership
management. It is proposed that CoAP supports two Header Options for
group "join" and "leave". These Options are Elective so they should
be assigned an even number. Assuming the Type for "join" is x (value
TBD), the Header Options are illustrated by the table in Figure 1:
+------+-----+---------------+--------------+--------+--------------+
| Type | C/E | Name | Data type | Length | Default |
|------+-----+---------------+--------------+--------+--------------+
| | | ... current Option Headers |.. | |
| | | | | |
| x | E | Group Join | String | 1-270 | "" |
| | | | | B | |
| x+2 | E | Group Leave | String | 1-270 | "" |
| | | | | B | |
+------+-----|---------------+--------------+--------+--------------+
Figure 1: CoAP Header Options for Group Management
Rahman Expires September 10, 2011 [Page 9]
Internet-Draft Group Communication for CoAP March 2011
Figure 2 illustrates how a node can join or leave a group using the
Header Options in a CoAP message:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | OC | Code | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delta |length | Join Group A (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |length | Join Group B (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |length | Leave Group C (ID or URI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CoAP Message for Group Management
Header Fields for the above example:
Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by
implementation as defined by the CoAP specification.
T: 2-bit unsigned integer for CoAP Transaction Type. Either '0'
Confirmation or '1' Non-Confirmable can be used for group "join" or
"leave" request.
OC: 4-bit unsigned integer for Option Count. For this example, the
value should be "3" since there are three option fields.
Code: 8-bit unsigned integer to indicate the Method in a Request or a
Response Code in a Response message. Any Code can be used so the
group management can be piggy-backed in either Request or Response
message.
Transaction ID: 16-bit unsigned integer assigned by the source to
uniquely identify a pair of Request and Response.
CoAP defined a delta encoding for header options. The first delta is
the "Type" for group join in this specific example. If the type for
group join is x as illustrated in Figure 1, delta will be x. In the
second header option, it is also a group join so the delta is 0. The
third header option is a group leave so the delta is 2.
Rahman Expires September 10, 2011 [Page 10]
Internet-Draft Group Communication for CoAP March 2011
5. Alternate Group Transmission Methods
5.1. Serial Unicast
Unicast can also be used for the transmission of group messages.
When unicast is used, no IP multicast address is provided by the
application. Instead, the group URI must be expanded into unicast
addresses.
6. CoAP Multicast and HTTP Unicast Interworking
Within the constrained network, CoAP runs over UDP for which IP
multicast is supported. In a non-constrained network (i.e. general
Internet), HTTP over TCP is used for which IP multicast is not
supported. Therefore the proxy node needs to have functionalities to
support interworking of unicast and multicast as illustrated in
Figure 3:
Rahman Expires September 10, 2011 [Page 11]
Internet-Draft Group Communication for CoAP March 2011
CoAP CoAP CoAP/HTTP HTTP
Node 1 Node 2 Proxy Node 3
| | | |
| REQUEST | | |
| (Group Join) | | |
|-----------------|------------- >| |
| RESPONSE | | |
|< ---------------|---------------| |
| | | |
| | REQUEST | |
| | (Group Join) | |
| |------------- >| |
| | RESPONSE | |
| |< -------------| |
| | | |
| | | |
| | | HTTP REQUEST |
| | | (to unicast addr) |
| | |< -----------------|
| | | |
| | map destination |
| | to multicast address |
| | | |
| REQUEST (to multicast addr) | |
| |< -------------| |
|< ---------------|---------------| |
| | | |
| (optional) RESPONSE | |
| |------------- >| |
|-----------------|-------------->| |
| | | HTTP RESPONSE |
| | |----------------- >|
| | | |
Figure 3: CoAP Multicast and HTTP Unicast Interworking
Note that Figure 3 illustrates the case of IP multicast as the
underlying group communications mechanism. However the overlay
multicast (Section 3.2) or CoAP application group communication
(Section 4) can be used as the underlying mechanism and the
principles of the figure would still apply (i.e. CoAP proxy needs to
do interworking between HTTP unicast and CoAP multicast).
A key point in Figure 3 is that the incoming HTTP request will carry
a URI (with the HTTP scheme) that resolves in the general Internet to
the proxy node. At the proxy node, the URI will then be again
resolved (with the CoAP scheme) to an IP multicast destination. This
Rahman Expires September 10, 2011 [Page 12]
Internet-Draft Group Communication for CoAP March 2011
may be performed, for example, by using DNS-SD (Section 3.1.3).
7. Security Considerations
Security for group communications at the IP level has been studied
extensively in the IETF MSEC (Multicast Security) WG, and to a lesser
extent in the IRTF SAMRG (Scalable Adaptive Multicast Research
Group). In particular, [RFC3740], [RFC5374] and [RFC4046] are very
instructive. The following requirements for securing group
communications in CoAP were derived from a study of these previous
investigations as well as understanding of CoAP specific needs:
REQ1- Group communications data encryption: Important CoAP group
communications shall be encrypted (using a group key) to preserve
confidentiality. It shall also be possible to send CoAP group
communications in the clear (i.e. unencrypted) for low value data.
REQ2- Group communications source data authentication: Important CoAP
group communications shall be authenticated by verifying the source
of the data (i.e. that it was generated by a given and trusted group
member). It shall also be possible to send unauthenticated CoAP
group communications for low value data.
REQ3- Group communications limited data authentication: Less
important CoAP group communications shall be authenticated by simply
verifying that it originated from one of the group members (i.e.
without explicitly identifying the source node). This is a weaker
requirement (but simpler to implement) than REQ2. It shall also be
possible to send unauthenticated CoAP group communications for low
value data.
REQ4- Group key management: There shall be a secure mechanism to
manage the cryptographic keys (e.g. generation and distribution)
belonging to the group; the state (e.g. current membership)
associated with the keys; and other security parameters.
REQ5- Use of Multicast IPSec: The CoAP protocol [I-D.ietf-core-coap]
allows IPSec to be used as one option to secure CoAP. If IPSec is
used at the CoAP level, then multicast IPSec [RFC5374] should be used
for securing CoAP group communications.
REQ6- Independence from underlying routing security: CoAP group
communication security shall not be tied to the security of
underlying routing and distribution protocols such as PIM [RFC4601]
and ROLL [I-D.ietf-roll-rpl]. Insecure or inappropriate routing
(including multicast routing) may cause loss of data to CoAP but will
not affect the authenticity or secrecy of CoAP group communications.
Rahman Expires September 10, 2011 [Page 13]
Internet-Draft Group Communication for CoAP March 2011
REQ7- Interaction with HTTPS: The security scheme for CoAP group
communications shall account for the fact that it may need to
interact with HTTPS (Hypertext Transfer Protocol Secure) when a
transaction involves a node in the general Internet (non-constrained
network).
8. IANA Considerations
This document makes no request of IANA.
9. Conclusions
Consider the proposals for group communication described in this
draft for incorporation into the overall CoAP protocol specification.
10. Acknowledgements
Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo
Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach
Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful
comments and discussions that have helped shape this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
Rahman Expires September 10, 2011 [Page 14]
Internet-Draft Group Communication for CoAP March 2011
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010.
11.2. Informative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-10 (work in
progress), February 2011.
[I-D.eggert-core-congestion-control]
Eggert, L., "Congestion Control for the Constrained
Application Protocol (CoAP)",
draft-eggert-core-congestion-control-01 (work in
progress), January 2011.
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in Low Power and Lossy Networks (6LoWPAN)",
draft-ietf-6lowpan-hc-15 (work in progress),
February 2011.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-04 (work in progress), January 2011.
[I-D.ietf-core-link-format]
Rahman Expires September 10, 2011 [Page 15]
Internet-Draft Group Communication for CoAP March 2011
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-02 (work in progress),
December 2010.
[I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-02 (work in progress),
October 2010.
[I-D.vanderstok-core-bc]
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-02 (work in progress),
October 2010.
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-18 (work in
progress), February 2011.
[ID.goland-http-udp]
Goland, Y., "Multicast and Unicast UDP HTTP Messages",
1999,
<http://tools.ietf.org/html/draft-goland-http-udp-01>.
[STUDY1] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A
Comparative Study of Multicast Protocols: Top, Bottom, or
In the Middle?", 2005, <http://www.cs.ucla.edu/NRL/hpi/
AggMC/papers/comparison_gi_2005.pdf>.
[STUDY2] Banerjee, B. and B. Bhattacharjee, "A Comparative Study of
Application Layer Multicast Protocols", 2001, <http://
wmedia.grnet.gr/P2PBackground/
a-comparative-study-ofALM.pdf>.
Author's Address
Akbar Rahman (editor)
InterDigital Communications, LLC
Email: Akbar.Rahman@InterDigital.com
Rahman Expires September 10, 2011 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 19:52:02 |