WO2023147477A1 - Multicast routing header using link number - Google Patents

Abstract

A method implemented by an ingress node in a multicast domain along a point-to-multipoint (P2MP) path. The method includes receiving a packet from a multicast source; duplicating the packet for each sub-tree branch branching from the ingress node of the P2MP path; and encapsulating a duplicate packet in a multicast routing header (MRH) for each sub-tree branch of the P2MP path. The MRH includes a link number for each link of the sub-tree branch. The method further includes transmitting the duplicate packet to a next hop node.

Description

Multicast Routing Header using Link Number

CROSS-REFERENCE TO REA TED APPLICATIONS

[0001] This patent application claims the benefit of U.S. Provisional Patent Application No. 63/303,823 filed January 27, 2022 by Futurewei Technologies, Inc., and titled “Multicast Routing Header using Link Number,” which is hereby incorporated by reference.

TECHNICAL FIELD

[0002] The present disclosure is generally related to the field of network communication and, in particular, to multicast routing header or multicast segment routing (SR) over the Internet Protocol version six (IPv6) data plane (SRv6), and specifically to stateless multicast tree engineering (TE) including Bit Index Explicit Replication - Tree Engineering (BIER-TE) and stateless SR Point to Multipoint (P2MP) path.

BACKGROUND

[0003] The packet header (e.g., BIER header with multiple bit strings encoding a BIER-TE path, or segment routing header with the multicast segment identifiers (SIDs) encoding an SR P2MP path) may be very big. This increases the overhead of multicast tree engineering (TE) and decreases the efficiency of multicast TE.

SUMMARY

[0004] The currently proposed solutions for multicast TE disclose techniques for providing a multicast routing header (MRH) having a point to point multipoint (P2MP) path encoded in link numbers.

[0005] A first aspect relates to a method implemented by an ingress node in a multicast domain along a multipoint P2MP path, comprising receiving a packet from a multicast source, duplicating the packet for each sub-tree branch branching from the ingress node of the P2MP path, encapsulating a duplicate packet in a MRH for each sub-tree of the P2MP path, wherein the MRH includes a link number for each link of the sub-tree branch; and transmitting the duplicate packet to a next hop node.

[0006] Optionally, in the preceding aspect, another implementation further comprises saving link numbers in a neighbor table comprising a link number, a link type and a next hop address. [0007] Optionally, in either of the preceding aspects, in another implementation the next hop address comprises a media access control (MAC) address.

[0008] Optionally, in any of the preceding aspects, the next hop address comprises an internet protocol (IP) address.

[0009] Optionally, in any of the preceding aspects, the next hop address comprises an internet protocol version 4 (IPv4) address.

[0010] Optionally, in any of the preceding aspects, the next hop address comprises an internet protocol version 6 (IPv6) address.

[0011] Optionally, in any of the preceding aspects, the link type comprises one or more point- to-point (P2P) link, multicast loopback (ML) link, or local area network (LAN) link.

[0012] Optionally, in any of the preceding aspects, encapsulating the packet in an MRH further comprises assigning a leaf flag bit (L) when a next hop node is a leaf node and assigning an extended flag bit (E) when a link number is too large to be represented by a basic field.

[0013] A second aspect relates to a method implemented by a transit node in a multicast domain along a P2MP path, comprising receiving a packet comprising a MRH, duplicating the packet, extracting one or more link numbers from the MRH, obtaining, based on a link number, a next hop address and transmitting, based on the next hop address, the duplicated packet to a next hop node.

[0014] Optionally, in the preceding aspect, obtaining a next hop address further comprises accessing a neighbor table comprising a link number, a link type and a next hop address.

[0015] Optionally, in either of the preceding aspects, the next hop address can be a media access control (MAC) address or an internet protocol (IP) address.

[0016] Optionally, in any of the preceding aspects the link type comprises at least one of, a point-to-point (P2P), a multicast loopback (ML) link or a local area network (LAN) link.

[0017] Optionally, in any of the preceding aspects, the MRH further comprises a leaf flag bit (L) when a next hop node is a leaf node and an extended flag bit (E) when a link number is too large to be represented by a basic field.

[0018] Optionally, in any of the preceding aspects, the transit node comprises a pseudo node.

[0019] A third aspect relates to an ingress node in a multicast domain along a P2MP path, comprising a memory storing instructions and a processor coupled to the memory, wherein the processor is configured to execute the instructions to cause the ingress node to receive a packet from a multicast source, duplicate the packet for each sub-tree branch branching from the ingress node of the P2MP path, encapsulate a duplicate packet in a multicast routing header (MRH) for each sub-tree of the P2MP path, wherein the MRH includes a link number for each link of the subtree branch and transmit the duplicate packet to a next hop node.

[0020] Optionally, in the preceding aspect, the processor is further configured to cause the ingress node to save link numbers in a neighbor table comprising a link number, a link type, and a next hop address.

[0021] Optionally, in either of the preceding aspects, the next hop address comprises either a media access control (MAC) address or an internet protocol (IP) address.

[0022] Optionally, in any of the preceding aspects, the link type comprises at least one of a point-to-point (P2P) link, a multicast loopback (ML) link or a local area network (LAN) link.

[0023] Optionally, in any of the preceding aspects, encapsulating the packet in an MRH further comprises assigning a leaf flag bit (L) when a next hop node is a leaf node and assigning an extended flag bit (E) when a link number is too large to be represented by a basic field.

[0024] A fourth aspect relates to a transit node in a multicast domain along a point-to- multipoint (P2MP) path, comprising a memory storing instructions and a processor coupled to the memory, in which the processor is configured to execute the instructions to cause the transit node to receive a packet comprising a multicast routing header (MRH), duplicate the packet, extract one or more link numbers from the MRH, obtain, based on a link number, a next hop address and transmit, based on the next hop address, the duplicated packet to a next hop node.

[0025] Optionally, in the preceding aspect, obtaining a next hop address further comprises accessing a neighbor table comprising a link number, a link type and a next hop address.

[0026] Optionally, in either of the preceding aspects, the next hop address comprises either a media access control (MAC) address or an internet protocol (IP) address.

[0027] Optionally, in any of the preceding aspects, the link type comprises at least one of, a to- point (P2P) link, a multicast loopback (ML) link or a local area network (LAN) link.

[0028] Optionally, in any of the preceding aspects, the MRH further comprises a leaf flag bit (L) when a next hop node is a leaf node and an extended flag bit (E) when a link number is too large to be represented by a basic field.

[0029] Optionally, in any of the preceding aspects, the transit node comprises a pseudo node. [0030] A fifth aspect relates to an ingress node in a multicast domain along a point-to- multipoint (P2MP) path, comprising means for receiving a packet from a multicast source, duplicating the packet for each sub-tree branch branching from the ingress node of the P2MP path, encapsulating a duplicate packet in a multicast routing header (MRH) for each sub-tree of the P2MP path, wherein the MRH includes a link number for each link of the sub-tree branch, and transmitting the duplicate packet to a next hop node.

[0031] A sixth aspect relates to a transit node in a multicast domain along a point-to-multipoint (P2MP) path, comprising means for receiving a packet having a multicast routing header (MRH) having a link number, duplicating the packet, extracting one or more link numbers from the MRH, obtaining, based on a link number, a next hop address and transmitting, based on the next hop address, the duplicated packet to a next hop node.

[0032] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

[0033] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0035] FIG. 1 shows an example network having nodes Pl, P2, P3, P4, PEI to PE6. For each of the links connected to a node, a number called local link number (or link number) is assigned.

[0036] FIG. 2 A shows an example neighbor table of Pl in FIG. 1, which is the neighbor media access control (MAC) address table of Pl.

[0037] FIG. 2B shows another example neighbor table of Pl in FIG. 1, which is the neighbor IP address table (IPv4 or IPv6) of Pl.

[0038] FIG. 2C shows an example neighbor table of PEI in FIG. 1, which is the neighbor IPv4 address table of PEI.

[0039] FIG. 2D shows an example neighbor table of egress node PE2 in FIG. 1, which is the neighbor IPv6 address table of PE2. [0040] FIG. 3 A shows an example network topology containing a broadcast link or a local area network (LAN) link.

[0041] FIG. 3B shows an example neighbor IPv6 address table of node G depicted in the example of FIG. 3 A.

[0042] FIG. 3C shows an example network topology containing a broadcast link as a pseudo node Px.

[0043] FIG. 3D shows an example main neighbor IPv6 address table of node G in the example network illustrated in FIG. 3C.

[0044] FIG. 3E shows the secondary neighbor IPv6 address table for pseudo node Px having link number, link type and IPv6 address for the four links of pseudo node Px.

[0045] FIG. 4A shows an example embodiment of encoding the P2MP path/tree in FIG. 1 from PEI via Pl to PE2, PE3, PE4 and PE5.

[0046] FIG. 4B shows an example embodiment of encoding the P2MP path/tree in the example of FIG. 1 from PEI via Pl to PE2, PE3, PE4 and PE5 using an L flag.

[0047] FIG. 5 A. shows an example of a Link-No field with E = 0, representing link number 3.

[0048] FIG. 5B shows an example of a Link-No field with E = 1 representing link number

4088 using the basic field and extended field combined.

[0049] FIG. 5C shows an example of a Link-No field with one extended field representing link number 1023 using the basic field and the extended field combined.

[0050] FIG. 5D shows an example of a Link-No field with two extended fields, representing link number 65535 using the basic field and the two extended fields combined.

[0051] FIG. 6A shows an example embodiment of encoding the P2MP path/tree in FIG. 1 from PEI via Pl to PE2, PE3, PE4 and PE5 using an L flag and an E flag.

[0052] FIG. 6B shows the encoding of the links in the tree from PEI via Pl towards PE2 to PE5.

[0053] FIG. 7 shows an embodiment of a Multicast Routing Header (MRH) between layer two and layer three. This MRH is called layer two and half (L2.5) MRH.

[0054] FIG. 8 A shows an example of a layer 2 packet received by PL

[0055] FIG. 8B shows an example of a layer 2 packet received by P2.

[0056] FIG. 8C shows an example of a layer 2 packet received by P3.

[0057] FIG. 8D shows an example of a layer 2 packet received by P4. [0058] FIG. 8E shows an example of a layer 2 packet with a header length zero (HL=0) received by PE5.

[0059] FIG. 8F shows an example layer 2 packet without MRH received by PE5.

[0060] FIG. 9 shows an example of a layer 2 packet received by P2.

[0061] FIG. 10A shows an embodiment of a MRH of layer three.

[0062] FIG. 10B shows an example of the format of a MRH of layer three.

[0063] FIG. 11 A shows an example of a layer 3 packet received by Pl .

[0064] FIG. 1 IB shows an example of a layer 3 packet received by P2.

[0065] FIG. 11C shows an example of a layer 3 packet received by P3.

[0066] FIG. 1 ID shows an example of a layer 3 packet received by PE2.

[0067] FIG. 1 IE shows an example of a layer 3 packet received by PE3.

[0068] FIG. 1 IF shows an example of a layer 3 packet received by P4.

[0069] FIG. 12A shows an example of a format of an IPv6 routing header.

[0070] FIG. 12B shows an example of a format of an IPv6 segment routing header.

[0071] FIG. 12C shows examples of formats of an IPv6 routing extension headers.

[0072] FIG. 13 illustrates a method implemented by an ingress node according to an embodiment of the disclosure.

[0073] FIG. 14 illustrates a method implemented by a transit node according to an embodiment of the disclosure.

[0074] FIG. 15 is a schematic diagram of a network apparatus according to an embodiment.

[0075] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

DETAILED DESCRIPTION

[0076] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. [0077] The present disclosure proposes systems and methods for multicast TE using multicast routing header (MRH) implemented by assigning link numbers. FIG. 1 shows an example multicast network domain having nodes Pl, P2, P3, P4, PEI to PE6. For each of the links connected to a node, a number called local link number (or link number) is assigned. For example, PEI has three links, a link from PEI to CE1, a link from PEI to Pl and a link from PEI to PE6. These three links have link numbers 1, 2 and 3 respectively on PEI. Pl has three links, a link from Pl to PEI, a link from Pl to P2 and a link from Pl to P3. These three links have link numbers 1, 2 and 3 respectively on Pl. P3 has two links, a link from P3 to Pl and a link from P3 to P4. These two links have link numbers 1 and 2 respectively on P3.

[0078] P2MP path from ingress PEI via Pl towards egresses PE2 to PE5 in FIG. 1 is represented by the link numbers along the path, PEl’s link number 2, Pl’s link numbers 2 and 3, P2’s link numbers 1 and 2, P3’s link number 2, and P4’s link numbers 2 and 3.

[0079] After receiving a packet from traffic source, ingress PEI 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.

[0080] When a node such as Pl 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 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).

[0081] Neighbor Table.

[0082] FIG. 2 A shows an example neighbor table of Pl in FIG. 1, which is the neighbor Media Access Control (MAC) address table of Pl. The table comprises three rows of link number, link type, and MAC address for the three links of Pl. The first row comprises link number 1 and link type P2P (Point to Point link) for link from Pl to next hop PEI and PEl’s MAC address. The second row comprises link number 2 and link type P2P for link from Pl to next hop P2 and P2’s MAC address. The third row comprises link number 3 and link type P2P for link from Pl to next hop P3 and P3’s MAC address. Using link number 1, Pl gets PEl’s MAC address from the table; using link number 2, Pl gets P2’s MAC address from the table; using link number 3, Pl gets P3’s MAC address from the table.

[0083] FIG. 2B shows another example neighbor table of Pl in FIG. 1, which is the neighbor IP (IPv4 or IPv6) address table of Pl. The table comprises three rows of link number, link type and IP address for the three links of Pl. The first row comprises link number 1 and link type P2P for link from Pl to next hop PEI and PEl’s IP address. The second row comprises link number 2 and link type P2P for link from Pl to next hop P2 and P2’s IP address. The third row comprises link number 3 and link type P2P for link from Pl to next hop P3 and P3’s IP address. Using link number 1, Pl gets PEl’s IP address from the table, using link number 2, Pl gets P2’s IP address from the table; using link number 3, Pl gets P3’s IP address from the table.

[0084] For an egress node, a special multicast link is configured on the node. This special multicast link is called a multicast loopback (ML) link or a multicast local decapsulation (Local Decap) link. For example, FIG. 1 shows an example network having egress nodes PEI, PE2, PE3, PE4, PE5, and PE6. A multicast loopback (ML) link is configured on each of these six egress nodes. Assume that the link numbers of these multicast loopback or local decap links configured on egress nodes PEI, PE2, PE3, PE4, PE5 and PE6 are 4, 2, 3, 4, 2 and 3, respectively.

[0085] FIG. 2C shows an example neighbor table of PEI in FIG. 1, which is the neighbor IPv4 address table of PEL The table comprises four rows of link number, link type, and IPv4 address for the four links of PEL The first row comprises link number 1, link type P2P for link from PEI to next hop CE1, and CEl’s IPv4 address. The second row comprises link number 2, link type P2P for link from PEI to next hop Pl, and Pl’s IPv4 address. The third row comprises link number 3, link type P2P for link from PEI to next hop PE6, and PE6’s IPv4 address. The fourth row comprises link number 4, and link type ML for the multicast loopback or local decapsulation link of PEL For the multicast loopback or local decapsulation link, the “Address of next hop” field is empty. For each of the P2P links, using link number 1, PEI gets CEl’s IPv4 address from the table; using link number 2, PEI gets Pl’s IPv4 address from the table; using link number 3, PEI gets PE6’s IPv4 address from the table. Using link number 4, PEI knows that the link with link number 4 is a multicast loopback or local decapsulation link from the table, and decapsulates the packet with the link.

[0086] FIG. 2D shows an example neighbor table of egress node PE2 in FIG. 1, which is the neighbor IPv6 address table of PE2. The table comprises two rows of link number, link type, and IPv6 address for the two links of PE2. The first row comprises link number 1, link type P2P for link from PE2 to next hop P2, and P2’s IPv6 address. The second row comprises link number 2 and link type ML for the multicast loopback or local decapsulation link of PE2. For the multicast loopback or local decapsulation link, the “Address of next hop” field is empty. Using link number 1, PE2 knows that the link with link number 1 is a P2P link from the table and gets P2’s IPv6 address from the table. Using link number 2, PE2 knows that the link with link number 2 is a multicast loopback or local decapsulation link from the table, and decapsulates the packet with the link.

[0087] FIG. 3 A shows an example multicast network domain or topology containing a broadcast or local area network (LAN) link. The broadcast or LAN link connects four nodes C, D, G and H. In an embodiment, these four nodes are considered as fully connected to each other by P2P links. These P2P links are shown in the figure by dashed lines. Node G has P2P link from node G to node B with link number 1, P2P link from node G to node H with link number 2, P2P link from node G to node D with link number 3, and P2P link from node G to node C with link number 4. Node D has P2P link from node D to node C with link number 1, P2P link from node D to node G with link number 2, P2P link from node D to node H with link number 3, and multicast loopback or local decap link with link number 4.

[0088] FIG. 3B shows an example neighbor IPv6 address table of node G depicted in the example of FIG. 3 A. The table comprises four rows of link number, link type and IPv6 address for the four links of node G. The first row comprises link number 1, link type P2P for the link from node G to next hop node B and node B’s IPv6 address. The second row comprises link number 2, link type P2P for the link from node G to next hop node H and node H’s IPv6 address. The third row comprises link number 3, link type P2P for the link from node G to next hop node D and node D’s IPv6 address. The fourth row comprises link number 4, link type P2P for link from G to next hop node C and node C’s IPv6 address. For each of P2P links, using link number 1, node G gets node B’s IPv6 address from the table; using link number 2, node G gets node H’s IPv6 address from the table; using link number 3, node G gets node D’s IPv6 address from the table; and using link number 4, node G gets node C’s IPv6 address from the table.

[0089] FIG. 3C shows an example multicast network domain or topology containing a broadcast or LAN link. The broadcast or LAN link connects four nodes C, D, G and H. In this example embodiment, each of these four nodes connects to a pseudo node Px by a link of type LAN, and pseudo node Px connects to each of nodes C, D, G and H by a link of type P2P. These P2P links are shown in FIG. 3C by dashed lines.

[0090] Node G has P2P link from node G to node B with link number 1, and LAN link from node G to pseudo node Px with link number 2. Node H has LAN link from node H to pseudo node Px with link number 1, and multicast loopback or local decap link with link number 2. Node D has LAN link from D to pseudo node Px with link number 1, and multicast loopback or local decap link with link number 2. Node C has P2P link from node C to node B with link number 1, LAN link from node C to Px with link number 2, and P2P link from node C to node F with link number 3.

[0091] Pseudo node Px has four P2P links from pseudo node Px to nodes C, G, H and D with link numbers 1, 2, 3, and 4, respectively.

[0092] Each of the four nodes C, G, H and D connected to pseudo node Px has two neighbor address tables, a main neighbor address table of the node, and a secondary neighbor address table for pseudo node Px.

[0093] FIG. 3D shows an example main neighbor IPv6 address table of node G in the example network illustrated in FIG. 3C. The table comprises two rows of link number, link type, and IPv6 address for the two links of node G. The first row comprises link number 1, link type P2P for link from node G to next hop node B, and node B’s IPv6 address. The second row comprises link number 2, link type LAN for link from node G to pseudo node Px, and a pointer to the secondary neighbor address table for pseudo node Px.

[0094] FIG. 3E shows the secondary neighbor IPv6 address table for pseudo node Px. The table comprises four rows of link number, link type, and IPv6 address for the four links of pseudo node Px. The first row comprises link number 1, link type P2P for link from pseudo node Px to next hop node C, and node C’s IPv6 address. The second row comprises link number 2, link type P2P for link from pseudo node Px to next hop node G, and node G’s IPv6 address. The third row comprises link number 3, link type P2P for link from Px to next hop node H, and node H’s IPv6 address. The fourth row comprises link number 4, link type P2P for link from pseudo node Px to next hop node D, and node D’s IPv6 address.

[0095] For a multicast packet containing the P2MP path with a LAN link from a node such as node G to the pseudo node Px for the LAN, the node sends the packet towards pseudo node Px's next hop nodes on the P2MP path encoded in the packet.

[0096] The node "sends" (i.e., works as sending) the packet to pseudo node Px according to the neighbor table of the node and the LAN link from the node to pseudo node Px. Then, the node acts as pseudo node Px to "send" (i.e., works as sending) the packet to each of the pseudo node Px's next hop nodes that are on the P2MP path using the secondary neighbor table for pseudo node Px. [0097] Encoding of P2MP Path/Tree (basic).

[0098] FIG. 4A shows an example embodiment of encoding the P2MP path/tree in FIG. 1 from PEI via Pl to PE2, PE3, PE4, and PE5. Each link on the tree is encoded or represented by the link number of the link. For example, the link from PEI to Pl on the tree is encoded by link number 2 of the link on PEI. The link from Pl to P2 on the tree is encoded by link number 2 of the link on Pl. The link from Pl to P3 on the tree is encoded by link number 3 of the link on Pl.

[0099] For each link from its upstream node to the next downstream (or next hop) node on the tree, two fields follow the link number (Link-No) field for storing the link number of the link. One field, called number of branches (No-Branches), stores the number branches of the tree from the next hop node. The other field, called size of branches+ (S-Branches+), stores the size of branches of the tree from the next hop node and the fields following. The size is in bits, bytes, or other units. For example, for the link from PEI to Pl on the tree, No-Branches field has a value of 2 since there are two branches from Pl; and S-Branches+ field has a value of 14 (bytes) since 14 bytes are used for storing/encoding the two branches from Pl when Link-No, No-Branches, and S-Branches+ fields occupy two bytes in total.

[00100] For the link from Pl to P2 on the tree, No-Branches field has a value of 2 since there are two branches from P2; and S-Branches+ field has a value of 10 (bytes) since 10 bytes are used for storing/encoding the two branches (i.e., sub-trees) from P2 and the fields following.

[00101] For the link from Pl to P3 on the tree, No-Branches field has a value of 1 since there is one branch (i.e., one sub-tree) from P3; and S-Branches+ field has a value of 6 (bytes) since 6 bytes are used for storing/encoding the branch from P3 and there are no other fields following.

[0100] For the link from P2 to egress PE2 on the tree, Link-No field has a value of 1 since the link number is 1 for the link on P2; No-Branches field has a value of 0 since there is no branch (i.e., no sub-tree) from PE2; and S-Branches+ field has a value of 0 (bytes).

[0101] Encoding of P2MP Path/Tree (L flag).

[0102] FIG. 4B shows an example embodiment of encoding the P2MP path/tree in the example of FIG. 1 from PEI via Pl to PE2, PE3, PE4, and PE5 using an L flag. The L flag added for a link indicates whether the next hop is a leaf node. When the L flag is set to one indicating the next hop is a leaf node (i.e., egress node), the “No-Branches” and “S-Branches+” fields are removed. There are four links to leaves (i.e., egress nodes) on the tree, which are link from P2 to PE2, link from P2 to PE3, link from P4 to PE4, and link from P4 to PE5. These four links have their L flags set to one. The No-Branches and S-Branches+ fields for these four links are removed from the encoding of the tree. This reduces the space/memory for encoding the tree.

[0103] For example, suppose that the L flag and Link-No (with possible padding, not shown) occupy 1 byte, and that the L flag, Link-No, No-Branches, and S-Branches+ occupy 2 bytes. In this case, the S-Branches+ field for link from PEI to Pl is 10 (bytes), which is the size of the fields for 7 links (i.e., link from Pl to P2, link from Pl to P3, link from P2 to PE2, . . ., link from P4 to PE5) encoding the sub-trees from Pl to PE2, PE3, PE4, and PE5. The S-Branches+ field for the link from Pl to P2 is 6 (bytes), which is the size of the fields for 5 links (i.e., link from P2 to PE2, link from P2 to PE3, link from P3 to P4, link from P4 to PE4, link from P4 to PE5) encoding the sub-trees from Pl to PE2 and PE3, and the fields following them.

[0104] Encoding the tree without L flag occupies 16 bytes in total as illustrated in FIG. 4A.

[0105] Encoding the tree with L flag occupies 12 bytes in total as illustrated in FIG. 4B. 4 bytes (or say 25% of space/memory) are saved/reduced. On average, encoding a link or node on the tree consumes 1.5 bytes when L flag is used.

[0106] Encoding of P2MP Path/Tree (E flag).

[0107] For supporting a large number of links attached to a node, an E flag is added into the Link-No field for a link. In an embodiment, the Link-No field comprises an E flag of one bit and a basic field when E is zero, where the basic field occupies a first number of bits such as 4 bits and indicates the link number such as link number 1. FIG. 5 A shows an example of a Link-No field with E = 0, representing link number 3. When a link number is too big to be represented by the basic field, the E flag is set to one and the Link-No field for a link comprises both the basic field and an extended field, where the extended field occupies a second number of bits such as 8 bits. These two fields combined such as 12 bits (combining 4 bits in the basic field with 8 bits in the extended field) indicate the link number. FIG. 5B shows an example of a Link-No field with E = 1, representing link number 4088 by the basic field and extended field combined.

[0108] In another embodiment, the Link-No field for a link comprises an E flag of one bit and a basic field when E is zero, where the basic field occupies a first number of bits such as 4 bits and indicates the link number such as link number 9.

[0109] When a link number is too big to be represented by the basic field, the E flag is set to one and the Link-No field for a link comprises the basic field and a first extended field, where the extended field comprises an E flag of one bit set to zero and a first extended link field with a second number of bits such as 7 bits. These two fields combined such as 11 bits (combining 4 bits in the basic field with 7 bits in the extended link field) indicate the link number. FIG. 5C shows an example of a Link-No field with one extended field, representing link number 1023 by the basic field and the extended field combined.

[0110] When a link number is too big to be represented by the two fields, the E flag in the first extended field is set to one and the Link-No field for a link comprises the basic field, the first extended field and a second extended field, where the second extended field comprises an E flag of one bit set to zero and a second extended link field with a third number of bits such as 8 bits. These three fields combined such as 19 bits (combining 4 bits in the basic field with 7 bits in the first extended link field and 8 bits in the second extended link field) indicate the link number. FIG. 5D shows an example of a Link-No field with two extended fields, representing link number 65535 by the basic field and the two extended fields combined.

[OHl] Similar to adding the E flag to a Link-No field, the E flag can be added into the NoBranches field and the S-Branches+ field for a link to represent a large number of branches and a large size of branches, respectively.

[0112] FIG. 6A shows an example embodiment of encoding for the P2MP path/tree in FIG. 1 from PEI via Pl to PE2, PE3, PE4, and PE5 using an L flag and an E flag. Suppose that the L flag, the E flag, and the Link-No occupy 6 bits, and that the No-Branches and S-Branches+ occupy 4 bits and 6 bits, respectively. For each link to a transit node in the tree, encoding the link uses 16 bits, which is 2 bytes. For each link to a leaf (i.e., egress) node, encoding the link uses 8 bits (including Pad of 2 bits for simplicity), which is 1 byte.

[0113] In this case, the S-Branches+ field for link from PEI to Pl is 10 (bytes), which is the size of the fields encoding the 7 links (i.e., link from Pl to P2, link from Pl to P3, link from P2 to PE2, link from P2 to PE3, link from P3 to P4, link from P4 to PE3, link from P4 to PE5) in the sub-trees from Pl towards PE2 to PE5.

[0114] The S-Branches+ field for the link from Pl to P2 is 6 (bytes), which is the size of the fields encoding the 5 links in the sub-trees from P2 and the links following them. The size of the fields encoding the 2 links (i.e., link from P2 to PE2, link from P2 to PE3) in the sub-trees from P2 is 2 bytes. The size of the fields encoding the links following these two links is 4 bytes.

[0115] The S-Branches+ field for the link from Pl to P3 is 4 (bytes), which is the size of the fields encoding the 3 links in the sub-tree from P3 and the links following them. The size of the fields encoding the 3 links (i.e., link from P3 to P4, link from P4 to PE4, link from P4 to PE5) in the sub-tree from P3 is 4 bytes. There is no link following these three links.

[0116] Assume, for example, that the link number of the link from P4 to leaf (i.e., egress) PE4 is 1023, which is too big to be represented by 4 bits in the basic field of the Link-No field. 1023 is represented by 4 bits in the basic field with value of 7 (111 in binary) and 7 bits in the first extended link field with value of 127 (1111111 in binary). The representation with the L flag and the E flag both equal to one for the link from P4 to PE4 uses 2 bytes. The encoding of the links in the tree from PEI via Pl towards PE2 to PE5 is shown in FIG. 6B.

[0117] In this case, the S-Branches+ field for the link from PEI to Pl is 11 (bytes), which is the size of the fields encoding the 7 links (i.e., link from Pl to P2, link from Pl to P3, link from P2 to PE2, link from P2 to PE3, link from P3 to P4, link from P4 to PE3, link from P4 to PE5) in the sub-trees from Pl towards PE2 to PE5.

[0118] The S-Branches+ field for link from Pl to P2 is 7 (bytes), which is the size of the fields encoding the links in the sub-trees from P2 and the links following them. The size of the fields encoding the 2 links (i.e., link from P2 to PE2, link from P2 to PE3) in the sub-trees from P2 is 2 bytes. The size of the fields encoding the links following these two links is 5 bytes.

[0119] The S-Branches+ field for link from Pl to P3 is 5 (bytes), which is the size of the fields encoding the links in the sub-tree from P3 and the links following them. The size of the fields encoding the 3 links (i.e., link from P3 to P4, link from P4 to PE4, link from P4 to PE5) in the subtree from P3 is 5 bytes. There is no link following these three links.

[0120] The S-Branches+ field for the link from P3 to P4 is 3 (bytes), which is the size of the fields encoding the 2 links in the sub-trees from P4 and the links following them. The size of the fields encoding the 2 links (i.e., link from P4 to PE4, link from P4 to PE5) in the sub-trees from P4 is 3 bytes. There is no link following these links.

[0121] Multicast Routing Header (MRH) (L2.5)

[0122] FIG. 7 shows an embodiment of a Multicast Routing Header (MRH) between layer two and layer three. This MRH is called layer two and half (L2.5) MRH.

[0123] The layer two includes a destination address and source address of layer two such as destination MAC address and source MAC address. The layer two addresses need to be from a special range. In an embodiment, MAC addresses from 01-00-5E 80-00-00 to 01-00-5E 8F-FF-FF are used. In this case, the Type field must have a value that is different from the ones used such as 0x8847 and 0x8848 used for multi-protocol label switching (MPLS) since this address range is also used by MPLS. In another embodiment, MAC addresses from unused MAC multicast address ranges such as 01-00-5E A0-00-00 to 01-00-5E AF-FF-FF are used. In a third embodiment, MAC addresses are normal MAC addresses and the Type field is a value that is different from every value which is used.

[0124] The layer three includes an IP multicast packet.

[0125] The MRH comprises a Type field with a value indicating that the packet is multicast packet encapsulated in this special MRH, a header length (HL) field with a value indicating the length of the MRH excluding the Type field and HL field, and a sub-tree field which is an encoding of a sub-tree.

[0126] In a first embodiment, the encoding of a sub-tree uses link numbers as illustrated in FIG. 4A.

[0127] In a second embodiment, the encoding of a sub-tree uses link numbers and the L flag as illustrated in FIG. 4B.

[0128] In a third embodiment, the encoding of a sub-tree uses link numbers, the L flag, and the E flag as illustrated in FIG. 6 A and FIG. 6B.

[0129] The MRH with the encoding of a sub-tree using link numbers is referred to as a link MRH or MRH-Lk.

[0130] In an embodiment, the P2MP path/tree from PEI via Pl to PE2, PE3, PE4, and PE5 in FIG. 1 is encoded by each of the links on the tree as illustrated in FIG. 4A. The link from ingress PEI to Pl is encoded by the link number of the link on PEI, the number of branches from Pl on the tree, and the size of the branches+ from Pl, which are 2, 2, and 14, respectively. That is, the link number on PEI is 2, the number of branches from Pl is 2, and the size of the branches+ from Pl is 14 bytes.

[0131] For an IP multicast packet to be transmitted by the P2MP path/tree, PEI constructs a layer 2 packet for each sub-tree and sends the layer 2 packet containing a MRH and the IP multicast packet to the next hop along the sub-tree. The P2MP path/tree has one sub-tree from PEI via Pl to PE2, PE3, PE4, and PE5. PEI finds Pl’s MAC address from PEl’s neighbor MAC address table using the link number 2 and sets DA (destination address) of the layer 2 packet to Pl’s MAC and SA (source address) of the layer 2 packet to PEl’s MAC. PEI builds the MRH based on the encoding of the tree in FIG. 4 A through including the number of branches from Pl and the links on the sub-tree from Pl and setting HL to the size of space for storing these (i.e., 1 plus 14, assume that 1 (byte) for storing the number of branches from Pl, wherein 14 is the size of branches+ from Pl). FIG. 8A shows the layer 2 packet to be sent to Pl, which is received by Pl.

[0132] The number of branches from Pl is 2, which is on the top of the MRH.

[0133] There are 2 links from Pl, a first link from Pl to P2 and a second link from Pl to P3. The link number of the first link from Pl to P2 is 2 on Pl. The number of branches from P2 is 2. The size of branches from P2 and the ones following them is 10. The link number of the second link from Pl to P3 is 3 on Pl. The number of branches from P3 is 1. The size of branches from P3 is 6. When the size of branches+ from a node equals to the size of branches from the node, the size of branches+ is also simply called the size of branches.

[0134] 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.

[0135] The link number of the link from P3 to P4 is 2 on P3. The number of branches from P4 is 2. The size of branches from P4 is 4.

[0136] The link number of the link from P4 to PE4 is 3 on P4. The link number of the link from P4 to PE5 is 2 on P4.

[0137] The number of branches from each of leaves/egresses such as PE2, PE3, PE4, and PE5 is zero. The size of branches from each leaf/egress is zero.

[0138] After receiving the layer 2 packet from PEI, Pl determines whether the packet contains the special MRH through checking the Type following the SA (source address) and/or the range of the DA (destination address) and/or SA in the packet. When the packet contains the special MRH, Pl duplicates the layer 2 packet for each branch/sub-tree from Pl and sends the layer 2 packet copy with an updated MRH to the next hop along the branch/sub-tree.

[0139] There are 2 branches from Pl according to the top of the MRH in the layer 2 packet received by Pl. The first branch/sub-tree is from the link from Pl to P2 towards PE2 and PE3. The second branch/sub-tree is from the link from Pl to P3 towards PE4 and PE5.

[0140] Pl duplicates the layer 2 packet for the first branch/sub-tree, finds P2’s MAC address from Pl’s neighbor MAC address table using the link number 2 of the link from Pl to P2 and sets DA (destination address) of the layer 2 packet to P2’s MAC and SA (source address) of the layer 2 packet to Pl’s MAC. Pl updates the MRH based on the encoding of the sub-tree in FIG. 8 A through including the number of branches from P2 and the links on the branches/ sub-trees from P2 and setting HL to the size of space for storing these (i.e., 1 plus 4, assume that 1 (byte) for storing the number of branches from P2, 4 is the size of branches from P2. The size of branches from P2 is the value in the S-Branches+ field for the link from Pl to P2 minus the value in the S-Branches+ field for the link from Pl to P3, i.e., 10 - 6 = 4.). FIG. 8B shows the layer 2 packet to be sent to P2, which is received by P2.

[0141] The number of branches from P2 is 2, which is on the top of the MRH.

[0142] There are 2 links from P2, a first link from P2 to PE2 and a second link from P2 to PE3. The link number of the first link from P2 to PE2 is 1 on P2. The number of branches from PE2 is zero. The size of branches from PE2 is zero. The link number of the second link from P2 to PE3 is 2 on P2. The number of branches from PE3 is zero. The size of branches from PE3 is zero.

[0143] After receiving the layer 2 packet from Pl, P2 determines whether the packet contains the special MRH. When the packet contains the special MRH, P2 duplicates the IP multicast packet for each leaf/egress from P2 and sends the packet copy to the leaf/egress. P2 sends one IP multicast packet copy to leaf/egress PE2 and another copy to leaf/egress PE3. In an embodiment, P2 sends the copy with MRH containing HL=0 to PE2 and PE3. In another embodiment, P2 sends the copy without MRH to PE2 and PE3.

[0144] Pl duplicates the layer 2 packet for the second branch/sub-tree, finds P3’s MAC address from Pl’s neighbor MAC address table using the link number 3 of the link from Pl to P3 and sets DA of the layer 2 packet to P3’s MAC and SA of the layer 2 packet to Pl’s MAC. Pl updates the MRH based on the encoding of the sub-tree in FIG. 8A through including the number of branches from P3 and the links on the branch/sub-tree from P3 and setting HL to the size of space for storing these (i.e., 1 plus 6, assume that 1 (byte) for storing the number of branches from P3, 6 is the size of branch from P3). FIG. 8C shows the layer 2 packet to be sent to P3, which is received by P3.

[0145] The number of branches from P3 is 1, which is on the top of the MRH.

[0146] There is one link from P3, the link from P3 to P4. The link number of the link from P3 to P4 is 2 on P3. The number of branches from P4 is 2. The size of branches from P4 and the ones following them is 4.

[0147] The link number of the link from P4 to PE4 is 3 on P4. The link number of the link from P4 to PE5 is 2 on P4. [0148] The number of branches from each of leaves/egresses such as PE4 and PE5 is zero. The size of branches from each leaf/egress such as PE4 and PE5 is zero.

[0149] After receiving the layer 2 packet from Pl, P3 determines whether the packet contains the special MRH. When the packet contains the special MRH, P3 sends a layer 2 packet copy for the branch from P3 to P4.

[0150] Before sending the packet, P3 finds P4’s MAC address from P3’s neighbor MAC address table using the link number 2 of the link from P3 to P4 and sets DA of the layer 2 packet to P4’s MAC and SA of the layer 2 packet to P3’s MAC. P3 updates the MRH based on the encoding of the sub-tree in FIG. 8C through including the number of branches from P4 and the links on the branches/sub-trees from P4 and setting HL to the size of space for storing these (i.e., 1 plus 4, assume that 1 (byte) for storing the number of branches from P4, where 4 is the size of branches from P4). FIG. 8D shows the layer 2 packet to be sent to P4, which is received by P4.

[0151] The number of branches from P4 is 2, which is on the top of the MRH.

[0152] There are 2 links from P4, a first link from P4 to PE4 and a second link from P4 to PE5. The link number of the first link from P4 to PE4 is 3 on P4. The number of branches from PE4 is zero. The size of branches from PE4 is zero. The link number of the second link from P4 to PE5 is 2 on P4. The number of branches from PE5 is zero. The size of branches from PE5 is zero.

[0153] After receiving the layer 2 packet from P3, P4 determines whether the packet contains the special MRH. When the packet contains the special MRH, P4 duplicates the IP multicast packet for each leaf/egress from P3 and sends the packet copy to the leaf/egress PE4 and PE5. P4 sends one IP multicast packet copy to leaf/egress PE4 and another copy to leaf/egress PE5. In an embodiment, P4 sends the copy with MRH containing HL=0 to PE4 and PE5. FIG. 8E shows the layer 2 packet with HL=0 received by PE5. In another embodiment, P4 sends the copy without MRH to PE4 and PE5. FIG. 8F shows the layer 2 packet without MRH received by PE5.

[0154] When a leaf/egress such as PE5 receives a layer 2 packet without MRH or with MRH having HL=0, the leaf/egress sends the IP multicast packet to the multicast layer of the leaf/egress.

[0155] In an embodiment, after a node duplicates the layer 2 packet for a branch/sub-tree from the node, the node updates the MRH in the packet through including the number of branches from a next hop node of the node along the branch/sub-tree and the links on the branches/sub-trees from the node and the links following them and setting HL to the size of space for storing these. [0156] For example, after Pl duplicates the layer 2 packet for the branch/sub-tree from Pl to P2 towards PE2 and PE3, Pl updates the MRH in the packet based on the sub-tree in FIG. 8 A. In this example, Pl updates the number of branches from P2, which is 2, updates the links on the branch/sub-tree from Pl to P2 towards PE2 and PE3, which are the link from P2 to PE2 and the link from P2 to PE3, updates the links following them, which are the links from P3 to P4, P4 to PE4 and P4 to PE5. HL is set to the size of space for storing these, which is 11 (i.e., 1 plus the value 10 in the S-Branches+ field for the link from Pl to P2 in FIG. 8 A, where 1 (byte) is the space for storing the number of branches from P2). FIG. 9 A shows the layer 2 packet to be sent to P2, which is received by P2.

[0157] Multicast Routing Header (MRH) (L3).

[0158] FIG. 10A shows an embodiment of a Multicast Routing Header (MRH) in a layer three IPv6 packet. This MRH is layer 3 (L3 for short) MRH. The IPv6 packet comprises an IPv6 header with a destination address (DA) and source address (SA) of IPv6, a routing header with a routing type field (TBD) for the routing type (to be assigned by Internet Assigned Numbers Authority, IANA), indicating MRH, and an IP multicast datagram. The routing header is indicated by the Next Header in the IPv6 header.

[0159] FIG. 10B shows the format of the MRH. The MRH comprises an 8-bit Next Header field with a value indicating the IP multicast datagram header in the packet, an 8-bit Hdr Ext Len field with a value indicating the length of the MRH in a unit of 64 bits (i.e., 8 bytes) excluding the first 8 bytes, an 8-bit routing type (TBD) field with a value (from IANA) indicating that the routing header is a Multicast Routing Header (MRH), an 8-bit Segments Left field with a value indicating the size of the sub-tree remaining, and a sub-tree field, which is an encoding of a multicast subtree.

[0160] In a first embodiment, the encoding of a sub-tree uses link numbers as illustrated in FIG. 4A.

[0161] In a second embodiment, the encoding of a sub-tree uses link numbers and L flag as illustrated in FIG. 4B.

[0162] In a third embodiment, the encoding of a sub-tree uses link numbers and L flag and E flag as illustrated in FIG. 6 A and FIG. 6B.

[0163] The MRH with the encoding of a sub-tree using link numbers is referred to as a link

MRH or MRH-Lk. [0164] In an embodiment, the P2MP path/tree from PEI via Pl to PE2, PE3, PE4, and PE5 in FIG. 1 is encoded by each of the links on the tree as illustrated in FIG. 6A. The link from ingress PEI to Pl is encoded by the link number of the link on PEI, the number of branches from Pl on the tree, and the size of the branches from Pl, which are 2, 2, and 10, respectively. That is, the link number on PEI is 2, the number of branches from Pl is 2, and the size of the branches from Pl is 10 bytes.

[0165] For an IP multicast datagram/packet to be transmitted by the P2MP path/tree, PEI encapsulates the datagram in a layer 3 IPv6 packet for each sub-tree and sends the packet containing a MRH and the IP multicast datagram to the next hop along the sub-tree.

[0166] The tree has one sub-tree from PEI via Pl to PE2, PE3, PE4, and PE5. PEI finds Pl’s IPv6 address from PEl’s neighbor IPv6 address table using the link number 2 and sets DA of the packet to Pl’s IPv6 address and SA of the packet to PEl’s IPv6 address. PEI builds the MRH based on the encoding of the tree in FIG. 6 A by including the number of branches from Pl and the links on the sub-tree from Pl and setting segments left (SL) to the size of space for storing the link from PEI to Pl and the links following, which is 12 bytes. FIG. 11 A shows the layer 3 packet to be sent to Pl, which is received by Pl. Note that some details are not shown.

[0167] The number of branches from Pl is 2. The size of branches from Pl is 10 (bytes). These are the information about the link from PEI to Pl. The link number of the link will not be used by Pl.

[0168] There are 2 links from Pl, a first link from Pl to P2 and a second link from Pl to P3. The link number of the first link from Pl to P2 is 2 on Pl. The number of branches from P2 is 2. The size of branches from P2 and the ones following them is 6. The link number of the second link from Pl to P3 is 3 on Pl. The number of branches from P3 is 1. The size of branches from P3 is 4.

[0169] 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).

[0170] The link number of the link from P3 to P4 is 2 on P3. The number of branches from P4 is 2. The size of branches from P4 is 2.

[0171] The link number of the link from P4 to PE4 is 3 on P4. The link number of the link from P4 to PE5 is 2 on P4. PE4 and PE5 are leaves.

[0172] After receiving the layer 3 packet from PEI, Pl determines whether the packet’s next header is a MRH by checking whether the next header is routing header and routing type in the routing header is TBD for MRH. When the next header is the MRH, Pl duplicates the packet for each branch/sub-tree from Pl and sends the packet copy with an updated MRH to the next hop along the branch. There are 2 branches from Pl according to the sub-tree remaining in the MRH in the packet received by Pl. The first branch/sub-tree is from the link from Pl to P2 towards PE2 and PE3. The second branch/sub-tree is from the link from Pl to P3 towards PE4 and PE5.

[0173] Pl duplicates the packet for the first branch/sub-tree, finds P2’s IPv6 address from Pl’s neighbor IPv6 address table using the link number 2 of the link from Pl to P2 and sets DA of the packet to P2’s IPv6 address. Pl updates the MRH based on the encoding of the sub-tree in FIG. 11 A by including the number of branches from P2 and the links on the branches/sub-trees from P2 and setting SL to the size of space for storing the link from Pl to P2 and the links following, which is 10 bytes. This is the size of the branches+ from Pl. FIG. 1 IB shows the packet to be sent to P2, which is received by P2.

[0174] The number of branches from P2 is 2. The size of branches+ from P2 is 6 (bytes). The link number of the link will not be used by P2.

[0175] 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.

[0176] The other links such as the link from Pl to P3 and the link from P3 to P4 in the MRH are not used by P2.

[0177] Pl duplicates the packet for the second branch/sub-tree, finds P3’s IPv6 address from Pl’s neighbor IPv6 address table using the link number 3 of the link from Pl to P3, and sets DA of the packet to P3’s IPv6 address. Pl updates the MRH based on the encoding of the sub-tree in FIG. 11 A through including the link from Pl to P3 and the links following and setting SL to the size of space for storing the link from Pl to P3 and the links following, which is 8 bytes. This is the size of the branches+ from Pl (i.e., 10) minus the size of the space to store the link from Pl to P2 (i.e., 2). FIG. 11C shows the packet to be sent to P3, which is received by P3.

[0178] The number of branches from P3 is 1. The size of branches from P3 is 4 (bytes). The link number of the link will not be used by P3.

[0179] The link number of the link from P3 to P4 is 2 on P3. The number of branches from P4 is 2. The size of branches from P4 is 2 (bytes).

[0180] The link number of the link from P4 to PE4 is 3 on P4. PE4 is a leaf (i.e., egress), which is indicated by L = 1. [0181] The link number of the link from P4 to PE5 is 2 on P4. PE5 is a leaf (i.e., egress), which is indicated by L = 1.

[0182] The other links such as the link from P2 to PE2 and the link from P2 to PE3 in the MRH are not used by P3.

[0183] After receiving the layer 3 packet from Pl, P2 determines whether the packet’s next header is a MRH. When the packet’s next header is the MRH, P2 duplicates the packet for each branch/sub-tree from P2 and sends the packet copy with an updated MRH to the next hop along the branch. There are 2 branches from P2 according to the sub-tree remaining in the MRH in the packet received by P2. The first branch/sub-tree is from the link from P2 to PE2. The second branch/sub-tree is from the link from P2 to PE3.

[0184] P2 duplicates the packet for the first branch, finds PE2’s IPv6 address from P2’s neighbor IPv6 address table using the link number 1 of the link from P2 to PE2, and sets the DA of the packet to PE2’s IPv6 address. P2 updates the MRH based on the encoding of the sub-tree in FIG. 11B through including the link from P2 to PE2 and the links following and setting SL to the size of space for storing these links, which is 6 (bytes). This is the size of the branches+ from P2. FIG. 1 ID shows the packet to be sent to PE2, which is received by PE2.

[0185] L = 1 in the top indicates that PE2 is a leaf (i.e., egress).

[0186] After receiving the layer 3 packet from P2, PE2 determines whether the packet’s next header is a MRH. When the packet’s next header is the MRH, PE2 checks whether PE2 itself is a leaf (i.e., egress) through checking whether L is 1. When PE2 is a leaf, PE2 decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module.

[0187] In another embodiment, after receiving the layer 3 packet from Pl and determining that the packet’s next header is a MRH, P2 checks whether each of its next hops is a leaf. When the next hop is a leaf, P2 decapsulates the packet and sends the IP multicast datagram to the next hop.

[0188] Since two next hops PE2 and PE3 are leaves, P2 sends the IP multicast datagram to PE2 and PE3.

[0189] P2 duplicates the packet for the second branch, finds PE3’s IPv6 address from P2’s neighbor IPv6 address table using the link number 2 of the link from P2 to PE3, and sets DA of the packet to PE3’s IPv6 address. P2 updates the MRH based on the encoding of the sub-tree in FIG.

1 IB through including the link from P2 to PE3 and the links following it and setting SL to the size of space for storing these links, which is 5 (bytes). This is the size of the branches+ from P2 minus the size of the space to store the first link (i.e., the link from P2 to PE2). FIG. 1 IE shows the packet to be sent to PE3, which is received by PE3.

[0190] L = 1 in the top indicates that PE3 is a leaf (i.e., egress).

[0191] After receiving the layer 3 packet from P2, PE3 determines whether the packet’s next header is a MRH. When the packet’s next header is the MRH, PE3 checks whether PE3 itself is a leaf (i.e., egress) through checking whether L is 1. When PE3 is a leaf, PE3 decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module.

[0192] After receiving the layer 3 packet from Pl, 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 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 (refer to FIG. 11C). The branch/sub-tree is from the link from P3 to P4 towards PE4 and PE5.

[0193] 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 FIG. 11C through including the link from P3 to P4 and the links following and setting SL to the size of space for storing these links. SL is set to 4 (bytes), which is the size of the branches from P3.

[0194] FIG. 1 IF shows the packet to be sent to P4, which is received by P4.

[0195] The number of branches from P4 is 2. The size of branches from P4 is 2 (bytes). The link number of the link will not be used.

[0196] The link number of the link from P4 to PE4 is 3 on P4. PE4 is a leaf (i.e., egress), which is indicated by L = 1.

[0197] The link number of the link from P4 to PE5 is 2 on P4. PE5 is a leaf (i.e., egress), which is indicated by L = 1.

[0198] Procedure/Behavior on Ingress Node.

[0199] 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. [0200] For example, there is one sub-tree branching from the ingress of the P2MP path/tree in FIG. 1. The sub-tree is from ingress PEI via next hop node Pl towards PE2 to PE5.

[0201] In a first embodiment, the contents of the MRH shown in FIG. 8A are used in layer 2. In a second embodiment, the contents of the MRH shown in Figure 11 A is used in layer 3.

[0202] In the first embodiment, ingress PEI sends Pl the packet as illustrated in FIG. 8 A.

[0203] In the second embodiment, ingress PEI sends Pl the packet as shown in FIG. 11 A.

[0204] Procedure/Behavior on a Transit Node.

[0205] When a transit node of a P2MP path receives a packet transported by the P2MP path, the packet is encapsulated in a MRH. The MRH contains the encoding/representation of the sub- trees/branches from the node. In an embodiment, the MRH is a L2.5 MRH such as the MRH shown in FIG. 8A. In another embodiment, the MRH is a L3 MRH such as the MRH shown in FIG. 11 A.

[0206] The Procedure/Behavior on a Transit Node for each of two types of MRHs (i.e., L2.5 MRH and L3 MRH) is described.

[0207] When a transit node of a P2MP path receives a packet transported by the P2MP path, the packet is encapsulated in a MRH. The node determines whether the MRH is a L3 MRH. After determining that the MRH is a L3 MRH, the node executes the procedure to duplicate the packet for each of the downstream links of the node on the P2MP path and send the packet copy to next hop (i.e., downstream node) of the link.

[0208] Suppose for example, that the transit node receives the packet from an upstream link from an upstream node to the transit node and there are n downstream links from the transit node on the P2MP path (i.e., there are n branches/sub-trees from the transit node on the P2MP path, wherein n is greater than zero).

[0209] The information about the upstream link is on the top of the L3 MRH, which includes the number of branches in the No-Branches field from the transit node and the size of the branches+ in the S-Branches+ field for the link. The information about n downstream links follows the information about the upstream link.

[0210] For example, when node Pl receives the packet transported by the P2MP path in FIG. 1 from ingress PEI, the L3 MRH is illustrated in FIG. 11 A. On the top of the L3 MRH is the information about the link from PEI to Pl, which includes No-Branches = 2 and S-Branches+ = 10. No-Branches = 2 indicates that there are two branches from Pl. S-Branches+ = 10 indicates that the size of the space/memory for storing the information about the links on the branches/sub- trees from Pl is 10 bytes. The information about 2 downstream links (i.e., link from Pl to P2 and link from Pl to P3) follows the information about the link from PEI to Pl .

[0211] The top of the L3 MRH (i.e., the root (information) of the sub-trees) is indicated by SL. For example, when Pl receives the packet transported by the P2MP path in FIG. 1 from PEI, the L3 MRH is illustrated in FIG. 11 A. SL in the MRH is 12 (bytes), which acts as a pointer pointing to the root (information) of the sub-trees from Pl. The root (information) is the information about the link from PEI to Pl.

[0212] For each of the downstream links of the transit node, the transit node duplicates the packet for the link, sets SL in the packet copy to a value as a pointer pointing to the information about the link, 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.

[0213] For the first downstream link, SL is set to the value of the S-Branches+ field for the upstream link. For the second downstream link, SL is set to the value of the S-Branches+ field for the upstream link minus the size of the space/memory for storing the information for the first downstream link. For the i-th downstream link, SL is set to the value of the S-Branches+ field for the upstream link minus the size of the space/memory for storing the information for the downstream links before the i-th link.

[0214] For example, for the first downstream link from Pl (i.e., link from Pl to P2), Pl duplicates the packet for the link, sets SL to 10 (which is the value of the S-Branches+ field for the upstream link, i.e., link from PEI to Pl), 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 FIG. 1 IB.

[0215] For the second downstream link from Pl (i.e., link from Pl to P3), Pl duplicates the packet for the link, sets SL to 8 (which is 10 minus 2, wherein 2 is the size of the space/memory for storing the information for the first link, i.e., link from Pl to P2), sets the DA of the packet copy to the P3’s IPv6 address, and sends the packet copy to P3. The packet copy sent by Pl and received by P3 is illustrated in FIG. 11C.

[0216] When a transit node of a P2MP path receives a packet transported by the P2MP path, the packet is encapsulated in a MRH. The node determines whether the MRH is a L2.5 MRH. After determining that the MRH is a L2.5 MRH, the node executes the procedure to duplicate the packet for each of the downstream links of the node on the P2MP path and sends the packet copy to the next hop (i.e., downstream node) of the link.

[0217] Suppose for example, that the transit node receives the packet from an upstream link from an upstream node to the transit node and there are n downstream links from the transit node on the P2MP path (i.e., there are n branches/sub-trees from the transit node on the P2MP path, wherein n is greater than zero).

[0218] The number of branches/sub-trees from the transit node is on the top of the L2.5 MRH, which is the value in the No-Branches field for the upstream link (i.e., the link from the upstream node to the transit node). The information about n downstream links follows the information about the number of branches/sub-trees.

[0219] For example, when node Pl receives the packet transported by the P2MP path in FIG. 1 from ingress PEI, the L2.5 MRH is illustrated in FIG. 8 A. On the top of the L2.5 MRH is the number of branches/sub-trees from Pl, which is 2, indicating that there are two branches from Pl. The information about 2 downstream links (i.e., link from Pl to P2 and link from Pl to P3) follows the information about the number of branches/sub-trees from Pl.

[0220] The top of the L2.5 MRH (i.e., the root (information) of the sub-trees) is indicated by HL. For example, when Pl receives the packet transported by the P2MP path in FIG. 1 from PEI, the L2.5 MRH is illustrated in FIG. 8A. HL in the L2.5 MRH is 15 (bytes), which acts as a pointer pointing to the root (information) of the sub-trees from PL The root (information) is the information about the number of branches/sub-trees from PL

[0221] For each of the downstream links of the transit node, the transit node duplicates the packet for the link, sets HL in the packet copy to the size of the space/memory for storing the subtrees from the next hop of the link, makes the L2.5 MRH contain the information about the subtrees from the next hop (i.e., the number of branches/sub-trees from the next hop and the information about the links on the sub-trees), finds the MAC address of the next hop (i.e., the downstream node) of the link from the neighbor MAC address table of the transit node using the link number of the link, sets the DA of the packet copy to the MAC address of the next hop, sets the SA of the packet copy to the MAC address of the transit node, and sends the packet copy to the next hop of the link. [0222] For the first downstream link, HL is set to the value of the S-Branches+ field for the first downstream link minus the value of the S-Branches+ field for the second downstream link plus the size of the space/memory for storing the number of branches from the next hop (i.e., the downstream node) of the first downstream link. The information about the links on the sub-trees from the next hop is in the area indicated by the value of the S-Branches+ field for the first downstream link as a starting point and the value of the S-Branches+ field for the second downstream link plus 1 as an ending point.

[0223] For the i-th downstream link (i < n), HL is set to the value of the S-Branches+ field for the i-th downstream link minus the value of the S-Branches+ field for the (i+ 1 )-th downstream link plus the size of the space/memory for storing the number of branches from the next hop (i.e., the downstream node) of the i-th downstream link. The information about the links on the sub-trees from the next hop is in the area indicated by the value of the S-Branches+ field for the i-th downstream link as a starting point and the value of the S-Branches+ field for the (i+l)-th downstream link plus 1 as an ending point.

[0224] For the i-th downstream link (i = n), HL is set to the value of the S-Branches+ field for the i-th downstream link plus the size of the space/memory for storing the number of branches from the next hop (i.e., the downstream node) of the i-th downstream link. The information about the links on the sub-trees from the next hop is in the area indicated by the value of the S-Branches+ field for the i-th downstream link as a starting point and 1 as an ending point.

[0225] For example, for the first downstream link from Pl (i.e., link from Pl to P2), Pl duplicates the packet for the link, sets HL to 5 (which is the value 10 of the S-Branches+ field for the link from Pl to P2 minus the value 6 of the S-Branches+ field for the link from Pl to P3, plus 1, where 1 (byte) is the size of the space/memory for storing the number of branches from P2). The information about the links on the sub-trees/branches from next hop P2 is in the area from 10 to 7 (i.e., from byte 10 to byte 7 = 6 + 1, where byte is counted from bottom). Pl makes the L2.5 MRH to contain the number of branches from P2 in 1 byte and the information about the links on the sub-trees/branches from P2 in 4 bytes. Pl sets the DA of the packet copy to the P2’s MAC address, sets the SA of the packet copy to the Pl’s MAC address, and sends the packet copy to P2. The packet copy received by P2 is shown in FIG. 8B.

[0226] For the second downstream link from Pl (i.e., link from Pl to P3), Pl duplicates the packet for the link, sets HL to 7 (which is the value 6 of the S-Branches+ field for the link from Pl to P3 plus 1, where 1 (byte) is the size of the space/memory for storing the number of branches from P3). The information about the links on the sub-trees/branches from next hop P3 is in the area from 6 (to 1). Pl makes the L2.5 MRH to contain the number of branches from P3 in 1 byte and the information about the links on the sub-trees/branches from P3 in 6 bytes. Pl sets the DA of the packet copy to the P3’s MAC address, sets the SA of the packet copy to the Pl’s MAC address, and sends the packet copy to P3. The packet copy received by P3 is illustrated in FIG. 8C.

[0227] Procedure/Behavior on Egress Node.

[0228] When an egress node of a P2MP path receives a packet transported by the P2MP path, the DA of the packet is the address of the egress node and there is an indication in the MRH for the leaf/egress.

[0229] In a first embodiment, the DA of the packet is the MAC address of the egress node and the MRH is a L2.5 MRH. The L2.5 MRH has HL = 0. In this case, the egress node decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module.

[0230] For example, after receiving the layer 2 packet from P2, PE3 determines whether there is a L2.5 MRH with HL = 0. If so, PE3 decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module.

[0231] In a second embodiment, the DA of the packet is the IPv6 address of the egress node and the MRH is a L3 MRH. In one embodiment, the L3 MRH has SL “pointing” to the information about the link to the egress with L flag set to one. In another embodiment, the L3 MRH has SL “pointing” to the information about the link to the egress with both No-Branches and S-Branches+ set to zeros. In these two cases, the egress node proceeds to process the next header in the packet.

[0232] For example, after receiving the layer 3 packet from P2, PE3 determines whether the packet’s next header is a L3 MRH. When the packet’s next header is the L3 MRH, PE3 checks whether PE3 itself is a leaf (i.e., egress) through checking whether L is 1. When PE3 is a leaf, PE3 decapsulates the packet and sends the IP multicast datagram to the IP multicast forwarding module. [0233] Segment Routing Header.

[0234] The Routing header is identified by a Next Header value of 43. It is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. It has the format shown in FIG. 12 A. [0235] Next Header: 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [IANA-PN],

[0236] Hdr Ext Len: 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets.

[0237] Routing Type: 8-bit identifier of a particular Routing header variant.

[0238] Segments Left: 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.

[0239] Type-specific data: Variable-length field, of format determined by the Routing Type, and of length such that the complete Routing header is an integer multiple of 8 octets long.

[0240] The routing header is defined in [RFC8200], The Segment Routing Header (SRH) has a new Routing Type (4) in the routing header [RFC8754], An example of the SRH format is shown in FIG. 12B.

[0241] In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper layer header in a packet. There is a small number of such extension headers, each one identified by a distinct Next Header value.

[0242] Extension headers are numbered from IANA IP Protocol Numbers [IANA-PN], the same values used for IPv4 and IPv6. When processing a sequence of Next Header values in a packet, the first one that is not an extension header [IANA-EH] indicates that the next item in the packet is the corresponding upper-layer header. A special "No Next Header" value is used when there is no upper-layer header.

[0243] As illustrated in the example of FIG. 12C, an IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header.

[0244] Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

[0245] At the destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header when no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones.

[0246] FIG. 13 depicts a method 1300 implemented by an ingress node in the multicast domain along a P2MP path according to an embodiment of the disclosure.

[0247] As shown in block 1310, the ingress node receives a packet from a multicast source.

[0248] In block 1320, the ingress node duplicates the packet for each sub-tree branch branching from the ingress node of the P2MP path.

[0249] In block 1330, the ingress node encapsulates the duplicate packet in a multicast routing header (MRH) for each sub-tree branch of the P2MP path. The MRH includes a link number for each link of the sub-tree branch.

[0250] In block 1340, the ingress node transmits the duplicate packet to a next hop node in the network.

[0251] FIG. 14 illustrates a method 1400 implemented by a transit node in the multicast domain along a P2MP path according to an embodiment of the disclosure.

[0252] In block 1410, the transit node receives a packet that includes a multicast routing header (MRH).

[0253] In block 1420, the transit node duplicates the packet.

[0254] In block 1430, the transit node extracts one or more link numbers of the transit node from the MRH.

[0255] As shown in block 1440, the transit node obtains a next hop address based on the link number.

[0256] In block 1450, the transit node transmits a duplicated packet to a next hop node based on the next hop address.

[0257] FIG. 15 is a schematic diagram of a routing device 1500 according to an embodiment of the disclosure. The routing device 1500 is suitable for implementing the disclosed embodiments as described herein. In an embodiment, the routing device 1500 may be a router, a switch, a node, or another communication device configured to process Internet traffic.

[0258] The routing device 1500 comprises ingress (input) ports 1510 and receiver units (Rx) 1520 for receiving data; a processor, logic unit, or central processing unit (CPU) 1530 to process the data; transmitter units (Tx) 1540 and egress ports 1350 (or output ports 1550) for transmitting the data; and a memory 1560 for storing the data. The routing device 1500 may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports 1510, the receiver units 1520, the transmitter units 1540, and the egress ports 1550 for egress or ingress of optical or electrical signals.

[0259] The processor 1530 is implemented by hardware and software. The processor 1530 may be implemented as one or more central processing unit (CPU) chips, cores (e.g., as a multicore processor), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 1530 is in communication with the ingress ports 1510, receiver units 1520, transmitter units 1540, egress ports 1550, and memory 1560. The processor 1530 comprises a routing module 1570. The routing module 1570 implements the disclosed embodiments described above. For instance, the routing module 1570 implements, processes, prepares, or provides the various coding operations. The inclusion of the routing module 1570 therefore provides a substantial improvement to the functionality of the routing device 1500 and effects a transformation of the routing device 1500 to a different state. Alternatively, the routing module 1570 is implemented as instructions stored in the memory 1560 and executed by the processor 1530.

[0260] The memory 1560 may comprise one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 1560 may be, for example, volatile and/or non-volatile and may be a read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).

[0261] While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0262] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method implemented by an ingress node in a multicast domain along a point-to- multipoint (P2MP) path, comprising: receiving a packet from a multicast source; duplicating the packet for each sub-tree branch branching from the ingress node of the P2MP path; encapsulating a duplicate packet in a multicast routing header (MRH) for each sub-tree branch of the P2MP path, wherein the MRH includes a link number for each link of the sub-tree branch; and transmitting the duplicate packet to a next hop node.

2. The method of claim 1, further comprising assigning link numbers to each link of the domain and saving the link numbers in a neighbor table comprising: the link number; a link type; and a next hop address.

3. The method of claim 2, wherein the next hop address comprises a media access control (MAC) address.

4. The method of claim 2, wherein the next hop address comprises an internet protocol (IP) address.

5. The method of claim 4, wherein the next hop address comprises an internet protocol version 4 (IPv4) address.

6. The method of claim 4, wherein the next hop address comprises an internet protocol version 6 (IPv6) address.

7. The method of any of claims 2-6, wherein the link type comprises at least one of a point-to-point (P2P) link; a multicast loopback (ML) link; or a local area network (LAN) link.

8. The method of any of claims 1-7, wherein encapsulating the packet in the MRH further comprises: assigning a leaf flag bit (L) when the next hop node is a leaf node; and assigning an extended flag bit (E) when a link number is too large to be represented by a basic field.

9. A method implemented by a transit node in a multicast domain along a point-to-multipoint (P2MP) path, comprising: receiving a packet comprising a multicast routing header (MRH); duplicating the packet; extracting one or more link numbers from the MRH; obtaining, based on a link number, a next hop address; and transmitting, based on the next hop address, a duplicated packet to a next hop node.

10. The method of claim 9, wherein obtaining the next hop address further comprises accessing a neighbor table comprising: the link number; a link type; and the next hop address.

11. The method of either of claims 9 or 10, wherein the next hop address comprises either a media access control (MAC) address or an internet protocol (IP) address.

12. The method of either of claims 10 or 11, wherein the link type comprises at least one of: a point-to-point (P2P); a multicast loopback (ML) link; or a local area network (LAN) link.

13. The method of any of claims 9-12, wherein the MRH further comprises: a leaf flag bit (L) when the next hop node is a leaf node; and an extended flag bit (E) when a link number is too large to be represented by a basic field.

14. The method of any of claims 9-13, wherein the transit node comprises a pseudo node.

15. An ingress node in a multicast domain along a point-to-multipoint (P2MP) path, comprising: a memory storing instructions; and a processor coupled to the memory, wherein the processor is configured to execute the instructions to cause the ingress node to: receive a packet from a multicast source; duplicate the packet for each sub-tree branch branching from the ingress node of the P2MP path; encapsulate a duplicate packet in a multicast routing header (MRH) for each subtree branch of the P2MP path, wherein the MRH includes a link number for each link of the sub-tree branch; and transmit the duplicate packet to a next hop node.

16. The ingress node of claim 15, wherein the processor is further configured to cause the ingress node to save the link numbers in a neighbor table comprising: a link number; a link type; and a next hop address.

17. The ingress node of claim 16, wherein the next hop address comprises either a media access control (MAC) address or an internet protocol (IP) address.

18. The ingress node of either of claims 16 or 17, wherein the link type comprises at least one of a point-to-point (P2P) link; a multicast loopback (ML) link; or a local area network (LAN) link.

19. The ingress node of any of claims 15-18, wherein causing the ingress node to encapsulate the packet in an MRH further comprises: assigning a leaf flag bit (L) when the next hop node is a leaf node; and assigning an extended flag bit (E) when a link number is too large to be represented by a basic field.

20. A transit node in a multicast domain along a point-to-multipoint (P2MP) path, comprising: a memory storing instructions; and a processor coupled to the memory, wherein the processor is configured to execute the instructions to cause the transit node to: receive a packet comprising a multicast routing header (MRH); duplicate the packet; extract one or more link numbers from the MRH; obtain, based on a link number, a next hop address; and transmit, based on the next hop address, a duplicated packet to a next hop node.

21. The transit node of claim 20, wherein obtaining the next hop address further comprises accessing a neighbor table comprising: the link number; a link type; and the next hop address.

22. The transit node of either of claims 20 or 21, wherein the next hop address comprises either a media access control (MAC) address or an internet protocol (IP) address.

23. The transit node of either of claims 21 or 22, wherein the link type comprises at least one of a point-to-point (P2P) link; a multicast loopback (ML) link; or a local area network (LAN) link.

24. The transit node of any of claims 20-23, wherein the MRH further comprises: a leaf flag bit (L) when the next hop node is a leaf node; and an extended flag bit (E) when a link number is too large to be represented by a basic field.

25. The transit node of any of claims 20-24, wherein the transit node comprises a pseudo node.

26. An ingress node in a multicast domain along a point-to-multipoint (P2MP) path, comprising means for: receiving a packet from a multicast source; duplicating the packet for each sub-tree branch branching from the ingress node of the P2MP path; encapsulating a duplicate packet in a multicast routing header (MRH) for each sub-tree branch of the P2MP path, wherein the MRH includes a link number for each link of the sub-tree branch; and transmitting the duplicate packet to a next hop node.

27. A transit node in a multicast domain along a point-to-multipoint (P2MP) path, comprising means for: receiving a packet having a multicast routing header (MRH) having link number: duplicating the packet; extracting one or more link numbers from the MRH; obtaining, based on a link number, a next hop address; and transmitting, based on the next hop address, a duplicated packet to a next hop node.