idnits 2.17.00 (12 Aug 2021) /tmp/idnits30066/draft-wang-bier-rh-bier-04.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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2022) is 75 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group W. Wang 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: September 8, 2022 H. Chen 6 Futurewei 7 G. Mishra 8 Verizon Inc. 9 March 7, 2022 11 Routing Header Based BIER Information Encapsulation 12 draft-wang-bier-rh-bier-04 14 Abstract 16 This draft proposes one new encapsulation schema of Bit Index 17 Explicit Replication (BIER) information to transfer the multicast 18 packets within the IPv6 network. By using a new type of IPv6 Routing 19 Header to forward the packet, the original source address and 20 destination address of the multicast packet is kept unchanged along 21 the forwarding path. Such encapsulation schema can make full use of 22 the existing IPv6 quality assurance solutions to provide high-quality 23 multicast service. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. BIER Routing Header . . . . . . . . . . . . . . . . . . . . . 3 62 4. Multicast Packet Forwarding Procedures . . . . . . . . . . . 5 63 4.1. All nodes in BIER domain support BIER Routing Header . . 6 64 4.2. Some nodes in BIER domain do not support BIER Routing 65 Header . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Bit Index Explicit Replication (BIER) is a new multicast technology 76 based on IPv6 defined in [RFC8279]. In BIER domain, the set of 77 destination nodes of multicast message is mapped into a BitString and 78 encapsulated into the BIER header. The position of each bit in the 79 BitString represents an BFER. Compared with the traditional 80 multicast technologies, the nodes in BIER domain do not need to 81 maintain a multicast tree and keep the multicast flow state for each 82 multicast flow. 84 Currently, there are two methods for encapsulating BIER information 85 based on IPv6 in IETF: BIERin6([I-D.ietf-bier-bierin6]) and 86 BIERv6([I-D.xie-bier-ipv6-encapsulation]). 88 BIERin6 carries BIER information by defining a new IPv6 next header 89 type. During the forwarding process, the source address and 90 destination address in the header will be changed. 92 BIERv6 carries bier related information by defining an new type of 93 destination options header (i.e. bier option). The source address in 94 the header remains unchanged but the destination address will be 95 changed along the forwarding path. 97 The differences between the above two BIER encapsulation and 98 forwarding schemes are unfavorable for the development of BIER and 99 its derivatives. In addition, when there is error in the forward 100 process of the multicast packet, the change of source address and 101 destination address during transmission will increase the difficulty 102 of fault location and traceability. 104 This draft proposes a BIER information transmission scheme without 105 changing the multicast source and destination addresses in the outer 106 IPv6 header. The relevant BIER information is encapsulated within 107 the newly defined IPv6 Routing Header type, each intermediate BIER 108 router will route the multicast packet based on the BitString 109 information and its associated BIFT. The multicast source and 110 destination address are not changed along the forwarding path. 112 The characteristics of such schema are helpful to the rapid fault 113 location and traceability, and can make full use of the existing IPv6 114 quality assurance technologies to provide high-quality multicast 115 service. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119] . 123 3. BIER Routing Header 125 One new type of IPv6 Routing Header is defined according to 126 [RFC8200]. The message format is shown in Figure 1. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | BIFT-id | TC |S| TTL | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |Nibble | Ver | BSL | Entropy | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |OAM|Rsv| DSCP | Proto | BFIR-id | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | BitString (first 32 bits) ~ 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ~ ~ 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 ~ BitString (last 32 bits) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: The format of BIER Routing Header 148 Where: 150 o Next Header(8 bits): indicating the message header type 151 immediately after the routing header. 153 o HDR Ext Len(8 bits): indicating the length of the routing header. 155 o Routing Type(8 bits): TBD. Identifying the newly defined Routing 156 Header to encode BIER information. 158 o Segments Left(8 bits): indicating the number of explicitly listed 159 intermediate nodes to be accessed before reaching the final 160 destination. It is not used here for the time being, and all are 161 set to 0. 163 o BIFT-id(20 bits): each < SD, Si, BSL > is assigned a BIFT-id. 165 o TC(3 bits): see [RFC8296]. This field is set to 0. 167 o S(1 bit): see [RFC8296]. This field is set to 0. 169 o TTL(8 bits): indicating the lifetime of the message. It is used 170 to prevent ring. The processing process is the same as that in 171 non MPLS networks. 173 o Nibble(4 bits): see [RFC8296]. This field is set to 0. 175 o Ver(4 bits): identifying the version of the BIER header. When an 176 unsupported BIER header version is received, the BFR needs to 177 discard the packet and record the error. 179 o BSL(4 bits): indicating the length of BitString. 181 o Entropy(20 bits): this field specifies an "entropy" for ECMP. 183 o OAM(2 bits): by default, this value will be set to 0 by BFIR, and 184 other BFRs will not be modified. Whether to use this field is 185 optional. 187 o Rsv(2 bits): unused, set to 0. 189 o DSCP(6 bits): this field is used to support different service 190 codes. 192 o Proto(6 bits): see [RFC8296]. This field is set to 0. 194 o BFIR-id(16 bits): indicating BFR ID of BFIR. 196 o Reserved (14 bits): reserved field, set to 0. 198 o BitString(variable): the length must be reflected in the BSL 199 field. The string saved in this field is used to identify the 200 destination BFER of the packet. 202 4. Multicast Packet Forwarding Procedures 204 Based on the newly defined BIER Routing Header, the nodes support 205 BIER Routing Header will perform the following steps to forward the 206 multicast packets: 208 1) When a BFIR receive a multicast packet, it will find out the 209 destination address and RD that relate to the source interface of the 210 packet. BFIR looks up its End.MVPN mapping table to find the 211 associated End.MVPN, and encapsulate a IPv6 Header with BIER Routing 212 Header. The payload is user data, the source address is the IPv6 213 address of BFIR, and destination address is End.MVPN. BitString in 214 BIER Routing Header indicates the BFERs that want to receives such 215 multicast packet. 217 2) BFIR checks whether there is BIFT corresponding to the BIFT-id 218 locally. If not, it will discard the packet; otherwise, it will 219 check whether the direct-connected node support BIER Routing Header. 220 If the direct-connected node supports BIER Routing Header, proceeding 221 to step 3). If the direct-connected node doesn't support BIER 222 Routing Header, proceeding to step 2.1) . 224 2.1) BFIR Calculates the IPv6 address of next hop that support BIER 225 Routing Header. 227 2.2) Encapsulating an outer IPv6 Header to the multicast packet. The 228 calculated IPv6 address is used as the destination address of the 229 outer IPv6 Header, and its own IPv6 address is used as the source 230 address of the outer IPv6 Header. BitString will not be changed. 232 2.3) Sending the encapsulated packet to the direct-connected node, 233 the node will perform normal IPv6 forwarding according to the outer 234 IPv6 Header. 236 3) Performing the normal BIER forwarding process as described in 237 [RFC8279]. 239 For a BFR, it performs as described in Section 4.2. 241 The detail procedures for forwarding the multicast packets based on 242 the newly defined Routing Header are described in the following 243 sections. 245 4.1. All nodes in BIER domain support BIER Routing Header 247 +---+ 248 +-----------+ B +----------+ 249 | +---+ | 250 | 0:01000000 | 251 | | 252 | | 253 | | 254 +-+-+ +-+-+ (Packet 2) +---+ (Packet 3)+---+ 255 | A |0:10000000 0:00100000| C +------------+ E +-----------+ F | 256 +-+-+ +-+-+ +---+ +---+ 257 | | 0:00001000 0:00000100 258 | | 259 | | 260 | | 261 | 0:00010000 | 262 | +---+ | 263 +-----------+ D +----------+ 264 (Packet 1) +---+ 266 Packet 1 267 +------------------------------------+ 268 IPv6 | IPv6 Address of A | 269 Header +------------------------------------+ 270 with | IPv6 Multicast Destination Address | 271 BIER +------------------------------------+ 272 Routing| BIER RH(BitString = 00101100) | 273 Header +------------------------------------+ 274 | Original multicast packet | 275 +------------------------------------+ 277 Packet 2 278 +------------------------------------+ 279 IPv6 | IPv6 Address of A | 280 Header +------------------------------------+ 281 with | IPv6 Multicast Destination Address | 282 BIER +------------------------------------+ 283 Routing| BIER RH(BitString = 00001100) | 284 Header +------------------------------------+ 285 | Original multicast packet | 286 +------------------------------------+ 288 Packet 3 289 +------------------------------------+ 290 IPv6 | IPv6 Address of A | 291 Header +------------------------------------+ 292 with | IPv6 Multicast Destination Address | 293 BIER +------------------------------------+ 294 Routing| BIER RH(BitString = 00000100) | 295 Header +------------------------------------+ 296 | Original multicast packet | 297 +------------------------------------+ 299 Figure 2: All nodes in BIER domain support BIER Routing Header 301 The topology is shown in Figure 2, node A-F support BIER Routing 302 Header. The packet need to be transmitted from A to F. The changes 303 of the Routing Header have been given in Figure 2. 305 1). Node A is BFIR, when it receives a multicast packet, it will 306 encapsulate a IPv6 Header with BIER Routing Header to the packet. 308 2). Node A checks whether there is BIFT corresponding to the BIFT-id 309 locally. If not, discarding the packet; otherwise, forwarding the 310 packet according to the BIFT related to the BIFT-id. 312 3). Node D-E repeat the step 2). 314 4). Node F looks up the associated table and submits the packet to 315 the new multicast downstreams. 317 During the forwarding procedures, the source & destination address in 318 IPv6 header are not changed, only the BitString in BIER Routing 319 Header is updated. 321 4.2. Some nodes in BIER domain do not support BIER Routing Header 323 +---+ 324 +-----------+ B +-----------+ 325 | +---+ | 326 | 0:01000000 | 327 | | 328 | | 329 | | 330 +-+-+ +-+-+ +---+ (Packet 3) +---+ 331 | A |0:10000000 | C +------------+ E +------------+ F | 332 +-+-+ +-+-+ +---+ +---+ 333 | | 0:00001000 0:00000100 334 | | 335 | | 336 | | 337 | 0:00010000 | 338 | +---+ | 339 +-----------+ D +-----------+ 340 (Packet 1) +---+ (Packet 2) 342 Packet 1 343 +------------------------------------+ 344 IPv6 | IPv6 Address of A | 345 Header +------------------------------------+ 346 with | IPv6 Multicast Destination Address | 347 BIER +------------------------------------+ 348 Routing| BIER RH(BitString = 00001100) | 349 Header +------------------------------------+ 350 | Original multicast packet | 351 +------------------------------------+ 353 Packet 2 354 +------------------------------------+ 355 Outer | Source IP Address = D | 356 IPv6 +------------------------------------+ 357 Header | Destination IP Address = E | 358 +------------------------------------+ 359 Inner | IPv6 Address of A | 360 IPv6 +------------------------------------+ 361 Header | IPv6 Multicast Destination Address | 362 with +------------------------------------+ 363 BIER | BIER RH(BitString = 00001100) | 365 Routing+------------------------------------+ 366 Header | Original multicast packet | 367 +------------------------------------+ 369 Packet 3 370 +-------------------------------------+ 371 IPv6 | IPv6 Address of A | 372 Header +-------------------------------------+ 373 with | IPv6 Multicast Destination Address | 374 BIER +-------------------------------------+ 375 Routing| BIER RH(BitString = 00000100) | 376 Header +-------------------------------------+ 377 | Original multicast packet | 378 +-------------------------------------+ 380 Figure 3: Some nodes in BIER domain do not support BIER Routing Header 382 The topology is shown in Figure 3, all nodes expect node C support 383 BIER Routing Header. The packet need to be transmitted from A to F. 384 The change of the Header has been given in the Figure 3. 386 1). After receiving a multicast packet, node A encapsulates a IPv6 387 Header with BIER Routing Header to it, and forwards the packet to 388 node D according to the BIFT. 390 2). Node D calculates the IPv6 address of next hop node(Node E) that 391 supports BIER Routing Header, and encapsulates an outer IPv6 Header 392 to the packet. The source IPv6 address is the IPv6 address of 393 itself, and the destination IPv6 address is the IPv6 address of node 394 E. Then, sending the packet to node C. 396 3). Node C performs normal IPv6 forwarding according to the outer 397 IPv6 header and sends the packet to node E. 399 4). Node E decapsulates the outer IPv6 header and forwards the 400 packet according to the BIFT to node F. 402 5). Node F looks up the associated table and submits the packet to 403 the new multicast downstreams. 405 In the forwarding procedures, the source address and destination 406 address in the Inner IPv6 Header are not changed, only the BitString 407 in BIER Routing Header is updated. 409 5. Security Considerations 411 TBD 413 6. IANA Considerations 415 This document defines a new type of IPv6 Routing Header - BIER 416 Routing Header. The code point is from the "Internet Protocol 417 Version 6 (IPv6) Parameters - Routing Types". It is recommended to 418 set the code point of BIER Routing Header to 7. 420 7. References 422 7.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 430 (IPv6) Specification", STD 86, RFC 8200, 431 DOI 10.17487/RFC8200, July 2017, 432 . 434 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 435 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 436 Explicit Replication (BIER)", RFC 8279, 437 DOI 10.17487/RFC8279, November 2017, 438 . 440 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 441 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 442 for Bit Index Explicit Replication (BIER) in MPLS and Non- 443 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 444 2018, . 446 7.2. Informative References 448 [I-D.ietf-bier-bierin6] 449 Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, 450 H., and G. Mishra, "Supporting BIER in IPv6 Networks 451 (BIERin6)", draft-ietf-bier-bierin6-04 (work in progress), 452 March 2022. 454 [I-D.xie-bier-ipv6-encapsulation] 455 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 456 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 457 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 458 xie-bier-ipv6-encapsulation-10 (work in progress), 459 February 2021. 461 Authors' Addresses 463 Wei Wang 464 China Telecom 465 Beiqijia Town, Changping District 466 Beijing, Beijing 102209 467 China 469 Email: weiwang94@foxmail.com 471 Aijun Wang 472 China Telecom 473 Beiqijia Town, Changping District 474 Beijing, Beijing 102209 475 China 477 Email: wangaj3@chinatelecom.cn 479 Huaimo Chen 480 Futurewei 481 Beiqijia Town, Changping District 482 Boston, MA 483 USA 485 Email: Huaimo.chen@futurewei.com 487 Gyan S. Mishra 488 Verizon Inc. 489 13101 Columbia Pike 490 Silver Spring MD 20904 491 United States of America 493 Phone: 301 502-1347 494 Email: gyan.s.mishra@verizon.com