idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-07.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 (June 5, 2017) is 2517 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-01 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: December 7, 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 June 5, 2017 16 Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS 17 Networks 18 draft-ietf-bier-mpls-encapsulation-07 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 December 7, 2017. 54 Copyright Notice 56 Copyright (c) 2017 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 . . . . . . . 14 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 17 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 92 8.2. Informative References . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 If two BIER packets have the same value in the entropy field of their 475 respective BIER headers, and if both are placed in an outer 476 encapsulation, it is desirable for the outer encapsulation to 477 preserve the fact that the two packets have the same entropy. If the 478 outer encapsulation is MPLS, and if the MPLS entropy label 479 ([RFC6790]) is in use in a given deployment, one way to do this is to 480 copy the value of the BIER header entropy field into an MPLS entropy 481 label. 483 2.2. In Non-MPLS Networks 485 2.2.1. Encapsulation Initial Four Octets 487 2.2.1.1. The BIFT-id 489 In non-MPLS networks, a BIFT-id MUST be assigned for every 490 combination of that is to be used in that network. The 491 correspondence between a BIFT-id and a particular 492 triple is unique throughout the BIER domain, and is known to all the 493 BFRs in the BIER domain. 495 The means by which the BIFT-ids are assigned, and the means by which 496 these assignments are made known to the BFRs, are outside the scope 497 of this document. 499 In an MPLS network, since the BIFT-id is an MPLS label, its value may 500 be changed as a BIER packet goes from BFR to BFR. In a non-MPLS 501 network, since the BIFT-id is domain-wide unique, it is not expected 502 to change as a BIER packet travels. 504 2.2.1.2. Other Fields of the Initial Four Octets 506 S bit: 508 The S bit has no significance in a non-MPLS network. It SHOULD be 509 set to 1 upon transmission, but it MUST be ignored upon reception. 511 TC: 513 By default, the TC field has no significance in a non-MPLS 514 network. The default behavior is that this field SHOULD be set to 515 the binary value 000 upon transmission, and MUST be ignored upon 516 reception. 518 Non-default use of this field in non-MPLS networks is outside the 519 scope of this document. 521 TTL: 523 This is the BIER "Time to Live" field. Its purpose is to prevent 524 BIER packets from looping indefinitely in the event of improper 525 operation of the control plane. When a BIER packet is received, 526 its "incoming TTL" (see below) is taken from this TTL field. 528 If the incoming TTL is 0 or 1, the packet MUST be treated as a 529 packet whose TTL has been exceeded. The packet MUST NOT be 530 forwarded, but it MAY be passed to other layers for processing 531 (e.g., to cause an ICMP message to be generated, and/or to invoke 532 BIER-specific traceroute procedures, and/or to invoke other OAM 533 procedures.) 535 If the packet is forwarded to one or more BFR adjacencies, the TTL 536 field of the packet MUST be set to a value that is one less than 537 the value of the incoming TTL. 539 2.2.2. Remainder of Encapsulation 541 Nibble: 543 This field SHOULD be set to 0000 upon transmission, but MUST be 544 ignored upon reception. 546 Ver: 548 See Section 2.1.2. 550 BSL: 552 See Section 2.1.2. 554 Entropy: 556 See Section 2.1.2. 558 OAM: 560 See Section 2.1.2. 562 Rsv: 564 See Section 2.1.2. 566 DSCP: 568 This 6-bit field MAY be used to hold a Differentiated Services 569 Codepoint ([RFC2474]). The significance of this field is outside 570 the scope of this document. 572 Proto: 574 See Section 2.1.2. 576 BFIR-id: 578 See Section 2.1.2. 580 BitString: 582 See Section 2.1.2. 584 2.2.3. Further Encapsulating a BIER Packet 586 Sending a BIER packet from one BFR to another may require the packet 587 to be further encapsulated. For example: in some scenarios it may be 588 necessary to encapsulate a BIER packet in an ethernet frame; in other 589 scenarios it may be necessary to encapsulate a BIER packet in in a 590 UDP packet. In such cases, the BIER packet itself is the payload of 591 an "outer" encapsulation. 593 In this document, we assume that the frame or packet carrying a BIER 594 packet as its payload is a unicast frame or packet. That is, 595 although a BIER packet is a multicast packet, we assume that the 596 frame or packet carrying the BIER packet as its payload is unicast 597 from one BFR to the next. 599 Generally the outer encapsulation has a codepoint identifying the 600 "next protocol". This codepoint MUST be set to a value that means 601 "Non-MPLS BIER". In particular, a codepoint that means "MPLS" (with 602 either upstream-assigned or downstream-assigned labels) MUST NOT be 603 used. 605 By requiring the use of a distinct codepoint for "non-MPLS BIER", we 606 allow for deployment scenarios where non-MPLS BIER can coexist with 607 non-BIER MPLS. The BIFT-id values used by the former will not 608 conflict with MPLS label values used by the latter. 610 As an example, if a non-MPLS BIER packet is encapsulated in an 611 ethernet header, the ethertype MUST NOT be 0x8847 or 0x8848 612 ([RFC5332]). Rather, a new ethertype would have to be assigned and 613 used. Specification of the layer 2 codepoints to be used for the 614 non-MPLS BIER encapsulation is outside the scope of this document. 616 In the special case where the outer encapsulation is MPLS, the outer 617 encapsulation has no "next protocol" codepoint. If it is necessary 618 to use MPLS as an outer encapsulation for BIER packets, it is 619 RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for 620 encapsulating a non-MPLS BIER packet in MPLS are outside the scope of 621 this document. 623 If two BIER packets have the same value in the entropy field of their 624 respective BIER headers, and if both are placed in an outer 625 encapsulation, it is desirable for the outer encapsulation to 626 preserve the fact that the two packets have the same entropy. 628 3. Imposing and Processing the BIER Encapsulation 630 When a BFIR receives a multicast packet from outside the BIER domain, 631 the BFIR carries out the following procedure: 633 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 634 determines the value of the "Proto" field. 636 2. By consulting the multicast flow overlay, it determines the set 637 of BFERs that must receive the packet. 639 3. If more than one SD is supported, the BFIR assigns the packet to 640 a particular SD. Procedures for determining the SD to which a 641 particular packet should be assigned are outside the scope of 642 this document. 644 4. The BFIR looks up the BFR-id, in the given SD, of each of the 645 BFERs. 647 5. The BFIR converts each such BFR-id into (SI, BitString) format, 648 as described in [BIER_ARCH]. 650 6. All such BFR-ids that have the same SI can be encoded into the 651 same BitString. Details of this encoding can be found in 652 [BIER_ARCH]. For each distinct SI that occurs in the list of the 653 packet's destination BFERs: 655 a. The BFIR makes a copy of the multicast data packet, and 656 encapsulates the copy in a BIER header (see Section 2). The 657 BIER header contains the BitString that represents all the 658 destination BFERs whose BFR-ids (in the given SD) correspond 659 to the given SI. It also contains the BFIR's BFIR-id in the 660 SD to which the packet has been assigned. 662 N.B.: For certain applications, it may be necessary for the 663 BFIR-id field to contain the BFR-id of a BFR other than the 664 BFIR that is creating the header. Such uses are outside the 665 scope of this document. 667 b. The BFIR then applies to that copy the forwarding procedure 668 of [BIER_ARCH]. This may result in one or more copies of 669 the packet (possibly with a modified BitString) being 670 transmitted to a neighboring BFR. 672 c. If the non-MPLS BIER encapsulation is being used, the BIFT- 673 id field is set to the BIFT-id that corresponds to the 674 packet's . The TTL is set according to policy. 676 If the MPLS BIER encapsulation is being used, the BFIR finds 677 the BIER-MPLS label that was advertised by the neighbor as 678 corresponding to the given . An MPLS label 679 stack is then prepended to the packet. This label stack 680 [RFC3032] will contain one label, the aforementioned BIER- 681 MPLS label. The "S" bit MUST be set, indicating the end of 682 the MPLS label stack. The TTL field of this label stack 683 entry is set according to policy. 685 d. The packet may then be transmitted to the neighboring BFR. 686 (In an MPLS network, this may result in additional MPLS 687 labels being pushed on the stack. For example, if an RSVP- 688 TE tunnel is used to transmit packets to the neighbor, a 689 label representing that tunnel would be pushed onto the 690 stack.) 692 When an intermediate BFR is processing a received MPLS packet, and 693 one of the BFR's own BIER-MPLS labels rises to the top of the label 694 stack, the BFR infers the BSL from the label. The SI and SD are also 695 implicitly identified by the label. The BFR then follows the 696 forwarding procedures of [BIER_ARCH]. If it forwards a copy of the 697 packet to a neighboring BFR, it first swaps the label at the top of 698 the label stack with the BIER-MPLS label, advertised by that 699 neighbor, that corresponds to the same . Note that when 700 this swap operation is done, the TTL field of the BIER-MPLS label of 701 the outgoing packet MUST be one less than the "incoming TTL" of the 702 packet, as defined in Section 2.1.1.1. 704 When an intermediate BFR is processing a received non-MPLS BIER 705 packet, the BFR infers the BSL from the BIFT-id. The SI and SD are 706 also implicitly identified by the BIFT-id. The BFR then follows the 707 forwarding procedures of [BIER_ARCH]. 709 Note that if the BIER payload is an MPLS packet, the BIER header is 710 followed by an MPLS label stack. This stack is separate from any 711 MPLS stack that may precede the BIER header. For an example of an 712 application where it is useful to carry an MPLS packet as the BIER 713 payload, see [BIER_MVPN]. 715 4. IANA Considerations 717 IANA is requested to set up a registry called "BIER Next Protocol 718 Identifiers". The registration policy for this registry is 719 "Standards Action" ([RFC5226] and [RFC7120]). 721 The initial values in the BIER Next Protocol Identifiers registry 722 are: 724 0: Reserved. 726 1: MPLS packet with downstream-assigned label at top of stack. 728 2: MPLS packet with upstream-assigned label at top of stack (see 729 [RFC5331]). If this value of the Proto field is used, the BFR-id 730 of the BFIR must be placed in the BFIR-id field. The BFIR-id 731 provides the "context" in which the upstream-assigned label is 732 interpreted. 734 3: Ethernet frame. 736 4: IPv4 packet. 738 5: OAM packet [BIER-OAM]. 740 6: IPv6 packet. 742 64: Reserved. 744 5. Security Considerations 746 Insofar as this document makes use of MPLS, it inherits any security 747 considerations that apply to the use of the MPLS data plane. 749 Insofar as this document makes use of IGP extensions, it inherits any 750 security considerations that apply to the IGP. 752 The security considerations of [BIER_ARCH] also apply. 754 6. Acknowledgements 756 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 757 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 758 Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to 759 this work. 761 7. Contributor Addresses 763 Below is a list of other contributing authors in alphabetical order: 765 Mach (Guoyi) Chen 766 Huawei 768 Email: mach.chen@huawei.com 770 Arkadiy Gulko 771 Thomson Reuters 772 195 Broadway 773 New York NY 10007 774 United States 776 Email: arkadiy.gulko@thomsonreuters.com 778 Wim Henderickx 779 Nokia 780 Copernicuslaan 50 781 Antwerp 2018 782 Belgium 784 Email: wim.henderickx@nokia.com 786 Martin Horneffer 787 Deutsche Telekom 788 Hammer Str. 216-226 789 Muenster 48153 790 Germany 792 Email: Martin.Horneffer@telekom.de 794 Uwe Joorde 795 Deutsche Telekom 796 Hammer Str. 216-226 797 Muenster D-48153 798 Germany 800 Email: Uwe.Joorde@telekom.de 802 Tony Przygienda 803 Juniper Networks, Inc. 804 1194 N. Mathilda Ave. 805 Sunnyvale, California 94089 806 United States 808 Email: prz@juniper.net 810 8. References 812 8.1. Normative References 814 [BIER_ARCH] 815 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 816 and S. Aldrin, "Multicast using Bit Index Explicit 817 Replication", internet-draft draft-ietf-bier-architecture- 818 05, October 2016. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 826 "Definition of the Differentiated Services Field (DS 827 Field) in the IPv4 and IPv6 Headers", RFC 2474, 828 DOI 10.17487/RFC2474, December 1998, 829 . 831 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 832 Label Switching Architecture", RFC 3031, 833 DOI 10.17487/RFC3031, January 2001, 834 . 836 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 837 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 838 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 839 . 841 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 842 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 843 DOI 10.17487/RFC5226, May 2008, 844 . 846 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 847 Label Assignment and Context-Specific Label Space", 848 RFC 5331, DOI 10.17487/RFC5331, August 2008, 849 . 851 [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 852 "MPLS Multicast Encapsulations", RFC 5332, 853 DOI 10.17487/RFC5332, August 2008, 854 . 856 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 857 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 858 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 859 2009, . 861 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 862 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 863 2014, . 865 8.2. Informative References 867 [BGP_BIER_EXTENSIONS] 868 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 869 Przygienda, "BGP Extensions for BIER", internet-draft 870 draft-ietf-bier-idr-extensions-02.txt, June 2017. 872 [BIER-OAM] 873 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 874 and G. Mirsky, "BIER Ping and Trace", internet-draft 875 draft-ietf-bier-ping-01.txt, January 2017. 877 [BIER_MVPN] 878 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 879 Dolganow, A., and T. Przygienda, "Multicast VPN Using 880 Bier", internet-draft draft-ietf-bier-mvpn-05, January 881 2017. 883 [ISIS_BIER_EXTENSIONS] 884 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 885 "BIER Support via ISIS", internet-draft draft-ietf-bier- 886 isis-extensions-04.txt, March 2017. 888 [OSPF_BIER_EXTENSIONS] 889 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 890 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 891 for Bit Index Explicit Replication", internet-draft draft- 892 ietf-ospf-bier-extensions-05.txt, March 2017. 894 [PPM] Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 895 Mizrahi, "IP Flow Performance Measurement Framework", 896 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 897 progress), March 2016. 899 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 900 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 901 RFC 6790, DOI 10.17487/RFC6790, November 2012, 902 . 904 Authors' Addresses 906 IJsbrand Wijnands (editor) 907 Cisco Systems, Inc. 908 De Kleetlaan 6a 909 Diegem 1831 910 Belgium 912 Email: ice@cisco.com 914 Eric C. Rosen (editor) 915 Juniper Networks, Inc. 916 10 Technology Park Drive 917 Westford, Massachusetts 01886 918 United States 920 Email: erosen@juniper.net 922 Andrew Dolganow 923 Nokia 924 600 March Rd. 925 Ottawa, Ontario K2K 2E6 926 Canada 928 Email: andrew.dolganow@nokia.com 930 Jeff Tantsura 931 Individual 933 Email: jefftant.ietf@gmail.com 935 Sam K Aldrin 936 Google, Inc. 937 1600 Amphitheatre Parkway 938 Mountain View, California 939 United States 941 Email: aldrin.ietf@gmail.com 943 Israel Meilik 944 Broadcom 946 Email: israel@broadcom.com