draft-ietf-roll-ccast-00.txt   draft-ietf-roll-ccast-01.txt 
Network Working Group O. Bergmann Roll Working Group O. Bergmann
Internet-Draft C. Bormann Internet-Draft C. Bormann
Intended status: Standards Track S. Gerdes Intended status: Standards Track S. Gerdes
Expires: September 11, 2017 Universitaet Bremen TZI Expires: May 3, 2018 Universitaet Bremen TZI
H. Chen H. Chen
Huawei Technologies Huawei Technologies
March 10, 2017 October 30, 2017
Constrained-Cast: Source-Routed Multicast for RPL Constrained-Cast: Source-Routed Multicast for RPL
draft-ietf-roll-ccast-00 draft-ietf-roll-ccast-01
Abstract Abstract
This specification defines a protocol for forwarding multicast This specification defines a protocol for forwarding multicast
traffic in a constrained node network employing the RPL routing traffic in a constrained node network employing the RPL routing
protocol in non-storing mode. protocol in non-storing mode.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 September 11, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The BIER Approach . . . . . . . . . . . . . . . . . . . . . . 3 2. The BIER Approach . . . . . . . . . . . . . . . . . . . . . . 3
3. The Constrained-Cast Approach . . . . . . . . . . . . . . . . 3 3. The Constrained-Cast Approach . . . . . . . . . . . . . . . . 3
4. False Positives . . . . . . . . . . . . . . . . . . . . . . . 4 4. False Positives . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Multicast Listener Advertisement Object (MLAO) . . . . . 4 5.1. Multicast Listener Advertisement Object (MLAO) . . . . . 4
5.2. Routing Header . . . . . . . . . . . . . . . . . . . . . 5 5.2. Routing Header . . . . . . . . . . . . . . . . . . . . . 5
6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 7
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9.1. ICMPv6 Parameter Registration . . . . . . . . . . . . . . 7 9.1. ICMPv6 Parameter Registration . . . . . . . . . . . . . . 8
9.2. IPv6 Routing Type Registration . . . . . . . . . . . . . 7 9.2. Critical 6LowPAN Routing Header Type Registration . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
As defined in [RFC6550], RPL Multicast assumes that the RPL network As defined in [RFC6550], RPL Multicast assumes that the RPL network
operates in Storing Mode. Multicast DAOs are used to indicate operates in Storing Mode. Multicast DAOs are used to indicate
subscription to multicast address to a parent; these DAOs percolate subscription to multicast address to a parent; these DAOs percolate
up and create bread-crumbs. This specification, although part of RFC up and create bread-crumbs. This specification, although part of RFC
6550, appears to be incomplete and untested. More importantly, 6550, appears to be incomplete and untested. More importantly,
Storing Mode is not in use in constrained node networks outside Storing Mode is not in use in constrained node networks outside
skipping to change at page 3, line 16 skipping to change at page 3, line 16
reach known multicast listeners. reach known multicast listeners.
Including an actual list of outgoing interfaces is rarely applicable, Including an actual list of outgoing interfaces is rarely applicable,
as this is likely to be a large list of 16-byte IPv6 addresses. Even as this is likely to be a large list of 16-byte IPv6 addresses. Even
with [RFC6554] style compression, the size of the list becomes with [RFC6554] style compression, the size of the list becomes
prohibitively quickly. prohibitively quickly.
1.1. Terminology 1.1. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In this specification, the term "byte" is used in its now customary In this specification, the term "byte" is used in its now customary
sense as a synonym for "octet". sense as a synonym for "octet".
All multi-byte integers in this protocol are interpreted in network All multi-byte integers in this protocol are interpreted in network
byte order. byte order.
2. The BIER Approach 2. The BIER Approach
Bit-Indexed Explicit Replication [I-D.ietf-bier-architecture] lists Bit-Indexed Explicit Replication [I-D.ietf-bier-architecture] lists
skipping to change at page 5, line 36 skipping to change at page 5, line 36
upwards the routing tree. upwards the routing tree.
Note: It has been suggested to use the RPL Transit Option (Type Note: It has been suggested to use the RPL Transit Option (Type
0x06) instead as it is used in Non-Storing mode to inform the 0x06) instead as it is used in Non-Storing mode to inform the
DODAG root of path attributes. Specifically, this option can be DODAG root of path attributes. Specifically, this option can be
used to limit the subscription by providing a proper Path used to limit the subscription by providing a proper Path
Lifetime. Lifetime.
5.2. Routing Header 5.2. Routing Header
0 1 2 3 This specification uses a new Soure Routing 6LowPAN Routing Header
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 (SRH-6LoRH) type [RFC8138] to convey the Bloom filter that describes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the source route for the IPv6 multicast packet to take within the RPL
| Next Header | Hdr Ext Len | Routing Type | Segments Left | routing tree. The 6LoRH Type for this Constrained Cast Routing
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header (CCRH) is set to TBD7. Figure 2 depicts the format of this
| Sequence Number | Func set | Modulus | new routing header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0 1 2 3
. . 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
. Filter data . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . |1|0|0|rsv|BSize| 6LoRH Type 7 | Func set | Modulus |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Filter data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Routing header Figure 2: Routing header
Routing Type: {IANA TBD2} 253 rsv: This field is reserved for future use an MUST be set to 0 when
Segments Left: This value is always 0, so network nodes that do not sending a packet containing a CCRH. A receiver MUST ignore the
support this routing header do not generate ICMP6 error messages. value of the rsv field.
Sequence Number: 16 bits sequence number. The number space is BSize: Specifies the size of the included Bloom filter. Currently,
unique for a sequence of multicast datagrams for a specific group only 64 bits, 128 bits, or 256 bits are supported. The BSize
that arrive at the DAG root on their way up. The DAG root field is encoded as specified in Table 1.
increments the number for each datagram it sends down the
respective DODAG. +-------------+--------------------+
| BSize value | Filter Size (Bits) |
+-------------+--------------------+
| 0 | 64 |
| 1 | 128 |
| 2 | 256 |
+-------------+--------------------+
Table 1: Possible Bloom Filter Lengths
Func set: The set of hash functions used to generate the Filter data Func set: The set of hash functions used to generate the Filter data
value. value.
Note: As the function set contains a combination of several distinct Note: As the function set contains a combination of several distinct
hash functions, it is currently unclear if 8 bits number space is hash functions, it is currently unclear if 8 bits number space is
large enough. large enough.
Modulus: The modulus that is used by the hash functions, minus 64 Modulus: The modulus that is used by the hash functions, minus 64
(the minimum filter data size that can be used). The DAG root (the minimum filter data size that can be used). The DAG root
chooses the modulus (and thus the filter data size) to achieve its chooses the modulus (and thus the filter data size) to achieve its
objectives for false positive rates (Section 4). objectives for false positive rates (Section 4).
Sequence Number: 32 bits sequence number. The number space is
unique for a sequence of multicast datagrams for a specific group
that arrive at the DAG root on their way up. The DAG root
increments the number for each datagram it sends down the
respective DODAG.
Filter data: A bit field that indicates which nodes should relay Filter data: A bit field that indicates which nodes should relay
this multicast datagram. The length of this field is a multiple this multicast datagram. The length of this field is a multiple
of 8 bytes. The actual length is derived from the contents of the of 8 bytes (2^(BSize + 3) bytes). The actual length is derived
field Header Ext Length. from the contents of the field BSize.
Note: The modulus could be derived from the length of the filter data
which is known from the extension header size. On the other hand,
keeping a separate record of the modulus means that the DAG root
could leave out 8-byte multiples of trailing zero bits if they happen
to occur. But then, a modulus that leaves 8-byte sequences of zero
bits in the filter is probably too large.
6. Implementation 6. Implementation
In 2013, Constrained-Cast was implemented in Contiki. It turns out In 2013, Constrained-Cast was implemented in Contiki. It turns out
that forwarders can compute the hash functions once for their that forwarders can compute the hash functions once for their
outgoing interfaces and then cache them, simply bit-matching their outgoing interfaces and then cache them, simply bit-matching their
outgoing interface hash bits against the bloom filter in the packet outgoing interface hash bits against the bloom filter in the packet
(a match is indicated when all bits in the outgoing interface hash (a match is indicated when all bits in the outgoing interface hash
are set in the bloom filter). are set in the bloom filter).
skipping to change at page 7, line 31 skipping to change at page 8, line 11
8. Security Considerations 8. Security Considerations
TODO TODO
9. IANA Considerations 9. IANA Considerations
The following registrations are done following the procedure The following registrations are done following the procedure
specified in [RFC6838]. specified in [RFC6838].
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and "IANA TBD1" with the with the RFC number of this specification and "TBD1" with the code
code selected for TBD1 below and "IANA TBD2" with the value selected selected for TBD1 below and "TBD7" with the code selected for TBD7.
for TBD2 below.
9.1. ICMPv6 Parameter Registration 9.1. ICMPv6 Parameter Registration
IANA is requested to add the following entry to the Code fields of IANA is requested to add the following entry to the Code fields of
the RPL Control Codes registry: the RPL Control Codes registry:
+------+------+------------+ +------+------+------------+
| Code | Name | Reference | | Code | Name | Reference |
+------+------+------------+ +------+------+------------+
| TBD1 | MLAO | [RFC-XXXX] | | TBD1 | MLAO | [RFC-XXXX] |
+------+------+------------+ +------+------+------------+
9.2. IPv6 Routing Type Registration 9.2. Critical 6LowPAN Routing Header Type Registration
IANA is requested to add the following entries to the IPv6 Routing IANA is requested to add the following entries to the Critical
Types registry: 6LowPAN Routing Header Type Registration registry:
+-------+----------------------+------------+ +-------+----------------------+------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+----------------------+------------+ +-------+----------------------+------------+
| TBD2 | CCast Routing Header | [RFC-XXXX] | | TBD7 | CCast Routing Header | [RFC-XXXX] |
+-------+----------------------+------------+ +-------+----------------------+------------+
10. Acknowledgments 10. Acknowledgments
Thanks to Yasuyuki Tanaka for valuable comments. Thanks to Yasuyuki Tanaka for valuable comments.
This work has been supported by Siemens Corporate Technology. This work has been supported by Siemens Corporate Technology.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6550>. editor.org/info/rfc6550>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[BLOOM] Bloom, B., "Space/time trade-offs in hash coding with [BLOOM] Bloom, B., "Space/time trade-offs in hash coding with
allowable errors", ISSN 0001-0782, ACM allowable errors", ISSN 0001-0782, ACM
Press Communications of the ACM vol 13 no 7 pp 422-426, Press Communications of the ACM vol 13 no 7 pp 422-426,
1970, <http://doi.acm.org/10.1145/362686.362692>. 1970, <http://doi.acm.org/10.1145/362686.362692>.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-05 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), October 2016. progress), September 2017.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6554>. editor.org/info/rfc6554>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
Authors' Addresses Authors' Addresses
Olaf Bergmann Olaf Bergmann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63904 Phone: +49-421-218-63904
Email: bergmann@tzi.org Email: bergmann@tzi.org
Carsten Bormann Carsten Bormann
 End of changes. 24 change blocks. 
59 lines changed or deleted 82 lines changed or added

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