idnits 2.17.1 draft-wijnands-mpls-bier-encapsulation-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 date (December 4, 2014) is 3432 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) -- Looks like a reference, but probably isn't: '1' on line 320 -- Looks like a reference, but probably isn't: '65535' on line 320 -- Looks like a reference, but probably isn't: '512' on line 153 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track E. Rosen, Ed. 5 Expires: June 7, 2015 Juniper Networks, Inc. 6 A. Dolganow 7 Alcatel-Lucent 8 J. Tantsura 9 Ericsson 10 S. Aldrin 11 Huawei Technologies 12 December 4, 2014 14 Encapsulation for Bit Index Explicit Replication in MPLS Networks 15 draft-wijnands-mpls-bier-encapsulation-02 17 Abstract 19 Bit Index Explicit Replication (BIER) is an architecture that 20 provides optimal multicast forwarding through a "multicast domain", 21 without requiring intermediate routers to maintain any per-flow state 22 or to engage in an explicit tree-building protocol. When a multicast 23 data packet enters the domain, the ingress router determines the set 24 of egress routers to which the packet needs to be sent. The ingress 25 router then encapsulates the packet in a BIER header. The BIER 26 header contains a bitstring in which each bit represents exactly one 27 egress router in the domain; to forward the packet to a given set of 28 egress routers, the bits corresponding to those routers are set in 29 the BIER header. The details of the encapsulation depend on the type 30 of network used to realize the multicast domain. This document 31 specifies the BIER encapsulation to be used in an MPLS network. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 7, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. The BIER-MPLS Label . . . . . . . . . . . . . . . . . . . . . 3 69 3. BIER Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Imposing and Processing the BIER Encapsulation . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 [BIER_ARCH] describes a new architecture for the forwarding of 83 multicast data packets. That architecture provides optimal 84 forwarding of multicast data packets through a "multicast domain". 85 However, it does not require any explicit tree-building protocol, and 86 does not require intermediate nodes to maintain any per-flow state. 87 That architecture is known as "Bit Index Explicit Replication" 88 (BIER). 90 This document will use terminology defined in [BIER_ARCH]. 92 A router that supports BIER is known as a "Bit-Forwarding Router" 93 (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers 94 (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix 95 is a routable IP address of a BFR, and is used by BIER to identify a 96 BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and 97 leaves the BIER domain at one or more egress BFRs (BFERs). As 98 specified in [BIER_ARCH], each BFR of a given BIER domain is 99 provisioned to be in one or more "sub-domains". In the context of a 100 given sub-domain, each BFIR and BFER must have a BFR-id that is 101 unique within that sub-domain. A BFR-id is just a number in the 102 range [1,65535] that, relative to a BIER sub-domain, identifies a BFR 103 uniquely. 105 As described in [BIER_ARCH], BIER requires that multicast data 106 packets be encapsulated with a header that provides the information 107 needed to support the BIER forwarding procedures. This information 108 includes the sub-domain to which the packet has been assigned, a Set- 109 Id (SI), a BitString, and a BitStringLength. Together these values 110 identify the set of BFERs to which the packet must be delivered. 112 This document is applicable when a given BIER domain is both an IGP 113 domain and an MPLS network. In this environment, the BIER 114 encapsulation consists of two components: 116 o an MPLS label (which we will call the "BIER-MPLS label"); this 117 label appears at the bottom of a packet's MPLS label stack. 119 o a BIER header, as specified in Section 3. 121 Following the BIER header is the "payload". The payload may be an 122 IPv4 packet, an IPv6 packet, an ethernet frame, or an MPLS packet. 123 If it is an MPLS packet, then an MPLS label stack immediately follows 124 the BIER header. The top label of this MPLS label stack may be 125 either a downstream-assigned label ([RFC3032]) or an upstream- 126 assigned label ([RFC5331]. The BIER header contains information 127 identifying the type of the payload. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. The BIER-MPLS Label 135 As stated in [BIER_ARCH], when a BIER domain is also an IGP domain, 136 IGP extensions can be used by each BFR to advertise the BFR-id and 137 BFR-prefix. The extensions for OSPF are given in 138 [OSPF_BIER_EXTENSIONS]. The extensions for ISIS are given in 139 [ISIS_BIER_EXTENSIONS]. 141 When a particular BIER domain is both an IGP domain and an MPLS 142 network, we assume that each BFR will also use IGP extensions to 143 advertise a set of one or more "BIER-MPLS" labels. When the domain 144 contains a single sub-domain, a given BFR needs to advertise one such 145 label for each combination of SI and BitStringLength. If the domain 146 contains multiple sub-domains, a BFR needs to advertise one such 147 label per SI per BitStringLength for each sub-domain. 149 The BIER-MPLS labels are locally significant (i.e., unique only to 150 the BFR that advertises them) downstream-assigned MPLS labels. For 151 example, suppose that there is a single sub-domain (the default sub- 152 domain), that the network is using a BitStringLength of 256, and that 153 all BFERs in the sub-domain have BFR-ids in the range [1,512]. Since 154 each BIER BitString is 256 bits long, this requires the use of two 155 SIs: SI=0 and SI=1. So each BFR will advertise, via IGP extensions, 156 two MPLS labels for BIER: one corresponding to SI=0 and one 157 corresponding to SI=1. The advertisements of these labels will also 158 bind each label to the default sub-domain and to the BitStringLength 159 256. 161 As another example, suppose a particular BIER domain contains 2 sub- 162 domains (sub-domain 0 and sub-domain 1), supports 2 BitStringLengths 163 (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for 164 both sub-domains, and that supports both BitStringLengths, would have 165 to advertise the following set of BIER-MPLS labels: 167 L1: corresponding to sub-domain 0, BitStringLength 256, SI 0. 169 L2: corresponding to sub-domain 0, BitStringLength 256, SI 1. 171 L3: corresponding to sub-domain 0, BitStringLength 256, SI 2. 173 L4: corresponding to sub-domain 0, BitStringLength 256, SI 3. 175 L5: corresponding to sub-domain 0, BitStringLength 512, SI 0. 177 L6: corresponding to sub-domain 0, BitStringLength 512, SI 1. 179 L7: corresponding to sub-domain 1, BitStringLength 256, SI 0. 181 L8: corresponding to sub-domain 1, BitStringLength 256, SI 1. 183 L9: corresponding to sub-domain 1, BitStringLength 256, SI 2. 185 L10: corresponding to sub-domain 1, BitStringLength 256, SI 3. 187 L11: corresponding to sub-domain 1, BitStringLength 512, SI 0. 189 L12: corresponding to sub-domain 1, BitStringLength 512, SI 1. 191 The above example should not be taken as implying that the BFRs need 192 to advertise 12 individual labels. For instance, instead of 193 advertising a label for and 194 a label for , a BFR could 195 advertise a contiguous range of labels (in this case, a range 196 containing exactly two labels) corresponding to . The first label in the range could correspond 198 to SI 0, and the second to SI 1. The precise mechanism for 199 generating and forming the advertisements is outside the scope of 200 this document. See [OSPF_BIER_EXTENSIONS] and 201 [ISIS_BIER_EXTENSIONS]. 203 Note that, in practice, labels only have to be assigned if they are 204 going to be used. If a particular BIER domain supports 205 BitStringLengths 256 and 512, but some sub-domain, say sub-domain 1, 206 only uses BitStringLength 256, then it is not necessary to assign 207 labels that correspond to the combination of sub-domain 1 and 208 BitStringLength 512. 210 When a BFR receives an MPLS packet, and the next label to be 211 processed is one of its BIER-MPLS labels, it will assume that a BIER 212 header (see Section 3) immediately follows the stack. It will also 213 infer the packet's sub-domain, SI, and BitStringLength from the 214 label. The packet's "incoming TTL" (see below) is taken from the TTL 215 field of the label stack entry that contains the BIER-MPLS label. 217 The BFR MUST perform the MPLS TTL processing correctly. If the 218 packet is forwarded to one or more BFR adjacencies, the BIER-MPLS 219 label carried by the forwarded packet MUST have a TTL field whose 220 value is one less than that of the incoming TTL. (Of course, if the 221 incoming TTL is 1, the packet will not be forwarded at all, but will 222 be discarded as an MPLS packet whose TTL has been exceeded.) 224 3. BIER Header 226 The BIER header is shown in Figure 1. This header appears after the 227 end of the MPLS label stack, immediately after the MPLS-BIER label. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |0 0 0 0| Proto | Len | Entropy | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | BitString (first 32 bits) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ~ ~ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ~ BitString (last 32 bits) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Reserved | BFIR-id | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 1: BIER Header 245 Ver: 247 The first 4 bits of the header are all set to zero; this ensures 248 that the BIER header will not be confused with an IP header. This 249 field can also be used as a version number if there are future 250 revisions of the BIER header. However, the values 4 and 6 MUST 251 NOT be used, as that may make the packets appear to some hardware 252 forwarder to be IP packets. 254 Proto: 256 This 4-bit field identifies the type of the payload. (The 257 "payload" is the packet or frame immediately following the BIER 258 header.) The protocol field may take any of the following values: 260 1: MPLS packet with downstream-assigned label at top of stack. 262 2: MPLS packet with upstream-assigned label at top of stack (see 263 [RFC5331]). If this value of the Proto field is used, the I 264 bit MUST be set, and the BFR-id of the BFIR must be placed in 265 the BFIR-id field. The BFIR-id provides the "context" in which 266 the upstream-assigned label is interpreted. 268 3: Ethernet frame. 270 4: IPv4 packet. 272 6: IPv6 packet. 274 Len: 276 This 4-bit field encodes the length in bits of the BitString. If 277 k is the length of the BitString, the value of this field is 278 log2(k)-5. However, only certain values are supported: 280 1: 64 bits 282 2: 128 bits 284 3: 256 bits 286 4: 512 bits 288 5: 1024 bits 290 6: 2048 bits 292 7: 4096 bits 294 All other values of this field are illegal. 296 Entropy: 298 This 20-bit field specifies an "entropy" value that can be used 299 for load balancing purposes. The BIER forwarding process may do 300 equal cost load balancing, but the load balancing procedure MUST 301 choose the same path for any two packets have the same entropy 302 value. 304 If a BFIR is encapsulating (as the payload) MPLS packets that have 305 entropy labels, the BFIR MUST ensure that if two such packets have 306 the same MPLS entropy label, they also have the same value of the 307 BIER entropy field. 309 BitString: 311 The BitString that, together with the packet's SI, identifies the 312 destination BFERs for this packet. Note that the SI for the 313 packet is inferred from the BIER-MPLS label that precedes the BIER 314 header. 316 BFIR-id 318 By default, this is the BFR-id of the BFIR, in the sub-domain to 319 which the packet has been assigned. The BFR-id is encoded in the 320 16-bit field as an unsigned integer in the range [1,65535]. 322 Certain applications may require that the BFIR-id field contain 323 the BFR-id of a BFR other than the BFIR. However, that usage of 324 the BFIR-id field is outside the scope of the current document. 326 4. Imposing and Processing the BIER Encapsulation 328 When a BFIR receives a multicast packet from outside the BIER domain, 329 the BFIR carries out the following procedure: 331 1. By consulting the "multicast flow layer" ([BIER_ARCH]), it 332 determines the value of the "Proto" field. 334 2. By consulting the "multicast flow layer", it determines the set 335 of BFERs that must receive the packet. 337 3. If more than one sub-domain is supported, the BFIR assigns the 338 packet to a particular sub-domain. Procedures for determining 339 the sub-domain to which a particular packet should be assigned 340 are outside the scope of this document. 342 4. The BFIR looks up the BFR-id, in the given sub-domain, of each of 343 those BFERs. 345 5. The BFIR converts each such BFR-id into (SI, BitString) format, 346 as described in [BIER_ARCH]. 348 6. All such BFR-ids that have the same SI can be encoded into the 349 same BitString. Details of this encoding can be found in 350 [BIER_ARCH]. For each distinct SI that occurs in the list of the 351 packet's destination BFERs: 353 a. The BFIR makes a copy of the multicast data packet, and 354 encapsulates the copy in a BIER header (see Section 3). The 355 BIER header contains the BitString that represents all the 356 destination BFERs whose BFR-ids (in the given sub-domain) 357 correspond to the given SI. It also contains the BFIR's 358 BFIR-id in the sub-domain to which the packet has been 359 assigned. 361 N.B.: For certain applications, it may be necessary for the 362 BFIR-id field to contain the BFR-id of a BFR other than the 363 BFIR that is creating the header. Such uses are outside the 364 scope of this document, but may be discussed in future 365 revisions. 367 b. The BFIR then applies to that copy the forwarding procedure 368 of [BIER_ARCH]. This may result in one or more copies of 369 the packet (possibly with a modified BitString) being 370 transmitted to a neighboring BFR. 372 c. Before transmitting a copy of the packet to a neighboring 373 BFR, the BFIR finds the BIER-MPLS label that was advertised 374 by the neighbor as corresponding to the given SI, sub- 375 domain, and BitStringLength. An MPLS label stack is then 376 preprended to the packet. This label stack [RFC3032] will 377 contain one label, the aforementioned BIER-MPLS label. The 378 "S" bit MUST be set, indicating the end of the MPLS label 379 stack. The TTL field of this label stack entry is set 380 according to policy. The packet may then be transmitted to 381 the neighboring BFR. (This may result in additional MPLS 382 labels being pushed on the stack. For example, if an RSVP- 383 TE tunnel is used to transmit packets to the neighbor, a 384 label representing that tunnel would be pushed onto the 385 stack.) 387 When an intermediate BFR is processing a received MPLS packet, and 388 one of the BFR's own BIER-MPLS labels rises to the top of the label 389 stack, the BFR infers the sub-domain, SI, and BitStringLength from 390 the label. The BFR then follows the forwarding procedures of 391 [BIER_ARCH]. If it forwards a copy of the packet to a neighboring 392 BFR, it first swaps the label at the top of the label stack with the 393 BIER-MPLS label, advertised by that neighbor, that corresponds to the 394 same SI, sub-domain, and BitStringLength. Note that when this swap 395 operation is done, the TTL field of the BIER-MPLS label of the 396 outgoing packet MUST be one less than the "incoming TTL" of the 397 packet, as defined in Section 2. 399 Thus a BIER-encapsulated packet in an MPLS network consists of a 400 packet that has: 402 o An MPLS label stack with a BIER-MPLS label at the bottom of the 403 stack. 405 o A BIER header, as described in Section 3. 407 o The payload. 409 The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, 410 or an MPLS packet. If it is an MPLS packet, the BIER header is 411 followed by a second MPLS label stack; this stack is separate from 412 the stack that precedes the BIER header. For an example of an 413 application where it is useful to carry an MPLS packet as the BIER 414 payload, see [BIER_MVPN]. 416 5. IANA Considerations 418 This document has no actions for IANA. 420 6. Security Considerations 422 As this document makes use of MPLS, it inherits any security 423 considerations that apply to the use of the MPLS data plane. 425 As this document makes use of IGP extensions, it inherits any 426 security considerations that apply to the IGP. 428 The security considerations of [BIER_ARCH] also apply. 430 7. Acknowledgements 432 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 433 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 434 and Jeffrey Zhang for their ideas and contributions to this work. 436 8. Contributor Addresses 438 Below is a list of other contributing authors in alphabetical order: 440 Mach (Guoyi) Chen 441 Huawei 443 Email: mach.chen@huawei.com 445 Arkadiy Gulko 446 Thomson Reuters 447 195 Broadway 448 New York NY 10007 449 US 451 Email: arkadiy.gulko@thomsonreuters.com 453 Wim Henderickx 454 Alcatel-Lucent 455 Copernicuslaan 50 456 Antwerp 2018 457 BE 459 Email: wim.henderickx@alcatel-lucent.com 461 Martin Horneffer 462 Deutsche Telekom 463 Hammer Str. 216-226 464 Muenster 48153 465 DE 467 Email: Martin.Horneffer@telekom.de 469 Uwe Joorde 470 Deutsche Telekom 471 Hammer Str. 216-226 472 Muenster D-48153 473 DE 475 Email: Uwe.Joorde@telekom.de 477 Tony Przygienda 478 Ericsson 479 300 Holger Way 480 San Jose, CA 95134 481 US 483 Email: antoni.przygienda@ericsson.com 485 9. References 487 9.1. Normative References 489 [BIER_ARCH] 490 Wijnands, IJ., "Multicast using Bit Index Explicit 491 Replication Architecture", internet-draft draft-wijnands- 492 bier-architecture-02, December 2014. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 498 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 499 Encoding", RFC 3032, January 2001. 501 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 502 Label Assignment and Context-Specific Label Space", RFC 503 5331, August 2008. 505 9.2. Informative References 507 [BIER_MVPN] 508 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 509 Dolganow, A., and T. Przygienda, "Multicast VPN Using 510 Bier", internet-draft draft-rosen-l3vpn-mvpn-bier-02, 511 December 2014. 513 [ISIS_BIER_EXTENSIONS] 514 Przygienda, T., Ginsberg, L., Aldrin, S., and J. Zhang, 515 "OSPF Extensions for Bit Index Explicit Replication", 516 internet-draft draft-przygienda-bier-isis-ranges-01.txt, 517 October 2014. 519 [OSPF_BIER_EXTENSIONS] 520 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 521 Przygienda, T., and J. Zhang, "OSPF Extensions for Bit 522 Index Explicit Replication", internet-draft draft-psenak- 523 ospf-bier-extensions-01.txt, October 2014. 525 Authors' Addresses 526 IJsbrand Wijnands (editor) 527 Cisco Systems, Inc. 528 De Kleetlaan 6a 529 Diegem 1831 530 BE 532 Email: ice@cisco.com 534 Eric C. Rosen (editor) 535 Juniper Networks, Inc. 536 10 Technology Park Drive 537 Westford, Massachusetts 01886 538 US 540 Email: erosen@juniper.net 542 Andrew Dolganow 543 Alcatel-Lucent 544 600 March Rd. 545 Ottawa, Ontario K2K 2E6 546 CA 548 Email: andrew.dolganow@alcatel-lucent.com 550 Jeff Tantsura 551 Ericsson 552 300 Holger Way 553 San Jose, California 95134 554 US 556 Email: jeff.tantsura@ericsson.com 558 Sam K Aldrin 559 Huawei Technologies 560 2330 Central Express Way 561 Santa Clara, California 562 US 564 Email: aldrin.ietf@gmail.com