idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-10.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 (October 18, 2017) is 2380 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 442 -- Looks like a reference, but probably isn't: '65535' on line 442 -- Looks like a reference, but probably isn't: '512' on line 226 == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-03 Summary: 0 errors (**), 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: Experimental E. Rosen, Ed. 5 Expires: April 21, 2018 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 October 18, 2017 16 Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS 17 Networks 18 draft-ietf-bier-mpls-encapsulation-10 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 https://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 April 21, 2018. 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 (https://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 . . . . . . . . . . . . . 8 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. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 8. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 17 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 9.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 [BIER_ARCH] describes a new architecture for the forwarding of 99 multicast data packets. Known as "Bit Index Explicit Replication" 100 (BIER), that architecture provides optimal forwarding of multicast 101 data packets through a "multicast domain". It does so without 102 requiring any explicit tree-building protocol and without requiring 103 intermediate nodes to maintain any per-flow state. 105 This document will use terminology defined in [BIER_ARCH]. 107 A router that supports BIER is known as a "Bit-Forwarding Router" 108 (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers 109 (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix 110 is a routable IP address of a BFR, and is used by BIER to identify a 111 BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and 112 leaves the BIER domain at one or more egress BFRs (BFERs). As 113 specified in [BIER_ARCH], each BFR of a given BIER domain is 114 provisioned to be in one or more "sub-domains" (SDs). In the context 115 of a given SD, each BFIR and BFER must have a BFR-id that is unique 116 within that SD. A BFR-id is just a number in the range [1,65535] 117 that, relative to a BIER SD, identifies a BFR uniquely. 119 As described in [BIER_ARCH], BIER requires that multicast data 120 packets be encapsulated with a header that provides the information 121 needed to support the BIER forwarding procedures. This information 122 includes the SD to which the packet has been assigned, a Set-Id (SI), 123 a BitString, and a BitStringLength (BSL). Together these values are 124 used to identify the set of BFERs to which the packet must be 125 delivered. 127 This document defines an encapsulation that can be used in either 128 MPLS networks or non-MPLS networks. However, the construction and 129 processing of the BIER header is slightly different in MPLS networks 130 than in non-MPLS networks. In particular: 132 o The handling of certain fields in the encapsulation header (the 133 "BIER header") is different depending upon whether the underlying 134 network is an MPLS network or not. 136 o In an MPLS network, the first four octets of a BIER header is also 137 the bottom entry (the last four octets) of an MPLS label stack. 139 The MPLS-based encapsulation is explained in detail in Section 2.1. 140 The differences between the MPLS-based encapsulation and the non-MPLS 141 encapsulation is explained in Section 2.2. 143 Following the BIER header is the "payload". The payload may be an 144 IPv4 packet, an IPv6 packet, an ethernet frame, an MPLS packet, or an 145 OAM packet. (The use of BIER with other payload types is also 146 possible, but is not further discussed in this document.) The BIER 147 header contains information (the Next Protocol field) identifying the 148 type of the payload. 150 If the payload is an MPLS packet, then an MPLS label stack 151 immediately follows the BIER header. The top label of this MPLS 152 label stack may be either a downstream-assigned label [RFC3032] or an 153 upstream-assigned label [RFC5331]. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 2. BIER Header 161 The BIER header is shown in Figure 1. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | BIFT-id | TC |S| TTL | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |Nibble | Ver | BSL | Entropy | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |OAM|Rsv| DSCP | Proto | BFIR-id | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | BitString (first 32 bits) ~ 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 ~ ~ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 ~ BitString (last 32 bits) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 1: BIER Header 181 The BIFT-id represents a particular Bit Index Forwarding 182 Table (BIFT); see Section 6.4 of [BIER_ARCH]. As explained in 183 [BIER_ARCH], each BIFT corresponds to a particular combination of SD, 184 BSL, and SI. 186 Section 2.1 explains how the fields of the encapsulation header are 187 used in MPLS networks. For those fields that are used differently in 188 non-MPLS networks, Section 2.2 explains the differences. 190 The default BitStringLength value for the encapsulations defined in 191 this document is 256. See Section 3 of [BIER_ARCH] for a discussion 192 of the default BitStringLength value. 194 2.1. In MPLS Networks 196 2.1.1. Encapsulation Initial Four Octets 198 2.1.1.1. The BIER-MPLS Label 200 As stated in [BIER_ARCH], when a BIER domain is also an IGP domain, 201 IGP extensions can be used by each BFR to advertise the BFR-id and 202 BFR-prefix. The extensions for OSPF are given in 203 [OSPF_BIER_EXTENSIONS]. The extensions for IS-IS are given in 204 [ISIS_BIER_EXTENSIONS]. 206 When a particular BIER domain is both an IGP domain and an MPLS 207 network, we assume that each BFR will also use IGP extensions to 208 advertise a set of one or more "BIER-MPLS" labels. When the domain 209 contains a single SD, a given BFR needs to advertise one such label 210 for each combination of SI and BSL. If the domain contains multiple 211 SDs, a BFR needs to advertise one such label per SI per BSL for each 212 SD. 214 In some environments, the only routing protocol in a BIER domain 215 might be BGP; in this case, the BGP extensions described in 216 [BGP_BIER_EXTENSIONS] can be used to advertise the necessary set of 217 BIER-MPLS labels. 219 The BIER-MPLS labels are locally significant (i.e., unique only to 220 the BFR that advertises them) downstream-assigned MPLS labels. 221 Penultimate hop popping ([RFC3031]) MUST NOT be applied to a BIER- 222 MPLS label. 224 Suppose for example that there is a single SD (the default SD), that 225 the network is using a BSL of 256, and that all BFERs in the SD have 226 BFR-ids in the range [1,512]. Since each BIER BitString is 256 bits 227 long, this requires the use of two SIs: SI=0 and SI=1. So each BFR 228 will advertise, via IGP extensions, two MPLS labels for BIER: one 229 corresponding to SI=0 and one corresponding to SI=1. The 230 advertisements of these labels will also bind each label to the 231 default SD and to the BSL 256. 233 As another example, suppose a particular BIER domain contains 2 SDs 234 (SD 0 and SD 1), supports 2 BSLs (256 and 512), and contains 1024 235 BFRs. A BFR that is provisioned for both SDs, and that supports both 236 BSLs, would have to advertise the following set of BIER-MPLS labels: 238 L1: corresponding to SD 0, BSL 256, SI 0. 240 L2: corresponding to SD 0, BSL 256, SI 1. 242 L3: corresponding to SD 0, BSL 256, SI 2. 244 L4: corresponding to SD 0, BSL 256, SI 3. 246 L5: corresponding to SD 0, BSL 512, SI 0. 248 L6: corresponding to SD 0, BSL 512, SI 1. 250 L7: corresponding to SD 1, BSL 256, SI 0. 252 L8: corresponding to SD 1, BSL 256, SI 1. 254 L9: corresponding to SD 1, BSL 256, SI 2. 256 L10: corresponding to SD 1, BSL 256, SI 3. 258 L11: corresponding to SD 1, BSL 512, SI 0. 260 L12: corresponding to SD 1, BSL 512, SI 1. 262 The above example should not be taken as implying that the BFRs need 263 to advertise 12 individual labels. For instance, instead of 264 advertising a label for and a label for , a BFR could advertise a contiguous range of labels 266 (in this case, a range containing exactly two labels) corresponding 267 to . The first label in the range could correspond to 268 SI 0, and the second to SI 1. The precise mechanism for generating 269 and forming the advertisements is outside the scope of this document. 270 See [OSPF_BIER_EXTENSIONS] and [ISIS_BIER_EXTENSIONS]. 272 The BIER-MPLS label corresponding to a particular combination of SD, 273 SI, and BSL is interpreted as representing the BIFT that corresponds 274 to that same combination of SD, SI, and BSL. That is, the BIER-MPLS 275 label performs the function of a BIFT-id. This label value is 276 carried in the BIFT-id field of the BIER encapsulation. 278 It is crucial to understand that in an MPLS network, the first four 279 octets of the BIER encapsulation header are also the last four octets 280 of the MPLS header. Therefore, any prior MPLS label stack entries 281 MUST have the S bit (see [RFC3032]) clear (i.e., the S bit must be 282 0). 284 When a BFR receives an MPLS packet, and the next label to be 285 processed is one of its BIER-MPLS labels, it will assume that the 286 remainder of the BIER header (see Section 2.1.2) immediately follows 287 the stack. 289 Note that in practice, labels only have to be assigned if they are 290 going to be used. If a particular BIER domain supports BSLs 256 and 291 512, but some SD, say SD 1, only uses BSL 256, then it is not 292 necessary to assign labels that correspond to the combination of SD 1 293 and BSL 512. 295 2.1.1.2. Other Fields of the Initial Four Octets 297 S bit: 299 When a BIER packet is traveling through an MPLS network, the high- 300 order 20 bits of the initial four octets of the BIER encapsulation 301 contain an MPLS label in the BIFT-id field. These four octets are 302 treated as the final entry in the packet's MPLS label stack. 303 Hence the S bit (see [RFC3032]) MUST be set to 1. If there are 304 any MPLS label stack entries immediately preceding the BIER 305 encapsulation, the S bit of those label stack entries MUST be set 306 to 0. 308 TC: 310 The "Traffic Class" field ([RFC5462]) has its usual meaning in an 311 MPLS label stack entry. 313 TTL: 315 This is the usual MPLS "Time to Live" field ([RFC3032]). When a 316 BIER packet is received, its "incoming TTL" (see below) is taken 317 from this TTL field. 319 The BFR MUST perform the MPLS TTL processing correctly. If the 320 packet is forwarded to one or more BFR adjacencies, the BIER-MPLS 321 label carried by the forwarded packet MUST have a TTL field whose 322 value is one less than that of the incoming TTL. 324 Of course, if the incoming TTL is 1, the packet MUST be treated as 325 a packet whose TTL has been exceeded. The packet MUST NOT be 326 forwarded, but it MAY be passed to other layers for processing 327 (e.g., to cause an ICMP message to be generated, and/or to invoke 328 BIER-specific traceroute procedures, and/or to invoke other OAM 329 procedures.) 331 2.1.2. Remainder of Encapsulation 333 Nibble: 335 This field is set to the binary value 0101; this ensures that the 336 MPLS ECMP logic will not confuse the remainder of the BIER header 337 with an IP header or with the header of a pseudowire packet. In 338 an MPLS network, if a BFR receives a BIER packet with any other 339 value in the first nibble after the label stack, it SHOULD discard 340 the packet and log an error. 342 Ver: 344 This 4-bit field identifies the version of the BIER header. This 345 document specifies version 0 of the BIER header. If a packet is 346 received by a particular BFR, and that BFR does not support the 347 specified version of the BIER header, the BFR MUST discard the 348 packet and log an error. 350 The value 0xF is reserved for experimental use; that value MUST 351 NOT be assigned by any future IETF document or by IANA. 353 BSL: 355 This 4-bit field encodes the length in bits of the BitString. 357 Note: When parsing the BIER header, a BFR MUST infer the length of 358 the BitString from the BIFT-id, and MUST NOT infer it from the 359 value of this field. This field is present only to enable off- 360 line tools (such as LAN analyzers) to parse the BIER header. 362 If k is the length of the BitString, the value of this field is 363 log2(k)-5. However, only certain values are supported: 365 1: 64 bits 367 2: 128 bits 369 3: 256 bits 371 4: 512 bits 373 5: 1024 bits 375 6: 2048 bits 377 7: 4096 bits 379 The value of this field MUST NOT be set to any value other than 380 those listed above. A received packet containing another value in 381 this field SHOULD be discarded, and an error logged. If the value 382 in this field is other than what is expected based on the BIER- 383 MPLS label, the packet SHOULD be discarded and an error logged. 385 Entropy: 387 This 20-bit field specifies an "entropy" value that can be used 388 for load balancing purposes. The BIER forwarding process may do 389 equal cost load balancing, in which case the load balancing 390 procedure MUST choose the same path for any two packets that have 391 the same entropy value and the same BitString. Please see 392 Section 6.7 ("Equal Cost Multi-path Forwarding") of [BIER_ARCH] 393 for a more detailed discussion of BIER load balancing procedures. 395 If a BFIR is encapsulating (as the payload) MPLS packets that have 396 entropy labels, the BFIR MUST ensure that if two such packets have 397 the same MPLS entropy label, they also have the same value of the 398 BIER entropy field. 400 OAM: 402 By default, these two bits are set to zero by the BFIR, and are 403 not modified by other BFRs. These two bits have no effect on the 404 path taken by a BIER packet, and have no effect on the quality of 405 service applied to a BIER packet. 407 The use of these bits in other than the default manner is 408 OPTIONAL. Specification of the non-default use or uses of these 409 bits is outside the scope of this document. (See [BIER-PMM] for 410 an example of such a specification.) 412 Rsv: 414 These 2 bits are currently unused. They SHOULD be set to zero 415 upon transmission, and MUST be ignored upon reception. 417 DSCP: 419 By default, this 6-bit field is not used in MPLS networks. The 420 default behavior is that all 6 bits SHOULD be set to zero upon 421 transmission, and MUST be ignored upon reception. 423 Non-default use of this field in MPLS networks is outside the 424 scope of this document. 426 Proto: 428 This 6-bit "Next Protocol" field identifies the type of the 429 payload. (The "payload" is the packet or frame immediately 430 following the BIER header.) IANA has been requested to create a 431 registry of "BIER Next Protocol Identifiers". This field is to be 432 populated with the appropriate entry from that registry. 434 If a BFER receives a BIER packet, but does not recognize (or does 435 not support) the value of the Next Protocol field, the BFER SHOULD 436 discard the packet and log an error. 438 BFIR-id: 440 By default, this is the BFR-id of the BFIR, in the SD to which the 441 packet has been assigned. The BFR-id is encoded in the 16-bit 442 field as an unsigned integer in the range [1,65535]. 444 Certain applications may require that the BFIR-id field contain 445 the BFR-id of a BFR other than the BFIR. However, that usage of 446 the BFIR-id field is outside the scope of the current document. 448 BitString: 450 The BitString that, together with the packet's SI and SD, 451 identifies the destination BFERs for this packet. Note that the 452 SI and SD for the packet are not carried explicitly in the BIER 453 header, as a particular BIFT-id always corresponds to a particular 454 SI and SD. 456 2.1.3. Further Encapsulating a BIER Packet 458 Sending a BIER packet from one BFR to another may require the packet 459 to be further encapsulated. For example: in some scenarios it may be 460 necessary to encapsulate a BIER packet in an ethernet frame; in other 461 scenarios it may be necessary to encapsulate a BIER packet in a UDP 462 packet. In such cases, the BIER packet itself is the payload of an 463 "outer" encapsulation. 465 In this document, we assume that the frame or packet carrying a BIER 466 packet as its payload is a unicast frame or packet. That is, 467 although a BIER packet is a multicast packet, we assume that the 468 frame or packet carrying the BIER packet as its payload is unicast 469 from one BFR to the next. 471 Generally the outer encapsulation has a codepoint identifying the 472 "next protocol". The outer encapsulation's "next protocol" codepoint 473 for MPLS MUST be used. If a particular outer encapsulation has a 474 codepoint for "MPLS with Downstream-Assigned Label" and a different 475 codepoint for "MPLS with Upstream-Assigned Label", the codepoint for 476 "MPLS with Downstream-Assigned Label" MUST be used. 478 For example, if a BIER packet is encapsulated in an ethernet frame, 479 the ethertype MUST be 0x8847 ([RFC5332]), which is the ethertype for 480 a unicast ethernet frame that carries an MPLS packet whose label 481 stack beings with a downstream-assigned label. 483 In the special case where the outer encapsulation is MPLS, the outer 484 encapsulation has no "next protocol" codepoint. All that is needed 485 to encapsulate the BIER packet is to push more MPLS label stack 486 entries (with S bit clear) on the BIER packet's label stack. 488 If two BIER packets have the same value in the entropy field of their 489 respective BIER headers, and if both are placed in an outer 490 encapsulation, it is desirable for the outer encapsulation to 491 preserve the fact that the two packets have the same entropy. If the 492 outer encapsulation is MPLS, and if the MPLS entropy label 493 ([RFC6790]) is in use in a given deployment, one way to do this is to 494 copy the value of the BIER header entropy field into an MPLS entropy 495 label. 497 2.2. In Non-MPLS Networks 499 2.2.1. Encapsulation Initial Four Octets 501 2.2.1.1. The BIFT-id 503 In non-MPLS networks, a BIFT-id MUST be assigned for every 504 combination of that is to be used in that network. The 505 correspondence between a BIFT-id and a particular 506 triple is unique throughout the BIER domain, and is known to all the 507 BFRs in the BIER domain. 509 The means by which the BIFT-ids are assigned, and the means by which 510 these assignments are made known to the BFRs, are outside the scope 511 of this document. 513 In an MPLS network, since the BIFT-id is an MPLS label, its value may 514 be changed as a BIER packet goes from BFR to BFR. In a non-MPLS 515 network, since the BIFT-id is domain-wide unique, it is not expected 516 to change as a BIER packet travels. 518 2.2.1.2. Other Fields of the Initial Four Octets 520 S bit: 522 The S bit has no significance in a non-MPLS network. It SHOULD be 523 set to 1 upon transmission, but it MUST be ignored upon reception. 525 TC: 527 By default, the TC field has no significance in a non-MPLS 528 network. The default behavior is that this field SHOULD be set to 529 the binary value 000 upon transmission, and MUST be ignored upon 530 reception. 532 Non-default use of this field in non-MPLS networks is outside the 533 scope of this document. 535 TTL: 537 This is the BIER "Time to Live" field. Its purpose is to prevent 538 BIER packets from looping indefinitely in the event of improper 539 operation of the control plane. When a BIER packet is received, 540 its "incoming TTL" (see below) is taken from this TTL field. 542 If the incoming TTL is 0 or 1, the packet MUST be treated as a 543 packet whose TTL has been exceeded. The packet MUST NOT be 544 forwarded, but it MAY be passed to other layers for processing 545 (e.g., to cause an ICMP message to be generated, and/or to invoke 546 BIER-specific traceroute procedures, and/or to invoke other OAM 547 procedures.) 549 If the packet is forwarded to one or more BFR adjacencies, the TTL 550 field of the packet MUST be set to a value that is one less than 551 the value of the incoming TTL. 553 2.2.2. Remainder of Encapsulation 555 Nibble: 557 This field SHOULD be set to 0000 upon transmission, but MUST be 558 ignored upon reception. 560 Ver: 562 See Section 2.1.2. 564 BSL: 566 See Section 2.1.2. 568 Entropy: 570 See Section 2.1.2. 572 OAM: 574 See Section 2.1.2. 576 Rsv: 578 See Section 2.1.2. 580 DSCP: 582 This 6-bit field MAY be used to hold a Differentiated Services 583 Codepoint ([RFC2474]). The significance of this field is outside 584 the scope of this document. 586 Proto: 588 See Section 2.1.2. 590 BFIR-id: 592 See Section 2.1.2. 594 BitString: 596 See Section 2.1.2. 598 2.2.3. Further Encapsulating a BIER Packet 600 Sending a BIER packet from one BFR to another may require the packet 601 to be further encapsulated. For example: in some scenarios it may be 602 necessary to encapsulate a BIER packet in an ethernet frame; in other 603 scenarios it may be necessary to encapsulate a BIER packet in in a 604 UDP packet. In such cases, the BIER packet itself is the payload of 605 an "outer" encapsulation. 607 In this document, we assume that the frame or packet carrying a BIER 608 packet as its payload is a unicast frame or packet. That is, 609 although a BIER packet is a multicast packet, we assume that the 610 frame or packet carrying the BIER packet as its payload is unicast 611 from one BFR to the next. 613 Generally the outer encapsulation has a codepoint identifying the 614 "next protocol". This codepoint MUST be set to a value that means 615 "Non-MPLS BIER". In particular, a codepoint that means "MPLS" (with 616 either upstream-assigned or downstream-assigned labels) MUST NOT be 617 used. 619 By requiring the use of a distinct codepoint for "non-MPLS BIER", we 620 allow for deployment scenarios where non-MPLS BIER can coexist with 621 non-BIER MPLS. The BIFT-id values used by the former will not 622 conflict with MPLS label values used by the latter. 624 Therefore, if a non-MPLS BIER packet is encapsulated in an ethernet 625 header, the ethertype MUST NOT be 0x8847 or 0x8848 ([RFC5332]). IEEE 626 has been requested to assign ethertype TBD1 for non-MPLS BIER 627 packets. 629 In the special case where the outer encapsulation is MPLS, the outer 630 encapsulation has no "next protocol" codepoint. If it is necessary 631 to use MPLS as an outer encapsulation for BIER packets, it is 632 RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for 633 encapsulating a non-MPLS BIER packet in MPLS are outside the scope of 634 this document. 636 If two BIER packets have the same value in the entropy field of their 637 respective BIER headers, and if both are placed in an outer 638 encapsulation, it is desirable for the outer encapsulation to 639 preserve the fact that the two packets have the same entropy. 641 3. Imposing and Processing the BIER Encapsulation 643 When a BFIR receives a multicast packet from outside the BIER domain, 644 the BFIR carries out the following procedure: 646 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 647 determines the value of the "Proto" field. 649 2. By consulting the multicast flow overlay, it determines the set 650 of BFERs that must receive the packet. 652 3. If more than one SD is supported, the BFIR assigns the packet to 653 a particular SD. Procedures for determining the SD to which a 654 particular packet should be assigned are outside the scope of 655 this document. 657 4. The BFIR looks up the BFR-id, in the given SD, of each of the 658 BFERs. 660 5. The BFIR converts each such BFR-id into (SI, BitString) format, 661 as described in [BIER_ARCH]. 663 6. All such BFR-ids that have the same SI can be encoded into the 664 same BitString. Details of this encoding can be found in 665 [BIER_ARCH]. For each distinct SI that occurs in the list of the 666 packet's destination BFERs: 668 a. The BFIR makes a copy of the multicast data packet, and 669 encapsulates the copy in a BIER header (see Section 2). The 670 BIER header contains the BitString that represents all the 671 destination BFERs whose BFR-ids (in the given SD) correspond 672 to the given SI. It also contains the BFIR's BFR-id in the 673 SD to which the packet has been assigned. 675 N.B.: For certain applications, it may be necessary for the 676 BFIR-id field to contain the BFR-id of a BFR other than the 677 BFIR that is creating the header. Such uses are outside the 678 scope of this document. 680 b. The BFIR then applies to that copy the forwarding procedure 681 of [BIER_ARCH]. This may result in one or more copies of 682 the packet (possibly with a modified BitString) being 683 transmitted to a neighboring BFR. 685 c. If the non-MPLS BIER encapsulation is being used, the BIFT- 686 id field is set to the BIFT-id that corresponds to the 687 packet's . The TTL is set according to policy. 689 If the MPLS BIER encapsulation is being used, the BFIR finds 690 the BIER-MPLS label that was advertised by the neighbor as 691 corresponding to the given . An MPLS label 692 stack is then prepended to the packet. This label stack 693 [RFC3032] will contain one label, the aforementioned BIER- 694 MPLS label. The "S" bit MUST be set, indicating the end of 695 the MPLS label stack. The TTL field of this label stack 696 entry is set according to policy. 698 d. The packet may then be transmitted to the neighboring BFR. 699 (In an MPLS network, this may result in additional MPLS 700 labels being pushed on the stack. For example, if an RSVP- 701 TE tunnel is used to transmit packets to the neighbor, a 702 label representing that tunnel would be pushed onto the 703 stack.) 705 When an intermediate BFR is processing a received MPLS packet, and 706 one of the BFR's own BIER-MPLS labels rises to the top of the label 707 stack, the BFR infers the BSL from the label. The SI and SD are also 708 implicitly identified by the label. The BFR then follows the 709 forwarding procedures of [BIER_ARCH]. If it forwards a copy of the 710 packet to a neighboring BFR, it first swaps the label at the top of 711 the label stack with the BIER-MPLS label, advertised by that 712 neighbor, that corresponds to the same . Note that when 713 this swap operation is done, the TTL field of the BIER-MPLS label of 714 the outgoing packet MUST be one less than the "incoming TTL" of the 715 packet, as defined in Section 2.1.1.1. 717 When an intermediate BFR is processing a received non-MPLS BIER 718 packet, the BFR infers the BSL from the BIFT-id. The SI and SD are 719 also implicitly identified by the BIFT-id. The BFR then follows the 720 forwarding procedures of [BIER_ARCH]. 722 If the BIER payload is an MPLS packet, the BIER header is followed by 723 an MPLS label stack. This stack is separate from any MPLS stack that 724 may precede the BIER header. For an example of an application where 725 it is useful to carry an MPLS packet as the BIER payload, see 726 [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that 727 the payload is an MPLS packet with an upstream-assigned at the top of 728 the stack, the upstream-assigned label is interpreted in the context 729 of . Note that the sub-domain-id must be 730 inferred from the BIFT-id. 732 4. IANA Considerations 734 IANA is requested to set up a registry called "BIER Next Protocol 735 Identifiers". The registration policy for this registry is "IETF 736 Review" ([RFC8126] and [RFC7120]). 738 Values in this registry must come from the range 0-63. 740 The initial values in the BIER Next Protocol Identifiers registry 741 are: 743 0: Reserved (not to be assigned by IANA). 745 1: MPLS packet with downstream-assigned label at top of stack. 747 2: MPLS packet with upstream-assigned label at top of stack 749 3: Ethernet frame. 751 4: IPv4 packet. 753 5: OAM packet (reference: [BIER_PING]) 755 6: IPv6 packet. 757 63: Reserved (not to be assigned by IANA). 759 5. IEEE Considerations 761 IEEE has been requested to assign ethertype TBD1 for non-MPLS BIER 762 packets. 764 6. Security Considerations 766 Insofar as this document makes use of MPLS, it inherits any security 767 considerations that apply to the use of the MPLS data plane. 769 Insofar as this document makes use of IGP extensions, it inherits any 770 security considerations that apply to the IGP. 772 The security considerations of [BIER_ARCH] also apply. 774 7. Acknowledgements 776 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 777 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 778 Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to 779 this work. 781 8. Contributor Addresses 783 Below is a list of other contributing authors in alphabetical order: 785 Mach (Guoyi) Chen 786 Huawei 788 Email: mach.chen@huawei.com 790 Arkadiy Gulko 791 Thomson Reuters 792 195 Broadway 793 New York NY 10007 794 United States 796 Email: arkadiy.gulko@thomsonreuters.com 798 Wim Henderickx 799 Nokia 800 Copernicuslaan 50 801 Antwerp 2018 802 Belgium 804 Email: wim.henderickx@nokia.com 806 Martin Horneffer 807 Deutsche Telekom 808 Hammer Str. 216-226 809 Muenster 48153 810 Germany 812 Email: Martin.Horneffer@telekom.de 814 Uwe Joorde 815 Deutsche Telekom 816 Hammer Str. 216-226 817 Muenster D-48153 818 Germany 820 Email: Uwe.Joorde@telekom.de 822 Tony Przygienda 823 Juniper Networks, Inc. 824 1194 N. Mathilda Ave. 825 Sunnyvale, California 94089 826 United States 828 Email: prz@juniper.net 830 9. References 832 9.1. Normative References 834 [BIER_ARCH] 835 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 836 and S. Aldrin, "Multicast using Bit Index Explicit 837 Replication", internet-draft draft-ietf-bier-architecture- 838 08, September 2017. 840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, 842 DOI 10.17487/RFC2119, March 1997, 843 . 845 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 846 "Definition of the Differentiated Services Field (DS 847 Field) in the IPv4 and IPv6 Headers", RFC 2474, 848 DOI 10.17487/RFC2474, December 1998, 849 . 851 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 852 Label Switching Architecture", RFC 3031, 853 DOI 10.17487/RFC3031, January 2001, 854 . 856 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 857 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 858 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 859 . 861 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 862 Label Assignment and Context-Specific Label Space", 863 RFC 5331, DOI 10.17487/RFC5331, August 2008, 864 . 866 [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 867 "MPLS Multicast Encapsulations", RFC 5332, 868 DOI 10.17487/RFC5332, August 2008, 869 . 871 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 872 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 873 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 874 2009, . 876 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 877 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 878 2014, . 880 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 881 Writing an IANA Considerations Section in RFCs", BCP 26, 882 RFC 8126, DOI 10.17487/RFC8126, June 2017, 883 . 885 9.2. Informative References 887 [BGP_BIER_EXTENSIONS] 888 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 889 Przygienda, "BGP Extensions for BIER", internet-draft 890 draft-ietf-bier-idr-extensions-03.txt, August 2017. 892 [BIER-PMM] 893 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "IP Flow 894 Performance Measurement Framework", draft-ietf-bier-pmmm- 895 oam-03 (work in progress), October 2017. 897 [BIER_MVPN] 898 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 899 Dolganow, A., and T. Przygienda, "Multicast VPN Using 900 Bier", internet-draft draft-ietf-bier-mvpn-07, July 2017. 902 [BIER_PING] 903 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 904 and G. Mirsky, "BIER Ping and Trace", internet-draft 905 draft-ietf-bier-ping-02.txt, July 2017. 907 [ISIS_BIER_EXTENSIONS] 908 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 909 "BIER Support via IS-IS", internet-draft draft-ietf-bier- 910 isis-extensions-05.txt, July 2017. 912 [OSPF_BIER_EXTENSIONS] 913 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 914 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 915 for Bit Index Explicit Replication", internet-draft draft- 916 ietf-ospf-bier-extensions-07.txt, July 2017. 918 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 919 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 920 RFC 6790, DOI 10.17487/RFC6790, November 2012, 921 . 923 Authors' Addresses 925 IJsbrand Wijnands (editor) 926 Cisco Systems, Inc. 927 De Kleetlaan 6a 928 Diegem 1831 929 Belgium 931 Email: ice@cisco.com 933 Eric C. Rosen (editor) 934 Juniper Networks, Inc. 935 10 Technology Park Drive 936 Westford, Massachusetts 01886 937 United States 939 Email: erosen@juniper.net 941 Andrew Dolganow 942 Nokia 943 438B Alexandra Rd #08-07/10 944 Alexandra Technopark 945 Singapore 119968 947 Email: andrew.dolganow@nokia.com 949 Jeff Tantsura 950 Individual 952 Email: jefftant.ietf@gmail.com 954 Sam K Aldrin 955 Google, Inc. 956 1600 Amphitheatre Parkway 957 Mountain View, California 958 United States 960 Email: aldrin.ietf@gmail.com 962 Israel Meilik 963 Broadcom 965 Email: israel@broadcom.com