idnits 2.17.1 draft-wijnands-mpls-bier-encapsulation-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 date (September 22, 2014) is 3504 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 255 -- Looks like a reference, but probably isn't: '65535' on line 255 -- Looks like a reference, but probably isn't: '512' on line 144 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 E. Rosen, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 26, 2015 A. Dolganow 6 Alcatel-Lucent 7 J. Tantsura 8 Ericsson 9 September 22, 2014 11 Encapsulation for Bit Index Explicit Replication in MPLS Networks 12 draft-wijnands-mpls-bier-encapsulation-00 14 Abstract 16 Bit Index Explicit Replication (BIER) is an architecture that 17 provides optimal multicast forwarding through a "multicast domain", 18 without requiring intermediate routers to maintain any per-flow state 19 or to engage in an explicit tree-building protocol. When a multicast 20 data packet enters the domain, the ingress router determines the set 21 of egress routers to which the packet needs to be sent. The ingress 22 router then encapsulates the packet in a BIER header. The BIER 23 header contains a bitstring in which each bit represents exactly one 24 egress router in the domain; to forward the packet to a given set of 25 egress routers, the bits corresponding to those routers are set in 26 the BIER header. The details of the encapsulation depend on the type 27 of network used to realize the multicast domain. This document 28 specifies the BIER encapsulation to be used in an MPLS network. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 26, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. The BIER-MPLS Label . . . . . . . . . . . . . . . . . . . . . 3 66 3. BIER Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Imposing and Processing the BIER Encapsulation . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 8 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 [BIER_ARCH] describes a new architecture for the forwarding of 78 multicast data packets. That architecture provides optimal 79 forwarding of multicast data packets through a "multicast domain". 80 However, it does not require any explicit tree-building protocol, and 81 does not require intermediate nodes to maintain any per-flow state. 82 That architecture is known as "Bit Index Explicit Replication" 83 (BIER). 85 This document will use terminology defined in [BIER_ARCH]. 87 A router that supports BIER is known as a "Bit-Forwarding Router" 88 (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers 89 (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix 90 is a routable IP address of a BFR, and is used by BIER to identify a 91 BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and 92 leaves the BIER domain at one or more egress BFRs (BFERs). Each BFER 93 must have a BFR-id as well as a BFR-prefix. A BFR-id is just a 94 number in the range [1,65535] that, within a BIER domain, identifies 95 a BFER uniquely. 97 As described in [BIER_ARCH], BIER requires that multicast data 98 packets be encapsulated with a header that carries the information 99 needed to support the BIER forwarding procedures. This information 100 includes a Set-Id (SI) and a BitString. Together the SI and the 101 BitString identify the set of BFERs to which the packet must be 102 delivered. 104 This document is applicable when a given BIER domain is both an IGP 105 domain and an MPLS network. In this environment, the BIER 106 encapsulation consists of two components: 108 o an MPLS label (which we will call the "BIER-MPLS label"); this 109 label appears at the bottom of a packet's MPLS label stack. 111 o a BIER header, as specified in Section 3. 113 Following the BIER header is the "payload". The payload may be an 114 IPv4 packet, an IPv6 packet, an ethernet frame, or an MPLS packet. 115 If it is an MPLS packet, then an MPLS label stack immediately follows 116 the BIER header. The top label of this MPLS label stack may be 117 either a downstream-assigned label ([RFC3032]) or an upstream- 118 assigned label ([RFC5331]. The BIER header contains information 119 identifying the type of the payload. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. The BIER-MPLS Label 127 As stated in [BIER_ARCH], when a BIER domain is also an IGP domain, 128 IGP extensions can be used by each BFR to advertise the BFR-id and 129 BFR-prefix. The extensions for OSPF are given in [BIER_OSPF]. 131 When a particular BIER domain is both an IGP domain and an MPLS 132 network, we assume that each BFR will also use IGP extensions to 133 advertise a set of one or more "BIER-MPLS" labels. When the domain 134 contains a single "routing underlay" (see [BIER_ARCH]), a given BFR 135 needs to advertise one such label for each SI. If the domain 136 contains multiple routing underlays, a given BFR needs to advertise 137 one such label per SI per each underlay in which that BFR has 138 adjacencies. 140 The BIER-MPLS labels are locally significant (i.e., unique only to 141 the BFR that advertises them) downstream-assigned MPLS labels. For 142 example, suppose there is a single routing underlay, the network is 143 using a BitStringLength of 255, and that all BFERs in the domain have 144 BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits 145 long, this requires the use of two SIs: SI=0 and SI=1. So each BFR 146 will advertise, via IGP extensions, two MPLS labels for BIER: one 147 corresponding to SI=0 and one corresponding to SI=1. 149 When a BFR receives an MPLS packet with one of its BIER-MPLS labels 150 at the top of the stack, it will assume that a BIER header (see 151 Section 3) immediately follows the stack. It will also infer the 152 packet's SI from the label. 154 3. BIER Header 156 The BIER header is shown in Figure 1. This header appears after the 157 end of the MPLS label stack, immediately after the MPLS-BIER label. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |0 0 0 0| Ver |I|0 0 0 0 0 0 0| Proto | Len | Entropy | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | BitString (first 32 bits) ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ~ ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 ~ BitString (last 32 bits) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | BFIR-id (optional) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: BIER Header 175 First nibble: 177 The first 4 bits of the header are all set to zero; this ensures 178 that the BIER header will not be confused with an IP header. 180 Ver: 182 This 4-bit field identifies the version of the BIER header. This 183 document specifies version 0 of the BIER header. 185 I: 187 This bit is set if and only if header contains the BFIR-id field. 188 If this bit is clear, the header does not contain the BFIR-id, and 189 the header ends at the end of the BitString. 191 Proto: 193 This 4-bit field identifies the type of the payload. (The 194 "payload" is the packet or frame immediately following the BIER 195 header.) The protocol field may take any of the following values: 197 1: MPLS packet with downstream-assigned label at top of stack. 199 2: MPLS packet with upstream-assigned label at top of stack (see 200 [RFC5331]). If this value of the Proto field is used, the I 201 bit MUST be set, and the BFR-id of the BFIR must be placed in 202 the BFIR-id field. The BFIR-id provides the "context" in which 203 the upstream-assigned label is interpreted. 205 3: Ethernet frame. 207 4: IPv4 packet. 209 6: IPv6 packet. 211 Len: 213 This 4-bit field encodes the length in bits of the BitString. If 214 k is the length of the BitString, the value of this field is 215 log2(k)-5. However, only certain values are supported: 217 1: 64 bits 219 2: 128 bits 221 3: 256 bits 223 4: 512 bits 225 5: 1024 bits 227 6: 2048 bits 229 7: 4096 bits 231 All other values of this field are illegal. 233 Entropy: 235 This 8-bit field specifies an "entropy" value that can be used for 236 load balancing purposes. The BIER forwarding process may do equal 237 cost load balancing, but the load balancing procedure MUST choose 238 the same path for any two packets have the same entropy value. 240 If a BFIR is encapsulating (as the payload) MPLS packets that have 241 entropy labels, the BFIR MUST ensure that if two such packets have 242 the same MPLS entropy label, they also have the same value of the 243 BIER entropy field. 245 BitString: 247 The BitString that, together with the packet's SI, identifies the 248 destination BFERs for this packet. Note that the SI for the 249 packet is inferred from the BIER-MPLS label that precedes the BIER 250 header. 252 BFIR-id 254 This is the BFR-id of the BFIR. The BFR-id is encoded in the 255 32-bit field as an unsigned integer in the range [1,65535]. 257 This field is optional, and is present only when the I bit is set. 259 4. Imposing and Processing the BIER Encapsulation 261 When a BFIR receives a multicast packet from outside the BIER domain, 262 it carries out the following procedure: 264 1. By consulting the "multicast flow layer" ([BIER_ARCH]), it 265 determines the value of the "Proto" field. 267 2. By consulting the "multicast flow layer", it determines the set 268 of BFERs that must receive the packet. 270 3. The BFIR looks up the BFR-id of each of those BFERs. 272 4. The BFIR converts each such BFR-id into (SI, BitString) format, 273 as described in [BIER_ARCH]. 275 5. All such BFR-ids that have the same SI can be encoded into the 276 same BitString. Details of this encoding can be found in 277 [BIER_ARCH]. For each distinct SI that occurs in the list of the 278 packet's destination BFERs: 280 a. The BFIR make a copy of the multicast data packet, and 281 encapsulates the copy in a BIER header (see Section 3). The 282 BIER header contains the BitString that represents all the 283 destination BFERs whose BFR-ids correspond to the given SI. 285 b. If the payload is an MPLS packet whose label stack begins 286 with an upstream-assigned label, the BFIR-id field MUST be 287 present. (Whether a particular MPLS packet payload begins 288 with an upstream-assigned label is learned from the 289 multicast flow layer.) The BFIR-id MAY be included in other 290 cases as well. 292 c. The BFIR then applies to that copy the forwarding procedure 293 of [BIER_ARCH]. This may result in one or more copies of 294 the packet (possibly with a modified BitString) being 295 transmitted to a neighboring BFR. 297 d. Before transmitting a copy of the packet to a neighboring 298 BFR, the BFIR finds the BIER-MPLS label that was advertised 299 by the neighbor as corresponding to the given SI. An MPLS 300 label stack is then preprended to the packet. This label 301 stack [RFC3032] will contain one label, the aforementioned 302 BIER-MPLS label. The "S" bit MUST be set, indicating the 303 end of the MPLS label stack. The packet may then be 304 transmitted to the neighboring BFR. (This may result in 305 additional MPLS labels being pushed on the stack. For 306 example, if an RSVP-TE tunnel is used to transmit packets to 307 the neighbor, a label representing that tunnel would be 308 pushed onto the stack.) 310 When an intermediate BFR receives a packet with one of its own BIER- 311 MPLS labels at the top of the label stack, it infers the SI from the 312 label, and follows the forwarding procedures of [BIER_ARCH]. If it 313 forwards a copy of the packet to a neighboring BFR, it first swaps 314 the label at the top of the label stack with the BIER-MPLS label that 315 the neighbor advertised that corresponds to the same SI and routing 316 underlay. 318 Thus a BIER-encapsulated packet in an MPLS network consists of a 319 packet that has: 321 o An MPLS label stack with a BIER-MPLS label at the bottom of the 322 stack. 324 o A BIER header, as described in Section 3. 326 o The payload, a multicast data packet. 328 The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, 329 or an MPLS packet. If it is an MPLS packet, the BIER header is 330 followed by a second MPLS label stack; this stack is separate from 331 the stack that precedes the BIER header. 333 5. IANA Considerations 335 This document has no actions for IANA. 337 6. Security Considerations 339 As this document makes use of MPLS, it inherits any security 340 considerations that apply to the use of the MPLS data plane. 342 As this document makes use of IGP extensions, it inherits any 343 security considerations that apply to the IGP. 345 The security considerations of [BIER_ARCH] also apply. 347 7. Acknowledgements 349 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 350 Christian Martin, Neale Ranns, Greg Shepherd, and Ramji Vaithianathan 351 for their ideas and contributions to this work. 353 8. Contributor Addresses 355 Below is a list of other contributing authors in alphabetical order: 357 Wim Henderickx 358 Alcatel-Lucent 359 Copernicuslaan 50 360 Antwerp 2018 361 Belgium 363 Email: wim.henderickx@alcatel-lucent.com 365 Martin Horneffer 366 Deutsche Telekom 367 Hammer Str. 216-226 368 Muenster 48153 369 DE 371 Email: Martin.Horneffer@telekom.de 373 Uwe Joorde 374 Deutsche Telekom 375 Hammer Str. 216-226 376 Muenster D-48153 377 DE 379 Email: Uwe.Joorde@telekom.de 381 Tony Przygienda 382 Ericsson 384 Email: antoni.przygienda@ericsson.com 386 9. Normative References 388 [BIER_ARCH] 389 Wijnands, IJ., "Multicast using Bit Index Explicit 390 Replication Architecture", internet-draft draft-wijnands- 391 bier-architecture-00, September 2014. 393 [BIER_OSPF] 394 Kumar, N., "OSPF Extension for Bit Index Explicit 395 Replication", internet-draft draft-kumar-ospf-bier- 396 extension-00, September 2014. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 402 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 403 Encoding", RFC 3032, January 2001. 405 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 406 Label Assignment and Context-Specific Label Space", RFC 407 5331, August 2008. 409 Authors' Addresses 411 IJsbrand Wijnands (editor) 412 Cisco Systems, Inc. 413 De Kleetlaan 6a 414 Diegem 1831 415 Belgium 417 Email: ice@cisco.com 419 Eric C. Rosen (editor) 420 Cisco Systems, Inc. 421 1414 Massachusetts Avenue 422 Boxborough, Massachusetts 01718 423 USA 425 Email: erosen@cisco.com 427 Andrew Dolganow 428 Alcatel-Lucent 429 600 March Rd. 430 Ottawa, Ontario K2K 2E6 431 Canada 433 Email: andrew.dolganow@alcatel-lucent.com 435 Jeff Tantsura 436 Ericsson 437 300 Holger Way 438 San Jose, California 95134 439 USA 441 Email: jeff.tantsura@ericsson.com