WO2023196689A2

WO2023196689A2 - Optimal stateless best effort multicast

Info

Publication number: WO2023196689A2
Application number: PCT/US2023/027274
Authority: WO
Inventors: Huaimo Chen
Original assignee: Futurewei Technologies, Inc.
Priority date: 2022-07-19
Filing date: 2023-07-10
Publication date: 2023-10-12
Also published as: WO2023196689A3

Abstract

A method for performing stateless multicasting in a network implemented by an ingress node of the network, the method comprising receiving, from a traffic source, a packet; generating a copy of the packet for each subtree of a point to multipoint (P2MP) path branching from the ingress node; adding an encoding of a subtree into a multicast routing header (MRH) with a combination of a flexible bitstring and an explicit node index; encapsulating the MRH and the copy of the packet into a second packet; and sending the second packet to a next hop for each subtree.

Description

Optimal Stateless Best Effort Multicast

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional application 63/390,564 filed on July 19, 2022, by Futurewei Technologies, Inc., and titled “Optimal Stateless Best Effort Multicast,” which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] The present disclosure is generally related to network communications, and in particular to stateless best effort multicast tree with node index and flexible bit string.

BACKGROUND

[0003] Multicast traffic is a type of network traffic where a single packet is sent to a group of devices simultaneously, rather than sending separate packets to each individual device. This is different from unicast traffic, where a packet is sent from one source device to one destination device, and broadcast traffic, where a packet is sent to all devices on the network.

[0004] Currently, bit indexed explicit replication (BIER) is a network architecture used for stateless best effort multicast. Bit Index Explicit Replication (BIER) mechanisms provide forwarding of multicast data packets through a BIER domain. For a data packet to be multicast to leaf/egress nodes in the BIER domain, fixed bitstrings are used to encode the leaf/egress nodes. The fixed bitstrings are big and they are even bigger when leaf/egress nodes are widespread. There are multiple BIER forwarding tables (BIFTs) on every node in the BIER domain. The fixed bitstrings and BIFTs impose substantial communication and processing overhead. BIER is described in further detail in Internet Engineering Task Force (IETF) document Request for Comments (RFC) 8279 entitled “Multicast Using Bit Index Explicit Replication (BIER)” by IJ.

Wijnands, et al., published November 2017.

SUMMARY

[0005] The disclosed aspects/embodiments of systems and methods provide stateless best effort (BE) multicast along the shortest paths to egress nodes of a point to multipoint (P2MP) path/tree. The multicast data packet is encapsulated in an Internet Protocol version 6 (IPv6) multicast routing header (MRH). The MRH comprises the egress nodes represented by a combination of indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along a shortest path. Therefore, packet routing within the stateless multicast is more efficient.

[0006] A first aspect relates to a method for performing stateless multicasting in a network implemented by an ingress node of the network, comprising receiving, from a traffic source, a packet; generating a copy of the packet for each subtree of a point to multipoint (P2MP) path branching from the ingress node; adding an encoding of a subtree into a multicast routing header (MRH) with a combination of a flexible bitstring and an explicit node index; encapsulating the MRH and the copy of the packet into a second packet; and sending the second packet to a next hop for each subtree.

[0007] Optionally, in any of the preceding aspects, another implementation of the aspect provides receiving the P2MP path from a controller, wherein the P2MP path is from the ingress node to a plurality of egress nodes along a shortest path to each of the egress nodes.

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of the subtree, a subtree end field indicating an end of the subtree, and a subtree field.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the explicit node index comprises a B flag field and a node index field, and the flexible bit string comprises a B flag field, a start index field, a size of bitstring field, and a bitstring field.

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides that each subtree branching from the ingress node comprises a group of the egress nodes which are on the P2MP path and to each of which a shortest path has a same next hop.

[0011] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the second packet further comprises a packet header comprising a source address and a destination address, wherein the source address is set to an address of the ingress node, and wherein the destination address is set to an address of the next hop.

[0012] Optionally, in any of the preceding aspects, another implementation of the aspect provides obtaining the address of the next hop from a node index forwarding table (NIFT) of the ingress node.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the node index forwarding table comprises a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an Internet Protocol version 6 (IPv6) address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node. [0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the encoding of the subtree with the combination of the flexible bitstring and the explicit node index is based on a memory space used for the encoding and/or time for processing the encoding.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the combination uses less space than any other combination of a second flexible bitstring and a second explicit node index.

[0016] A second aspect relates to a method for performing stateless multicasting in a network implemented by a node of the network, comprising receiving a packet comprising a packet header, a multicast routing header (MRH), and a multicast packet, wherein the MRH comprises a first subtree encoded using a combination of a flexible bitstring and an explicit node index; generating a copy of the packet for each next hop branching from the node to egress nodes specified in the first subtree; and sending the copy of the packet with an updated MRH to a next hop.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect provides setting, in the packet header, a destination address of the copy of the packet to a first address of the next hop.

[0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides determining the next hop node based on a node index forwarding table (NIFT) comprising a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an Internet Protocol version 6 (IPv6) address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node. [0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the flexible bitstring comprises a B flag field, a start index field, a S-bitstring field, and a bitstring field, and wherein the explicit node index comprises a B flag field, and a node index field.

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of a subtree, a subtree end field indicating an end of the subtree, and a subtree field.

[0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the updated MRH comprises a second subtree encoded by modifying at least one of the subtree left field or the subtree end field to point to a start and an end of the second subtree, respectively and removing a first plurality of egress nodes which are not on the second subtree.

[0022] Optionally, in any of the preceding aspects, another implementation of the aspect provides that removing the first plurality of egress nodes which are not on the second subtree comprises setting corresponding node index fields or bits in bitstring fields to zeros, wherein setting corresponding bits in a bitstring field (bitstring) to zeros comprises logically ANDing the bitstring with bits in a bit mask of an egress node on the second sub-tree, and wherein the bits in the bit mask correspond to the bitstring.

[0023] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the second subtree has a second plurality of egress nodes indicated by a second bit mask of a first egress node of the first subtree or an updated first subtree, and wherein an i-th bit with value 1 in the second bit mask indicates an egress node having node index i is one of the second plurality of the egress nodes when the egress node is on the first subtree or the updated first subtree.

[0024] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the updated first subtree is from updating the first subtree by removing the second plurality of egress nodes through setting corresponding node index fields or bits in bitstring fields to zeros, wherein setting corresponding bits in a bitstring field to zeros comprises logically ANDing the bitstring with INVERSE of bits in a bit mask of an egress node in the second plurality of egress nodes, and wherein the bits in the bit mask correspond to the bitstring.

[0025] Optionally, in any of the preceding aspects, another implementation of the aspect provides decap sulating the packet; sending the multicast packet to an IP multicast forwarding module, and updating the first subtree when an egress node on the first subtree or an updated first subtree is the node, wherein updating the first subtree comprises setting a node index or bit in a bitstring to zero, and wherein the node index or bit encodes the egress node.

[0026] Athird aspect relates to an ingress node in a network, comprising a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the ingress node to perform the method of the first aspect.

[0027] A fourth aspect relates to a node in a network, comprising a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the node to perform the method of the second aspect.

[0028] A fifth aspect relates to a non-transitory computer readable medium comprising a computer program product for use by an ingress node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the ingress node to execute the method of the first aspect.

[0029] A sixth aspect relates to a non-transitory computer readable medium comprising a computer program product for use by a node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the node to execute the method of the second aspect.

[0030] A seventh aspect relates to an ingress node in a network, comprising means for performing the method of the first aspect.

[0031] An eight aspect relates to a node in a network, comprising means for performing the method of the second aspect.

[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 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 is a schematic diagram of an example network with a controller and network nodes according to an embodiment of the present disclosure. [0036] FTG. 2A is a schematic diagram of an example node index forwarding table of a transit node according to an embodiment of the present disclosure.

[0037] FIG. 2B is a schematic diagram of an example node index forwarding table of an ingress node according to an embodiment of the present disclosure.

[0038] FIG. 3A is a schematic diagram of an example P2MP path/tree encoding format according to an embodiment of the present disclosure.

[0039] FIG. 3B is a schematic diagram of an example P2MP path/tree encoding format according to an embodiment of the present disclosure.

[0040] FIG. 3C is a schematic diagram of an example P2MP tree encoding format according to an embodiment of the present disclosure.

[0041] FIG. 3D is a schematic diagram of an example P2MP tree encoding format according to an embodiment of the present disclosure.

[0042] FIG. 4A is a schematic diagram of an example IPv6 MRH for best effort multicast according to an embodiment of the present disclosure.

[0043] FIG. 4B is a schematic diagram of an example of a shortest path tree branching from a transit node according to an embodiment of the present disclosure.

[0044] FIG. 4C is a schematic diagram of an example of a shortest path tree branching from a transit node according to an embodiment of the present disclosure.

[0045] FIG. 5A illustrates an IPv6 packet sent by an ingress node to a transit node according to an embodiment of the present disclosure.

[0046] FIG. 5B illustrates an IPv6 packet sent by an ingress node to a transit node according to an embodiment of the present disclosure. [0047] FTG. 5C illustrates an IPv6 packet sent by an ingress node to a transit node according to an embodiment of the present disclosure.

[0048] FIG. 6A illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0049] FIG. 6B illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0050] FIG. 6C illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0051] FIG. 6D illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0052] FIG. 6E illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0053] FIG. 6F illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0054] FIG. 6G illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0055] FIG. 6H illustrates an IPv6 packet in accordance with an embodiment of the present disclosure.

[0056] FIG. 7 is a method implemented by an ingress node according to an embodiment of the present disclosure.

[0057] FIG. 8 is a method implemented by a node according to an embodiment of the present disclosure. [0058] FIG. 9 is a schematic diagram of a network apparatus according to an embodiment of the present disclosure.

DESCRIPTION OF EMBODIMENTS

[0059] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or 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. In the present disclosure, path and tree, branch and sub-tree, node number and node index, leaf and egress are used interchangeably.

[0060] BIER is a current solution for stateless best effort multicast. BIER mechanisms provide forwarding of multicast data packets through a BIER domain. For a data packet to be multicast to leaf/egress nodes in the BIER domain, fixed bitstrings are used to encode the leaf/egress nodes. The fixed bitstrings are big and they are even bigger when leaf/egress nodes are widespread. There are multiple BIER forwarding tables (BIFTs) on every network node in the BIER domain. The fixed bitstrings and BIFTs impose substantial communication and processing overheads.

[0061] The disclosed aspects/embodiments of systems and methods providing stateless best effort multicast along the shortest paths to egress nodes of a point to multipoint (P2MP) path/tree. The multicast data packet is encapsulated in an Internet Protocol version 6 (IPv6) multicast routing header (MRH). The MRH comprises the egress nodes represented by indexes of the nodes and flexible bit strings for the nodes. The packet is delivered to each of the egress nodes along a shortest path for an efficient stateless multicast. The packet routing within the stateless multicast domain is improved relative to existing techniques as the network nodes do not need to maintain any multicast flow forwarding state information or multiple BIFTs.

[0062] FIG. 1 is a schematic diagram of a network topology 100 of a network 102 supporting stateless multicast. The network 102 receives packet 140 from a content source 104. The content source 104 may be a network node, a server, a data center, or other telecommunications device configured to receive and respond to requests for content. The network 102 comprises a plurality of network nodes (or simply, nodes) 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 130, 132, and 134. While fifteen network nodes 106-134 are shown in the network 102, more or fewer nodes may be included in practical applications.

[0063] Each of the network nodes 106-134 may comprise a router, switch, or other telecommunications device configured to receive, route, store, and transmit packet 140. Some of the network nodes, namely the network nodes 106, 118, 120, 122, 124, 126, 128, 130, 132, and 134 are disposed at an edge of the network 102. The network nodes 106, 118, 120, 122, 124, 126, 128, 130, 132, and 134 receiving multicast packets from outside the network 102 may be referred to as an ingress network node (or simply, an ingress node). The network nodes 106, 118, 120, 122, 124, 126, 128, 130, 132, and 134 transmitting multicast packets out of the network 102 may be referred to as an egress network node (or simply, an egress node). Depending on the direction of multicast packet traffic, each of the network nodes 106, 118, 120, 122, 124, 126, 128, 130, 132, and 134 may function as an ingress node or an egress node. The network nodes 108, 110, 112, 114, and 116 forwarding multicast packets in the network 102 may be referred to as a transit network node (or simply, a transit node). [0064] The content sources 104 and network nodes 106-134 in FIG. 1 are coupled to, and communicate with each other, via links 150. The links 150 may be wired, wireless, or some combination thereof. In an embodiment, each of the links 150 may have a cost. The cost of each of the links 150 may be the same or different, depending on the network topology 100 and the conditions therein.

[0065] For ease of reference, the various network nodes have been given a letter and number designation in FIG. 1. For example, the content source 104 is designated CE1, the network nodes 106-134 are designated PEI, Pl to P5, PE2 to PE10, and so on. In an embodiment, network nodes 106-134 in the network 102 are numbered or indexed from 1 to the number of the nodes. For example, egress nodes PEI to PE10 have node numbers or node indexes 1 to 10 respectively, and transit nodes Pl to P5 are numbered or indexed from 11 to 15, respectively. That is, each node 106-134 in the network 102 may be assigned a node number or a node index. The node index of each network node is unique in the network 102. It should be noted that the node indexes assigned to PEI to PE 10 and Pl to P5 in the following discussion are given as examples and may be different in practice.

[0066] In an embodiment, the network 102 is controlled by a network controller 180 (or simply, a controller). The network controller 180 receives multicast join request(s) from the one or more of egress nodes 118-124. After receiving multicast join request(s), the network controller 180 sends a point-to-multipoint (P2MP) path/tree 160 to the ingress node 106. The P2MP path/tree 160 provided by the network controller 180 extends from the ingress node 106 towards the egress nodes 118-124. In an embodiment, the network controller 180 has information about the node indexes. The P2MP path/tree 160 is encoded using node indexes of egress nodes 118-124 (designated as PE2-PE5), which are 2, 3, 4 and 5, respectively. The node indexes are represented by a flexible bit string or the indexes directly. Thus, the P2MP path/tree 160 encoded the node indexes PE2, PE3, PE4, and PE5 using a combination of flexible bit string and the indexes directly. A more efficient representation is used to encode the P2MP path/tree 160. That is when the indexes are more efficient, the indexes are used directly; otherwise, the flexible bit string is used.

[0067] In an embodiment, after having the node indexes of the nodes in the network 102, every node builds and maintains a node index forwarding table (NIFT) that is used for forwarding packets in the network 102.

[0068] FIG. 2A is a schematic diagram of an example node index forwarding table 200A of a transit node according to an embodiment of the present disclosure. In the depicted embodiment, the node index forwarding table 200 A represents the data stored of Pl in FIG. 1. The node index forwarding table 200 A comprises 10 rows for each of egress node indexes with the IPv6 address of the next hop of the shortest path to the egress node. The node index forwarding table 200A comprises a first column comprising the node index (or number) 1 through 10 corresponding to PEI to PE 10, a second column comprising next hop interface, a third column comprising next hop node index, a fourth column comprising next hop IPv6 address, and a fifth column comprising node index bit mask (BM) of the same next hop node (BM-SN).

[0069] In an example, the second row comprises node index 2 of egress PE2, next hop interface PHP2, next hop node P2’s index 12, next hop node P2’s IPv6 address, and the same next hop P2’s bit mask (BM-SN) ObO 110000000 indicating node indexes 2 and 3 of PE2 and PE3 have the same next hop P2. The BM-SN has the bits for node indexes 2 and 3 set to ones (1 s) and the other bits set to zeros (0s). i.e., each of bit 2 and 3 has value 1 in the BM-SN and each of the other bits has value 0. The bits in the BM-SN are counted from left to right, and from 1, 2, 3, and so on. The BM-SN indicates the egress nodes PE2 and PE3 having the same next hop, i.e., being on the same sub-tree via the next hop P2. Tn an example, the fourth row comprises node index 4 of egress PE4, next hop interface Pl — > P5, next hop node P5’s index 15, next hop P5’s IPv6 address, and the same next hop P5’s bit mask (BM-SN) ObOOOllllOOO indicating node indexes 4, 5, 6 and 7 ofPE4, PE5, PE6 and PE7 have the same next hop P5. The BM-SN has the bits for node indexes 4, 5, 6 and 7 set to ones (Is) and the other bits set to zeros (Os). The BM-SN indicates the egress nodes PE4, PE5, PE6 and PE7 having the same next hop P5, i.e., being on the same sub-tree via the next hop P5. In an example, the ninth row comprises node index 9 of egress PE9, next hop interface P 1 ->PE9, next hop nodePE9’s index 9, next hop PE9’s IPv6 address, and the same next hop PE9’s bit mask (BM-SN) ObOOOOOOOOlO indicating node index 9 of PE9 has the same next hop PE9. The BM-SN has the bit for node index 9 set to one (1) and the other bits set to zeros (Os).

[0070] In an embodiment, the next hop IPv6 address field in each row is a core part (or core) of an IPv6 address. The core is the IPv6 address’ locator or locator and function. In an embodiment, all the locators of the IPv6 addresses used for next hops for best effort multicast have the same size, and all the functions of the IPv6 addresses used also have the same size. In one case, when the core is IPv6 address’ locator, the ingress of a P2MP tree puts a function and parameters into the corresponding fields of DA of the packet with MRH to be sent to the next hop along the subtree branching from the ingress. In another case, when the core is IPv6 address’ locator and function, the ingress of a P2MP tree puts parameters into the parameters field of DA of the packet with MRH to be sent to the next hop along the sub-tree branching from the ingress node.

[0071] FIG. 2B is a schematic diagram of an example node index forwarding table 200B of an ingress node according to an embodiment of the disclosure. In the depicted embodiment, the node index forwarding table 200B represents the data stored of PEI in FIG. 1. The node index forwarding table 200B comprises a first column comprising node index (or number), a second column comprising next hop interface, a third column comprising next hop node index, a fourth column comprising next hop IPv6 address, and a fifth column comprising node index bit mask (BM) of the same next hop node (BM-SN).

[0072] In an example, the first row comprises node index 1 of egress node PEI . All other fields such as the next hop interface, next hop node index, next hop IPv6 address, and node index bit mask are null since the next hop to PEI is NULL (i.e., there is no next hop from PEI to PEI itself). In an example, the second row comprises node index 2 of egress node PE2, next hop interface PE I — >P1 , next hop node Pl’s index 11, next hop node Pl’s IPv6 address, and the same next hop Pl’s bit mask (BM-SN) ObOl 11111110 indicating node indexes 2 to 9 of nodes PE2 to PE9 have the same next hop PL The BM-SN has the bits for node indexes 2 to 9 set to ones (Is) and the other bits set to zeros(Os), i.e., each of bit 2 to 9 has value 1 in the BM-SN and each of the other bits have value 0. The BM-SN indicates the egress nodes PE2 to PE9 having the same next hop Pl, i.e., being on the same sub-tree via the next hop Pl if PE2 to PE9 are in the MRH. Each of the third to ninth row is similar to the second row. In an example, the tenth row comprises node index 10 of egress node PE 10, next hop interface PEI -> PEI 0, next hop node PElO’s index 10, next hop PElO’s IPv6 address, and the same next hop PElO’s bit mask (BM-SN) ObOOOOOOOOOl indicating node index 10 of PE10 has the same next hop PE10. The BM-SN has the bit for node index 10 set to one (1) and the other bits set to zeros (0s). The BM-SN indicates the egress node PE10 having the same next hop PE 10, i.e., being on the same sub-tree via the next hop PE 10 if PE 10 is in the MRH

[0073] Referring back to FIG. 1, PEI receives a packet from the traffic source CE1 that is to be multicasted out of the network 102 at egress nodes PE2, PE3, PE4, and PE5. As will be further described herein, in accordance with the disclosed embodiments, after receiving the packet, PEI determines the next hop node to send the packet to PE2, PE3, PE4, and PE5 using the node index forwarding table 200B in FIG. 2B. In one embodiment, for a packet to be transported by the P2MP path/tree 160, PEI duplicates the packet for each sub-tree of the P2MP path/tree branching from the PEI, encapsulates the packet copy in an MRH containing the sub-tree, and sends the encapsulated packet copy to next hop node along the sub-tree.

[0074] When P 1 receives the encapsulated packet copy, using the node index forwarding table

200A in FIG. 2A, Pl obtains the index of each of the egress nodes and determines the address of the next hop node. Pl duplicates the packet for each sub-tree branching from the Pl and sends the packet copy with an updated MRH to the next hop along the sub-tree. The above process repeats at each of the receiving nodes until the egress nodes specified in the original P2MP tree (i.e., PE2, PE3, PE4, and PE5 in the given example) receives a copy of the packet.

[0075] FIG. 3A is a schematic diagram of an example P2MP path/tree encoding format 300A according to an embodiment of the present disclosure. In one embodiment, encoding of the P2MP path/tree 160 is the encoding of the node indexes of the egress nodes of the P2MP path/tree. For example, for the P2MP tree from ingress node PEI to egress nodes PE2, PE3, PE4 and PE5 in FIG.1, the encoding of the P2MP tree (i.e., the encoding of the node indexes of egress nodes PE2 to PE5 of the P2MP tree) using a flexible bitstring is shown in FIG. 3 A. The node indexes of egress nodes PE2 to PE5 are 2 to 5, respectively. The flexible bitstring includes a B flag field 302, a start index (Startindex) field 304, a size of bitstring (S-BitString) field 306, and a bitstring (BitString) field 308. The B flag field 302, which occupies 1 bit, indicates whether a flexible bit string is used to encode multiple node indexes. The B flag field 302 set to 1 indicates that a flexible bit string is used to encode multiple node indexes and B flag field 302 set to 0 indicates that a node index is directly used to encode the node index. The Startindex field 304 contains a start index. The S- BitString field 306, which occupies 1 byte, indicates the size of the BitString field in a unit such as byte. The BitString field 308 contains a bit string, each bit with value of 1 in the string indicates a node index, which is the start index plus the bit number. In an embodiment, the bit number in the bit string is counted from left to right and from 0. That is, the first bit is bit 0, the second bit is bit 1, the third bit is bit 2, and so on. In this case, the node indexes are represented by a flexible bit string (or bit string) indirectly.

[0076] For an example, as shown in FIG. 3 A, the indexes of egress nodes PE2, PE3, PE4 and PE5 are encoded by four fields of a flexible bit string such as the B flag field 302 with value of 1, the start index (Startindex) field 304 with value of 2, the size of bitstring (S-BitString) field 306 with value of 1 indicating that the size of BitString is 1 byte, and the bitstring (BitString) field 308 with value Obi 1110000 combined with the start index indicates four node indexes 2, 3, 4 and 5, wherein the BitString’s first bit (bit 0) with value 1 indicates the first node index 2 equal to 2 + 0; the BitString’s second bit (bit 1) with value 1 indicates the second node index 3 equal to 2 + 1, the BitString’s third bit (bit 2) with value 1 indicates the third node index 4 equal to 2 + 2, and so on. In this example, using P2MP tree encoding format 300 A, the encoding of the P2MP tree using a flexible bit string uses 4 bytes. In contrast, BIER uses 32 bytes (i.e., 256 bits) for encoding the same P2MP tree using a fixed bit string.

[0077] FIG. 3B is a schematic diagram of an example P2MP path/tree encoding format 300B according to an embodiment of the present disclosure. In one embodiment, for the P2MP path/tree 160 from ingress node PEI to egress nodes PE2, PE3, PE4 and PE5 in FIG.1 , the encoding of the P2MP path/tree 160 (i.e., the encoding of the node indexes of egress nodes PE2 to PE5 of the tree) using node indexes directly is shown in FIG. 3B. The node indexes of egress nodes PE2 to PE5 are 2 to 5, respectively. In this embodiment, the indexes of egress nodes PE2, PE3, PE4 and PE5 are represented directly by NodeTndex fields 312 each following a B flag field 310 set to value 0.

The Nodeindex fields 312 comprising a first Nodeindex field contains node index 2, which is the node index of PE2, a second Nodeindex field contains node index 3, which is the node index of

PE3, a third Nodeindex field contains node index 4, which is the node index of PE4, and a fourth Nodeindex field contains node index 5, which is the node index of PE5. In this example, using P2MP tree encoding format 300B, the encoding of the P2MP through representing node indexes directly uses 8 bytes. In contrast, using P2MP tree encoding format 300A, the encoding of the P2MP through representing node indexes indirectly by a flexible bit string uses 4 bytes, which is more efficient than the encoding as shown in FIG. 3B. Thus, the encoding of the tree through representing node indexes indirectly by a flexible bit string as shown in FIG. 3 A is selected or used in the MRH.

[0078] When comparing the efficiencies of two encodings (e.g., 300A and 300B), in addition to the memory spaces used by the two encodings, central processing unit (CPU) times for processing the two encodings may be considered. In one embodiment, one encoding is more efficient than another encoding when one of the conditions is satisfied: 1) one encoding uses less space and less time than the other encoding, 2) one encoding uses the same space size as the other encoding and uses less time than the other encoding, 3) one encoding uses less space than the other encoding and uses the same time as the other encoding, 4) one encoding uses less space than the other encoding and the cost for the extra time used by one encoding is less than the cost for the space saved by one encoding, 5) one encoding uses less space than the other encoding, and/or 6) one encoding uses less time than the other encoding and the cost for the extra space used by one encoding is less than the cost for the time saved by one encoding. [0079] FIG. 3C is a schematic diagram of an example P2MP path/tree encoding format 300C according to an embodiment of the present disclosure. In this example, suppose that the index of egress node PE2 is 2 and the indexes of egress nodes PE3, PE4, and PE5 are 30003, 30004 and 30005, respectively. In the depicted embodiment, P2MP tree encoding format 300C illustrates an encoding P2MP tree for PE2 to PE5 using a combination of a direct node index (for PE2) and a flexible bit string (for PE3-PE5). As shown in P2MP tree encoding format 300C, a B flag field 314 is set to 0. When the B flag field 314 is 0, there is one field 316 of a given length (e.g., 15 bits) following the B flag field 314. Field 316 contains a node index. The node index of PE2 is represented directly by Nodeindex with value of 2 (i.e., Nodeindex = 2).

[0080] When a B flag field 318 is set to 1, it indicates that a flexible bit string is being used to encode multiple node indexes. In an embodiment, when the B flag field 318 is 1, there are three fields following the B flag field 318: a start index (Startindex) field 320 of 15 bits, a size of bit string (S-BitString) field 322 of 1 byte, and a bit string (BitString) field 324 of variable size. The Startindex field 320 contains a start index. The S-BitString field 322 indicates the size of the BitString field 324 in a unit such as byte. The BitString field 324 contains a bit string, where each bit with value of 1 in the bit string indicates a node index, which is the start index indicated in Startindex field 320 plus the bit number. For instance, in the given example, the Startindex field 320 is encoded with value 30003 (i.e., PE3’s node index acting as the starting index), the S- BitString field 322 is encoded with the value of 1 to indicate that the size of the BitString field 324 is 1 byte, and the BitString field 324 is encoded with the bit string 1 1100000. BitString field 324 with value 11100000 combined with the Startindex field 320 indicating three node indexes 30003, 30004 and 30005, wherein the BitString’s first bit (bit 0) with value 1 indicates the first node index 30003 equal to 30003 + 0; the BitString’s second bit (bit 1) with value 1 indicates the second node index 30004 equal to 30003 + 1 ; and the BitString’s third bit (bit 2) with value 1 indicates the third node index 30005 equal to 30003 + 2, which corresponds to the node indexes of PE3, PE4, and PE5 respectively. In this example, using P2MP tree encoding format 300C, the encoding of the P2MP tree uses 6 bytes. In contrast, in BIER the encoding of the same P2MP tree using fixed bit strings uses 64 bytes (i.e., 2 x 256 bits). The encoding of the node index of PE2 by using a node index uses 2 bytes as shown in FIG. 3C, but the encoding of the node index of PE2 by using a flexible bit string uses 4 bytes. Thus, the encoding of the node index using a node index is more efficient. As such, the encoding of the node index of PE2 using a node index is selected.

[0081] FIG. 3D is a schematic diagram of an example P2MP path/tree encoding format 300D according to an embodiment of the present disclosure. In this example, suppose that the indexes of egress nodes PE2-PE5 are 20002, 20003, 30004 and 30006, respectively. In the depicted embodiment, the encoding of the P2MP path/tree from ingress PEI to egresses PE2, PE3, PE4 and PE5 is shown in FIG. 3D. As shown in P2MP tree encoding format 300D, the indexes of egress nodes PE2 and PE3 are encoded by a flexible bit string. The B flag field 326 is set to 1 indicating that a flexible bit string is being used to encode multiple node indexes. For instance, in the given example, the Startindex field 328 is encoded with value 20002 (i.e., PE2’s node index acting as the starting index), the S-BitString field 330 is encoded with the value of 1 to indicate that the size of the BitString field 332 is 1 byte, and the BitString field 332 is encoded with the bit string 11000000 combined with the start index indicating two node indexes 20002 and 20003 of PE2 and PE3 respectively. Further, as shown in P2MP tree encoding format 300D, the indexes of egress nodes PE4 and PE5 are encoded by another flexible bit string. The B flag field 334 is set to 1 indicating that a flexible bit string is being used to encode multiple node indexes. For instance, in the given example, the Startindex field 336 is encoded with value 30004 (i.e., PE4’s node index acting as the starting index), the S-BitString field 338 is encoded with the value of 1 to indicate that the size of the BitString field 340 is 1 byte, and the BitString field 340 is encoded with the bit string 10100000 combined with the start index indicating two node indexes 30004 and 30006 of PE4 and PE5 respectively. The BitString’ s first bit (bit 0) with value 1 indicates the first node index 30004 equal to 30004 + 0; and the BitString’s third bit (bit 2) with value 1 indicates the second node index 30006 equal to 30004 + 2. In this example, as shown in FIG. 3D, representing the node indexes of PE2 and PE3 indirectly by using a flexible bit string is used in the MRH. Similarly, representing the node indexes of PE4 and PE5 indirectly by using a flexible bit string is used in the MRH. In this embodiment, using P2MP tree encoding format 300D, the encoding of the P2MP tree using flexible bit strings uses 8 bytes. In contrast, BIER uses 64 bytes to encode the same P2MP tree.

[0082] FIG. 4A is a schematic diagram of an example IPv6 packet 400A with an IPv6 MRH 400B for best effort multicast according to an embodiment of the present disclosure. The IPv6 packet 400A includes an IPv6 header 402, a routing header indicating MRH 404, and an IP multicast datagram/packet 406. The IPv6 header 402 includes a Next Header field that indicates the next header in the IPv6 packet 400A. The IPv6 header 402 also includes a destination address (DA) and source address (SA) of the IPv6 packet. The MRH 404 includes a Next Header field, a Routing Type field (type to be determined (TBD)), a subtree left/ start (SL) field, a subtree end/size (SE) field, and an encoding of a multicast subtree. The IP multicast datagram/packet (or an extension header) 406 includes an IP datagram header and data carried in a payload of the TP multicast datagram 406.

[0083] The MRH 400B is an example embodiment of the MRH 404 in IPv6 packet 400A.

The MRH 400B includes a Next Header field 408, a Hdr Ext Len field 410, a Routing Type field 412, a version field 414, a flags field 416, a SL field 418, a SE field 420, a reserved field 422, and a subtree encoding field 424. The Next Header field 408 is an 8-bit field that stores a value indicating the IP multicast datagram header 406 in IPv6 packet 400 A. The Hdr Ext Len field 410 is an 8-bit field that stores a value indicating the length of the MRH 400B in a unit of 64 bits (i.e., 8 bytes) excluding the first 8 bytes. The Routing Type field 412 is an 8-bit field that stores a value (to be determined (TBD) by the Internet Assigned Numbers Authority (IANA)) indicating that the routing header is an MRH for best effort multicast. The SL field 418 is an 11 -bit field that stores a value indicating the start of the sub-tree. The SE field 420 is an 11 -bit field that stores a value indicating the end of the sub-tree. The sub-tree field 424 stores an encoding of a multicast subtree. The multicast subtree may be encoded using any of the P2MP tree encoding formats as described in connection with FIGS. 3A-3D.

[0084] FIG. 4B is a schematic diagram of an example 400C of a shortest path tree branching from a transit node according to an embodiment of the present disclosure. For a P2MP path/tree or sub-tree from a transit node such as Pl to a number of egress nodes, the P2MP path/tree or subtree is the shortest path tree from Pl to the egress nodes in Pl’s view. Pl views the sub-trees branching from Pl. For example, as depicted in FIG. 4B, the tree or sub-tree from Pl towards egresses PE2 to PE5 is the shortest path tree from Pl towards PE2 to PE5 from Pl’s view.

[0085] FIG. 4C is a schematic diagram of an example 400D of a shortest path tree branching from a transit node according to an embodiment of the present disclosure. As depicted in FIG. 4C, Pl views two sub-trees branching from Pl , one is from Pl via next hop P2 to egresses PE2 and PE3, and the other is from Pl via next hop P5 to PE4 and PE5. When Pl sends an IPv6 packet with an MRH containing a sub-tree branching from Pl to the next hop along the sub-tree (in Pl ’s view), the sub-tree is a tree from the next hop node as root in the view of the next hop node. For example, when Pl sends next hop P2 the IPv6 packet with an MRH containing the sub-tree from Pl via next hop P2 to egresses PE2 and PE3 in Pl’s view, the sub-tree is a tree from P2 to egresses PE2 and PE3 in P2’s view.

[0086] FIG. 5A illustrates an IPv6 packet 500A sent by an ingress node to a transit node according to an embodiment of the present disclosure. The IPv6 packet 500A includes an IPv6 header 502, a MRH 504, and an IP multicast packet 506. The IPv6 header 502 and the IP multicast packet 506 are the same as the IPv6 header 402 and the IP multicast packet 406 of IPv6 packet 400Ain FIG. 4A. The MRH 504 is the same as the MRH 400B in FIG. 4A.

[0087] In the depicted embodiment, the IPv6 packet 500A represents an example of IPv6 packet that is constructed by PEI having a P2MP path/tree 160 from PEI towards PE2 to PE5 in FIG. 1. As described above, when PEI receives the IP multicast packet 506 to be transmitted by the P2MP path/tree from PEI towards PE2 to PE5, PEI duplicates the packet for each sub-tree branching from PEI, encapsulates the copy in the IPv6 packet with the MRH 504, and sends the IPv6 packet to the next hop along the sub-tree. The number of subtrees from PEI is determined by the number of different next hop nodes from PEI to the egress nodes (i.e., PE2 to PE5), which is based on the locally stored node index forwarding table 200B as described in FIG. 2B. PEI gets the IPv6 addresses of the next hops to the egress nodes using node index forwarding table 200B with the node indexes of the egress nodes, which are 2, 3, 4 and 5. As shown in FIG. 2B, the IPv6 addresses of the next hops are all the same (i.e., the IPv6 address of P l) for node indexes 2, 3, 4 and 5. Thus, there is only one subtree from PEI via Pl towards PE2 to PE5.

[0088] As shown in FIG. 5 A, in the IPv6 packet 500 A, PEI sets the DA in the IPv6 header 502 to the IPv6 address of Pl and sets the SA to the IPv6 address of PEI. In this embodiment, the

P2MP tree from PEI towards PE2 to PE5 as encoded in FIG. 3 A is used in the MRH 504. PEI builds the MRH 504 based on the encoding of the P2MP tree in FIG. 3 A through including the sub-tree from Pl, setting the SL field in the MRH 504 to 4, which acts as a pointer pointing to the start of the subtree, and setting the SE field to 4 to indicate the end of the sub-tree. PEI then sends the IPv6 packet 500 A to Pl. In one embodiment, ingress PEI sets DA’s core of the IPv6 packet to the next hop node Pl’s IPv6 address’ core, the other parts of the DA such as parameters or function and parameters to the corresponding values configured or given by a controller or an application. [0089] FIG. 5B illustrates an IPv6 packet 500B sent by an ingress node to a transit node according to an embodiment of the present disclosure. The IPv6 packet 500B includes an IPv6 header 508, a MRH 510, and an IP multicast packet 512. The IPv6 header 508 and the IP multicast packet 512 are the same as the IPv6 header 402 and the IP multicast datagram 406 of IPv6 packet 400 A in FIG. 4A. The MRH 510 is the same as the MRH 400B in FIG. 4 A.

[0090] In the depicted embodiment, the IPv6 packet 500B represents an example of an IPv6 packet constructed by PEI having a P2MP path/tree 160 from PEI towards PE2 to PE5 in FIG. 1. As described above, when PEI receives an IP multicast packet 512 to be transmitted by the P2MP path/tree from PEI towards PE2 to PE5, PEI duplicates the packet for each sub-tree branching from PEI, encapsulates the copy in the IPv6 packet with the MRH 510, and sends the IPv6 packet to the next hop along the sub-tree. As shown in FIG. 5B, in the IPv6 packet 500B, PEI sets the DA of the IPv6 packet 500B to next hop node Pl’s IPv6 address and sets the SA to the IPv6 address of PEI. In this embodiment, the P2MP tree from PEI towards PE2 to PE5 as encoded in FIG. 3C is used in the MRH 510. PEI builds the MRH 510 based on the encoding of the P2MP tree in FIG. 3C through including the sub-tree from Pl, setting the SL field in the MRH 510 to 6, which acts as a pointer pointing to the start of the subtree, and setting the SE field to 6, which is the size of the sub-tree to indicate the end of the sub-tree. PEI then sends the IPv6 packet 500B to Pl. [0091] FIG. 5C illustrates an IPv6 packet 500C sent by an ingress node to a transit node according to an embodiment of the present disclosure. The IPv6 packet 500C includes an IPv6 header 514, a MRH 516, and an IP multicast packet 518. The IPv6 header 514 and the IP multicast packet 518 are the same as the IPv6 header 402 and the IP multicast datagram 406 of IPv6 packet 400 A in FIG. 4 A. The MRH 516 is the same as the MRH 400B in FIG. 4 A. In the depicted embodiment, the IPv6 packet 500C represents an example of IPv6 packet that is constructed by PEI having a P2MP path/tree from PEI towards PE2 to PE5 in FIG. 1. As described above, when PEI receives an IP multicast packet to be transmitted by the P2MP path/tree from PEI towards PE2 to PE5, PEI duplicates the packet for each sub-tree branching from PEI, encapsulates the copy in the IPv6 packet with the MRH 516, and sends the IPv6 packet to the next hop along the sub-tree from PEI via the next hop Pl towards PE2 to PE5. As shown in FIG. 5C, in the IPv6 packet 500C, PEI sets the DA of the IPv6 packet 500C to next hop node Pl’s IPv6 address and sets the SA to the IPv6 address of PEI . In this embodiment, the P2MP tree from PEI towards PE2 to PE5 as encoded in FIG. 3D is used in the MRH 516. PEI builds the MRH 516 based on the encoding of the P2MP tree in FIG. 3D through including the sub-tree from Pl, setting the SL field in the MRH 516 to 8, which acts as a pointer pointing to the start of the subtree, and setting the SE field to 8, which is the size of the sub-tree to indicate the end of the sub-tree. PEI then sends the IPv6 packet 500C to Pl.

[0092] FIG. 6A illustrates an IPv6 packet 600A sent by P l to P2 in accordance with an embodiment of the present disclosure. After receiving the IPv6 packet (e g., the IPv6 packet 500 A) from PEI, Pl determines whether the IPv6 packet’s 500A next header is a MRH by checking whether the next header specified in the IPv6 header of the packet 500A is a routing header, and if yes, determining whether the routing type in the routing header is a value (TBD) indicating that the routing header is a MRH. When the next header is the MRH, Pl duplicates the packet 500A for each sub-tree branching from Pl and sends the packet copy with an updated MRH to the next hop along the sub-tree. The sub-trees from Pl are determined by SL, SE and sub-tree fields in the MRH 504 as shown in FIG. 5A. In PEl’s view, the sub-tree field includes the sub-tree from PEI via next hop Pl towards egresses PE2 to PE5, SL = 4 as a pointer points to the start of the sub-tree, and SE = 4 as the size of the sub-tree “points” to the end of the sub-tree. In P 1 ’ s view, the sub-tree field contains the P2MP sub-tree from Pl towards egresses PE2 to PE5.

[0093] As shown in FIG. 4C, there are 2 sub-trees from P 1. One sub-tree is from P 1 via next hop P2 to egresses PE2 and PE3. The other sub-tree is from Pl via next hop P5 to egresses PE4 and PE5. Pl duplicates the packet for each of these two sub-trees and sends one copy with an updated MRH to the next hop P2 for the first sub-tree and another copy with the updated MRH to the next hop P5 for the second sub-tree.

[0094] In an example, suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by Pl as shown in FIG. 5 A. In one embodiment, Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 2 of egress PE2. The node index 2 is indicated by the bit 0 with value 1 and Startindex with value 2, which equals to 2 + 0 = 2. Using node index 2, from the second row of Pl’s node index forwarding table as shown in FIG. 2A, Pl obtains the IPv6 address of the next hop P2 to egress PE2 and the BM-SN ObO 110000000 indicating node indexes 2 and 3 of PE2 and PE3 have the same next hop P2. As shown in FIG. 6 A, Pl sets DA of packet-c 600A to next hop P2’s IPv6 address in the IPv6 header 602, removes the egress nodes indexes not having next hop P2 by logically ANDing the bitstring in the MRH 604 of packet-c with the BM-SN’ s bits corresponding to the bitstring, i.e., the bitstring = the bitstring AND the BM-SN’s bits corresponding to the bitstring. The bitstring Obi 111 OOOO corresponds to the BM-SN’s bit 2 to 9, which is Obi 1000000 Obi 1110000 AND 0b 11000000 = Obi 1000000. Pl sends packet-c to the DA of packet-c, which is P2. As shown in FIG. 6A, the IPv6 packet 600A comprising the IP multicast packet 606 sent to P2, which is received by P2.

[0095] In an embodiment. Pl removes the egress node indexes having the next hop P2 from packet-p by logically ANDing the bitstring in the MRH of packet-p with the INVERSE of BM- SN’s bits corresponding to the bitstring, and copies packet-p to packet-c. The bitstring in the MRH of packet-p and packet-c is ObOOllOOOO, which is Obi 1110000 AND (INVERSE 0b 11000000) = ObllllOOOO AND ObOOl 11111 = ObOOllOOOO. This bitstring with Startindex = 2 indicates node indexes 4 and 5 of egress nodes PE4 and PE5. In one embodiment, Pl sets DA’s core of packet-c to the next hop P2’s IPv6 address’ core.

[0096] FIG. 6B illustrates an IPv6 packet 600B sent to P5 in accordance with an embodiment of the present disclosure. In an example, suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by Pl and node indexes of PE2 and PE3 in the packet are removed. In an embodiment, Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 4 of egress PE4. The node index 4 is indicated by the bit 2 with value 1 and Startindex with value 2, which equals to 2 + 2 = 4. Using node index 4, from the fourth row of Pl’s node index forwarding table as shown in FIG. 2A, Pl obtains the IPv6 address of the next hop P5 to egress node PE4 and the BM-SN ObOOOl l l lOOO indicating node indexes 4, 5, 6 and 7 of PE4, PE5, PE6 and PE7 have or share the same next hop P5. As shown in FIG. 6B, Pl sets DA of packet-c 600B to next hop P5’s IPv6 address in the IPv6 header 608, removes the egress node indexes not having the same next hop P5 by logically ANDing the bitstring in the MRH 610 of packet-c with the BM-SN’s bits corresponding to the bitstring, i.e., the bitstring = the bitstring AND the BM-SN’s bits corresponding to the bitstring. The bitstring ObOOllOOOO corresponds to the BM-SN’s bit 2 to 9, which is ObOOl l llOO. ObOOl lOOOO AND ObOOll l lOO = ObOOl lOOOO. Pl sends packet-c to the DA of packet-c, which is P5. As shown in FIG. 6B, the IPv6 packet 600B comprising the IP multicast packet 612 to P5, which is received by P5. In one embodiment, Pl sets DA’s core of packet-c to the next hop P5’s IPv6 address’ core. In one embodiment, Pl removes the egress nodes PE4 and PE5 from packet-p by logical ANDing the bitstring in the MRH of packet-p with the INVERSE of BM-SN’s corresponding bits. The bitstring in the MRH of packet-p is ObOOOOOOOO, which is ObOOl lOOOO AND (INVERSE ObOOl 111100) = ObOOllOOOO AND Ob 11000011 = ObOOOOOOOO. The bitstring in the MRH of packet-p is all zeros, which indicates Pl has sent a packet copy to each of the sub-trees branching from Pl .

[0097] FIG. 6C illustrates an IPv6 packet 600C sent to PE2 in accordance with an embodiment of the present disclosure. After receiving the IPv6 packet (e.g., the IPv6 packet 500B) from Pl, P2 determines whether the IPv6 packet’s next header is a MRH. When the next header is the MRH, P2 duplicates the packet for each sub-tree branching from P2 and sends the packet copy with an updated MRH to the next hop along the sub-tree. The sub-trees branching from P2 are determined by the SL field, the SE field, and the sub-tree field in the MRH 604 as shown in FIG. 6A, where SL = 4 as a pointer points to the start of the sub-tree, and SE = 4 as the size of the sub-tree indicates the end of the sub-tree. There are 2 sub-trees from P2. One sub-tree is from P2 to PE2. The other is from P2 to PE3. P2 duplicates the packet for each of these two sub-trees and sends one copy with an updated MRH to the next hop PE2 for the first sub-tree and another copy with an updated MRH to the next hop PE3 for the second sub-tree.

[0098] In an example, suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by P2. In one embodiment, P2 gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 2 of egress PE2. The node index 2 is indicated by the bit 0 with value 1 and Startindex with value 2, which equals to 2 + 0 = 2. Using node index 2, from the second row of P2’s Node Index Forwarding Table, P2 obtains the IPv6 address of the next hop PE2 to egress PE2 and the BM-SN indicating the node indexes having the same next hop PE2. As shown in FIG. 6C, P2 sets DA of packet-c 600C to next hop PE2’s IPv6 address in the IPv6 header 614, removes the egress node indexes not having the next hop PE2 by logically ANDing the bitstring in the MRH 616 of packet-c with the BM-SN’s bits corresponding to the bitstring, i.e., the bitstring = the bitstring AND the BM-SN’s bits corresponding to the bitstring. The bitstring Ob 11000000 corresponds to the BM-SN’s bit 2 to 9, which is OblOOOOOOO. Obi 1000000 AND OblOOOOOOO = OblOOOOOOO. P2 sends packet-c to the DA of packet-c, which is PE2. As shown in FIG. 6C, the IPv6 packet 600C comprising the IP multicast packet 618 to PE2, which is received by PE2.

[0099] In one embodiment, P2 removes the egress PE2 from packet-p by logically ANDing the bitstring in the MRH of packet-p with the INVERSE of BM-SN’s corresponding bits, and copies packet-p to packet-c. The bitstring in the MRH of packet-p and packet-c is ObO 1000000, which is 0b 11000000 AND (INVERSE OblOOOOOOO) = 0b 11000000 AND ObOll lllll = ObO 1000000. This bitstring with Startindex = 2 indicates node indexes 3 of egress node PE3. In one embodiment, P2 sets DA’s core of packet-c to the next hop PE2’s IPv6 address’ core.

[0100] FIG. 6D illustrates an IPv6 packet 600D sent to PE3 in accordance with an embodiment of the present disclosure. Tn an example, suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by P2 and PE2’s node index in the packet is removed (i.e., the bit for PE2’s node index is cleared). In an embodiment, P2 gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 3 of egress PE3. The node index 3 is indicated by the bit 1 with value 1 and StartTndex with value 2, which equals to 2 + 1 = 3. Using node index 3, from the third row of P2’s node index forwarding table, P2 obtains the IPv6 address of the next hop PE3 to egress PE3 and the BM-SN ObOO 10000000 indicating node index 3 of PE3 has the same next hop PE3. In one embodiment, P2 sets DA of packet-c 600D to next hop PE3’s IPv6 address in the IPv6 header 620, removes the egress node indexes not having next hop PE3 by logically ANDing the bitstring in the MRH 622 of packet-c with the BM-SN’s bits corresponding to the bitstring, i.e., the bitstring = the bitstring AND the BM-SN’s bits corresponding to the bitstring. The bitstring ObOlOOOOOO corresponds to the BM-SN’s bit 2 to 9, which is ObOlOOOOOO. ObOlOOOOOO AND ObOlOOOOOO = ObOlOOOOOO. P2 sends packet-c to the DA of packet-c, which is PE3. As shown in FIG. 6D, the IPv6 packet 600D comprising the IP multicast packet 624 is sent to PE3, which is received by PE3. In an instance, P2 knows that PE3 is an egress since the next hop node to PE3 is PE3 itself. In an embodiment, P2 decapsulates the packet copy packet-c and sends the decapsulated packet such as the IP multicast datagram in the next header to egress PE3. In one embodiment, P2 removes the egress PE3 from packet-p by logically ANDing the bitstring in the MRH of packet-p with the INVERSE of BM-SN’s corresponding bits. The bitstring in the MRH of packet-p is ObOOOOOOOO, which is ObOlOOOOOO AND (INVERSE ObOlOOOOOO) = ObOlOOOOOO AND 0b 10111111 = ObOOOOOOOO . The bitstring in the MRH of packet-p is all zeros, which indicates P2 has sent a packet copy to each of the sub-trees branching from P2. In one embodiment, P2 sets DA’s core of packet-c to the next hop PE3’s IPv6 address’ core.

[0101] FIG. 6E illustrates an IPv6 packet 600E sent to P2 in accordance with an embodiment of the present disclosure. After receiving the IPv6 packet 500B from PEI as shown in FIG. 5B, Pl determines whether the packet’s next header is a MRH. When the next header is the MRH, Pl duplicates the packet for each sub-tree branching from Pl and sends the packet copy with an updated MRH to the next hop along the sub-tree. There are 2 sub-trees from Pl. One sub-tree is from Pl via next hop P2 to egresses PE2 and PE3. The other is from Pl via next hop P5 to egresses PE4 and PE5. Pl duplicates the packet for each of these two sub-trees and sends one copy with an updated MRH to the next hop P2 for the first sub-tree and another copy with an updated MRH to the next hop P5 for the second sub-tree.

[0102] Suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by Pl as shown in FIG. 5B. In one embodiment, Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 2 of egress PE2. The node index 2 is represented by Nodeindex with value 2. Using node index 2, from the second row of Pl ’s Node Index Forwarding Table, Pl obtains the IPv6 address of the next hop P2 to egress PE2 and the BM-SN indicating egress node indexes having or sharing the same next hop P2. As shown in FIG. 6E, Pl sets DA of packet-c 600E to next hop P2’s IPv6 address in the IPv6 header 626, removes the egress node indexes not having or sharing the next hop P2 (i.e., the egress PE4 and PE5). The node indexes of egresses PE4 and PE5 have the same next hop P5, but do not have or share the next hop P2. The node indexes of egresses PE2 and PE3 have the same next hop P2. In one implementation, removing the egress node indexes not having or sharing next hop P2 comprises logically ANDing the bitstring in the MRH 628 of packet-c with the BM-SN’ s bits corresponding the bitstring. P l sends packet-c to the DA of packet-c, which is P2. As shown in FIG. 6E, the IPv6 packet 600E comprising the TP multicast packet 630 sent to P2, which is received by P2. Pl removes the egress node indexes from packet-p that have or share the next hop P2. This is achieved by setting the Nodeindex to 0 since the Nodeindex with value 2 has or shares the next hop P2, and logically ANDing the bitstring in the MRH of packet-p with the INVERSE of the BM-SN’s bits corresponding to the bitstring. And then Pl changes SL and SE in packet-p’s

MRH to indicate the start and end of the tree/sub-tree. Pl copies packet-p to packet-c. The bitstring in the MRH of packet-p and packet-c is ObOl 100000, indicating the node indexes of egresses PE4 and PE5. Both SL and SE are 4 in the MRH of packet-p and packet-c. In one embodiment, Pl sets DA’s core of packet-c to the next hop P2’s IPv6 address’ core.

[0103] FIG. 6F illustrates an IPv6 packet 600F sent to P5 in accordance with an embodiment of the present disclosure. Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 30004 of egress PE4. The node index 30004 is indicated by the bitstring having bit 1 with value 1 and Startindex with value 30003, which equals to 30003 + 1 = 30004. Using node index 30004, from Pl’s node index forwarding table, Pl obtains the IPv6 address of the next hop P5 to egress PE4 and the BM-SN indicating egress node indexes having or sharing the same next hop P5. As shown in FIG. 6F, Pl sets DA of packet-c 600F to next hop P5’s IPv6 address in the IPv6 header 632, removes the egress node indexes not having or sharing the next hop P5 from packet-c’ s MRH 634. Pl sends packet-c to the DA of packet-c, which is P5. As shown in FIG. 6F, the IPv6 packet 600F comprising the IP multicast packet 636 sent to P5, which is received by P5. In one embodiment, Pl sets DA’s core of packet-c to the next hop P5’s IPv6 address’ core. Pl removes the egress node indexes from packet-p that have or share the next hop P5. This is achieved by logically ANDing the bitstring in the MRH of packet-p with the INVERSE of the BM-SN’s bits corresponding to the bitstring. The bitstring in the MRH of packet- p is all zeros, which indicates Pl has sent a packet copy to each of the sub-trees branching from Pl.

[0104] FIG. 6G illustrates an IPv6 packet 600G sent to P2 in accordance with an embodiment of the present disclosure. After receiving the IPv6 packet from PEI as shown in FIG. 5C, Pl determines whether the packet’s next header is a MRH. When the next header is the MRH, Pl duplicates the packet for each sub-tree branching from Pl and sends the packet copy with an updated MRH to the next hop along the sub-tree. There are 2 sub-trees from Pl. One sub-tree is from Pl via next hop P2 to egresses PE2 and PE3. The other is from Pl via next hop P5 to egress nodes PE4 and PE5. Pl duplicates the packet for each of these two sub-trees and sends one copy with an updated MRH to the next hop P2 for the first sub-tree and another copy with the updated MRH to the next hop P5 for the second sub-tree.

[0105] Suppose that packet-p is the packet to be processed and packet-c is a copy of packet-p. Initially, packet-p is the packet received by Pl as shown in FIG. 5C. In one embodiment, Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 20002 of egress PE2. The node index 20002 is represented by a flexible bitstring having bit 0 with value 1 and Startindex with value 20002. Using node index 20002, from Pl’s Node Index Forwarding Table, Pl obtains the IPv6 address of the next hop P2 to egress PE2 and the BM-SN indicating egress node indexes having or sharing the same next hop P2. As shown in FIG. 6G, Pl sets DA of packet-c to next hop P2’s IPv6 address in the IPv6 header 638, removes the egress node indexes not having or sharing the next hop P2 (i.e., the egress nodes PE4 and PE5). The node indexes of egresses PE4 and PE5 have the same next hop P5, but do not have or share the same next hop P2 as node index 20002. The node indexes of egresses PE2 and PE3 have the same next hop P2. In one implementation, removing the egress node indexes not having or sharing next hop P2 comprises logically ANDing each of the two bitstrings in the MRH 640 of packet-c with the BM- SN’s bits corresponding to the bitstring. Pl sends packet-c to the DA of packet-c, which is P2. FIG. 6G shows the packet 600G comprising the IP multicast packet 642 sent to P2, which is received by P2. Pl removes the egress node indexes from packet-p that have or share the next hop P2. This is achieved by logically ANDing each of the two bitstrings in the MRH of packet-p with the INVERSE of the BM-SN’s bits corresponding to the bitstring. And then Pl changes SL and SE in packet-p’s MRH to indicate the start and end of the tree/sub-tree. Pl copies packet-p to packet-c. The first bitstring in the MRH of packet-p and packet-c is ObOOOOOOOO (i.e., all zeros(Os)). The second bitstring is OblOlOOOOO, indicating the node indexes of egresses PE4 and PE5. Both SL and SE are 4 in the MRH of packet-p and packet-c. In one embodiment, Pl sets DA’s core of packet-c to the next hop P2’s IPv6 address’ core.

[0106] FIG. 6H illustrates an IPv6 packet 600H sent to P5 in accordance with an embodiment of the present disclosure. Pl gets the first egress node index from the sub-tree in the MRH in packet-p, which is node index 30004 of egress PE4. The node index 30004 is indicated by the bitstring having bit 0 with value 1 and Startindex with value 30004, which equals to 30004 + 0 = 30004. Using node index 30004, from Pl’s Node Index Forwarding Table, Pl obtains the IPv6 address of the next hop P5 to egress PE4 and the BM-SN indicating egress node indexes having or sharing the same next hop P5. As shown in in FIG. 6H, Pl sets DA of packet-c to next hop P5’s IPv6 address in the IPv6 header 644, removes the egress node indexes not having or sharing the next hop P5 from packet-c’s MRH 646. Pl sends packet-c to the DA of packet-c, which is P5. FIG. 6H shows the packet comprising the IP multicast packet 648 sent to P5, which is received by P5. In one embodiment, Pl sets DA’s core of packet-c to the next hop P5’s IPv6 address’ core. Pl removes the egress node indexes from packet-p that have or share the next hop P5. This is achieved by logically ANDing the bitstring in the MRH of packet-p with the INVERSE of the BM-SN’s bits corresponding to the bitstring. The bitstring in the MRH of packet-p is all zeros, which indicates that Pl has sent a packet copy to each of the sub-trees branching from Pl. [0107] Tn one embodiment, after receiving the IPv6 packet from P2, PE2 determines whether the packet’s next header is a MRH. When the next header is the MRH, PE2 checks if PE2 itself is an egress through checking whether the node index in the MRH is the node index of PE2 itself. When PE2 is an egress, PE2 decapsulates the packet and sends the IP multicast datagram to an IP multicast forwarding module.

[0108] Best Effort Multicast Forwarding Procedure at Ingress Node.

[0109] In one embodiment, for a packet to be transported by a P2MP path/tree, the ingress of the P2MP path/tree duplicates the packet for each sub-tree of the P2MP path/tree branching from the ingress, encapsulates a copy of the packet in a MRH containing the sub-tree and sends the encapsulated copy of the packet to the next hop node along the sub-tree. 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. In an embodiment, ingress PEI sends Pl the packet as illustrated in FIG. 5A.

[0110] In one embodiment, for a packet to be transported by a P2MP path/tree, the ingress of the P2MP path/tree encapsulates the packet in a MRH containing the tree and “sends” the encapsulated packet to the ingress itself through calling the best effort multicast forwarding procedure of the ingress. This procedure duplicates the encapsulated packet for each sub-tree of the P2MP path/tree branching from the ingress and sends the copy to the next hop node along the sub-tree. For example, suppose that there is a P2MP path/tree in FIG. I from ingress PEI to egresses PE2, PE3, PE4, PE5 and PE10. There are two sub-trees branching from the ingress PEI of the P2MP path/tree. One is from ingress PEI via next hop node Pl towards PE2 to PE5; the other is from ingress PEI to egress PE10. For a packet to be transported by the P2MP path/tree, ingress PEI encapsulates the packet in a MRH containing the P2MP path/tree and sends the encapsulated packet to the ingress PEI itself through calling the best effort multicast forwarding procedure of the ingress PEI. The procedure duplicates the encapsulated packet for each of these two sub-trees branching from the ingress PEI and sends the copy to the next hop node along the sub-tree.

[OHl] In one embodiment, before sending the packet with MRH to the next hop along a subtree branching from the ingress, the ingress sets DA’s core of the packet to the next hop’s IPv6 address’ core, the other parts of the DA such as parameters or function and parameters to the corresponding values configured or given by a controller or an application.

[0112] Best Effort Multicast Forwarding Procedure at a Node.

[0113] When receiving an IPv6 packet with a MRH containing a P2MP tree/sub-tree, a node duplicates the packet for each sub-tree branching from the node and sends a copy of the packet with an updated MRH to the next hop along the sub-tree. The number of sub-trees branching from the node is the number of different next hop nodes from the node to the egress nodes of the tree. The node determines the different next hops to the egress nodes using the node index forwarding table of the node with the node indexes of the egress nodes. In an embodiment of a best effort multicast forwarding procedure, the execution of the procedure for an IPv6 packet with a MRH at a node duplicates the packet for each sub-tree branching from the node and sends the packet copy with an updated MRH to the next hop along the sub-tree.

[0114] The execution of the best effort multicast forwarding procedure includes the following steps. Initially, packet-p is the IPv6 packet received by the node.

[0115] At step 1, the procedure checks if packet-p’ s MRH does not have any egress node index.

If the MRH does not have any egress node index, the procedure discards packet-p and returns; otherwise (i.e., the MRH has some egress node indexes), the procedure proceeds to next step (i.e., step 2).

[0116] At step 2, the procedure finds the first egress node index J in packet-p’s MRH (i.e., in the tree/subtree in packet-p’s MRH).

[0117] At step 3, the procedure checks if node index J is the index of the node itself. If so, the procedure duplicates packet-p to packet-c, decapsulates the packet copy (i.e., packet-c), sends the decapsulated packet copy (i.e., IP multicast datagram/packet) to the IP multicast forwarding module, clears node index J in packet-p’s MRH, and goes to step 1; otherwise (i.e., node index J is not the node index of the node), the procedure proceeds to next step (i.e., step 4).

[0118] At step 4, the procedure gets the next hop IPv6 address (NH-IPv6 for short) and the BM-SN from node index forwarding table of the node using node index I as the “index” into the table.

[0119] At step 5, the procedure duplicates packet-p to packet-c, removes the egress node indexes from the packet copy’s MRH (i.e., packet-c’s MRH) that do not have the same next hop as node index J, sets DA of the packet copy to NH-IPv6, sends the copy to DA (i.e., the next hop). In one embodiment, the procedure sets DA’s core of the packet copy to the core of NH-IPv6.

[0120] At step 6, the procedure removes the egress node indexes having the same next hop as node index J from packet-p’s MRH, and then goes to step 1.

[0121] In an embodiment, when the DA of the IPv6 packet received by the node comprises a locator, a function and parameters, and the locator identifies the node, the node executes the instructions indicated by the function with the parameters before or during the execution of the procedure. [0122] Each operation on a MRH is the operation on the P2MP tree/sub-tree in the MRET from its start to its end indicated by SL and SE respectively, i.e., on every Nodeindex and flexible bitstring (bitstring for short) from the start to the end of the P2MP tree/sub-tree. For example, removing the egress node indexes having the same next hop as node index J from packet-p’s MRH is each bitstring &= -BM-SN’s bits corresponding to bitstring and each Nodeindex = 0 when Nodeindex has the same next hop as node index J from the start of the P2MP tree/sub-tree in packet-p’s MRH indicated by SL to the end of the tree/sub-tree indicated by SE.

[0123] As described in step 1, from the start of the tree/sub-tree in packet-p’s MRH indicated by SLto the end of the tree/sub-tree indicated by SE, if each Nodeindex field is 0 and each bitstring are zeros, then packet-p’s MRH does not have any egress node index. In one embodiment, for a flexible bitstring with a Startindex and a bitstring, when the bitstring becomes zeros, the Startindex is set to zero (0). In this case, if each Nodeindex and Startindex is 0 from the start to the end of the tree/sub-tree, then packet-p’s MRH does not have any egress node index.

[0124] As described in step 2, the first node index J is the first node index represented directly by a Nodeindex with value J or represented indirectly by a flexible bitstring from the start of the tree/sub-tree in MRH pointed by SL.

[0125] As described in step 3, clearing node index J in packet-p’s MRH is clearing node index J in the tree/subtree in packet-p’s MRH and comprises setting Nodeindex field to 0 when node index J is represented directly by Nodeindex with value J, or setting the bit for the node index J to 0 in the bitstring when node index J is represented indirectly by the bitstring.

[0126] As described in step 5, removing the egress node indexes from the packet copy packet- c’s MRH (i.e., from the tree/subtree in the packet copy packet-c’s MRH) that do not have the same next hop as node index J comprises logically ANDing each bitstring with the BM-SN’s bits corresponding to the bitstring (i.e., bitstring &= BM-SN’s bits corresponding to bitstring), and setting each Nodeindex field to 0 when node index in the field does not have the same next hop as node index J from the start of the tree/sub-tree in packet-c’s MRH indicated by SL to the end of the tree/sub-tree indicated by SE.

[0127] As described in step 6, removing the egress node indexes from packet-p’s MRH (i.e., from the tree/subtree in packet-p’s MRH) that have the same next hop as node index J comprises logically ANDing each bitstring with INVERSE of the BM-SN’s bits corresponding to the bitstring (i.e., bitstring &= -BM-SN’s bits corresponding to bitstring), and setting each Nodeindex field to 0 when node index in the field has the same next hop as node index J from the start of the tree/sub- tree in packet-p’s MRH indicated by SL to the end of the tree/sub-tree indicated by SE.

[0128] After or while changing the MRH, each of step 3, 5, and 6 comprises updating SL and SE to indicate the start and end of the tree/sub-tree in the MRH respectively, wherein the updated SL points to the first flexible bitstring with a bit having value 1 or the first Nodeindex with a value greater than 0, and the updated SE is the size of the P2MP tree/sub-tree from the start pointed by the updated SL to the last flexible bitstring with a bit having value 1 or the last Nodeindex with a value greater than 0.

[0129] FIG. 7 is a flowchart illustrating a process 700 for performing stateless multicasting in a network according to an embodiment of the present disclosure. The process 700 is implemented by an ingress node (e.g., PE I in FIG. 1) of the network. The ingress node, at step 702, receives a packet from a traffic source. The ingress node, at step 704, generates a copy of the packet for each subtree of a point to multipoint (P2MP) path branching from the ingress node. In an embodiment, a controller such as path computation element (PCE) can have the information about the node indexes in the network, and send the P2MP path to the ingress node of the path. In one embodiment, the P2MP path is encoded using a combination of an explicit node index and a flexible bitstring APCE is a network entity responsible for calculating and determining the optimal paths for traffic flows in a network. The ingress node, at step 706, adds an encoding of a subtree in a multicast routing header (MRH) with a combination of a flexible bitstring and an explicit node index as described in FIGS. 3A-3D. In an embodiment, the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of the subtree, a subtree end field indicating an end of the subtree, and a subtree field. In an embodiment, the explicit node index comprises a B flag field and a node index field, and wherein the flexible bitstring comprises a B flag field, a start index field, a size of bitstring field, and a bitstring field. In an embodiment, each subtree branching from the ingress node comprises a group of the egress nodes which are on the P2MP path and to each of which a shortest path has a same next hop. In an embodiment, the encoding of the subtree with the combination of the flexible bitstring and the explicit node index is based on a memory space used for the encoding and/or time for processing the encoding. In an embodiment, the combination uses less space than any other combination of a second flexible bitstring and a second explicit node index.

[0130] The ingress node, at step 708, encapsulates the MRH and the copy of the packet into a second packet. In an embodiment, the second packet further comprises a packet header comprising a source address and a destination address, wherein the source address is set to an address of the ingress node, and wherein the destination address is set to an address of the next hop. Encapsulating a packet refers to the process of adding additional information (e g., adding new protocol headers) to the original data packet to enable the packet to be properly handled or routed across a network. [0131] As described above, the address of the next hop is obtained from a node index forwarding table of the ingress node, wherein the node index forwarding table comprises a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an Internet Protocol version 6 (IPv6) address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node.

[0132] The ingress node, at step 710, sends the second packet to a next hop for each subtree of the P2MP path.

[0133] FIG. 8 is a flowchart illustrating a process 800 for performing stateless multicasting in a network according to an embodiment of the present disclosure. The process 800 is implemented by a node (e.g., Pl in FIG. 1) of the network. The node, at step 802, receives a packet comprising a packet header, a MRH, and a multicast packet. The MRH includes a first subtree encoded using a combination of a flexible bitstring and an explicit node index as described in FIGS. 6A-6H. In an embodiment, the flexible bitstring includes a B flag field, a start index field, a S-bitstring field, and a bitstring field. In some embodiments, the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of a subtree, a subtree end field indicating an end of the subtree, and a subtree field.

[0134] The node, at step 804, generates a copy of the packet for each of next hop nodes branching from the node to egress nodes specified in the first subtree using a node index forwarding table, wherein the node index forwarding table comprises a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an IPv6 address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node. [0135] The node, at step 806, sends the copy of the packet with an updated MRH to a next hop. In some embodiments, the updated MRH comprises a second subtree encoded by modifying at least one the subtree left field or a subtree end field to point to a start and an end of the second subtree respectively and removing the egress nodes which are not on the second subtree. The second subtree has a second plurality of egress nodes indicated by a second bit mask of a first egress node of the first subtree or an updated first subtree, wherein an i-th bit with value “1” (one) in the second bit mask indicates an egress node having node index i is one of the second plurality of the egress nodes when the egress node is on the first subtree or the updated first subtree. In some embodiments, removing the egress nodes which are not on the second subtree comprises setting corresponding Nodeindex fields or bits in bitstrings to zeros. In some embodiments, the updated first subtree is from updating the first subtree by removing the second plurality of egress nodes through setting corresponding node index fields or bits to zeros. In some embodiments, the node sets a Startindex field in the flexible bitstring to zero when a flexible bitstring has a bitstring with all zeros. In some embodiments, the node also modifies a destination address in the packet header of the copy of the packet to a first address of the next hop. When an egress node on the first subtree or an updated first subtree is the node, the node decapsulates the packet, sends the multicast packet to an IP multicast forwarding module, and updates the first subtree. Updating the first subtree comprises setting a node index or bit in a bitstring to zero, and wherein the node index or bit encodes the egress node.

[0136] FIG. 9 illustrates an apparatus 900 configured to implement one or more of the methods disclosed herein according to an embodiment of the disclosure. For example, the apparatus 900 may represent an ingress node, transit node, or egress node as described herein (e.g., PE1-PE10 or P1-P5 of network 100 in FIG. 1). The apparatus 900 comprises ingress ports 910 and receiver units (Rx) 920 for receiving data packets, one or more processors, logic units, or central processing units (CPUs) 930 for processing data packets, transmitter units (TX) 940 and egress ports 950 for transmitting data packets, and a memory 960. The one or more processors 930 are implemented by any suitable combination of hardware, middleware, and firmware. For example, the one or more processors 930 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or digital signal processors (DSPs). The one or more processors 930 are in communication with the ingress ports 910, receiver units 920, transmitter units 940, egress ports 950, and memory 960. The memory 960 comprises one or more disks, tape drives, or solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, or to store instructions and data that are read during program execution. The memory 960 may be volatile and/or non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), or static randomaccess memory (SRAM). In one embodiment, the memory 960 comprises a stateless multicast module 970. The stateless multicast module 970 comprises executable instructions and data configurations that when executed by the one or more processors 930 implement the disclosed embodiments as described herein.

[0137] 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. A person skilled in the art would understand how to combine any or all of the above techniques in a vast variety of permutations and combinations. [0138] 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.

[0139] 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 for performing stateless multicasting in a network implemented by an ingress node of the network, the method comprising: receiving, from a traffic source, a packet; generating a copy of the packet for each subtree of a point to multipoint (P2MP) path branching from the ingress node; adding an encoding of a subtree into a multicast routing header (MRH) with a combination of a flexible bitstring and an explicit node index; encapsulating the MRH and the copy of the packet into a second packet; and sending the second packet to a next hop for each subtree.

2. The method of claim 1, further comprising receiving the P2MP path from a controller, wherein the P2MP path is from the ingress node to a plurality of egress nodes along a shortest path to each of the egress nodes.

3. The method of any of claims 1 -2, wherein the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of the subtree, a subtree end field indicating an end of the subtree, and a subtree field.

4. The method of any of claims 1-3, wherein the explicit node index comprises a B flag field and a node index field, and wherein the flexible bitstring comprises a B flag field, a start index field, a size of bitstring field, and a bitstring field.

5. The method of any of claims 1-4, wherein each subtree branching from the ingress node comprises a group of the egress nodes which are on the P2MP path and to each of which a shortest path has a same next hop.

6. The method of any of claims 1-5, wherein the second packet further comprises a packet header comprising a source address and a destination address, wherein the source address is set to an address of the ingress node, and wherein the destination address is set to an address of the next hop.

7. The method of any of claims 1-6, further comprising obtaining the address of the next hop from a node index forwarding table (NIFT) of the ingress node.

8. The method of any of claims 1-7, wherein the NIFT comprises a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an Internet Protocol version 6 (IPv6) address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node.

9. The method of any of claims 1 -8, wherein the encoding of the subtree with the combination of the flexible bitstring and the explicit node index is based on a memory space used for the encoding and/or time for processing the encoding.

10. The method of any of claims 1 -9, wherein the combination uses less space than any other combination of a second flexible bitstring and a second explicit node index.

11. A method for performing stateless multicasting in a network implemented by a node of the network, the method comprising: receiving a packet comprising a packet header, a multicast routing header (MRH), and a multicast packet, wherein the MRH comprises a first subtree encoded using a combination of a flexible bitstring and an explicit node index; generating a copy of the packet for each next hop branching from the node to egress nodes specified in the first subtree; and sending the copy of the packet with an updated MRH to a next hop.

12. The method of claim 11, further comprising setting, in the packet header, a destination address of the copy of the packet to a first address of the next hop.

13. The method of any of claims 11-12, further comprising determining the next hop node based on a node index forwarding table (NIFT) comprising a row for each egress node in the network, wherein the row comprises a first node index of an egress node, an interface of the next hop, a second node index of the next hop, an Internet Protocol version 6 (IPv6) address of the next hop, and a bit mask of a same next hop node, and wherein the bit mask indicates egress nodes that have the same next hop node.

14. The method of any of claims 11-13, wherein the flexible bitstring comprises a B flag field, a start index field, a S-bitstring field, and a bitstring field, and wherein the explicit node index comprises a B flag field and a node index field.

15. The method of any of claims 11-14, wherein the MRH comprises a next header field, a routing type field, a header length field, a version field, a flags field, a subtree left field indicating a start of a subtree, a subtree end field indicating an end of the subtree, and a subtree field.

16. The method of any of claims 11-15, wherein the updated MRH comprises a second subtree encoded by modifying at least one of the subtree left field or the subtree end field to point to a start and an end of the second subtree, respectively and by removing a first plurality of egress nodes which are not on the second subtree.

17. The method of any of claims 11-16, wherein removing the first plurality of egress nodes which are not on the second subtree comprises setting corresponding node index fields or bits in bitstring fields to zeros, wherein setting corresponding bits in a bitstring field to zeros comprises logically ANDing a bitstring with bits in a bit mask of a second egress node on the second subtree, and wherein the bits in the bit mask correspond to the bitstring.

18 The method of any of claims 11 -17, wherein the second subtree has a second plurality of egress nodes indicated by a second bit mask of a first egress node of the first subtree or an updated first subtree, and wherein an i-th bit with value 1 in the second bit mask indicates an egress node having node index i is one of the second plurality of the egress nodes when the egress node is on the first subtree or the updated first subtree.

19. The method of any of claims 11-18, wherein the updated first subtree comprises updating the first subtree by removing the second plurality of egress nodes through setting corresponding node index fields or bits in bitstring fields to zeros, wherein setting corresponding bits in a bitstring field to zeros comprises logically ANDing a bitstring with INVERSE of bits in a bit mask of an egress node in the second plurality of egress nodes, and wherein the bits in the bit mask correspond to the bitstring.

20. The method of any of claims 11-19, further comprising: decapsulating the multicast packet; sending the multicast packet to an IP multicast forwarding module; and updating the first subtree when the first egress node on the first subtree or the updated first subtree is the node, wherein updating the first subtree comprises setting a node index or bit in a bitstring to zero, and wherein the node index or bit encodes the egress node.

21. An ingress node in a network, comprising: a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the ingress node to perform the method of any of claims 1-10.

22. A node in a network, comprising: a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the node to perform the method of any of claims 11-20.

23. A non-transitory computer readable medium comprising a computer program product for use by an ingress node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the ingress node to execute the method of any of claims 1-10.

24. A non-transitory computer readable medium comprising a computer program product for use by a node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the node to execute the method of any of claims 11-20.

25. An ingress node in a network, comprising means for performing the method of any of claims 1-10.

26. A node in a network, comprising means for performing the method of any of claims 11-20.