idnits 2.17.1 draft-ietf-roll-ccast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2017) is 2604 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-XXXX' is mentioned on line 334, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Bergmann 3 Internet-Draft C. Bormann 4 Intended status: Standards Track S. Gerdes 5 Expires: September 11, 2017 Universitaet Bremen TZI 6 H. Chen 7 Huawei Technologies 8 March 10, 2017 10 Constrained-Cast: Source-Routed Multicast for RPL 11 draft-ietf-roll-ccast-00 13 Abstract 15 This specification defines a protocol for forwarding multicast 16 traffic in a constrained node network employing the RPL routing 17 protocol in non-storing mode. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 11, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The BIER Approach . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Constrained-Cast Approach . . . . . . . . . . . . . . . . 3 57 4. False Positives . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Multicast Listener Advertisement Object (MLAO) . . . . . 4 60 5.2. Routing Header . . . . . . . . . . . . . . . . . . . . . 5 61 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. ICMPv6 Parameter Registration . . . . . . . . . . . . . . 7 66 9.2. IPv6 Routing Type Registration . . . . . . . . . . . . . 7 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 11.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 As defined in [RFC6550], RPL Multicast assumes that the RPL network 76 operates in Storing Mode. Multicast DAOs are used to indicate 77 subscription to multicast address to a parent; these DAOs percolate 78 up and create bread-crumbs. This specification, although part of RFC 79 6550, appears to be incomplete and untested. More importantly, 80 Storing Mode is not in use in constrained node networks outside 81 research operating environments. 83 The present specification addresses multicast forwarding for RPL 84 networks in the much more common Non-Storing Mode. Non-Storing is 85 based on the root node adding source-routing information to downward 86 packets. Evidently, to make this work, RPL multicast needs to 87 source-route multicast packets. A source route here is a list of 88 identifiers to instruct forwarders to relay the respective IP 89 datagram. 91 As every forwarder in an IP-based constrained node network has at 92 least one network interface, it is straight-forward to use the 93 address of an outgoing interface as identifiers in this source-route. 94 (Typically, this is a globally unique public address of the node's 95 only network adapter.) 96 The source-route subsets the whole set of potential forwarders 97 available in the RPL DODAG to those that need to forward in order to 98 reach known multicast listeners. 100 Including an actual list of outgoing interfaces is rarely applicable, 101 as this is likely to be a large list of 16-byte IPv6 addresses. Even 102 with [RFC6554] style compression, the size of the list becomes 103 prohibitively quickly. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 In this specification, the term "byte" is used in its now customary 112 sense as a synonym for "octet". 114 All multi-byte integers in this protocol are interpreted in network 115 byte order. 117 2. The BIER Approach 119 Bit-Indexed Explicit Replication [I-D.ietf-bier-architecture] lists 120 all egress routers in a bitmap included in each multicast packet. 121 This requires creating a mostly contiguous numbering of all egress 122 routers; more importantly, BIER requires the presence of a network 123 map in each forwarders to be able to interpret the bitmap and map it 124 to a set of local outgoing interfaces. 126 3. The Constrained-Cast Approach 128 Constrained-Cast employs Bloom Filters [BLOOM] as a compact 129 representation of a match or non-match for elements in a large set: 130 Each element to be included is hashed with multiple hash functions; 131 the result is used to index a bitmap and set the corresponding bit. 132 To check for the presence of an element, the same hash functions are 133 applied to obtain bit positions; if all corresponding bits are set, 134 this is used to indicate a match. (Multiple hash functions are most 135 easily obtained by adding a varying seed value to a single hash 136 algorithm.) 138 By including a bloom filter in each packet that matches all outgoing 139 interfaces that need to forward the packet, each forwarder can 140 efficiently decide whether (and on which interfaces) to forward the 141 packet. 143 4. False Positives 145 Bloom filters are probabilistic. A false positive might be 146 indicating a match where the bits are set by aliasing of the hash 147 values. In case of Constrained-Cast, this causes spurious 148 transmission and wastes some energy and radio bandwidth. However, 149 there is no semantic damage (hosts still filter out unneeded 150 multicasts). The total waste in energy and spectrum can be 151 visualized as the false-positive-rate multiplied by the density of 152 the RPL network. A network can easily live with a significant 153 percentage of false positives. By changing the set of hash functions 154 (i.e., seed) over time, the root can avoid a single node with a false 155 positive to become an unnecessary hotspot for that multicast group. 157 5. Protocol 159 The protocol uses DAO-like "MLAO" messages to announce membership to 160 the root as specified in Section 5.1. 162 For downward messages, the root adds a new routing header that 163 includes a hash function identifier and a seed value; another one of 164 its fields gives the number of hash functions (k) to ask for k 165 instances of application of the hash function, with increasing seed. 166 The format of the new routing header is specified in Section 5.2. 168 Typical sizes of the bloom filter bitmap that the root inserts into 169 the packet can be 64, 128, or 256 bit, which may lead to acceptable 170 false positive rates if the total number of forwarders in the 10s and 171 100s. (To do: write more about the math here. Note that this number 172 tallies forwarding routers, not end hosts.) 174 A potential forwarder that receives a multicast packet adorned with a 175 constrained-cast routing header first checks that the packet is 176 marked with a RPL rank smaller than its own (loop prevention). If 177 yes, it then forwards the packet to all outgoing interfaces that 178 match the bloom filter in the packet. 180 5.1. Multicast Listener Advertisement Object (MLAO) 182 The header format of the MLAO is depicted in Figure 1. The basic 183 structure of the MLAO message is similar to the RPL Destination 184 Advertisement Object (DAO). In particular, it starts with RPL ICMP 185 base header with a type value of 155 and the code {IANA TBD1} (MLAO), 186 followed by the Checksum, RPLInstanceID, parameters and flags as in a 187 DAO. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type = 0x05 | Option Length | Reserved | Prefix Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 + + 196 | Group Address | 197 . . 198 . . 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: RPL Target Option for MLAO 203 The group address field indicates the group that the sender of the 204 MLAO is interested in. This field usually contains a 128 bit IPv6 205 multicast group address. Shorter group identifiers could be used 206 together with a protocol for explicit creation of groups. The MLAO 207 message must have at least one RPL target option to specify the 208 address of the listener that has generated the MLAO. The message is 209 directed to the global unicast address of the DODAG root and travels 210 upwards the routing tree. 212 Note: It has been suggested to use the RPL Transit Option (Type 213 0x06) instead as it is used in Non-Storing mode to inform the 214 DODAG root of path attributes. Specifically, this option can be 215 used to limit the subscription by providing a proper Path 216 Lifetime. 218 5.2. Routing Header 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Sequence Number | Func set | Modulus | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 . . 229 . Filter data . 230 . . 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: Routing header 236 Routing Type: {IANA TBD2} 253 237 Segments Left: This value is always 0, so network nodes that do not 238 support this routing header do not generate ICMP6 error messages. 240 Sequence Number: 16 bits sequence number. The number space is 241 unique for a sequence of multicast datagrams for a specific group 242 that arrive at the DAG root on their way up. The DAG root 243 increments the number for each datagram it sends down the 244 respective DODAG. 246 Func set: The set of hash functions used to generate the Filter data 247 value. 249 Note: As the function set contains a combination of several distinct 250 hash functions, it is currently unclear if 8 bits number space is 251 large enough. 253 Modulus: The modulus that is used by the hash functions, minus 64 254 (the minimum filter data size that can be used). The DAG root 255 chooses the modulus (and thus the filter data size) to achieve its 256 objectives for false positive rates (Section 4). 258 Filter data: A bit field that indicates which nodes should relay 259 this multicast datagram. The length of this field is a multiple 260 of 8 bytes. The actual length is derived from the contents of the 261 field Header Ext Length. 263 Note: The modulus could be derived from the length of the filter data 264 which is known from the extension header size. On the other hand, 265 keeping a separate record of the modulus means that the DAG root 266 could leave out 8-byte multiples of trailing zero bits if they happen 267 to occur. But then, a modulus that leaves 8-byte sequences of zero 268 bits in the filter is probably too large. 270 6. Implementation 272 In 2013, Constrained-Cast was implemented in Contiki. It turns out 273 that forwarders can compute the hash functions once for their 274 outgoing interfaces and then cache them, simply bit-matching their 275 outgoing interface hash bits against the bloom filter in the packet 276 (a match is indicated when all bits in the outgoing interface hash 277 are set in the bloom filter). 279 The Root computes the tree for each multicast group, computes the 280 bloom filter for it, caches these values, and then simply adds the 281 bloom filter routing header to each downward packet. For adding a 282 new member, the relevant outgoing interfaces are simply added to the 283 bloom filter. For removing a leaving member, however, the bloom 284 filter needs to be recomputed (which can be sped up logarithmically 285 if desired). 287 7. Benefits 289 Constrained-Cast: 291 o operates in Non-Storing Mode, with the simple addition of a 292 membership information service; 294 o performs all routing decisions at the root. 296 Further optimizations might include using a similar kind of bloom 297 filter routing header for unicast forwarding as well (representing, 298 instead of the outgoing interface list, a list of children that 299 forwarding parents need to forward to). 301 8. Security Considerations 303 TODO 305 9. IANA Considerations 307 The following registrations are done following the procedure 308 specified in [RFC6838]. 310 Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" 311 with the RFC number of this specification and "IANA TBD1" with the 312 code selected for TBD1 below and "IANA TBD2" with the value selected 313 for TBD2 below. 315 9.1. ICMPv6 Parameter Registration 317 IANA is requested to add the following entry to the Code fields of 318 the RPL Control Codes registry: 320 +------+------+------------+ 321 | Code | Name | Reference | 322 +------+------+------------+ 323 | TBD1 | MLAO | [RFC-XXXX] | 324 +------+------+------------+ 326 9.2. IPv6 Routing Type Registration 328 IANA is requested to add the following entries to the IPv6 Routing 329 Types registry: 331 +-------+----------------------+------------+ 332 | Value | Name | Reference | 333 +-------+----------------------+------------+ 334 | TBD2 | CCast Routing Header | [RFC-XXXX] | 335 +-------+----------------------+------------+ 337 10. Acknowledgments 339 Thanks to Yasuyuki Tanaka for valuable comments. 341 This work has been supported by Siemens Corporate Technology. 343 11. References 345 11.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 353 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 354 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 355 Low-Power and Lossy Networks", RFC 6550, 356 DOI 10.17487/RFC6550, March 2012, 357 . 359 11.2. Informative References 361 [BLOOM] Bloom, B., "Space/time trade-offs in hash coding with 362 allowable errors", ISSN 0001-0782, ACM 363 Press Communications of the ACM vol 13 no 7 pp 422-426, 364 1970, . 366 [I-D.ietf-bier-architecture] 367 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 368 S. Aldrin, "Multicast using Bit Index Explicit 369 Replication", draft-ietf-bier-architecture-05 (work in 370 progress), October 2016. 372 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 373 Routing Header for Source Routes with the Routing Protocol 374 for Low-Power and Lossy Networks (RPL)", RFC 6554, 375 DOI 10.17487/RFC6554, March 2012, 376 . 378 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 379 Specifications and Registration Procedures", BCP 13, 380 RFC 6838, DOI 10.17487/RFC6838, January 2013, 381 . 383 Authors' Addresses 385 Olaf Bergmann 386 Universitaet Bremen TZI 387 Postfach 330440 388 Bremen D-28359 389 Germany 391 Phone: +49-421-218-63904 392 Email: bergmann@tzi.org 394 Carsten Bormann 395 Universitaet Bremen TZI 396 Postfach 330440 397 Bremen D-28359 398 Germany 400 Phone: +49-421-218-63921 401 Email: cabo@tzi.org 403 Stefanie Gerdes 404 Universitaet Bremen TZI 405 Postfach 330440 406 Bremen D-28359 407 Germany 409 Phone: +49-421-218-63906 410 Email: gerdes@tzi.org 412 Hao Chen 413 Huawei Technologies 414 12, E. Mozhou Rd 415 Nanjing 211111 416 China 418 Phone: +86-25-5662-7052 419 Email: philips.chenhao@huawei.com