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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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]