idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-06.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 9, 2016) is 2687 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 428 -- Looks like a reference, but probably isn't: '65535' on line 428 -- Looks like a reference, but probably isn't: '512' on line 221 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 12, 2017 Juniper Networks, Inc. 6 A. Dolganow 7 Nokia 8 J. Tantsura 9 Individual 10 S. Aldrin 11 Google, Inc. 12 I. Meilik 13 Broadcom 14 December 9, 2016 16 Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS 17 Networks 18 draft-ietf-bier-mpls-encapsulation-06 20 Abstract 22 Bit Index Explicit Replication (BIER) is an architecture that 23 provides optimal multicast forwarding through a "multicast domain", 24 without requiring intermediate routers to maintain any per-flow state 25 or to engage in an explicit tree-building protocol. When a multicast 26 data packet enters the domain, the ingress router determines the set 27 of egress routers to which the packet needs to be sent. The ingress 28 router then encapsulates the packet in a BIER header. The BIER 29 header contains a bitstring in which each bit represents exactly one 30 egress router in the domain; to forward the packet to a given set of 31 egress routers, the bits corresponding to those routers are set in 32 the BIER header. The details of the encapsulation depend on the type 33 of network used to realize the multicast domain. This document 34 specifies a BIER encapsulation that can be used in an MPLS network, 35 or with slight differences, in a non-MPLS network. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 12, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. BIER Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. In MPLS Networks . . . . . . . . . . . . . . . . . . . . 5 74 2.1.1. Encapsulation Initial Four Octets . . . . . . . . . . 5 75 2.1.1.1. The BIER-MPLS Label . . . . . . . . . . . . . . . 5 76 2.1.1.2. Other Fields of the Initial Four Octets . . . . . 7 77 2.1.2. Remainder of Encapsulation . . . . . . . . . . . . . 7 78 2.1.3. Further Encapsulating a BIER Packet . . . . . . . . . 10 79 2.2. In Non-MPLS Networks . . . . . . . . . . . . . . . . . . 11 80 2.2.1. Encapsulation Initial Four Octets . . . . . . . . . . 11 81 2.2.1.1. The BIFT-id . . . . . . . . . . . . . . . . . . . 11 82 2.2.1.2. Other Fields of the Initial Four Octets . . . . . 11 83 2.2.2. Remainder of Encapsulation . . . . . . . . . . . . . 12 84 2.2.3. Further Encapsulating a BIER Packet . . . . . . . . . 13 85 3. Imposing and Processing the BIER Encapsulation . . . . . . . 13 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 8.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 [BIER_ARCH] describes a new architecture for the forwarding of 98 multicast data packets. Known as "Bit Index Explicit Replication" 99 (BIER), that architecture provides optimal forwarding of multicast 100 data packets through a "multicast domain". It does so without 101 requiring any explicit tree-building protocol and without requiring 102 intermediate nodes to maintain any per-flow state. 104 This document will use terminology defined in [BIER_ARCH]. 106 A router that supports BIER is known as a "Bit-Forwarding Router" 107 (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers 108 (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix 109 is a routable IP address of a BFR, and is used by BIER to identify a 110 BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and 111 leaves the BIER domain at one or more egress BFRs (BFERs). As 112 specified in [BIER_ARCH], each BFR of a given BIER domain is 113 provisioned to be in one or more "sub-domains" (SDs). In the context 114 of a given SD, each BFIR and BFER must have a BFR-id that is unique 115 within that SD. A BFR-id is just a number in the range [1,65535] 116 that, relative to a BIER SD, identifies a BFR uniquely. 118 As described in [BIER_ARCH], BIER requires that multicast data 119 packets be encapsulated with a header that provides the information 120 needed to support the BIER forwarding procedures. This information 121 includes the SD to which the packet has been assigned, a Set-Id (SI), 122 a BitString, and a BitStringLength (BSL) Together these values are 123 used to identify the set of BFERs to which the packet must be 124 delivered. 126 This document defines an encapsulation that can be used in either 127 MPLS networks or non-MPLS networks. However, the construction and 128 processing of the BIER header is slightly different in MPLS networks 129 than in non-MPLS networks. In particular: 131 o The handling of certain fields in the encapsulation header (the 132 "BIER header") is different depending upon whether the underlying 133 network is an MPLS network or not. 135 o In an MPLS network, the first four octets of a BIER header is also 136 the bottom entry (the last four octets) of an MPLS label stack. 138 The MPLS-based encapsulation is explained in detail in Section 2.1. 139 The differences between the MPLS-based encapsulation and the non-MPLS 140 encapsulation is explained in Section 2.2. 142 Following the BIER header is the "payload". The payload may be an 143 IPv4 packet, an IPv6 packet, an ethernet frame, an MPLS packet, or an 144 OAM packet. (The use of BIER with other payload types is also 145 possible, but is not further discussed in this document.) The BIER 146 header contains information (the Next Protocol field) identifying the 147 type of the payload. 149 If the payload is an MPLS packet, then an MPLS label stack 150 immediately follows the BIER header. The top label of this MPLS 151 label stack may be either a downstream-assigned label [RFC3032] or an 152 upstream-assigned label [RFC5331]. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 2. BIER Header 160 The BIER header is shown in Figure 1. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | BIFT-id | TC |S| TTL | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |Nibble | Ver | BSL | Entropy | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |OAM|Rsv| DSCP | Proto | BFIR-id | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | BitString (first 32 bits) ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 ~ ~ 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ~ BitString (last 32 bits) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: BIER Header 180 The BIFT-id represents a particular Bit Index Forwarding 181 Table (BIFT); see Section 6.4 of [BIER_ARCH]. As explained in 182 [BIER_ARCH], each BIFT corresponds to a particular combination of SD, 183 BSL, and SI. 185 Section 2.1 explains how the fields of the encapsulation header are 186 used in MPLS networks. For those fields that are used differently in 187 non-MPLS networks, Section 2.2 explains the differences. 189 2.1. In MPLS Networks 191 2.1.1. Encapsulation Initial Four Octets 193 2.1.1.1. The BIER-MPLS Label 195 As stated in [BIER_ARCH], when a BIER domain is also an IGP domain, 196 IGP extensions can be used by each BFR to advertise the BFR-id and 197 BFR-prefix. The extensions for OSPF are given in 198 [OSPF_BIER_EXTENSIONS]. The extensions for ISIS are given in 199 [ISIS_BIER_EXTENSIONS]. 201 When a particular BIER domain is both an IGP domain and an MPLS 202 network, we assume that each BFR will also use IGP extensions to 203 advertise a set of one or more "BIER-MPLS" labels. When the domain 204 contains a single SD, a given BFR needs to advertise one such label 205 for each combination of SI and BSL. If the domain contains multiple 206 SDs, a BFR needs to advertise one such label per SI per BSL for each 207 SD. 209 In some environments, the only routing protocol in a BIER domain 210 might be BGP; in this case, the BGP extensions described in 211 [BGP_BIER_EXTENSIONS] can be used to advertise the necessary set of 212 BIER-MPLS labels. 214 The BIER-MPLS labels are locally significant (i.e., unique only to 215 the BFR that advertises them) downstream-assigned MPLS labels. 216 Penultimate hop popping ([RFC3031]) MUST NOT be applied to a BIER- 217 MPLS label. 219 Suppose for example that there is a single SD (the default SD), that 220 the network is using a BSL of 256, and that all BFERs in the SD have 221 BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits 222 long, this requires the use of two SIs: SI=0 and SI=1. So each BFR 223 will advertise, via IGP extensions, two MPLS labels for BIER: one 224 corresponding to SI=0 and one corresponding to SI=1. The 225 advertisements of these labels will also bind each label to the 226 default SD and to the BSL 256. 228 As another example, suppose a particular BIER domain contains 2 SDs 229 (SD 0 and SD 1), supports 2 BSLs (256 and 512), and contains 1024 230 BFRs. A BFR that is provisioned for both SDs, and that supports both 231 BSLs, would have to advertise the following set of BIER-MPLS labels: 233 L1: corresponding to SD 0, BSL 256, SI 0. 235 L2: corresponding to SD 0, BSL 256, SI 1. 237 L3: corresponding to SD 0, BSL 256, SI 2. 239 L4: corresponding to SD 0, BSL 256, SI 3. 241 L5: corresponding to SD 0, BSL 512, SI 0. 243 L6: corresponding to SD 0, BSL 512, SI 1. 245 L7: corresponding to SD 1, BSL 256, SI 0. 247 L8: corresponding to SD 1, BSL 256, SI 1. 249 L9: corresponding to SD 1, BSL 256, SI 2. 251 L10: corresponding to SD 1, BSL 256, SI 3. 253 L11: corresponding to SD 1, BSL 512, SI 0. 255 L12: corresponding to SD 1, BSL 512, SI 1. 257 The above example should not be taken as implying that the BFRs need 258 to advertise 12 individual labels. For instance, instead of 259 advertising a label for and a label for , a BFR could advertise a contiguous range of labels 261 (in this case, a range containing exactly two labels) corresponding 262 to . The first label in the range could correspond to 263 SI 0, and the second to SI 1. The precise mechanism for generating 264 and forming the advertisements is outside the scope of this document. 265 See [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS]. 267 The BIER-MPLS label corresponding to a particular combination of SD, 268 SI, and BSL is interpreted as representing the BIFT that corresponds 269 to that same combination of SD, SI, and BSL. That is, the BIER-MPLS 270 label performs the function of a BIFT-id. This label value is 271 carried in the BIFT-id field of the BIER encapsulation. 273 It is crucial to understand that in an MPLS network, the first four 274 octets of the BIER encapsulation header are also the last four octets 275 of the MPLS header. Therefore, any prior MPLS label stack entries 276 MUST have the S bit (see [RFC3032]) clear (i.e., the S bit must be 277 0). 279 When a BFR receives an MPLS packet, and the next label to be 280 processed is one of its BIER-MPLS labels, it will assume that the 281 remainder of the BIER header (see Section 2.1.2) immediately follows 282 the stack. 284 Note that in practice, labels only have to be assigned if they are 285 going to be used. If a particular BIER domain supports BSLs 256 and 286 512, but some SD, say SD 1, only uses BSL 256, then it is not 287 necessary to assign labels that correspond to the combination of SD 1 288 and BSL 512. 290 2.1.1.2. Other Fields of the Initial Four Octets 292 S bit: 294 When a BIER packet is traveling through an MPLS network, the high- 295 order 20 bits of the initial four octets of the BIER encapsulation 296 contain an MPLS label in the BIFT-id field. These four octets are 297 treated as the final entry in the packet's MPLS label stack. 298 Hence the S bit (see [RFC3032]) MUST be set to 1. If there are 299 any MPLS label stack entries immediately preceding the BIER 300 encapsulation, the S bit of those label stack entries MUST be set 301 to 0. 303 TC: 305 The "Traffic Class" field ([RFC5462]) has its usual meaning in an 306 MPLS label stack entry. 308 TTL: 310 This is the usual MPLS "Time to Live" field ([RFC3032]). When a 311 BIER packet is received, its "incoming TTL" (see below) is taken 312 from this TTL field. 314 The BFR MUST perform the MPLS TTL processing correctly. If the 315 packet is forwarded to one or more BFR adjacencies, the BIER-MPLS 316 label carried by the forwarded packet MUST have a TTL field whose 317 value is one less than that of the incoming TTL. 319 Of course, if the incoming TTL is 1, the packet MUST be treated as 320 a packet whose TTL has been exceeded. The packet MUST NOT be 321 forwarded, but it MAY be passed to other layers for processing 322 (e.g., to cause an ICMP message to be generated, and/or to invoke 323 BIER-specific traceroute procedures, and/or to invoke other OAM 324 procedures.) 326 2.1.2. Remainder of Encapsulation 328 Nibble: 330 This field is set to the binary value 0101; this ensures that the 331 MPLS ECMP logic will not confuse the remainder of the BIER header 332 with an IP header or with the header of a pseudowire packet. In 333 an MPLS network, if a BFR receives a BIER packet with any other 334 value in the first nibble after the label stack, it SHOULD discard 335 the packet and log an error. 337 Ver: 339 This 4-bit field identifies the version of the BIER header. This 340 document specifies version 0 of the BIER header. If a packet is 341 received by a particular BFR, and that BFR does not support the 342 specified version of the BIER header, the BFR MUST discard the 343 packet and log an error. 345 The value 0xF is reserved for experimental use; that value MUST 346 NOT be assigned by any future IETF document or by IANA. 348 BSL: 350 This 4-bit field encodes the length in bits of the BitString. 352 Note: When parsing the BIER header, a BFR MUST infer the length of 353 the BitString from the BIFT-id, and MUST NOT infer it from the 354 value of this field. This field is present only to enable off- 355 line tools (such as LAN analyzers) to parse the BIER header. 357 If k is the length of the BitString, the value of this field is 358 log2(k)-5. However, only certain values are supported: 360 1: 64 bits 362 2: 128 bits 364 3: 256 bits 366 4: 512 bits 368 5: 1024 bits 370 6: 2048 bits 372 7: 4096 bits 374 The value of this field MUST NOT be set to any value other than 375 those listed above. A received packet containing another value in 376 this field SHOULD be discarded, and an error logged. If the value 377 in this field is other than what is expected based on the BIER- 378 MPLS label, the packet SHOULD be discarded and an error logged. 380 Entropy: 382 This 20-bit field specifies an "entropy" value that can be used 383 for load balancing purposes. The BIER forwarding process may do 384 equal cost load balancing, in which case the load balancing 385 procedure MUST choose the same path for any two packets have the 386 same entropy value. 388 If a BFIR is encapsulating (as the payload) MPLS packets that have 389 entropy labels, the BFIR MUST ensure that if two such packets have 390 the same MPLS entropy label, they also have the same value of the 391 BIER entropy field. 393 OAM: 395 These two bits are used for the passive performance measurement 396 marking method described in [PPM]. 398 Rsv: 400 These 2 bits are currently unused. They SHOULD be set to zero 401 upon transmission, and MUST be ignored upon reception. 403 DSCP: 405 By default, this 6-bit field is not used in MPLS networks. The 406 default behavior is that all 6 bits SHOULD be set to zero upon 407 transmission, and MUST be ignored upon reception. 409 Non-default use of this field in MPLS networks is outside the 410 scope of this document. 412 Proto: 414 This 6-bit "Next Protocol" field identifies the type of the 415 payload. (The "payload" is the packet or frame immediately 416 following the BIER header.) IANA has been requested to create a 417 registry of "BIER Next Protocol Identifiers". This field is to be 418 populated with the appropriate entry from that registry. 420 If a BFER receives a BIER packet, but does not recognize (or does 421 not support) the value of the Next Protocol field, the BFER SHOULD 422 discard the packet and log an error. 424 BFIR-id: 426 By default, this is the BFR-id of the BFIR, in the SD to which the 427 packet has been assigned. The BFR-id is encoded in the 16-bit 428 field as an unsigned integer in the range [1,65535]. 430 Certain applications may require that the BFIR-id field contain 431 the BFR-id of a BFR other than the BFIR. However, that usage of 432 the BFIR-id field is outside the scope of the current document. 434 BitString: 436 The BitString that, together with the packet's SI and SD, 437 identifies the destination BFERs for this packet. Note that the 438 SI and SD for the packet are not carried explicitly in the BIER 439 header, as a particular BIFT-id always corresponds to a particular 440 SI and SD. 442 2.1.3. Further Encapsulating a BIER Packet 444 Sending a BIER packet from one BFR to another may require the packet 445 to be further encapsulated. For example: in some scenarios it may be 446 necessary to encapsulate a BIER packet in an ethernet frame; in other 447 scenarios it may be necessary to encapsulate a BIER packet in in a 448 UDP packet. In such cases, the BIER packet itself is the payload of 449 an "outer" encapsulation. 451 In this document, we assume that the frame or packet carrying a BIER 452 packet as its payload is a unicast frame or packet. That is, 453 although a BIER packet is a multicast packet, we assume that the 454 frame or packet carrying the BIER packet as its payload is unicast 455 from one BFR to the next. 457 Generally the outer encapsulation has a codepoint identifying the 458 "next protocol". The outer encapsulation's "next protocol" codepoint 459 for MPLS MUST be used. If a particular outer encapsulation has a 460 codepoint for "MPLS with Downstream-Assigned Label" and a different 461 codepoint for "MPLS with Upstream-Assigned Label", the codepoint for 462 "MPLS with Downstream-Assigned Label" MUST be used. 464 For example, if a BIER packet is encapsulated in an ethernet frame, 465 the ethertype MUST be 0x8847 ([RFC5332]), which is the ethertype for 466 a unicast ethernet frame that carries an MPLS packet whose label 467 stack beings with a downstream-assigned label. 469 In the special case where the outer encapsulation is MPLS, the outer 470 encapsulation has no "next protocol" codepoint. All that is needed 471 to encapsulate the BIER packet is to push more MPLS label stack 472 entries (with S bit clear) on the BIER packet's label stack. 474 2.2. In Non-MPLS Networks 476 2.2.1. Encapsulation Initial Four Octets 478 2.2.1.1. The BIFT-id 480 In non-MPLS networks, a BIFT-id MUST be assigned for every 481 combination of that is to be used in that network. The 482 correspondence between a BIFT-id and a particular 483 triple is unique throughout the BIER domain, and is known to all the 484 BFRs in the BIER domain. 486 The means by which the BIFT-ids are assigned, and the means by which 487 these assignments are made known to the BFRs, are outside the scope 488 of this document. 490 In an MPLS network, since the BIFT-id is an MPLS label, its value may 491 be changed as a BIER packet goes from BFR to BFR. In a non-MPLS 492 network, since the BIFT-id is domain-wide unique, it is not expected 493 to change as a BIER packet travels. 495 2.2.1.2. Other Fields of the Initial Four Octets 497 S bit: 499 The S bit has no significance in a non-MPLS network. It SHOULD be 500 set to 1 upon transmission, but it MUST be ignored upon reception. 502 TC: 504 By default, the TC field has no significance in a non-MPLS 505 network. The default behavior is that this field SHOULD be set to 506 the binary value 000 upon transmission, and MUST be ignored upon 507 reception. 509 Non-default use of this field in non-MPLS networks is outside the 510 scope of this document. 512 TTL: 514 This is the BIER "Time to Live" field. Its purpose is to prevent 515 BIER packets from looping indefinitely in the event of improper 516 operation of the control plane. When a BIER packet is received, 517 its "incoming TTL" (see below) is taken from this TTL field. 519 If the incoming TTL is 0 or 1, the packet MUST be treated as a 520 packet whose TTL has been exceeded. The packet MUST NOT be 521 forwarded, but it MAY be passed to other layers for processing 522 (e.g., to cause an ICMP message to be generated, and/or to invoke 523 BIER-specific traceroute procedures, and/or to invoke other OAM 524 procedures.) 526 If the packet is forwarded to one or more BFR adjacencies, the TTL 527 field of the packet MUST be set to a value that is one less than 528 the value of the incoming TTL. 530 2.2.2. Remainder of Encapsulation 532 Nibble: 534 This field SHOULD be set to 0000 upon transmission, but MUST be 535 ignored upon reception. 537 Ver: 539 See Section 2.1.2. 541 BSL: 543 See Section 2.1.2. 545 Entropy: 547 See Section 2.1.2. 549 OAM: 551 See Section 2.1.2. 553 Rsv: 555 See Section 2.1.2. 557 DSCP: 559 This 6-bit field MAY be used to hold a Differentiated Services 560 Codepoint ([RFC2474]). The significance of this field is outside 561 the scope of this document. 563 Proto: 565 See Section 2.1.2. 567 BFIR-id: 569 See Section 2.1.2. 571 BitString: 573 See Section 2.1.2. 575 2.2.3. Further Encapsulating a BIER Packet 577 Sending a BIER packet from one BFR to another may require the packet 578 to be further encapsulated. For example: in some scenarios it may be 579 necessary to encapsulate a BIER packet in an ethernet frame; in other 580 scenarios it may be necessary to encapsulate a BIER packet in in a 581 UDP packet. In such cases, the BIER packet itself is the payload of 582 an "outer" encapsulation. 584 In this document, we assume that the frame or packet carrying a BIER 585 packet as its payload is a unicast frame or packet. That is, 586 although a BIER packet is a multicast packet, we assume that the 587 frame or packet carrying the BIER packet as its payload is unicast 588 from one BFR to the next. 590 Generally the outer encapsulation has a codepoint identifying the 591 "next protocol". This codepoint MUST be set to a value that means 592 "Non-MPLS BIER". In particular, a codepoint that means "MPLS" (with 593 either upstream-assigned or downstream-assigned labels) MUST NOT be 594 used. 596 By requiring the use of a distinct codepoint for "non-MPLS BIER", we 597 allow for deployment scenarios where non-MPLS BIER can coexist with 598 non-BIER MPLS. The BIFT-id values used by the former will not 599 conflict with MPLS label values used by the latter. 601 As an example, if a non-MPLS BIER packet is encapsulated in an 602 ethernet header, the ethertype MUST NOT be 0x8847 or 0x8848 603 ([RFC5332]). Rather, a new ethertype would have to be assigned and 604 used. Specification of the layer 2 codepoints to be used for the 605 non-MPLS BIER encapsulation is outside the scope of this document. 607 In the special case where the outer encapsulation is MPLS, the outer 608 encapsulation has no "next protocol" codepoint. If it is necessary 609 to use MPLS as an outer encapsulation for BIER packets, it is 610 RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for 611 encapsulating a non-MPLS BIER packet in MPLS are outside the scope of 612 this document. 614 3. Imposing and Processing the BIER Encapsulation 616 When a BFIR receives a multicast packet from outside the BIER domain, 617 the BFIR carries out the following procedure: 619 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 620 determines the value of the "Proto" field. 622 2. By consulting the multicast flow overlay, it determines the set 623 of BFERs that must receive the packet. 625 3. If more than one SD is supported, the BFIR assigns the packet to 626 a particular SD. Procedures for determining the SD to which a 627 particular packet should be assigned are outside the scope of 628 this document. 630 4. The BFIR looks up the BFR-id, in the given SD, of each of the 631 BFERs. 633 5. The BFIR converts each such BFR-id into (SI, BitString) format, 634 as described in [BIER_ARCH]. 636 6. All such BFR-ids that have the same SI can be encoded into the 637 same BitString. Details of this encoding can be found in 638 [BIER_ARCH]. For each distinct SI that occurs in the list of the 639 packet's destination BFERs: 641 a. The BFIR makes a copy of the multicast data packet, and 642 encapsulates the copy in a BIER header (see Section 2). The 643 BIER header contains the BitString that represents all the 644 destination BFERs whose BFR-ids (in the given SD) correspond 645 to the given SI. It also contains the BFIR's BFIR-id in the 646 SD to which the packet has been assigned. 648 N.B.: For certain applications, it may be necessary for the 649 BFIR-id field to contain the BFR-id of a BFR other than the 650 BFIR that is creating the header. Such uses are outside the 651 scope of this document. 653 b. The BFIR then applies to that copy the forwarding procedure 654 of [BIER_ARCH]. This may result in one or more copies of 655 the packet (possibly with a modified BitString) being 656 transmitted to a neighboring BFR. 658 c. If the non-MPLS BIER encapsulation is being used, the BIFT- 659 id field is set to the BIFT-id that corresponds to the 660 packet's . The TTL is set according to policy. 662 If the MPLS BIER encapsulation is being used, the BFIR finds 663 the BIER-MPLS label that was advertised by the neighbor as 664 corresponding to the given . An MPLS label 665 stack is then prepended to the packet. This label stack 666 [RFC3032] will contain one label, the aforementioned BIER- 667 MPLS label. The "S" bit MUST be set, indicating the end of 668 the MPLS label stack. The TTL field of this label stack 669 entry is set according to policy. 671 d. The packet may then be transmitted to the neighboring BFR. 672 (In an MPLS network, this may result in additional MPLS 673 labels being pushed on the stack. For example, if an RSVP- 674 TE tunnel is used to transmit packets to the neighbor, a 675 label representing that tunnel would be pushed onto the 676 stack.) 678 When an intermediate BFR is processing a received MPLS packet, and 679 one of the BFR's own BIER-MPLS labels rises to the top of the label 680 stack, the BFR infers the BSL from the label. The SI and SD are also 681 implicitly identified by the label. The BFR then follows the 682 forwarding procedures of [BIER_ARCH]. If it forwards a copy of the 683 packet to a neighboring BFR, it first swaps the label at the top of 684 the label stack with the BIER-MPLS label, advertised by that 685 neighbor, that corresponds to the same . Note that when 686 this swap operation is done, the TTL field of the BIER-MPLS label of 687 the outgoing packet MUST be one less than the "incoming TTL" of the 688 packet, as defined in Section 2.1.1.1. 690 When an intermediate BFR is processing a received non-MPLS BIER 691 packet, the BFR infers the BSL from the BIFT-id. The SI and SD are 692 also implicitly identified by the BIFT-id. The BFR then follows the 693 forwarding procedures of [BIER_ARCH]. 695 Note that if the BIER payload is an MPLS packet, the BIER header is 696 followed by an MPLS label stack. This stack is separate from any 697 MPLS stack that may precede the BIER header. For an example of an 698 application where it is useful to carry an MPLS packet as the BIER 699 payload, see [BIER_MVPN]. 701 4. IANA Considerations 703 IANA is requested to set up a registry called "BIER Next Protocol 704 Identifiers". The registration policy for this registry is 705 "Standards Action" ([RFC5226] and [RFC7120]). 707 The initial values in the BIER Next Protocol Identifiers registry 708 are: 710 0: Reserved. 712 1: MPLS packet with downstream-assigned label at top of stack. 714 2: MPLS packet with upstream-assigned label at top of stack (see 715 [RFC5331]). If this value of the Proto field is used, the BFR-id 716 of the BFIR must be placed in the BFIR-id field. The BFIR-id 717 provides the "context" in which the upstream-assigned label is 718 interpreted. 720 3: Ethernet frame. 722 4: IPv4 packet. 724 5: OAM packet [BIER-OAM]. 726 6: IPv6 packet. 728 64: Reserved. 730 5. Security Considerations 732 Insofar as this document makes use of MPLS, it inherits any security 733 considerations that apply to the use of the MPLS data plane. 735 Insofar as this document makes use of IGP extensions, it inherits any 736 security considerations that apply to the IGP. 738 The security considerations of [BIER_ARCH] also apply. 740 6. Acknowledgements 742 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 743 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 744 Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to 745 this work. 747 7. Contributor Addresses 749 Below is a list of other contributing authors in alphabetical order: 751 Mach (Guoyi) Chen 752 Huawei 754 Email: mach.chen@huawei.com 756 Arkadiy Gulko 757 Thomson Reuters 758 195 Broadway 759 New York NY 10007 760 United States 762 Email: arkadiy.gulko@thomsonreuters.com 764 Wim Henderickx 765 Nokia 766 Copernicuslaan 50 767 Antwerp 2018 768 Belgium 770 Email: wim.henderickx@nokia.com 772 Martin Horneffer 773 Deutsche Telekom 774 Hammer Str. 216-226 775 Muenster 48153 776 Germany 778 Email: Martin.Horneffer@telekom.de 780 Uwe Joorde 781 Deutsche Telekom 782 Hammer Str. 216-226 783 Muenster D-48153 784 Germany 786 Email: Uwe.Joorde@telekom.de 788 Tony Przygienda 789 Juniper Networks, Inc. 790 1194 N. Mathilda Ave. 791 Sunnyvale, California 94089 792 United States 794 Email: prz@juniper.net 796 8. References 798 8.1. Normative References 800 [BIER_ARCH] 801 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 802 and S. Aldrin, "Multicast using Bit Index Explicit 803 Replication", internet-draft draft-ietf-bier-architecture- 804 05, October 2016. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 812 "Definition of the Differentiated Services Field (DS 813 Field) in the IPv4 and IPv6 Headers", RFC 2474, 814 DOI 10.17487/RFC2474, December 1998, 815 . 817 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 818 Label Switching Architecture", RFC 3031, 819 DOI 10.17487/RFC3031, January 2001, 820 . 822 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 823 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 824 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 825 . 827 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 828 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 829 DOI 10.17487/RFC5226, May 2008, 830 . 832 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 833 Label Assignment and Context-Specific Label Space", 834 RFC 5331, DOI 10.17487/RFC5331, August 2008, 835 . 837 [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 838 "MPLS Multicast Encapsulations", RFC 5332, 839 DOI 10.17487/RFC5332, August 2008, 840 . 842 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 843 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 844 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 845 2009, . 847 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 848 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 849 2014, . 851 8.2. Informative References 853 [BGP_BIER_EXTENSIONS] 854 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 855 Przygienda, "BGP Extensions for BIER", internet-draft 856 draft-ietf-bier-idr-extensions-01.txt, June 2016. 858 [BIER-OAM] 859 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 860 and G. Mirsky, "BIER Ping and Trace", internet-draft 861 draft-ietf-bier-ping-00.txt, July 2016. 863 [BIER_MVPN] 864 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 865 Dolganow, A., and T. Przygienda, "Multicast VPN Using 866 Bier", internet-draft draft-ietf-bier-mvpn-04, July 2016. 868 [ISIS_BIER_EXTENSIONS] 869 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 870 "BIER Support via ISIS", internet-draft draft-ietf-bier- 871 isis-extensions-03.txt, September 2016. 873 [OSPF_BIER_EXTENSIONS] 874 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 875 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 876 for Bit Index Explicit Replication", internet-draft draft- 877 ietf-ospf-bier-extensions-04.txt, September 2016. 879 [PPM] Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 880 Mizrahi, "IP Flow Performance Measurement Framework", 881 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 882 progress), March 2016. 884 Authors' Addresses 885 IJsbrand Wijnands (editor) 886 Cisco Systems, Inc. 887 De Kleetlaan 6a 888 Diegem 1831 889 Belgium 891 Email: ice@cisco.com 893 Eric C. Rosen (editor) 894 Juniper Networks, Inc. 895 10 Technology Park Drive 896 Westford, Massachusetts 01886 897 United States 899 Email: erosen@juniper.net 901 Andrew Dolganow 902 Nokia 903 600 March Rd. 904 Ottawa, Ontario K2K 2E6 905 Canada 907 Email: andrew.dolganow@nokia.com 909 Jeff Tantsura 910 Individual 912 Email: jefftant.ietf@gmail.com 914 Sam K Aldrin 915 Google, Inc. 916 1600 Amphitheatre Parkway 917 Mountain View, California 918 United States 920 Email: aldrin.ietf@gmail.com 922 Israel Meilik 923 Broadcom 925 Email: israel@broadcom.com