idnits 2.17.1 draft-thubert-6lo-bier-dispatch-03.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 (July 24, 2017) is 2468 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 281, but not defined == Outdated reference: A later version (-06) exists of draft-eckert-bier-te-arch-05 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-07 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-02 == Outdated reference: A later version (-03) exists of draft-thubert-bier-replication-elimination-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: January 25, 2018 Ecole Polytechnique 6 H. Jiang 7 G. Texier 8 Telecom Bretagne 9 July 24, 2017 11 A 6loRH for BitStrings 12 draft-thubert-6lo-bier-dispatch-03 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 January 25, 2018. 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 . . . . . . . . . . . . . . . . 4 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] [RFC8138] is such a 79 technique, that extends the 6lo adaptation layer framework [RFC4944], 80 [RFC6282] so as to carry routing information for Route-over use 81 cases. The original specification includes the formats necessary for 82 RPL such as the Source Route Header (SRH) and is intended to be 83 extended for additional routing artifacts. 85 The Bit Index Explicit Replication (BIER), as introduced in the BIER 86 Architecture [I-D.ietf-bier-architecture], can be used as an 87 alternate artifact to route multicast as well as unicast traffic. 88 The Traffic Engineering for Bit Index Explicit Replication 89 [I-D.eckert-bier-te-arch] (BIER-TE) adds support for traffic 90 engineering by explicit hop-by-hop forwarding and loose hop 91 forwarding of packets along a unicast route. 93 This specification provides additional formats for the 6LoRH 94 compression to carry BitStrings such as used for Bit Index Explicit 95 Replication and its Traffic Engineering variant (BIER and BIER-TE, 96 respectively). 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [RFC2119]. 105 The Terminology used in this document is consistent with and 106 incorporates that described in Terms Used in Routing for Low-Power 107 and Lossy Networks (LLNs). [RFC7102]. 109 Other terms in use in LLNs are found in Terminology for Constrained- 110 Node Networks [RFC7228]. 112 The term "byte" is used in its now customary sense as a synonym for 113 "octet". 115 "RPL", "RPL Packet Information" (RPI) and "RPL Instance" are defined 116 in the RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 117 [RFC6550] specification. 119 The terms Bit-Forwarding Egress Routers (BFR), BFR-id and BitString 120 are defined in [I-D.ietf-bier-architecture]. A BitString indicates a 121 continuous sequence of bits indexed by an offset in the sequence. 122 The leftmost bit is bit 0 and corresponds to the value 0x80 of the 123 leftmost octet in the BitString. 125 3. Applicability 127 BIER and other bit-indexed methods that would leverage BitStrings 128 will generally require additional information in the packet to 129 complement the BitString. For instance, BIER has the concept of a 130 BFR-id and an Entropy value in the BIER header. Since those 131 additional fields depend on the bit-indexed method, they are expected 132 to be transported separately from the BitString. This specification 133 concentrates on the BitString alone. 135 Within the context of "the Deterministic Networking (DetNet) 136 Architecture" [I-D.ietf-detnet-architecture] ), the "BIER-TE-based 137 OAM, Replication and Elimination" 138 [I-D.thubert-bier-replication-elimination] document details how BIER- 139 TE can be leveraged to activate the Deterministic Networking 140 Replication and Elimination functions in a manner that is abstract to 141 the data plane forwarding information. An adjacency, which is 142 represented by a bit in the BIER header, can be mapped in the data 143 plane to an Ethernet hop, a Label Switched Path, or it may correspond 144 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 [RFC8138]. 156 The 6TiSCH requirements for DetNet [I-D.thubert-6tisch-4detnet] 157 indicate that a 6TiSCH Track may leverage replication and elimination 158 as defined in DetNet. This specification enables this behavior as 159 follows: if a BIER-6LoRH is positioned right after a RPI-6LoRH, then 160 the BitString in the BIER-6LoRH applies to the context of the Track 161 indicated by the source or destination address of the packet and the 162 local Instance ID associated to the source or destination of the 163 packet. 165 4. The BIER-6LoRH encoding 167 The BIER 6LoRH (BIER-6LoRH) is a Critical 6LoWPAN Routing Header that 168 provides a variable-size container for a BitString such as, a but not 169 limited to, a BIER BitString. 171 The capability to parse the BIER BitString is necessary to forward 172 the packet so the Type cannot be ignored. 174 0 1 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 177 |1|0|0| Control |6LoRHType 15-24| BitString | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 180 Figure 1: The BIER-6LoRH 182 This specification provides a 5-bit Control field that can be used to 183 encode information that is specific to the BitString. The type and 184 size of the BitString are encoded in the 6LoRHType. 186 4.1. The Bit-by-bit BitStrings 188 In the bit-by-bit case, each bit is mapped in an unequivocal fashion 189 with a single addressable resource in the network. This may rapidly 190 lead to large BitStrings, and BIER allows to divide a network into 191 groups that partition the network so that a given BitString is 192 locally significant to one group only. This specification uses the 193 5-bits Control field to encode the group. 195 When groups are used, it may be that a packet is sent to different 196 groups at the same time. In that case, multiple BIER-6LoRH headers 197 can be prepended to a same packet, each one for a different group. 198 As the packet flows along the multicast distribution tree, a BIER- 199 6LoRH header that has no more destination in a given branch may be 200 removed to make the packet shorter. 202 4.2. Bloom Filters 204 A Bloom Filter can be seen as a compression technique for the 205 BitString. A Bloom Filter may generate false positives, which, in 206 the case of BIER, result in undue forwarding of a packet down a path 207 where no listener exists. 209 As an example, the Constrained-Cast [I-D.bergmann-bier-ccast] 210 specification employs Bloom Filters as a compact representation of a 211 match or non-match for elements in a set that may be larger than the 212 number of bits in the BitString. 214 In the case of a Bloom Filter, a number of Hash functions must be run 215 to obtain a multi-bit signature of an encoded element. This 216 specification uses the 5-bits Control field to signal an Identifier 217 of the set of Hash functions being used to generate a certain 218 BitString, so as to enable the migration from a set of Hash functions 219 to the next. 221 4.3. Types of BIER-6LoRH header 223 The Type of a BIER-6LoRH header indicates the size of words used to 224 build the BitString and whether the BitString is operated as an 225 uncompressed bit-by-bit mapping, or as a Bloom filter. 227 +---------+--------------+----------------------+----------------+ 228 | Type | Encoding | Control field | BitString Size | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 230 | 15 | bit-by-bit | Group ID | 8 bits | 231 | 16 | bit-by-bit | Group ID | 16 bits | 232 | 17 | bit-by-bit | Group ID | 32 bits | 233 | 18 | bit-by-bit | Group ID | 64 bits | 234 | 19 | bit-by-bit | Group ID | 128 bits | 235 +---------+--------------+----------------------+----------------+ 236 | 20 | Bloom filter | Hash function Set ID | 8 bits | 237 | 21 | Bloom filter | Hash function Set ID | 16 bits | 238 | 22 | Bloom filter | Hash function Set ID | 32 bits | 239 | 23 | Bloom filter | Hash function Set ID | 64 bits | 240 | 24 | Bloom filter | Hash function Set ID | 128 bits | 241 +---------+--------------+----------------------+----------------+ 243 Figure 2: The BIER-6LoRH Types 245 In order to address a potentially large number of devices, the 246 BitString may grow very large. Yet, the maximum frame size for a 247 given MAC layer may limit the number of bits that can be dedicated to 248 routing. With this specification, a number of BIER-6LoRH headers of 249 a same type (bit-by-bit or Bloom filter) may be placed contiguously 250 in the packet. This results in a larger BitString that is the 251 concatenation of the BitStrings in the individual headers in the 252 order they are appearing in the packet. 254 5. Implementation Status 256 A research-stage implementation was developed at Cisco's Paris 257 Innovation Lab (PIRL) by Zacharie Brodard. It was implemented on 258 OpenWSN open-source firmware and tested on the OpenMote-CC2538 259 hardware. It implements the header types 15, 16, 17, 18 and 19 (bit- 260 by-bit encoding without group ID) in order to allow a BIER-TE 261 protocol over IEE802.15.4e. 263 Links: 265 github: https://github.com/zach-b/openwsn-fw/tree/BIER 267 OpenWSN firmware: https://openwsn.atlassian.net/wiki/pages/ 268 viewpage.action?pageId=688187 270 OpenMote hardware: http://www.openmote.com/ 272 6. Security Considerations 274 The security considerations of [RFC8138] apply. 276 7. IANA Considerations 278 This document extends the IANA registry created by [RFC8138] for the 279 6LoWPAN Routing Header Type, and adds the following values: 281 15..24 : BIER-6LoRH [RFCthis] 283 8. Acknowledgments 285 9. References 287 9.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 295 "Transmission of IPv6 Packets over IEEE 802.15.4 296 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 297 . 299 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 300 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 301 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 302 Low-Power and Lossy Networks", RFC 6550, 303 DOI 10.17487/RFC6550, March 2012, 304 . 306 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 307 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 308 RFC 8025, DOI 10.17487/RFC8025, November 2016, 309 . 311 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 312 "IPv6 over Low-Power Wireless Personal Area Network 313 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 314 April 2017, . 316 9.2. Informative References 318 [I-D.bergmann-bier-ccast] 319 Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, 320 "Constrained-Cast: Source-Routed Multicast for RPL", 321 draft-bergmann-bier-ccast-02 (work in progress), October 322 2016. 324 [I-D.eckert-bier-te-arch] 325 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 326 Engineering for Bit Index Explicit Replication BIER-TE", 327 draft-eckert-bier-te-arch-05 (work in progress), June 328 2017. 330 [I-D.ietf-6tisch-architecture] 331 Thubert, P., "An Architecture for IPv6 over the TSCH mode 332 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 333 in progress), January 2017. 335 [I-D.ietf-bier-architecture] 336 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 337 S. Aldrin, "Multicast using Bit Index Explicit 338 Replication", draft-ietf-bier-architecture-07 (work in 339 progress), June 2017. 341 [I-D.ietf-detnet-architecture] 342 Finn, N., Thubert, P., Varga, B., and J. Farkas, 343 "Deterministic Networking Architecture", draft-ietf- 344 detnet-architecture-02 (work in progress), June 2017. 346 [I-D.thubert-6tisch-4detnet] 347 Thubert, P., "6TiSCH requirements for DetNet", draft- 348 thubert-6tisch-4detnet-01 (work in progress), June 2015. 350 [I-D.thubert-bier-replication-elimination] 351 Thubert, P., Brodard, Z., and H. Jiang, "BIER-TE-based 352 OAM, Replication and Elimination", draft-thubert-bier- 353 replication-elimination-00 (work in progress), September 354 2016. 356 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 357 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 358 DOI 10.17487/RFC6282, September 2011, 359 . 361 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 362 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 363 2014, . 365 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 366 Constrained-Node Networks", RFC 7228, 367 DOI 10.17487/RFC7228, May 2014, 368 . 370 Authors' Addresses 372 Pascal Thubert (editor) 373 Cisco Systems 374 Village d'Entreprises Green Side 375 400, Avenue de Roumanille 376 Batiment T3 377 Biot - Sophia Antipolis 06410 378 FRANCE 380 Phone: +33 4 97 23 26 34 381 Email: pthubert@cisco.com 383 Zacharie Brodard 384 Ecole Polytechnique 385 Route de Saclay 386 Palaiseau 91128 387 FRANCE 389 Phone: +33 6 73 73 35 09 390 Email: zacharie.brodard@polytechnique.edu 392 Hao Jiang 393 Telecom Bretagne 394 2, rue de la Chataigneraie 395 Cesson-Sevigne 35510 396 FRANCE 398 Phone: +33 7 53 70 97 34 399 Email: hao.jiang@telecom-bretagne.eu 401 Geraldine Texier 402 Telecom Bretagne 403 2, rue de la Chataigneraie 404 Cesson-Sevigne 35510 405 FRANCE 407 Phone: +33 2 99 12 70 38 408 Email: geraldine.texier@telecom-bretagne.eu