<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-chen-pim-mrh6-06"
     ipr="trust200902">
  <front>
    <title abbrev="TE Multicast in MRH">
           Stateless Traffic Engineering Multicast using MRH</title>
     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>

    <author initials="M" fullname="Mehmet Toy" 
            surname="Toy">
      <organization> Verizon </organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <country>USA</country>
        </postal>
        <email>mehmet.toy@verizon.com</email>
      </address>
     </author>
    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

  <author fullname="Yisong Liu" initials="Y" surname="Liu">
   <organization>China Mobile</organization>
   <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
    <email>liuyisong@chinamobile.com</email>
   </address>
  </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Alef Edge</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2024"/>

    <abstract>
      <t>This document describes a stateless traffic engineering (TE) 
         multicast along an explicit P2MP Path/Tree using 
         an IPv6 extension header called
         TE multicast routing header (MRH). 
         The MRH with the path encoded in link numbers
         is added into a packet to be multicast at the ingress. 
         The packet is delivered to the egresses along the path.
         There is no state stored in the core of the network.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"></xref> <xref target="RFC8174"></xref>
      when, and only when, they appear in all
      capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	

     <t><xref target="I-D.ietf-pim-sr-p2mp-policy"/> proposes a 
        solution for a SR P2MP path.       
        A multicast P2MP tree is created for the path and the state 
        of the tree
        is instantiated in the forwarding plane by a controller at
        Root, intermediate Replication nodes and Leaves of the tree.
      </t>
<!--
     <t><xref target="I-D.ietf-bier-te-arch"/> introduces Bit Index 
        Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE).
        It is a stateless solution for multicast using L2.5.
        The overhead for encoding the P2MP path using bit strings may be big.</t>
-->
     <t><xref target="I-D.chen-pim-srv6-p2mp-path"/> proposes a 
        stateless solution for a SR P2MP path. 
        The overhead for encoding the P2MP path using SIDs in SRH 
        may be large.</t>

     <t>This document describes a stateless traffic engineering (TE) 
         multicast along an explicit P2MP Path/Tree using 
         an IPv6 extension header called
         TE multicast routing header (MRH). 

         The MRH with the path encoded in link numbers
         is added into a packet to be multicast at the ingress. 
         The packet is delivered to the egresses along the path.
         There is no state stored in the core of the network.
        </t>  
    </section> <!-- Introduction -->


    <section title="Overview of TE Multicast using MRH">
     <t><xref target = "p2mp-path-R-L14"/> 
        shows an example network having nodes 
        P1, P2, P3, P4, PE1 to PE10. 
        For each of the links connected to a node, 
        a number called local link number (or link number for short)
        is assigned to it. 
        For example, PE1 has three links: link from PE1 to CE1, 
        link from PE1 to P1, and link from PE1 to PE10. 
        These three links have link numbers 1, 2 and 3 
        respectively on PE1. 
        P1 has five links: P1 to PE1, P1 to P2, P1 to P3, P1 to PE8 
        and P1 to PE9. 
        These five links have link numbers 1, 2, 3, 4 and 5 
        respectively on P1. 
        P3 has two links: P3 to P1 and P3 to P4. 
        These two links have link numbers 1 and 2 respectively 
        on P3.</t>

    <t>
<figure anchor="p2mp-path-R-L14" 
 title="Network with P2MP Path from ingress PE1 to 
egresses PE2, PE3, ..., PE9">
  <artwork  align="center"> <![CDATA[
                            [PE2]            PE1: Ingress/Root
                           1/                PEi(i=2,3,..,,9): Egress
                           /                 Pi: Transit Node
                         1/      1
                        [P2]------[PE3]
                       3/    2   
                       /
        1      2   1  /2      1
[CE1].....[PE1]------[P1]------[P3]     [PE4]
           3:     5/ 4\   3    2\      1/
            :     /    \         \     /
           1:   1/     1\        1\  2/    1
         [PE10] [PE9]   [PE8]     [P4]------[PE5]
                                 5/ 4\  3
                                 /    \
                               1/     1\
                              [PE7]    [PE6]
]]></artwork>
</figure>
</t>

    <t>The P2MP path from ingress PE1 via P1 towards egresses PE2 to PE9
       in <xref target = "p2mp-path-R-L14"/> is represented 
       by the link numbers along the path: 
       PE1's link number 2; P1's link numbers 2, 3, 4 and 5; 
       P2's link numbers 1 and 2; P3's link number 2; and 
       P4's link numbers 2, 3, 4 and 5.</t>

    <t>A controller such as PCE as a
   controller has the link numbers of the links originating at every
   node. The controller can send the ingress
   the P2MP path represented by the link numbers of the links along the path.
    </t>
  
    <t>After receiving a packet from traffic source CE1, 
       ingress PE1 encapsulates the packet in a MRH with 
       a P2MP path represented by the link numbers along the path. 
       The packet in the MRH is transmitted along the path to 
       the egresses of the path.</t> 

    <t>When a node such as P1 receives a packet with the MRH, 
       the node gets/pops each of its link numbers, 
       finds the address of the next hop from a neighbor address table 
       using the link number (i.e., the link number such as 3 of 
       the link from the node to the next hop such as P3), and
       sends the packet to the next hop (such as P3).</t> 

    <t><xref target = "p1-neighbor-table"/> 
       shows the neighbor IPv6 address table of P1. 
       The table has five rows of link number, 
       link type and IPv6 address for the five links of P1. 
       The first row has link number 1, link type P2P 
       for link from P1 to next hop PE1 and PE1's IPv6 address. 
       The 2nd row has link number 2, link type P2P 
       for link from P1 to next hop P2 and P2's IPv6 address. 
       The 3rd row has link number 3, link type P2P 
       for link from P1 to next hop P3 and P3's IPv6 address.
       The 4-th row has link number 4, link type P2P 
       for link from P1 to next hop PE8 and PE8's IPv6 address.
       The 5-th row has link number 5, link type P2P 
       for link from P1 to next hop PE9 and PE9's IPv6 address.
</t> 
    <t>
<figure anchor="p1-neighbor-table" 
 title="Neighbor IPv6 address table of P1">
  <artwork  align="center"> <![CDATA[
+==============+============+======================+
| Link number  | Link type  | Address of next hop  |
+==============+============+======================+
|      1       |    P2P     | IPv6 address of PE1  |
+--------------+------------+----------------------+
|      2       |    P2P     | IPv6 address of P2   |
+--------------+------------+----------------------+
|      3       |    P2P     | IPv6 address of P3   |
+--------------+------------+----------------------+
|      4       |    P2P     | IPv6 address of PE8  |
+--------------+------------+----------------------+
|      5       |    P2P     | IPv6 address of PE9  |
+==============+============+======================+]]></artwork>
</figure>
</t>
   <t>Using link number 1, 
      P1 gets PE1's IPv6 address from the table; 
      using link number 2, P1 gets P2's IPv6 address from the table; 
      using link number 3, P1 gets P3's IPv6 address from the table; 
      and so on.</t>	  
    </section> <!-- Overview of P2MP Multicast Tree --> 


    <section title="Encoding of P2MP Path/Tree">
      <t><xref target = "srh-p2mp-p1-2-l1-4"/> 
         shows the encoding of the P2MP path/tree in 
         <xref target = "p2mp-path-R-L14"/> 
         from PE1 via P1 to PE2, PE3, ..., PE9. 
         Each link on the tree is encoded or represented by 
         the link number of the link. 

         For example, the link from PE1 to P1 on the tree is 
         encoded by link number 2 of the link on PE1. 
         The link from P1 to P2 on the tree is encoded 
         by link number 2 of the link on P1. 
         The link from P1 to P3 on the tree is encoded 
         by link number 3 of the link on P1.</t>

      <t>For each link from its upstream node to its downstream 
(or say next hop) node on the tree, three fields are used for the 
link: 
1). link number (Link-No for short) field for storing the link number
on the upstream node, 
2). number of branches (N-Branches for short) for
storing the number branches/sub-trees of the tree from the next hop 
node, and 3). size of branches+ (S-Branches+ for short) for 
storing the size of branches of the tree from the next hop node and 
the fields following. The size is in bytes.</t>
<t>

<figure anchor="srh-p2mp-p1-2-l1-4" 
 title="Encoding of tree from PE1 via P1
        to PE2, PE3, ..., PE9">
  <artwork align="center"> <![CDATA[
     +=======+==========+===========+
size |Link-No|N-Branches|S-Branches+|  link
     +=======+==========+===========+                     -+
 24  |   2   |    4     |    22     | PE1 to P1            |
     +-------+----------+-----------+                      |sub-tree
 22  |   2   |    2     |    14     | P1 to P2             |from PE1
     +-------+----------+-----------+                      |to P1
 20  |   3   |    1     |    10     | P1 to P3             |to PE2-PE9
     +-------+----------+-----------+                      |
 18  |   4   |    0     |    0      | P1 to PE8            |
     +-------+----------+-----------+                      |
 16  |   5   |    0     |    0      | P1 to PE9            |
     +-------+----------+-----------+          -+          |
 14  |   1   |    0     |    0      | P2 to PE2 |sub-trees |
     +-------+----------+-----------+           |from P2   |
 12  |   2   |    0     |    0      | P2 to PE3 |          |
     +-------+----------+-----------+          -+          |
 10  |   2   |    4     |    8      | P3 to P4  |          |
     +-------+----------+-----------+           |sub-tree  |
  8  |   2   |    0     |    0      | P4 to PE4 |from P3   |
     +-------+----------+-----------+           |          |
  6  |   3   |    0     |    0      | P4 to PE5 |          |
     +-------+----------+-----------+           |          |
  4  |   4   |    0     |    0      | P4 to PE6 |          |
     +-------+----------+-----------+           |          |
  2  |   5   |    0     |    0      | P4 to PE7 |          |
     +-------+----------+-----------+          -+         -+
]]></artwork>
</figure>
</t>
 
      <t>For example, for the link from PE1 to P1 on the tree, 
Link-No field has value of 2 since the link number is 2 for the link on PE1;
N-Branches field has value of 4 since there are 4 branches from P1; 
S-Branches+ field has value of 22 (bytes) since 22 bytes are used 
for storing/encoding 4 branches from P1 when the three fields Link-No, 
N-Branches and S-Branches+ for a link 
occupy 2 bytes in total.</t>

      <t>For the link from P1 to P2 on the tree, 
Link-No field has value of 2 since the link number is 2 for the link on P1;
N-Branches field has value of 2 since there are two branches from P2; 
S-Branches+ field has value of 14 (bytes) since 14 bytes are used 
for storing/encoding the two branches (i.e., sub-trees) from P2 
and the fields following.</t>

      <t>For the link from P1 to P3 on the tree, 
Link-No field has value of 3 since the link number is 3 for the link on P1;
N-Branches field 
has value of 1 since there is one branch (i.e., sub-tree) from P3; 
S-Branches+ field has value of 10 (bytes) since 10 bytes are used 
for storing/encoding the branch from P3 and no other fields 
following.</t>

      <t>For the link from P2 to egress PE2 on the tree, Link-No 
field has value of 1 since the link number is 1 for the link on P2; 
N-Branches field has value of 0 since there is no branch (i.e., 
sub-tree) from PE2; S-Branches+ field has value of 0 (bytes).</t>

      <t><xref target = "p2mp-p1-2-l1-4-L"/> 
shows an enhancement of encoding the P2MP path/tree in 
<xref target = "p2mp-path-R-L14"/> 
using L flag. 
The L flag added for a link indicates whether the next hop is a 
leaf node. When L is set to one indicating the next hop is a leaf 
(i.e., egress), the "N-Branches" and "S-Branches+" fields are removed.
There are 8 links to leaves (i.e., egress nodes) on the tree, which
are 2 links from P2 to PE2 and PE3; 4 links from P4 to PE4, PE5, PE6 and 
PE7; and 2 links from P1 to PE8 and PE9.
These 8 links have their L flags set to one. 
The N-Branches and S-Branches+ fields for these 8 links are removed 
from the encoding of the tree. This reduces the space/memory for 
encoding the tree.</t>

<t>
<figure anchor="p2mp-p1-2-l1-4-L" 
 title="Encoding of tree from PE1 via P1
        to PE2, PE3, ..., PE9 with L flag">
  <artwork align="center"> <![CDATA[
     +=+=======+==========+===========+
size |L|Link-No|N-Branches|S-Branches+|  link
     +=+=======+==========+===========+                     -+
 16  |0|   2   |    4     |    14     | PE1 to P1            |
     +-+-------+----------+-----------+                      |sub-tree
 14  |0|   2   |    2     |    8      | P1 to P2             |from PE1
     +-+-------+----------+-----------+                      |to P1 to
 12  |0|   3   |    1     |    6      | P1 to P3             |PE2-PE9
     +-+-------+----------+-----------+                      |
 10  |1|   4   |                        P1 to PE8            |
     +-+-------+                                             |
  9  |1|   5   |                        P1 to PE9            | 
     +-+-------+                                 -+          |
  8  |1|   1   |                       P2 to PE2  |sub-trees |
     +-+-------+                                  |from P2   |
  7  |1|   2   |                       P2 to PE3  |          |
     +-+-------+----------+-----------+          -+          |
  6  |0|   2   |    4     |    4      |P3 to P4   |          |
     +-+-------+----------+-----------+           |sub-tree  |
  4  |1|   2   |                       P4 to PE4  |from P3   |
     +-+-------+                                  |          |
  3  |1|   3   |                       P4 to PE5  |          |
     +-+-------+                                  |          |
  2  |1|   4   |                       P4 to PE6  |          |
     +-+-------+                                  |          |
  1  |1|   5   |                       P4 to PE7  |          |
     +-+-------+----------+-----------+          -+         -+
]]></artwork>
</figure>
</t>

      <t>For example, suppose that two fields L and Link-No with padding 
(padding is not shown) for a link to leaf occupy 1 byte; 
four fields L, Link-No, N-Branches and S-Branches+ for a link
to a transit node occupy 2 bytes. 
In this case, the S-Branches+ field for link from PE1 to P1 is 14 
(bytes), which is the size of the fields for 11 links (i.e., link from
P1 to P2, link from P1 to P3, ..., link from P4 
to PE7) encoding the sub-trees from P1 to PE2, PE3, ..., PE9. 
The S-Branches+ field for link from P1 to P2 is 8 (bytes), which is 
the size of the fields for 7 links (i.e., link from P2 to PE2, 
link from P2 to PE3, link from P3 to P4, and 4 links from P4 to PE4 - PE7) 
encoding the sub-trees from P1 to PE2 and PE3, and 
the fields following them.</t>

      <t>Encoding the tree without L flag occupies 24 bytes in total 
as illustrated in <xref target = "srh-p2mp-p1-2-l1-4"/>. 
Encoding the tree with L flag occupies 16 bytes in total as 
illustrated in <xref target = "p2mp-p1-2-l1-4-L"/>. 
8 bytes (or say 33% of space/memory) are saved/reduced.</t>


      <t><xref target = "p2mp-p3-2-l4-7-B"/> 
shows an enhancement of encoding the branch/sub-tree from P3 to
PE4, PE5, PE6 and PE7 in <xref target = "p2mp-path-R-L14"/> 
using B flag. 
The B flag added for a link indicates whether 
the link bits+ are used to represent the link numbers 
and other link related information such as whether links' 
remote end nodes (i.e., next hops) are leaves. 
When B flag for the link from upstream node such as P3 
to downstream node such as P4 is set to one indicating the link bits+ 
are used, the links from downstream node such as P4 on the tree 
are encoded or represented by link bits+. 
A link bits+ contains a P (short for plus leaf) field, 
S-Bits (short for size of the bits in a unit such as byte) field, 
and Bits field.</t>

<t>P field has a value such as 1 indicating that a bit with value 
of 1 (one) in Bits field means that the corresponding link is 
on the branch and the link's next hop is a leaf. 
There are four links to leaves (i.e., egress nodes) from P4, 
which are link from P4 to PE4 with link number 2, 
link from P4 to PE5 with link number 3, 
link from P4 to PE6 with link number 4,  
and link from P4 to PE7 with link number 5. 
These four links are represented by 
the 2-th bit, 3-th bit, 4-th bit and 5-th bit in the Bits field 
(from left to right) respectively. </t>

<t>S-Bits field has a value such as 1 indicating the size of the 
Bits field in a unit such as byte.</t> 

<t>Suppose that the fields 
(i.e., L, B, Link-No, No-Branches and S-Branches+) for the link 
from P3 to P4 occupy 2 bytes; P and S-Bits occupy 1 byte. 
In this case, the link bits+ for the links from P4 occupy 2 bytes, 
encoding the branch from P3 uses 4 bytes in total.</t>

<t>The number of branches from P4 is the number of bits with value of 
one in the Bits field. 
The N-Branches field for the link from P3 to P4 is used 
for other purpose. 
For example, N-Branches field and S-Branches+ field combined to 
represent the size of the branches plus the fields following (i.e., 
S-Branches+).</t>

<t>
<figure anchor="p2mp-p3-2-l4-7-B" 
 title="Encoding of branch from P3 via P4
        to PE4, PE5, PE6, PE7 with B flag">
  <artwork align="center"> <![CDATA[
     +=+=+=======+==========+===========+
size |L|B|Link-No|N-Branches|S-Branches+|  link
     +=+=+=======+==========+===========+               -+
  4  |0|1|   2   |          |    2      | P3 to P4       |branch
     +-+-+-------+------+---+-----------+                |from P3
  2  |1|        1       |0 1 1 1 1 0 0 0| P4 to PE4-PE7  |to PE4-PE7
     +-+----------------+---------------+               -+
     |P|     S-Bits     |     Bits      |
]]></artwork>
</figure>
</t>


      <t><xref target = "p2mp-pe1-2-p1-2-p2-pe9-B"/> 
shows an enhancement of encoding the branch part from PE1 via P1 
to P2, P3, PE8 and PE9 on the P2MP tree/path in 
<xref target = "p2mp-path-R-L14"/>
using B flag. 
B flag for the link from upstream node PE1 to downstream node P1 
is set to one indicating that the link bits+ are used to 
represent the information about the links on the tree from 
downstream node P1. </t>

<t>P field has a value such as 0 indicating that a bit with value 
of 1 (one) in Bits field means that the corresponding link 
from downstream node P1 is on the tree. </t>

<t>S-Bits field has a value such as 1 indicating the size of Bits 
field in a unit such as byte. </t>

<t>Bits field of one byte has the second (2-th) bit, third (3-th) bit, 
4-th bit and 5-th bit set to one (from left to right), 
indicating four links from P1 on the tree: 
the link from P1 to P2 with link number 2, 
link from P1 to P3 with link number 3, 
link from P1 to PE8 with link number 4 and 
link from P1 to PE9 with link number 5.  
The fields for each of these links do not have Link-No field, 
which is called reduced fields. 
 </t>

<t>
<figure anchor="p2mp-pe1-2-p1-2-p2-pe9-B" 
 title="Encoding of branch part from PE1 via P1
        to P2, P3, PE8, PE9 with B flag">
  <artwork align="center"> <![CDATA[
     +=+=+=======+==========+===========+
size |L|B|Link-No|N-Branches|S-Branches+|  link
     +=+=+=======+==========+===========+              -+
 13  |0|1|   2   |          |    11     | PE1 to P1     |branch part
     +-+-+-------+------+---+-----------+               |from PE1
 11  |0|        1       |0 1 1 1 1 0 0 0| P1 to P2,P3,  |to P2,P3,
     +-+----------------+---------------+      PE8,PE9  |  PE8,PE9
     |P|     S-Bits     |     Bits      |               |
                                                        |
             |L|B|N-Branches|S-Branches+|               |
             +=+=+==========+===========+               |
             |0|0|     2    |     6     | P1 to P2      |
             +-+-+----------+-----------+               |
             |0|0|     1    |     4     | P1 to P3      |
             +-+-+----------+-----------+               |
             |1|                          P1 to PE8     |
             +-+                                        |
             |1|                          P1 to PE9     |
             +-+                                       -+
]]></artwork>
</figure>
</t>

<t>The reduced fields (i.e., L = 0, B = 0, No-Branches = 2, S-Branches+ = 6) 
for the link from P1 to P2 indicates that the link's next hop is not leaf, 
link bits+ is not used for the branches from P2, 
the number of branches from P2 is 2 and the size of the branches from P2 
plus the fields following is 6.</t>

<t>The reduced fields (i.e., L = 0, B = 0, No-Branches = 1, S-Branches+ = 4)
for the link from P1 to P3 indicates that the link's next hop is not leaf,
link bits+ is not used for the branches from P3, 
the number of branches from P3 is 1 and 
the size of the branches from P3 plus the fields following is 4.</t>

<t>The reduced fields (i.e., L = 1) for the link from P1 to PE8 
indicates that the link's next hop PE8 is a leaf.</t>

<t>The reduced fields (i.e., L = 1) for the link from P1 to PE9 
indicates that the link's next hop PE9 is a leaf.</t>

<t>Suppose the fields (i.e., L, B, Link-No, No-Branches and S-Branches+) 
for a link to a transit node occupy 2 bytes; 
P and S-Bits occupy 1 byte; 
the reduced fields (i.e., L, B, No-Branches and S-Branches+) 
for a link to a transit node occupy 11 bits, 
the reduced fields (i.e., L) for a link to a leaf occupy 1 bit.  
In this case the reduced fields for four links from P1 to P2, P3, PE8 
and PE9 uses 3 bytes (i.e., 24 bits). 
Encoding the branch part from PE1 via P1 to P2, P3, PE8 and PE9 uses 
7 bytes.</t>


<t><xref target = "p2mp-pe1-2-p1-2-pe2-pe9-B"/> 
shows an enhancement of encoding the P2MP path/tree in 
<xref target = "p2mp-path-R-L14"/> 
using both L and B flags.</t>

<t>The branch part from PE1 via P1 to P2, P3, PE8 and PE9 is the same as
the one in <xref target = "p2mp-pe1-2-p1-2-p2-pe9-B"/> 
and occupies 7 bytes.</t>

<t>The link from P2 to PE2 is represented by L = 1 and Link-No = 1. 
The link from P2 to PE3 is represented by L = 1 and Link-No = 2. 
These two links occupy 2 bytes. 

In an option, when L = 1, the Link-No field and Pad are combined to 
represent link number. </t>

<t>The branch from P3 is the same as the one in 
<xref target = "p2mp-p3-2-l4-7-B"/>
and occupies 4 bytes. 
Encoding the tree of 13 nodes uses 13 bytes in total.</t>

<t>
<figure anchor="p2mp-pe1-2-p1-2-pe2-pe9-B" 
 title="Encoding of tree from PE1
        to PE2 - PE9 with L and B">
  <artwork align="center"> <![CDATA[
     +=+=+=======+==========+===========+
size |L|B|Link-No|N-Branches|S-Branches+|  link
     +=+=+=======+==========+===========+                    -+
 13  |0|1|   2   |          |    11     | PE1 to P1           |sub-tree
     +-+-+-------+------+---+-----------+                     |from PE1
 11  |0|        1       |0 1 1 1 1 0 0 0| P1 to P2,P3,        |to P1 to
     +-+----------------+---------------+      PE8,PE9        |PE2-PE9
     |P|     S-Bits     |     Bits      |                     |
                                                              |
             |L|B|N-Branches|S-Branches+|                     |
             +=+=+==========+===========+                     |
  9          |0|0|     2    |     6     | P1 to P2            |
             +-+-+----------+-----------+                     |
             |0|0|     1    |     4     | P1 to P3            |
             +-+-+----------+-----------+                     |
             |1|                          P1 to PE8           |
             +-+                                              |
      L      |1|                          P1 to PE9           |
     +-+-----+-+-+                                 -+         |
  6  |1|  1  |Pad|                        P2 to PE2 |sub-tree |
     +-+-----+-+-+                                  |from P2  |
  5  |1|  2  |Pad|                        P2 to PE3 |         |
     +-+-+---+---+----------+-----------+          -+         |
  4  |0|1|   2   |          |     2     | P3 to P4  |sub-tree |
     +-+-+-------+------+---+-----------+           |from P3  |
  2  |1|        1       |0 1 1 1 1 0 0 0| P4 to PE4 |         |
     +-+----------------+---------------+      -PE7-+        -+
     |P|     S-Bits     |     Bits      |
]]></artwork>
</figure>
</t>

    </section> <!-- Encoding P2MP Path/Tree -->

    <section title="Multicast Routing Header (MRH)">
      <t><xref target = "mrh-in-pkt"/> shows 
a Multicast Routing Header (MRH) in an IPv6 packet.  
The IPv6 packet comprises an IPv6 header with a destination address
(DA) and source address (SA) of IPv6, 
a routing header with Routing type (TBD) indicating MRH and 
an IP multicast datagram. 
The routing header is indicated by the Next Header in the IPv6 header. 
</t>

<t>
<figure anchor="mrh-in-pkt" 
 title="Multicast Routing Header (MRH) in IPv6 packet ">
  <artwork align="center"> <![CDATA[
+-----------------+------------------+------------------------+
|   IPv6 header:  |  Routing header: | IP multicast datagram  |
|                 |                  | (IP datagram header +  |
|  Next Header =  | Next Header      |  data)                 |
|  Routing header |                  |                        |
|                 | Hdr Ext Len      |                        |
| SA=IPv6 Address | Routing Type =   |                        |
| DA=IPv6 Address |   TBD (MRH)      |                        |
|                 | SL, b, nB        |                        |
|                 | sub-tree         |                        |
+-----------------+------------------+------------------------+
                  |<----   MRH  ---->|
]]></artwork>
</figure>
</t>

      <t>The format of the MRH is shown in 
<xref target = "mrh-format"/>.

<figure anchor="mrh-format" 
 title="Format of Multicast Routing Header (MRH)">
  <artwork align="center"> <![CDATA[
 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|b|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SL (Subtree Left)  |nB (# Branches)|        Reserved         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Sub-tree encoded by link numbers                |
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The MRH has the following fields:
  <list style="hanging">
      <t hangText="Next Header:">The type of the header after the MRH.
         Either another extension header or the type of 
         IP multicast datagram in the packet.</t>
      <t hangText="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.</t>
      <t hangText="Routing Type:">Its value TBD 
         indicates that the routing header is a Multicast Routing 
         Header (MRH) for TE multicast.</t>
      <t hangText="Version:">The Version of the MRH. 
         This document specifies Version zero.</t>
      <t hangText="Flags:">A 1-bit b flag is defined. 
         b = 1 indicates the links directly from the root of
         the sub-tree are encoded by bits+.</t>
      <t hangText="Sub-tree Left (SL):">Its value as a pointer points to
         the sub-tree.</t>
      <t hangText="Number of Branches (nB):">Its value indicates 
          the number of branches from the root of the sub-tree.</t>
      <t hangText="Sub-tree:">Its value encodes the TE multicast 
         sub-tree using link numbers.</t>
  </list>
</t>

      <t>The P2MP path/tree from PE1 via P1 to PE2 - PE9
in <xref target = "p2mp-path-R-L14"/>
is encoded by the link numbers of the links on the tree as illustrated 
in <xref target = "p2mp-pe1-2-p1-2-pe2-pe9-B"/>. 
The link from ingress PE1 to P1 is encoded by the link number of 
the link on PE1, which is 2, 
the number of branches from P1 on the tree,   
and the size of the branches+ from P1, which is 11. 
The number of branches from P1 is the number of bits with value 1 
in the Bits field for the links from P1 to P2, P3, PE8 and PE9, 
which is 4 since there are 4 bits with value 1 in the Bits field.</t>

<t>For an IP multicast packet to be transmitted 
by the P2MP path/tree, PE1 constructs an IPv6 packet 
for each sub-tree/branch from PE1 and sends the packet 
containing a MRH and the IP multicast packet to the next hop 
along the sub-tree. </t>

<t>The P2MP path/tree has one sub-tree from PE1 via P1 to PE2 - PE9. 
PE1 finds P1's IPv6 address from PE1's neighbor IPv6 address table 
using the link number 2 and sets DA (destination address) of the 
IPv6 packet to P1's IPv6 address and SA (source address) of 
the IPv6 packet to PE1's IPv6 address. 
PE1 builds the MRH based on the encoding of the tree in 
<xref target = "p2mp-pe1-2-p1-2-pe2-pe9-B"/>
through setting b flag to 1, 
which is the value of B for the link from PE1 to P1,
SL to 11, which is the value of S-Branches+ 
for the link from PE1 to P1. 
nB is not set since B = 1.
<xref target = "pkt-mrh-2p1"/> shows the IPv6
packet to be sent to P1, which is received by P1.
Note that some details are not shown.</t>

<t>
<figure anchor="pkt-mrh-2p1" 
 title="IPv6 packet with MRH received by P1">
  <artwork align="center"> <![CDATA[
| IPv6 Header | <--------    MRH    --------> |
+-------------+-------------------------------+-------------+
|DA=P1's IPv6 |Routing Type=TBD,SL=11,b=1,nB  |IP multicast |
|SA=PE1's IPv6|sub-tree from P1 to PE2-PE9    |datagram     |
+-------------+-------------------------------+-------------+
size  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5   Link
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                    -+
 11  |0|      1      |0 1 1 1 1 0 0 0| P1 to P2,P3,PE8,PE9 |sub-tree
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     |from P1
  9   P        |0|0|  2  |     6     |     P1 to P2        |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+                 |
               |0|0|  1  |     4     |1|1| P1 to P3,       |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+   PE8,PE9       |
      L        |L|B|N-Bra|S-Branches+|L|L|                 |
     +-+-+-+-+-+-+-+-+                         -+          |
  6  |1|     1   |Pad|                 P2 to PE2|sub-trees |
     +-+-+-+-+-+-+-+-+                          |from P2   |
  5  |1|     2   |Pad|                 P2 to PE3|          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         -+          |
  4  |0|1|   2   |       |    2      | P3 to P4 |          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |sub-tree  |
  2  |1|      1      |0 1 1 1 1 0 0 0|P4 to PE4 |from P3   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    - PE7-+         -+
     |P|    S-Bits   |      Bits     |
]]></artwork>
</figure>
</t>

<t>The number of branches from P1 is 4, which is the number of bits 
with value 1 in the Bits field for the links from P1 to P2, P3, 
PE8 and PE9. This is determined by b = 1 and the Bits+ fields 
pointed by SL = 11.</t>

<t>There are 4 links from P1. 
The 2-th bit in the Bits field has value 1 indicating 
the link with link number 2, which is the link from P1 to P2. 
The reduced fields (i.e., L = 0, B = 0, No-Branches = 2, S-Branches+ = 6) 
for the link indicates that the link's next hop P2 is not leaf, 
link bits+ is not used for the branches from P2, 
the number of branches from P2 is 2 and 
the size of the branches from P2 plus the fields following is 6.</t>

<t>The 3-th bit has value 1 indicating the link with link number 3, 
which is the link from P1 to P3. 
The reduced fields (i.e., L = 0, B = 0, No-Branches = 1, S-Branches+ = 4) 
for the link indicates that the link's next hop P3 is not leaf, 
link bits+ is not used for the branches from P3, 
the number of branches from P3 Is 1 and 
the size of the branches from P3 plus the fields following is 4.</t>

<t>The 4-th bit has value 1 indicating the link with link number 4, 
which is the link from P1 to PE8. 
PE8 is a leaf, which is indicated by the first L = 1. 
The 5-th bit has value 1 indicating the link with link number 5, 
which is the link from P1 to PE9. 
PE9 is a leaf indicated by the second L = 1.</t>

<t>The link number of the link from P2 to leaf PE2 is 1 on P2. 
The link number of the link from P2 to leaf PE3 is 2 on P2.
The link number of the link from P3 to P4 is 2 on P3. 
The size of branches from P4 is 2. 
The link numbers of the links from P4 to leaf PE4, PE5, PE6 and PE7 
are 2, 3, 4 and 5 on P4 respectively.</t>

      <t>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 routing header and routing type in the routing header 
is TBD for MRH. When the next header is the MRH, P1 duplicates 
the packet for each link/branch/sub-tree from P1 and sends the packet copy 
with an updated MRH (note: only SL, b and nB are updated) 
to the next hop along the branch. 
Since b = 1, the number of bits with value 1 in the Bits field 
of Bits+ pointed by SL = 11 is the number of branches/links 
from P1 according to <xref target = "pkt-mrh-2p1"/>, which is 4.</t>

<t>The 2-th bit in the Bits field has value 1 indicating 
the link with link number 2, which is the link from P1 to P2. 
The first reduced fields is for link from P1 to P2 and 
indicates the number of branches from P2 is 2 and 
the size of branches from P2 plus the ones following them is 6.</t>


<t>P1 duplicates the packet for the link with link number 2, 
finds P2's IPv6 address from P1's neighbor IPv6 address table using 
the link number 2 of the link from P1 to P2 and 
sets DA of the packet to P2's IPv6 address. 
P1 updates the MRH based on the encoding of the sub-tree in 
<xref target = "pkt-mrh-2p1"/>
through setting SL, b and nB to S-Branches+ = 6, B = 0 and 
N-Branches = 2 for the link from P1 to P2 respectively. 
<xref target = "pkt-mrh-2p2"/> 
shows the packet to be sent to P2, which is received by P2.</t>

<t>
<figure anchor="pkt-mrh-2p2" 
 title="IPv6 packet with MRH received by P2">
  <artwork align="center"> <![CDATA[
| IPv6 Header | <--------    MRH    --------> |
+-------------+-------------------------------+-------------+
|DA=P2's IPv6 |Routing Type=TBD, SL=6,b=0,nB=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   Link
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      L| Link-No |
     +-+-+-+-+-+-+-+-+                         -+          
  6  |1|     1   |Pad|                 P2 to PE2|sub-trees 
     +-+-+-+-+-+-+-+-+                          |from P2   
  5  |1|     2   |Pad|                 P2 to PE3|          
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         -+          
  4  |0|1|   2   |       |    2      | P3 to P4 |         
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |sub-tree 
  2  |1|      1      |0 1 1 1 1 0 0 0|P4 to PE4 |from P3  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    - PE7-+       
     |P|    S-Bits   |      Bits     |
]]></artwork>
</figure>
</t>

<t>The number of branches from P2 is 2. 
The link number of the link from P2 to PE2 is 1 on P2. 
The link number of the link from P2 to PE3 is 2 on P2. 
PE2 and PE3 are leaves (i.e., egresses), 
which are indicated by L = 1. </t>

<t>The fields for encoding the branch/sub-tree from P3 follows 
the branches/sub-trees from P2.</t>

<t>The 3-th bit has value 1 indicating the link with link number 3, 
which is the link from P1 to P3. 
The second reduced fields is for link from P1 to P3 and 
indicates the number of branches from P3 is 1 and 
the size of branches from P3 plus the ones following them is 4. </t>

<t>P1 duplicates the packet for the link with link number 3 
(which is link from P1 to P3) and 
sends the packet copy with an updated MRH to P3.</t>

<t>The 4-th bit has value 1 indicating the link with link number 4, 
which is the link from P1 to PE8. PE8 is a leaf, 
which is indicated by the first L = 1.</t>

<t>P1 duplicates the packet for the link with link number 4 and 
sends the packet copy with an updated MRH to PE8.</t>

<t>The 5-th bit has value 1 indicating the link with link number 5, 
which is the link from P1 to PE9. PE9 is a leaf, 
which is indicated by the second L = 1.</t>

<t>P1 duplicates the packet for the link with link number 5 and 
sends the packet copy with an updated MRH to PE9.</t>



      <t>
P1 duplicates the packet for the link with link number 3 
(which is link from P1 to P3), 
finds P3's IPv6 address from P1's neighbor IPv6 address table 
using the link number 3 of the link from P1 to P3 and 
sets DA of the packet to P3's IPv6 address. 
P1 updates the MRH based on the encoding of the sub-tree in 
<xref target = "pkt-mrh-2p1"/>

through setting SL, b and nB to S-Branches+ = 4, B = 0 and 
N-Branches = 1 in the reduced fields for the link from P1 to P3 
respectively. 
<xref target = "pkt-mrh-2p3"/>
shows the packet to be sent to P3, which is received by P3.</t>

<t>
<figure anchor="pkt-mrh-2p3" 
 title="IPv6 packet with MRH received by P3">
  <artwork align="center"> <![CDATA[
| IPv6 Header | <--------    MRH    --------> |
+-------------+-------------------------------+-------------+
|DA=P3's IPv6 |Routing Type=TBD, SL=4,b=0,nB=1|IP multicast |
|SA=PE1's IPv6|sub-tree from P3 to PE4-PE7    |datagram     |
+-------------+-------------------------------+-------------+
size  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5   Link                     
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           
         
     |L|B|Link-No|N-Branc|S-Branches+|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         -+     
  4  |0|1|   2   |       |    2      | P3 to P4 |          
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |sub-tree  
  2  |1|      1      |0 1 1 1 1 0 0 0|P4 to PE4 |from P3   
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    - PE7-+    
     |P|    S-Bits   |      Bits     |
]]></artwork>
</figure>
</t>

<t>The number of branches from P3 is 1. 
The link number of the link from P3 to P4 is 2 on P3. 
The size of branches from P4 is 2. 
B = 1 for the link from P3 to P4 indicates that the links from P4 are 
encoded by link bits+. 
The number of branches from P4 is the number of bits with value 1 
in the Bits field for the links from P4 to PE4 - PE7, 
which is 4 since there are 4 bits with value 1 in the Bits field.</t>

<t>After receiving the IPv6 packet from P1, P3 determines whether 
the packet's next header is a MRH. 
When the packet's next header is the MRH, 
P3 duplicates the packet for each link/branch/sub-tree from P3 and 
sends the packet copy with an updated MRH to the next hop 
along the branch. 
There is one branch from P3 according to the sub-tree remaining in 
the MRH in the packet received by P3. 
The branch/sub-tree is from the link from P3 to P4 towards PE4 - PE7. 
 </t>

      <t>P3 duplicates the packet for the branch/sub-tree, 
finds P4's IPv6 address from P3's neighbor IPv6 address table using 
the link number 2 of the link from P3 to P4 and 
sets DA of the packet to P4's IPv6 address. 
P3 updates the MRH based on the encoding of the sub-tree in 
<xref target = "pkt-mrh-2p3"/>
through setting SL and b to S-Branches+ = 2 and B = 1 for the link 
from P3 to P4 respectively. nB is not set or used since b = 1. 

<xref target = "pkt-mrh-2p4"/>
shows the packet to be sent to P4, which is received by P4.
</t>

<t>
<figure anchor="pkt-mrh-2p4" 
 title="IPv6 packet with MRH received by P4">
  <artwork align="center"> <![CDATA[
| IPv6 Header | <--------    MRH    --------> |
+-------------+-------------------------------+-------------+
|DA=P4's IPv6 |Routing Type=TBD, SL=2,b=1,nB  |IP multicast |
|SA=PE1's IPv6|sub-tree from P4 to PE4-PE7    |datagram     |
+-------------+-------------------------------+-------------+
size  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5   Link                     
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         -+sub-trees  
  2  |1|      1      |0 1 1 1 1 0 0 0|P4 to PE4 |from P4   
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    - PE7-+    
     |P|    S-Bits   |      Bits     |
]]></artwork>
</figure>
</t>

<t>After receiving the IPv6 packet from P3, 
P4 determines whether the packet's next header is a MRH. 
When the packet's next header is the MRH, 
P4 duplicates the packet for each branch/link from P4 and 
sends the packet copy with an updated MRH to the next hop 
along the branch. 
There are 4 branches/links from P4 according to the sub-tree 
remaining in the MRH in the packet received by P4. </t>

<t>
The 2-th bit in the Bits field has value 1 indicating the link 
with link number 2, which is the link from P4 to leaf PE4. </t>
<t>
The 3-th bit has value 1 indicating the link 
with link number 3, which is the link from P4 to leaf PE5. </t>
<t>
The 4-th bit has value 1 indicating the link 
with link number 4, which is the link from P4 to leaf PE6. </t>
<t>
The 5-th bit has value 1 indicating the link 
with link number 5, which is the link from P4 to leaf PE7. </t>

      <t>P4 duplicates the packet for the first branch, finds PE4's 
IPv6 address from P4's neighbor IPv6 address table using the link 
number 2 of the link from P4 to PE4 and sets DA of the packet to 
PE4's IPv6 address. 

P4 updates the MRH based on the encoding of the sub-tree in 
<xref target = "pkt-mrh-2p4"/>

through setting SL to 0 since PE4 is a leaf.
 
<xref target = "pkt-mrh-2pe4"/> shows 
the packet to be sent to PE4, which is received by PE4.

Similarly, P4 duplicates the packet for each of the other links, 
updates the MRH and sends the packet copy to each of PE5, PE6 and PE7.</t>

<t>
<figure anchor="pkt-mrh-2pe4" 
 title="IPv6 packet with MRH received by PE4">
  <artwork align="center"> <![CDATA[
| IPv6 Header | <--------    MRH    --------> |
+-------------+-------------------------------+-------------+
|DA=PE4's IPv6|Routing Type=TBD, SL=0, b, nB  |IP multicast |
|SA=PE1's IPv6|sub-tree/leaf PE4              |datagram     |
+-------------+-------------------------------+-------------+
]]></artwork>
</figure>
</t>

<t>After receiving the packet from P4, PE4 determines whether 
the packet's next header is a MRH. 
When the packet's next header is the MRH, 
PE4 checks if PE4 itself is a leaf (i.e., egress) 
through checking whether SL is 0. 
When PE4 is a leaf, 
PE4 decapsulates the packet and sends the IP multicast datagram 
to the IP multicast forwarding module.</t>

      <t>Alternatively, after receiving the packet from P3 and 
determining that the packet's next header is a MRH, 
P4 checks if each of its next hops is a leaf. 
When the next hop is a leaf, P4 decapsulates the packet and 
sends the IP multicast datagram to the next hop.
Since 4 next hops PE4 - PE7 are leaves, 
P4 sends the IP multicast datagram to PE4 - PE7.</t>
    </section> <!-- Multicast Routing Header (MRH) -->

    <section title="Procedures/Behaviors">
      <t>This section describes the procedures or behaviors on 
         the ingress, transit and egress/leaf node of a P2MP path
         to deliver a packet received from the path to its destinations.</t>

    <section title="Procedure/Behavior on Ingress Node">
      <t>For a packet to be transported by a P2MP Path, 
the ingress of the P2MP path duplicates the packet for each 
sub-tree/branch of the P2MP path branching from the ingress, 
encapsulates the packet copy in a MRH containing the sub-tree and 
sends the encapsulated packet copy to the next hop node along the 
sub-tree.</t>

      <t>For example, there is one sub-tree branching from the 
ingress of the P2MP path/tree in <xref target = "p2mp-path-R-L14"/>. 
The sub-tree is from ingress PE1 via next hop node P1 towards PE2 
to PE9.

PE1 sends P1 the packet as shown in 
<xref target = "pkt-mrh-2p1"/>.</t>

    </section> <!-- Procedure/Behavior on Ingress -->


    <section title="Procedure/Behavior on Transit Node">
<t>When a transit node of a P2MP path/tree receives a packet 
transported by the P2MP path/tree,  
the node determines whether the current routing header is a MRH. 
After determining that it is a MRH, the node executes the 
procedure to duplicate the packet for each of the downstream links 
of the node on the P2MP path/tree and send the packet copy to next hop 
(i.e., downstream node) of the link.</t>

      <t>Suppose that the transit node receives the packet from a 
upstream link from a upstream node to the transit node and there 
are n downstream links from the transit node on the P2MP path/tree 
(i.e., there are n branches/sub-trees from the transit node on 
the P2MP path/tree, where n is greater than zero). </t>

<t>The information about the upstream link is in b and nB field 
of the MRH. When b = 0, nB field contains the number of branches 
from the transit node. 
The information about n downstream links is pointed by SL. 
When b = 1, the number of branches from the transit node is 
the number of bits with value 1 in the Bits field of the Bits+ 
fields pointed by SL. 
The information about n downstream links is encoded by the Bits 
field and the fields following the Bits field.</t>

<t>For example, when node P1 receives the packet transported 
by the P2MP path/tree in <xref target = "p2mp-path-R-L14"/> 
from ingress PE1, the MRH is illustrated in 
<xref target = "pkt-mrh-2p1"/>. 

The b = 1, the Bits field of the Bits+ fields pointed by SL = 11 
has 4 bits with value 1. 
So there are 4 branches from P1. 
The information about 4 downstream links 
(i.e., link from P1 to P2, link from P1 to P3, link from P1 to PE8 
and link from P1 to PE9) is encoded by the Bits field and 
the reduced fields for these 4 links following the Bits field.</t>

<!--
<t>The top of the MRH (i.e., the root (information) of the sub-trees) 
is indicated by SL. 
For example, when P1 receives the packet transported by the P2MP 
path/tree in <xref target = "p2mp-path-R-L14"/>  
from PE1, the MRH is illustrated in <xref target = "pkt-mrh-2p1"/>. 
SL in the MRH is 11 (bytes), which acts as a pointer pointing to 
the root (information) of the sub-trees from P1. 
The root (information) is the information about the links from P1.</t>
-->

      <t>For each of the downstream links of the transit node, the 
transit node duplicates the packet for the link, sets SL, b and nB 
in the packet copy accordingly. 
If the next hop is a leaf (i.e., egress), the transit node sets SL to 0; 
otherwise, the transit node sets SL, b and nB to the value of 
S-Branches+, B and N-Branches for the link respectively when B is 0. 
When B = 1, the transit node sets SL and b to the value of 
S-Branches+ and B for the link respectively. 
The transit node finds the IPv6 address of the next hop 
(i.e., the downstream node) of the link from the neighbor IPv6 address 
table of the transit node using the link number of the link, 
sets the DA of the packet copy to the IPv6 address of the next hop,  
and sends the packet copy to the next hop of the link.</t>

<t>For example, for the first downstream link from P1 (i.e., 
link from P1 to P2), P1 duplicates the packet for the link, 
sets SL to 6 (which is the value of the S-Branches+ field for the link), 
b to 0 (which is the value of B for the link) and nB to 2 
(which is the value of the N-Branches field for the link). 
P1 finds the IPv6 address of the next hop P2 of the link from 
the neighbor IPv6 address table of P1 using the link number 2 
of the link, sets the DA of the packet copy to the P2's IPv6 address, 
and sends the packet copy to P2. 
The packet copy received by P2 is shown in 
<xref target = "pkt-mrh-2p2"/>.</t>

      <t>For the second downstream link from P1 
(i.e., link from P1 to P3), P1 duplicates the packet for the link, 
sets SL, b and nB to 4, 0 and 1 respectively, 
which are the values of S-Branches+, B and N-Branches for the link 
from P1 to P3 respectively. 
P1 finds the IPv6 address of the next hop P3 of the link from the 
neighbor IPv6 address table of P1 using the link number 3 of the link, 
sets the DA of the packet copy to the P3's IPv6 address, and 
sends the packet copy to P3. 
The packet copy received by P3 is illustrated in 
<xref target = "pkt-mrh-2p3"/>.
</t>

      <t>For the 3-th downstream link from P1 
(i.e., link from P1 to PE8), P1 duplicates the packet for the link, 
sets SL to 0 since PE8 is a leaf (i.e., egress). 
P1 finds the IPv6 address of the next hop PE8 of the link from the 
neighbor IPv6 address table of P1 using the link number 4 of the link, 
sets the DA of the packet copy to the PE8's IPv6 address, 
and sends the packet copy to PE8.</t>

    </section> <!-- Procedure/Behavior on Transit Node  -->

    <section title="Procedure/Behavior on Egress Node">
      <t>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 there is an indication in the MRH for the leaf/egress. 

The egress node proceeds to process the next header 
in the packet.</t>

      <t>For example, after receiving the IPv6 packet from P4, 
PE4 determines whether the packet's next header is a MRH. 
When the packet's next header is the MRH, PE4 checks if PE4 itself 
is a leaf (i.e., egress) through checking whether SL is 0. 
When PE4 is a leaf, PE4 decapsulates the packet and sends the IP 
multicast datagram to the IP multicast forwarding module.</t>
    </section> <!-- Procedures/Behaviors on Egress Node -->

   </section> <!-- Procedures/Behaviors  -->

    <section anchor="IANA" title="IANA Considerations">
      <t>
This document requests assigning a new Routing Type in the subregistry 
"Routing Types" under registry
"Internet Protocol Version 6 (IPv6) Parameters"
as follows:
        <figure>
            <artwork align="center"><![CDATA[
   +===================+==========================+=============+
   | Value             | Description              | Reference   |
   +===================+==========================+=============+
   | TBD (7 suggested) | Multicast Routing Header |This document|
   +===================+==========================+=============+]]></artwork>
          </figure>

</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Donald Eastlake
         for the valuable comments and suggestions on this draft.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8200"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.chen-pim-srv6-p2mp-path"?>
<!--
      <?rfc include="reference.I-D.ietf-bier-te-arch"?>
-->
	  <?rfc include="reference.I-D.ietf-pim-sr-p2mp-policy"?>
    </references>


  </back>

</rfc>
