CN114465920A

CN114465920A - Method, device and system for determining corresponding relation

Info

Publication number: CN114465920A
Application number: CN202011350079.2A
Authority: CN
Inventors: 董甲甲; 谢经荣; 沙李; 李良格; 侯鹏; 姚俊达
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-11-09
Filing date: 2020-11-26
Publication date: 2022-05-10
Anticipated expiration: 2040-11-26
Also published as: CN114465946B; CN114465920B; CN114465946A

Abstract

The application provides a method, a device and a system for determining a corresponding relation, wherein the method comprises the following steps: acquiring a topology identifier and corresponding equipment; the first network device obtains a first corresponding relationship, where the first corresponding relationship includes multicast source group (S, G) information and at least one next hop, and any one of the at least one next hop is a device corresponding to the topology identifier obtained through calculation. The technical scheme provided by the application can meet the SLA of the multicast service.

Description

Method, device and system for determining corresponding relation

The present application claims priority of chinese patent application entitled "a method and apparatus for establishing BIER tunnel" filed by the chinese patent office on 09.11/2020, application No. 202011241852.1, which is incorporated herein by reference in its entirety.

Technical Field

The present application relates to the field of network communication, and more particularly, to a method, an apparatus, and a system for determining a correspondence relationship.

Background

Multicast (multicast) is a data transmission method for transmitting data to a plurality of receivers on a Transmission Control Protocol (TCP)/Internet Protocol (IP) network in an efficient manner at the same time by using one multicast address. The multicast source sends a multicast stream to the multicast group members in the multicast group through the link in the network, and the multicast group members in the multicast group can all receive the multicast stream. The multicast transmission mode realizes point-to-multipoint data connection between a multicast source and multicast group members. Since the multicast stream only needs to be delivered once per network link, and the multicast is replicated only when a branch occurs on the link. Therefore, the multicast transmission mode improves the data transmission efficiency and reduces the possibility of congestion of the backbone network. However, at present, it is impossible to provide corresponding network resources for multicast services according to a Service Level Agreement (SLA), so that the SLA of the multicast services cannot be satisfied.

Disclosure of Invention

The application provides a method, a device and a system for determining a corresponding relation, which can meet the SLA of a multicast service.

In a first aspect, a method for determining a corresponding relationship is provided, where the method includes: the method comprises the steps that a first network device obtains a topology identifier and a corresponding device; the first network device obtains a first corresponding relationship, where the first corresponding relationship includes multicast source group (S, G) information and at least one next hop, and any one of the at least one next hop is a device corresponding to the topology identifier obtained through calculation. Wherein S denotes an address of a multicast source (source), and G denotes an address of a multicast group (group).

In the above technical solution, the first network device may send the multicast packet to at least one device corresponding to the topology identifier obtained based on the calculation, so as to satisfy SLAs of different multicast services. In addition, the first network device may also send different multicast packets to devices corresponding to different topology identifiers.

In one possible implementation, the topology identifier is any one of the following: multi-topology identification (MT ID), flexible algorithm identification (flex algorithm ID).

In another possible implementation manner, the first network device obtains a second corresponding relationship, where the second corresponding relationship includes the (S, G) and the topology identifier; and the first network equipment acquires a first forwarding table item according to the topology identifier and the corresponding equipment, wherein the first forwarding table item comprises the topology identifier and the at least one next hop.

In another possible implementation, the method includes: the first network equipment receives a first multicast message, wherein the first multicast message comprises the (S, G) information; the first network device obtains the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message; the first network equipment obtains a second multicast message according to the topology identifier and the first multicast message; the first network device determines the at least one next hop according to the topology identifier included in the first forwarding table entry and the second multicast message; and the first network equipment sends the second multicast message to the at least one next hop.

In another possible implementation manner, the second multicast packet includes the first multicast packet and the topology identifier.

In another possible implementation manner, the second multicast packet includes the first multicast packet and an address of a device corresponding to the topology identifier, such as an end.

In another possible implementation manner, the method further includes: the first network equipment obtains a forwarding identifier according to a third corresponding relation and the topology identifier, wherein the third corresponding relation comprises the topology identifier and the forwarding identifier; and the first network equipment acquires a second multicast message according to the topology information and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

In another possible implementation manner, the method further includes: the first network equipment acquires the forwarding identifier and the topology identifier; and the first network equipment acquires the third corresponding relation according to the forwarding identifier and the topology identifier.

In another possible implementation manner, the forwarding identifier is a slice identifier slice ID or a destination address included in the second multicast packet.

In another possible implementation manner, the first network device obtains a fourth corresponding relationship, where the fourth corresponding relationship includes the (S, G) information and an identifier obtained by calculation based on the topology identifier; and the first network equipment acquires a second forwarding table corresponding to the identifier obtained by calculation based on the topology identifier, wherein the second forwarding table comprises the at least one next hop.

In another possible implementation manner, the first network device receives a first multicast packet, where the first multicast packet includes the (S, G) information; the first network device obtains the identifier obtained by calculation based on the topology identifier according to the fourth corresponding relationship and the (S, G) information included in the first multicast packet; the first network equipment obtains a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message comprises the first multicast message and the identifier obtained by calculation based on the topology identifier; and the first network equipment sends the second multicast message to the at least one next hop included in the second forwarding table entry.

In another possible implementation manner, the second multicast packet is a bit index explicit copy BIERv6 packet based on the sixth version of the internet protocol.

In a second aspect, a method for sending a multicast packet is provided, including: a first network device receives a first multicast message, wherein the first multicast message comprises multicast source group (S, G) information; the first network device obtains at least one next hop according to a first corresponding relationship and the (S, G) information included in the first multicast message, wherein the first corresponding relationship includes the (S, G) information and the at least one next hop, and any one next hop in the at least one next hop is a device which is obtained through calculation and corresponds to the topology identifier; the first network equipment acquires a second multicast message corresponding to the topology identifier based on the first multicast message, wherein the second multicast message comprises the first multicast message; and the first network equipment sends a second multicast message to the at least one next hop.

In one possible implementation, the topology identifier is any one of the following: the multi-topology identifies the MT ID, and the flexible algorithm identifies the flex-algo ID.

In another possible implementation manner, the method further includes: the first network equipment acquires the topology identifier and corresponding equipment; and the first network equipment acquires the first corresponding relation based on the (S, G) information, the topology identifier and the corresponding equipment thereof.

In another possible implementation manner, the method further includes: the first network device obtains the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message; the first network equipment obtains the second multicast message according to the topology identifier and the first multicast message; and the first network device acquires the at least one next hop according to the topology identifier and the first forwarding table entry included in the second corresponding relationship.

In another possible implementation manner, the second multicast packet includes the topology identifier and the first multicast packet.

In another possible implementation manner, the method further includes: the first network device obtains a forwarding identifier based on the topology identifier and a third corresponding relationship, wherein the third corresponding relationship comprises the forwarding identifier and the topology identifier; the first network device obtains the forwarding identifier based on the topology identifier and the third corresponding relationship; and the first network equipment obtains the second multicast message based on the forwarding identifier and the first multicast message, wherein the second multicast message also comprises the forwarding identifier.

In another possible implementation manner, the forwarding identifier is a slice identifier slice ID or a destination address of the second multicast packet.

In another possible implementation manner, the first network device obtains, based on the fourth correspondence and the (S, G) information included in the first multicast message, an identifier obtained by calculation based on the topology identifier; and the first network equipment acquires the at least one next hop included in the second forwarding table entry according to the identifier obtained by calculation based on the topology identifier.

In another possible implementation manner, the first network device obtains the identifier obtained based on the topology identifier calculation according to the fourth corresponding relationship and the (S, G) information included in the first multicast packet; and the first network equipment obtains a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message also comprises the identifier obtained by calculation based on the topology identifier.

The beneficial effects of the second aspect and any one of the possible implementation manners of the second aspect correspond to the beneficial effects of the first aspect and any one of the possible implementation manners of the first aspect, and therefore, the detailed description is omitted here.

In a third aspect, an apparatus for determining a corresponding relationship is provided, including: an acquisition module for acquiring the data of the target object,

the acquisition module is used for acquiring the topology identifier and the corresponding equipment;

the obtaining module is further configured to obtain a first corresponding relationship, where the first corresponding relationship includes multicast source group (S, G) information and at least one next hop, and any one of the at least one next hop is a device corresponding to the topology identifier, which is obtained through calculation.

In one possible implementation, the topology identifier is a multi-topology identifier MT ID or a flexible algorithm identifier flex-algo ID.

In another possible implementation manner, the obtaining module is specifically configured to: acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identifier; and acquiring a first forwarding table entry according to the topology identifier and the corresponding device, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

In another possible implementation manner, the apparatus further includes: the receiving module, the processing module, the sending module and the receiving module are used for receiving a first multicast message, and the first multicast message comprises the (S, G) information;

the processing module is used for obtaining the topology identifier according to the second corresponding relation and the (S, G) information included in the first multicast message;

the processing module is further configured to obtain a second multicast packet according to the topology identifier and the first multicast packet;

the processing module is further configured to obtain the at least one next hop according to the topology identifier included in the first forwarding table entry and the second multicast packet;

and the sending module is used for sending the second multicast message to the at least one next hop.

In another possible implementation manner, the processing module is specifically configured to: obtaining a forwarding identifier according to a third corresponding relationship and the topology identifier, wherein the third corresponding relationship comprises the topology identifier and the forwarding identifier; and obtaining the second multicast message according to the forwarding identifier and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

In another possible implementation manner, the obtaining module is further configured to: acquiring the forwarding identifier and the topology identifier; and acquiring the third corresponding relation according to the forwarding identifier and the topology identifier.

In another possible implementation manner, the obtaining module is specifically configured to: acquiring a fourth corresponding relation, wherein the fourth corresponding relation comprises the (S, G) information and an identifier obtained by calculation based on the topological identifier; and acquiring a second forwarding table corresponding to the identifier obtained by calculation based on the topology identifier, wherein the second forwarding table comprises the at least one next hop.

a processing module, configured to obtain, according to the fourth correspondence and the (S, G) information included in the first multicast packet, the identifier obtained through calculation based on the topology identifier;

the processing module is further configured to obtain a second multicast packet according to the first multicast packet and the identifier obtained through calculation based on the topology identifier, where the second multicast packet includes the first multicast packet and the identifier obtained through calculation based on the topology identifier;

a sending module, configured to send the second multicast packet to the at least one next hop included in the second forwarding table entry.

In a fourth aspect, an apparatus for sending a multicast packet is provided, including: the multicast source group receiving module is used for receiving a multicast source group (S, G) message;

a processing module, configured to obtain at least one next hop according to a first corresponding relationship and the (S, G) information included in the first multicast message, where the first corresponding relationship includes the (S, G) information and the at least one next hop, and any next hop in the at least one next hop is a device corresponding to a topology identifier obtained through calculation;

the processing module is further configured to obtain a second multicast packet corresponding to the topology identifier based on the first multicast packet, where the second multicast packet includes the first multicast packet;

In another possible implementation, the topology identification is a multi-topology identification MT ID or a flexible algorithm identification flex-algo ID.

In another possible implementation manner, the apparatus further includes: an acquisition module for acquiring the data of the target object,

the obtaining module is further configured to obtain the first corresponding relationship based on the (S, G) information, the topology identifier, and the device corresponding to the topology identifier.

In another possible implementation manner, the obtaining module is specifically configured to: acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identifier; and acquiring a first forwarding table entry according to the topology identifier and the device corresponding to the topology identifier, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

In another possible implementation manner, the processing module is specifically configured to: obtaining the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message; obtaining the second multicast message according to the topology identifier and the first multicast message; and acquiring the at least one next hop according to the topology identifier and the first forwarding table entry included in the second corresponding relationship.

In another possible implementation manner, the obtaining module is further configured to: acquiring a forwarding identifier based on the topology identifier and a third corresponding relationship, wherein the third corresponding relationship comprises the forwarding identifier and the topology identifier; acquiring the forwarding identifier based on the topology identifier and the third corresponding relation; the processing module is specifically configured to: and obtaining the second multicast message based on the forwarding identifier and the first multicast message, wherein the second multicast message also comprises the forwarding identifier.

In another possible implementation manner, the obtaining module is specifically configured to: obtaining an identifier obtained based on the topology identifier calculation based on the fourth correspondence and the (S, G) information included in the first multicast message; and acquiring the at least one next hop included in the second forwarding table entry according to the identifier obtained by calculation based on the topology identifier.

In another possible implementation manner, the processing module is specifically configured to: obtaining the identifier obtained by calculation based on the topology identifier according to the fourth corresponding relationship and the (S, G) information included in the first multicast message; and obtaining a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message also comprises the identifier obtained by calculation based on the topology identifier.

In a fifth aspect, a first network device is provided, where the first network device has a function of implementing the above apparatus for determining a corresponding relationship. The functions can be realized based on hardware, and corresponding software can be executed based on hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

In one possible design, the first network device includes a processor in its structure, and the processor is configured to support the first network device to execute the corresponding functions of the method.

The first network device may also include a memory, coupled to the processor, that retains program instructions and data necessary for the first network device.

In another possible design, the first network device includes: a processor, a transmitter, a receiver, a random access memory, a read only memory, and a bus. The processor is coupled to the transmitter, the receiver, the random access memory and the read only memory through the bus respectively. When the first network device needs to be operated, the first network device is guided to enter a normal operation state by starting a basic input/output system solidified in a read-only memory or a bootloader guiding system in an embedded system. After the first network device enters the normal operation state, the application program and the operating system are executed in the random access memory, so that the processor executes the method of the first aspect or any possible implementation manner of the first aspect.

In a sixth aspect, a first network device is provided, the first network device comprising: the main control board and the interface board, further, can also include the exchange network board. The first network device is configured to execute the method for determining a correspondence relationship in the first aspect or any possible implementation manner of the first aspect. In particular, the first network device comprises means for performing the method of determining correspondence in the first aspect or any possible implementation manner of the first aspect.

It should be noted that there may be one or more main control boards, and when there are multiple main control boards, the main control boards may include an active main control board and a standby main control board. The interface board may have one or more boards, and the more the data processing capability of the first network device is, the more interface boards are provided. There may also be one or more physical interface cards on an interface board. The exchange network board may not have one or more blocks, and when there are more blocks, the load sharing redundancy backup can be realized together. Under the centralized forwarding architecture, the first network device may not need the switching network board, and the interface board undertakes the processing function of the service data of the whole system. Under the distributed forwarding architecture, the first network device may have at least one switching network board, and data exchange between the plurality of interface boards is realized through the switching network board, so as to provide large-capacity data exchange and processing capability. Therefore, the data access and processing capabilities of the first network device of the distributed architecture are greater than those of the centralized architecture. Which architecture is specifically adopted depends on the specific networking deployment scenario, and is not limited herein.

In a seventh aspect, a first network device is provided, which includes a control module and a first forwarding sub-device. The first forwarding sub-apparatus comprises: the interface board further can also comprise a switching network board. The first forwarding sub-device is configured to execute the function of the interface board in the sixth aspect, and further, may also execute the function of the switch web board in the sixth aspect. The control module comprises a receiver, a processor, a transmitter, a random access memory, a read-only memory and a bus. The processor is coupled to the receiver, the transmitter, the random access memory and the read only memory through the bus respectively. When the control module needs to be operated, the control module is guided to enter a normal operation state by starting a basic input/output system solidified in a read-only memory or a bootloader guiding system in an embedded system. After the control module enters a normal operation state, the application program and the operating system are operated in the random access memory, so that the processor executes the functions of the main control board in the sixth aspect.

It will be appreciated that in actual practice, the first network device may contain any number of interfaces, processors, or memories.

In an eighth aspect, a first network device is provided, where the first network device has a function of implementing the apparatus for sending a multicast packet. The functions can be realized based on hardware, and can also be realized based on hardware to execute corresponding software. The hardware or software includes one or more modules corresponding to the functions described above.

In another possible design, the first network device includes: a processor, a transmitter, a receiver, a random access memory, a read only memory, and a bus. The processor is coupled to the transmitter, the receiver, the random access memory and the read only memory through the bus respectively. When the first network equipment needs to be operated, the first network equipment is guided to enter a normal operation state by starting a basic input/output system solidified in a read-only memory or a bootloader guiding system in an embedded system. After the first network device enters the normal operation state, the application program and the operating system are executed in the random access memory, so that the processor executes the method of the first aspect or any possible implementation manner of the first aspect.

In a ninth aspect, a first network device is provided, the first network device comprising: the main control board and the interface board, further, can also include the exchange network board. The first network device is configured to execute the second aspect or the method for sending a multicast packet in any possible implementation manner of the second aspect. Specifically, the first network device includes a module configured to execute the second aspect or send a multicast packet in any possible implementation manner of the second aspect.

In a tenth aspect, there is provided a computer program product comprising: computer program code for causing a computer to perform the method of the first aspect or any one of the possible implementations of the first aspect, when the computer program code runs on a computer.

In an eleventh aspect, there is provided a computer program product comprising: computer program code for causing a computer to perform the method of any of the second aspects or possible implementations of the second aspect described above, when the computer program code runs on a computer.

In a twelfth aspect, a computer-readable medium is provided, which stores program code, which, when run on a computer, causes the computer to perform the above-described first aspect or any of the possible implementations of the first aspect. These computer-readable memories include, but are not limited to, one or more of the following: read-only memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Flash memory, Electrically EPROM (EEPROM), and hard drive (hard drive).

In a thirteenth aspect, there is provided a computer readable medium having program code stored thereon, which when run on a computer causes the computer to perform the method of any of the second aspects or possible implementations of the second aspects. These computer-readable memories include, but are not limited to, one or more of the following: read-only memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Flash memory, Electrically EPROM (EEPROM), and hard drive (hard drive).

In a fourteenth aspect, a chip is provided, where the chip includes a processor and a data interface, where the processor reads instructions stored in a memory through the data interface to perform the method of the first aspect or any one of the possible implementation manners of the first aspect. In a specific implementation process, the chip may be implemented in the form of a Central Processing Unit (CPU), a Micro Controller Unit (MCU), a Micro Processing Unit (MPU), a Digital Signal Processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), or a Programmable Logic Device (PLD).

In a fifteenth aspect, a chip is provided, where the chip includes a processor and a data interface, where the processor reads instructions stored in a memory through the data interface to execute the method of the second aspect or any one of the possible implementations of the second aspect. In a specific implementation process, the chip may be implemented in the form of a Central Processing Unit (CPU), a Micro Controller Unit (MCU), a Micro Processing Unit (MPU), a Digital Signal Processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), or a Programmable Logic Device (PLD).

A sixteenth aspect provides a system, where the system includes the apparatus for determining a correspondence relationship in any one of the foregoing possible implementation manners of the third aspect or the third aspect, and/or the apparatus for sending a multicast packet in any one of the foregoing possible implementation manners of the fourth aspect or the fourth aspect.

Drawings

Fig. 1 is a schematic flowchart of a method for obtaining a corresponding relationship according to an embodiment of the present disclosure.

Fig. 2 is a scene schematic diagram of a BIER domain provided in an embodiment of the present application.

Fig. 3 is a schematic flowchart of another method for determining an acquisition correspondence according to an embodiment of the present application.

Fig. 4 is a schematic format diagram of a TLV provided in an embodiment of the present application.

Fig. 5 is a schematic format diagram of a sub-TLV provided in an embodiment of the present application.

Fig. 6 is a schematic format diagram of TLV for flooding MT ID provided in an embodiment of the present application.

Fig. 7 is a schematic format diagram of a TLV for flooding a flex-algo ID provided in an embodiment of the present application.

Fig. 8 is a schematic diagram of a TLV format of another flooding MT ID provided in an embodiment of the present application.

Fig. 9 is a schematic format diagram of a TLV for flooding a flex-algo ID provided in an embodiment of the present application.

Fig. 10 is a schematic block diagram of one possible BIER header format.

Fig. 11 is a schematic diagram of another possible BIER header format.

Fig. 12 is a scene diagram of another BIER domain provided in the embodiment of the present application.

Fig. 13 is a schematic flowchart of a method for sending a multicast packet according to an embodiment of the present application.

Fig. 14 is a schematic structural diagram of an apparatus 1400 for determining a correspondence relationship according to an embodiment of the present application.

Fig. 15 is a schematic structural diagram of an apparatus 1500 for sending a multicast packet according to an embodiment of the present application.

Fig. 16 is a schematic hardware structure diagram of a first network device 2000 according to an embodiment of the present disclosure.

Fig. 17 is a schematic hardware structure diagram of another first network device 2100 according to an embodiment of the present disclosure.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

This application is intended to present various aspects, embodiments or features around a system comprising a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Furthermore, a combination of these schemes may also be used.

In addition, in the embodiments of the present application, words such as "exemplary", "for example", etc. are used to mean serving as examples, illustrations or explanations. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term using examples is intended to present concepts in a concrete fashion.

In the embodiments of the present application, "corresponding" and "corresponding" may be sometimes used in a mixed manner, and it should be noted that the intended meaning is consistent when the difference is not emphasized.

The network architecture and the service scenario described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not form a limitation on the technical solution provided in the embodiment of the present application, and it can be known by a person skilled in the art that the technical solution provided in the embodiment of the present application is also applicable to similar technical problems along with the evolution of the network architecture and the appearance of a new service scenario.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

In the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: including the presence of a alone, a and B together, and B alone, where a, B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of the singular or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or multiple.

Multicast (multicast) is a data transmission method for transmitting data to a plurality of receivers on a Transmission Control Protocol (TCP)/Internet Protocol (IP) network in an efficient manner at the same time by using one multicast address. The multicast source sends a multicast stream to the multicast group members in the multicast group through the link in the network, and the multicast group members in the multicast group can all receive the multicast stream. The multicast transmission mode realizes point-to-multipoint data connection between a multicast source and multicast group members. Since the multicast stream only needs to be delivered once per network link, and the multicast is replicated only when a branch occurs on the link. Therefore, the multicast transmission mode improves the data transmission efficiency and reduces the possibility of congestion of the backbone network.

The Internet Protocol (IP) multicast technology realizes the high-efficiency data transmission from point to multipoint in the IP network, and can effectively save the network bandwidth and reduce the network load. Therefore, the method and the device have wide application in real-time data transmission, multimedia conferences, data copying, Internet Protocol Television (IPTV), games, simulation and other aspects. The multicast technology uses a multicast protocol to construct a control plane multicast tree, and then uses the multicast tree to logically tree a network plane so as to realize multicast point-to-multipoint data forwarding. The intermediate device with the distribution tree as the core needs to maintain a complex multicast forwarding information state.

However, at present, it is impossible to provide corresponding network resources for multicast services according to a Service Level Agreement (SLA), so that the SLA of the multicast services cannot be satisfied.

In view of this, the embodiments of the present application provide a method for determining a corresponding relationship, where the method can meet the SLA of a multicast service.

A method for determining the corresponding relationship provided in the embodiment of the present application is described in detail below with reference to fig. 1.

Fig. 1 is a schematic flowchart of a method for determining a corresponding relationship provided in an embodiment of the present application. As shown in fig. 1, the method may include steps 110-120, and the steps 110-120 are described in detail below.

Step 110: the first network equipment acquires the topology identification and the corresponding equipment.

Multicast messages required by different SLAs need different topology forwarding paths, and the topology forwarding paths are paths determined by next hops obtained through calculation based on topology identifiers. As an example, the computation of different topologies is mainly influenced by the following factors: link metric (metric) type, routing algorithm, link constraints, etc. Wherein, the metric type represents a link index constraint (e.g. a delay index), the route calculation algorithm represents a calculation algorithm constraint (e.g. using a Shortest Path First (SPF) algorithm), and the link constraint represents a topology constraint (e.g. whether some links are included/removed during calculation).

The multicast packet in the embodiment of the present application is not specifically limited, and may be a common multicast packet, or may also be a Bit Index Explicit Replication (BIER) packet obtained by encapsulating an original multicast packet. For example, the BIERv6 message is obtained by performing bit index explicit replication (BIERv 6) encapsulation based on the sixth version of the internet protocol on the original multicast message.

It should be understood that, as the network size is larger and larger, and the flow of multicast messages is increasing day by day, the multicast technology faces larger and larger challenges in terms of cost and operation and maintenance. Therefore, a new technology for constructing a multicast message forwarding path is proposed in the industry, which is called BIER technology, and the technology provides a multicast technology architecture without constructing a multicast distribution tree.

For example, a router supporting BIER technology is called a bit-forwarding router (BFR). BFRs located at the edge include Bit Forwarding Ingress Routers (BFIR) and Bit Forwarding Egress Routers (BFER). A BFR located between the BFIR and the BFER may be referred to as an intermediate BFR. BFIR can carry out BIER encapsulation on the original multicast message to obtain the BIER message. The BFER can decapsulate the received BIER message to obtain an original multicast message. The BIER domain (domain) includes a BFIR and at least one BFER. Optionally, the BEIR field may also include at least one intermediate BFR. The BFIR is positioned at the entrance position of the BIER domain and is used as a head node for transmitting the BIER message to encapsulate the BIER message. The BFER is positioned at the exit position of the BIER domain and is used as a tail node for forwarding the BIER message to decapsulate the BIER message. The intermediate BFR is positioned between the BFIR and the BFER of the BIER domain and is used as an intermediate forwarding node of the BIER message to be responsible for forwarding the BIER message.

The first network device in the embodiment of the present application may be an intermediate forwarding device of the BIER domain, for example, an intermediate BFR in the BIER domain. The forwarding technique associated with BIER will be described in detail below with reference to specific embodiments, which will not be described in detail here. Taking the multicast packet as a BIERv6 packet as an example, the first network device may be an entry device in a BIER domain, for example, a BFIR in the BIER domain. The forwarding technique associated with BIER will be described in detail below with reference to specific embodiments, which will not be detailed here.

In this embodiment, the first network device may obtain the topology identifier and the corresponding device based on IGP flooding or configuration. The topology identifier may be various, and this is not specifically limited in this embodiment of the application. As an example, the topology identification may be an MT ID. As another example, the topology identification may be a flex-algo ID.

Step 120: the first network device obtains a first correspondence, the first correspondence including multicast source group (S, G) information and at least one next hop.

The first mapping relationship may include the multicast source group (S, G) information and at least one next hop, where any next hop of the at least one next hop is a device obtained through calculation and corresponding to the topology identifier. As an example, if the topology identifier is an MT ID, a device corresponding to the topology identifier may be obtained by calculation using a preset algorithm in a topology domain corresponding to the MT ID. If the topology identifier is a flex-algo ID, calculating and obtaining equipment corresponding to the topology identifier by adopting an algorithm corresponding to the flex-algo ID in a topology domain formed by nodes supporting the flex-algo ID. The preset algorithm or the algorithm corresponding to the flex-algo ID may be a BIER flex-algo algorithm or other algorithms of IGP, such as an Independent Path Algorithm (IPA) or SPF algorithm.

As an example, the first corresponding relationship may include first multicast source group (S, G) information and a next hop device 1, where the next hop device 1 is a device obtained through calculation and corresponding to the first topology identifier. Optionally, the first correspondence further includes a next hop device 2. And the next-hop device 2 is a device obtained by calculation and corresponding to the second topology identifier.

As another example, the first corresponding relationship may include first multicast source group (S, G) information and a next hop device 1, where the next hop device 1 is a device obtained through calculation and corresponding to the first topology identifier. Optionally, the first correspondence further includes a next hop device 2. And the next-hop device 2 is a device obtained by calculation and corresponding to the first topology identifier.

As another example, the first correspondence relationship may include first multicast source group (S, G) information and a next hop device 1, where the next hop device 1 is a device obtained through calculation and corresponding to both the first topology identifier and the second topology identifier.

In the above technical solution, the first network device may send the multicast packet to one or more devices corresponding to the topology identifier obtained based on the calculation, or the first network device may send different multicast packets to one or more devices corresponding to different topology identifiers, thereby satisfying SLAs of different multicast services.

The following describes in detail a specific implementation process of determining the correspondence relationship by the first network device, taking the multicast packet as a BIERv6 packet as an example. For convenience of description, a scenario applicable to the embodiment of the present application will be described in detail below by taking the BIER domain shown in fig. 2 as an example. Fig. 2 is a scene schematic diagram of a BIER domain provided in an embodiment of the present application. As shown in fig. 2, the BIER domain may include device PE1, device PE2, device P1, device P2, and device P3. Among them, device PE1 and device PE2 belong to edge BFRs within the BIER domain. Device P1, device P2, and device P3 belong to the intermediate BFR within the BIER domain. Specifically, the device PE1 is located at an entry of the BIER domain, and is responsible for BIER encapsulation on the original multicast packet, which corresponds to the above BFIR. The device PE2 is located at the exit of the BIER domain, and is responsible for decapsulating the original multicast packet from the BIER packet, which corresponds to the BFER in the foregoing.

Fig. 3 is a schematic flowchart of another method for determining an acquisition correspondence according to an embodiment of the present application. As shown in FIG. 3, the method may include steps 310-350, which are described in detail below in relation to steps 310-350, respectively.

It should be understood that fig. 3 specifically illustrates the method for determining the acquisition correspondence relationship by taking the scenario of the BIER domain shown in fig. 2 as an example.

Step 310: the device PE1 obtains the topology identity and its corresponding device.

The device PE1 may obtain the topology identifier and its corresponding device through flooding or configuration. This process is described in detail below, taking as an example that the device PE1 obtains the topology identifier and its corresponding device through flooding.

As an example, the intermediate BFR or BFER of the BIER domain may flood information to device PE1 (BFIR in the BIER domain) through an Interior Gateway Protocol (IGP). This information may include, but is not limited to: MT or flex-algo ID, sub-domain (SD), end. The different MT or flex-algo IDs may correspond to the same end.

It should be understood that Segment Routing (SR) uses segment identification (segment identity) in the message to indicate the instructions of the operation in the network. For example, in segment routing based on IPv6 data plane (segment routing IPv6, SRv6), an IPv6 address is taken as one SRv6 SID. BIERv6 is a technique to implement BIER forwarding in the IPv6 data plane, using a special IPv6 destination address (called end. BIER) to instruct devices to do BIER forwarding. BIER is an SRv6 SID with a special indication function that instructs the device to perform BIER forwarding locally. End.bier may also be referred to as end.bier SID.

BIER denotes an IPv6 address configured on the device to instruct the device to perform BIER forwarding locally. After configuring the address of the end.bier, the device forms a forwarding table entry of a 128-bit mask of the address in a Forwarding Information Base (FIB), and the forwarding table entry identifies that the address is the end.bier. When the device receives the IPv6 message, it first looks up FIB for the destination address, and when the FIB lookup result is an end.bier address, it will execute an action specific to the end.bier, i.e. continue to process the BIER header in the IPv6 extended header. Otherwise, if the message is a normal IPv6 destination address, the FIB lookup result indicates that the message is an IPv6 message sent to the router and containing a destination option extension header, and the message may be sent to the processor for processing, which may not achieve the purpose of data plane processing.

As an example, a device in the BIER domain may flood the above information through Type Length Value (TLV). Fig. 4 is a format diagram of a TLV, see fig. 4, that may be used to flood the MT ID. One TLV may carry one or more sub-TLVs (sub-TLVs), and fig. 5 is a schematic format diagram of the sub-TLVs. Referring to fig. 5, a sub-domain ID field may be included in the sub-TLV for flooding the sub-domain. The sub-TLV may also be extended, one or more sub-sub-TLVs (sub-sub-TLVs) may be extended in the sub-TLV, and the end.bier and the flex-algo ID may be flooded through the extended sub-sub-TLV. For sub-TLV, reference is made to RFC8401, which is not described in detail here.

It should be noted that the TLV shown in fig. 4 is an extended TLV RFC5120 of an intermediate system to intermediate system (ISIS) protocol message. The embodiment of the present application does not specifically limit the protocol type, and only uses the TLV of ISIS as an example for explanation.

The process by which BFRs or BFERs in the BIER domain flood the MT ID to other devices in the BIER domain via IGP is described in detail below.

It should be understood that, for convenience of description, the following describes a process of flooding BIER information for each device on path 1 or path 2, taking the transmission path of the BIER message as path 1 or path 2 shown in fig. 2 as an example.

Taking the example that different MT or flex-algo IDs on the device P1 correspond to the same end.bier, the information that the device P1 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID 1, MT or flex-algo ID 2;

End.BIER＝2001::1/128；

where "MT or flex-algo ID 1, MT or flex-algo ID 2" means that the device P1 supports both the topology of MT or flex-algo ID 1 and the topology of MT or flex-algo ID 2. And, for the device P1, under sub-domain 0, MT or flex-algo ID 1 is the same as end.bier corresponding to MT or flex-algo ID 2, which is 2001:: 1/128.

It should be noted that in the embodiment of the present application, a sub-domain may include multiple topologies, for example, in the information that P1 floods to other devices in the BIER domain, sub-domain 0 may include two topologies, i.e., MT or flex-algo ID 1 and MT or flex-algo ID 2.

As an example, device P1 floods TLVs for MT ID to other devices in the BIER domain as shown in fig. 6(a) and 6 (b). Specifically, device P1 may flood two TLVs. One TLV is (a) of fig. 6, which is used to flood MT ID ═ 1, and sub-TLV carried sub-TLV to flood sub-domain ═ 0. And extending sub-TLVs carried by the TLVs, and flooding end.BIER 2001: 1/128 corresponding to MT ID: 1 through the extended sub-sub-TLVs. Another TLV is (b) of fig. 6, which is used to flood MT ID 2, sub-TLV carried sub-domain 0. And expanding the sub-TLV carried by the TLV, and flooding the end.BIER 2001::1/128 corresponding to the MT ID ═ 2 through the expanded sub-sub-TLV.

As an example, device P1 floods the TLVs of flex-algo ID 1 and flex-algo ID 2 to other devices in the BIER domain as shown in fig. 7. Device P1 may flood sub-domain 0 with sub-TLVs carried by TLVs. And expanding the sub-TLV carried by the TLV, and flooding the end.BIER 2001::1/128 corresponding to the flex-algo ID 1 and the flex-algo ID 2 through the expanded sub-sub-TLV.

Taking as an example that different MT or flex-algo IDs on the device P1 correspond to different end.bier, the information that the device P1 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID ═ 1; end. bier 2001: 1/128;

MT or flex-algo ID 2; end, bier 2002:: 1/128;

for device P1, at sub-domain 0, end. bier for MT or flex-algo ID 1 is 2001::1/128, end. bier for MT or flex-algo ID 2 is 2002:: 1/128.

As an example, device P1 floods TLVs of MT ID to other devices in the BIER domain as shown in fig. 8(a) and 8 (b). Specifically, device P1 may flood two TLVs. One TLV is (a) of fig. 8, which is used to flood MT ID 1, and sub-TLV carried by the TLV to flood sub-domain 0. And expanding the sub-TLV carried by the TLV, and flooding the end.BIER 2001::1/128 corresponding to the MT ID ═ 1 through the expanded sub-sub-TLV. Another TLV is (b) of fig. 8, which is used to flood MT ID 2, which carries sub-TLV flooding sub-domain 0. And expanding the sub-TLV carried by the TLV, and flooding the end.BIER 2002::1/128 corresponding to the MT ID ═ 2 through the expanded sub-sub-TLV.

As an example, device P1 floods other devices in the BIER domain with a TLV of flex-algo ID 1 and flex-algo ID 2 as shown in fig. 9. Device P1 may flood sub-domain 0 with sub-TLVs carried by TLVs. And expanding the sub-TLVs carried by the TLVs, and flooding an end.BIER 2001::1/128 corresponding to the flex-algo ID ═ 1 through one expanded sub-sub-TLV. End. bier 2002::1/128 corresponding to flex-algo ID ═ 2 is flooded through another extended sub-sub-TLV.

Taking as an example that different MT or flex-algo IDs on the device P2 correspond to the same end.bier, the information that the device P2 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID 1, MT or flex-algo ID 2;

End.BIER＝2003::1/128；

on device P2, "MT or flex-algo ID 1, MT or flex-algo ID 2" means that device P2 supports both a topology of MT or flex-algo ID 1 and a topology of MT or flex-algo ID 2. And, for the device P2, under sub-domain 0, MT or flex-algo ID 1 is the same as end.bier corresponding to MT or flex-algo ID 2, both 2003:: 1/128.

For the device P2 to flood TLVs with MT ID 1 to other devices in the BIER domain, please refer to the format of (a) in fig. 6, and for the TLV with MT ID 2, please refer to the format of (b) in fig. 6, which is not described herein again. Please refer to the format in fig. 7, which is not described herein, for the device P2 to flood TLVs with flex-algo ID of 1 and flex-algo ID of 2 to other devices in the BIER domain.

Taking as an example that different MT or flex-algo IDs on the device P2 correspond to different end.bier, the information that the device P2 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID ═ 1; end. bier 2003: 1/128;

MT or flex-algo ID 2; end. bier 2004: 1/128;

for device P2, at sub-domain 0, end. bier for MT or flex-algo ID 1 is 2003::1/128, and end. bier for MT or flex-algo ID 2 is 2004:: 1/128.

The device P2 floods TLV of MT ID to other devices in the BIER domain, please refer to the format of (a) in fig. 8, and the TLV of MT ID 2 refers to the format of (b) in fig. 8, which is not described herein again. Please refer to the format in fig. 9, which is not described herein, for the device P2 to flood TLVs with flex-algo ID of 1 and flex-algo ID of 2 to other devices in the BIER domain.

Taking device P3 as an example, the information that this device P3 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID 2;

End.BIER＝2005::1/128；

on device P3, "MT or flex-algo ID 2" means that device P3 only supports topologies of MT or flex-algo ID 2. And, for device P3, end.bier corresponding to MT or flex-algo ID 2 at sub-domain 0 is 2005:: 1/128.

Please refer to the format of (a) in fig. 6, and refer to the format of (b) in fig. 6, for the device P3 flooding TLV 1 of MT ID and TLV 2 of MT ID to other devices in the BIER domain, which is not described herein again. Please refer to the format in fig. 7, which is not described herein, for the device P3 to flood TLVs with flex-algo ID of 1 and flex-algo ID of 2 to other devices in the BIER domain.

Taking as an example that different MT or flex-algo IDs on the device PE2 correspond to the same end.bier, the information that the device PE2 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID 1, MT or flex-algo ID 2;

End.BIER＝2007::1/128；

on device PE2, "MT or flex-algo ID 1, MT or flex-algo ID 2" means that device PE2 supports both a topology of MT or flex-algo ID 1 and a topology of MT or flex-algo ID 2. And, for the device PE2, at sub-domain 0, MT or flex-algo ID 1 is the same as end.bier corresponding to MT or flex-algo ID 2, both 2007:: 1/128.

Device PE2 may also flood the other devices in the BIER domain with the BFR identifier (BFR-ID) assigned to itself. It should be appreciated that in the BIER domain, the edge BFR (e.g., BFIR, BFER) may be configured with a bit position identification that is globally unique throughout the BIER sub-domain (SD). As an example, each edge BFR is configured with a value as a BFR-ID), e.g., the BFR-ID allocated for device PE2 is 4.

The device PE2 floods TLV of MT ID to other devices in the BIER domain, please refer to the format of (a) in fig. 6, and the TLV of MT ID to 2, please refer to (b) in fig. 6, which is not described herein again. Please refer to the format in fig. 7, which is repeated herein, for the device PE2 to flood TLVs with a flex-algo ID of 1 and a flex-algo ID of 2 to other devices in the BIER domain. It should be understood that the device PE2 may also include a BFR-ID field in the TLV flooded by fig. 6 or fig. 7, the BFR-ID field carrying a value of 4.

Taking as an example that different MT or flex-algo IDs on the device PE2 may correspond to different end.bier, the information that the device PE2 floods other devices in the BIER domain is as follows:

sub-domain＝0；

MT or flex-algo ID ═ 1; end. bier 2007: 1/128;

MT or flex-algo ID 2; end, bier 2008:: 1/128;

for the device PE2, at sub-domain 0, end. bier for MT or flex-algo ID 1 is 2007::1/128, and end. bier for MT or flex-algo ID 2 is 2008:: 1/128.

The device PE2 floods TLV with MT ID equal to 1 to other devices in the BIER domain, please refer to the format of (a) in fig. 8, and the TLV with MT ID equal to 2 refers to the format of (b) in fig. 8, which is not described herein again. Please refer to the format in fig. 9, which is repeated herein, for the device PE2 to flood TLVs with a flex-algo ID of 1 and a flex-algo ID of 2 to other devices in the BIER domain.

It should be understood that the device PE2 may also include a BFR-ID field in the TLV flooded by fig. 8 or fig. 9, the BFR-ID field carrying a value of 4.

Step 320: the device PE1 obtains at least one next hop.

For example, the device PE1 that supports MT or flex-algo ID 1 acquired by flooding includes: device P1, device P2, and device PE 2. The device PE1 may acquire a device corresponding to MT or flex-algo ID of 1 by calculation, and regard the device as the next hop. For example, the device PE1 calculates that the obtained device corresponding to the MT or flex-algo ID of 1 is the device P1, and the device PE1 may use the device P1 as the next hop corresponding to the MT or flex-algo ID of 1.

As another example, the MT or flex-algo ID 2-capable device obtained by the device PE1 through flooding includes: device P1, device P2, device P3, and device PE 2. The device PE1 may obtain a device corresponding to the MT or flex-algo ID of 2 by calculation, and treat the device as the next hop. For example, the device PE1 calculates that the obtained device corresponding to the MT or flex-algo ID of 2 is the device P1, and the device PE1 may use the device P1 as the next hop corresponding to the MT or flex-algo ID of 2.

Step 330: the device PE1 obtains a first correspondence between multicast source group (S, G) information and at least one next hop.

There are various manners of obtaining the first corresponding relationship, and this is not specifically limited in this embodiment of the present application. Several possible implementations are described in detail below.

In one possible implementation, the device PE1 may obtain a second corresponding relationship, where the second corresponding relationship includes (S, G) information and the MT or flex-algo ID. The device PE1 may further obtain a first forwarding table entry according to the MT or flex-algo ID and the corresponding device, where the first forwarding table entry includes the MT or flex-algo ID and the next hop. The first forwarding table entry may also be referred to as a first BIFT.

As an example, the second correspondence obtained by the device PE1 includes: (S1, G1) and MT or flex-algo ID ═ 1, and the second correspondence may further include: (S2, G2) and MT or flex-algo ID ═ 2.

In this implementation, to distinguish different MT or flex-algo IDs in one BIFT and match to different next hops according to the different MT or flex-algo IDs, one MT or flex-algo ID column may be added to the BIFT. For the same BFR ID, different values in the MT or flex-algo ID columns correspond to different next hops.

The first BIFT generated by device PE1 is shown in table 1 below.

TABLE 1 first BIFT generated by device PE1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P1	00001000
4	2	Device P1	00001000

The bit obtained by the device PE1 determines which BFERs the packet is to be sent to according to the bit string (bit string) in the BIER packet. The FBM is used for matching with a bit string (bit string) in the BIER message, and if the matching is successful, the matched BIER message is sent to the corresponding next hop.

It should be understood that the BIER packet may include a BIER header and an original multicast packet. The BIER header may include a bit string (bit string) field.

bit string is the destination device set string of the BIER message. Each bit in the bit string is used to identify the edge BFR, e.g., the lower (rightmost) bit of the bit string is used to identify the BFER with a BFR-ID of 1. The 2 nd Bit from right to left in Bit string is used to identify the BFER with BFR-ID ═ 2. The 4 th Bit from right to left in Bit string is used to identify the BFER with BFR-ID of 4. The 8 th Bit from right to left in Bit string is used to identify the BFER with BFR-ID of 8. And if the bit value of the bit string is 1, the message is sent to the BFER equipment represented by the BFR-ID, and if the bit value of the bit string is 0, the message is not required to be sent to the BFER equipment represented by the BFR-ID.

There are various specific formats of the BIER header, and two different BIER header formats are shown in fig. 10 and 11, respectively.

As shown in table 1, if the device PE1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, a bit string (bit string) of the BIER packet is 1 from right to left with the 4 th bit, and the MT or flex-algo ID corresponding to the BIER packet is 1 or MT or flex-algo ID is 2, the device PE1 may forward the BIER packet to the device P1.

In another possible implementation manner, the device PE1 may further obtain a fourth corresponding relationship, where the fourth corresponding relationship includes (S, G) information and an identifier obtained through calculation based on the MT or flex-algo ID, and obtain a second forwarding table entry corresponding to the identifier obtained through calculation based on the topology identifier, where the second forwarding table entry includes the next hop. As an example, the identifier calculated based on the MT or flex-algo ID in the embodiment of the present application may be a BIFT ID. That is, the BIFT ID corresponds to the MT or flex-algo ID. The assignment of BIFT IDs is of < SD, BSL, SI, MT or flex-algo ID > granularity, with different MT or flex-algo IDs corresponding to different BIFT IDs. Different MT or flex-algo IDs can be distinguished by different BIFT IDs.

In such an implementation, device PE1 may maintain a fourth correspondence between the (S, G) information and the BIFT ID computed based on the MT or flex-algo ID. For example, the fourth correspondence relationship includes: (S1, G1) and a BIFT ID of 1, where the fourth correspondence may further include: (S2, G2) and BIFT ID ═ 2.

In this implementation, the device PE1 has a BIFT ID ═ 1 corresponding to MT or flex-algo ID ═ 1 as shown in table 2 below.

Table 2 the BIFT ID generated by the device PE1 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Device P1	00001000

As shown in table 2, if the device PE1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 1, and the device PE1 may forward the BIER packet to the device P1.

The BIFT ID ═ 2 corresponding to the MT or flex-algo ID ═ 2 generated by the device PE1 is shown in table 3 below.

Table 3 BIFT ID generated by device PE1 is 2

BFR ID	Jump next (neighbor)	FBM
			4	Device P1	00001000

As shown in table 3, if the device PE1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device PE1 may forward the BIER packet to the device P1.

In this embodiment, there are various implementation manners for the device PE1 to obtain the correspondence between the (S, G) information of the multicast packet and the MT or the flex-algo ID. In a possible implementation manner, the device PE1 may obtain, based on local configuration, a correspondence between (S, G) information of the multicast packet and the MT or the flex-algo ID. In another possible implementation manner, the device PE1 may further obtain a correspondence between (S, G) information of the multicast packet and the MT or flex-algo ID through a message sent by a receiver of the BIER packet (e.g., the device PE 2). These two different implementations are described in detail below.

In a possible implementation manner, the device PE1 may obtain, based on local configuration, a correspondence between (S, G) information of the multicast packet and the MT or the flex-algo ID. The specific implementation form of the above correspondence may be various, and this is not specifically limited in the present application, and several possible implementation ways are described in detail below.

For example, the above correspondence is a mapping relationship between an MVPN and a BIER identifier field to which the multicast packet belongs. By way of example, the BIER identification field is BIER color, which identifies a different MT or flex-algo ID. That is to say, the BIER color can be associated with one or more MTs or flex-algo IDs, corresponding color values can be set according to different SLAs, and then the corresponding MT or flex-algo IDs can be determined according to different color values.

The local configuration of the ingress device of the BIER domain in this implementation is illustrated below.

Wherein, "Bier-slicing 11MT/flex-algo ═ 1 a" indicates that the MT or flex-algo ID associated with the network slice Bier-slicing11 is 1 a. Similarly, "Bier-slicing 22MT/flex-algo is 1 b" indicates that the MT or flex-algo ID associated with the network slice Bier-slicing22 is 1 b. "Bier-slicing 33MT/flex-algo is 1 c" indicates that the MT or flex-algo ID associated with the network slice Bier-slicing 33 is 1 c.

"Sub-domain 0ipv6 end: MT/flex-algo 1a, MT/flex-algo 1b, MT/flex-algo 1 c" means that multiple MTs or flex-algo IDs, for example, 1a, 1b, 1c, will be issued under one Sub-domain. Specifically, each MT or flex-algo ID corresponds to one end.

"Bier-color 100Bier-slicing 11" means that the Bier-color 100 is associated with a network slice Bier-slicing 11.

"Bier-color 200Bier-slicing 22Bier-slicing 33" means that Bier-color 100 associates multiple BIERv6 network slices, e.g., Bier-slicing22 and Bier-slicing 33.

It should be noted that one Bier-color may be associated with one BIERv6 network slice, or may also be associated with a plurality of BIERv6 network slices, which is not specifically limited in this application. If the multicast message is a Bier-color associated multiple BIERv6 network slices, the multiple BIERv6 network slices can perform load sharing on the multicast message belonging to the VPN. For example, Bier-color 200 associates two BIERv6 network slices, one being Bier-sliding 22. The other is Bier-sliding 33, and the two BIERv6 network slices can perform load sharing on the multicast traffic of the VPN associated with the Bier-color 200.

"MVPN bier sub-domain 0bier-color 100" means that the sub-domain of BIERv6 tunnel is designated as sub-domain 0 under VPN, and the corresponding color is bier-color 100. That is, the multicast packet belonging to the VPN can be forwarded on the MT or flex-algo ID associated with the one or more BIERv6 network slices according to the sub-domain and the corresponding bier-color in the VPN and associated with the one or more BIERv6 network slices.

It should be understood that multiple MVPNs can bind to the same bier-color, and one MVPN can bind to only one bier-color. Different multicast traffic streams of the same MVPN may be forwarded on the same MT or flex-algo ID.

For another example, a BIER identifier field may not be introduced, and the correspondence is a mapping relationship between the MVPN to which the multicast packet belongs and the BIERv6 network slice.

Wherein, the "MVPN bier sub-domain 0 bier-sliding 11" indicates that the sub-domain of the BIERv6 tunnel is designated as sub-domain 0 under the VPN, and the corresponding BIERv6 network slice is bier-sliding 11. The multicast message belonging to the VPN can be forwarded on the MT or flex-algo ID corresponding to the BIERv6 network slice.

For another example, no BIERv6 network slice may be introduced, and the correspondence is a mapping relationship between the MVPN and BIER color to which the multicast packet belongs.

Wherein, the MVPN Bier sub-domain 0Bier-color 100 means that the sub-domain of the BIERv6 tunnel is designated as sub-domain 0 under the VPN, and the corresponding color is Bier-color 100.

"Bier-color 100MT/flex-algo 1 a" means that the Bier-color 100 associated MT or flex-algo ID is 1 a.

In another possible implementation, device PE1 may also map different multicast services to different MTs or flex-algo IDs according to quality of service (QoS) of different multicast services on the forwarding plane. For example, the QoS flag is a value of a DSCP field in a multicast packet. The value of one or more DSCP fields can be associated with one MT or flex-algo ID, the value of the corresponding DSCP field can be set according to different SLAs, and the corresponding MT or flex-algo ID can be determined according to the value of different DSCP fields.

In the following, by taking DSCP as an example, several possible implementations are described in detail.

For example, the correspondence is a mapping relationship between the MVPN and Bierv6-group to which the multicast message belongs. Wherein, Bierv6-group is used for representing the mapping relation between DSCP and bier-color. The entrance device of the BIER domain can further determine the associated MT or flex-algo ID according to different color values.

Wherein, the 'Bierv 6-group1 dccp 10match bier-color 100 dccp 20match bier-color 100' represents the mapping relation between DSCP and bier-color in the Bierv6-group1, the color associated with the DSCP 100 is bier-color 100, and the color associated with the DSCP 200 is bier-color 100.

It should be understood that the same DSCP value may be associated with the same bier-color, or may also be associated with different bier-colors, which is not specifically limited in this application.

It should also be understood that there are many ways to implement the mapping between bier-color and MT or flex-algo ID. For example, the bier-color can directly associate an MT or a flex-algo ID. As another example, bier-color may also associate a BIERv6 network slice, BIERv6 network slice with MT or flex-algo ID. For a specific implementation, please refer to the above description, which will not be detailed here.

"MVPN Use Bierv6-group 1" indicates that the designated BIERv6 tunnel under VPN is Bierv6-group 1.

For another example, the correspondence is a mapping relationship between the MVPN and Bierv6-group to which the multicast packet belongs. Wherein, Bierv6-group is used for representing the mapping relation between DSCP and BIERv6 network slice. The ingress device of the BIER domain may in turn determine the associated MT or flex-algo ID from the different BIERv6 network slices.

Wherein "Bierv 6-group 1DSCP 10match bier-sliding 11DSCP 20match bier-sliding 22" represents the mapping relationship between the DSCP and the BIERv6 network slice in Bierv6-group1, the BIERv6 network slice associated with the DSCP 100 is bier-sliding 11, and the BIERv6 network slice associated with the DSCP 200 is bier-sliding 22.

The correspondence between the BIERv6 network slice and the MT or flex-algo ID is described above and will not be described in detail here.

It should be understood that the same DSCP value may be associated with the same BIERv6 network slice, or may also be associated with different BIERv6 network slices, which is not specifically limited in this application.

In another possible implementation manner, the device PE1 may further obtain a correspondence between the multicast packet and the MT or the flex-algo ID through a message sent by a receiver of the BIER packet (e.g., the device PE 2).

Specifically, an egress device (e.g., device PE2) of the BIER domain may carry the differentiated SLA complaint identifier when sending the message to the device PE 1. As an example, the BGP NG-MVPN signaling protocol may be extended, so that the extended BGP NG-MVPN signaling protocol may carry a BIER color. For example, when sending a multicast join message to an ingress device in the BIER domain, an egress device in the BIER domain may carry a BIER color in an automatic discovery-interface-discovery (I-PMSI a-D) including a provider multicast service interface. As another example, the outlet device of BIER domain may also carry BIER color in the I-PMSI A-D that advertises Sub-domain, BFR-prefix, BFR-ID to the inlet device of BIER domain.

For example, the BIER color is used to identify an MT or a flex-algo ID corresponding to a multicast packet of VPN granularity, in this implementation, different (S, G) in the same VPN bind the same BIER color value, that is, different (S, G) in the same VPN correspond to the same MT or flex-algo ID.

In another possible implementation manner, the BIER color is used to identify the MT or flex-algo ID corresponding to the multicast packet with the VPN (S, G) group granularity. Different (S, G) binding different BIER color values in the same VPN, that is, different (S, G) binding different MT or flex-algo ID in the same VPN.

Optionally, the method shown in fig. 3 may further include step 340.

Step 340: the device PE1 obtains a third correspondence between the forwarding identity and the topology identity.

Wherein, the forwarding identification corresponds to the MT or the flex-algo ID. The forwarding identifier may be a slice identifier slice ID, or may also be a destination address included in the multicast packet.

As an example, the device PE1 may obtain a third correspondence between the configured slice ID and the MT or flex-algo ID. For example, the third correspondence relationship includes: slice ID 1, MT or flex-algo ID 1. The third corresponding relationship may further include: slice ID 2, MT or flex-algo ID 2.

As another example, assuming that the next hop corresponding to MT or flex-algo ID 1 acquired by the device PE1 is the device P1, the device PE1 may acquire the third correspondence relationship based on information flooded by the device P1. For example, the third correspondence relationship includes: MT or flex-algo ID 1, and MT or flex-algo ID 1 on device P1 corresponds to end. Assuming that the next hop corresponding to the MT or flex-algo ID 2 acquired by the device PE1 is the device P1, the device PE1 may acquire the third correspondence relationship based on the information flooded by the device P1. For example, the third correspondence relationship includes: MT or flex-algo ID 2, and end.bier corresponding to MT or flex-algo ID 2 on the device P1.

As another example, when the next hop corresponding to the topology identifier 1 acquired by the device PE1 is the device P1, the device PE1 may acquire a third correspondence relationship based on the configuration, where the third correspondence relationship includes the topology identifier having a value of 1 and the end. When the next hop corresponding to the topology identifier obtained by the device PE1 being 2 is the device P1, the device PE1 may obtain a third corresponding relationship based on the configuration, where the third corresponding relationship includes the topology identifier having a value of 2 and end. When the next hop corresponding to the topology identifier with the value of 1 and the topology identifier with the value of 2 obtained by the device PE1 are both the device P1, the device PE1 may obtain a third corresponding relationship based on the configuration, where the third corresponding relationship includes the topology identifier with the value of 1, the topology identifier with the value of 2, and the end. Wherein the topology ID is MT ID or flex-algo ID.

Step 350: the intermediate BFR or BFER obtains BIFT.

Taking the device P1 as an example, the device supporting MT or flex-algo ID 1 acquired by flooding includes: device P2 and device PE 2. The device P1 may calculate the obtained device corresponding to MT or flex-algo ID ═ 1 as the next hop to the device PE 2. For example, the obtained next hop to device PE2 is calculated as device P2. The device P1 that supports MT or flex-algo ID 2 acquired by flooding includes: device P3, device P2, and device PE 2. The device P1 may calculate the obtained device corresponding to MT or flex-algo ID 2 as the next hop to the device PE 2. For example, the next hop obtained to device PE2 is calculated as device P3.

In one possible implementation, the BIFT generated by device P1 is shown in Table 4 below.

TABLE 4 BIFT GENERATED BY DEVICE P1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P2	00001000
4	2	Device P3	00001000

As shown in table 4, the device P1 needs to send the BIER packet to the device PE2 with BFR ID of 4, and the 4 th bit of the bit string (bit string) of the BIER packet from right to left is 1. If the MT or flex-algo ID corresponding to the BIER packet is 1, the device P1 may forward the BIER packet to the device P2. If the MT or flex-algo ID corresponding to the BIER packet is 2, the device P1 may forward the BIER packet to the device P3.

In another possible implementation, the assignment of the BIFT ID is associated with the MT or flex-algo ID. The BIFT ID ═ 1 corresponding to the MT or flex-algo ID ═ 1 generated by the device P1 is shown in table 5 below.

Table 5 BIFT ID 1 generated by device P1

BFR ID	Jump next (neighbor)	FBM
			4	Device P2	00001000

As shown in table 5, if the device P1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 1, and the device P1 may forward the BIER packet to the device P2.

The BIFT ID ═ 1 corresponding to the MT or flex-algo ID ═ 2 generated by the device P1 is shown in table 6 below.

Table 6 BIFT ID 2 generated by device P1

BFR ID	Jump next (neighbor)	FBM
			4	Device P3	00001000

As shown in table 6, if the device P1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device P1 may forward the BIER packet to the device P3.

The method for acquiring the BIFT by other BFRs (e.g., device P2 and device P3) in the BIER domain is similar to the method for acquiring the BIFT by device P1, and is not repeated here. As illustrated by device P2, in one possible implementation, one type of BIFT obtained by device P2 is shown in table 7. In another possible implementation, the BIFT obtained by device P2 is shown in tables 8 and 9.

TABLE 7 BIFT GENERATED BY DEVICE P2

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Equipment PE2	00001000
4	2	Equipment PE2	00001000

As shown in table 7, the device P2 needs to send the BIER packet to the device PE2 with BFR ID of 4, and the 4 th bit of the bit string (bit string) of the BIER packet from right to left is 1. If the MT or flex-algo ID corresponding to the BIER packet is 1, the device P2 may forward the BIER packet to the device PE 2. If the MT or flex-algo ID corresponding to the BIER packet is 2, the device P2 may forward the BIER packet to the device PE 2.

Table 8 the BIFT ID generated by the device P2 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Equipment PE2	00001000

As shown in table 8, if the device P2 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 1, and the device P2 may forward the BIER packet to the device PE 2.

Table 9 BIFT ID generated by device P2 is 2

BFR ID	Jump next (neighbor)	FBM
			4	Equipment PE2	00001000

As shown in table 9, if the device P2 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device P2 may forward the BIER packet to the device PE 2.

Taking the device PE2 as an example, if the BIER message needs to be sent to the device PE2 with the BFR-ID of 4, the device PE2 determines that the next hop with the BFR-ID of 4 is itself. The BIFT generated by the device PE2 based on the flooded information is shown in table 10 below.

TABLE 10 BIFT generated by device PE2

BFR ID	Jump next (neighbor)	FBM
			4	Device PE2	00001000

Table 10 shows that when the bit string of the BIER packet is 1 from the right to the left, the BIER packet is sent to the neighbor of the device PE2 (device PE2), and PE2 indicates that the neighbor of the device PE2 is itself.

Optionally, fig. 12 is another schematic view of a scenario applicable to the embodiment of the present application. As shown in fig. 12, the device PE1 may send the multicast packet carrying the same (S, G) information to different leaf nodes through different topology forwarding paths (a topology forwarding path is a path corresponding to the topology identifier). The leaf node is a BFER, and in the scenario, the BFER includes PE2 and PE 3. The device PE1 may send the multicast packet including the (S, G) information to the device PE2 via path 1, and send the multicast packet including the (S, G) information to the device PE3 via path 2. Path 1 may be, for example, a topology forwarding path corresponding to MT or flex-algo ID ═ 1, and path 2 may be, for example, a topology forwarding path corresponding to MT or flex-algo ID ═ 2.

In the scenario shown in fig. 12, the device PE1 may acquire the topology identifier and its corresponding device through flooding or configuration. As an example, device PE1 may obtain the topology identification and its corresponding device through flooding. The method for the device P1, the device P2, the device P3, and the device PE2 to flood information through TLVs corresponds to the method in step 310 in fig. 3, for details, refer to the method for the above-mentioned devices to flood through TLVs in step 310, and are not described herein again. Device PE3 may flood BIERv6 information (BIER info sub-TLV) using the method used by PE2 in the corresponding embodiment of fig. 3. The BIERv6 information includes its own BFR-id and address, such as BFR-prefix. Device PE3 has an assigned BFR-ID of 8. The TLV flooded by the PE3 may further include a BFR-ID field, where the BFR-ID field carries a value of 8.

As shown in fig. 12, the device PE1 may obtain the BIFT according to the method in step 330 of fig. 3. In one possible implementation, a type of BIFT obtained by the device PE1 is shown in table 11. In another possible implementation, the BIFT obtained by the device PE1 is shown in tables 12 and 13.

TABLE 11 BIFT generated by device PE1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P1	10001000
8	2	Device P1	10001000

As shown in table 11, for the scenario shown in fig. 12, PE3 and PE2 are BFERs belonging to different MTs that need to acquire multicast packets carrying the same (S, G) information, the next hops that PE1 passes to PE3 and PE2 are both devices P1, and the FBM acquired by PE1 may represent 10001000. The forwarding table entry with BFR ID of 4 indicates that the next hop passed by to reach PE2 is P1, and the topological forwarding path needed to pass to reach P1 corresponds to MT or flex-algo ID with value of 1. The forwarding table entry with the BFR ID of 8 indicates that the next hop passed by to reach PE3 is P1, and the topological forwarding path needed to pass to reach P1 corresponds to the MT or flex-algo ID with the value of 2.

Table 12 the BIFT ID generated by the device PE1 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Device P1	10001000

Table 13 the BIFT ID generated by the device PE1 is 2

BFR ID	Jump next (neighbor)	FBM
			8	Device P1	10001000

As shown in table 12, if the device PE1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 1, and the device PE1 may forward the BIER packet to the device P1.

As shown in table 13, if the device PE1 needs to send the BIER packet to the device PE3 with a BFR ID of 8, the 8 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device PE1 may forward the BIER packet to the device P1.

Device P1 may also obtain the BIFT according to the method in step 340 of fig. 3. In one possible implementation, a type of BIFT obtained by device P1 is shown in table 14. In another possible implementation, the BIFT obtained by device P1 is shown in tables 15 and 16.

TABLE 14 BIFT GENERATED BY DEVICE P1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P2	00001000
8	2	Device P3	10000000

As shown in table 14, if the device P1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, and the 4 th bit of the bit string (bit string) of the BIER packet is 1 from right to left, the device P1 may forward the BIER packet to the device P2. If the device P1 needs to send the BIER packet to the device PE3 with a BFR ID of 8, and the 8 th bit of the bit string (bit string) of the BIER packet is 1 from right to left, the device P1 may forward the BIER packet to the device P3.

Table 15 the BIFT ID generated by the device P1 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Device P2	00001000

Table 16 generated by device P1 with a BIFT ID of 2

BFR ID	Jump next (neighbor)	FBM
			8	Device P3	10000000

As shown in table 15, if the device P1 needs to send the BIER packet to the device PE2 with a BFR ID of 4, the 4 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 1, and the device P1 may forward the BIER packet to the device P2.

As shown in table 16, if the device P1 needs to send the BIER packet to the device PE3 with a BFR ID of 8, the 8 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device P1 may forward the BIER packet to the device P3.

Device P2 may also obtain a BIFT by referring to the method in step 340 of fig. 3. Specifically, please refer to the BIFT obtained by the device P2 in step 340, which is not described herein again.

Device P3 may also obtain the BIFT according to the method in step 340 of fig. 3. In one possible implementation, a type of BIFT obtained by device P3 is shown in table 17. In another possible implementation, the BIFT obtained by device P3 is shown in Table 18.

TABLE 17 BIFT generated by device P3

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				8	2	Equipment PE3	10000000

As shown in table 17, if the device P3 needs to send the BIER packet to the device PE3 with BFR ID of 8, and the 8 th bit of the bit string (bit string) of the BIER packet is 1 from right to left, the device P3 may forward the BIER packet to the device PE 3.

Table 18 BIFT generated by device P3 ═ 2

BFR ID	Jump next (neighbor)	FBM
			8	Equipment PE3	10000000

As shown in table 18, if the device P3 needs to send the BIER packet to the device PE3 with a BFR ID of 8, the 8 th bit from right to left of the bit string (bit string) of the BIER packet is 1, the bit ID in the BIER packet is 2, and the device P3 may forward the BIER packet to the device PE 3.

The following describes in detail a specific implementation process of the method for sending a multicast packet with reference to fig. 13, taking the multicast packet as a BIERv6 packet, and taking the scenario shown in fig. 2 as an example.

Fig. 13 is a schematic flowchart of a method for sending a multicast packet according to an embodiment of the present application. As shown in FIG. 13, the method may include steps 1310-.

It should be understood that, for convenience of description, fig. 13 illustrates a method for sending a multicast packet by taking the forwarding path 1 shown in fig. 2 as an example.

Step 1310: the PE1 acquires and sends the BIERv6 message.

For example, the device PE1, serving as an entry device of the BIER domain, needs to determine an MT or a flex-algo ID corresponding to a multicast packet after receiving the multicast packet sent by the multicast source, and performs BIERv6 encapsulation on the multicast packet according to the MT or the flex-algo ID to generate a BIERv6 packet. As an example, the BIERv6 message may include: IPv6 header + BIER header + original multicast message. The BIER header may be included in the IPv6 extension header, and the original multicast packet is used as a payload (payload) of the outer IPv6 header.

In a first possible implementation, the BIERv6 message includes an MT or flex-algo ID. Specifically, the MT or flex-algo ID may be encapsulated in a field of the BIER header. For example, the device PE1 determines that the MT or flex-algo ID corresponding to the multicast packet is 1, and the device PE1 may encapsulate the MT or flex-algo ID 1 in the BIER header. The BIERv6 message includes various ways to implement the MT or the flex-algo ID, for example, the MT or the flex-algo ID may be carried in the proto field of the BIER header, or, for example, the MT or the flex-algo ID may also be carried in the BIFT ID field of the BIER header.

In a second possible implementation manner, if the assignment of the bipt ID generated by the device PE1 is of the granularity < SD, BSL, SI, MT, or flex-algo ID >, for example, the device PE1 determines that the MT or flex-algo ID corresponding to the multicast packet is 1, and assuming that the MT or flex-algo ID is 1 and the bipt ID is 1, the device PE1 may set the value of the bipt ID field of the BIER header to 1.

In a third possible implementation manner, the BIERv6 message may include a forwarding identifier corresponding to the MT or a flex-algo ID. The forwarding identity may be a network slice identity, slice ID, or may also be end. The network slice is a networking-on-demand mode, and can enable an operator to separate a plurality of virtual end-to-end networks on a unified infrastructure. The method is based on a logic concept, and the resources are recombined, wherein the recombination is to select required virtual machines and physical resources for a specific communication service type according to a Service Level Agreement (SLA). In a third implementation, the PE1 further needs to obtain a corresponding relationship between a forwarding identifier and a topology identifier, where the topology identifier may be, for example, an MT or a flex-algo ID. Taking the forwarding identifier as a slice ID as an example, assuming that the slice ID corresponding to MT or flex-algo ID 1 is 1, the device PE1 may encapsulate the slice ID 1 in the BIERv6 message.

For example, when the end.bier identified as device PE1 is forwarded, the end.bier of device PE1 is included in the Destination Address (DA) field of the BIERv6 message acquired by device PE 1. The device PE1 may use its own end to find the third correspondence, and obtain a topology identifier, such as MT or flex-algo ID ═ 1. The device PE1 may use the MT or flex-algo ID ═ 1 to search for the forwarding table entry it obtained. For example, device PE1 may determine the next hop of MT or flex-algo ID ═ 1 as device P1 according to table 1. The device PE1 determines, based on the flooding information, an end.bier corresponding to the MT or flex-algo ID 1 in the device P1, encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the destination field to the device P1.

For example, the device PE1 may look up a forwarding table entry according to the MT or flex-algo ID corresponding to the (S, G) information, and determine that the next hop with the MT or flex-algo ID of 1 is the device P1. The device PE1 determines, based on the flooding information, an end.bier corresponding to the MT or flex-algo ID 1 in the device P1, encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the destination field to the device P1. Subsequent devices P1 and the intermediate BFR may determine the next hop of the forwarding table entry obtained by the subsequent device P1 based on the corresponding relationship between the end.bier in the BIERv6 message and the topology identifier, thereby realizing sending the BIERv6 message to the corresponding BFER. The implementation method avoids adding a topology identifier in the BIERv6 message, and can be better compatible with the equipment in the common BIER domain.

Since the leaf node of the BIERv6 message is the device PE2 and the BFR-ID flooded by the device PE2 is 4, the bit string of the BIERv6 message is 00001000.

Step 1320: and the equipment P1 forwards the BIERv6 message according to the BIFT.

Take the BIERv6 message including MT or flex-algo ID as an example. Assuming that the MT or flex-algo ID included in the BIERv6 message is 1, after receiving the BIERv6 message, the device P1 may determine, according to the bit string of the BIERv6 message being 00001000 and the BIFT shown in table 4, that the next hop corresponding to the MT or flex-algo ID being 1 is the device P2, and the device P1 determines, based on the flooding information, the end.bier corresponding to the MT or flex-algo ID being 1 on the device P2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the end.bier to the device P2.

Taking an end.bier included in the BIERv6 message as an end.bier corresponding to the MT or flex-algo ID 1 on the device P1, the device P1 may determine the corresponding MT or flex-algo ID 1 according to the configuration. And determines the next hop corresponding to MT or flex-algo ID 1 as device P2 according to bit string of BIERv6 message 00001000 and the BIFT shown in table 4, device P1 determines the end.bier corresponding to MT or flex-algo ID 1 on device P2 based on the flooding information, and encapsulates the end.bier in the destination field of the outer IPv6 header of BIERv6 message, and sends it to device P2.

Taking an example that the BIERv6 message includes a slice ID, assuming that the slice ID included in the BIERv6 message is 1, after receiving the BIERv6 message, the device P1 may determine, according to a correspondence between the slice ID and a topology identifier (e.g., an MT or a flex-algo ID), that the MT or the flex-algo ID corresponding to the slice ID is 1. The device P1 determines, according to the bit string of the BIERv6 message being 00001000 and the BIFT shown in table 4, that the next hop corresponding to the MT or flex-algo ID being 1 is the device P2, and the device P1 determines, based on the flooding information, the end.bier corresponding to the MT or flex-algo ID being 1 on the device P2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the destination field to the device P2.

Taking the bit ID of the BIERv6 message as 1 as an example, the device P1 may determine the bit shown in table 5 according to the bit ID of 1. And determines the next hop corresponding to MT or flex-algo ID 1 as device P2 according to bit string of BIERv6 message 00001000 and the BIFT shown in table 5, device P1 determines the end.bier corresponding to MT or flex-algo ID 1 on device P2 based on the flooding information, and encapsulates the end.bier in the destination field of the outer IPv6 header of BIERv6 message, and sends it to device P2.

Step 1330: the device P2 forwards the received message according to the BIFT.

Take the BIERv6 message containing MT or flex-algo ID as an example. Assuming that the MT or flex-algo ID included in the BIERv6 message is 1, after receiving the BIERv6 message, the device P2 may determine, according to the bit string of the BIERv6 message being 00001000 and the BIFT shown in table 7, that the next hop corresponding to the MT or flex-algo ID being 1 is the device PE2, and the device P2 determines, based on the flooding information, the end.bier corresponding to the MT or flex-algo ID being 1 on the device PE2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the end.bier to the device PE 2.

Taking an end.bier included in the BIERv6 message as an end.bier corresponding to the MT or flex-algo ID 1 on the device P2, the device P2 may determine the corresponding MT or flex-algo ID 1 according to the configuration. And determines the next hop corresponding to MT or flex-algo ID 1 as the device PE2 according to the bit string of the BIERv6 message 00001000 and the BIFT shown in table 7, the device P2 determines the end.bier corresponding to MT or flex-algo ID 1 on the device PE2 based on the flooding information, and encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the destination field to the device PE 2.

Taking the slice ID included in the BIERv6 message as an example, assuming that the slice ID included in the BIERv6 message is 1, after receiving the BIERv6 message, the device P2 may determine, according to the correspondence between the slice ID and the topology identifier (e.g., MT or flex-algo ID), that the MT or flex-algo ID corresponding to the slice ID of 1 is 1. The device P2 determines, according to the bit string of the BIERv6 message being 00001000 and the BIFT shown in table 7, that the next hop corresponding to the MT or flex-algo ID being 1 is the device PE2, and the device P2 determines, based on the flooding information, the end.bier corresponding to the MT or flex-algo ID being 1 on the device PE2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the destination field to the device PE 2.

Taking the bit ID of the BIERv6 message as 1 as an example, the device P2 may determine the bit shown in table 8 according to the bit ID of 1. And determines the next hop corresponding to MT or flex-algo ID 1 as the device PE2 according to the bit string of the BIERv6 message 00001000 and the BIFT shown in table 8, the device P2 determines the end.bier corresponding to MT or flex-algo ID 1 on the device PE2 based on the flooding information, encapsulates the end.bier in the destination field of the outer IPv6 header of the BIERv6 message, and sends the end.bier to the device PE 2.

Step 1340: the device PE2 forwards the received message according to the BIFT.

After receiving the BIERv6 message, the device PE2 may determine that the neighbor device of the device PE2 is itself according to that bit string of the BIERv6 message is 00001000 and the bit shown in table 10. Therefore, the device PE2, as a BFER of the BIER domain, may decapsulate the original multicast packet from the BIERv6 packet, and forward the multicast packet to the CE2 device according to the destination address information in the original multicast packet of the inner layer.

Optionally, in the scenario shown in fig. 12, after the device PE1 receives the multicast packet sent by the multicast source, the device PE1 may perform BIERv6 encapsulation on the multicast packet according to the method in step 1310, generate a BIERv6 packet, and forward the BIERv6 packet based on the BIFT acquired by the device PE 1. For example, the device PE1 receives a multicast packet carrying (S1, G1) information. The leaf node corresponding to the multicast packet carrying (S1, G1) information includes a device PE2 and a device PE 3. The multicast packet carrying (S1, G1) information is forwarded to the device PE2 and the device PE3 via paths corresponding to different topology identifiers. The device PE1 needs to send a first BIERv6 message to PE2 through path 1, where bit string of the first BIERv6 message is 00001000. Device PE1 needs to send a second BIERv6 message to PE3 via path 2, where the bit string of the second BIERv6 message is 10000000.

In a first possible implementation, the BIERv6 message includes an MT or flex-algo ID. For example, the MT or flex-algo ID included in the first BIERv6 message is 1, and the MT or flex-algo ID included in the second BIERv6 message is 2. In a second possible implementation manner, for example, assuming that the MT or flex-algo ID is 1 and corresponds to a bit ID of 1, the device PE1 may set a value of a bit ID field of a bit header of the first BIERv6 packet to 1. For another example, assuming that the MT or flex-algo ID 2 corresponds to the bit ID 2, the device PE1 may set the value of the bit ID field of the BIER header of the second BIERv6 message to 2. In a third possible implementation manner, the BIERv6 message may include a forwarding identifier corresponding to the MT or the flex-algo ID. Taking the forwarding identifier as a slice ID as an example, assuming that the slice ID corresponding to MT or flex-algo ID 1 is 1, the device PE1 may encapsulate the slice ID 1 in the first BIERv6 message. Assuming that the slice ID corresponding to MT or flex-algo ID 2 is 2, the device PE1 may encapsulate slice ID 2 in the second BIERv6 message.

For example, when forwarding the end.bier identified as device PE1, device PE1 may further obtain end.bier1 corresponding to the topology identifier having a value of 1 according to the topology identifier (MT or flex-algo ID) having a value of 1. The first BIERv6 message includes end.bier1 of device PE 1. The device PE1 may further obtain end.bier2 corresponding to the topology identifier having the value 2 according to the obtained topology identifier having the value 2 (MT or flex-algo ID). The second BIERv6 message includes end.bier2 of device PE 1. The device PE1 checks the MT or flex-algo ID ═ 1 corresponding to the end.bier1 of the device PE1 included in the first BIERv6 message. The device PE1 may determine the next hop of MT or flex-algo ID 1 as device P1 according to table 1. The device PE1 determines, based on the flooding information, the end.bier3 corresponding to the MT or flex-algo ID 1 in the device P1, and sends the end.bier3 of the device P1 to the device P1 after replacing the end.bier1 of the device PE1 in the first BIERv6 message. The device PE1 checks the MT or flex-algo ID 2 corresponding to the end.bier2 of the device PE1 included in the second BIERv6 message. The device PE1 may determine the next hop of MT or flex-algo ID 2 as device P1 according to table 1. The device PE1 determines, based on the flooding information, the end.bier4 corresponding to the MT or flex-algo ID 2 on the device P1, and sends the end.bier4 of the device P1 to the device P1 after replacing the end.bier2 of the device PE1 in the second BIERv6 message. The device PE1 may obtain the required end.bier or topology identifier through the correspondence between the forwarding identifier and the topology identifier, such as the third correspondence.

For example, the device PE1 may find a forwarding table entry according to the topology identifier with the value 1 and the topology identifier with the value 2 corresponding to the (S1, G1) information, and determine that the MT or flex-algo ID is 1 and the next hop of the MT or flex-algo ID is 2 is the device P1. The device PE1 determines, based on the flooding information, the end.bier3 corresponding to the MT or flex-algo ID 1 in the device P1, encapsulates the end.bier3 in the device P1 in the destination field of the first BIERv6 message, and sends the destination field to the device P1. The device PE1 determines, based on the flooding information, the end.bier4 corresponding to the MT or flex-algo ID 2 on the device P1, encapsulates the end.bier4 of the device P1 in the destination field of the second BIERv6 message, and sends the destination field to the device P1. Subsequent devices P1 and the intermediate BFR may determine the next hop of the forwarding table entry obtained by the subsequent device P1 based on the corresponding relationship between the end.bier in the BIERv6 message and the topology identifier, thereby realizing sending the BIERv6 message to the corresponding BFER. The implementation method avoids adding the topology identifier in the BIERv6 message, and can be better compatible with the equipment in the common BIER domain.

The following description will be made of a method for implementing forwarding by taking the topology identifier carried in the BIERv6 message as an example, specifically as follows:

after receiving the first BIERv6 message and the second BIERv6 message, the device P1 may also send the first BIERv6 message to the device P2 according to the BIFT generated by the device P1, and send the second BIERv6 message to the device P3. For example, the first BIERv6 message includes an MT or flex-algo ID as an example. Assuming that the MT or flex-algo ID included in the first BIERv6 message is 1, after receiving the first BIERv6 message, the device P1 may determine, according to the bit string of the first BIERv6 message being 00001000 and the BIFT shown in table 14, that the next hop corresponding to the MT or flex-algo ID being 1 is device P2, and the device P1 determines, based on the information of the flooding, the end.bier corresponding to the MT or flex-algo ID being 1 on the device P2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the first BIERv6 message, and sends the destination field to the device P2. Take the example that the second BIERv6 message includes the MT or flex-algo ID. Assuming that the MT or flex-algo ID included in the second BIERv6 message is 2, after receiving the second BIERv6 message, the device P1 may determine, according to the bit string of the second BIERv6 message being 10000000 and the BIFT shown in table 14, that the next hop corresponding to the MT or flex-algo ID being 2 is the device P2, and the device P1 determines, based on the flooded information, the end.bier corresponding to the MT or flex-algo ID being 2 on the device P2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the second BIERv6 message, and sends the destination field to the device P2.

After receiving the first BIERv6 message, the device P2 may send the first BIERv6 message to the device PE 2. For example, the first BIERv6 message includes an MT or flex-algo ID as an example. Assuming that the MT or flex-algo ID included in the first BIERv6 message is 1, after receiving the first BIERv6 message, the device P2 may determine, according to the bit string of the first BIERv6 message being 00001000 and table 8, that the next hop corresponding to the MT or flex-algo ID being 1 is the device PE2, and the device P2 determines, based on the flooding information, the end.bier corresponding to the MT or flex-algo ID being 1 on the device PE2, and encapsulates the end.bier in the destination field of the outer IPv6 header of the first BIERv6 message, and sends the end.bier to the device PE 2. The device PE2 receives the first BIERv6 message, and may forward the multicast message in the first BIERv6 message to the CE2 device according to the method in step 1340.

After receiving the second BIERv6 message, device P3 may send the second BIERv6 message to device PE 2. For example, the second BIERv6 message includes an MT or a flex-algo ID. Assuming that the MT or flex-algo ID included in the second BIERv6 message is 2, after receiving the second BIERv6 message, the device P3 may determine, according to the bit string of the second BIERv6 message being 10000000 and the BIFT shown in table 17, that the next hop corresponding to the MT or flex-algo ID being 2 is the device PE3, and the device P3 determines, based on the flooded information, the end.bier corresponding to the MT or flex-algo ID being 2 on the device PE3, and encapsulates the end.bier in the destination field of the outer IPv6 header of the second BIERv6 message, and sends the destination field to the device PE 3. The device PE3 receives the second BIERv6 packet, and may forward the multicast packet in the second BIERv6 packet to the CE3 device. The specific method is similar to step 1340 and will not be described in detail here.

When the BIERv6 message carries a forwarding identifier or an identifier (for example, a BIFT ID) obtained by calculation based on the topology identifier, the intermediate BFR may obtain the corresponding topology identifier according to the forwarding identifier carried in the BIERv6 message or the identifier obtained by calculation based on the topology identifier, and then search for a forwarding table entry by using the obtained topology identifier to obtain a next hop, which is not described in detail in this embodiment of the present application.

It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

The method provided by the embodiment of the present application is described in detail above with reference to fig. 1 to 13, and the embodiment of the apparatus of the present application is described in detail below with reference to fig. 14 to 17. It is to be understood that the description of the method embodiments corresponds to the description of the apparatus embodiments, and therefore reference may be made to the preceding method embodiments for parts not described in detail.

Another network scenario provided in this embodiment of the present application may combine the network scenarios in fig. 2 and fig. 12, and PE1 may reach PE2 via a topology path PE1- > P1- > P2. PE1 may reach PE2 via topological path PE1- > P1- > P3- > P2, and may reach PE3 via PE1 via topological path PE1- > P1- > P3. The topology path PE1- > P1- > P3- > P2- > PE2 and the topology path PE1- > P1- > P3- > PE3 correspond to the same topology identifier, such as the topology identifier with the value of 2. The topology path PE1- > P1- > P2- > PE2 and the topology path PE1- > P1- > P3- > PE3 correspond to different topology identifications. The topology path PE1- > P1- > P2- > PE2 corresponds to the topology identifier with the value 1. In this network scenario, the method for flooding the device PE2 may be referred to in the corresponding embodiment of fig. 3. The method for flooding the equipment PE3 can be seen in the corresponding embodiment of fig. 3. The method for obtaining the BIFT by the device PE1 can be referred to as the method adopted by the device PE1 in the corresponding embodiment of fig. 3, and is not described herein again. PE1 was obtained as in tables 19 to 21 below.

TABLE 19 first BIFT generated by device PE1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P1	10001000
4	2	Device P1	10001000
				8	2	Device P1	10001000

The value of 1 corresponds to the topology ID of table 20. The value of 2 corresponds to the topology ID in table 21.

Table 20 the BIFT ID generated by the device PE1 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Device P1	10001000

Table 21 BIFT ID generated by device PE1 is 2

BFR ID	Jump next (neighbor)	FBM
			4	Device P1	10001000
8	Device P1	10001000

The method for obtaining the BIFT by the device P1 can be referred to the method adopted by the device P1 in the corresponding embodiment of fig. 3, and is not described herein again. P1 was obtained as in tables 22 to 24 below.

TABLE 22 BIFT GENERATED BY DEVICE P1

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	1	Device P2	00001000
4	2	Device P3	10001000
				8	2	Device P3	10001000

Table 23 BIFT ID generated by device P1 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Device P2	00001000

Table 24 the BIFT ID generated by the device P1 is 2

BFR ID	Jump next (neighbor)	FBM
			4	Device P3	10001000
8	Device P3	10001000

The method for obtaining the BIFT by the device P2 can be referred to the method adopted by the device P2 in the corresponding embodiment of fig. 3, and is not described herein again. P2 can be obtained as in tables 25 to 27 below.

TABLE 25 BIFT GENERATED BY DEVICE P2

Table 26 the BIFT ID generated by the device P2 is 1

BFR ID	Jump next (neighbor)	FBM
			4	Equipment PE2	00001000

Table 27 BIFT ID generated by device P2 is 2

BFR ID	Jump next (neighbor)	FBM
			4	Equipment PE2	00001000

The method for obtaining the BIFT by the device P3 can be referred to the method adopted by the device P3 in the corresponding embodiment of fig. 3, and is not described herein again. P3 was obtained as in tables 28 to 29 below.

TABLE 28 BIFT GENERATED BY DEVICE P3

BFR ID	MT or flex-algo ID	Jump next (neighbor)	FBM
				4	2	Device P2	00001000
8	2	Equipment PE3	10000000

TABLE 29 BIFT 2 generated by device P3

BFR ID	Jump (neighbor)	FBM
			4	Device P2	00001000
8	Equipment PE3	10000000

The method for sending the BIER packet by the device PE1, the device P1, the device P2, and the device P3 according to the obtained forwarding table entry may refer to corresponding contents in the corresponding embodiment of fig. 13, and details are not described herein.

Fig. 14 is a schematic structural diagram of an apparatus 1400 for determining a correspondence relationship according to an embodiment of the present application. The apparatus 1400 for determining correspondence shown in fig. 14 may perform the corresponding steps of the method for determining correspondence of the above-described embodiment. As shown in fig. 14, the apparatus 1400 for determining a corresponding relationship includes: the acquisition module 1410 is configured to acquire a data item,

an obtaining module 1410, configured to obtain a topology identifier and a device corresponding to the topology identifier;

the obtaining module 1410 is further configured to obtain a first corresponding relationship, where the first corresponding relationship includes multicast source group (S, G) information and at least one next hop, and any next hop in the at least one next hop is a device corresponding to the topology identifier, which is obtained through calculation.

Optionally, the topology identifier is a multi-topology identifier MT ID or a flexible algorithm identifier flex-algo ID.

Optionally, the obtaining module 1410 is specifically configured to: acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identifier; and acquiring a first forwarding table entry according to the topology identifier and the corresponding device, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

Optionally, the apparatus 1400 further comprises: a receiving module 1420, a processing module 1430, a sending module 1440, and a receiving module 1420, configured to receive a first multicast packet, where the first multicast packet includes the (S, G) information;

a processing module 1430, configured to obtain the topology identifier according to the second correspondence and the (S, G) information included in the first multicast packet;

the processing module 1430 is further configured to obtain a second multicast packet according to the topology identifier and the first multicast packet;

the processing module 1430 is further configured to obtain the at least one next hop according to the topology identifier included in the first forwarding table entry and the second multicast packet;

a sending module 1440, configured to send the second multicast packet to the at least one next hop.

Optionally, the second multicast packet includes the first multicast packet and the topology identifier.

Optionally, the processing module 1430 is specifically configured to: obtaining a forwarding identifier according to a third corresponding relationship and the topology identifier, wherein the third corresponding relationship comprises the topology identifier and the forwarding identifier; and obtaining the second multicast message according to the forwarding identifier and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

Optionally, the obtaining module 1410 is further configured to: acquiring the forwarding identifier and the topology identifier; and acquiring the third corresponding relation according to the forwarding identifier and the topology identifier.

Optionally, the forwarding identifier is a slice identifier slice ID or a destination address included in the second multicast packet.

Optionally, the obtaining module 1410 is specifically configured to: acquiring a fourth corresponding relation, wherein the fourth corresponding relation comprises the (S, G) information and an identifier obtained by calculation based on the topological identifier; and acquiring a second forwarding table corresponding to the identifier obtained based on the topology identifier calculation, wherein the second forwarding table comprises the at least one next hop.

Optionally, the receiving module 1420 is configured to receive a first multicast packet, where the first multicast packet includes the (S, G) information; a processing module 1430, configured to obtain the identifier obtained by calculation based on the topology identifier according to the fourth correspondence and the (S, G) information included in the first multicast message; the processing module 1430 is further configured to obtain a second multicast packet according to the first multicast packet and the identifier obtained through calculation based on the topology identifier, where the second multicast packet includes the first multicast packet and the identifier obtained through calculation based on the topology identifier; a sending module 1440, configured to send the second multicast packet to the at least one next hop included in the second forwarding entry.

Optionally, the second multicast packet is a bit index explicit copy BIERv6 packet based on the sixth version of the internet protocol.

Fig. 15 is a schematic structural diagram of an apparatus 1500 for sending a multicast packet according to an embodiment of the present application. The apparatus 1500 for sending multicast messages shown in fig. 15 may perform corresponding steps in the method for sending multicast messages according to the foregoing embodiment. As shown in fig. 15, the apparatus 1500 for sending a multicast packet includes: a receiving module 1510, a processing module 1520, a transmitting module 1530,

a receiving module 1510, configured to receive a first multicast packet, where the first multicast packet includes multicast source group (S, G) information;

a processing module 1520, configured to obtain at least one next hop according to a first corresponding relationship and the (S, G) information included in the first multicast message, where the first corresponding relationship includes the (S, G) information and the at least one next hop, and any next hop in the at least one next hop is a device corresponding to the topology identifier, which is obtained through calculation;

the processing module 1520, further configured to obtain, based on the first multicast packet, a second multicast packet corresponding to the topology identifier, where the second multicast packet includes the first multicast packet;

a sending module 1530, configured to send the second multicast packet to the at least one next hop.

Optionally, the apparatus 1500 further comprises: the obtaining module 1540 of the data to be obtained,

an obtaining module 1540, configured to obtain the topology identifier and the corresponding device;

the obtaining module 1540 is further configured to obtain the first corresponding relationship based on the (S, G) information, the topology identifier, and the device corresponding to the topology identifier.

Optionally, the obtaining module 1540 is specifically configured to: acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identifier; and acquiring a first forwarding table entry according to the topology identifier and the device corresponding to the topology identifier, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

Optionally, the processing module 1520 is specifically configured to: obtaining the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message; obtaining the second multicast message according to the topology identifier and the first multicast message; and acquiring the at least one next hop according to the topology identifier and the first forwarding table entry included in the second corresponding relationship.

Optionally, the second multicast packet further includes the topology identifier.

Optionally, the obtaining module 1540 is further configured to: acquiring a forwarding identifier based on the topology identifier and a third corresponding relationship, wherein the third corresponding relationship comprises the forwarding identifier and the topology identifier; acquiring the forwarding identifier based on the topology identifier and the third corresponding relation; the processing module 1520 is specifically configured to: and obtaining the second multicast message based on the forwarding identifier and the first multicast message, wherein the second multicast message also comprises the forwarding identifier.

Optionally, the forwarding identifier is a slice identifier slice ID or a destination address of the second multicast packet.

Optionally, the obtaining module 1540 is specifically configured to: acquiring a fourth corresponding relation, wherein the fourth corresponding relation comprises the (S, G) information and an identifier obtained by calculation based on the topological identifier; and acquiring a second forwarding table corresponding to the identifier obtained by calculation based on the topology identifier, wherein the second forwarding table comprises the at least one next hop.

Optionally, the obtaining module 1540 is specifically configured to: obtaining an identifier obtained based on the topology identifier calculation based on the fourth correspondence and the (S, G) information included in the first multicast message; and acquiring the at least one next hop included in the second forwarding table entry according to the identifier obtained by calculation based on the topology identifier.

Optionally, the processing module 1520 is specifically configured to: obtaining the identifier obtained by calculation based on the topology identifier according to the fourth corresponding relationship and the (S, G) information included in the first multicast message; and obtaining a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message also comprises the identifier obtained by calculation based on the topology identifier.

Fig. 16 is a schematic hardware configuration diagram of the first network device 2000 according to the embodiment of the present application. The first network device 2000 shown in fig. 16 may execute the method for sending a multicast packet and/or the method for determining a corresponding relationship according to the foregoing embodiments.

As shown in fig. 16, the first network device 2000 includes a processor 2001, a memory 2002, an interface 2003, and a bus 2004. Wherein the interface 2003 may be implemented by wireless or wired means, specifically a network card. The processor 2001, the memory 2002, and the interface 2003 are connected by a bus 2004.

The interface 2003 may specifically include a transmitter and a receiver for the first network device to implement the transceiving described above.

The processor 2001 is configured to execute the processing performed by the first network device in the above embodiments. The memory 2002 includes an operating system 20021 and an application 20022 for storing programs, codes, or instructions that when executed by a processor or hardware device may perform the BFIR-related processes of the method embodiments. Alternatively, the memory 2002 may include a read-only memory (ROM) and a Random Access Memory (RAM). Wherein the ROM includes a basic input/output system (BIOS) or an embedded system; the RAM includes an application program and an operating system. When the first network device 2000 needs to be operated, the first network device 2000 is booted to enter a normal operation state by booting through a BIOS that is solidified in a ROM or a bootloader boot system in an embedded system. After the first network device 2000 enters the normal operation state, the application program and the operating system that are run in the RAM, thereby completing the processing procedures related to the first network device R2000 in the method embodiment.

It will be appreciated that fig. 16 shows only a simplified design of the first network device 2000. In practical applications, the first network device may comprise any number of interfaces, processors or memories.

Fig. 17 is a schematic hardware configuration diagram of another first network device 2100 according to an embodiment of the present application. The first network device 2100 shown in fig. 17 may execute the method for sending a multicast packet and/or the method for determining a corresponding relationship according to the foregoing embodiments.

As illustrated in fig. 17, the first network device 2100 includes: a main control board 2110, an interface board 2130, a switch board 2120 and an interface board 2140. The main control board 2110, the interface boards 2130 and 2140, and the switch board 2120 are connected to the system backplane through the system bus to realize intercommunication. The main control board 2110 is used for completing functions such as system management, device maintenance, and protocol processing. The switch network board 2120 is used to complete data exchange between interface boards (interface boards are also called line cards or service boards). The interface boards 2130 and 2140 are used to provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and implement forwarding of packets.

The interface board 2130 may include a central processor 2131, a forwarding entry memory 2134, a physical interface card 2133, and a network processor 2132. The central processing unit 2131 is used for controlling and managing the interface board and communicating with the central processing unit on the main control board. The forwarding entry memory 2134 is used to hold entries, e.g., BIFT as described above. Physical interface card 2133 is used to complete the reception and transmission of traffic.

It should be understood that operations on the interface board 2140 in the embodiment of the present application are the same as those of the interface board 2130, and are not described again for brevity.

It should be understood that the first network device 2100 in this embodiment may correspond to the functions and/or various steps of the foregoing method embodiments, and are not described herein again.

In addition, it should be noted that there may be one or more main control boards, and when there are multiple main control boards, the main control board may include an active main control board and a standby main control board. The interface board may have one or more blocks, and the stronger the data processing capability of the BFIR, the more interface boards are provided. There may also be one or more physical interface cards on an interface board. The exchange network board may not have one or more blocks, and when there are more blocks, the load sharing redundancy backup can be realized together. Under the centralized forwarding architecture, the first network device may not need the switching network board, and the interface board undertakes the processing function of the service data of the whole system. The first network device may have at least one switching network board under the distributed forwarding architecture, and the switching network board realizes data exchange among a plurality of interface boards, thereby providing large-capacity data exchange and processing capability. Therefore, the data access and processing capabilities of the first network device of the distributed architecture are greater than those of the centralized architecture. Which architecture is specifically adopted depends on the specific networking deployment scenario, and is not limited herein.

An embodiment of the present application further provides a computer-readable medium, where the computer-readable medium stores program codes, and when the computer program codes run on a computer, the computer is caused to execute the method executed by the first network device. These computer-readable memories include, but are not limited to, one or more of the following: read-only memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Flash memory, Electrically EPROM (EEPROM), and hard drive (hard drive).

An embodiment of the present application further provides a chip system, which is applied to a first network device, and the chip system includes: the chip system comprises at least one processor, at least one memory and an interface circuit, wherein the interface circuit is responsible for information interaction between the chip system and the outside, the at least one memory, the interface circuit and the at least one processor are interconnected through lines, and instructions are stored in the at least one memory; the instructions are executable by the at least one processor to perform the operations of the BFIR in the method of the above aspects.

In a specific implementation process, the chip may be implemented in the form of a Central Processing Unit (CPU), a Micro Controller Unit (MCU), a Micro Processing Unit (MPU), a Digital Signal Processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), or a Programmable Logic Device (PLD).

The present invention also provides a computer program product, which is applied to a first network device, and includes a series of instructions, when executed, to perform the operations of the first network device in the method of the above aspects.

An embodiment of the present application further provides a system, including: the first network device.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of determining correspondence, the method comprising:

the method comprises the steps that a first network device obtains a topology identifier and a device corresponding to the topology identifier;

the first network device obtains a first corresponding relationship, where the first corresponding relationship includes multicast source group (S, G) information and at least one next hop, and any one of the at least one next hop is a device corresponding to the topology identifier obtained through calculation.

2. The method according to claim 1, wherein the topology identification is a multi-topology identification (MT ID) or a flexible algorithm identification (flex-algo ID).

3. The method of claim 1 or 2, wherein the first network device obtaining the first correspondence comprises:

the first network device obtains a second corresponding relationship, wherein the second corresponding relationship comprises the (S, G) information and the topology identifier;

and the first network equipment acquires a first forwarding table item according to the topology identifier and the corresponding equipment, wherein the first forwarding table item comprises the topology identifier and the at least one next hop.

4. The method of claim 3, further comprising:

the first network equipment receives a first multicast message, wherein the first multicast message comprises the (S, G) information;

the first network device obtains the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message;

the first network equipment obtains a second multicast message according to the topology identifier and the first multicast message;

the first network device obtains the at least one next hop according to the first forwarding table entry and the topology identifier;

and the first network equipment sends the second multicast message to the at least one next hop.

5. The method of claim 4, wherein the second multicast packet comprises the first multicast packet and the topology identifier; or

The second multicast message comprises the first multicast message and the address of the equipment corresponding to the topology identifier.

6. The method according to claim 4, wherein the obtaining, by the first network device, the second multicast packet according to the topology identifier and the first multicast packet includes:

the first network equipment obtains a forwarding identifier according to a third corresponding relation and the topology identifier, wherein the third corresponding relation comprises the topology identifier and the forwarding identifier;

and the first network equipment acquires the second multicast message according to the forwarding identifier and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

7. The method of claim 6, further comprising:

the first network equipment acquires the forwarding identifier and the topology identifier;

and the first network equipment acquires the third corresponding relation according to the forwarding identifier and the topology identifier.

8. The method according to claim 6 or 7, wherein the forwarding identifier is a slice identifier slice ID or a destination address included in the second multicast message.

9. The method of claim 1, wherein the first network device obtaining the first correspondence comprises:

the first network device obtains a fourth corresponding relationship, wherein the fourth corresponding relationship comprises the (S, G) information and an identifier obtained by calculation based on the topology identifier;

and the first network equipment acquires a second forwarding table corresponding to the identifier obtained by calculation based on the topology identifier, wherein the second forwarding table comprises the at least one next hop.

10. The method of claim 9, further comprising:

the first network device obtains the identifier obtained by calculation based on the topology identifier according to the fourth corresponding relationship and the (S, G) information included in the first multicast packet;

the first network equipment obtains a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message comprises the first multicast message and the identifier obtained by calculation based on the topology identifier;

and the first network equipment sends the second multicast message to the at least one next hop included in the second forwarding table item.

11. The method according to any of claims 1 to 10, wherein the second multicast packet is an explicit copy BIERv6 packet based on a bit index of the sixth version of the internet protocol.

12. A method for sending multicast messages is characterized by comprising the following steps:

a first network device receives a first multicast message, wherein the first multicast message comprises multicast source group (S, G) information;

the first network device obtains at least one next hop according to a first corresponding relationship and the (S, G) information included in the first multicast message, wherein the first corresponding relationship includes the (S, G) information and the at least one next hop, and any one next hop in the at least one next hop is a device which is obtained through calculation and corresponds to the topology identifier;

the first network equipment acquires a second multicast message corresponding to the topology identifier based on the first multicast message;

13. The method according to claim 12, wherein the topology identification is a multi-topology identification MT ID or a flexible algorithm identification flex-algo ID.

14. The method according to claim 12 or 13, characterized in that the method further comprises:

the first network equipment acquires the topology identifier and corresponding equipment;

and the first network equipment acquires the first corresponding relation based on the (S, G) information, the topology identifier and the corresponding equipment thereof.

15. The method of claim 14, wherein said obtaining the first correspondence comprises:

and the first network equipment acquires a first forwarding table item according to the topology identifier and the equipment corresponding to the topology identifier, wherein the first forwarding table item comprises the topology identifier and the at least one next hop.

16. The method of claim 15, wherein the obtaining, by the first network device, the second multicast packet corresponding to the topology identifier based on the first multicast packet comprises:

the first network equipment obtains the second multicast message according to the topology identifier and the first multicast message;

the first network device obtaining, according to the first correspondence and the (S, G) information included in the first multicast packet, at least one next hop includes: and the first network device acquires the at least one next hop according to the topology identifier and the first forwarding table entry included in the second corresponding relationship.

17. The method of claim 16, wherein the second multicast packet comprises the topology identifier and the first multicast packet; or

18. The method of claim 16, further comprising:

the first network device obtains a forwarding identifier based on the topology identifier and a third corresponding relationship, wherein the third corresponding relationship comprises the forwarding identifier and the topology identifier;

the obtaining, by the first network device, the second multicast packet based on the topology identifier and the first multicast packet includes:

the first network device obtains the forwarding identifier based on the topology identifier and the third corresponding relationship;

the first network device obtains the second multicast packet based on the forwarding identifier and the first multicast packet, where the second multicast packet includes the first multicast packet and the forwarding identifier.

19. The method of claim 18, wherein the forwarding identifier is a slice identifier slice ID or a destination address of the second multicast packet.

20. The method of claim 14, wherein the first network device obtaining the first corresponding relationship based on the (S, G) information, the topology identifier and its corresponding device comprises:

21. The method according to claim 20, wherein the obtaining, by the first network device, at least one next hop according to the first correspondence and the (S, G) information included in the first multicast packet comprises:

the first network device obtains an identifier obtained by calculation based on the topology identifier based on the fourth correspondence and the (S, G) information included in the first multicast packet;

and the first network equipment acquires the at least one next hop included in the second forwarding table entry according to the identifier obtained by calculation based on the topology identifier.

22. The method of claim 20, wherein the obtaining, by the first network device, a second multicast packet corresponding to the topology identifier based on the first multicast packet comprises:

and the first network equipment acquires a second multicast message according to the first multicast message and the identifier calculated and acquired based on the topology identifier, wherein the second multicast message comprises the first multicast message and the identifier calculated and acquired based on the topology identifier.

23. The method according to any of claims 12 to 22, wherein the second multicast packet is an explicit copy BIERv6 packet based on a bit index of the sixth version of the internet protocol.

24. An apparatus for determining correspondence, the apparatus comprising:

25. The apparatus according to claim 24, wherein the topology identification is a multi-topology identification MT ID or a flexible algorithm identification flex-algo ID.

26. The apparatus according to claim 24 or 25, wherein the obtaining module is specifically configured to:

acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identification;

and acquiring a first forwarding table entry according to the topology identifier and the corresponding device, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

27. The apparatus of claim 26, further comprising:

a receiving module, configured to receive a first multicast packet, where the first multicast packet includes the (S, G) information;

the processing module is further configured to obtain the at least one next hop according to the first forwarding table entry and the topology identifier;

28. The apparatus of claim 27, wherein the second multicast packet comprises the first multicast packet and the topology identifier; or

29. The apparatus of claim 27, wherein the processing module is specifically configured to:

obtaining a forwarding identifier according to a third corresponding relationship and the topology identifier, wherein the third corresponding relationship comprises the topology identifier and the forwarding identifier;

and obtaining the second multicast message according to the forwarding identifier and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

30. The apparatus of claim 29, wherein the obtaining module is further configured to:

acquiring the forwarding identifier and the topology identifier;

and acquiring the third corresponding relation according to the forwarding identifier and the topology identifier.

31. The apparatus according to claim 29 or 30, wherein the forwarding identifier is a slice identifier slice ID or a destination address included in the second multicast message.

32. The apparatus of claim 24, wherein the obtaining module is specifically configured to:

acquiring a fourth corresponding relation, wherein the fourth corresponding relation comprises the (S, G) information and an identifier obtained by calculation based on the topological identifier;

and acquiring a second forwarding table corresponding to the identifier obtained by calculation based on the topology identifier, wherein the second forwarding table comprises the at least one next hop.

33. The apparatus of claim 32, further comprising:

34. The apparatus according to any of claims 24 to 33, wherein the second multicast packet is an explicit copy BIERv6 packet based on a bit index of the sixth version of the internet protocol.

35. An apparatus for sending multicast messages, comprising:

the multicast source group receiving module is used for receiving a first multicast message, wherein the first multicast message comprises multicast source group (S, G) information;

a processing module, configured to obtain at least one next hop according to a first corresponding relationship and the (S, G) information included in the first multicast message, where the first corresponding relationship includes the (S, G) information and the at least one next hop, and any next hop in the at least one next hop is a device corresponding to the topology identifier, which is obtained through calculation;

the processing module is further configured to obtain a second multicast packet corresponding to the topology identifier based on the first multicast packet;

36. The apparatus according to claim 35, wherein the topology identification is a multi-topology identification MT ID or a flexible algorithm identification flex-algo ID.

37. The apparatus of claim 35 or 36, further comprising:

38. The apparatus of claim 37, wherein the obtaining module is specifically configured to:

acquiring a second corresponding relation, wherein the second corresponding relation comprises the (S, G) information and the topology identifier;

and acquiring a first forwarding table entry according to the topology identifier and the device corresponding to the topology identifier, wherein the first forwarding table entry comprises the topology identifier and the at least one next hop.

39. The apparatus of claim 38, wherein the processing module is specifically configured to:

obtaining the topology identifier according to the second corresponding relationship and the (S, G) information included in the first multicast message;

obtaining the second multicast message according to the topology identifier and the first multicast message;

and acquiring the at least one next hop according to the topology identifier and the first forwarding table entry included in the second corresponding relationship.

40. The apparatus of claim 39, wherein the second multicast packet comprises the topology identifier and the first multicast packet; or

41. The apparatus of claim 39, wherein the obtaining module is further configured to:

acquiring a forwarding identifier based on the topology identifier and a third corresponding relationship, wherein the third corresponding relationship comprises the forwarding identifier and the topology identifier;

acquiring the forwarding identifier based on the topology identifier and the third corresponding relation;

the processing module is specifically configured to: and obtaining the second multicast message based on the forwarding identifier and the first multicast message, wherein the second multicast message comprises the first multicast message and the forwarding identifier.

42. The apparatus of claim 41, wherein the forwarding identifier is a slice identifier (slice ID) or a destination address of the second multicast packet.

43. The apparatus of claim 37, wherein the obtaining module is specifically configured to:

44. The apparatus of claim 43, wherein the obtaining module is specifically configured to:

obtaining an identifier obtained based on the topology identifier calculation based on the fourth correspondence and the (S, G) information included in the first multicast message;

and acquiring the at least one next hop included in the second forwarding table entry according to the identifier obtained by calculation based on the topology identifier.

45. The apparatus according to claim 44, wherein the processing module is specifically configured to:

obtaining the identifier obtained by calculation based on the topology identifier according to the fourth corresponding relationship and the (S, G) information included in the first multicast message;

and obtaining a second multicast message according to the first multicast message and the identifier obtained by calculation based on the topology identifier, wherein the second multicast message also comprises the identifier obtained by calculation based on the topology identifier.

46. The apparatus according to any of claims 35 to 45, wherein the second multicast packet is an explicit copy BIERv6 packet based on a bit index of the sixth version of the Internet protocol.

47. A system comprising means for determining correspondence according to any of claims 24 to 34 and/or means for sending multicast messages according to any of claims 35 to 46.