idnits 2.17.00 (12 Aug 2021) /tmp/idnits41605/draft-chen-pim-mrh6-01.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 68 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) == Missing Reference: 'PE2' is mentioned on line 123, but not defined == Missing Reference: 'CE1' is mentioned on line 131, but not defined == Missing Reference: 'PE1' is mentioned on line 131, but not defined == Missing Reference: 'P1' is mentioned on line 131, but not defined == Missing Reference: 'P3' is mentioned on line 131, but not defined == Missing Reference: 'PE4' is mentioned on line 131, but not defined == Missing Reference: 'PE10' is mentioned on line 135, but not defined == Missing Reference: 'PE9' is mentioned on line 135, but not defined == Missing Reference: 'PE8' is mentioned on line 135, but not defined == Missing Reference: 'P4' is mentioned on line 135, but not defined == Missing Reference: 'PE5' is mentioned on line 135, but not defined == Missing Reference: 'PE7' is mentioned on line 139, but not defined == Missing Reference: 'PE6' is mentioned on line 139, but not defined == Unused Reference: 'RFC8200' is defined on line 960, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-pim-sr-p2mp-policy-03 Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei 5 Expires: September 8, 2022 Y. Fan 6 Casa Systems 7 Z. Li 8 X. Geng 9 Huawei 10 M. Toy 11 G. Mishra 12 Verizon 13 Y. Liu 14 China Mobile 15 A. Wang 16 China Telecom 17 L. Liu 18 Fujitsu 19 X. Liu 20 Volta Networks 21 March 7, 2022 23 Multicast using Multicast Routing Header 24 draft-chen-pim-mrh6-01 26 Abstract 28 This document describes an efficient solution for multicast along an 29 explicit P2MP Path/Tree using an IPv6 extension header called 30 multicast routing header (MRH). The MRH with the path encoded in 31 link numbers is added into a packet to be multicast at the ingress. 32 The packet is delivered to the egresses along the path. There is no 33 state stored in the core of the network. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119] [RFC8174] 40 when, and only when, they appear in all capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 8, 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Overview of Multicast using MRH . . . . . . . . . . . . . . . 3 78 3. Encoding of P2MP Path/Tree . . . . . . . . . . . . . . . . . 5 79 4. Multicast Routing Header (MRH) . . . . . . . . . . . . . . . 11 80 5. Procedures/Behaviors . . . . . . . . . . . . . . . . . . . . 18 81 5.1. Procedure/Behavior on Ingress Node . . . . . . . . . . . 18 82 5.2. Procedure/Behavior on Transit Node . . . . . . . . . . . 19 83 5.3. Procedure/Behavior on Egress Node . . . . . . . . . . . . 20 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 89 9.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 [I-D.ietf-pim-sr-p2mp-policy] proposes a solution for a SR P2MP path. 95 A multicast P2MP tree is created for the path and the state of the 96 tree is instantiated in the forwarding plane by a controller at Root, 97 intermediate Replication nodes and Leaves of the tree. 99 [I-D.chen-pim-srv6-p2mp-path] proposes a stateless solution for a SR 100 P2MP path. The overhead for encoding the P2MP path using SIDs in SRH 101 may be large. 103 This document describes an efficient solution for multicast along an 104 explicit P2MP Path/Tree using an IPv6 extension header called 105 multicast routing header (MRH). The MRH with the path encoded in 106 link numbers is added into a packet to be multicast at the ingress. 107 The packet is delivered to the egresses along the path. There is no 108 state stored in the core of the network. 110 2. Overview of Multicast using MRH 112 Figure 1 shows an example network having nodes P1, P2, P3, P4, PE1 to 113 PE10. For each of the links connected to a node, a number called 114 local link number (or link number for short) is assigned to it. For 115 example, PE1 has three links: link from PE1 to CE1, link from PE1 to 116 P1, and link from PE1 to PE10. These three links have link numbers 117 1, 2 and 3 respectively on PE1. P1 has five links: P1 to PE1, P1 to 118 P2, P1 to P3, P1 to PE8 and P1 to PE9. These five links have link 119 numbers 1, 2, 3, 4 and 5 respectively on P1. P3 has two links: P3 to 120 P1 and P3 to P4. These two links have link numbers 1 and 2 121 respectively on P3. 123 [PE2] PE1: Ingress/Root 124 1/ PEi(i=2,3,..,,9): Egress 125 / Pi: Transit Node 126 1/ 1 127 [P2]------[PE3] 128 3/ 2 129 / 130 1 2 1 /2 1 131 [CE1].....[PE1]------[P1]------[P3] [PE4] 132 3: 5/ 4\ 3 2\ 1/ 133 : / \ \ / 134 1: 1/ 1\ 1\ 2/ 1 135 [PE10] [PE9] [PE8] [P4]------[PE5] 136 5/ 4\ 3 137 / \ 138 1/ 1\ 139 [PE7] [PE6] 141 Figure 1: Network with P2MP Path from ingress PE1 to egresses PE2, 142 PE3, ..., PE9 144 P2MP path from ingress PE1 via P1 towards egresses PE2 to PE9 in 145 Figure 1 is represented by the link numbers along the path: PE1's 146 link number 2; P1's link numbers 2, 3, 4 and 5; P2's link numbers 1 147 and 2; P3's link number 2; and P4's link numbers 2, 3, 4 and 5. 149 After receiving a packet from traffic source CE1, ingress PE1 150 encapsulates the packet in a MRH with a P2MP path represented by the 151 link numbers along the path. The packet in the MRH is transmitted 152 along the path to the egresses of the path. 154 When a node such as P1 receives a packet with the MRH, the node gets/ 155 pops each of its link numbers, finds the address of the next hop from 156 a neighbor address table using the link number (i.e., the link number 157 such as 3 of the link from the node to the next hop such as P3), 158 sends the packet to the next hop (such as P3). 160 Figure 2 shows the neighbor IPv6 address table of P1. The table 161 comprises five rows of link number, link type and IPv6 address for 162 the five links of P1. The first row comprises link number 1, link 163 type P2P for link from P1 to next hop PE1 and PE1's IPv6 address. 164 The 2nd row comprises link number 2, link type P2P for link from P1 165 to next hop P2 and P2's IPv6 address. The 3rd row comprises link 166 number 3, link type P2P for link from P1 to next hop P3 and P3's IPv6 167 address. The 4-th row comprises link number 4, link type P2P for 168 link from P1 to next hop PE8 and PE8's IPv6 address. The 5-th row 169 comprises link number 5, link type P2P for link from P1 to next hop 170 PE9 and PE9's IPv6 address. 172 +==============+============+======================+ 173 | Link number | Link type | Address of next hop | 174 +==============+============+======================+ 175 | 1 | P2P | IPv6 address of PE1 | 176 +--------------+------------+----------------------+ 177 | 2 | P2P | IPv6 address of P2 | 178 +--------------+------------+----------------------+ 179 | 3 | P2P | IPv6 address of P3 | 180 +--------------+------------+----------------------+ 181 | 4 | P2P | IPv6 address of PE8 | 182 +--------------+------------+----------------------+ 183 | 5 | P2P | IPv6 address of PE9 | 184 +==============+============+======================+ 186 Figure 2: Neighbor IPv6 address table of P1 188 Using link number 1, P1 gets PE1's IPv6 address from the table; using 189 link number 2, P1 gets P2's IPv6 address from the table; using link 190 number 3, P1 gets P3's IPv6 address from the table; and so on. 192 3. Encoding of P2MP Path/Tree 194 Figure 3 shows the encoding of the P2MP path/tree in Figure 1 from 195 PE1 via P1 to PE2, PE3, ..., PE9. Each link on the tree is encoded 196 or represented by the link number of the link. For example, the link 197 from PE1 to P1 on the tree is encoded by link number 2 of the link on 198 PE1. The link from P1 to P2 on the tree is encoded by link number 2 199 of the link on P1. The link from P1 to P3 on the tree is encoded by 200 link number 3 of the link on P1. 202 For each link from its upstream node to its downstream (or say next 203 hop) node on the tree, three fields are used for the link: 1). link 204 number (Link-No for short) field for storing the link number, 2). 205 number of branches (N-Branches for short) for storing the number 206 branches/sub-trees of the tree from the next hop node, and 3). size 207 of branches+ (S-Branches+ for short) for storing the size of branches 208 of the tree from the next hop node and the fields following. The 209 size is in bits, bytes, or other units. 211 +=======+==========+===========+ 212 size |Link-No|N-Branches|S-Branches+| link 213 +=======+==========+===========+ -+ 214 24 | 2 | 4 | 22 | PE1 to P1 | 215 +-------+----------+-----------+ |sub-tree 216 22 | 2 | 2 | 14 | P1 to P2 |from PE1 217 +-------+----------+-----------+ |to P1 218 20 | 3 | 1 | 10 | P1 to P3 |to PE2-PE9 219 +-------+----------+-----------+ | 220 18 | 4 | 0 | 0 | P1 to PE8 | 221 +-------+----------+-----------+ | 222 16 | 5 | 0 | 0 | P1 to PE9 | 223 +-------+----------+-----------+ -+ | 224 14 | 1 | 0 | 0 | P2 to PE2 |sub-trees | 225 +-------+----------+-----------+ |from P2 | 226 12 | 2 | 0 | 0 | P2 to PE3 | | 227 +-------+----------+-----------+ -+ | 228 10 | 2 | 4 | 8 | P3 to P4 | | 229 +-------+----------+-----------+ |sub-tree | 230 8 | 2 | 0 | 0 | P4 to PE4 |from P3 | 231 +-------+----------+-----------+ | | 232 6 | 3 | 0 | 0 | P4 to PE5 | | 233 +-------+----------+-----------+ | | 234 4 | 4 | 0 | 0 | P4 to PE6 | | 235 +-------+----------+-----------+ | | 236 2 | 5 | 0 | 0 | P4 to PE7 | | 237 +-------+----------+-----------+ -+ -+ 239 Figure 3: Encoding of tree from PE1 via P1 to PE2, PE3, ..., PE9 241 For example, for the link from PE1 to P1 on the tree, Link-No field 242 has value of 2 since the link number is 2 for the link on PE1; 243 N-Branches field has value of 4 since there are 4 branches from P1; 244 S-Branches+ field has value of 22 (bytes) since 22 bytes are used for 245 storing/encoding 4 branches from P1 when the three fields Link-No, 246 N-Branches and S-Branches+ for a link occupy 2 bytes in total. 248 For the link from P1 to P2 on the tree, Link-No field has value of 2 249 since the link number is 2 for the link on P1; N-Branches field has 250 value of 2 since there are two branches from P2; S-Branches+ field 251 has value of 14 (bytes) since 14 bytes are used for storing/encoding 252 the two branches (i.e., sub-trees) from P2 and the fields following. 254 For the link from P1 to P3 on the tree, Link-No field has value of 3 255 since the link number is 3 for the link on P1; N-Branches field has 256 value of 1 since there is one branch (i.e., sub-tree) from P3; 257 S-Branches+ field has value of 10 (bytes) since 10 bytes are used for 258 storing/encoding the branch from P3 and no other fields following. 260 For the link from P2 to egress PE2 on the tree, Link-No field has 261 value of 1 since the link number is 1 for the link on P2; N-Branches 262 field has value of 0 since there is no branch (i.e., sub-tree) from 263 PE2; S-Branches+ field has value of 0 (bytes). 265 Figure 4 shows an enhancement of encoding the P2MP path/tree in 266 Figure 1 using L flag. The L flag added for a link indicates whether 267 the next hop is a leaf node. When L is set to one indicating the 268 next hop is a leaf (i.e., egress), the "N-Branches" and "S-Branches+" 269 fields are removed. There are 8 links to leaves (i.e., egress nodes) 270 on the tree, which are 2 links from P2 to PE2 and PE3; 4 links from 271 P4 to PE4, PE5, PE6 and PE7; and 2 links from P1 to PE8 and PE9. 272 These 8 links have their L flags set to one. The N-Branches and 273 S-Branches+ fields for these 8 links are removed from the encoding of 274 the tree. This reduces the space/memory for encoding the tree. 276 +=+=======+==========+===========+ 277 size |L|Link-No|N-Branches|S-Branches+| link 278 +=+=======+==========+===========+ -+ 279 16 |0| 2 | 4 | 14 | PE1 to P1 | 280 +-+-------+----------+-----------+ |sub-tree 281 14 |0| 2 | 2 | 8 | P1 to P2 |from PE1 282 +-+-------+----------+-----------+ |to P1 to 283 12 |0| 3 | 1 | 6 | P1 to P3 |PE2-PE9 284 +-+-------+----------+-----------+ | 285 10 |1| 4 | P1 to PE8 | 286 +-+-------+ | 287 9 |1| 5 | P1 to PE9 | 288 +-+-------+ -+ | 289 8 |1| 1 | P2 to PE2 |sub-trees | 290 +-+-------+ |from P2 | 291 7 |1| 2 | P2 to PE3 | | 292 +-+-------+----------+-----------+ -+ | 293 6 |0| 2 | 4 | 4 |P3 to P4 | | 294 +-+-------+----------+-----------+ |sub-tree | 295 4 |1| 2 | P4 to PE4 |from P3 | 296 +-+-------+ | | 297 3 |1| 3 | P4 to PE5 | | 298 +-+-------+ | | 299 2 |1| 4 | P4 to PE6 | | 300 +-+-------+ | | 301 1 |1| 5 | P4 to PE7 | | 302 +-+-------+----------+-----------+ -+ -+ 304 Figure 4: Encoding of tree from PE1 via P1 to PE2, PE3, ..., PE9 with 305 L flag 307 For example, suppose that two fields L and Link-No with padding 308 (padding is not shown) for a link to leaf occupy 1 byte; four fields 309 L, Link-No, N-Branches and S-Branches+ for a link to a transit node 310 occupy 2 bytes. In this case, the S-Branches+ field for link from 311 PE1 to P1 is 14 (bytes), which is the size of the fields for 11 links 312 (i.e., link from P1 to P2, link from P1 to P3, ..., link from P4 to 313 PE7) encoding the sub-trees from P1 to PE2, PE3, ..., PE9. The 314 S-Branches+ field for link from P1 to P2 is 8 (bytes), which is the 315 size of the fields for 7 links (i.e., link from P2 to PE2, link from 316 P2 to PE3, link from P3 to P4, and 4 links from P4 to PE4 - PE7) 317 encoding the sub-trees from P1 to PE2 and PE3, and the fields 318 following them. 320 Encoding the tree without L flag occupies 24 bytes in total as 321 illustrated in Figure 3. Encoding the tree with L flag occupies 16 322 bytes in total as illustrated in Figure 4. 8 bytes (or say 33% of 323 space/memory) are saved/reduced. 325 Figure 5 shows an enhancement of encoding the branch/sub-tree from P3 326 to PE4, PE5, PE6 and PE7 in Figure 1 using B flag. The B flag added 327 for a link indicates whether the link bits+ are used to represent the 328 link numbers and other link related information such as whether 329 links' remote end nodes (i.e., next hops) are leaves. When B flag 330 for the link from upstream node such as P3 to downstream node such as 331 P4 is set to one indicating the link bits+ are used, the links from 332 downstream node such as P4 on the tree are encoded or represented by 333 link bits+. A link bits+ contains a P (short for plus leaf) field, 334 S-Bits (short for size of the bits in a unit such as byte) field, and 335 Bits field. 337 P field has a value such as 1 indicating that a bit with value of 1 338 (one) in Bits field means that the corresponding link is on the 339 branch and the link's next hop is a leaf. There are four links to 340 leaves (i.e., egress nodes) from P4, which are link from P4 to PE4 341 with link number 2, link from P4 to PE5 with link number 3, link from 342 P4 to PE6 with link number 4, and link from P4 to PE7 with link 343 number 5. These four links are represented by the 2-th bit, 3-th 344 bit, 4-th bit and 5-th bit in the Bits field (from left to right) 345 respectively. 347 S-Bits field has a value such as 1 indicating the size of the Bits 348 field in a unit such as byte. 350 Suppose that the fields (i.e., L, B, Link-No, No-Branches and 351 S-Branches+) for the link from P3 to P4 occupy 2 bytes; P and S-Bits 352 occupy 1 byte. In this case, the link bits+ for the links from P4 353 occupy 2 bytes, encoding the branch from P3 uses 4 bytes in total. 355 The number of branches from P4 is the number of bits with value of 356 one in the Bits field. The N-Branches field for the link from P3 to 357 P4 is used for other purpose. For example, N-Branches field and 358 S-Branches+ field combined to represent the size of the branches plus 359 the fields following (i.e., S-Branches+). 361 +=+=+=======+==========+===========+ 362 size |L|B|Link-No|N-Branches|S-Branches+| link 363 +=+=+=======+==========+===========+ -+ 364 4 |0|1| 2 | | 2 | P3 to P4 |branch 365 +-+-+-------+------+---+-----------+ |from P3 366 2 |1| 1 |0 1 1 1 1 0 0 0| P4 to PE4-PE7 |to PE4-PE7 367 +-+----------------+---------------+ -+ 368 |P| S-Bits | Bits | 370 Figure 5: Encoding of branch from P3 via P4 to PE4, PE5, PE6, PE7 371 with B flag 373 Figure 6 shows an enhancement of encoding the branch part from PE1 374 via P1 to P2, P3, PE8 and PE9 on the P2MP tree/path in Figure 1 using 375 B flag. B flag for the link from upstream node PE1 to downstream 376 node P1 is set to one indicating that the link bits+ are used to 377 represent the information about the links on the tree from downstream 378 node P1. 380 P field has a value such as 0 indicating that a bit with value of 1 381 (one) in Bits field means that the corresponding link from downstream 382 node P1 is on the tree. 384 S-Bits field has a value such as 1 indicating the size of Bits field 385 in a unit such as byte. 387 Bits field of one byte has the second (2-th) bit, third (3-th) bit, 388 4-th bit and 5-th bit set to one (from left to right), indicating 389 four links from P1 on the tree: the link from P1 to P2 with link 390 number 2, link from P1 to P3 with link number 3, link from P1 to PE8 391 with link number 4 and link from P1 to PE9 with link number 5. The 392 fields for each of these links do not have Link-No field, which is 393 called reduced fields. 395 +=+=+=======+==========+===========+ 396 size |L|B|Link-No|N-Branches|S-Branches+| link 397 +=+=+=======+==========+===========+ -+ 398 13 |0|1| 2 | | 11 | PE1 to P1 |branch part 399 +-+-+-------+------+---+-----------+ |from PE1 400 11 |0| 1 |0 1 1 1 1 0 0 0| P1 to P2,P3, |to P2,P3, 401 +-+----------------+---------------+ PE8,PE9 | PE8,PE9 402 |P| S-Bits | Bits | | 403 | 404 |L|B|N-Branches|S-Branches+| | 405 +=+=+==========+===========+ | 406 |0|0| 2 | 6 | P1 to P2 | 407 +-+-+----------+-----------+ | 408 |0|0| 1 | 4 | P1 to P3 | 409 +-+-+----------+-----------+ | 410 |1| P1 to PE8 | 411 +-+ | 412 |1| P1 to PE9 | 413 +-+ -+ 415 Figure 6: Encoding of branch part from PE1 via P1 to P2, P3, PE8, PE9 416 with B flag 418 The reduced fields (i.e., L = 0, B = 0, No-Branches = 2, S-Branches+ 419 = 6) for the link from P1 to P2 indicates that the link's next hop is 420 not leaf, link bits+ is not used for the branches from P2, the number 421 of branches from P2 is 2 and the size of the branches from P2 plus 422 the fields following is 6. 424 The reduced fields (i.e., L = 0, B = 0, No-Branches = 1, S-Branches+ 425 = 4) for the link from P1 to P3 indicates that the link's next hop is 426 not leaf, link bits+ is not used for the branches from P3, the number 427 of branches from P3 is 1 and the size of the branches from P3 plus 428 the fields following is 4. 430 The reduced fields (i.e., L = 1) for the link from P1 to PE8 431 indicates that the link's next hop PE8 is a leaf. 433 The reduced fields (i.e., L = 1) for the link from P1 to PE9 434 indicates that the link's next hop PE9 is a leaf. 436 Suppose the fields (i.e., L, B, Link-No, No-Branches and S-Branches+) 437 for a link to a transit node occupy 2 bytes; P and S-Bits occupy 1 438 byte; the reduced fields (i.e., L, B, No-Branches and S-Branches+) 439 for a link to a transit node occupy 11 bits, the reduced fields 440 (i.e., L) for a link to a leaf occupy 1 bit. In this case the 441 reduced fields for four links from P1 to P2, P3, PE8 and PE9 uses 3 442 bytes (i.e., 24 bits). Encoding the branch part from PE1 via P1 to 443 P2, P3, PE8 and PE9 uses 7 bytes. 445 Figure 7 shows an enhancement of encoding the P2MP path/tree in 446 Figure 1 using both L and B flags. 448 The branch part from PE1 via P1 to P2, P3, PE8 and PE9 is the same as 449 the one in Figure 6 and occupies 7 bytes. 451 The link from P2 to PE2 is represented by L = 1 and Link-No = 1. The 452 link from P2 to PE3 is represented by L = 1 and Link-No = 2. These 453 two links occupy 2 bytes. In an option, when L = 1, the Link-No 454 field and Pad are combined to represent link number. 456 The branch from P3 is the same as the one in Figure 5 and occupies 4 457 bytes. Encoding the tree of 13 nodes uses 13 bytes in total. 459 +=+=+=======+==========+===========+ 460 size |L|B|Link-No|N-Branches|S-Branches+| link 461 +=+=+=======+==========+===========+ -+ 462 13 |0|1| 2 | | 11 | PE1 to P1 |sub-tree 463 +-+-+-------+------+---+-----------+ |from PE1 464 11 |0| 1 |0 1 1 1 1 0 0 0| P1 to P2,P3, |to P1 to 465 +-+----------------+---------------+ PE8,PE9 |PE2-PE9 466 |P| S-Bits | Bits | | 467 | 468 |L|B|N-Branches|S-Branches+| | 469 +=+=+==========+===========+ | 470 9 |0|0| 2 | 6 | P1 to P2 | 471 +-+-+----------+-----------+ | 472 |0|0| 1 | 4 | P1 to P3 | 473 +-+-+----------+-----------+ | 474 |1| P1 to PE8 | 475 +-+ | 476 L |1| P1 to PE9 | 477 +-+-----+-+-+ -+ | 478 6 |1| 1 |Pad| P2 to PE2 |sub-tree | 479 +-+-----+-+-+ |from P2 | 480 5 |1| 2 |Pad| P2 to PE3 | | 481 +-+-+---+---+----------+-----------+ -+ | 482 4 |0|1| 2 | | 2 | P3 to P4 |sub-tree | 483 +-+-+-------+------+---+-----------+ |from P3 | 484 2 |1| 1 |0 1 1 1 1 0 0 0| P4 to PE4 | | 485 +-+----------------+---------------+ -PE7-+ -+ 486 |P| S-Bits | Bits | 488 Figure 7: Encoding of tree from PE1 to PE2 - PE9 with L and B 490 4. Multicast Routing Header (MRH) 492 Figure 8 shows a Multicast Routing Header (MRH) in an IPv6 packet. 493 The IPv6 packet comprises an IPv6 header with a destination address 494 (DA) and source address (SA) of IPv6, a routing header with Routing 495 type (TBD) indicating MRH and an IP multicast datagram. The routing 496 header is indicated by the Next Header in the IPv6 header. 498 +-----------------+------------------+------------------------+ 499 | IPv6 header: | Routing header: | IP multicast datagram | 500 | | | (IP datagram header + | 501 | Next Header = | Next Header | data) | 502 | Routing header | | | 503 | | Hdr Ext Len | | 504 | SA=IPv6 Address | Routing Type = | | 505 | DA=IPv6 Address | TBD (MRH) | | 506 | | SL, b, nB | | 507 | | sub-tree | | 508 +-----------------+------------------+------------------------+ 509 |<---- MRH ---->| 511 Figure 8: Multicast Routing Header (MRH) in IPv6 packet 513 The format of the MRH is shown in Figure 9. The MRH comprises a 514 8-bit Next Header field with a value indicating the IP multicast 515 datagram header in the packet, a 8-bit Hdr Ext Len field with a value 516 indicating the length of the MRH in a unit of 64 bits (i.e., 8 bytes) 517 excluding the first 8 bytes, a 8-bit Routing Type field with a value 518 (to be assigned by IANA) indicating that the routing header is a 519 Multicast Routing Header (MRH), a 8-bit SL (short for Sub-tree Left) 520 field with a value indicating the size of the sub-tree remaining, a 521 1-bit b flag is set to value one indicating the links directly from 522 the root of the sub-tree are encoded by link bits+, a 3-bit Rsv 523 (Reserved) field with zero, a 4-bit nB (short for n-Branches) field 524 with a value indicating the number of branches from the root of the 525 sub-tree, and a sub-tree field which is an encoding of a multicast 526 sub-tree. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Next Header | Hdr Ext Len |RoutingType=TBD| SL | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |b| Rsv | nB | | 534 +-+-+-+-+-+-+-+-+ Sub-tree encoded by link numbers : 535 : : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 9: Format of Multicast Routing Header (MRH) 540 The P2MP path/tree from PE1 via P1 to PE2 - PE9 in Figure 1 is 541 encoded by the link numbers of the links on the tree as illustrated 542 in Figure 7. The link from ingress PE1 to P1 is encoded by the link 543 number of the link on PE1, which is 2, the number of branches from P1 544 on the tree, and the size of the branches+ from P1, which is 11. The 545 number of branches from P1 is the number of bits with value 1 in the 546 Bits field for the links from P1 to P2, P3, PE8 and PE9, which is 4 547 since there are 4 bits with value 1 in the Bits field. 549 For an IP multicast packet to be transmitted by the P2MP path/tree, 550 PE1 constructs an IPv6 packet for each sub-tree/branch from PE1 and 551 sends the packet containing a MRH and the IP multicast packet to the 552 next hop along the sub-tree. 554 The P2MP path/tree has one sub-tree from PE1 via P1 to PE2 - PE9. 555 PE1 finds P1's IPv6 address from PE1's neighbor IPv6 address table 556 using the link number 2 and sets DA (destination address) of the IPv6 557 packet to P1's IPv6 address and SA (source address) of the IPv6 558 packet to PE1's IPv6 address. PE1 builds the MRH based on the 559 encoding of the tree in Figure 7 through setting b flag to 1, which 560 is the value of B for the link from PE1 to P1, SL to 11, which is the 561 value of S-Branches+ for the link from PE1 to P1. nB is not set 562 since B = 1. Figure 10 shows the IPv6 packet to be sent to P1, which 563 is received by P1. Note that some details are not shown. 565 | IPv6 Header | <-------- MRH --------> | 566 +-------------+-------------------------------+-------------+ 567 |DA=P1's IPv6 |Routing Type=TBD,SL=11,b=1,nB |IP multicast | 568 |SA=PE1's IPv6|sub-tree from P1 to PE2-PE9 |datagram | 569 +-------------+-------------------------------+-------------+ 570 size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Link 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ 572 11 |0| 1 |0 1 1 1 1 0 0 0| P1 to P2,P3,PE8,PE9 |sub-tree 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |from P1 574 9 P |0|0| 2 | 6 | P1 to P2 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 |0|0| 1 | 4 |1|1| P1 to P3, | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+ PE8,PE9 | 578 L |L|B|N-Bra|S-Branches+|L|L| | 579 +-+-+-+-+-+-+-+-+ -+ | 580 6 |1| 1 |Pad| P2 to PE2|sub-trees | 581 +-+-+-+-+-+-+-+-+ |from P2 | 582 5 |1| 2 |Pad| P2 to PE3| | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ | 584 4 |0|1| 2 | | 2 | P3 to P4 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-tree | 586 2 |1| 1 |0 1 1 1 1 0 0 0|P4 to PE4 |from P3 | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - PE7-+ -+ 588 |P| S-Bits | Bits | 590 Figure 10: IPv6 packet with MRH received by P1 592 The number of branches from P1 is 4, which is the number of bits with 593 value 1 in the Bits field for the links from P1 to P2, P3, PE8 and 594 PE9. This is determined by b = 1 and the Bits+ fields pointed by SL 595 = 11. 597 There are 4 links from P1. The 2-th bit in the Bits field has value 598 1 indicating the link with link number 2, which is the link from P1 599 to P2. The reduced fields (i.e., L = 0, B = 0, No-Branches = 2, 600 S-Branches+ = 6) for the link indicates that the link's next hop P2 601 is not leaf, link bits+ is not used for the branches from P2, the 602 number of branches from P2 is 2 and the size of the branches from P2 603 plus the fields following is 6. 605 The 3-th bit has value 1 indicating the link with link number 3, 606 which is the link from P1 to P3. The reduced fields (i.e., L = 0, B 607 = 0, No-Branches = 1, S-Branches+ = 4) for the link indicates that 608 the link's next hop P3 is not leaf, link bits+ is not used for the 609 branches from P3, the number of branches from P3 Is 1 and the size of 610 the branches from P3 plus the fields following is 4. 612 The 4-th bit has value 1 indicating the link with link number 4, 613 which is the link from P1 to PE8. PE8 is a leaf, which is indicated 614 by the first L = 1. The 5-th bit has value 1 indicating the link 615 with link number 5, which is the link from P1 to PE9. PE9 is a leaf 616 indicated by the second L = 1. 618 The link number of the link from P2 to leaf PE2 is 1 on P2. The link 619 number of the link from P2 to leaf PE3 is 2 on P2. The link number 620 of the link from P3 to P4 is 2 on P3. The size of branches from P4 621 is 2. The link numbers of the links from P4 to leaf PE4, PE5, PE6 622 and PE7 are 2, 3, 4 and 5 on P4 respectively. 624 After receiving the IPv6 packet from PE1, P1 determines whether the 625 packet's next header is a MRH through checking if the next header is 626 routing header and routing type in the routing header is TBD for MRH. 627 When the next header is the MRH, P1 duplicates the packet for each 628 link/branch/sub-tree from P1 and sends the packet copy with an 629 updated MRH (note: only SL, b and nB are updated) to the next hop 630 along the branch. Since b = 1, the number of bits with value 1 in 631 the Bits field of Bits+ pointed by SL = 11 is the number of branches/ 632 links from P1 according to Figure 10, which is 4. 634 The 2-th bit in the Bits field has value 1 indicating the link with 635 link number 2, which is the link from P1 to P2. The first reduced 636 fields is for link from P1 to P2 and indicates the number of branches 637 from P2 is 2 and the size of branches from P2 plus the ones following 638 them is 6. 640 P1 duplicates the packet for the link with link number 2, finds P2's 641 IPv6 address from P1's neighbor IPv6 address table using the link 642 number 2 of the link from P1 to P2 and sets DA of the packet to P2's 643 IPv6 address and SA of the packet to P1's IPv6 address. P1 updates 644 the MRH based on the encoding of the sub-tree in Figure 10 through 645 setting SL, b and nB to S-Branches+ = 6, B = 0 and N-Branches = 2 for 646 the link from P1 to P2 respectively. Figure 11 shows the packet to 647 be sent to P2, which is received by P2. 649 | IPv6 Header | <-------- MRH --------> | 650 +-------------+-------------------------------+-------------+ 651 |DA=P2's IPv6 |Routing Type=TBD, SL=6,b=0,nB=2|IP multicast | 652 |SA=P1's IPv6 |sub-tree from P2 to PE2,PE3 |datagram | 653 +-------------+-------------------------------+-------------+ 654 size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Link 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 L| Link-No | 657 +-+-+-+-+-+-+-+-+ -+ 658 6 |1| 1 |Pad| P2 to PE2|sub-trees 659 +-+-+-+-+-+-+-+-+ |from P2 660 5 |1| 2 |Pad| P2 to PE3| 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ 662 4 |0|1| 2 | | 2 | P3 to P4 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-tree 664 2 |1| 1 |0 1 1 1 1 0 0 0|P4 to PE4 |from P3 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - PE7-+ 666 |P| S-Bits | Bits | 668 Figure 11: IPv6 packet with MRH received by P2 670 The number of branches from P2 is 2. The link number of the link 671 from P2 to PE2 is 1 on P2. The link number of the link from P2 to 672 PE3 is 2 on P2. PE2 and PE3 are leaves (i.e., egresses), which are 673 indicated by L = 1. 675 The fields for encoding the branch/sub-tree from P3 follows the 676 branches/sub-trees from P2. 678 The 3-th bit has value 1 indicating the link with link number 3, 679 which is the link from P1 to P3. The second reduced fields is for 680 link from P1 to P3 and indicates the number of branches from P3 is 1 681 and the size of branches from P3 plus the ones following them is 4. 683 P1 duplicates the packet for the link with link number 3 (which is 684 link from P1 to P3) and sends the packet copy with an updated MRH to 685 P3. 687 The 4-th bit has value 1 indicating the link with link number 4, 688 which is the link from P1 to PE8. PE8 is a leaf, which is indicated 689 by the first L = 1. 691 P1 duplicates the packet for the link with link number 4 and sends 692 the packet copy with an updated MRH to PE8. 694 The 5-th bit has value 1 indicating the link with link number 5, 695 which is the link from P1 to PE9. PE9 is a leaf, which is indicated 696 by the second L = 1. 698 P1 duplicates the packet for the link with link number 5 and sends 699 the packet copy with an updated MRH to PE9. 701 P1 duplicates the packet for the link with link number 3 (which is 702 link from P1 to P3), finds P3's IPv6 address from P1's neighbor IPv6 703 address table using the link number 3 of the link from P1 to P3 and 704 sets DA of the packet to P3's IPv6 address and SA of the packet to 705 P1's IPv6 address. P1 updates the MRH based on the encoding of the 706 sub-tree in Figure 10 through setting SL, b and nB to S-Branches+ = 707 4, B = 0 and N-Branches = 1 in the reduced fields for the link from 708 P1 to P3 respectively. Figure 12 shows the packet to be sent to P3, 709 which is received by P3. 711 | IPv6 Header | <-------- MRH --------> | 712 +-------------+-------------------------------+-------------+ 713 |DA=P3's IPv6 |Routing Type=TBD, SL=4,b=0,nB=1|IP multicast | 714 |SA=P1's IPv6 |sub-tree from P3 to PE4-PE7 |datagram | 715 +-------------+-------------------------------+-------------+ 716 size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Link 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 |L|B|Link-No|N-Branc|S-Branches+| 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ 721 4 |0|1| 2 | | 2 | P3 to P4 | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-tree 723 2 |1| 1 |0 1 1 1 1 0 0 0|P4 to PE4 |from P3 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - PE7-+ 725 |P| S-Bits | Bits | 727 Figure 12: IPv6 packet with MRH received by P3 729 The number of branches from P3 is 1. The link number of the link 730 from P3 to P4 is 2 on P3. The size of branches from P4 is 2. B = 1 731 for the link from P3 to P4 indicates that the links from P4 are 732 encoded by link bits+. The number of branches from P4 is the number 733 of bits with value 1 in the Bits field for the links from P4 to PE4 - 734 PE7, which is 4 since there are 4 bits with value 1 in the Bits 735 field. 737 After receiving the IPv6 packet from P1, P3 determines whether the 738 packet's next header is a MRH. When the packet's next header is the 739 MRH, P3 duplicates the packet for each link/branch/sub-tree from P3 740 and sends the packet copy with an updated MRH to the next hop along 741 the branch. There is one branch from P3 according to the sub-tree 742 remaining in the MRH in the packet received by P3. The branch/sub- 743 tree is from the link from P3 to P4 towards PE4 - PE7. 745 P3 duplicates the packet for the branch/sub-tree, finds P4's IPv6 746 address from P3's neighbor IPv6 address table using the link number 2 747 of the link from P3 to P4 and sets DA of the packet to P4's IPv6 748 address and SA of the packet to P3's IPv6 address. P3 updates the 749 MRH based on the encoding of the sub-tree in Figure 12 through 750 setting SL and b to S-Branches+ = 2 and B = 1 for the link from P3 to 751 P4 respectively. nB is not set or used since b = 1. Figure 13 shows 752 the packet to be sent to P4, which is received by P4. 754 | IPv6 Header | <-------- MRH --------> | 755 +-------------+-------------------------------+-------------+ 756 |DA=P4's IPv6 |Routing Type=TBD, SL=2,b=1,nB |IP multicast | 757 |SA=P3's IPv6 |sub-tree from P4 to PE4-PE7 |datagram | 758 +-------------+-------------------------------+-------------+ 759 size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Link 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+sub-trees 761 2 |1| 1 |0 1 1 1 1 0 0 0|P4 to PE4 |from P4 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - PE7-+ 763 |P| S-Bits | Bits | 765 Figure 13: IPv6 packet with MRH received by P4 767 After receiving the IPv6 packet from P3, P4 determines whether the 768 packet's next header is a MRH. When the packet's next header is the 769 MRH, P4 duplicates the packet for each branch/link from P4 and sends 770 the packet copy with an updated MRH to the next hop along the branch. 771 There are 4 branches/links from P4 according to the sub-tree 772 remaining in the MRH in the packet received by P4. 774 The 2-th bit in the Bits field has value 1 indicating the link with 775 link number 2, which is the link from P4 to leaf PE4. 777 The 3-th bit has value 1 indicating the link with link number 3, 778 which is the link from P4 to leaf PE5. 780 The 4-th bit has value 1 indicating the link with link number 4, 781 which is the link from P4 to leaf PE6. 783 The 5-th bit has value 1 indicating the link with link number 5, 784 which is the link from P4 to leaf PE7. 786 P4 duplicates the packet for the first branch, finds PE4's IPv6 787 address from P4's neighbor IPv6 address table using the link number 2 788 of the link from P4 to PE4 and sets DA of the packet to PE4's IPv6 789 address and SA of the packet to P4's IPv6 address. P4 updates the 790 MRH based on the encoding of the sub-tree in Figure 13 through 791 setting SL to 0 since PE4 is a leaf. Figure 14 shows the packet to 792 be sent to PE4, which is received by PE4. Similarly, P4 duplicates 793 the packet for each of the other links, updates the MRH and sends the 794 packet copy to each of PE5, PE6 and PE7. 796 | IPv6 Header | <-------- MRH --------> | 797 +-------------+-------------------------------+-------------+ 798 |DA=PE4's IPv6|Routing Type=TBD, SL=0, b, nB |IP multicast | 799 |SA=P4's IPv6 |sub-tree/leaf PE4 |datagram | 800 +-------------+-------------------------------+-------------+ 802 Figure 14: IPv6 packet with MRH received by PE4 804 After receiving the packet from P4, PE4 determines whether the 805 packet's next header is a MRH. When the packet's next header is the 806 MRH, PE4 checks if PE4 itself is a leaf (i.e., egress) through 807 checking whether SL is 0. When PE4 is a leaf, PE4 decapsulates the 808 packet and sends the IP multicast datagram to the IP multicast 809 forwarding module. 811 Alternatively, after receiving the packet from P3 and determining 812 that the packet's next header is a MRH, P4 checks if each of its next 813 hops is a leaf. When the next hop is a leaf, P4 decapsulates the 814 packet and sends the IP multicast datagram to the next hop. Since 4 815 next hops PE4 - PE7 are leaves, P4 sends the IP multicast datagram to 816 PE4 - PE7. 818 5. Procedures/Behaviors 820 This section describes the procedures or behaviors on the ingress, 821 transit and egress/leaf node of a P2MP path to deliver a packet 822 received from the path to its destinations. 824 5.1. Procedure/Behavior on Ingress Node 826 For a packet to be transported by a P2MP Path, the ingress of the 827 P2MP path duplicates the packet for each sub-tree/branch of the P2MP 828 path branching from the ingress, encapsulates the packet copy in a 829 MRH containing the sub-tree and sends the encapsulated packet copy to 830 the next hop node along the sub-tree. 832 For example, there is one sub-tree branching from the ingress of the 833 P2MP path/tree in Figure 1. The sub-tree is from ingress PE1 via 834 next hop node P1 towards PE2 to PE9. PE1 sends P1 the packet as 835 shown in Figure 10. 837 5.2. Procedure/Behavior on Transit Node 839 When a transit node of a P2MP path/tree receives a packet transported 840 by the P2MP path/tree, the node determines whether the current 841 routing header is a MRH. After determining that it is a MRH, the 842 node executes the procedure to duplicate the packet for each of the 843 downstream links of the node on the P2MP path/tree and send the 844 packet copy to next hop (i.e., downstream node) of the link. 846 Suppose that the transit node receives the packet from a upstream 847 link from a upstream node to the transit node and there are n 848 downstream links from the transit node on the P2MP path/tree (i.e., 849 there are n branches/sub-trees from the transit node on the P2MP 850 path/tree, where n is greater than zero). 852 The information about the upstream link is in b and nB field of the 853 MRH. When b = 0, nB field contains the number of branches from the 854 transit node. The information about n downstream links is pointed by 855 SL. When b = 1, the number of branches from the transit node is the 856 number of bits with value 1 in the Bits field of the Bits+ fields 857 pointed by SL. The information about n downstream links is encoded 858 by the Bits field and the fields following the Bits field. 860 For example, when node P1 receives the packet transported by the P2MP 861 path/tree in Figure 1 from ingress PE1, the MRH is illustrated in 862 Figure 10. The b = 1, the Bits field of the Bits+ fields pointed by 863 SL = 11 has 4 bits with value 1. So there are 4 branches from P1. 864 The information about 4 downstream links (i.e., link from P1 to P2, 865 link from P1 to P3, link from P1 to PE8 and link from P1 to PE9) is 866 encoded by the Bits field and the reduced fields for these 4 links 867 following the Bits field. 869 For each of the downstream links of the transit node, the transit 870 node duplicates the packet for the link, sets SL, b and nB in the 871 packet copy accordingly. If the next hop is a leaf (i.e., egress), 872 the transit node sets SL to 0; otherwise, the transit node sets SL, b 873 and nB to the value of S-Branches+, B and N-Branches for the link 874 respectively when B is 0. When B = 1, the transit node sets SL and b 875 to the value of S-Branches+ and B for the link respectively. The 876 transit node finds the IPv6 address of the next hop (i.e., the 877 downstream node) of the link from the neighbor IPv6 address table of 878 the transit node using the link number of the link, sets the DA of 879 the packet copy to the IPv6 address of the next hop, sets the SA of 880 the packet copy to the IPv6 address of the transit node, and sends 881 the packet copy to the next hop of the link. 883 For example, for the first downstream link from P1 (i.e., link from 884 P1 to P2), P1 duplicates the packet for the link, sets SL to 6 (which 885 is the value of the S-Branches+ field for the link), b to 0 (which is 886 the value of B for the link) and nB to 2 (which is the value of the 887 N-Branches field for the link). P1 finds the IPv6 address of the 888 next hop P2 of the link from the neighbor IPv6 address table of P1 889 using the link number 2 of the link, sets the DA of the packet copy 890 to the P2's IPv6 address, sets the SA of the packet copy to the P1's 891 IPv6 address, and sends the packet copy to P2. The packet copy 892 received by P2 is shown in Figure 11. 894 For the second downstream link from P1 (i.e., link from P1 to P3), P1 895 duplicates the packet for the link, sets SL, b and nB to 4, 0 and 1 896 respectively, which are the values of S-Branches+, B and N-Branches 897 for the link from P1 to P3 respectively. P1 finds the IPv6 address 898 of the next hop P3 of the link from the neighbor IPv6 address table 899 of P1 using the link number 3 of the link, sets the DA of the packet 900 copy to the P3's IPv6 address, sets the SA of the packet copy to the 901 P1's IPv6 address, and sends the packet copy to P3. The packet copy 902 received by P3 is illustrated in Figure 12. 904 For the 3-th downstream link from P1 (i.e., link from P1 to PE8), P1 905 duplicates the packet for the link, sets SL to 0 since PE8 is a leaf 906 (i.e., egress). P1 finds the IPv6 address of the next hop PE8 of the 907 link from the neighbor IPv6 address table of P1 using the link number 908 4 of the link, sets the DA of the packet copy to the PE8's IPv6 909 address, sets the SA of the packet copy to the P1's IPv6 address, and 910 sends the packet copy to PE8. 912 5.3. Procedure/Behavior on Egress Node 914 When an egress node of a P2MP path receives a packet transported by 915 the path, the DA of the packet is the IPv6 address of the egress node 916 and there is an indication in the MRH for the leaf/egress. The 917 egress node proceeds to process the next header in the packet. 919 For example, after receiving the IPv6 packet from P4, PE4 determines 920 whether the packet's next header is a MRH. When the packet's next 921 header is the MRH, PE4 checks if PE4 itself is a leaf (i.e., egress) 922 through checking whether SL is 0. When PE4 is a leaf, PE4 923 decapsulates the packet and sends the IP multicast datagram to the IP 924 multicast forwarding module. 926 6. IANA Considerations 928 This document requests assigning a new Routing Type in the 929 subregistry "Routing Types" under registry "Internet Protocol Version 930 6 (IPv6) Parameters" as follows: 932 +===================+==========================+=============+ 933 | Value | Description | Reference | 934 +===================+==========================+=============+ 935 | TBD (7 suggested) | Multicast Routing Header |This document| 936 +===================+==========================+=============+ 938 7. Security Considerations 940 TBD 942 8. Acknowledgements 944 The authors would like to thank Donald Eastlake for the valuable 945 comments and suggestions on this draft. 947 9. References 949 9.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, 953 DOI 10.17487/RFC2119, March 1997, 954 . 956 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 957 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 958 May 2017, . 960 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 961 (IPv6) Specification", STD 86, RFC 8200, 962 DOI 10.17487/RFC8200, July 2017, 963 . 965 9.2. Informative References 967 [I-D.chen-pim-srv6-p2mp-path] 968 Chen, H., McBride, M., Fan, Y., Li, Z., Geng, X., Toy, M., 969 Mishra, G. S., Wang, A., Liu, L., and X. Liu, "Stateless 970 SRv6 Point-to-Multipoint Path", draft-chen-pim-srv6-p2mp- 971 path-05 (work in progress), November 2021. 973 [I-D.ietf-pim-sr-p2mp-policy] 974 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 975 and Z. Zhang, "Segment Routing Point-to-Multipoint 976 Policy", draft-ietf-pim-sr-p2mp-policy-03 (work in 977 progress), August 2021. 979 Authors' Addresses 981 Huaimo Chen 982 Futurewei 983 Boston, MA 984 USA 986 Email: Huaimo.chen@futurewei.com 988 Mike McBride 989 Futurewei 991 Email: michael.mcbride@futurewei.com 993 Yanhe Fan 994 Casa Systems 995 USA 997 Email: yfan@casa-systems.com 999 Zhenbin Li 1000 Huawei 1002 Email: lizhenbin@huawei.com 1004 Xuesong Geng 1005 Huawei 1007 Email: gengxuesong@huawei.com 1009 Mehmet Toy 1010 Verizon 1011 USA 1013 Email: mehmet.toy@verizon.com 1014 Gyan S. Mishra 1015 Verizon 1016 13101 Columbia Pike 1017 Silver Spring MD 20904 1018 USA 1020 Phone: 301 502-1347 1021 Email: gyan.s.mishra@verizon.com 1023 Yisong Liu 1024 China Mobile 1026 Email: liuyisong@chinamobile.com 1028 Aijun Wang 1029 China Telecom 1030 Beiqijia Town, Changping District 1031 Beijing 102209 1032 China 1034 Email: wangaj3@chinatelecom.cn 1036 Lei Liu 1037 Fujitsu 1038 USA 1040 Email: liulei.kddi@gmail.com 1042 Xufeng Liu 1043 Volta Networks 1044 McLean, VA 1045 USA 1047 Email: xufeng.liu.ietf@gmail.com