idnits 2.17.1 draft-thubert-bier-replication-elimination-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 (September 14, 2016) is 2774 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) == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-opsawg-oam-overview' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 473, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-04) exists of draft-dt-detnet-dp-alt-03 == 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 (-09) exists of draft-ietf-detnet-problem-statement-00 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track Z. Brodard 5 Expires: March 18, 2017 Ecole Polytechnique 6 H. Jiang 7 Telecom Bretagne 8 September 14, 2016 10 BIER-TE-based OAM, Replication and Elimination 11 draft-thubert-bier-replication-elimination-00 13 Abstract 15 This specification leverages Bit Index Explicit Replication - Traffic 16 Engineering to control in the data plane the DetNet Replication and 17 Elimination activities, and to provide traceability on links where 18 replication and loss happen, in a manner that is abstract to the 19 forwarding information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 18, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. On BIER - Traffic Engineering . . . . . . . . . . . . . . . . 3 58 4. BIER-TE-based Replication and Elimination Control . . . . . . 4 59 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 61 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 10.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Deterministic Networking (DetNet) [I-D.ietf-detnet-problem-statement] 72 provides a capability to carry unicast or multicast data flows for 73 real-time applications with extremely low data loss rates and known 74 upper bound maximum latency [I-D.finn-detnet-architecture]. 76 DetNet applies to multiple environments where there is a desire to 77 replace a point to point serial cable or a multidrop bus by a 78 switched or routed infrastucture, in order to scale, lower costs, and 79 simplify management. One classical use case is found in particular 80 in the context of the convergence of IT with Operational Technology 81 (OT), also referred to as the Industrial Internet. But there are 82 many others use cases [I-D.ietf-detnet-use-cases], for instance in in 83 professional audio and video, automotive, radio fronthauls, etc.. 85 The DetNet data plane alternatives [I-D.dt-detnet-dp-alt] studies the 86 applicability of existing and emerging dataplane techniques that can 87 be leveraged to enable DetNet properties in IP networks. One 88 critical feature in the dataplane is traceability, the capability to 89 control the activity of intermediate nodes on a packet. For 90 instance, if Replication and Elimination is applied to a packet, then 91 it is desirable to determine which node performed a certain copy of 92 that packet that is circulating in the network. 94 Traceability belongs to Operations, Administration, and Maintenance 95 (OAM), which is the toolset for fault detection and isolation, and 96 for performance measurement. An Overview of OAM Tools is available 97 at [I-D.ietf-detnet-use-cases]. 99 This document proposes a new set to OAM tools based on Bit Indexed 100 Explicit Replication [I-D.ietf-bier-architecture] (BIER) and more 101 specifically BIER Traffic Engineering [I-D.eckert-bier-te-arch] 102 (BIER-TE) to control the process or Replication and Elimination, and 103 provide traceability of these operations, in the DetNet dataplane. 104 An adjacency, which is represented by a bit in the BIER header, can 105 correspond in the dataplane to an Ethernet hop, a Label Switched 106 Path, or it can correspond to an IPv6 loose or strict source routed 107 path. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. On BIER - Traffic Engineering 117 BIER [I-D.ietf-bier-architecture] is a network plane replication 118 technique that was initially intended as a new method for multicast 119 distribution. In a nutshell, a BIER header includes a bitmap that 120 explicitly signals the listeners that are intended for a particular 121 packet, which means that 1) the sender is aware of the individual 122 listeners and 2) the BIER control plane is a simple extension of the 123 unicast routing as opposed to a dedicated multicast data plane, which 124 represents a considerable reduction in OPEX. For this reason, the 125 technology faces a lot of traction from Service Providers. 127 The simplicity of the BIER technology makes it very versatile as a 128 network plane signaling protocol. Already, a new Traffic Engineering 129 variation is emerging that uses bits to signal segments along a TE 130 path. While BIER is mainly a multicast technology that typically 131 leverages a unicast distributed control plane through IGP extensions, 132 BIER-TE [I-D.eckert-bier-te-arch] is mainly a unicast technology that 133 leverages a central computation to setup path, compute segments and 134 install the mapping in the intermediate nodes. 136 BIER-TE supports a Traffic Engineered forwarding plane by explicit 137 hop-by-hop forwarding and loose hop forwarding of packets. 139 From the BIER-TE architecture, the key differences over BIER are: 141 o BIER-TE replaces in-network autonomous path calculation by 142 explicit paths calculated off path by the BIER-TE controller host. 144 o In BIER-TE every BitPosition of the BitString of a BIER-TE packet 145 indicates one or more adjacencies - instead of a BFER as in BIER. 146 o BIER-TE in each BFR has no routing table but only a BIER-TE 147 Forwarding Table (BIFT) indexed by SI:BitPosition and populated 148 with only those adjacencies to which the BFR should replicate 149 packets to. 151 The generic view of an adjacency can be over a link, a tunnel or 152 along a path segment. 154 With Segment Routing [I-D.ietf-spring-segment-routing] a segment can 155 be signaled as an MPLS label, or an IPv6 routing header . A segment 156 may be loosely of strictly source routed, depending on the need for 157 full non-congruence and the confidence that loose routing may still 158 achieve that need. 160 4. BIER-TE-based Replication and Elimination Control 162 In a nutshell, BIER-TE is used as follows: 164 o A controller computes a complex path, sometimes called a track, 165 which takes the general form of a ladder. The steps and the side 166 rails between them are the adjacencies that can be activated on 167 demand on a per-packet basis using bits in the BIER header. 169 ===> (A) ====> (C) ==== 170 // ^ | ^ | \\ 171 ingress (I) | | | | (E) egress 172 \\ | v | v // 173 ===> (B) ====> (D) ==== 175 Figure 1: Ladder Shape with Replication and Elimination Points 177 o The controller assigns a BIER domain, and inside that domain, 178 assigns bits to the adjacencies. The controller assigns each bit 179 to a replication node that sends towards the adjacency, for 180 instance the ingress router into a segment that will insert a 181 routing header in the packet. A single bit may be used for a step 182 in the ladder, indicating the other end of the step in both 183 directions. 185 ===> (A) ====> (C) ==== 186 // 1 ^ | 4 ^ | 7 \\ 187 ingress (I) |2| |6| (E) egress 188 \\ 3 | v 5 | v 8 // 189 ===> (B) ====> (D) ==== 191 Figure 2: Assigning Bits 193 o The controller activates the replication by deciding the setting 194 of the bits associated with the adjacencies. This decision can be 195 modified at any time, but takes the latency of a controller round 196 trip to effectively take place. Below is an example that uses 197 Replication and Elimination to protect the A->C adjacency. 199 +-------+-----------+-------+---------------------+ 200 | Bit # | Adjacency | Owner | Example Bit Setting | 201 +-------+-----------+-------+---------------------+ 202 | 1 | I->A | I | 1 | 203 | 2 | A->B | A | 1 | 204 | | B->A | B | | 205 | 3 | I->C | I | 0 | 206 | 4 | A->C | A | 1 | 207 | 5 | B->D | B | 1 | 208 | 6 | C->D | C | 1 | 209 | | D->C | D | | 210 | 7 | C->E | C | 1 | 211 | 8 | D->E | D | 0 | 212 +-------+-----------+-------+---------------------+ 214 Replication and Elimination Protecting A->C 216 Table 1: Controlling Replication 218 o The BIER header with the controlling BitString is injected in the 219 packet by the ingress node of the deterministic path. That node 220 may act as a replication point, in which case it may issue 221 multiple copies of the packet 223 ====> Repl ===> Elim ==== 224 // | ^ \\ 225 ingress | | egress 226 v | 227 Fwd ====> Fwd 229 Figure 3: Enabled Adjacencies 231 o For each of its bits that is set in the BIER header, the owner 232 replication point resets the bit and transmits towards the 233 associated adjacency; to achieve this, the replication point 234 copies the packet and inserts the relevant data plane information, 235 such as a source route header, towards the adjacency that 236 corresponds to the bit 238 +-----------+----------------+ 239 | Adjacency | BIER BitString | 240 +-----------+----------------+ 241 | I->A | 01011110 | 242 | A->B | 00011110 | 243 | B->D | 00010110 | 244 | D->C | 00010010 | 245 | A->C | 01001110 | 246 +-----------+----------------+ 248 BitString in BIER Header as Packet Progresses 250 Table 2: BIER-TE in Action 252 o Adversely, an elimination node on the way strips the data plane 253 information and performs a bitwise AND on the BitStrings from the 254 various copies of the packet that it has received, before it 255 forwards the packet with the resulting BitString. 257 +-----------+----------------+ 258 | Operation | BIER BitString | 259 +-----------+----------------+ 260 | D->C | 00010010 | 261 | A->C | 01001110 | 262 | | -------- | 263 | AND in C | 00000010 | 264 | | | 265 | C->E | 00000000 | 266 +-----------+----------------+ 268 BitString Processing at Elimination Point C 270 Table 3: BIER-TE in Action (cont.) 272 o In this example, all the transmissions succeeded and the BitString 273 at arrival has all the bits reset - note that the egress may be an 274 Elimination Point in which case this is evaluated after this node 275 has performed its AND operation on the received BitStrings). 277 +-------------------+-----------------------+ 278 | Failing Adjacency | Egress BIER BitString | 279 +-------------------+-----------------------+ 280 | I->A | Frame Lost | 281 | I->B | Not Tried | 282 | A->C | 00010000 | 283 | A->B | 01001100 | 284 | B->D | 01001100 | 285 | D->C | 01001100 | 286 | C->E | Frame Lost | 287 | D->E | Not Tried | 288 +-------------------+-----------------------+ 290 BitString indicating failures 292 Table 4: BIER-TE in Action (cont.) 294 o But if a transmission failed along the way, one (or more) bit is 295 never cleared. Table 4 provides the possible outcomes of a 296 transmission. If the frame is lost, then it is probably due to a 297 failure in either I->A or C->E, and the controller should enable 298 I->B and D->E to find out. A BitString of 00010000 indicates 299 unequivocally a transmission error on the A->C adjacency, and a 300 BitString of 01001100 indicates a loss in either A->B, B->D or 301 D->C; enabling D->E on the next packets may provide more 302 information to sort things out. 304 In more details: 306 The BIER header is of variable size, and a DetNet network of a 307 limited size can use a model with 64 bits if 64 adjacencies are 308 enough, whereas a larger deployment may be able to signal up to 256 309 adjacencies for use in very complex paths. The format of this header 310 is common to BIER and BIER-TE. 312 For the DetNet data plane, a replication point is an ingress point 313 for more than one adjacency, and an elimination point is an egress 314 point for more than one adjacency. 316 A pre-populated state in a replication node indicates which bits are 317 served by this node and to which adjacency each of these bits 318 corresponds. With DetNet, the state is typically installed by a 319 controller entity such as a PCE. The way the adjacency is signaled 320 in the packet is fully abstracted in the bit representation and must 321 be provisioned to the replication nodes and maintained as a local 322 state, together with the timing or shaping information for the 323 associated flow. 325 The DetNet data plane uses BIER-TE to control which adjacencies are 326 used for a given packet. This is signaled from the path ingress, 327 which sets the appropriate bits in the BIER BitString to indicate 328 which replication must happen. 330 The replication point clears the bit associated to the adjacency 331 where the replica is placed, and the elimination points perform a 332 logical AND of the BitStrings of the copies that it gets before 333 forwarding. 335 As is apparent in the examples above, clearing the bits enables to 336 trace a packet to the replication points that made any particular 337 copy. BIER-TE also enables to detect the failing adjacencies or 338 sequences of adjacencies along a path and to activate additional 339 replications to counter balance the failures. 341 Finally, using the same BIER-TE bit for both directions of the steps 342 of the ladder enables to avoid replication in both directions along 343 the crossing adjacencies. At the time of sending along the step of 344 the ladder, the bit may have been already reset by performing the AND 345 operation with the copy from the other side, in which case the 346 transmission is not needed and does not occur (since the control bit 347 is now off). 349 5. Summary 351 BIER-TE occupies a particular position in the DetNet dataplane. In 352 the one hand it is optional, and only useful if replication and 353 elimination is taking place. In the other hand, it has unique 354 capabilities to: 356 o control which replication take place on a per packet basis, so 357 that replication points can be configured but not actually 358 utilized 359 o trace the replication activity and determine which node replicated 360 a particular packet 361 o measure the quality of transmission of the actual data packet 362 along the replication segments and use that in a control loop to 363 adapt the setting of the bits and maintain the reliability. 365 6. Implementation Status 367 A research-stage implementation of the forwarding plane fir a 6TiSCH 368 IOT use case was developed at Cisco's Paris Innovation Lab (PIRL) by 369 Zacharie Brodard. It was implemented on OpenWSN Open-source firmware 370 and tested on the OpenMote-CC2538 hardware. It implements the header 371 types 15,16, 17, 18 and 19 (bit-by-bit encoding without group ID) in 372 order to allow a BIER-TE protocol over IEE802.15.4e. 374 This work was complemented with a Controller-based control loop by 375 Hao Jiang. The controller builds the complex paths (called Tracks in 376 6TiSCH) and decides the setting oif the BitStrings in real time in 377 order to optimize the delivery ratio within a minimal energy budget. 379 Links: 381 github: https://github.com/zach-b/openwsn-fw/tree/BIER 382 OpenWSN firmware: https://openwsn.atlassian.net/wiki/pages/ 383 viewpage.action?pageId=688187 384 OpenMote hardware: http://www.openmote.com/ 386 7. Security considerations 388 TBD. 390 8. IANA Considerations 392 This document has no IANA considerations. 394 9. Acknowledgements 396 The method presented in this document was discussed and worked out 397 together with the DetNet Data Plane Design Team: 399 Jouni Korhonen 400 Janos Farkas 401 Norman Finn 402 Olivier Marce 403 Gregory Mirsky 404 Pascal Thubert 405 Zhuangyan Zhuang 407 The authors also like to thank the DetNet chairs Lou Berger and Pat 408 Thaler, as well as Thomas Watteyne, 6TiSCH co-chair, for their 409 contributions and support to this work. 411 10. References 413 10.1. Normative References 415 [I-D.finn-detnet-architecture] 416 Finn, N. and P. Thubert, "Deterministic Networking 417 Architecture", draft-finn-detnet-architecture-08 (work in 418 progress), August 2016. 420 [I-D.ietf-bier-architecture] 421 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 422 S. Aldrin, "Multicast using Bit Index Explicit 423 Replication", draft-ietf-bier-architecture-04 (work in 424 progress), July 2016. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 10.2. Informative References 433 [I-D.dt-detnet-dp-alt] 434 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 435 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 436 and Solution Alternatives", draft-dt-detnet-dp-alt-03 437 (work in progress), August 2016. 439 [I-D.eckert-bier-te-arch] 440 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 441 Engineering for Bit Index Explicit Replication BIER-TE", 442 draft-eckert-bier-te-arch-04 (work in progress), July 443 2016. 445 [I-D.ietf-6tisch-architecture] 446 Thubert, P., "An Architecture for IPv6 over the TSCH mode 447 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 448 in progress), June 2016. 450 [I-D.ietf-detnet-problem-statement] 451 Finn, N. and P. Thubert, "Deterministic Networking Problem 452 Statement", draft-ietf-detnet-problem-statement-00 (work 453 in progress), April 2016. 455 [I-D.ietf-detnet-use-cases] 456 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 457 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 458 Varga, B., Farkas, J., Goetz, F., and J. Schmitt, 459 "Deterministic Networking Use Cases", draft-ietf-detnet- 460 use-cases-10 (work in progress), July 2016. 462 [I-D.ietf-opsawg-oam-overview] 463 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 464 Weingarten, "An Overview of Operations, Administration, 465 and Maintenance (OAM) Tools", draft-ietf-opsawg-oam- 466 overview-16 (work in progress), March 2014. 468 [I-D.ietf-spring-segment-routing] 469 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 470 and R. Shakir, "Segment Routing Architecture", draft-ietf- 471 spring-segment-routing-09 (work in progress), July 2016. 473 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 474 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 475 DOI 10.17487/RFC6282, September 2011, 476 . 478 Authors' Addresses 480 Pascal Thubert (editor) 481 Cisco Systems 482 Village d'Entreprises Green Side 483 400, Avenue de Roumanille 484 Batiment T3 485 Biot - Sophia Antipolis 06410 486 FRANCE 488 Phone: +33 4 97 23 26 34 489 Email: pthubert@cisco.com 491 Zacharie Brodard 492 Ecole Polytechnique 493 Route de Saclay 494 Palaiseau 91128 495 FRANCE 497 Phone: +33 6 73 73 35 09 498 Email: zacharie.brodard@polytechnique.edu 500 Hao Jiang 501 Telecom Bretagne 502 2, rue de la Chataigneraie 503 Cesson-Sevigne 35510 504 FRANCE 506 Phone: +33 7 53 70 97 34 507 Email: hao.jiang@telecom-bretagne.eu