idnits 2.17.1 draft-thubert-6lo-bier-dispatch-02.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 (January 24, 2017) is 2648 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: 'RFCthis' is mentioned on line 284, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-06) exists of draft-eckert-bier-te-arch-04 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-10 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-05 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track Z. Brodard 5 Expires: July 28, 2017 Ecole Polytechnique 6 H. Jiang 7 G. Texier 8 Telecom Bretagne 9 January 24, 2017 11 A 6loRH for BitStrings 12 draft-thubert-6lo-bier-dispatch-02 14 Abstract 16 This specification extends the 6LoWPAN Routing Header to signal 17 BitStrings such as utilized in Bit Index Explicit Replication and its 18 Traffic Engineering variant. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 28, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. The BIER-6LoRH encoding . . . . . . . . . . . . . . . . . . . 4 58 4.1. The Bit-by-bit BitStrings . . . . . . . . . . . . . . . . 5 59 4.2. Bloom Filters . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Types of BIER-6LoRH header . . . . . . . . . . . . . . . 5 61 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The type of information that needs to be present in a packet inside 73 the LLN but not outside of the LLN varies with the routing operation, 74 but there is overall a need for an extensible compression technique 75 that would simplify the IP-in-IP encapsulation, when needed, and 76 optimally compress existing routing artifacts found in LLNs. 78 The 6LoWPAN Routing Header (6LoRH) [RFC8025] 79 [I-D.ietf-roll-routing-dispatch] is such a technique, that extends 80 the 6lo adaptation layer framework [RFC4944], [RFC6282] so as to 81 carry routing information for Route-over use cases. The original 82 specification includes the formats necessary for RPL such as the 83 Source Route Header (SRH) and is intended to be extended for 84 additional routing artifacts. 86 The Bit Index Explicit Replication (BIER), as introduced in the BIER 87 Architecture [I-D.ietf-bier-architecture], can be used as an 88 alternate artifact to route multicast as well as unicast traffic. 89 The Traffic Engineering for Bit Index Explicit Replication 90 [I-D.eckert-bier-te-arch] (BIER-TE) adds support for traffic 91 engineering by explicit hop-by-hop forwarding and loose hop 92 forwarding of packets along a unicast route. 94 This specification provides additional formats for the 6LoRH 95 compression to carry BitStrings such as used for Bit Index Explicit 96 Replication and its Traffic Engineering variant (BIER and BIER-TE, 97 respectively). 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 The Terminology used in this document is consistent with and 107 incorporates that described in Terms Used in Routing for Low-Power 108 and Lossy Networks (LLNs). [RFC7102]. 110 Other terms in use in LLNs are found in Terminology for Constrained- 111 Node Networks [RFC7228]. 113 The term "byte" is used in its now customary sense as a synonym for 114 "octet". 116 "RPL", "RPL Packet Information" (RPI) and "RPL Instance" are defined 117 in the RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 118 [RFC6550] specification. 120 The terms Bit-Forwarding Egress Routers (BFR), BFR-id and BitString 121 are defined in [I-D.ietf-bier-architecture]. A BitString indicates a 122 continuous sequence of bits indexed by an offset in the sequence. 123 The leftmost bit is bit 0 and corresponds to the value 0x80 of the 124 leftmost octet in the BitString. 126 3. Applicability 128 BIER and other bit-indexed methods that would leverage BitStrings 129 will generally require additional information in the packet to 130 complement the BitString. For instance, BIER has the concept of a 131 BFR-id and an Entropy value in the BIER header. Since those 132 additional fields depend on the bit-indexed method, they are expected 133 to be transported separately from the BitString. This specification 134 concentrates on the BitString alone. 136 Within the scope of Deterministic Networking 137 [I-D.ietf-detnet-architecture] (DetNet), the DetNet Data Plane 138 Protocol and Solution Alternatives [I-D.ietf-detnet-dp-alt] document 139 details how BIER-TE can be leveraged to activate the Deterministic 140 Networking Replication and Elimination functions in a manner that is 141 abstract to the data plane forwarding information. An adjacency, 142 which is represented by a bit in the BIER header, can be mapped in 143 the data plane to an Ethernet hop, a Label Switched Path, or it may 144 correspond to a loose or a strict IPv6 Source Routed Path. 146 In the context of LLNs, the 6TiSCH Architecture 147 [I-D.ietf-6tisch-architecture] introduces the concept of a Track that 148 is a directional traffic-engineered path between a source and a 149 destination. A Track is indicated in a packet by a Source or 150 Destination IPv6 Address and a RPL Local Instance. The RPL Instance 151 is carried in an IPv6 packet as part of the RPL Packet Information 152 (RPI), and a bit in the RPI indicates whether the Instance is Local 153 to the Source or the Destination Address. The RPI can be compressed 154 as a RPI 6LoRH header (RPI-6LoRH) as described in 155 [I-D.ietf-roll-routing-dispatch]. 157 The 6TiSCH requirements for DetNet [I-D.thubert-6tisch-4detnet] 158 indicate that a 6TiSCH Track may leverage replication and elimination 159 as defined in DetNet. This specification enables this behavior as 160 follows: if a BIER-6LoRH is positioned right after a RPI-6LoRH, then 161 the BitString in the BIER-6LoRH applies to the context of the Track 162 indicated by the source or destination address of the packet and the 163 local Instance ID associated to the source or destination of the 164 packet. 166 4. The BIER-6LoRH encoding 168 The BIER 6LoRH (BIER-6LoRH) is a Critical 6LoWPAN Routing Header that 169 provides a variable-size container for a BitString such as, a but not 170 limited to, a BIER BitString. 172 The capability to parse the BIER BitString is necessary to forward 173 the packet so the Type cannot be ignored. 175 0 1 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 178 |1|0|0| Control |6LoRHType 15-24| BitString | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 181 Figure 1: The BIER-6LoRH 183 This specification provides a 5-bit Control field that can be used to 184 encode information that is specific to the BitString. The type and 185 size of the BitString are encoded in the 6LoRHType. 187 4.1. The Bit-by-bit BitStrings 189 In the bit-by-bit case, each bit is mapped in an unequivocal fashion 190 with a single addressable resource in the network. This may rapidly 191 lead to large BitStrings, and BIER allows to divide a network into 192 groups that partition the network so that a given BitString is 193 locally significant to one group only. This specification uses the 194 5-bits Control field to encode the group. 196 When groups are used, it may be that a packet is sent to different 197 groups at the same time. In that case, multiple BIER-6LoRH headers 198 can be prepended to a same packet, each one for a different group. 199 As the packet flows along the multicast distribution tree, a BIER- 200 6LoRH header that has no more destination in a given branch may be 201 removed to make the packet shorter. 203 4.2. Bloom Filters 205 A Bloom Filter can be seen as a compression technique for the 206 BitString. A Bloom Filter may generate false positives, which, in 207 the case of BIER, result in undue forwarding of a packet down a path 208 where no listener exists. 210 As an example, the Constrained-Cast [I-D.bergmann-bier-ccast] 211 specification employs Bloom Filters as a compact representation of a 212 match or non-match for elements in a set that may be larger than the 213 number of bits in the BitString. 215 In the case of a Bloom Filter, a number of Hash functions must be run 216 to obtain a multi-bit signature of an encoded element. This 217 specification uses the 5-bits Control field to signal an Identifier 218 of the set of Hash functions being used to generate a certain 219 BitString, so as to enable the migration from a set of Hash functions 220 to the next. 222 4.3. Types of BIER-6LoRH header 224 The Type of a BIER-6LoRH header indicates the size of words used to 225 build the BitString and whether the BitString is operated as an 226 uncompressed bit-by-bit mapping, or as a Bloom filter. 228 +---------+--------------+----------------------+----------------+ 229 | Type | Encoding | Control field | BitString Size | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 231 | 15 | bit-by-bit | Group ID | 8 bits | 232 | 16 | bit-by-bit | Group ID | 16 bits | 233 | 17 | bit-by-bit | Group ID | 32 bits | 234 | 18 | bit-by-bit | Group ID | 64 bits | 235 | 19 | bit-by-bit | Group ID | 128 bits | 236 +---------+--------------+----------------------+----------------+ 237 | 20 | Bloom filter | Hash function Set ID | 8 bits | 238 | 21 | Bloom filter | Hash function Set ID | 16 bits | 239 | 22 | Bloom filter | Hash function Set ID | 32 bits | 240 | 23 | Bloom filter | Hash function Set ID | 64 bits | 241 | 24 | Bloom filter | Hash function Set ID | 128 bits | 242 +---------+--------------+----------------------+----------------+ 244 Figure 2: The BIER-6LoRH Types 246 In order to address a potentially large number of devices, the 247 BitString may grow very large. Yet, the maximum frame size for a 248 given MAC layer may limit the number of bits that can be dedicated to 249 routing. With this specification, a number of BIER-6LoRH headers of 250 a same type (bit-by-bit or Bloom filter) may be placed contiguously 251 in the packet. This results in a larger BitString that is the 252 concatenation of the BitStrings in the individual headers in the 253 order they are appearing in the packet. 255 5. Implementation Status 257 A research-stage implementation was developed at Cisco's Paris 258 Innovation Lab (PIRL) by Zacharie Brodard. It was implemented on 259 OpenWSN open-source firmware and tested on the OpenMote-CC2538 260 hardware. It implements the header types 15, 16, 17, 18 and 19 (bit- 261 by-bit encoding without group ID) in order to allow a BIER-TE 262 protocol over IEE802.15.4e. 264 Links: 266 github: https://github.com/zach-b/openwsn-fw/tree/BIER 268 OpenWSN firmware: https://openwsn.atlassian.net/wiki/pages/ 269 viewpage.action?pageId=688187 271 OpenMote hardware: http://www.openmote.com/ 273 6. Security Considerations 275 The security considerations of [I-D.ietf-roll-routing-dispatch] 276 apply. 278 7. IANA Considerations 280 This document extends the IANA registry created by 281 [I-D.ietf-roll-routing-dispatch] for the 6LoWPAN Routing Header Type, 282 and adds the following values: 284 15..24 : BIER-6LoRH [RFCthis] 286 8. Acknowledgments 288 9. References 290 9.1. Normative References 292 [I-D.ietf-roll-routing-dispatch] 293 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 294 "6LoWPAN Routing Header", draft-ietf-roll-routing- 295 dispatch-05 (work in progress), October 2016. 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 303 "Transmission of IPv6 Packets over IEEE 802.15.4 304 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 305 . 307 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 308 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 309 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 310 Low-Power and Lossy Networks", RFC 6550, 311 DOI 10.17487/RFC6550, March 2012, 312 . 314 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 315 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 316 2014, . 318 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 319 Constrained-Node Networks", RFC 7228, 320 DOI 10.17487/RFC7228, May 2014, 321 . 323 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 324 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 325 RFC 8025, DOI 10.17487/RFC8025, November 2016, 326 . 328 9.2. Informative References 330 [I-D.bergmann-bier-ccast] 331 Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, 332 "Constrained-Cast: Source-Routed Multicast for RPL", 333 draft-bergmann-bier-ccast-02 (work in progress), October 334 2016. 336 [I-D.eckert-bier-te-arch] 337 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 338 Engineering for Bit Index Explicit Replication BIER-TE", 339 draft-eckert-bier-te-arch-04 (work in progress), July 340 2016. 342 [I-D.ietf-6tisch-architecture] 343 Thubert, P., "An Architecture for IPv6 over the TSCH mode 344 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 345 in progress), June 2016. 347 [I-D.ietf-bier-architecture] 348 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 349 S. Aldrin, "Multicast using Bit Index Explicit 350 Replication", draft-ietf-bier-architecture-05 (work in 351 progress), October 2016. 353 [I-D.ietf-detnet-architecture] 354 Finn, N. and P. Thubert, "Deterministic Networking 355 Architecture", draft-ietf-detnet-architecture-00 (work in 356 progress), September 2016. 358 [I-D.ietf-detnet-dp-alt] 359 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 360 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 361 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 362 (work in progress), October 2016. 364 [I-D.thubert-6tisch-4detnet] 365 Thubert, P., "6TiSCH requirements for DetNet", draft- 366 thubert-6tisch-4detnet-01 (work in progress), June 2015. 368 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 369 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 370 DOI 10.17487/RFC6282, September 2011, 371 . 373 Authors' Addresses 375 Pascal Thubert (editor) 376 Cisco Systems 377 Village d'Entreprises Green Side 378 400, Avenue de Roumanille 379 Batiment T3 380 Biot - Sophia Antipolis 06410 381 FRANCE 383 Phone: +33 4 97 23 26 34 384 Email: pthubert@cisco.com 386 Zacharie Brodard 387 Ecole Polytechnique 388 Route de Saclay 389 Palaiseau 91128 390 FRANCE 392 Phone: +33 6 73 73 35 09 393 Email: zacharie.brodard@polytechnique.edu 395 Hao Jiang 396 Telecom Bretagne 397 2, rue de la Chataigneraie 398 Cesson-Sevigne 35510 399 FRANCE 401 Phone: +33 7 53 70 97 34 402 Email: hao.jiang@telecom-bretagne.eu 403 Geraldine Texier 404 Telecom Bretagne 405 2, rue de la Chataigneraie 406 Cesson-Sevigne 35510 407 FRANCE 409 Phone: +33 2 99 12 70 38 410 Email: geraldine.texier@telecom-bretagne.eu