idnits 2.17.00 (12 Aug 2021) /tmp/idnits29675/draft-wang-bier-rh-bier-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2021) is 208 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) == Outdated reference: A later version (-04) exists of draft-ietf-bier-bierin6-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: April 28, 2022 October 25, 2021 7 Routing Header Based BIER Information Encapsulation 8 draft-wang-bier-rh-bier-00 10 Abstract 12 This draft proposes one new encapsulation schema of Bit Index 13 Explicit Replication (BIER) information to transfer the multicast 14 packets within the IPv6 network. By defining a new IPv6 Routing 15 Header type, it keeps the original source address and destination 16 address unchanged in forwarding process. The encapsulation schema 17 can make full use of the existing IPv6 quality assurance methods to 18 provide high-quality multicast service. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 28, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 3. BIER Routing Header . . . . . . . . . . . . . . . . . . . . . 3 57 4. The transmission process of packets with BIER Routing Header 5 58 4.1. All devices in BIER domain support BIER Routing Header . 5 59 4.2. Some devices in BIER domain do not support BIER Routing 60 Header . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 Bit Index Explicit Replication (BIER) is a new multicast technology 69 based on IPv6 defined in [RFC8279]. In BIER domain, the set of 70 destination nodes of multicast message is mapped into a BitString and 71 encapsulated into the BIER header. The position of each bit in the 72 BitString represents an BFER. Compared with the traditional 73 multicast technology, the nodes in BIER domain do not need to 74 maintain a multicast tree and save the multicast flow state for each 75 multicast flow. 77 At present, there are two methods for encapsulating BIER information 78 based on IPv6 in IETF: bierin6([I-D.ietf-bier-bierin6]) and 79 bierv6([I-D.xie-bier-ipv6-encapsulation]). 81 BIERin6 carries BIER information by defining a new IPv6 next header 82 type. In the process of transmission, the source address and 83 destination address in the header will change. BIERv6 carries bier 84 related information by creating an option type of destination options 85 header (i.e. bier option). During transmission, the source address 86 in the header remains unchanged and the destination address will 87 change. 89 There are some differences between the above two BIER encapsulation 90 and forwarding schemes, which is unfavorable to the development of 91 BIER and its derivatives. In addition, when there is an error in the 92 transmission process of the message, the source address and 93 destination address help the operators locate and trace the fault. 94 The change of source address and destination address during 95 transmission will increase the difficulty of fault location and 96 traceability. 98 This draft proposes a BIER information transmission scheme without 99 changing the source and destination addresses. By defining an IPv6 100 Routing Header type, it carries the relevant information of BIER and 101 ensures that the source address and destination address do not change 102 during message transmission. The characteristics of this scheme are 103 conducive to rapid fault location and traceability, and can make full 104 use of the existing IPv6 quality assurance technologies to provide 105 high-quality multicast service. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] . 113 3. BIER Routing Header 115 In RFC8020, the format of IPv6 Routing Header is defined, as shown in 116 Figure 1. 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 . . 123 . type-specific data . 124 . . 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 1: The format of IPv6 Routing Header 130 Where: 132 o Next Header(8 bits): indicating the message header type 133 immediately after the routing header. 135 o HDR Ext Len(8 bits): indicating the length of the routing header. 137 o Routing Type(8 bits): TBD. Identifying the newly defined Routing 138 Header to encode BIER information. 140 o Segments Left(8 bits): indicating the number of explicitly listed 141 intermediate nodes to be accessed before reaching the final 142 destination. It is not used here for the time being, and all are 143 set to 0. 145 o Type-specific data(variable): Its format is determined by the 146 routing type. The length should ensure that the complete routing 147 header is an integer multiple of 8 octets. 149 We define a new Routing Header type: BIER Routing Header to carry 150 BIER related information. The message format of the newly defined 151 Routing Header type is shown in Figure 2. 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | BIFT-id | Ver | TTL | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | BSL | Entropy | DSCP |OAM| 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | BFIR-id |Rsv| Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 . . 164 . BitString . 165 . . 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 2: The format of BIER Routing Header 171 Where: 173 o BIFT-id(20 bits): each < SD, Si, BSL > is assigned a BIFT-id. 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 TTL(8 bits): indicating the lifetime of the message. It is used 180 to prevent ring. The processing process is the same as that in 181 non MPLS networks. 183 o BSL(4 bits): indicating the length of BitString. 185 o Entropy(20 bits): this field specifies an "entropy" for ECMP. 187 o DSCP(6 bits): this field is used to support different service 188 codes. 190 o OAM(2 bits): by default, this value will be set to 0 by BFIR, and 191 other BFRs will not be modified. Whether to use this field is 192 optional. 194 o BFIR-id(16 bits): indicating BFR ID of BFIR. 196 o Rsv(2 bits): unused, set to 0. 198 o Reserved (14 bits): reserved field, set to 0. 200 o BitString(variable): the length must be reflected in the BSL 201 field. The string saved in this field is used to identify the 202 destination BFER of the packet. 204 4. The transmission process of packets with BIER Routing Header 206 Based on the newly defined BIER Routing Header, the devices support 207 BIER Routing Header resolution will perform the following steps: 209 1) Checking whether there is BIFT corresponding to the BIFT-id 210 locally. 212 2) Checking whether the direct-connected device support BIER Routing 213 Header. If yes, proceed to step 3; otherwise, proceed to step 2.1. 215 2.1) Calculating the IPv6 address of next hop that support BIER 216 Routing Header. 218 2.2) Encapsulating an outer IPv6 Header to the packet. The 219 calculated IPv6 address is used as the destination address of the 220 outer IPv6 Header, and its own IPv6 address is used as the source 221 address of the outer IPv6 Header. BitString will not be changed. 223 2.3) Sending the encapsulated packet to the next-connected device, 224 the device will perform normal IPv6 forwarding according to the outer 225 IPv6 Header. 227 3) Performing the normal BIER forwarding process as described in 228 [RFC8279]. 230 The detail procedures for forwarding the multicast packets based on 231 the newly defined Routing Header are described in the following 232 sections. 234 4.1. All devices in BIER domain support BIER Routing Header 236 +---+ 237 +-----------+ B +----------+ 238 | +---+ | 239 | 0:01000000 | 240 | | 241 | | 242 | | 243 +-+-+ +-+-+ (Packet 2) +---+ (Packet 3)+---+ 244 | A |0:10000000 0:00100000| C +------------+ E +-----------+ F | 245 +-+-+ +-+-+ +---+ +---+ 246 | | 0:00001000 0:00000100 247 | | 248 | | 249 | | 250 | 0:00010000 | 251 | +---+ | 252 +-----------+ D +----------+ 253 (Packet 1) +---+ 255 Packet 1 256 +----------------------------+ 257 IPv6 | Source IP Address = A | 258 Header +----------------------------+ 259 | Destination IP Address = F | 260 BIER +----------------------------+ 261 Routing| BitString = 00101100 | 262 Header +----------------------------+ 264 Packet 2 265 +----------------------------+ 266 IPv6 | Source IP Address = A | 267 Header +----------------------------+ 268 | Destination IP Address = F | 269 BIER +----------------------------+ 270 Routing| BitString = 00001100 | 271 Header +----------------------------+ 273 Packet 3 274 +----------------------------+ 275 Inner | Source IP Address = A | 276 IPv6 +----------------------------+ 277 Header | Destination IP Address = F | 278 +----------------------------+ 279 BIER | BitString = 00000100 | 280 Routing+----------------------------+ 281 Header 283 Figure 3: All devices in BIER domain support BIER Routing Header 285 The topology is shown in Figure 3, device A-F support BIER Routing 286 Header resolution. The packet need to be transmitted from A to F. 288 The change of the Header has been given in the Figure. Each device 289 will perform the following steps after receiving the packet: 291 1. Checking whether there is BIFT corresponding to the BIFT-id 292 locally. If yes, proceed to step 2; otherwise, discard the packet. 294 2. Checking whether the direct-connected device support BIER Routing 295 Header. If yes, forwarding the packet according to the BIFT related 296 to the BIFT-id; otherwise, see sectionSection 4.2 for detail 297 procedures. 299 In this forwarding process, the source address and destination 300 address in the Inner IPv6 Header are not changed, only the BitString 301 in BIER Routing Header is changed. 303 4.2. Some devices in BIER domain do not support BIER Routing Header 305 +---+ 306 +-----------+ B +-----------+ 307 | +---+ | 308 | 0:01000000 | 309 | | 310 | | 311 | | 312 +-+-+ +-+-+ (Packet 2) +---+ (Packet 3) +---+ 313 | A |0:10000000 | C +------------+ E +------------+ F | 314 +-+-+ +-+-+ +---+ +---+ 315 | | 0:00001000 0:00000100 316 | | 317 | | 318 | | 319 | 0:00010000 | 320 | +---+ | 321 +-----------+ D +-----------+ 322 (Packet 1) +---+ 324 Packet 1 325 +----------------------------+ 326 Outer | Source IP Address = A | 327 IPv6 +----------------------------+ 328 Header | Destination IP Address = E | 329 +----------------------------+ 330 Inner | Source IP Address = A | 331 IPv6 +----------------------------+ 332 Header | Destination IP Address = F | 333 +----------------------------+ 334 BIER | BitString = 00001100 | 336 Routing+----------------------------+ 337 Header 338 Packet 2 339 +----------------------------+ 340 Outer | Source IP Address = C | 341 IPv6 +----------------------------+ 342 Header | Destination IP Address = E | 343 +----------------------------+ 344 Inner | Source IP Address = A | 345 IPv6 +----------------------------+ 346 Header | Destination IP Address = F | 347 +----------------------------+ 348 BIER | BitString = 00001100 | 349 Routing+----------------------------+ 350 Header 351 Packet 3 352 +----------------------------+ 353 IPv6 | Source IP Address = A | 354 Header +----------------------------+ 355 | Destination IP Address = F | 356 BIER +----------------------------+ 357 Routing| BitString = 00000100 | 358 Header +----------------------------+ 360 Figure 4: Some devices in BIER domain do not support BIER Routing Header 362 The topology is shown in Figure 4, all devices expect device C 363 support BIER Routing Header resolution. The packet need to be 364 transmitted from A to F. The change of the Header has been given in 365 the Figure 4. When it is found that device C does not support BIER 366 Routing Header resolution, device A will perform the following steps 367 after receiving the packet: 369 1. Calculating the IPv6 address of next hop device that supports 370 BIER Routing Header. 372 2. Encapsulating an outer IPv6 Header to the packet. The calculated 373 IPv6 address is used as the destination address of the outer IPv6 374 Header, and its own IPv6 address is used as the source address of the 375 outer IPv6 Header. BitString will not be changed. 377 3. Sending the packet to device C. 379 After receiving the packet, device C will perform IPv6 forwarding 380 according the information in outer IPv6 Header, and send the packet 381 to device E. Device E will send it to device F according the 382 information in BIER Routing Header. In the forwarding process, the 383 source address and destination address in the Inner IPv6 Header are 384 not changed. 386 5. Security Considerations 388 TBD 390 6. IANA Considerations 392 This document defines a new IPv6 Routing Header - BIER Routing 393 Header. The code point is from the "Internet Protocol Version 6 394 (IPv6) Parameters - Routing Types". It is recommended to set the 395 code point of BIER Routing Header to 7. 397 7. Normative References 399 [I-D.ietf-bier-bierin6] 400 Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, 401 H., and G. Mishra, "Supporting BIER in IPv6 Networks 402 (BIERin6)", draft-ietf-bier-bierin6-00 (work in progress), 403 June 2021. 405 [I-D.xie-bier-ipv6-encapsulation] 406 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 407 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 408 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 409 xie-bier-ipv6-encapsulation-10 (work in progress), 410 February 2021. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 418 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 419 Explicit Replication (BIER)", RFC 8279, 420 DOI 10.17487/RFC8279, November 2017, 421 . 423 Authors' Addresses 424 Wei Wang 425 China Telecom 426 Beiqijia Town, Changping District 427 Beijing, Beijing 102209 428 China 430 Email: weiwang94@foxmail.com 432 Aijun Wang 433 China Telecom 434 Beiqijia Town, Changping District 435 Beijing, Beijing 102209 436 China 438 Email: wangaj3@chinatelecom.cn