Network Working Group H. Chen Internet-Draft D. Eastlake Intended status: Standards Track M. McBride Expires: January 12, 2023 Futurewei Y. Fan Casa Systems G. Mishra Verizon Y. Liu China Mobile A. Wang China Telecom X. Liu IBM Corporation L. Liu Fujitsu July 11, 2022 Stateless Best Effort Multicast Using MRH draft-chen-pim-be-mrh-00 Abstract This document describes stateless best effort Multicast along the shortest paths to the egress nodes of a P2MP Path/Tree. The multicast data packet is encapsulated in an IPv6 Multicast Routing Header (MRH). The MRH contains the egress nodes represented by the indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along the shortest path. There is no state stored in the core of the network. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Chen, et al. Expires January 12, 2023 [Page 1] Internet-Draft BE Multicast in MRH July 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Encoding of P2MP Path/Tree . . . . . . . . . . . . . . . . . 4 2.1. More Efficient Encoding of P2MP Path/Tree . . . . . . . . 4 3. Node Index Table . . . . . . . . . . . . . . . . . . . . . . 6 4. IPv6 Multicast Routing Header (MRH) . . . . . . . . . . . . . 8 5. Procedures at Nodes . . . . . . . . . . . . . . . . . . . . . 14 5.1. Procedure at Ingress Node . . . . . . . . . . . . . . . . 14 5.2. Procedure at Transit Nodes . . . . . . . . . . . . . . . 14 5.3. Procedure at Egress Node . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The potential egress nodes and transit nodes in a network are numbered or indexed from 1 to the number of the nodes. Figure 1 shows an example network having nodes E1 to PE10 and P1 to P5, where PE1 to PE10 are edge nodes (i.e., potential egress nodes) and P1 to Chen, et al. Expires January 12, 2023 [Page 2] Internet-Draft BE Multicast in MRH July 2022 P5 are transit nodes. In this example, these nodes have node indexes 1 to 10 and 11 to 15 respectively. The number labeling a link is the cost of the link. For example, 5 on the link between P5 and PE4 is the cost of the link. The cost of a link without a numeric label is 1. [PE2] 2 / PEi(i=1 to 10):Edge Nodes / Pi(i=1 to 5):Transit Nodes / [P2]--------[PE3] 3 / / / /4 / / P2MP path/tree from / [P5] PE1 to PE2 - PE6 / ___/ \ \____5 / ___/ \ \___ 1 / / \ \ [CE1].....[PE1]------[P1]------[P3] \ [PE4] 4 : / \ \__ \ / : / \ 4\ \ __/ : / \ \ | / [PE10] [PE9] [PE8] [P4]------[PE5] 5 10 9 8 / \ / \ / \ 7 [PE7] [PE6] 6 Figure 1: Network with 10 edges and P2MP tree from PE1 to PE2 - PE6 The P2MP path/tree from ingress PE1 towards egresses PE2 to PE6 (i.e., PE2, PE3, PE4, PE5 and PE6) in Figure 1 is represented by the set of the indexes of the egress nodes of the P2MP path. The indexes of PE2 to PE6 are 2 to 6 (i.e., 2, 3, 4, 5 and 6) respectively. These indexes are encoded by the indexes directly or the bit string of one byte. A controller such as PCE as a controller can have the information about the node indexes, and send the P2MP path to the ingress of the path. After receiving a data packet from traffic source CE1, ingress PE1 encapsulates the packet in a MRH with the P2MP path represented by the indexes. The packet is transmitted along the shortest path to each of the egresses. Chen, et al. Expires January 12, 2023 [Page 3] Internet-Draft BE Multicast in MRH July 2022 This document describes the encoding of a P2MP Path/Tree using the indexes of the egress nodes of the tree and specifies the procedure/ behavior of the nodes along the shortest paths to the egresses. 1.1. Acronyms The following acronyms are used in this document: CE: Customer edge/equipment. MRH: Multicast Routing Header. P2MP: Point 2 Multi-Point. PE: Provider Edge. 2. Encoding of P2MP Path/Tree A simple encoding could use a fixed length field such as 2 bytes to store a node index. The P2MP path/tree from ingress PE1 to egresses PE2 - PE6 (i.e., PE2, PE3, PE4, PE5 and PE6) in Figure 1 is represented in Figure 2. There are five fields, each of which occupies 2 bytes and stores the index of an egress node. These five fields store 2, 3, 4, 5 and 6, which are the indexes of egress nodes PE2 to PE6 respectively. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | PE2's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | PE3's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | PE4's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | PE5's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | PE6's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Encoding tree from PE1 to PE2 - PE6 with indexes directly 2.1. More Efficient Encoding of P2MP Path/Tree However, in many cases, we can improve on the above encoding by having a B flag to indicate whether an entry uses a bit string to represent multiple node indexes. When B = 0, there is one fixed length (15 bits) field following B, having a node index. When B = 1, there are three fields following B: a start index (StartIndex) field, Chen, et al. Expires January 12, 2023 [Page 4] Internet-Draft BE Multicast in MRH July 2022 a size of bit string (S-BitString) field and a bit string (BitString) field. The StartIndex field contains a starting node number (index) as an unsigned integer. The S-BitString field of 1 byte indicates the size of the BitString field in bytes as an unsigned integer. The BitString field contains a bit string, where each bit with value of 1 in the string indicates a node index equal to the start index plus that bit position number. The P2MP path/tree from ingress PE1 to egresses PE2 - PE6 (i.e., PE2, PE3, PE4, PE5 and PE6) in Figure 1 is represented in Figure 3 using a bit string. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 1 | 1 |1|1|1|1|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| StartIndex | S-BitString | BitString | Figure 3: Encoding tree from PE1 to PE2 - PE6 using bit string The indexes of egress nodes PE2 to PE6 are represented by four fields: B flag with value of 1, StartIndex of 15 bits with value of 1, the S-BitString byte with value of 1, and the BitString of 1 byte (i.e., 8 bits) with value 0b11111000. S-BitString = 1 indicates BitString occupies 1 byte. BitString = 0b11111000 combined with StartIndex = 1 indicates five node indexes 2, 3, 4, 5 and 6. The BitString's first bit = 1 indicates the first node index after the start index 1, which is 2 (i.e., 2 = 1 + 1); the BitString's second bit = 1 indicates the second node index after the start index 1, which is 3 (i.e., 3 = 1 + 2); and so on. Suppose that the index of egress node PE2 is 2 and the indexes of egress nodes PE3 to PE6 are 30003 to 30006 respectively. The P2MP path/tree from ingress PE1 to egresses PE2 - PE6 can be represented as shown in Figure 4 using the node index and bit string. Chen, et al. Expires January 12, 2023 [Page 5] Internet-Draft BE Multicast in MRH July 2022 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| NodeIndex = 2 | PE2's Index 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 30002 | 1 |1|1|1|1|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| StartIndex | S-BitString | BitString | Figure 4: Encoding tree from PE1 to PE2 - PE6 using index and bit string The node index of PE2 is represented by B = 0 and NodeIndex of 15 bits with value of 2 (i.e., NodeIndex = 2). The indexes of egress nodes PE3 to PE6 are represented by four fields: B flag of 1 bit with value of 1, StartIndex of 15 bits with value of 30002, S-BitString of 8 bits with value of 1, and BitString of 1 byte (i.e., 8 bits) with value 0b11110000. S-BitString = 1 indicates BitString occupies 1 byte. BitString = 0b11110000 combined with StartIndex = 30002 indicates four node indexes 30003 to 30006. The BitString's first bit = 1 indicates the first node index after StartIndex = 30002, which is 30003 (i.e., 30003 = 30002 + 1); The BitString's second bit = 1 indicates the second node index after StartIndex = 30002, which is 30004 (i.e., 30004 = 30002 + 2); and so on. 3. Node Index Table Every node in a network has a node index IPv6 table. The table has a row for the index of each egress node with the IPv6 address and the index of the next hop on the shortest path to that node. This table indicates the shortest IGP path to each egress, i.e., the next hop of the shortest path to each egress. This is similar to a unicast forwarding table but organized by exact match node index rather than longest match IP address or the like. Figure 5 shows an example Node Index IPv6 table of PE1 in Figure 1. Chen, et al. Expires January 12, 2023 [Page 6] Internet-Draft BE Multicast in MRH July 2022 +============+==========================+====================+ | Node index | IPv6 Address of next hop | Index of next hop | +============+==========================+====================+ | 1 | NULL | NULL | +------------+--------------------------+--------------------+ | 2 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 3 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 4 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 5 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 6 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 7 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 8 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 9 | IPv6 address of P1 | 11 (index of P1) | +------------+--------------------------+--------------------+ | 10 | IPv6 address of PE10 | 10 (index of PE10)| +============+==========================+==================-=+ Figure 5: Node Index IPv6 Table of PE1 The table has 10 rows of node index and IPv6 address. The 10 rows have node indexes of egress nodes PE1 to PE10, the IPv6 addresses and the indexes of the next hops of the shortest paths to PE1 to PE10 respectively. The next hop to PE1 itself is NULL. The next hop to each of PE2 to PE9 is P1. The next hop to PE10 is PE10. Note: The information such as port number or interface used to forward a packet to the next hop is not shown in the figure, which is the same as the corresponding information in the forwarding table (FIB) of PE1. For example, the second row has node index 2 of PE2 and the IPv6 address of the next hop node to PE2, which is IPv6 address of P1 since the next hop to PE2 is P1. The tenth row has node index 10 of PE10 and the IPv6 address of the next hop to PE10, which is IPv6 address of PE10 since the next hop to PE10 is PE10. Figure 6 shows an example Node Index IPv6 table of P1 in Figure 1. The table has 10 rows of node index and IPv6 address. The 10 rows have node indexes of PE1 to PE10 and the IPv6 addresses of the next hops of the shortest paths to PE1 to PE10 respectively. Chen, et al. Expires January 12, 2023 [Page 7] Internet-Draft BE Multicast in MRH July 2022 +============+==========================+===================+ | Node index | IPv6 Address of next hop | Index of next hop | +============+==========================+===================+ | 1 | IPv6 address of PE1 | 1 (index of PE1)| +------------+--------------------------+-------------------+ | 2 | IPv6 address of P2 | 12 (index of P2) | +------------+--------------------------+-------------------+ | 3 | IPv6 address of P2 | 12 (index of P2) | +------------+--------------------------+-------------------+ | 4 | IPv6 address of P5 | 15 (index of P5) | +------------+--------------------------+-------------------+ | 5 | IPv6 address of P5 | 15 (index of P5) | +------------+--------------------------+-------------------+ | 6 | IPv6 address of P5 | 15 (index of P5) | +------------+--------------------------+-------------------+ | 7 | IPv6 address of P5 | 15 (index of P5) | +------------+--------------------------+-------------------+ | 8 | IPv6 address of PE8 | 8 (index of PE8)| +------------+--------------------------+-------------------+ | 9 | IPv6 address of PE9 | 9 (index of PE9)| +------------+--------------------------+-------------------+ | 10 | IPv6 address of PE1 | 1 (index of PE1)| +============+==========================+===================+ Figure 6: Node Index IPv6 Table of P1 For example, the first row has node index 1 of PE1 and the IPv6 address of the next hop node to PE1, which is IPv6 address of PE1 since the next hop to PE1 is PE1. The second row has node index 2 of PE2 and the IPv6 address of the next hop node to PE2, which is IPv6 address of P2 since the next hop to PE2 is P2. The fourth row has node index 4 of PE4 and the IPv6 address of the next hop node to PE4, which is IPv6 address of P5 since the next hop to PE4 is P5. The tenth row has node index 10 of PE10 and the IPv6 address of the next hop to PE10, which is IPv6 address of PE1 since the next hop to PE10 is PE1. 4. IPv6 Multicast Routing Header (MRH) Figure 7 shows a Multicast Routing Header (MRH) in an IPv6 packet. The IPv6 packet has an IPv6 header with a destination address (DA) and source address (SA) of IPv6, a routing header with Routing type Chen, et al. Expires January 12, 2023 [Page 8] Internet-Draft BE Multicast in MRH July 2022 (TBD) indicating MRH and an IP multicast datagram. The routing header is indicated by the Next Header in the IPv6 header. |<--IPv6 header-->|<-Routing header->| +-----------------+------------------+------------------------+ | Next Header = | Next Header | (an extension header) | | Routing header | | IP multicast datagram | | SA=IPv6 Address | Routing Type = | | | DA=IPv6 Address | TBD (MRH) | | | | SL, NE, Sub-tree | | +-----------------+------------------+------------------------+ |<---- MRH ---->| Figure 7: Multicast Routing Header (MRH) in IPv6 packet The format of the MRH is shown in Figure 8. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |RoutingType=TBD|Version| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SL (Subtree Left) |NE (# Egresses)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-tree encoding of node indexes | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Format of Multicast Routing Header (MRH) The MRH has the following fields: Next Header: The type of the header after the MRH. Either another extension header or the type of IP multicast datagram in the packet. Hdr Ext Len: Its value indicates the length of the MRH in a unit of 64 bits (i.e., 8 bytes) excluding the first 8 bytes. Routing Type: Its value TBD indicates that the routing header is a Multicast Routing Header (MRH). Version: The Version of the MRH. This document specifies Version zero. Flags: No flag is defined yet. Sub-tree Left (SL): Its value points to the sub-tree. Chen, et al. Expires January 12, 2023 [Page 9] Internet-Draft BE Multicast in MRH July 2022 Number of Egresses (NE): Its value indicates the number of egress nodes of the sub-tree. Sub-tree: Its value encodes the egress nodes of the sub-tree. A node index MUST NOT occur more than once. The node indexes in sub-tree are ordered so that, the egress nodes in every sub-tree of the P2MP tree are contiguous. The P2MP path/tree from PE1 via P1 to PE2, PE3, PE4, PE5 and PE6 as shown in Figure 1 is encoded by the indexes of the egress nodes of the tree as illustrated in Figure 2. For an IP multicast datagram/ packet to be transmitted by the P2MP path/tree, PE1 constructs an IPv6 packet for each sub-tree and sends the packet containing a MRH and the IP multicast datagram/packet to the next hop along the sub- tree. The number of sub-trees from PE1 is the number of different next hop nodes from PE1 to the egress nodes (i.e., PE2 to PE6). PE1 gets the next hops to the egress nodes using its Node Index IPv6 Table as shown in Figure 5 with the node indexes of the egress nodes, which are 2, 3, 4, 5 and 6. The next hops are the same, which are P1. Thus, there is one sub-tree from PE1 via P1 towards PE2 to PE6. PE1 sets DA of the IPv6 packet to P1's IPv6 address (P1's IPv6 for short) and SA of the packet to PE1's IPv6 address (PE1's IPv6 for short). PE1 builds the MRH based on the encoding of the tree in Figure 2 through including the sub-tree from P1 and setting SL to 10 as a pointer pointing to the sub-tree and setting NE to 5, which is the number of egresses of the sub-tree. Figure 9 shows the packet to be sent to P1, which is received by P1. Chen, et al. Expires January 12, 2023 [Page 10] Internet-Draft BE Multicast in MRH July 2022 | IPv6 Header | <------- MRH -------> | +----------------+---------------------------+-------------+ |DA = P1's IPv6 |RoutingType=TBD,SL=10,NE=5 |IP multicast | |SA = PE1's IPv6 |sub-tree from P1 to PE2-PE6|datagram | +----------------+---------------------------+-------------+ Size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | 2 | PE2's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 3 | PE3's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 4 | PE4's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 5 | PE5's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 | PE6's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: IPv6 packet with MRH received by P1 After receiving the IPv6 packet from PE1, P1 determines whether the packet's next header is a MRH through checking if the next header is a routing header, and if so, whether the routing type in the routing header is TBD for MRH. When the next header is the MRH, P1 duplicates the packet for each sub-tree from P1 and sends the packet copy with an updated MRH to the next hop along the sub-tree. P1 gets the next hops to the egress nodes using its Node Index IPv6 Table as shown in Figure 6 with the node indexes of the egress nodes, which are 2, 3, 4, 5 and 6. PE2 and PE3 have the same next hop P2 according to the table. PE4 to PE6 have the same next hop P5. There are 2 sub-trees from P1. One sub-tree is from P1 via next hop P2 to PE2 and PE3. The other is from P1 via next hop P5 to PE4, PE5 and PE6. P1 duplicates the packet for each of these two sub-trees and sends the packet copy to the next hop along the sub-tree. P1 sets the DA of one packet copy to P2's IPv6 address. P1 updates the MRH based on the encoding of the tree in Figure 9 through setting NE to the number of egress nodes of the sub-tree from P2 to PE2 and PE3 (which is 2). Figure 10 shows the IPv6 packet to be sent to P2, which is received by P2. Chen, et al. Expires January 12, 2023 [Page 11] Internet-Draft BE Multicast in MRH July 2022 | IPv6 Header | <------- MRH -------> | +----------------+---------------------------+-------------+ |DA = P2's IPv6 |RoutingType=TBD,SL=10,NE=2 |IP multicast | |SA = PE1's IPv6 |sub-tree from P2 to PE2-PE3|datagram | +----------------+---------------------------+-------------+ Size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | 2 | PE2's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 3 | PE3's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 4 | PE4's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 5 | PE5's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 | PE6's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: IPv6 packet with MRH received by P2 P1 sets the DA of the other packet copy to P5's IPv6 address. P1 updates the MRH based on the encoding of the tree in Figure 9 through setting SL to 6 as a pointer pointing to the start of the sub-tree from P5 to PE4, PE5 and PE6, setting NE to 3, which is the number of egress nodes of the sub-tree from P5 to PE4, PE5 and PE6. Figure 11 shows the IPv6 packet to be sent to P5, which is received by P5. | IPv6 Header | <------- MRH -------> | +----------------+---------------------------+-------------+ |DA = P5's IPv6 |RoutingType=TBD,SL=6,NE=3 |IP multicast | |SA = PE1's IPv6 |sub-tree from P5 to PE4-PE6|datagram | +----------------+---------------------------+-------------+ Size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 4 | PE4's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 5 | PE5's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 | PE6's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: IPv6 packet with MRH received by P5 After receiving the IPv6 packet from P1, P5 determines whether the packet's next header is an MRH. When the next header is an MRH, P5 duplicates the packet for each sub-tree from P5 and sends the packet copy with an updated MRH to the next hop along the sub-tree. Chen, et al. Expires January 12, 2023 [Page 12] Internet-Draft BE Multicast in MRH July 2022 P5 gets the next hops to the egress nodes using its Node Index IPv6 Table with the node indexes of the egress nodes, which are 4, 5 and 6. PE4, PE5 and PE6 have the same next hop P4 according to the table. P5 sets the DA of the packet copy to P4's IPv6 address. P5 updates the MRH based on the encoding of the tree in Figure 11 through setting SL to 6, which points to the start of the sub-tree from P4 to PE4, PE5 and PE6, NE to the number of egress nodes of the sub-tree from P4 to PE4 and PE5 (which is 3). Figure 12 shows the packet to be sent to P4, which is received by P4. | IPv6 Header | <------- MRH -------> | +----------------+---------------------------+-------------+ |DA = P4's IPv6 |RoutingType=TBD,SL=6,NE=3 |IP multicast | |SA = PE1's IPv6 |sub-tree from P4 to PE4-PE6|datagram | +----------------+---------------------------+-------------+ Size 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 4 | PE4's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 5 | PE5's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 | PE6's Index +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: IPv6 packet with MRH received by P4 After receiving the IPv6 packet from P5, P4 determines whether the packet's next header is an MRH. When the next header is the MRH, P4 duplicates the packet for each sub-tree from P4 and sends the packet copy with an updated MRH to the next hop along the sub-tree. P4 gets the next hops to the egress nodes using its Node Index IPv6 Table with the node indexes of the egress nodes, which are 4, 5 and 6. PE4, PE5 and PE6 are the next hops PE4, PE5 and PE6 themselves according to the table. P4 sends the copy with MRH containing SL = 0 to each of PE4, PE5 and PE6. The packet received by PE4 is shown in Figure 13. | IPv6 Header | <------- MRH -------> | +----------------+---------------------------+-------------+ |DA = PE4's IPv6 |RoutingType=TBD,SL=0,NE |IP multicast | |SA = PE1's IPv6 | |datagram | +----------------+---------------------------+-------------+ Figure 13: IPv6 packet with MRH received by PE4 Chen, et al. Expires January 12, 2023 [Page 13] Internet-Draft BE Multicast in MRH July 2022 When a leaf/egress such as PE4 receives an IPv6 packet with MRH having SL = 0, the leaf/egress sends the IP multicast packet to the multicast layer of the leaf/egress. 5. Procedures at Nodes This section describes the procedures at the ingress, transit and egress/leaf nodes of a P2MP path/tree delivering a packet received from the path to its destinations. 5.1. Procedure at Ingress Node For a packet to be transported by a P2MP path/tree, the ingress of the P2MP path/tree duplicates the packet for each sub-tree/branch of the P2MP path/tree branching from the ingress, encapsulates each packet copy in a MRH containing its sub-tree and sends the encapsulated packet copy to the next hop node along that sub-tree. For example, there is one sub-tree branching from the ingress of the P2MP path/tree in Figure 1. The sub-tree is from ingress PE1 via next hop node P1 towards PE2 to PE6. PE1 sends P1 the packet as shown in Figure 9. 5.2. Procedure at Transit Nodes When a transit node receives a packet encapsulated in an MRH, the node executes the procedure to duplicate the packet for each of the sub-trees/branches from the transit node on the path/tree and sends the packet copy to the next hop along each sub-tree. The number of sub-trees from the transit node is the number of different next hop nodes from the transit node to the egress nodes. The transit node gets the next hops to the egress nodes using its Node Index IPv6 Table with the node indexes of the egress nodes. The transit node sets the DA of a packet copy to a next hop node's IPv6 address. The transit node updates the MRH based on the encoding of the sub-tree in the packet received. For example, after receiving the IPv6 packet as shown in Figure 9, the transit node P1 duplicates the packet for each branch/sub-tree from P1 and sends the packet copy with an updated MRH to the next hop along the branch/sub-tree. P1 gets the next hops to the egress nodes using its Node Index IPv6 Table as shown in Figure 6 with the node indexes of the egress nodes, which are 2, 3, 4, 5 and 6 of PE2, PE3, PE4, PE5 and PE6 Chen, et al. Expires January 12, 2023 [Page 14] Internet-Draft BE Multicast in MRH July 2022 respectively. PE2 and PE3 have the same next hop P2 according to the table. PE4, PE5 and PE6 have the same next hop P5. There are 2 sub-trees from P1. One sub-tree is from P1 via next hop P2 to PE2 and PE3. The other is from P1 via next hop P5 to PE4, PE5 and PE6. P1 duplicates the packet for each of these two sub-trees and sends a packet copy to the next hop along each sub-tree. P1 sets the DA of one packet copy to P2's IPv6 address. P1 updates the MRH based on the encoding of the tree in Figure 9 through setting SL to 10 as a pointer pointing to the sub-tree from P2 to PE2 and PE3, and setting NE to 2, which is the number of egress nodes of the sub-tree. Figure 10 shows the packet to be sent to P2, which is received by P2. The other packet copy is updated in a similar fashion but for the other subtree. 5.3. Procedure at Egress Node When an egress node of a P2MP path receives a packet transported by the path, the DA of the packet is the IPv6 address of the egress node and the MRH in the packet has SL = 0. In this case, the egress node decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module. For example, after receiving the IPv6 packet from P4 as shown in Figure 13, PE4 determines that the packet has a MRH with SL = 0. PE4 decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module. 6. Security Considerations For general IPv6 and IPv6 extension header security considerations, see [RFC8200]. More TBD 7. IANA Considerations IANA is requested to assign a new Routing Type in the subregistry "Routing Types" under registry "Internet Protocol Version 6 (IPv6) Parameters" as follows: +===================+==========================+=============+ | Value | Description | Reference | +===================+==========================+=============+ | TBD (8 suggested) | Multicast Routing Header |This document| +===================+==========================+=============+ Chen, et al. Expires January 12, 2023 [Page 15] Internet-Draft BE Multicast in MRH July 2022 8. Acknowledgements TBD 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References [I-D.chen-pim-srv6-p2mp-path] Chen, H., McBride, M., Fan, Y., Li, Z., Geng, X., Toy, M., Mishra, G. S., Wang, A., Liu, L., and X. Liu, "Stateless SRv6 Point-to-Multipoint Path", draft-chen-pim-srv6-p2mp- path-06 (work in progress), April 2022. [I-D.ietf-pim-sr-p2mp-policy] (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Zhang, "Segment Routing Point-to-Multipoint Policy", draft-ietf-pim-sr-p2mp-policy-05 (work in progress), July 2022. Authors' Addresses Huaimo Chen Futurewei Boston, MA USA Email: Huaimo.chen@futurewei.com Chen, et al. Expires January 12, 2023 [Page 16] Internet-Draft BE Multicast in MRH July 2022 Donald E. Eastlake 3rd Futurewei 2386 Panoramic Circle Apopka, FL 32703 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Mike McBride Futurewei Email: michael.mcbride@futurewei.com Yanhe Fan Casa Systems USA Email: yfan@casa-systems.com Gyan S. Mishra Verizon 13101 Columbia Pike Silver Spring MD 20904 USA Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com Yisong Liu China Mobile Email: liuyisong@chinamobile.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: wangaj3@chinatelecom.cn Chen, et al. Expires January 12, 2023 [Page 17] Internet-Draft BE Multicast in MRH July 2022 Xufeng Liu IBM Corporation USA Email: xufeng.liu.ietf@gmail.com Lei Liu Fujitsu USA Email: liulei.kddi@gmail.com Chen, et al. Expires January 12, 2023 [Page 18]