WO2023168134A1 - Multidiffusion sans état avec indice de nœud et chaîne de bits flexible - Google Patents

Multidiffusion sans état avec indice de nœud et chaîne de bits flexible Download PDF

Info

Publication number
WO2023168134A1
WO2023168134A1 PCT/US2023/024663 US2023024663W WO2023168134A1 WO 2023168134 A1 WO2023168134 A1 WO 2023168134A1 US 2023024663 W US2023024663 W US 2023024663W WO 2023168134 A1 WO2023168134 A1 WO 2023168134A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
node
subtree
header
mrh
Prior art date
Application number
PCT/US2023/024663
Other languages
English (en)
Inventor
Huaimo Chen
Original Assignee
Futurewei Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Futurewei Technologies, Inc. filed Critical Futurewei Technologies, Inc.
Publication of WO2023168134A1 publication Critical patent/WO2023168134A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/66—Layer 2 routing, e.g. in Ethernet based MAN's

Definitions

  • the present disclosure is generally related to network communications, and in particular to various embodiments of systems and methods providing stateless multicast with node index and flexible bit string.
  • 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.
  • bit indexed explicit replication is a network architecture used to forward multicast traffic.
  • BIER enables stateless multicast without Traffic Engineering (TE).
  • Traffic Engineering refers to processes that manages network traffic (e.g., processes that optimize the performance and utilization of a network by controlling the flow of traffic through the network).
  • Stateless multicast refers to a multicast forwarding mechanism that does not require the use of any protocol-specific state information in the forwarding plane of the network. In other words, the network devices do not need to maintain any explicit multicast state, such as multicast group membership or routing tables, to forward multicast traffic.
  • Stateless multicast relies on the use of bitstrings to identify the multicast group and the set of devices that belong to that group.
  • BIER uses a bitstring to indicate which routers in the network should receive the packet, enabling more targeted and efficient routing.
  • a first aspect relates to a method for performing stateless multicasting in a network implemented by an ingress node of the network.
  • the method includes receiving a first packet from a traffic source; determining a point to multipoint (P2MP) path for forwarding the first packet; determining a next hop node for each subtree of the P2MP path branching from the ingress node based on a node index forwarding table; encapsulating the first packet to generate an encapsulated packet for each subtree; encoding a subtree of egress nodes in a multicast routing header (MRH) of the encapsulated packet using a flexible bitstring, an explicit node index, or a combination of the flexible bitstring and the explicit node index; and sending the encapsulated packet to the next hop node for each subtree.
  • P2MP point to multipoint
  • 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 Internet Protocol version 6 (IPv6) address of a next hop to the egress node, a media access control (MAC) address of the next hop, a second node index of the next hop, and a bit mask of a same next hop node, wherein the bit mask indicates egress nodes that have the same next hop node.
  • IPv6 Internet Protocol version 6
  • MAC media access control
  • the MRH is located in the encapsulated packet between a layer 2 header and the first packet.
  • the MRH comprises a header length.
  • the MRH is located in the encapsulated packet between a layer 3 header and the first packet.
  • the MRH further comprises a routing type, a header length, a first pointer to a start of the subtree, and a second pointer to an end of the subtree.
  • the MRH comprises a routing type, a header length, and a number of egress nodes in the subtree.
  • encoding the subtree comprises encoding a number of node indexes of a certain size preceding the node indexes of the certain size in the subtree.
  • the encoding the subtree comprises encoding the flexible bitstring, the flexible bitstring comprising a flag bit, a start index, a bitstring size, and a bitstring.
  • a second aspect relates to a method for performing stateless multicasting in a network implemented by a transit node of the network.
  • the method includes receiving a packet comprising a packet header, a MRH, and a multicast packet, wherein the MRH comprises a first subtree encoded using a flexible bitstring, an explicit node index, or a combination of the flexible bitstring and the explicit node index; determining a number of different next hop nodes from the transit node to egress nodes specified in the first subtree; generating a copy of the packet for each of the different next hop nodes; modifying, in the packet header, a destination address of the copy of the packet to a first address of one of the different next hop nodes; modifying the first subtree in the MRH of the copy of the packet to indicate a second subtree, wherein the second subtree comprises the egress nodes branching from the one of the different next hop nodes; and sending the copy of the packet to the one of the different next next
  • the method further includes modifying, in the packet header, a source address of the copy of the packet to a second address of the transit node.
  • modifying the first subtree in the MRH of the copy of the packet to indicate the second subtree includes modifying at least one of a first pointer to a start of the second subtree or a second pointer to an end of the second subtree.
  • modifying the first subtree in the MRH of the copy of the packet to indicate the second subtree includes modifying a number of egress nodes in the second subtree.
  • determining the number of different next hop nodes is based on a node index forwarding table that includes a row for each egress node in the network, wherein the row includes a first node index of an egress node, an IPv6 address of a next hop to the egress node, a MAC address of the next hop, a second node index of the next hop, and a bit mask of a same next hop node, wherein the bit mask indicates egress nodes that have the same next hop node.
  • the flexible bitstring includes a flag bit, a start index, a bitstring size, and a bitstring
  • the packet header is layer 2 header, and wherein the source address and the destination address are MAC addresses.
  • the packet header is layer 3 header, and wherein the source address and the destination address are IPv6 addresses
  • a third aspect relates to a method for performing stateless multicasting in a network implemented by an egress node of the network.
  • the method includes receiving a packet comprising a packet header, a MRH, and a multicast packet; determining based on the MRH that the egress node is an endpoint of a P2MP path; decapsulating the multicast packet from the packet; and sending the multicast packet to an IP multicast forwarding module.
  • the packet header is a layer 2 header and the MRH has a header length of 0.
  • the packet header is a layer 3 header with a destination IPv6 address of the egress node.
  • a fourth aspect relates to a network device 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 network device to perform the method according to the first aspect or any implementation thereof.
  • a fifth aspect relates to a network device 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 network device to perform the method according to the second aspect or any implementation thereof.
  • a sixth aspect relates to a network device 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 network device to perform the method according to the third aspect or any implementation thereof.
  • FIG. 1 illustrates a network 100 according to an embodiment of the disclosure.
  • FIG. 2A illustrates a NIFT 200A according to an embodiment of the disclosure.
  • FIG. 2B illustrates a NIFT 200B that represents the data stored in a NIFT of Pl in FIG.
  • FTG. 3 A illustrates a P2MP tree encoding format 300 A according to an embodiment of the present disclosure.
  • FIG. 3B illustrates a P2MP tree encoding format 300B according to an embodiment of the present disclosure.
  • FIG. 3C illustrates a P2MP tree encoding format 300C according to an embodiment of the present disclosure.
  • FIG. 3D illustrates a P2MPtree encoding format 300D according to an embodiment of the present disclosure.
  • FIG. 3E illustrates a P2MP tree encoding format 300E according to an embodiment of the present disclosure.
  • FIG. 3F illustrates a P2MP tree encoding format 300F according to an embodiment of the present disclosure.
  • FIG. 3G illustrates a P2MPtree encoding format 300G according to an embodiment of the present disclosure.
  • FIG. 4 illustrates a packet 400 according to an embodiment of the present disclosure.
  • FIG. 5A illustrates a layer 2 packet 500 sent by PEI to Pl according to an embodiment of the present disclosure.
  • FIG. 5B illustrates a layer 2 packet 510 sent by Pl to P2 according to an embodiment of the present disclosure.
  • FIG. 5C illustrates a layer 2 packet 520 sent by P2 to PE2 from according to an embodiment of the present disclosure.
  • FIG. 6A illustrates a packet 600 in accordance with an embodiment of the present disclosure.
  • FTG. 6B illustrates a MRH 610 in accordance with an embodiment of the present disclosure.
  • FIG. 6C illustrates a MRH 630 in accordance with an embodiment of the present disclosure.
  • FIG. 7A illustrates a packet 700 in accordance with an embodiment of the present disclosure.
  • FIG. 7B illustrates a packet 710 sent by Pl to P2 according to an embodiment of the present disclosure.
  • FIG. 7C illustrates a packet 720 sent by Pl to P5 according to an embodiment of the present disclosure.
  • FIG. 7D illustrates a packet 730 sent by P5 to P4 according to an embodiment of the present disclosure.
  • FIG. 7E illustrates a packet 740 sent by P4 to PE4 according to an embodiment of the present disclosure.
  • FIG. 8 is a flowchart illustrating a process 800 for performing stateless multicasting in a network according to an embodiment of the present disclosure.
  • FIG. 9 is a flowchart illustrating a process 900 for performing stateless multicasting in a network according to an embodiment of the present disclosure.
  • FIG. 10 is a flowchart illustrating a process 1000 for performing stateless multicasting in a network according to an embodiment of the present disclosure.
  • FIG. 11 illustrates an apparatus 1100 configured to implement one or more of the methods disclosed herein according to an embodiment of the disclosure. DESCRIPTION OF EMBODIMENTS
  • BIER BIER Forwarding Tables
  • the present disclosure provides various embodiments of systems and methods for improving stateless multicasting.
  • the disclosed embodiments seeks to resolve one or more of the issues associated with BIER by utilizing a multicast routing header (MRH) with a point to multipoint (P2MP) path/tree encoded in the node indexes (i.e., indexes of the egress nodes) and flexible bit strings.
  • MMH multicast routing header
  • P2MP point to multipoint
  • FIG. 1 illustrates a network 100 according to an embodiment of the disclosure.
  • the network 100 is a service provider network.
  • a service provider network is a network that provides connectivity and services to customers, such as individuals, businesses, and other organizations.
  • Service provider networks are typically owned and operated by service providers, such as telecommunications companies, cable companies, and Internet Service
  • ISPs ISP Providers
  • the network 100 includes a plurality of network nodes such as, but not limited to, 10 provider edge (PE) nodes labeled PEI to PE 10 and 5 internal network nodes or transit nodes labeled Pl to P5.
  • PEI to PE 10 provide connectivity between the network 100 and other networks such as, but not limited to, customer networks, the Internet, or other service provider networks.
  • PEI to PE 10 are typically located at the edge of the network 100 and serve as demarcation points (i.e., are the ingress/egress nodes) between the network 100 and the other networks.
  • Atransit node is a node in the network (e.g., Pl to P5 in the network 100) that is used for routing a packet between PEI to PE 10.
  • PEI to PE 10 have node numbers or indexes 1 to 10 respectively and that Pl to P5 have node indexes 11 to 15 respectively. It should be noted that the node indexes assigned to PEI to PE10 and Pl to P5 in the following discussion are given as examples and may be different in practice.
  • every node in the network 100 has a node index forwarding table (NIFT) that comprises data that is used for forwarding packets in the network 100.
  • the NIFT is similar to a unicast forwarding table, but organized by exact match node index rather than longest match Internet Protocol (IP) address or the like.
  • IP Internet Protocol
  • the NIFT moods a row for the index of each egress node of the network 100 (e.g., PEl toPElO in FIG. 1).
  • the NIFT indicates the shortest interior gateway protocol (TGP) path to each egress, i.e., the next hop of the shortest path to each egress.
  • TGP shortest interior gateway protocol
  • the “next hop” refers to the next network node that a packet is forwarded to in order to reach its intended destination.
  • the row contains the index of the egress node, the IP version 6 (IPv6) address, the media access control (MAC) address, and the index of the next hop (NH) on the shortest path to the egress node, and a node index bit mask (BM) of the same next hop node (BM-SNH).
  • IPv6 IP version 6
  • MAC media access control
  • NH next hop
  • BM-SNH node index bit mask
  • the BM-SNH indicates egress nodes that have the same next hop node.
  • FIG. 2A illustrates a NIFT 200A according to an embodiment of the disclosure.
  • the NIFT 200 A represents the data stored in a NIFT of PEI in FIG. 1.
  • the NIFT 200A has 10 rows/entries for each of the egress nodes in the network 100 (i.e., PEI to PE 10).
  • the first column of the NIFT 200 A contains the node index 1 through 10 corresponding to PEI to PE10.
  • the second, third, and fourth column of the NIFT 200A contains the IPv6 address, the MAC address, and the node index of the next hop from the current node (in this case PEI) to the egress node indicated in first column of the NIFT 200 A.
  • the fifth column of the NIFT 200A contains the BM-SNH of the egress node in the first column. It should be noted that the NIFT 200Amay include other information not depicted such as, but not limited to, port number or interface used to forward a packet to the next hop. Additionally, in other embodiments, the particular arrangement of the columns of the NIFT 200A may be different.
  • the IPv6 address, the MAC address, the node index of the next hop from the current node, and BM-SNH are null because the NIFT 200 A is the NIFT of PEI and thus, there is no next hop from PEI to PEI.
  • the next hop from PEI to PE2 to PE9 is Pl. Therefore, the rows for PE2 to PE9 contain the IPv6 address, the MAC address, and the node index of Pl (which is 11 in the given example as described above in FIG. 1).
  • the rows for PE2 to PE9 contain the same BM-SNH of ObOl 11111110, which means that node indexes 2-9 (as indicated by “1” in bit positions 2-9 following “0b” in the bitmap) corresponding to PE2 to PE9 share the same next hop (Pl) as the next hop from PEI to any of PE2 to PE9.
  • the row for PE10 indicates that the next hop from PEI to PE10 is PE10 as shown in FIG. 1 , and PEI 0 is the next hop node for only PEI 0 from PEI as indicated by the BM-SNH for PE10.
  • FIG. 2B illustrates a NIFT 200B that represents the data stored in a NIFT of Pl in FIG. 1. Similar to the NIFT 200A, the NIFT 200B has 10 rows/entries for each of the egress nodes in the network 100 (i.e., PEI to PE10). The first column of the NIFT 200B contains the node index 1 through 10 corresponding to PEI to PE 10. The second, third, and fourth column of the NIFT 200B contains the IPv6 address, the MAC address, and the node index of the next hop from the current node (in this case Pl) to the egress node indicated in first column of the NIFT 200B. The fifth column of the NIFT 200B contains the BM-SNH of the egress node in the first column.
  • the next hop from Pl to either PEI or PE 10 is PEI
  • the next hop from Pl to either PE2 or PE3 is P2
  • the next hop from Pl to either PE4, PE5, PE6, or PE7 is P5
  • the next hop from Pl to PE8 is PE8, and the next hop from Pl to PE9 is PE9.
  • PEI receives a packet from a traffic source CE1 that is to be multicasted out of the network 100 at egress nodes PE2, PE3, PE4, and PE5.
  • PEI determines the next hop node to send the packet to PE2, PE3, PE4, and PE5 using the NIFT 200A in FIG. 2A.
  • PEI For each different next hop node (in this example, there is only 1 next hop node, which is Pl), PEI encapsulates the packet to generate an encapsulated packet that includes a MRH that specifies a P2MP tree from ingress PEI towards egresses PE2, PE3, PE4, and PE5 using the node indices of PE2, PE3, PE4, and PE5, which are 2, 3, 4 and 5 respectively.
  • the encapsulated packet is then transmitted along the shortest path tree to the egress nodes specified in the P2MP tree (i.e., PE2, PE3, PE4, and PE5 in the given example).
  • Pl receives the encapsulated packet, using the NTFT 200B in FIG.
  • Pl obtains the index of each of the egress nodes and determines the address of the next hop node. As shown in FIG. 2B, there are two different next hop nodes for PE2, PE3, PE4, and PE5. The next hop node for PE2 and PE3 is P2, and the next hop node for PE4 and PE5 is P5. For each of the different next hop nodes, Pl sends a copy of the encapsulated packet that has a modified MRH indicating the new P2MP subtree for the respective next hop node.
  • P 1 sends a copy of the encapsulated packet to P2 with an MRH indicating a P2MP subtree of egress nodes PE2 and PE3, and P 1 sends a copy of the encapsulated packet to P5 with an MRH indicating a P2MP subtree of egress nodes PE4 and PE5.
  • 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.
  • FIG. 3 A illustrates a P2MP tree encoding format 300A according to an embodiment of the present disclosure.
  • PEI encodes the P2MP path/tree from ingress PEI to egresses PE2, PE3, PE4 and PE5 using a node index field of 1 byte for each node index in the P2MP tree.
  • node indexes 2-5 corresponding to egress nodes PE2, PE3, PE4 and PE5 respectively are encoded in fields 304-310.
  • the P2MP tree encoding format 300A includes a first field 302, also 1 byte, that indicates the number of node indexes in the P2MP tree.
  • FIG. 3B illustrates a P2MP tree encoding format 300B according to an embodiment of the present disclosure.
  • the indexes of egress nodes PE2 and PE3 are 2 and 3 respectively, each of which is encoded in one byte, but the indexes of egress nodes PE4 and PE5 are not 4 and 5 as given above, but instead are 2004 and 2005 respectively, each of which is encoded in one and half bytes (i.e., 12 bits).
  • PEI encodes field 320, which occupies one byte, with the number of node indexes in the P2MP tree that also occupy 1 byte (in this case, 2 for PE2 and PE3).
  • the node indexes for PE2 and PE3 are then inserted in the fields 322 and 324 respectively.
  • field 326 which occupies 2 bytes
  • PEI encodes the number of node indexes in the P2MP tree that occupy 1.5 bytes/12 bits (in this case, 2 for PE4 and PE5).
  • PEI then encodes the indexes for PE4 and PE5 (i.e., 2004 and 2005) in the fields 328 and 330 respectively.
  • the encoding of the P2MP tree uses 8 bytes.
  • BIER requires 2 bit strings of 256 bits each to encode the same P2MP tree, which occupies 64 bytes (i.e., 2 x 256 bits).
  • FIG. 3C illustrates a P2MP tree encoding format 300C according to an embodiment of the present disclosure.
  • the indexes of egress nodes PE2 and PE3 are 2 and 3 respectively, each of which is encoded in one byte, but the indexes of egress nodes PE4 and PE5 are not 4 and 5 as given above, but instead are 30004 and 30005 respectively, each of which is encoded in 2 bytes (i.e., 16 bits).
  • PEI encodes field 340, which occupies one byte, with the number of node indexes in the P2MP tree that also occupy 1 byte (in this case, 2 for PE2 and PE3).
  • the node indexes for PE2 and PE3 are then inserted in the fields 342 and 344 respectively.
  • field 346 which occupies 2 bytes, PEI encodes the number of node indexes in the P2MP tree that occupy 1.5 bytes/12 bits (in this case, 0).
  • field 348 which occupies 2 bytes, PEI encodes the number of node indexes in the P2MP tree that occupy 2 bytes (in this case, 2 for PE4 and PE5).
  • PEI then encodes the indexes for PE4 and PE5 (i.e., 30004 and 30005) in the fields 350 and 352 respectively
  • P2MP tree encoding format 300C the encoding of the P2MP tree uses 11 bytes.
  • BIER requires 2 bit strings to encode the same P2MP tree, which occupies 64 bytes (i.e., 2 x 256 bits).
  • FIG. 3D illustrates a P2MP tree encoding format 300D according to an embodiment of the present disclosure.
  • each egress node index for PE2, PE3, PE4, and PE5 occupies a fix 2 byte field comprising a B flag field 360 of 1 bit followed by a node index field 362 of 15 bits.
  • the B flag field 360 is used to indicate whether an egress node index is encoded using its node index number or by a bit string that encodes multiple node indexes.
  • the B flag field 360 is set to 0 for each of the node indexes corresponding to PE2 to PE5.
  • the node index field 362 is included using the node index/number (e g., node index 2, 3, 4, and 5 corresponding to PE2 to PE5 respectively) as shown in FIG. 3D.
  • the node index/number e g., node index 2, 3, 4, and 5 corresponding to PE2 to PE5 respectively.
  • the encoding of the P2MP tree uses 8 bytes.
  • BIER requires 1 bit string to encode the same P2MP tree, which occupies 32 bytes (i.e., 256 bits).
  • FIG. 3E illustrates a P2MP tree encoding format 300E according to an embodiment of the present disclosure.
  • the index of egress node PE2 is 2 and the indexes of egress nodes PE3, PE4, and PE5 are 30003, 30004 and 30005 respectively.
  • P2MP tree encoding format 300E 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).
  • the B flag field 370 is set to 0.
  • B flag field 370 When B flag field 370 is 0, there is one field 372 of a given length (e.g., 15 bits) following the B flag field 370.
  • Field 372 contains a node index.
  • the node index of PE2 i.e., 2 is encoded in field
  • B flag field 376 When B flag field 376 is set to 1, it indicates that a bit string is being used to encode multiple node indexes.
  • the B flag field 376 when the B flag field 376 is 1, there are three fields following the B flag field 376: a start index (Startindex) field 378 of 15 bits, a size of bit string (S- BitString) field 380 of 1 byte, and a bit string (BitString) field 382 (variable size).
  • the Startindex field 378 contains a start index.
  • the S-BitString field 380 indicates the size of the BitString field 382 in a unit such as byte.
  • the BitString field 382 contains a bit string, where each bit with value of 1 in the string indicates a node index, which is the start index indicated in Startindex field 378 plus the bit number.
  • the Startindex field 378 is encoded with value 30003 (i.e., PE3’s node index acting as the starting index)
  • the S-BitString field 380 is encoded with the value of 1 to indicate that the BitString field 382 is 1 byte
  • the BitString field 382 is encoded with the bit string 11000000 indicating that there are two additional node indexes (i.e., two bits with value of 1).
  • the value in the Startindex field 378 (i.e., 30003) is added to the bit position that are 1.
  • the P2MP tree encoding format 300E illustrates an embodiment where the node indexes for PE2, PE3, PE4, and PE5 can be encoded using a combination of a direct node index and a flexible bitstring.
  • FIG. 3F illustrates a P2MP tree encoding format 300F according to an embodiment of the present disclosure.
  • the indexes of egress nodes PE2-PE5 are 30002, 30003, 30004 and 30006 respectively.
  • P2MP tree encoding format 3 OOF illustrates an encoding tree for PE2 to PE5 using a flexible bit string.
  • the B flag field 390 is set to 1 indicating that a bit string is being used to encode multiple node indexes.
  • the Startindex field 392 is encoded with value 30002 (i.e., PE2’s node index)
  • the S-BitString field 394 is encoded with the value of 1 to indicate that the BitString field 396 is 1 byte
  • the BitString field 396 is encoded with the bit string 11010000 indicating that there are three additional node indexes.
  • the value in the Startindex field 394 i.e., 30002
  • the value in the Startindex field 394 is added to the bit positions that are 1.
  • P2MP tree encoding format 3 OOF the encoding of the P2MP tree uses 4 bytes.
  • BIER requires 32 bytes to encode the same P2MP tree.
  • FIG. 3G illustrates a P2MP tree encoding format 300G according to an embodiment of the present disclosure.
  • P2MP tree encoding format 300G is similar to P2MP tree encoding format 300F, except in this embodiment, the value in the Startindex field 393 is not used to indicate a node index, but only acts as the start index.
  • the B flag field 391 is set to 1 indicating that a bit string is being used to encode multiple node indexes.
  • the StartTndex field 393 is encoded with value 30001, which is not a node index
  • the S-BitString field 395 is encoded with the value of 1 to indicate that the BitString field 397 is 1 byte
  • the BitString field 397 is encoded with the bit string 11101000 indicating that there are four node indexes.
  • the value in the Startindex field 393 i.e., 30001
  • the first (1) bit, the second (2) bit, the third (3) bit and the fifth (5) bit in the BitString field 397 have values of 1.
  • FIG. 4 illustrates a packet 400 according to an embodiment of the present disclosure.
  • the packet 400 includes a layer 2 header 402, a MRH 404, and a layer 3 406.
  • the layer 3 406 includes an IP multicast packet, which is a packet that is sent from one device to many devices simultaneously in a network.
  • the layer 2 header 402 includes a MAC address of a destination node, a MAC address of a source node, and a type field.
  • the layer 2 destination address and source address are within a predetermined range.
  • the destination MAC address and the source MAC address are between 01-00-5E 80-00-00 and 01-00-5E 8F-FF-
  • the type field in the layer 2 header 402 must have a value assigned exclusively for stateless multicasting as disclosed herein (e.g., the values assigned for other purposes such as 0x8847 and 0x8848 used for Multiprotocol Label Switching (MPLS) could not be used for stateless multicasting because this address range is also used by MPLS).
  • MPLS Multiprotocol Label Switching
  • MAC addresses from unused MAC multicast address ranges such as 01-00-5E A0- 00-00 to 01-00-5E AF-FF-FF are used.
  • the type field in the layer 2 header 402 is TBD.
  • MAC addresses are normal MAC addresses and the type field in the layer 2 header 402 has a value assigned exclusively for stateless multicasting as disclosed herein.
  • the MRH 404 is referred to as a layer 2.5 (L2.5 for short) header because the MRH 404 is located between the layer 2 header 402 and layer 3 406.
  • the MRH 404 includes a HL (short for header length) field and a sub-tree field.
  • the HL field has a value indicating the length of the MRH 404 excluding HL field in the MRH 404.
  • the sub-tree field comprises an encoding of a sub-tree that indicates the index of the egress nodes in which to send the IP multicast packet.
  • the sub-tree may be encoded using any of the P2MP tree encoding formats described in FIGS. 3A-3G.
  • FIG. 5A illustrates a layer 2 packet 500 sent by PEI to Pl according to an embodiment of the present disclosure.
  • PEI constructs the layer 2 packet 500 for each subtree and sends the layer 2 packet 500 containing a MRH 504 and the IP multicast packet to the next hop along the subtree.
  • 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 NIFT as described in FIG. 2A.
  • PEI gets the MAC addresses of the next hops to the egress nodes using NIFT 200A with the node indexes of the egress nodes, which are 2, 3, 4 and 5. As shown in FIG. 2 A, the MAC addresses of the next hops are all the same (i.e., the MAC address of Pl) for node indexes 2, 3, 4 and 5. Thus, there is only one subtree from PEI via Pl towards PE2 to PE5. [0081] Therefore, in layer 2 packet 500, PEI sets the destination address (DA) of the layer 2 header 502 to the MAC address of Pland the source address(SA) of the layer 2 header 502 to the MAC address of PEI. In an embodiment, the type of the layer 2 header 502 is set to a value to be determined (TBD) by Internet Assigned Numbers Authority (LANA).
  • TDD Internet Assigned Numbers Authority
  • PEI encodes the P2MP tree from PEI towards PE2 to PE5 in the MRH 504 using the P2MP tree encoding format 300 A in FIG. 3 A.
  • PEI sets HL in the MRH 504 to indicate the size of space for storing the subtree (i.e., 5 bytes).
  • PEI then sends the layer 2 packet 500 to Pl.
  • FIG. 5B illustrates a layer 2 packet 510 sent by Pl to P2 according to an embodiment of the present disclosure.
  • Pl determines whether the layer 2 packet 500 contains an MRH as described in the present disclosure (e.g., the MRH 504) by checking the type field in the layer 2 header 502 and/or the range of the DA and/or SA in the layer 2 packet 500.
  • Pl determines the number of branch/ subtree from Pl to the egress nodes specified in the subtree in the MRH 504 of the layer 2 packet 500 (i.e., egress nodes PE2-PE5) using the NIFT 200B in FIG. 2B locally stored by Pl.
  • egress nodes PE2 and PE3 share the same next hop, which is P2, and egress nodes PE4 and PE5 share the same next hop, which is of P5.
  • Pl constructs a layer 2 packet copy for each of these two subtree and sends the packet copy to the next hop along the subtree.
  • Pl constructs the layer 2 packet 510, as shown in FIG. 5B, to send to P2 for egress nodes PE2 and PE3.
  • Pl sets DA in the layer 2 header 512 to the MAC address of P2 and SA to the MAC address of Pl.
  • Pl builds the MRH 514 of the layer 2 packet 510 by encoding the subtree from P2 to PE2 and PE3 using the encoding of the subtree received in the layer 2 packet 500.
  • Pl sets HL in the MRH 514 to the size of space for storing the subtree (i.e., 3 bytes as shown in FIG. 5B).
  • Pl then sends the layer 2 packet 510 with a copy of the IP multicast packet 516 to P2.
  • Pl constructs and sends a similar packet (with a different DA and MRH) to P5.
  • FIG. 5C illustrates a layer 2 packet 520 sent by P2 to PE2 from according to an embodiment of the present disclosure.
  • P2 determines whether the layer 2 packet 510 contains an MRH as described in the present disclosure by checking the type field in the layer 2 header 512 and/or the range of the DA and/or SA in the layer 2 packet 510.
  • P2 determines the number of branch/ subtree from P2 to the egress nodes specified in the subtree in the MRH 514 of the layer 2 packet 510 (i.e., egress nodes PE2-PE3) using the NFFT locally stored at P2. As shown in FIG.
  • P2 duplicates the IP multicast packet and sends a copy of the IP multicast packet to each of PE2 and PE3.
  • P2 constructs the layer 2 packet 520 shown in FIG. 5C with a DA set to the MAC address of PE2 and an SA set to the MAC address of P2.
  • P2 sends the layer 2 packet 520 with the copy of the IP multicast packet 526 to PE2.
  • FIG. 6A illustrates a packet 600 in accordance with an embodiment of the present disclosure.
  • the packet 600 is a layer 3 IPv6 packet that includes an IPv6 header 602, a layer 3 MRH 604, and an IP multicast datagram 606.
  • the IPv6 header 602 includes a Next Header field that indicates the next header in the packet 600 following the IPv6 header 602, which, in this example, is the layer 3 MRH 604.
  • the IPv6 header 602 also includes an IPv6 address of a SA and an IPv6 address of a DA.
  • the layer 3 MRH 604 also includes a Next Header field, a Hdr Ext Len field, a Routing Type field, a Segment Left field, and an encoding of a multicast subtree.
  • the IP multicast datagram 606 includes an IP datagram header and data carried in a payload of the IP multicast datagram 606.
  • FIG. 6B illustrates a MRH 610 in accordance with an embodiment of the present disclosure.
  • the MRH 610 is an example embodiment of the MRH 604 in packet 600 in FIG. 6A.
  • the MRH 610 includes an Next Header field 612, a Hdr Ext Len field 614, a Routing Type field 616, a Segment Left field 618, and a subtree encoding field 620.
  • the Next Header field 612 is an 8 bit field that stores a value indicating the IP datagram header of the IP multicast datagram 606 in FIG. 6A.
  • the Hdr Ext Len field 614 is an 8 bit field that stores a value indicating the length of the MRH 610 in a unit of 64 bits (i.e., 8 bytes) excluding the first 8 bytes.
  • the Routing Type field 616 is an 8 bit field that stores a value (to be determined (TBD) by the IAN A) indicating that the routing header is a MRH type header.
  • the Segment Left field 618 is an 8 bit field that stores a value indicating the size of the sub-tree remaining (e.g., may be the entire subtree or a remaining portion of the subtree encoded in the Subtree Encoding field 620).
  • the Subtree Encoding field 620 stores an encoding of a multicast subtree.
  • the multicast subtree may be encoded using any of the P2MP tree encoding formats described in FIGS. 3A-3G.
  • FIG. 6C illustrates a MRH 630 in accordance with an embodiment of the present disclosure.
  • the MRH 630 is an example embodiment of the MRH 604 in packet 600 in FIG. 6A.
  • the MRH 630 includes an Next Header field 632, a Hdr Ext Len field 634, a Routing Type field 636, a Segment Left field 638, a Subtree End (SE) or number of egresses (N-Eg) field 640, and a subtree encoding field 642.
  • SE Subtree End
  • N-Eg number of egresses
  • the Segment Left field 638 is an 8 bit field that stores a value that acts as a pointer pointing to the top of the sub-tree remaining.
  • the SE or N-Eg field 640 either stores a value that acts as a pointer pointing to the end of the subtree (i.e., SE) or stores a value that indicating the number of egress nodes in the sub-tree (i.e., N-Eg).
  • the Subtree Encoding field 642 stores an encoding of a multicast subtree.
  • the multicast subtree may be encoded using any of the P2MP tree encoding formats described in FIGS. 3A-3G.
  • FIG. 7A illustrates a packet 700 in accordance with an embodiment of the present disclosure.
  • the packet 700 includes an IPv6 header 702, a MRH 704, and an IP multicast datagram 706.
  • the IPv6 header 702 and the IP multicast datagram 706 are the same as the IPv6 header 602 and the IP multicast datagram 606 of packet 600 in FIG. 6 A.
  • the MRH 704 is the same as the MRH 630 in FIG. 6C.
  • the packet 700 represents an example of layer 3 IPv6 packet that is constructed by PEI having a P2MP path/tree from PEI towards PE2 to PE5 in FIG.
  • PEI when PEI receives an IP multicast packet to be transmitted by the P2MP path/tree from PEI towards PE2 to PE5, PEI constructs a layer 3 packet for each subtree and sends the layer 3 packet containing a MRH and the IP multicast packet to the next hop along the subtree.
  • 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 NIFT 200A as described in FIG. 2A.
  • PEI gets the IPv6 addresses of the next hops to the egress nodes using NIFT 200 A with the node indexes of the egress nodes, which are 2, 3, 4 and 5.
  • the IPv6 addresses of the next hops are all the same (i.e., the IPv6 address of Pl) for node indexes 2, 3, 4 and 5.
  • the IPv6 address of Pl there is only one subtree from PEI via Pl towards PE2 to PE5.
  • PEI sets the DA in the IPv6 header 702 to the IPv6 address of Pland sets the SA to the IPv6 address of PEI.
  • the MRH 704 encodes the P2MP tree from PEI towards PE2 to PE5 using the P2MP tree encoding format 300D in FIG. 3D.
  • PEI sets the Segment Left (SL) field in the MRH 704 to 8, which acts as a pointer pointing to the top of the subtree, and sets the SE to 0 to indicate the end of the sub-tree.
  • PEI sets the N-Eg field in the MRH 704 to 4 to indicate the number of egress nodes in the subtree. PEI then sends the packet 700 to Pl.
  • Pl determines whether the packet 700 next header is a MRH by determining whether the next header specified in the IPv6 header of the packet 700 is a routing header and if so, determining whether the routing type in the routing header is a value (TBD) indicating that the routing header is a MRH.
  • TDB a value indicating that the routing header is a MRH.
  • Pl duplicates the packet 700 for each subtree from Pl to the egress nodes specified in the subtree encoded in the packet 700 (i.e., egress nodes PE2-PE5).
  • the number of subtrees from Pl to PE2- PE5 is determined by the number of different next hop nodes from Pl to PE2-PE5.
  • Pl makes this determination using the locally stored NIFT 200B as described in FIG. 2B.
  • the next hop node for PE2 and PE3 is P2
  • the next hop node for PE4 and PE5 is P5.
  • Pl For each of the different next hop nodes, Pl generates a copy of the packet 700 and modifies the IPv6 header and MRH for each corresponding next hop node.
  • FIG. 7B illustrates a packet 710 sent by Pl to P2 according to an embodiment of the present disclosure.
  • Pl sets the DA in the IPv6 header 712 of the packet 710 to the IPv6 address of P2.
  • Pl updates the MRH 714 in the packet 710 based on the encoding of the subtree received in the packet 700 by keeping the SL at 8 to point to the first index in the subtree encoding and changing SE from 0 to 4 to indicate the end of the subtree (i.e , the subtree remaining is PE2 and PE3).
  • Pl sets the N-Eg to 2 to indicate the number of egress nodes in the subtree (i.e., PE2 and PE3). Pl then sends the packet 710 comprising the IP multicast packet 716 to P2.
  • FIG. 7C illustrates a packet 720 sent by Pl to P5 according to an embodiment of the present disclosure.
  • Pl sets the DA in the IPv6 header 722 of the packet 720 to the IPv6 address of P5.
  • Pl updates the MRH 724 in the packet 720 based on the encoding of the subtree received in the packet 710 by setting SL to 4 to point to the first index in the subtree encoding and setting SE to 0 to indicate the end of the subtree (i.e., the subtree remaining is PE4 and PE5).
  • Pl sets the N-Eg to 2 to indicate the number of egress nodes in the subtree (i.e., PE4 and PE5). Pl then sends the packet 720 comprising the IP multicast packet 726 to P5.
  • P5 determines whether the packet 720 next header is a MRH by determining whether the next header specified in the IPv6 header of the packet 720 is a routing header and if so, determining whether the routing type in the routing header is a value (TBD) indicating that the routing header is a MRH.
  • TDB a value indicating that the routing header is a MRH.
  • P5 duplicates the packet 720 for each subtree from P5 to the egress nodes specified in the subtree encoded in the packet 720 (i.e., PE4 and PE5).
  • the number of subtrees from P5 to PE4 and PE5 is determined by the number of different next hop nodes from P5 to PE4 and PE5.
  • P5 makes this determination using its locally stored NIFT. As shown in FIG. 1, the next hop node from P5 to PE4 and PE5 is P4.
  • FIG. 7D illustrates a packet 730 sent by P5 to P4 according to an embodiment of the present disclosure.
  • P5 sets the DA in the IPv6 header 732 of the packet 730 to the IPv6 address of P4.
  • P5 updates the MRH 734 in the packet 730 based on the encoding of the subtree received in the packet 720 by setting SL to 4 to point to the first index in the subtree encoding and setting SE to 0 to indicate the end of the subtree (i.e., the subtree remaining is still PE4 and PE5).
  • P5 sets the N-Eg to 2 to indicate the number of egress nodes in the subtree (i.e., PE4 and PE5). P5 then sends the packet 730 comprising the IP multicast packet 736 to P4.
  • P4 determines whether the packet 730 next header is a MRH by determining whether the next header specified in the IPv6 header of the packet 730 is a routing header and if so, determining whether the routing type in the routing header is a value (TBD) indicating that the routing header is a MRH.
  • TDB a value indicating that the routing header is a MRH.
  • P4 duplicates the packet 730 for each subtree from P4 to the egress nodes specified in the subtree encoded in the packet 730 (i.e., PE4 and PE5).
  • the number of subtrees from P4 to PE4 and PE5 is determined by the number of different next hop nodes from P4 to PE4 and PE5.
  • P4 makes this determination using its locally stored NIFT. As shown in FIG. 1, the next hop node from P4 to PE4 is PE4 and the next hop node from P4 to PE5 is PE5. Thus, in one embodiment, P4 duplicates the packet 730 to be able to send a copy to each of PE4 and PE5.
  • FIG. 7E illustrates a packet 740 sent by P4 to PE4 according to an embodiment of the present disclosure.
  • P4 sets the DA in the IPv6 header 742 of the packet 740 to the IPv6 address of PE4.
  • P4 updates the MRH 744 in the packet 740 by setting SL to 0 to indicate that the MRH 744 does not include a subtree encoding.
  • SE or N-Eg field is null (i.e., blank) P4 then sends the packet 740 comprising the IP multicast packet 746 to PE4.
  • 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 an ingress node of the network such as PEI in FIG. 1 .
  • the ingress node receives a first packet from a traffic source.
  • the ingress node determines a P2MP path for forwarding the first packet.
  • 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 (e.g., PEI in FIG. 1).
  • PCE path computation element
  • a PCE is a network entity responsible for calculating and determining the optimal paths for traffic flows in a network.
  • the ingress node determines a next hop node for each subtree of the P2MP path branching from the ingress node based on a NIFT (e.g., NIFT 200Ain FIG. 2A).
  • a NIFT e.g., NIFT 200Ain FIG. 2A
  • the ingress node at step 808, encapsulates the first packet to generate an encapsulated packet for each subtree of the P2MP path branching from the ingress node to the egress nodes in the P2MP path.
  • the number of subtrees of the P2MP path branching from the ingress node to the egress nodes in the P2MP path is determined by the number of different next hop nodes from the ingress node to the egress nodes.
  • Encapsulating a packet refers to the process of adding additional information (e.g., adding new protocol headers) to the original data packet (copy) to enable the packet to be properly handled or routed across a network.
  • the ingress node encodes a subtree of egress nodes in a MRH of the encapsulated packet using a flexible bitstring, an explicit node index, or a combination of the flexible bitstring and the explicit node index as described in FIGS. 3A-3G.
  • the MRH may be a layer 2.5 header or a layer 3 header as disclosed herein.
  • the MRH includes a header type, a header length, a first pointer to a start of the subtree, and a second pointer to an end of the subtree.
  • the MRH includes a header type, a header length, and a number of egress nodes in the subtree.
  • An explicit node index is a unique identifier or numerical value assigned to each node in a network.
  • a flexible bitstring is an encoding format that enables encoding of multiple node indexes using a starting index and a bitstring as described in FIGS. 3E-3G.
  • encoding the subtree includes encoding a number of node indexes of a certain size preceding the node indexes of the certain size in the subtree.
  • the ingress node sends the encapsulated packet to the next hop node for each subtree of the P2MP path.
  • FIG. 9 is a flowchart illustrating a process 900 for performing stateless multicasting in a network according to an embodiment of the present disclosure.
  • the process 900 is implemented by a transit node of the network such as Pl in FIG. 1.
  • the transit node receives a packet comprising a packet header, a MRH, and a multicast packet.
  • the MRH includes a first subtree encoded using a flexible bitstring, an explicit node index, or a combination of the flexible bitstring and the explicit node index as described in FIGS. 3E-3G.
  • the flexible bitstring includes a flag bit, a start index, a bitstring size, and a bitstring.
  • the MRH may be a layer 2.5 header or a layer 3 header as disclosed herein.
  • the transit node determines a number of different next hop nodes from the transit node to egress nodes specified in the first subtree using a NIFT (e.g., NIFT 200B in FIG. 2B).
  • determining the number of different next hop nodes is based on a NIFT that includes a row for each egress node in the network. Each row includes a first node index of an egress node, an IPv6 address of a next hop to the egress node, a MAC address of the next hop, a second node index of the next hop, and a bit mask of a same next hop node. The bit mask indicates egress nodes that have the same next hop node.
  • the transit node at step 906, generates a copy of the packet for each of the different next hop nodes.
  • the transit node modifies, in the packet header, a destination address of the copy of the packet to a first address of one of the different next hop nodes.
  • the transit node also modifies a source address in the packet header of the copy of the packet to an address of the transit node.
  • the transit node modifies the first subtree in the MRH of the copy of the packet to indicate a second subtree.
  • the second subtree includes the egress nodes branching from the one of the different next hop nodes.
  • modifying the first subtree in the MRH of the copy of the packet to indicate the second subtree includes modifying at least one of a first pointer to a start of the second subtree or a second pointer to an end of the second subtree.
  • modifying the first subtree in the MRH of the copy of the packet to indicate the second subtree includes modifying a number of egress nodes in the second subtree.
  • the transit node sends the copy of the packet to the one of the different next hop nodes. For example, as described above, after receiving the packet from PEI and determining that there are two different next hop nodes for the egress nodes PE2, PE3, PE4, and PE5, which are P2 and P5, Pl (i.e., the transit node) sends a copy of the encapsulated packet to P2 with an MRH indicating a P2MP subtree of egress nodes PE2 and PE3, and Pl sends a copy of the encapsulated packet to P5 with an MRH indicating a P2MP subtree of egress nodes PE4 and PE5. [0108] FIG.
  • the process 1000 is implemented by an egress node of the network such as PE2 in FIG. 1.
  • the egress node receives a packet comprising a packet header, a multicast routing header (MRH), and a multicast packet, wherein the MRH indicates that the egress node is an endpoint of a point to multipoint (P2MP) path.
  • the MRH may be a layer 2.5 header or a layer 3 header as disclosed herein.
  • the egress node determines based on the MRH that the egress node is an endpoint of a P2MP path.
  • the egress node determines that the egress node is an endpoint of a P2MP path. In another embodiment, the egress node determines that the egress node is an endpoint of a P2MP path when the MRH has a header length of 0.
  • the egress node decapsulates the multicast packet from the packet. Decapsulating refers to the process of removing the encapsulation or outer headers of a packet to reveal the original payload or data (i.e., the multicast packet) contained within the packet.
  • the egress node sends the multicast packet to an IP multicast forwarding module.
  • the Internet IP multicast forwarding module is a component of a network device or router that is configured to forward multicast traffic within an IP network.
  • FIG. 11 illustrates an apparatus 1100 configured to implement one or more of the methods disclosed herein according to an embodiment of the disclosure.
  • the apparatus 1100 may represent an ingress node, transit node, or egress node as described herein (e.g., PE1-PE10 orPl-P5 of network 100 in FIG. 1).
  • the apparatus 1100 comprises ingress ports 1110 and receiver units (Rx) 1120 for receiving data packets, one or more processors, logic units, or central processing units (CPUs) 1130 for processing data packets, transmitter units (TX) 1140 and egress ports 1150 for transmitting data packets, and a memory 1160.
  • Rx receiver units
  • CPUs central processing units
  • the one or more processors 1130 are implemented by any suitable combination of hardware, middleware, and firmware.
  • the one or more processors 1130 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 1130 are in communication with the ingress ports 1110, receiver units 1120, transmitter units 1140, egress ports 1150, and memory 1160.
  • the memory 1160 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 1160 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).
  • the memory 1160 comprises a stateless multicast module 1170.
  • the stateless multicast module 1170 comprises executable instructions and data configurations that when executed by the one or more processors 1130 implement the disclosed embodiments as described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé permettant d'effectuer une multidiffusion sans état dans un réseau mis en œuvre par un nœud d'entrée du réseau. Le procédé consiste à recevoir, par le nœud d'entrée, un premier paquet provenant d'une source de trafic. Le nœud d'entrée détermine un trajet point à multipoint (P2MP) pour renvoyer le premier paquet. Le nœud d'entrée détermine un nœud de saut suivant pour chaque sous-arbre du trajet P2MP se ramifiant à partir du nœud d'entrée sur la base d'une table de renvoi d'indice de nœud. Le nœud d'entrée encapsule le premier paquet pour générer un paquet encapsulé pour chaque sous-arbre. Le nœud d'entrée code un sous-arbre de nœuds de sortie dans un en-tête de routage de multidiffusion (MRH) du paquet encapsulé à l'aide d'une chaîne de bits flexible, d'un indice de nœud explicite, ou d'une combinaison de la chaîne de bits flexible et de l'indice de nœud explicite. Le nœud d'entrée envoie le paquet encapsulé au nœud de saut suivant pour chaque sous-arbre.
PCT/US2023/024663 2022-06-08 2023-06-07 Multidiffusion sans état avec indice de nœud et chaîne de bits flexible WO2023168134A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263350230P 2022-06-08 2022-06-08
US63/350,230 2022-06-08

Publications (1)

Publication Number Publication Date
WO2023168134A1 true WO2023168134A1 (fr) 2023-09-07

Family

ID=87136416

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/024663 WO2023168134A1 (fr) 2022-06-08 2023-06-07 Multidiffusion sans état avec indice de nœud et chaîne de bits flexible

Country Status (1)

Country Link
WO (1) WO2023168134A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021257141A1 (fr) * 2020-06-16 2021-12-23 Futurewei Technologies, Inc. Trajet point à multipoint de routage de segment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021257141A1 (fr) * 2020-06-16 2021-12-23 Futurewei Technologies, Inc. Trajet point à multipoint de routage de segment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CHEN M MCBRIDE ET AL: "Multicast using Multicast Routing Header", no. 1, 7 March 2022 (2022-03-07), pages 1 - 23, XP015150688, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-chen-pim-mrh6-01> *
GENG Z LI J XIE HUAWEI TECHNOLOGIES X: "IPv6 Multicast Source Routing Traffic Engineering", 25 October 2021 (2021-10-25), pages 1 - 17, XP015148566, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-geng-msr6-traffic-engineering-00> *

Similar Documents

Publication Publication Date Title
US11838396B2 (en) Ethernet virtual private network using segment routing
US11374862B2 (en) Packet sending and processing method and apparatus, PE node, and node
US20230121236A1 (en) Segment routing point to multipoint path
US20080159285A1 (en) Method and apparatus for improved multicast routing
US20090135833A1 (en) Ingress node and egress node with improved packet transfer rate on multi-protocol label switching (MPLS) network, and method of improving packet transfer rate in MPLS network system
CN113726667B (zh) 一种反向路径转发rpf检查方法及装置
WO2023168134A1 (fr) Multidiffusion sans état avec indice de nœud et chaîne de bits flexible
US20230143419A1 (en) Segment Routing MPLS Point To Multipoint Path
WO2023158889A2 (fr) Multidiffusion sans état avec sauts mobiles
US20240146642A1 (en) BIER-TE Encapsulation With Multiple Sets
WO2023164320A1 (fr) Arbre de multidiffusion à codage optimal utilisant un numéro de liaison et un bit
EP4300913A1 (fr) Procédé et dispositif d&#39;envoi de paquets de multidiffusion
WO2023196689A2 (fr) Multidiffusion au mieux sans état optimal
US20230261969A1 (en) Stateless and secure packet forwarding
WO2023147477A1 (fr) En-tête de routage de multidiffusion utilisant un numéro de liaison
US20240163200A1 (en) BGP for BIER-TE Path
WO2023288146A2 (fr) Multidiffusion de routage de segment compact pour ipv6
US20230135615A1 (en) Mac-based routing
WO2023025171A1 (fr) Procédé et dispositif de communication
US10924395B2 (en) Seamless multipoint label distribution protocol (mLDP) transport over a bit index explicit replication (BIER) core
US20230283558A1 (en) Bit Index Explicit Replication Traffic Engineering Fast Reroute
WO2024010954A1 (fr) Distribution de numéro de liaison pour multidiffusion
WO2023196690A1 (fr) Multidiffusion pour ingénierie de trafic sans état optimale
WO2023177927A9 (fr) Distribution d&#39;indice de nœud pour multidiffusion
WO2022115882A2 (fr) Extensions igp pour bier-te

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23738296

Country of ref document: EP

Kind code of ref document: A1