idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-12.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 27, 2017) is 2373 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 457 -- Looks like a reference, but probably isn't: '65535' on line 457 -- 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 30, 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 27, 2017 16 Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS 17 Networks 18 draft-ietf-bier-mpls-encapsulation-12 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 30, 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 . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 17 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 90 8. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 18 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 9.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 TC: 299 The "Traffic Class" field ([RFC5462]) has its usual meaning in an 300 MPLS label stack entry. 302 S bit: 304 When a BIER packet is traveling through an MPLS network, the high- 305 order 20 bits of the initial four octets of the BIER encapsulation 306 contain an MPLS label in the BIFT-id field. These four octets are 307 treated as the final entry in the packet's MPLS label stack. 308 Hence the S bit (see [RFC3032]) MUST be set to 1. If there are 309 any MPLS label stack entries immediately preceding the BIER 310 encapsulation, the S bit of those label stack entries MUST be set 311 to 0. 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 When a BIER packet is forwarded to one or more BFR adjacencies, 320 the BIER-MPLS label carried by the forwarded packet MUST have a 321 TTL field whose value is one less than that of the packet's 322 incoming TTL. 324 If a BIER packet's incoming TTL is 1 or greater, and one of the 325 bits in its BitString identifies the current BFR, then the current 326 BFR is a BFER for the packet. Therefore the current BFR MUST 327 process the packet as a BFER, e.g., by removing the BIER 328 encapsulation and processing the payload based on the contents of 329 the Proto field. 331 If the incoming TTL is 0, the packet is considered to be 332 "expired". If the incoming TTL is 1, and the BitString has a bit 333 set that does not identify the current BFR, the packet is also 334 considered to be expired. Expired packets SHOULD be passed to an 335 error handling procedure. (Optional implementation-specific rate 336 limiting may be applied to control the rate at which packets are 337 passed to the error handling procedure.) Specification of the 338 error handling procedure is outside the scope of this document. 340 Note that if a received BIER packet has an incoming TTL of 1, and 341 its BitString has a bit set identifying the current BFR, the 342 payload MUST be processed by the current BFR, but the packet MUST 343 NOT be forwarded further, and the packet SHOULD also be passed to 344 the error handling procedures for expired packets (subject to any 345 implementation-specific rate limiting). 347 2.1.2. Remainder of Encapsulation 349 Nibble: 351 This field is set to the binary value 0101; this ensures that the 352 MPLS ECMP logic will not confuse the remainder of the BIER header 353 with an IP header or with the header of a pseudowire packet. In 354 an MPLS network, if a BFR receives a BIER packet with any other 355 value in the first nibble after the label stack, it SHOULD discard 356 the packet and log an error. 358 Ver: 360 This 4-bit field identifies the version of the BIER header. This 361 document specifies version 0 of the BIER header. If a packet is 362 received by a particular BFR, and that BFR does not support the 363 specified version of the BIER header, the BFR MUST discard the 364 packet and log an error. 366 The value 0xF is reserved for experimental use; that value MUST 367 NOT be assigned by any future IETF document or by IANA. 369 BSL: 371 This 4-bit field encodes the length in bits of the BitString. 373 Note: When parsing the BIER header, a BFR MUST infer the length of 374 the BitString from the BIFT-id, and MUST NOT infer it from the 375 value of this field. This field is present only to enable off- 376 line tools (such as LAN analyzers) to parse the BIER header. 378 If k is the length of the BitString, the value of this field is 379 log2(k)-5. However, only certain values are supported: 381 1: 64 bits 382 2: 128 bits 384 3: 256 bits 386 4: 512 bits 388 5: 1024 bits 390 6: 2048 bits 392 7: 4096 bits 394 The value of this field MUST NOT be set to any value other than 395 those listed above. A received packet containing another value in 396 this field SHOULD be discarded, and an error logged. If the value 397 in this field is other than what is expected based on the BIER- 398 MPLS label, the packet SHOULD be discarded and an error logged. 400 Entropy: 402 This 20-bit field specifies an "entropy" value that can be used 403 for load balancing purposes. The BIER forwarding process may do 404 equal cost load balancing, in which case the load balancing 405 procedure MUST choose the same path for any two packets that have 406 the same entropy value and the same BitString. Please see 407 Section 6.7 ("Equal Cost Multi-path Forwarding") of [BIER_ARCH] 408 for a more detailed discussion of BIER load balancing procedures. 410 If a BFIR is encapsulating (as the payload) MPLS packets that have 411 entropy labels, the BFIR MUST ensure that if two such packets have 412 the same MPLS entropy label, they also have the same value of the 413 BIER entropy field. 415 OAM: 417 By default, these two bits are set to zero by the BFIR, and are 418 not modified by other BFRs. These two bits have no effect on the 419 path taken by a BIER packet, and have no effect on the quality of 420 service applied to a BIER packet. 422 The use of these bits in other than the default manner is 423 OPTIONAL. Specification of the non-default use or uses of these 424 bits is outside the scope of this document. (See [BIER-PMM] for 425 an example of such a specification.) 427 Rsv: 429 These 2 bits are currently unused. They SHOULD be set to zero 430 upon transmission, and MUST be ignored upon reception. 432 DSCP: 434 By default, this 6-bit field is not used in MPLS networks. The 435 default behavior is that all 6 bits SHOULD be set to zero upon 436 transmission, and MUST be ignored upon reception. 438 Non-default use of this field in MPLS networks is outside the 439 scope of this document. 441 Proto: 443 This 6-bit "Next Protocol" field identifies the type of the 444 payload. (The "payload" is the packet or frame immediately 445 following the BIER header.) IANA has been requested to create a 446 registry of "BIER Next Protocol Identifiers". This field is to be 447 populated with the appropriate entry from that registry. 449 If a BFER receives a BIER packet, but does not recognize (or does 450 not support) the value of the Next Protocol field, the BFER SHOULD 451 discard the packet and log an error. 453 BFIR-id: 455 By default, this is the BFR-id of the BFIR, in the SD to which the 456 packet has been assigned. The BFR-id is encoded in the 16-bit 457 field as an unsigned integer in the range [1,65535]. 459 Certain applications may require that the BFIR-id field contain 460 the BFR-id of a BFR other than the BFIR. However, that usage of 461 the BFIR-id field is outside the scope of the current document. 463 BitString: 465 The BitString that, together with the packet's SI and SD, 466 identifies the destination BFERs for this packet. Note that the 467 SI and SD for the packet are not carried explicitly in the BIER 468 header, as a particular BIFT-id always corresponds to a particular 469 SI and SD. 471 2.1.3. Further Encapsulating a BIER Packet 473 Sending a BIER packet from one BFR to another may require the packet 474 to be further encapsulated. For example: in some scenarios it may be 475 necessary to encapsulate a BIER packet in an ethernet frame; in other 476 scenarios it may be necessary to encapsulate a BIER packet in a UDP 477 packet. In such cases, the BIER packet itself is the payload of an 478 "outer" encapsulation. 480 In this document, we assume that the frame or packet carrying a BIER 481 packet as its payload is a unicast frame or packet. That is, 482 although a BIER packet is a multicast packet, we assume that the 483 frame or packet carrying the BIER packet as its payload is unicast 484 from one BFR to the next. 486 Generally the outer encapsulation has a codepoint identifying the 487 "next protocol". The outer encapsulation's "next protocol" codepoint 488 for MPLS MUST be used. If a particular outer encapsulation has a 489 codepoint for "MPLS with Downstream-Assigned Label" and a different 490 codepoint for "MPLS with Upstream-Assigned Label", the codepoint for 491 "MPLS with Downstream-Assigned Label" MUST be used. 493 For example, if a BIER packet is encapsulated in an ethernet frame, 494 the ethertype MUST be 0x8847 ([RFC5332]), which is the ethertype for 495 a unicast ethernet frame that carries an MPLS packet whose label 496 stack beings with a downstream-assigned label. 498 In the special case where the outer encapsulation is MPLS, the outer 499 encapsulation has no "next protocol" codepoint. All that is needed 500 to encapsulate the BIER packet is to push more MPLS label stack 501 entries (with S bit clear) on the BIER packet's label stack. 503 If two BIER packets have the same value in the entropy field of their 504 respective BIER headers, and if both are placed in an outer 505 encapsulation, it is desirable for the outer encapsulation to 506 preserve the fact that the two packets have the same entropy. If the 507 outer encapsulation is MPLS, and if the MPLS entropy label 508 ([RFC6790]) is in use in a given deployment, one way to do this is to 509 copy the value of the BIER header entropy field into an MPLS entropy 510 label. 512 2.2. In Non-MPLS Networks 514 2.2.1. Encapsulation Initial Four Octets 516 2.2.1.1. The BIFT-id 518 In non-MPLS networks, a BIFT-id MUST be assigned for every 519 combination of that is to be used in that network. The 520 correspondence between a BIFT-id and a particular 521 triple is unique throughout the BIER domain, and is known to all the 522 BFRs in the BIER domain. 524 The means by which the BIFT-ids are assigned, and the means by which 525 these assignments are made known to the BFRs, are outside the scope 526 of this document. 528 In an MPLS network, since the BIFT-id is an MPLS label, its value may 529 be changed as a BIER packet goes from BFR to BFR. In a non-MPLS 530 network, since the BIFT-id is domain-wide unique, it is not expected 531 to change as a BIER packet travels. 533 2.2.1.2. Other Fields of the Initial Four Octets 535 TC: 537 By default, the TC field has no significance in a non-MPLS 538 network. The default behavior is that this field SHOULD be set to 539 the binary value 000 upon transmission, and MUST be ignored upon 540 reception. 542 Non-default use of this field in non-MPLS networks is outside the 543 scope of this document. 545 S bit: 547 The S bit has no significance in a non-MPLS network. It SHOULD be 548 set to 1 upon transmission, but it MUST be ignored upon reception. 550 TTL: 552 This is the BIER "Time to Live" field. Its purpose is to prevent 553 BIER packets from looping indefinitely in the event of improper 554 operation of the control plane. When a BIER packet is received, 555 its "incoming TTL" (see below) is taken from this TTL field. 557 The effect of this field on the processing of a BIER packet is 558 described in Section 2.1.1.2. 560 2.2.2. Remainder of Encapsulation 562 Nibble: 564 This field SHOULD be set to 0000 upon transmission, but MUST be 565 ignored upon reception. 567 Ver: 569 See Section 2.1.2. 571 BSL: 573 See Section 2.1.2. 575 Entropy: 577 See Section 2.1.2. 579 OAM: 581 See Section 2.1.2. 583 Rsv: 585 See Section 2.1.2. 587 DSCP: 589 This 6-bit field MAY be used to hold a Differentiated Services 590 Codepoint ([RFC2474]). The significance of this field is outside 591 the scope of this document. 593 Proto: 595 See Section 2.1.2. 597 BFIR-id: 599 See Section 2.1.2. 601 BitString: 603 See Section 2.1.2. 605 2.2.3. Further Encapsulating a BIER Packet 607 Sending a BIER packet from one BFR to another may require the packet 608 to be further encapsulated. For example: in some scenarios it may be 609 necessary to encapsulate a BIER packet in an ethernet frame; in other 610 scenarios it may be necessary to encapsulate a BIER packet in in a 611 UDP packet. In such cases, the BIER packet itself is the payload of 612 an "outer" encapsulation. 614 In this document, we assume that the frame or packet carrying a BIER 615 packet as its payload is a unicast frame or packet. That is, 616 although a BIER packet is a multicast packet, we assume that the 617 frame or packet carrying the BIER packet as its payload is unicast 618 from one BFR to the next. 620 Generally the outer encapsulation has a codepoint identifying the 621 "next protocol". This codepoint MUST be set to a value that means 622 "Non-MPLS BIER". In particular, a codepoint that means "MPLS" (with 623 either upstream-assigned or downstream-assigned labels) MUST NOT be 624 used. 626 By requiring the use of a distinct codepoint for "non-MPLS BIER", we 627 allow for deployment scenarios where non-MPLS BIER can coexist with 628 non-BIER MPLS. The BIFT-id values used by the former will not 629 conflict with MPLS label values used by the latter. 631 Therefore, if a non-MPLS BIER packet is encapsulated in an ethernet 632 header, the ethertype MUST NOT be 0x8847 or 0x8848 ([RFC5332]). IEEE 633 has been requested to assign ethertype TBD1 for non-MPLS BIER 634 packets. 636 In the special case where the outer encapsulation is MPLS, the outer 637 encapsulation has no "next protocol" codepoint. If it is necessary 638 to use MPLS as an outer encapsulation for BIER packets, it is 639 RECOMMENDED to use the MPLS encapsulation for BIER. Procedures for 640 encapsulating a non-MPLS BIER packet in MPLS are outside the scope of 641 this document. 643 If two BIER packets have the same value in the entropy field of their 644 respective BIER headers, and if both are placed in an outer 645 encapsulation, it is desirable for the outer encapsulation to 646 preserve the fact that the two packets have the same entropy. 648 3. Imposing and Processing the BIER Encapsulation 650 Each BFIR is expected to know the Maximum Transit Unit (MTU) of the 651 BIER domain. This may be known by provisioning, or by some other 652 method outside the scope of this document. Each BFIR also knows the 653 size of the BIER encapsulation. Thus each BFIR can deduce the 654 maximum size payload that can be encapsulated in a BIER packet. We 655 will refer to this payload size as the BIER-MTU. 657 If a BFIR receives a multicast packet from outside the BIER domain, 658 and the packet size exceeds the BIER-MTU, the BFIR takes whatever 659 action is appropriate to take when receiving a multicast packet that 660 is too large to be forwarded to all its next hops. If the 661 appropriate action is to drop the packet and advertise an MTU to the 662 source, then the BFIR drops the packet and advertises the BIER-MTU. 663 If the appropriate action is to fragment the packet, then the 664 procedures of this section are applied, in sequence, to each 665 fragment. 667 When a BFIR processes a multicast packet (or fragment thereof) from 668 outside the BIER domain, the BFIR carries out the following 669 procedure: 671 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 672 determines the value of the "Proto" field. 674 2. By consulting the multicast flow overlay, it determines the set 675 of BFERs that must receive the packet. 677 3. If more than one SD is supported, the BFIR assigns the packet to 678 a particular SD. Procedures for determining the SD to which a 679 particular packet should be assigned are outside the scope of 680 this document. 682 4. The BFIR looks up the BFR-id, in the given SD, of each of the 683 BFERs. 685 5. The BFIR converts each such BFR-id into (SI, BitString) format, 686 as described in [BIER_ARCH]. 688 6. All such BFR-ids that have the same SI can be encoded into the 689 same BitString. Details of this encoding can be found in 690 [BIER_ARCH]. For each distinct SI that occurs in the list of the 691 packet's destination BFERs: 693 a. The BFIR makes a copy of the multicast data packet, and 694 encapsulates the copy in a BIER header (see Section 2). The 695 BIER header contains the BitString that represents all the 696 destination BFERs whose BFR-ids (in the given SD) correspond 697 to the given SI. It also contains the BFIR's BFR-id in the 698 SD to which the packet has been assigned. 700 N.B.: For certain applications, it may be necessary for the 701 BFIR-id field to contain the BFR-id of a BFR other than the 702 BFIR that is creating the header. Such uses are outside the 703 scope of this document. 705 b. The BFIR then applies to that copy the forwarding procedure 706 of [BIER_ARCH]. This may result in one or more copies of 707 the packet (possibly with a modified BitString) being 708 transmitted to a neighboring BFR. 710 c. If the non-MPLS BIER encapsulation is being used, the BIFT- 711 id field is set to the BIFT-id that corresponds to the 712 packet's . The TTL is set according to policy. 714 If the MPLS BIER encapsulation is being used, the BFIR finds 715 the BIER-MPLS label that was advertised by the neighbor as 716 corresponding to the given . An MPLS label 717 stack is then prepended to the packet. This label stack 718 [RFC3032] will contain one label, the aforementioned BIER- 719 MPLS label. The "S" bit MUST be set, indicating the end of 720 the MPLS label stack. The TTL field of this label stack 721 entry is set according to policy. 723 d. The packet may then be transmitted to the neighboring BFR. 724 (In an MPLS network, this may result in additional MPLS 725 labels being pushed on the stack. For example, if an RSVP- 726 TE tunnel is used to transmit packets to the neighbor, a 727 label representing that tunnel would be pushed onto the 728 stack.) 730 When an intermediate BFR is processing a received MPLS packet, and 731 one of the BFR's own BIER-MPLS labels rises to the top of the label 732 stack, the BFR infers the BSL from the label. The SI and SD are also 733 implicitly identified by the label. The BFR then follows the 734 forwarding procedures of [BIER_ARCH]. If it forwards a copy of the 735 packet to a neighboring BFR, it first swaps the label at the top of 736 the label stack with the BIER-MPLS label, advertised by that 737 neighbor, that corresponds to the same . Note that when 738 this swap operation is done, the TTL field of the BIER-MPLS label of 739 the outgoing packet MUST be one less than the "incoming TTL" of the 740 packet, as defined in Section 2.1.1.1. 742 When an intermediate BFR is processing a received non-MPLS BIER 743 packet, the BFR infers the BSL from the BIFT-id. The SI and SD are 744 also implicitly identified by the BIFT-id. The BFR then follows the 745 forwarding procedures of [BIER_ARCH]. 747 If the BIER payload is an MPLS packet, the BIER header is followed by 748 an MPLS label stack. This stack is separate from any MPLS stack that 749 may precede the BIER header. For an example of an application where 750 it is useful to carry an MPLS packet as the BIER payload, see 751 [BIER_MVPN]. If the BIER encapsulation's Proto field indicates that 752 the payload is an MPLS packet with an upstream-assigned at the top of 753 the stack, the upstream-assigned label is interpreted in the context 754 of . Note that the sub-domain-id must be 755 inferred from the BIFT-id. 757 4. IANA Considerations 759 IANA is requested to set up a registry called "BIER Next Protocol 760 Identifiers". The registration policy for this registry is "IETF 761 Review" ([RFC8126] and [RFC7120]). 763 Values in this registry must come from the range 0-63. 765 The initial values in the BIER Next Protocol Identifiers registry 766 are: 768 0: Reserved (not to be assigned by IANA). 770 1: MPLS packet with downstream-assigned label at top of stack. 772 2: MPLS packet with upstream-assigned label at top of stack 774 3: Ethernet frame. 776 4: IPv4 packet. 778 5: OAM packet (reference: [BIER_PING]) 780 6: IPv6 packet. 782 63: Reserved (not to be assigned by IANA). 784 5. IEEE Considerations 786 IEEE has been requested to assign ethertype TBD1 for non-MPLS BIER 787 packets. 789 6. Security Considerations 791 Insofar as this document makes use of MPLS, it inherits any security 792 considerations that apply to the use of the MPLS data plane. 794 If a BIER encapsulation header is modified in ways other than those 795 specified in [BIER_ARCH] and in this document, packets may be lost, 796 stolen, or otherwise misdelivered. Such modifications are likely to 797 go undetected, as the BIER encapsulation does not provide 798 cryptographic integrity protection. 800 Layer 2 encryption can be used to ensure that a BIER-encapsulated 801 packet is not altered while in transit between adjacent BFRs. If a 802 BFR itself is compromised, there is no way to prevent the compromised 803 BFR from making illegitimate modifications to the BIER header, or to 804 prevent it from misforwarding or misdelivering the a BIER- 805 encapsulated packet. 807 If the routing underlay (see Section 4.1 of [BIER_ARCH]) is based on 808 a unicast routing protocol, BIER assumes that the routers 809 participating in the unicast routing protocol have not been 810 compromised. BIER has no procedures to ensure that the unicast 811 routing adjacencies have not been compromised; that falls within the 812 scope of whatever unicast routing protocols are being used. 814 BIER-encapsulated packets should generally not be accepted from 815 untrusted interfaces or tunnels. For example, an operator may wish 816 to have a policy of accepting BIER-encapsulated packets only from 817 interfaces to trusted routers, and not from customer-facing 818 interfaces. 820 There may be applications that require a BFR to accept a BIER- 821 encapsulated packet from an interface to a system that is not 822 controlled by the network operator. For instance, there may be an 823 application in which a Virtual Machine in a Data Center submits BIER- 824 encapsulated packets to a router. In such a case, it is desirable to 825 verify that the packet is from a legitimate source, and that its 826 BitString denotes only systems to which that source is allowed to 827 send. However, the BIER encapsulation itself does not provide a way 828 to verify that the source is legitimate, or that the source is really 829 the system denoted by the BFIR-id, or that the source is allowed to 830 set any particular set of bits in the BitString. 832 Insofar as this document relies upon IGP extensions, it inherits any 833 security considerations that apply to the IGP. 835 The security considerations of [BIER_ARCH] also apply. 837 7. Acknowledgements 839 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 840 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 841 Xiaohu Xu, and Jeffrey Zhang for their ideas and contributions to 842 this work. 844 8. Contributor Addresses 846 Below is a list of other contributing authors in alphabetical order: 848 Mach (Guoyi) Chen 849 Huawei 851 Email: mach.chen@huawei.com 853 Arkadiy Gulko 854 Thomson Reuters 855 195 Broadway 856 New York NY 10007 857 United States 859 Email: arkadiy.gulko@thomsonreuters.com 861 Wim Henderickx 862 Nokia 863 Copernicuslaan 50 864 Antwerp 2018 865 Belgium 867 Email: wim.henderickx@nokia.com 869 Martin Horneffer 870 Deutsche Telekom 871 Hammer Str. 216-226 872 Muenster 48153 873 Germany 875 Email: Martin.Horneffer@telekom.de 877 Uwe Joorde 878 Deutsche Telekom 879 Hammer Str. 216-226 880 Muenster D-48153 881 Germany 883 Email: Uwe.Joorde@telekom.de 885 Tony Przygienda 886 Juniper Networks, Inc. 887 1194 N. Mathilda Ave. 888 Sunnyvale, California 94089 889 United States 891 Email: prz@juniper.net 893 9. References 895 9.1. Normative References 897 [BIER_ARCH] 898 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 899 and S. Aldrin, "Multicast using Bit Index Explicit 900 Replication", internet-draft draft-ietf-bier-architecture- 901 08, September 2017. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, 905 DOI 10.17487/RFC2119, March 1997, 906 . 908 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 909 "Definition of the Differentiated Services Field (DS 910 Field) in the IPv4 and IPv6 Headers", RFC 2474, 911 DOI 10.17487/RFC2474, December 1998, 912 . 914 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 915 Label Switching Architecture", RFC 3031, 916 DOI 10.17487/RFC3031, January 2001, 917 . 919 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 920 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 921 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 922 . 924 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 925 Label Assignment and Context-Specific Label Space", 926 RFC 5331, DOI 10.17487/RFC5331, August 2008, 927 . 929 [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 930 "MPLS Multicast Encapsulations", RFC 5332, 931 DOI 10.17487/RFC5332, August 2008, 932 . 934 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 935 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 936 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 937 2009, . 939 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 940 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 941 2014, . 943 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 944 Writing an IANA Considerations Section in RFCs", BCP 26, 945 RFC 8126, DOI 10.17487/RFC8126, June 2017, 946 . 948 9.2. Informative References 950 [BGP_BIER_EXTENSIONS] 951 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 952 Przygienda, "BGP Extensions for BIER", internet-draft 953 draft-ietf-bier-idr-extensions-03.txt, August 2017. 955 [BIER-PMM] 956 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "IP Flow 957 Performance Measurement Framework", internet-draft draft- 958 ietf-bier-pmmm-oam-03, October 2017. 960 [BIER_MVPN] 961 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 962 Dolganow, A., and T. Przygienda, "Multicast VPN Using 963 Bier", internet-draft draft-ietf-bier-mvpn-07, July 2017. 965 [BIER_PING] 966 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 967 and G. Mirsky, "BIER Ping and Trace", internet-draft 968 draft-ietf-bier-ping-02.txt, July 2017. 970 [ISIS_BIER_EXTENSIONS] 971 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 972 "BIER Support via IS-IS", internet-draft draft-ietf-bier- 973 isis-extensions-05.txt, July 2017. 975 [OSPF_BIER_EXTENSIONS] 976 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 977 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 978 for Bit Index Explicit Replication", internet-draft draft- 979 ietf-ospf-bier-extensions-07.txt, July 2017. 981 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 982 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 983 RFC 6790, DOI 10.17487/RFC6790, November 2012, 984 . 986 Authors' Addresses 988 IJsbrand Wijnands (editor) 989 Cisco Systems, Inc. 990 De Kleetlaan 6a 991 Diegem 1831 992 Belgium 994 Email: ice@cisco.com 996 Eric C. Rosen (editor) 997 Juniper Networks, Inc. 998 10 Technology Park Drive 999 Westford, Massachusetts 01886 1000 United States 1002 Email: erosen@juniper.net 1004 Andrew Dolganow 1005 Nokia 1006 438B Alexandra Rd #08-07/10 1007 Alexandra Technopark 1008 Singapore 119968 1010 Email: andrew.dolganow@nokia.com 1012 Jeff Tantsura 1013 Individual 1015 Email: jefftant.ietf@gmail.com 1017 Sam K Aldrin 1018 Google, Inc. 1019 1600 Amphitheatre Parkway 1020 Mountain View, California 1021 United States 1023 Email: aldrin.ietf@gmail.com 1025 Israel Meilik 1026 Broadcom 1028 Email: israel@broadcom.com