Method and apparatus for sending multicast messages

Abstract

The application provides a method and device for sending multicast messages. In the method, an entry device acquires the identification of a region corresponding to a received multicast message; the entry device obtains the address of an intermediate device for forwarding the multicast message to the region based on the identification of the region and a forwarding table item, the forwarding table item including the identification of the region and the address of the intermediate device; and the entry device sends the multicast message based on the address of the intermediate device. An intermediate device acquires the identification of a region corresponding to a multicast message based on the multicast message from an entry device; the intermediate device obtains the address of a next-hop device based on the identification of the region and a forwarding table item, the forwarding table item including the identification of the region and the address of the next-hop device; and the intermediate device sends the multicast message based on the address of the next-hop device. The method can save network resources.

Description

[0001] This application claims priority to Chinese Patent Application No. 202010393103.4, filed with the State Intellectual Property Office of China on May 11, 2020, entitled "A Multicast Forwarding Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and more specifically, to methods and apparatus for transmitting multicast messages. Background Technology

[0003] Bit-indexed Explicit Replication (BIER) is a commonly used multicast architecture. The Internet Engineering Task Force (IETF) standard defines the BIER header encapsulation format and encapsulation method. BIER encapsulation can be based on, for example, Multi-Protocol Label Switching (MPLS), Ethernet, and Internet Protocol version 6 (IPv6). IPv6-based BIER (or BIERv6) offers good flexibility in deployment across Autonomous System (AS) domains.

[0004] In BIERv6-based cross-domain multicast scenarios, multicast sources can communicate with Provider Edge (PE) devices in the backbone network, and multiple multicast receivers can communicate with multiple PE devices in the metropolitan area network. PE devices communicating with the multicast source can send multicast packets to PE devices communicating with multicast receivers through Autonomous System Boundary Routers (ASBRs) in the backbone network. In BIERv6-based multicast scenarios, any PE device can be assigned a Bit Forwarding Router (BFR) identifier (BFR-id). When PE devices communicating with multicast receivers are in different AS domains and need to receive multicast packets from a certain multicast source, the PE devices communicating with the multicast source need to copy multiple multicast packets and send them to the AS domain where the PE devices communicating with the multicast receivers reside, which wastes network resources. Summary of the Invention

[0005] This application provides a method and apparatus for sending multicast messages, which can save network resources.

[0006] In a first aspect, a method for sending multicast messages is provided. The method includes: an intermediate device obtaining an identifier of a region corresponding to a multicast message from an ingress device; the intermediate device obtaining the address of a next-hop device based on the region identifier and a forwarding table entry, wherein the forwarding table entry contains the region identifier and the address of the next-hop device; and the intermediate device sending the multicast message based on the address of the next-hop device.

[0007] In the above method, the intermediate device acts as a relay node between one or more egress devices and the ingress device. After receiving multicast packets from the ingress device, it forwards the multicast packets based on the identified area. Unlike typical cross-domain multicast scenarios where multicast packet copying and forwarding starts from the PE device communicating with the multicast source, this method locates the intermediate device as the relay node based on the area identifier. The intermediate device then sends the packets to the next-hop device, which performs the multicast packet copying and forwarding. This saves traffic between the ingress device and the intermediate device (by consuming less network resources to send the copied multicast packets). Optionally, if the next-hop device is not an egress device, it further saves traffic between the intermediate device and the next-hop device (by consuming less network resources to send the copied multicast packets).

[0008] In one possible implementation, the area comprises one or more AS domains. The next-hop device can be an egress device or an ASBR within the AS domain where the egress device resides. The egress device is an edge device capable of communicating with multicast receivers, also known as a bit-forwarding egress router (BFER). The ingress device can be an edge device communicating with the multicast source, also known as a bit-forwarding ingress router (BFIR). Intermediate and ingress devices are devices in a BIER cross-domain network scenario.

[0009] In one possible implementation, the multicast message includes a region identifier. The intermediate device obtains the region identifier corresponding to the multicast message based on the multicast message from the ingress device, which includes: the intermediate device obtaining the region identifier from the multicast message.

[0010] In one possible implementation, the multicast message includes the identifier of the intermediate device. The intermediate device, based on the multicast message from the ingress device, obtains the identifier of the region corresponding to the multicast message. This includes the intermediate device retrieving the identifier of the region corresponding to its identifier from the multicast message. In this implementation, a mapping relationship can be pre-configured on the intermediate device, including the identifier of the intermediate device and the identifier of the region. This approach offers better compatibility and requires minimal modification or processing of the multicast message.

[0011] In one possible implementation, the method further includes: the intermediate device receiving the address of the next-hop device and the identifier of the region to which the next-hop device belongs from the next-hop device; the intermediate device obtaining forwarding table entries based on the region identifier and the address of the next-hop device.

[0012] In one possible implementation, the method further includes: the intermediate device receiving the identifier of the next-hop device and the identifier of the region to which the next-hop device belongs from the next-hop device; the intermediate device obtaining the address of the next-hop device based on the identifier of the next-hop device; and the intermediate device obtaining forwarding table entries based on the identifier of the region and the address of the next-hop device.

[0013] In one possible implementation, the method further includes: an intermediate device receiving a range of Bit Forwarding Router (BFR) identifiers within the destination AS domain sent by a next-hop device, wherein the destination AS domain is the AS domain to which the next-hop device belongs within the area, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

[0014] In one possible implementation, the multicast message also includes a range of BFR identifiers, and the method further includes: the intermediate device determining forwarding entries based on the region identifier and the range of BFR identifiers.

[0015] In one possible implementation, the method further includes: the intermediate device sending its address and the identifier of the region to which the intermediate device belongs to the entry device.

[0016] In one possible implementation, the method further includes: the intermediate device sending the range of BFR identifiers within the AS domain to which the intermediate device belongs to the ingress device, wherein the AS domain to which the intermediate device belongs is contained within the region to which the intermediate device belongs.

[0017] Secondly, a method for sending multicast messages is provided. The method includes: an ingress device obtaining the identifier of the region corresponding to the received multicast message; the ingress device obtaining the address of an intermediate device for forwarding the multicast message to the region based on the region identifier and forwarding table entries, the forwarding table entries including the region identifier and the address of the intermediate device; and the ingress device sending the multicast message based on the address of the intermediate device.

[0018] In the above method, the ingress device can send multicast packets to the intermediate device based on the region identifier, without performing multicast packet copying and forwarding as in typical cross-domain multicast scenarios, thus saving traffic between itself and the intermediate device (consuming less network resources to send copied multicast packets). The intermediate device and the ingress device are devices in the BIER cross-domain network scenario.

[0019] In one possible implementation, the method further includes: the entry device receiving the address and region identifier of the intermediate device sent by the intermediate device; and the entry device obtaining forwarding table entries based on the address and region identifier of the intermediate device.

[0020] In one possible implementation, the method further includes: the entry device receiving the identifier of the intermediate device and the identifier of the region sent by the intermediate device; the entry device determining the address of the intermediate device based on the identifier of the intermediate device; and the entry device obtaining forwarding table entries based on the address of the intermediate device and the identifier of the region.

[0021] In one possible implementation, the method further includes: the ingress device receiving the range of BFR identifiers within the destination Autonomous System (AS) domain sent by the intermediate device, wherein the destination AS domain is the AS domain to which the multicast message contained in the region needs to be sent, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

[0022] In one possible implementation, the method further includes: the ingress device determining forwarding entries based on the scope and region identifiers of the BFR identifier within the destination AS domain.

[0023] In one possible implementation, the multicast message contains an identifier of a region. The process by which the ingress device obtains the identifier of the region corresponding to the received multicast message includes: the ingress device obtaining the identifier of the region from the multicast message; or the multicast message contains an identifier of an intermediate device and an identifier of a region. The process by which the ingress device obtains the identifier of the region corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message includes: the ingress device obtaining the identifier of the region corresponding to the identifier of the intermediate device.

[0024] In a third aspect, a method for generating forwarding table entries is provided. The method includes: an intermediate device obtaining from a next-hop device an identifier of the region to which the next-hop device belongs and the address of the next-hop device; the intermediate device obtaining forwarding table entries based on the region identifier and the address of the next-hop device.

[0025] In the above method, the intermediate device can obtain the forwarding table entries for forwarding multicast packets based on the parameters obtained from the next-hop device, which reduces the complexity of manual configuration after changes in network structure and allows for more flexible and faster refreshing of the table entries for forwarding multicast packets.

[0026] In one possible implementation, the intermediate device obtaining the identifier of the region to which the next-hop device belongs and the address of the next-hop device from the next-hop device includes: the intermediate device receiving the address of the next-hop device and the identifier of the region sent by the next-hop device.

[0027] In one possible implementation, the intermediate device obtaining the identifier of the region to which the next-hop device belongs and the address of the next-hop device from the next-hop device includes: the intermediate device receiving the identifier of the next-hop device and the identifier of the region sent by the next-hop device; and the intermediate device obtaining the address of the next-hop device based on the identifier of the next-hop device. The identifier of the next-hop device can be other information or parameters used to identify the next-hop device besides the address. The intermediate device can convert the identifier of the next-hop device into the address of the next-hop device according to a preset algorithm, or the intermediate device can obtain the address of the next-hop device according to a correspondence between the identifier of the next-hop device and the identifier of the next-hop device, where the correspondence includes the identifier of the next-hop device and the address of the next-hop device.

[0028] In one possible implementation, the method further includes: an intermediate device receiving a range of Bit Forwarding Router (BFR) identifiers within the destination AS domain sent by a next-hop device, wherein the destination AS domain is the AS domain to which the next-hop device belongs within the area, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

[0029] In the above method, after generating forwarding table entries, the intermediate device can use these entries to send multicast messages from the ingress device, saving traffic between the ingress device and the intermediate device (using less network resources to send replicated multicast messages). Optionally, if the next-hop device is not the egress device, traffic between the intermediate device and the next-hop device can be further saved (using less network resources to send replicated multicast messages).

[0030] In a fourth aspect, a method for generating forwarding table entries is provided. The method includes: an entry device obtaining the address and region identifier of an intermediate device from an intermediate device; and the entry device obtaining forwarding table entries based on the address and region identifier of the intermediate device.

[0031] In the above method, the entry device can obtain the forwarding table entries for forwarding multicast packets based on the parameters obtained from the intermediate device, which reduces the complexity of manual configuration after changes in network structure and allows for more flexible and faster refreshing of the table entries for forwarding multicast packets.

[0032] In one possible implementation, the entry device obtaining the address of the intermediate device and the identifier of the region from the intermediate device includes: the entry device receiving the address of the intermediate device and the identifier of the region sent by the intermediate device.

[0033] In one possible implementation, the entry device obtaining the address and region identifier of the intermediate device from the intermediate device includes: the entry device receiving the identifier of the intermediate device and the identifier of the region sent by the intermediate device; and the entry device determining the address of the intermediate device based on the identifier of the intermediate device. The identifier of the intermediate device can be other information or parameters used to identify the intermediate device besides an address. The entry device can convert the identifier of the intermediate device into the address of the intermediate device according to a preset algorithm, or the entry device can obtain the address of the intermediate device based on a correspondence between the intermediate device and its identifier, where the correspondence includes the identifier and address of the intermediate hop device.

[0034] In one possible implementation, the method further includes: the ingress device receiving the range of BFR identifiers within the destination Autonomous System (AS) domain sent by the intermediate device, wherein the destination AS domain is the AS domain to which the multicast message contained in the region needs to be sent, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

[0035] In the above method, after the ingress device generates a forwarding table entry, it can use the forwarding table entry to send multicast messages to the intermediate device, saving traffic between the ingress device and the intermediate device (using less network resources to send duplicate multicast messages).

[0036] Fifthly, an apparatus for transmitting multicast messages is provided, the apparatus being disposed in an intermediate device. The apparatus includes modules for implementing the functions corresponding to the method provided in the first aspect or any possible implementation thereof; or the apparatus includes modules for implementing the functions corresponding to the method provided in the third aspect or any possible implementation thereof.

[0037] Sixthly, an apparatus for transmitting multicast messages is provided, the apparatus being disposed at an entry device. The apparatus includes modules for implementing the functions corresponding to the methods provided in the second aspect or any possible implementation thereof; or the apparatus includes modules for implementing the functions corresponding to the methods provided in the fourth aspect or any possible implementation thereof.

[0038] A seventh aspect provides an apparatus. The apparatus includes a processor and a memory storing instructions, which, when executed by the processor, cause the apparatus to perform the method provided in the first aspect or any possible implementation thereof; or, when executed by the processor, cause the apparatus to perform the method provided in the second aspect or any possible implementation thereof; or, when executed by the processor, cause the apparatus to perform the method provided in the third aspect or any possible implementation thereof; or, when executed by the processor, cause the apparatus to perform the method provided in the fourth aspect or any possible implementation thereof.

[0039] Eighthly, a computer-readable storage medium is provided that stores instructions thereon, which, when executed by a processor in a device, cause the device to perform the method provided by the first aspect or any possible implementation thereof; or, when executed by a processor, cause the device to perform the method provided by the second aspect or any possible implementation thereof; or, when executed by a processor, cause the device to perform the method provided by the third aspect or any possible implementation thereof; or, when executed by a processor, cause the device to perform the method provided by the fourth aspect or any possible implementation thereof.

[0040] Ninthly, a system is provided, the system comprising the apparatus described in the fifth aspect and the apparatus described in the sixth aspect. Attached Figure Description

[0041] Figure 1 This illustration shows a network scenario provided by an embodiment of this application;

[0042] Figure 2 This illustration shows a schematic diagram of the interaction flow of multicast messages provided in an embodiment of this application;

[0043] Figure 3 This application illustrates a multicast scenario provided by an embodiment of the present application;

[0044] Figure 4 This illustrates another multicast scenario provided by an embodiment of this application;

[0045] Figure 5 This illustrates another multicast scenario provided by an embodiment of this application;

[0046] Figure 6 A schematic diagram of the structure of an apparatus for sending multicast messages provided in an embodiment of this application is shown;

[0047] Figure 7 A schematic diagram of the structure of an apparatus for sending multicast messages according to an embodiment of this application is shown; and

[0048] Figure 8 A schematic diagram of the device provided in an embodiment of this application is shown. Detailed Implementation

[0049] In this application's embodiments, the term "entry device" refers to a device located near the multicast source and capable of communicating with it during cross-domain multicast. As an example, the entry device may include a PE device in the AS domain where the multicast source resides. The entry device can be located in the backbone network or in a metropolitan area network. In embodiments of cross-domain multicast based on BIER, the entry device can perform BIER encapsulation on multicast packets from the multicast source. In this application's embodiments, the term "exit device" refers to a device located near the multicast receiver and capable of communicating with it during cross-domain multicast. As an example, the exit device may include a PE device in the AS domain to which the multicast receiver communicates or belongs. The exit device can be located in a metropolitan area network. In embodiments of cross-domain multicast based on BIER, the exit device can perform BIER decapsulation on received multicast packets. In this application's embodiments, the term "intermediate device" refers to a device used to implement multicast forwarding between the entry device and the exit device during cross-domain multicast. As an example, the intermediate device may include an ASBR in the backbone network. The intermediate device can also be located in a metropolitan area network. The term "comprising" and its variations in the embodiments of this application are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment". Relevant definitions for other terms will be given in the description below. Although the terms "first" and "second", etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0050] In typical hierarchical multicast, when forwarding BIERv6 across domains from the backbone network to the metropolitan area network, each PE device can be distinguished by its BFR-id. The BFR-id of a PE device is uniformly assigned, therefore the number of supported PE devices is limited by the number of bits in the BFR-id value. For example, if the BFR-id value is 16 bits, it cannot support more than 65,535 PE devices. In typical peer-to-peer multicast, the BFR-id of a PE device can be independently assigned, thus supporting more PE devices. However, the ingress device needs to forward multicast packets to all AS domains. Especially as the network expands, more and more AS domains are added. Even if a certain AS domain has a small number of PE devices, the ingress device still needs to forward packets to that AS domain, resulting in significant wasted traffic replication.

[0051] This application provides a method for sending multicast messages. In this method, a region includes one or more AS domains. An intermediate device obtains one or more forwarding entries corresponding to the region. Each forwarding entry includes the region's identifier (ID) and the associated address of each AS domain within that region. This address can be the address of any appropriate device associated with an AS domain. For example, it can be the address of an intermediate or egress device of the AS domain, or it can be the address of a device downstream of the intermediate device on the path to the AS domain. After receiving a multicast message from an ingress device, the intermediate device determines the ID of the region to which the multicast message will be sent and obtains a first forwarding entry using the region's ID. The first forwarding entry includes the region's ID and the address of the next-hop device corresponding to the destination AS domain. Based on the address of the next-hop device in the first forwarding entry, the destination AS domain is the AS domain where the egress device corresponding to the multicast message is located. The intermediate device sends the multicast message to the next-hop device according to the first forwarding entry. The ingress device can obtain one or more forwarding entries corresponding to the region, each forwarding entry including the region's ID and the address of the intermediate device. After receiving a multicast message, the ingress device determines the ID of the region to which the multicast message should be sent, and uses the region ID to obtain a second forwarding table entry. The second forwarding table entry includes the region ID and the address of the intermediate device. Based on the second forwarding table entry, the ingress device sends the multicast message to the intermediate device. In the method provided in this application embodiment, a forwarding table entry is generated for forwarding multicast messages to regions including one or more AS domains. This increases the number of supported egress devices in each region, and also reduces the waste of traffic replication by allowing the ingress device to send messages to the region where the egress device is located, instead of sending messages to all AS domains.

[0052] Figure 1 This illustration shows a network scenario provided by an embodiment of this application. Figure 1 As shown, environment 100 is, for example, part of a communication network and may include a backbone network and a metropolitan area network. Environment 100 includes an ingress device 105 for sending multicast messages from a multicast source to an egress device (not shown) to which the multicast receiver communicates. Ingress device 105 may be directly connected to or connected to the multicast source (not shown) via a user-side edge device. As an example, ingress device 105 may be a PE device in an AS domain of a backbone network or a PE device in an AS domain of a metropolitan area network.

[0053] Environment 100 also includes intermediate device 110. In the direction from ingress device 105 to egress device, intermediate device 110 is located downstream of ingress device 105 in the backbone network or metropolitan area network. Intermediate device 110 is used to forward multicast messages from ingress device 105 to egress device. In one possible implementation, intermediate device 110 and ingress device 105 are located in the same AS domain. For example, ingress device 105 is a PE device in an AS domain of the backbone network or metropolitan area network, and intermediate device 110 can be an ASBR in that AS domain. In another possible implementation, intermediate device 110 may be located in a different AS domain than ingress device 105. For example, in an embodiment where ingress device 105 is an AS domain in the backbone network, in the direction from ingress device 105 to egress device, the AS domain to which intermediate device 110 belongs is located downstream of the AS domain to which ingress device 105 belongs.

[0054] In environment 100, there are multiple AS domains, such as Figure 2 AS fields identified by 115-1, 115-2, 115-3...115-N can communicate with multicast receivers, where N is an integer greater than or equal to 1. AS fields 115-1...115-N can be located in a metropolitan area network. The N AS fields 115-1...115-N are divided into M regions 120-1...120-M, where M is an integer greater than or equal to 1 and less than or equal to N. For example... Figure 1 As shown, region 120-1 includes AS domain 115-1. Region 120-2 includes AS domains 115-2 and 115-3. Region 120-M includes AS domain 115-N. In one possible implementation, when M is 1, region 120-1 includes N AS domains 115-1, 115-2, ..., 115-N. One or more AS domains included in the region can be configured and / or updated as needed. AS domains 115-1, 115-2, 115-3, ..., 115-N are also referred to as AS domain 115, and regions 120-1...120-M are also referred to as region 120.

[0055] like Figure 1 As shown, intermediate device 110 stores a forwarding table 125, where each row is a forwarding entry. Forwarding table 125 includes forwarding entries 130-1, 130-2, 130-3, ... Individual forwarding entries 130-1, 130-2, and 130-3 in forwarding table 125 are also referred to as forwarding entries 130 (also referred to as the first forwarding entry 130).

[0056] Column 135 of forwarding table 125 records the zone ID (also known as the "zone ID"). Column 138 of forwarding table 125 records the addresses of the next-hop devices 140-1, 140-2...140-N belonging to the zone identified by the zone ID. The address of the next-hop device can be an IP address. The next-hop devices 140-1, 140-2...140-N are the edge devices of their respective AS domains and can be called ASBRs. Figure 1 As shown, in column 135 of forwarding table 125, the region ID of region 120-1 is "2". The edge device of AS domain 115-1 included in region 120-1 is next-hop device 140-1, and the address of next-hop device 140-1 is "IP address 2a". The region ID of region 120-2 is "3". The edge device of AS domain 115-2 included in region 120-2 is next-hop device 140-2. The edge device of AS domain 115-3 included in region 120-2 is next-hop device 140-3. The address of next-hop device 140-2 is "IP address 3a", and the address of next-hop device 140-3 is "IP address 4a".

[0057] Next-hop devices 140-1, 140-2...140-N are hereinafter also referred to as device 140. In one possible implementation, device 140 can be the ASBR of its AS domain. Device 140 can forward multicast packets to one or more egress devices (not shown) included in its AS domain. The egress device can be a PE device included in its AS domain. In another possible implementation, device 140 can be an egress device of its AS domain. Intermediate device 110 can forward multicast packets directly to the egress device of the AS domain. In yet another possible implementation, when ingress device 105 and intermediate device 110 are located in the same AS domain of the metropolitan area network, next-hop device 140 can be the ASBR of the backbone network AS domain.

[0058] exist Figure 1 In the example shown, forwarding table 125 also includes column 145, which stores the range of BFR identifiers (also known as "BFR-ids") corresponding to the AS domain to which the device identified by the parameters in column 138 belongs. Figure 1As shown in column 145, the BFR-id range corresponding to AS domain 115-1 to which the next-hop device 140-1 identified by "IP address 2a" belongs is 1 to 256. This means the BFR-id range that can be assigned to the Bit Forwarding Egress Router (BFER) (also called the egress device) in AS domain 115-1 is 1 to 256. In column 145, the BFR-id range corresponding to AS domain 115-2 to which the next-hop device 140-2 identified by "IP address 3a" belongs is 1 to 44. This means the BFR-id range that can be assigned to the BFER in AS domain 115-2 is 1 to 44. In column 145, the BFR-id range corresponding to AS domain 115-3 to which the next-hop device 140-3 identified by "IP address 4a" belongs is 45 to 144. This means the BFR-id range that can be assigned to the BFER in AS domain 115-3 is 45 to 144. By using the range of BFR-id, AS fields 115-2 and 115-3 within the same region 120-2 can be distinguished. Column 145, which records the range of BFR-id, is optional. For region 120-1, which includes only one AS field 115-1, the corresponding forwarding table entry 130-1 may not include the BFR-id column 145.

[0059] Intermediate device 110 can receive information indicating its address and its area ID from next-hop device 140, and establish a forwarding table 125 based on the received information. In one possible implementation, next-hop device 140 can directly send its address and its area ID to intermediate device 110 via BGP messages. In another possible implementation, next-hop device 140 can publish BGP messages to intermediate device 110 via a route reflector (RR), which includes the address of next-hop device 140 and its area ID. Optionally, next-hop device 140 can also publish the range of BFR-ids corresponding to its AS domain to intermediate device 110, for example, directly to intermediate device 110 via BGP messages, or to intermediate device 110 via an RR. Accordingly, the BGP messages also include the range of BFR-ids corresponding to the AS domain to which next-hop device 140 belongs. For example, the next-hop device 140-2 in AS domain 115-2, which includes region 120-2, publishes to the intermediate device 110 a BFR-id range of 1 to 44 corresponding to its AS domain 115-2. The next-hop device 140-3 in AS domain 115-3, which includes region 120-2, publishes to the intermediate device 110 a BFR-id range of 45 to 144 corresponding to its AS domain 115-3.

[0060] To further simplify signaling, a default region ID can be set. For next-hop devices included in the AS domain within a region using the default region ID, their region IDs may not be sent to intermediate device 110. Intermediate device 110 can record the region to which the next-hop device belongs using the default region ID in the forwarding table 125 according to the settings.

[0061] like Figure 1 As shown, the entry device 105 stores a forwarding table 150. The forwarding table 150 includes multiple forwarding entries, specifically forwarding entries 155-1, 155-2, 155-3, etc. The forwarding entries 155-1, 155-2, and 155-3 included in the forwarding table 150 are also referred to as forwarding entries 155 (also known as the second forwarding entry 155).

[0062] In one possible implementation, the entry device 105 and the intermediate device 110 reside in the same AS domain. Accordingly, column 160 of the forwarding table 150 records the zone ID, and column 162 records the address of the intermediate device 110 corresponding to the zone ID, such as an IP address or other form of address. The intermediate device 110 may have multiple addresses, each corresponding to a zone ID. Figure 1 In the forwarding table 150 shown, the intermediate device address corresponding to region ID "2" (identifying region 120-1) is IP address 2b, and the intermediate device address corresponding to region ID "3" (identifying region 120-2) is IP address 3b. Optionally, the forwarding table 150 also includes a column 165 storing the BFR-id range, which records the range of BFR-ids in region 120 identified by the region ID. For region 120-2, which includes multiple AS domains 115-2 and 115-3, multiple forwarding table entries 155-2 and 155-3 can be created in the forwarding table 150. Forwarding table entry 155-2 records the range of BFR-ids 1 to 44 corresponding to AS domain 115-2. Forwarding table entry 155-3 records the range of BFR-ids 45 to 144 within AS domain 115-3.

[0063] The entry device 105 can obtain the region ID, intermediate device address, and BFR-id range from the intermediate device 110, and generate a forwarding table 150 based on the obtained information. For example, the intermediate device 110 can publish the region ID, the address of the intermediate device 110, and the range of BFR-ids corresponding to the AS domains included in the region identified by the region ID to the entry device 105 via BGP messages. The intermediate device 110 can publish multiple BGP messages, each containing the region ID, the address of the intermediate device 110, and the range of BFR-ids for a certain AS domain included in the region. The intermediate device 110 can publish BGP messages via RR or directly. In embodiments where a default region ID is set, the published BGP messages may not carry the region ID. Accordingly, the entry device 105 can use the default region ID to determine the corresponding region based on the settings.

[0064] According to an embodiment of this application, after the ingress device 105 determines the ID of the region to which the multicast message will be sent, it obtains a second forwarding table entry 155, including the region ID and the address of the intermediate device 110, using the region ID. The ingress device 105 sends the multicast message to the intermediate device 110 based on the address of the intermediate device 110. Upon receiving the multicast message, the intermediate device 110 determines the ID of the region to which the multicast message will be sent. The intermediate device 110 obtains a first forwarding table entry 130, recording the region ID and the address of the next-hop device 140, using the region ID. The intermediate device 110 sends the multicast message to the next-hop device 140 based on the address of the next-hop device 140 in the first forwarding table entry 130. The intermediate device 110 and the ingress device 105 can obtain forwarding tables 125 and 150 to reach one or more regions. Each region 120 may include one or more AS domains 115. BFR-id planning can be performed independently within region 120, thereby supporting multicast messages to a larger number of egress devices. The forwarding table 125 on the intermediate device 110 includes the next-hop device address of multiple AS domains 115 in the region 120 identified by the region ID obtained from the multicast message location. The ingress device 105 does not need to send multicast messages to each AS region separately, thereby significantly improving multicast efficiency.

[0065] In another possible implementation, the entry device 105 and the intermediate device 110 are located in different AS domains, and the address recorded in column 162 of the forwarding table 150 of the entry device 105 can be the address of the forwarding device between the entry device 105 and the intermediate device 110.

[0066] For example, the ID of the region to which the AS domain where the ingress device 105 is located is different from the ID of the region to which the AS domain where the egress device is located is located. Thus, in a scenario where the ingress device 105 acts as an egress device, the ingress device and intermediate device 110 communicating with the multicast source can transmit multicast messages based on the region ID of the ingress device 105 acting as the egress device. Specific embodiments in this regard will be referred to below. Figure 4 and Figure 5 Detailed description.

[0067] Figure 2 This illustration shows a schematic diagram of the interaction flow of multicast messages provided in an embodiment of this application. Figure 2 The process 200 shown can be performed in Figure 1 This will be conducted in the example scenario described above. For ease of discussion, the following will combine... Figure 1 To describe it.

[0068] 205, the entry device 105 determines the identifier of the area 120 to which the multicast message will be sent.

[0069] In one implementation, the multicast message from the multicast source may contain the ID of the region to which the egress device of the multicast receiver belongs. The ingress device 105 can determine the region ID based on the received multicast message. In another possible implementation, a field or portion of the multicast message may have a mapping or correspondence with a region ID. The destination address contained in the multicast message may correspond to a region ID. The ingress device 105 can determine the region ID based on the destination address and the correspondence in the received multicast message.

[0070] 210, the entry device 105 obtains the second forwarding table entry 155 using the region ID.

[0071] For example, the second forwarding table entry 155 includes the region ID and the address of intermediate device 110. (The rest of the text appears to be incomplete and possibly contains errors.) Figure 1 As shown, forwarding table 150 stores the mapping between region IDs and intermediate device addresses. Ingress device 105 uses the region ID to look up forwarding table 150, obtaining a second forwarding table entry 155 containing the region ID and the address of intermediate device 110. Forwarding table 150 can be statically configured, for example, manually configured. Forwarding table 150 can also be dynamically configured to further improve the configuration and update efficiency of the forwarding table; see the above for details. Figure 1 Related content.

[0072] 215. The entry device 105 sends the multicast message to the intermediate device 110 based on the determined address.

[0073] For example, ingress device 105 can encapsulate the address of the determined intermediate device 110 in the destination address of the multicast message. In one possible implementation, the multicast message can include the ID of the area 120 to which it is to be sent, to explicitly indicate the area ID to intermediate device 110. Optionally, the multicast message can also include a range of BFR-ids corresponding to the AS domain where the egress device to be sent is located. In another possible implementation, there can be a mapping or correspondence between the area ID and the identifier of intermediate device 110. The identifier of intermediate device 110 can be any appropriate information that can be used to identify intermediate device 110, such as including the address of intermediate device 110. Ingress device 105 can include the identifier of intermediate device 110 in the multicast message to implicitly indicate the area ID to intermediate device 110. The identifier of intermediate device 110 can be included in any appropriate part of the multicast message. For example, ingress device 105 can include the identifier of intermediate device 110 in the destination address field of the multicast message. In this way, the structure of the multicast message can be simplified, and backward compatibility can be better achieved. Intermediate device 110 can obtain the area ID based on the identifier and correspondence of intermediate device 110 included in the multicast message.

[0074] In this way, the ingress device 105 only needs to send one message to one area 120, instead of sending it to all AS domains 115, thus improving multicast efficiency.

[0075] 220. After receiving a multicast message whose destination address is its own address, intermediate device 110 determines the ID of the area 120 to which the multicast message will be sent.

[0076] In embodiments where the multicast message includes the ID of the region 120 to be sent, the intermediate device 110 can obtain the region ID from the multicast message. In embodiments where the multicast message includes the identifier of the intermediate device 110 (e.g., the address of the intermediate device 110), the intermediate device 110 can determine the region ID based on the identifier of the intermediate device 110 contained in the multicast message and the correspondence between the region ID and the intermediate device 110. The intermediate device 110 can be assigned multiple identifiers (or addresses), each identifier of the intermediate device 110 corresponding to a different region ID. Upon receiving a multicast message, the intermediate device 110 can obtain its identifier from the multicast message (e.g., from the destination address field or portion of the multicast message) and then determine the corresponding region ID.

[0077] 225. Intermediate device 110 uses the region ID to obtain the first forwarding table entry 130.

[0078] For example, intermediate device 110 can use the determined region ID to look up forwarding table 125 to obtain the first forwarding entry 130. In embodiments where region 120 includes multiple AS domains 115, intermediate device 110 can find multiple forwarding entries 130 in forwarding table 125 corresponding to the region ID of a certain region 120. For example, for region 120-2 including AS domains 115-2 and 115-3, forwarding entries 130-2 and 130-3 can be found to correspond to the region identifier 2 of region 120-2. If forwarding entries 130-2 and 130-3 also include the range of BFR-ids corresponding to AS domains 115-2 and 115-3 respectively, and the multicast message also includes the range of BFR-ids, then intermediate device 110 can determine the corresponding forwarding entry 130-2 or 130-3 based on the range of BFR-ids contained in the multicast message. The forwarding table 125 at intermediate device 110 can be configured statically or dynamically. Static configuration can be done manually. For dynamic configuration methods, please refer to [link / reference]. Figure 1 The corresponding content. When the network is expanded, the intermediate device 110 can receive information from the newly added AS domain and update the forwarding table 125 accordingly, thereby significantly improving the efficiency of forwarding table configuration and update.

[0079] 230. The intermediate device 110 sends the multicast message to the next-hop device 140 based on the address of the next-hop device 140 contained in the first forwarding table entry 130.

[0080] For example, for region 120-1 which includes only one AS domain 115-1, after obtaining the forwarding table entry 130 containing the ID of region 120-1, intermediate device 110 can directly send multicast packets to AS domain 115-1 of region 120-1 without copying the received multicast packets. For region 120-2 which includes multiple AS domains 115-2 and 115-3, intermediate device 140 can copy the multicast packets so that the multicast packets and the copied multicast packets can be sent to AS domains 115-2 and 115-3 in region 120-2.

[0081] The following is combined Figure 3 , Figure 4 and Figure 5 An example process for sending multicast messages using the methods provided in embodiments of this application is discussed.

[0082] Figure 3 This illustration shows a multicast scenario provided by an embodiment of this application. For ease of discussion, the following will be combined with... Figure 1 To describe such Figure 3 Scene 300 is shown.

[0083] Scenario 300 differs from Scenario 1 in that AS domains 115-4 and 115-5 are AS domains added after network expansion. Area 120-2 includes AS domain 115-4. Area 120-3 includes AS domain 115-5. Ingress device 105 and intermediate device 110 are located in the same AS domain 115-6 of the backbone network. Ingress device 105 can be implemented by a PE device in AS domain 115-6. Intermediate device 110 can be implemented by an ASBR in AS domain 115-6. Next-hop device 140-4 belongs to AS domain 115-4. Next-hop device 140-5 belongs to AS domain 115-5. For a description of the same structure, see [link to relevant documentation]. Figure 1 The corresponding content for the scene shown.

[0084] Next-hop devices 140-1, 140-2, and 140-3 can directly publish the following information to intermediate device 110, or they can publish it to intermediate device 110 via RR 310. The information published by next-hop devices 140-1, 140-2, and 140-3 is as follows:

[0085] The information published by the next-hop device 140-1 is: (Color=2, IPv6 address) <asbr2>(BFR-id = 1~256)

[0086] The information published by next-hop device 140-2 is: (Color=3, IPv6 address) <asbr3>(BFR-id = 1 to 44)

[0087] The information published by the next-hop device 140-3 is: (Color=3, IPv6 address) <asbr4>(BFR-id = 45~144)

[0088] Where Color=2 represents the region ID of region 120-1, ASBR2 represents device 140-1, and the IPv6 address. <asbr2>This indicates the IPv6 address of device 140-1. BFR-id = 1~256 represents the range of BFR-ids corresponding to AS domain 115-1. Color = 3 represents the ID of zone 120-2, and ASBR3 represents the IPv6 address of device 140-2. <asbr3>This indicates the IPv6 address of device 140-2. BFR-id = 1~44 represents the range of BFR-ids corresponding to AS domain 115-2. Color = 3 represents the ID of zone 120-2, and ASBR4 represents the IPv6 address of device 140-3. <asbr4>This represents the IPv6 address of device 140-3. BFR-id = 45~144 represents the range of BFR-id within AS domain 115-3.

[0089] Intermediate device 110 builds a forwarding table 125 based on the received information. In this example, forwarding table 125 includes the following forwarding entries 130:

[0090] -(Color=2,BFR-id=1~256,Next Hop=IPv6 Address) <asbr2>)

[0091] -(Color=3,BFR-id=1~44,Next Hop=IPv6 Address) <asbr3>)

[0092] -(Color=3,BFR-id=45~144,Next Hop=IPv6 Address) <asbr4>)

[0093] After a multicast message from ingress device 105 arrives at intermediate device 110, intermediate device 110 first determines the region ID of region 120. In one possible implementation, the multicast message (e.g., a BIERv6 multicast message) may carry a Color value to represent the region ID. In another possible implementation, intermediate device 110 may obtain a mapping between Color values ​​and the identifier of intermediate device 110. Based on this mapping and the identifier of intermediate device 110 included in the multicast message, intermediate device 110 determines the Color value to represent the region ID. The mapping between the Color value and the address of intermediate device 110 is as follows: for example, Color=2 corresponds to address 2001:db1::2, and Color=3 corresponds to address 2001:db1::3. This mapping can be statically or dynamically configured. If the destination address of the multicast message received by intermediate device 110 is 2001:db1::2, then it can be determined that the multicast message should be sent to region 120-1 identified by Color=2. Intermediate device 110 then determines the next-hop address based on the range of BFR-ids contained in the multicast message. For example, in an embodiment where the multicast message is a BIERv6 multicast message, intermediate device 110 can determine the range of BFR-ids based on the bit string included in the BIERv6 message. Based on this BFR-id range and forwarding table 125, intermediate device 110 determines the next-hop address to be an IPv6 address. <asbr2>For region 120-2, which includes AS domains 115-2 and 115-3, after determining that region 120-2 is identified by Color=3 based on the destination address 2001:db1::3 of the multicast message, intermediate device 110 further determines the next-hop address as an IPv6 address based on the range of BFR-id contained in the multicast message. <asbr3>and IPv6 address <asbr4>One or more of them. If it is necessary to send to multiple next-hop devices, intermediate device 110 can copy the bit string in the multicast message so that the multicast message can be sent to AS domains 115-2 and 115-3.

[0094] In scenario 300, intermediate device 110 can instruct the ingress device 105 to publish information including the region ID, its corresponding address, and an optional BFR-id range. Intermediate device 110 can publish this information to ingress device 105 via RR 310 or directly. In this example, intermediate device 110 can publish the following information to ingress device 105:

[0095] -(Color=2, IPv6 address=2001:db1::2)

[0096] -(Color=2, BFR-id=1~256)

[0097] -(Color=3, IPv6 address=2001:db1::3)

[0098] -(Color=3, BFR-id=1~44)

[0099] -(Color=3,BFR-id=45~144)

[0100] The above information includes the mapping relationship of (Color, IPv6 address), where the IPv6 address represents the IPv6 address of intermediate device 110, which corresponds to the area ID. Optionally, this information also includes information on the BFR-id range within each AS domain of the area identified by the Color value, i.e., (Color, BFR-id) information.

[0101] After receiving the information published by the intermediate device 110, the entry device 105 can obtain the following forwarding table entry 155:

[0102] -(Color=2,BFR-id=1~256,Next-hop=2001:db1::2)

[0103] -(Color=3,BFR-id=1~44,Next-hop=2001:db1::3)

[0104] -(Color=3,BFR-id=45~144,Next-hop=2001:db1::3)

[0105] Optionally, the following two forwarding entries 155 can be merged as follows:

[0106] -(Color=2,BFR-id=1~256,Next-hop=2001:db1::2)

[0107] -(Color=3,BFR-id=1~144,Next-hop=2001:db1::3)

[0108] Here, next hop = 2001:db1::2 and next hop = 2001:db1::3 are both addresses of intermediate device 110, and different addresses correspond to regions identified by different Color values. BFR-id = 1~256 and BFR-id = 1~144 are optional parameters.

[0109] In scenario 300, the network has been expanded, for example, by adding AS domain 115-4. AS domain 115-4 corresponds to 112 BFR-ids, bringing the total number of BFR-ids with those corresponding to AS 115-2 and 115-3 to 256. The next-hop device 140-4 of AS domain 115-4 publishes the area ID, the address of the next-hop device 140-4, and the range of BFR-ids corresponding to AS domain 115-4 to the intermediate device 110. For example, device 140-4 can publish the following information to intermediate device 110 via RR 310: (Color=3, IPv6 address) <asbr5>(BFR-id = 145~256), where Color = 3 represents the area ID of area 120-2, ASBR5 represents device 140-4, and the IPv6 address. <asbr5>This indicates the IPv6 address of device 140-4.

[0110] After receiving the above information, intermediate device 110 adds an entry to forwarding table 125: (Color=3, BFR-id=145~256, next hop=IPv6 address) <asbr5>Intermediate device 110 can publish additional information (Color=3, BFR-id=145~256, next hop=2001:db1::3) to ingress device 105 via RR 310. Here, next hop=2001:db1::3 is the address corresponding to intermediate device 110 and region 120-2.

[0111] After receiving the above information, the entry device 105 creates the following forwarding table entry 155 to update the forwarding table 150:

[0112] -(Color=2,BFR-id=1 to 256,Next hop=2001:db1::2)

[0113] -(Color=3,BFR-id=1 to 256,Next hop=2001:db1::3)

[0114] When adding an AS domain 115-4 during network expansion, only the expanded device 140-4 needs to be configured. Other devices or nodes do not require additional configuration. The ingress device and intermediate devices can automatically update their respective forwarding tables, improving the efficiency of forwarding table updates.

[0115] For example, if the network continues to expand, such as adding an AS domain 115-5 with 65,500 BFR-IDs, AS domain 115-5 can be set up as a new area 120-3. Color=6 can be configured to represent the ID of area 120-3. Device 140-5 in AS domain 115-5 can advertise the area ID, device 140-5's address, and the BFR-ID range within AS domain 115-5 to intermediate device 110 via RR310. The advertised information would be, for example, (Color=6, IPv6 address...). <asbr6>(BFR-id = 1 ~ 65500), where Color = 6 represents the area ID of area 120-3, ASBR6 represents device 140-5, and the IPv6 address <asbr6>This indicates the IPv6 address of device 140-5.

[0116] After receiving the above information, intermediate device 110 adds an entry to forwarding table 125 (Color=6, BFR-id=1~65500, next hop=IPv6 address). <asbr6>Intermediate device 110 publishes the added information (Color=6, BFR-id=1~65500, next hop=2001:db1::6) to ingress device 105 via RR 310. Upon receiving the above information, ingress device 105 creates the following forwarding table entry 155 to update forwarding table 150:

[0117] -(Color=2,BFR-id=1~256,Next-hop=2001:db1::2)

[0118] -(Color=3,BFR-id=1~256,Next-hop=2001:db1::3)

[0119] -(Color=6,BFR-id=1~65500,Next-hop=2001:db1::6)

[0120] Here, 2001:db1::6 is another IPv6 address of intermediate device 110, corresponding to the zone ID represented by Color=6. This address can be dynamically requested by intermediate device 110 based on the received Color value, thus eliminating the need for additional configuration and improving efficiency. Alternatively, intermediate device 110 can also be configured with the address corresponding to Color=6. Neither of these methods requires additional configuration from the ingress device 105.

[0121] The following discusses an example multicast configuration using the multicast mechanism of an embodiment of this application. BGP routes can use the BGP IPv6-Unicast address family, or other address families, such as the BGP Link-State (BGP-LS) address family. Alternatively, a newly created address family, such as the BIER address family, can be used. As an example, the IPv6-Unicast address family can be used and advertised via RR 310. In this example, device 140-1 is represented as ASBR2, device 140-2 as ASBR3, device 140-3 as ASBR4, intermediate device 110 as ASBR1b, and ingress device 105 as PE1. These devices can be configured as follows:

[0122]

[0123]

[0124] Figure 4 This illustrates another multicast scenario provided by an embodiment of this application.

[0125] and Figure 1 Scene 100 and Figure 3 The scene is different in 300. Figure 4 In scenario 400 shown, entry device 105 and intermediate device 110 are located in different AS domains. For example... Figure 4 As shown, the ingress device 105 is located in AS domain 115-6 of the metropolitan area network, for example, implemented as a PE device in AS domain 115-6. The intermediate device 110 is located in AS domain 115-7 of the backbone network, for example, implemented as an ASBR in AS domain 115-7. Moreover, unlike scenario 300, another ASBR 405-7 in AS domain 115-7 acts as the next-hop device associated with AS domains 115-1...115-5. Multicast packets destined for each AS domain 115-1...115-5 are forwarded via ASBR 405-7 to ASBRs 405-1...405-5 of these AS domains 115-1...115-5. The intermediate device 110 and ASBR 405-7 can both establish BGP neighbor relationships with RR 310, so that ASBR 405-7 can advertise relevant routing information to the intermediate device 110 via RR 310. In scenario 400, AS domain 115-6 belongs to area 120-4 and has a different area ID than areas 120-1, 120-2, and 120-3. Accordingly, establishing a forwarding table 125 at intermediate device 110 can include a forwarding entry with ingress device 105 as the multicast destination, recording the area ID of area 120-4. In this example, ASBR 405-6 of AS domain 115-6 acts as the next-hop device associated with area 120-4. The area ID of ingress device 105, the address of the associated next-hop device, and the BFR-id range of area 120-4 can be advertised to intermediate device 110 by ASBR 405-6 via RR 310. Since area 120-4, where ingress device 105 is located, has a different area ID than areas 120-1, 120-2, and 120-3, RR 310 can use the area ID to distinguish the destination device of the routing information when advertising routing information via RR 310.

[0126] Figure 5 This illustrates another multicast scenario provided by an embodiment of this application. Figure 5 In scenario 500, ASBRs 405-1 through 405-7 are ASBRs in AS domains 115-1 through 115-7, while ASBR 405-8 is another ASBR in AS domain 115-7. Both 405-7 and 405-8 can act as intermediate devices. In this example, routing information is not advertised via RR, but is directly advertised by each device to upstream and downstream devices.

[0127] In scenario 500, ASBRs 405-1 to 405-5 in each AS domain 115-1 to 115-5, acting as the original route advertisers, publish the following routing information:

[0128] The routing information published by ASBR 405-1 is: (prefix=ASBR2,NextHop=ASBR2,Color=2,

[0129] BIER-info=<BFR-id-range 1 to 256> )

[0130] The routing information published by ASBR 405-2 is: (prefix=ASBR3,NextHop=ASBR3,Color=3,

[0131] BIER-info=<BFR-id-range 1 to 44> )

[0132] The routing information published by ASBR 405-3 is as follows: (prefix=ASBR4,NextHop=ASBR4,Color=3,

[0133] BIER-info=<BFR-id-range 45 to 144> )

[0134] The routing information published by ASBR 405-4 is as follows: (prefix=ASBR5,NextHop=ASBR5,Color=3,

[0135] BIER-info=<BFR-id-range 145 to 256> )

[0136] The routing information published by ASBR 405-5 is: (prefix=ASBR6,NextHop=ASBR6,Color=6,

[0137] BIER-info=<BFR-id-range 1 to 65500> )

[0138] The prefix field carries the IP address prefix, the NextHop field carries the IP address, BIER-info represents BIER information, and BFR-id-range represents the range of BFR-id. ASBR2, ASBR3, ASBR4, ASBR5, and ASBR6 represent ASBR 405-1, 405-2, 405-3, 405-4, and 405-5, respectively.

[0139] ASBR 405-6, as the next-hop device associated with AS domain 115-6, is also the original route advertiser, and it advertises the following routing information about AS domain 115-6:

[0140] -(prefix=ASBR0,NextHop=ASBR0,Color=7,BIER-info=<BFR-id-range 1 to256> )

[0141] Here, ASBR0 represents ASBR 405-6, and Color=7 represents the region ID of region 120-4 to which AS domain 115-6 belongs.

[0142] ASBR 405-8 and ASBR 405-7 are not the original route advertisers, but they redistribute routing information advertised by other devices to other internal BGP (iBGP) peers or external BGP (eBGP) peers. For example, ASBR 405-7 can receive the corresponding routing information from ASBR 405-1...405-5, which are eBGP peers, and then advertise it to ASBR 405-8, which is an iBGP peer, changing the next hop of the route to itself during the advertisement. This can be achieved through routing policies. ASBR 405-8 can receive routing information from ASBR 405-6, which is an eBGP peer, and then advertise it to ASBR 405-7, which is an iBGP peer, also changing the next hop of the route to itself during the advertisement. ASBR 405-8 and ASBR 405-7 can also advertise routing information to PE 505, which is an iBGP peer within the same AS domain 115-7. PE 505 can act as the ingress device for AS domain 115-7. In this case, ASBR 405-7 can act as an associated intermediate device. Thus, PE 505 can obtain the following routing information, where ASBR1b represents ASBR 405-7 and ASBR1a represents ASBR 405-8:

[0143] -(prefix=ASBR2,NextHop=ASBR1b,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0144] -(prefix=ASBR3,NextHop=ASBR1b,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0145] -(prefix=ASBR4,NextHop=ASBR1b,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0146] -(prefix=ASBR5,NextHop=ASBR1b,Color=3,BIER-info=<BFR-id-range 145to 256> )

[0147] -(prefix=ASBR6,NextHop=ASBR1b,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0148] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0149] PE 505 can use this to create the following BIER forwarding entries to reach AS domains 115-1...115-6:

[0150] -(Color=2,BFR-id=1~256,Next-hop=ASBR1b)

[0151] -(Color=3,BFR-id=1~256,Next-hop=ASBR1b)

[0152] -(Color=4,BFR-id=1~65550,Next-hop=ASBR1b)

[0153] -(Color=7,BFR-id=1~256,Next-hop=ASBR1a)

[0154] In scenario 500, when ASBR 405-7 publishes routing information received from ASBR 405-1...405-5 (as eBGP peers) to PE 505 and ASBR 405-8 (as iBGP peers), it can set the next-hop address to one or more of its own identifiers to indicate the corresponding area ID. Thus, after ASBR 405-7 receives the multicast message, it can determine the corresponding area ID based on the identifiers contained in the multicast message. In this way, PE 505 can obtain the following routing information:

[0155] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0156] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0157] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0158] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0159] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0160] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> Among them, ASBR1b2, ASBR1b3, ASBR1b6 and ASBR1a represent the identifiers of ASBR 405-7 corresponding to region IDs Color=2, Color=3, Color=6 and Color=7, respectively.

[0161] PE 505 can use this to create the following BIER forwarding entries to reach AS domains 115-1...115-6:

[0162] -(Color=2,BFR-id=1~256,Next-hop=ASBR1b2)

[0163] -(Color=3,BFR-id=1~256,Next-hop=ASBR1b3)

[0164] -(Color=4,BFR-id=1~65550,Next-hop=ASBR1b6)

[0165] -(Color=7,BFR-id=1~256,Next-hop=ASBR1a)

[0166] Furthermore, ASBR 405-8 can obtain the following routing information:

[0167] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0168] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0169] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0170] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0171] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0172] -(prefix=ASBR0,NextHop=ASBR0,Color=7,BIER-info=<BFR-id-range 1 to256> )

[0173] ASBR 405-8 can be used to create BIER forwarding entries to AS domains 115-1...115-6. The next hop for a BIER forwarding entry created by ASBR 405-8 to AS domain 115-6 is ASBR 405-6.

[0174] Similarly, ASBR 405-7 can obtain the following routing information:

[0175] -(prefix=ASBR2,NextHop=ASBR2,Color=2,BIER-info=<BFR-id-range 1 to256> )

[0176] -(prefix=ASBR3,NextHop=ASBR3,Color=3,BIER-info=<BFR-id-range 1 to44> )

[0177] -(prefix=ASBR4,NextHop=ASBR4,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0178] -(prefix=ASBR5,NextHop=ASBR5,Color=3,BIER-info=<BFR-id-range 145to 256> )

[0179] -(prefix=ASBR6,NextHop=ASBR6,Color=6,BIER-info=<BFR-id-range 1 to65500> )

[0180] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0181] ASBR 405-7 can be used to create BIER forwarding table entries that lead to AS domains 115-1...115-6. The next hop for the BIER forwarding table created by ASBR 405-7 that leads to AS domains 115-1...115-5 is ASBR 405-1...405-5.

[0182] In one possible implementation, ASBR 405-8 will not republish routing information published by ASBR 405-6 to ASBR 405-6, but will instead publish routing information published by ASBR 405-7 to ASBR 405-6 without modifying the next hop. This can be achieved through routing policies. Accordingly, ASBR 405-6 can obtain the following routing information:

[0183] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0184] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0185] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0186] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0187] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0188] ASBR 405-6 can use this to create BIER forwarding table entries to AS domains 115-1...115-5. The BIER forwarding table entries of each BFR-id of ASBR 405-6 to AS domain 115-6 belong to the AS domain and can be created without BGP messages.

[0189] In one possible implementation, ASBR 405-6 will republish the routing information published by ASBR 405-8 to ingress device 105 without modifying the next hop. This can be achieved through routing policies. Accordingly, ingress device 105 can obtain the following routing information:

[0190] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0191] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0192] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0193] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0194] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0195] The entry device 105 can establish BIER forwarding table entries to reach AS domains 115-1...115-5 based on this. The BIER forwarding table entries of each BFR-id of the entry device 105 to reach AS domain 115-6 belong to the AS domain and can be established without BGP messages.

[0196] Furthermore, ASBR 405-7 can further advertise the received routing information to ASBRs 405-1 through 405-5. For example, ASBR 405-7 can re-advertise the routing information advertised by ASBR 405-8 to ASBRs 405-1 through 405-5 without changing the next hop.

[0197] ASBR 405-7 can also re-advertise routes published by ASBR 405-2...405-6 to ASBR 405-1, and change the next hop to itself. ASBR 405-1 can re-advertise routes published by ASBR 405-7 to PE 510-1 in AS domain 115-1 (which can act as the ingress device for AS domain 115-1), without changing the next hop.

[0198] Accordingly, both ASBR 405-1 and PE 510-1 can obtain the following routing information and can establish corresponding BIER forwarding table entries based on this:

[0199] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0200] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0201] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0202] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0203] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0204] ASBR 405-7 can also re-advertise routes advertised by ASBR 405-1, 405-3, 405-4, 405-5, and 405-6 to ASBR 405-2, changing the next hop to itself. ASBR 405-2 can also re-advertise routes advertised by ASBR 405-7 to PE 510-2 (which can act as the ingress device for AS domain 115-2), without changing the next hop.

[0205] Accordingly, both ASBR 405-2 and PE 510-2 can obtain the following routing information and can establish corresponding BIER forwarding table entries based on this:

[0206] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0207] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0208] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0209] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0210] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0211] ASBR 405-7 can also re-advertise routes advertised by ASBR 405-1, 405-2, 405-4, 405-5, and 405-6 to ASBR 405-3, changing the next hop to itself. ASBR 405-3 can also re-advertise routes advertised by ASBR 405-7 to PE 510-3 (which can act as the ingress device for AS domain 115-3), without changing the next hop.

[0212] Both ASBR 405-3 and PE 510-3 can obtain the following routing information and can create corresponding BIER forwarding table entries based on it:

[0213] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0214] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0215] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0216] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0217] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0218] Similarly, ASBR 405-4 can obtain the following routing information and create corresponding BIER forwarding table entries accordingly:

[0219] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0220] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0221] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0222] -(prefix=ASBR6,NextHop=ASBR1b6,Color=6,BIER-info=<BFR-id-range 1to 65500> )

[0223] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0224] ASBR 405-5 can obtain the following routing information and can use it to create corresponding BIER forwarding table entries:

[0225] -(prefix=ASBR2,NextHop=ASBR1b2,Color=2,BIER-info=<BFR-id-range 1to 256> )

[0226] -(prefix=ASBR3,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 1to 44> )

[0227] -(prefix=ASBR4,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range 45to 144> )

[0228] -(prefix=ASBR5,NextHop=ASBR1b3,Color=3,BIER-info=<BFR-id-range145 to 256> )

[0229] -(prefix=ASBR0,NextHop=ASBR1a,Color=7,BIER-info=<BFR-id-range 1to 256> )

[0230] In this example, the next hop for ASBR 405-1...405-5 recorded by ingress device 105 and ASBR 405-6 is ASBR 405-7. If IPv6 unicast routing (i.e., the IPv6 Unicast address family) is used, it can be required that IPv6 unicast routing not generate corresponding unicast forwarding tables, but instead generate BIER forwarding tables. This can be achieved by applying routing policies to IPv6 unicast routes. If other address families are used, such as IPv6 multicast routing (i.e., the IPv6 Multicast address family), then IPv6 multicast routing itself does not generate unicast forwarding tables. It only needs to generate BIER forwarding tables based on these IPv6 multicast routes and the area ID information (such as color values) and BIER information (such as BFR-id ranges) they carry.

[0231] Figure 6 A schematic diagram of the structure of an apparatus for sending multicast messages provided in an embodiment of this application is shown. Figure 6 The device 600 shown can be set in Figures 1 to 5 The intermediate device in any corresponding embodiment. The following will be combined with... Figure 1 and Figure 6 The device 600 will be described below.

[0232] like Figure 6 As shown, the device 600 includes a first obtaining module 605, a second obtaining module 610, and a first sending module 615. The first obtaining module 605 is used to obtain the identifier of the region corresponding to the multicast message based on the multicast message from the ingress device. The second obtaining module 610 is used to obtain the address of the next-hop device based on the region identifier and a forwarding table entry, wherein the forwarding table entry contains the region identifier and the address of the next-hop device. The first sending module 615 is used to send the multicast message based on the address of the next-hop device.

[0233] In one possible implementation, the multicast message includes an identifier of the region, and the first obtaining module 605 is used to obtain the identifier of the region from the multicast message.

[0234] In one possible implementation, the first obtaining module 605 is used to obtain the identifier of the region corresponding to the identifier of the intermediate device in the multicast message. The device 600 may store a correspondence, which includes the identifier of the intermediate device and the identifier of the region.

[0235] In one possible implementation, the first obtaining module 605 is used to obtain the identifier of the region corresponding to the address of the intermediate device in the multicast message. The device 600 may store a correspondence, which includes the address of the intermediate device and the identifier of the region.

[0236] In one possible implementation, the apparatus 600 may further include: a first receiving module for receiving the address of the next-hop device and the identifier of the region to which the next-hop device belongs, sent by the next-hop device; and a third obtaining module for obtaining forwarding table entries based on the identifier of the region and the address of the next-hop device.

[0237] In one possible implementation, the device 600 may further include: a first receiving module, configured to receive the identifier of the next-hop device and the identifier of the region to which the next-hop device belongs, sent by the next-hop device; and a third obtaining module, configured to obtain the address of the next-hop device based on the identifier of the next-hop device; the third obtaining module is also configured to obtain forwarding table entries based on the region identifier and the address of the next-hop device. The device 600 may store a correspondence, which includes the identifier of the next-hop device and the address of the next-hop device.

[0238] In one possible implementation, the first receiving module is further configured to receive the range of Bit Forwarding Router (BFR) identifiers within the destination AS domain sent by the next-hop device. The destination AS domain is the AS domain to which the next-hop device belongs within the area. The forwarding table entry also includes the range of BFR identifiers within the destination AS domain. Correspondingly, the multicast message also includes the range of BFR identifiers. The third obtaining module is configured to determine the forwarding table entry based on the area identifier and the range of BFR identifiers.

[0239] In one possible implementation, the device 600 may further include: a second sending module for sending the address of the intermediate device and the identifier of the area to which the intermediate device belongs to the entry device.

[0240] In one possible implementation, the second sending module is further configured to send the range of BFR identifiers within the AS domain to which the intermediate device belongs to the ingress device, wherein the AS domain to which the intermediate device belongs is contained within the region to which the intermediate device belongs.

[0241] Figure 7 A schematic diagram of the structure of an apparatus for sending multicast messages provided in an embodiment of this application is shown. Figure 7 The device 700 shown can be set in Figures 1 to 5 The corresponding entry device in any of the embodiments. The following will be combined with... Figure 1 and Figure 7 The device 700 will be described below.

[0242] like Figure 7 As shown, the device 700 includes a first obtaining module 705, a second obtaining module 710, and a first sending module 715. The first obtaining module 705 is used to obtain the identifier of the region corresponding to the received multicast message. The second obtaining module 710 is used to obtain the address of an intermediate device for forwarding the multicast message to the region based on the region identifier and forwarding table entries; the forwarding table entries include the region identifier and the address of the intermediate device. The first sending module 715 is used to send the multicast message based on the address of the intermediate device.

[0243] In one possible implementation, the apparatus 700 may further include: a second receiving module for receiving the address and region identifier of the intermediate device sent by the intermediate device; and a third obtaining module for obtaining forwarding table entries based on the address and region identifier of the intermediate device.

[0244] In one possible implementation, the apparatus 700 may further include: a second receiving module for receiving an identifier of the intermediate device and an identifier of a region sent by the intermediate device; and a third obtaining module for determining the address of the intermediate device based on the identifier of the intermediate device; the third obtaining module is used to obtain forwarding entries based on the address of the intermediate device and the identifier of the region.

[0245] In one possible implementation, the second receiving module is further configured to receive the range of BFR identifiers within the destination Autonomous System (AS) domain sent by the intermediate device. The destination AS domain is the AS domain to which the multicast message contained in the region needs to be sent, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

[0246] In one possible implementation, the second obtaining module 710 is used to determine forwarding entries based on the scope and region identifiers of the BFR identifiers within the destination AS domain.

[0247] In one possible implementation, the multicast message contains an identifier of the region, and the first obtaining module 705 is used to obtain the identifier of the region from the multicast message.

[0248] In one possible implementation, the multicast message contains the identifier of the intermediate device, and the first obtaining module 705 is used to obtain the identifier of the area corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message.

[0249] The modules included in devices 600 and 700 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the modules in devices 600 and 700 can be implemented at least partially by one or more hardware logic components. By way of example, and not limitation, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), and so on.

[0250] Figure 8 A block diagram of a device 800 in which certain embodiments of the present application may be implemented is shown. Device 800 is capable of implementing examples. Figures 1 to 7 The intermediate device or entry device provided in any corresponding embodiment. For example... Figure 8 As shown, device 800 includes a processor 810, a memory 820, a communication interface 830, and a communication bus 840. The processor 810, memory 820, and communication interface 830 interact internally via the communication bus 840. The communication bus 840 can interact with external devices or apparatuses. When device 800 is configured as an intermediate device, the memory 820 is used to store instructions; the processor 810 is used to execute the instructions stored in the memory, performing the aforementioned... Figures 2 to 5 The corresponding embodiment provides a method executed by an intermediate device. When device 800 is set as an entry device, the memory 820 is used to store instructions; the processor 810 is used to execute the instructions in the memory to perform the above-mentioned... Figures 2 to 5 The method performed by the entry device is provided in any corresponding embodiment. The memory 820 can be any suitable type applicable to the local technical environment and can be implemented using any suitable data storage technology, including but not limited to semiconductor-based memory devices, magnetic storage devices and systems, and optical storage devices and systems. Although Figure 8 Only one memory unit is shown, but device 800 may have multiple physically different memory units. Processor 810 may be any suitable type applicable to the local technical environment and may include, but is not limited to, one or more of a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal controller (DSP), and a controller-based multi-core controller architecture. Device 800 may also include multiple processors 810. Processor 810 is coupled to communication unit 840. Communication unit 840 can receive and transmit information via radio signals or by means of optical fibers, cables, and / or other components.

[0251] Generally, the various exemplary embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. When aspects of the exemplary embodiments of this application are illustrated or described as block diagrams, flowcharts, or using some other graphical representation, it will be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0252] As an example, exemplary embodiments of this application can be described in the context of machine or computer-executable instructions, such as program modules included in a device that executes on a real or virtual processor of the target. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various exemplary embodiments, the functionality of program modules may be combined or divided among the described program modules. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside on both local and remote storage media.

[0253] Computer program code used to implement the methods of the embodiments of this application may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the computer or other programmable data processing apparatus, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a standalone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0254] In the context of embodiments of this application, a machine-readable medium or computer-readable medium can be any tangible medium that contains or stores a program for or relating to an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More detailed examples of machine-readable storage media include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0255] Furthermore, although the operations are depicted in a specific order, this should not be construed as requiring such operations to be performed in the specific order shown or in a sequential order, or to execute all illustrated operations to obtain the desired result. In some cases, multitasking or parallel processing may be beneficial. Similarly, although the foregoing discussion includes certain specific implementation details, this should not be construed as limiting the scope of any invention or claim, but rather as a description of specific exemplary embodiments that may be implemented with respect to a particular invention. Certain features described in the context of separate exemplary embodiments in this specification may also be implemented in a single exemplary embodiment. Conversely, various features described in the context of a single exemplary embodiment may also be implemented separately in multiple exemplary embodiments or in any suitable sub-combination.

[0256] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A method for sending multicast messages, characterized in that, The method includes: The intermediate device obtains the identifier of the region corresponding to the multicast message based on the multicast message from the ingress device, wherein the region contains one or more Autonomous System (AS) domains; The intermediate device obtains the address of the next-hop device based on the identifier of the region and the forwarding table entry, wherein the forwarding table entry contains the identifier of the region and the address of the next-hop device; The intermediate device sends the multicast message based on the address of the next-hop device.

2. The method according to claim 1, characterized in that, The multicast message includes the identifier of the region. The intermediate device obtains the identifier of the region corresponding to the multicast message based on the multicast message from the ingress device, including: the intermediate device obtaining the identifier of the region from the multicast message; or The multicast message includes the identifier of the intermediate device. The intermediate device obtains the identifier of the region corresponding to the multicast message based on the multicast message from the ingress device, which includes: the intermediate device obtains the identifier of the region corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The intermediate device receives the address of the next-hop device and the identifier of the region to which the next-hop device belongs, sent by the next-hop device; The intermediate device obtains the forwarding table entry based on the identifier of the region and the address of the next-hop device.

4. The method according to claim 1 or 2, characterized in that, The method further includes: The intermediate device receives the identifier of the next-hop device and the identifier of the region to which the next-hop device belongs, sent by the next-hop device; The intermediate device obtains the address of the next-hop device based on the identifier of the next-hop device; The intermediate device obtains the forwarding table entry based on the identifier of the region and the address of the next-hop device.

5. The method according to claim 3 or 4, characterized in that, The method further includes: The intermediate device receives the range of Bit Forwarding Router (BFR) identifiers within the destination AS domain sent by the next-hop device. The destination AS domain is the AS domain to which the next-hop device belongs, which is included in the region. The forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

6. The method according to claim 5, characterized in that, The multicast message also includes the range of the BFR identifier, and the method further includes: The intermediate device determines the forwarding table entry based on the identifier of the region and the range of the BFR identifier.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The intermediate device sends its address and the identifier of the region to which it belongs to the entry device.

8. The method according to claim 7, characterized in that, The method further includes: The intermediate device sends the range of BFR identifiers within the AS domain to which the intermediate device belongs to the entry device, wherein the AS domain to which the intermediate device belongs is included in the region to which the intermediate device belongs.

9. A method for sending multicast messages, characterized in that, The method includes: The ingress device obtains the identifier of the region corresponding to the received multicast message, wherein the region contains one or more Autonomous System (AS) domains; The ingress device obtains the address of an intermediate device for forwarding the multicast message to the region based on the region's identifier and forwarding table entries, wherein the forwarding table entries include the region's identifier and the intermediate device's address. The entry device sends the multicast message based on the address of the intermediate device.

10. The method according to claim 9, characterized in that, The method further includes: The entry device receives the address of the intermediate device and the identifier of the region sent by the intermediate device; The entry device obtains the forwarding table entry based on the address of the intermediate device and the identifier of the region.

11. The method according to claim 9, characterized in that, The method further includes: The entry device receives the identifier of the intermediate device and the identifier of the area sent by the intermediate device; The entry device determines the address of the intermediate device based on the identifier of the intermediate device; The entry device obtains the forwarding table entry based on the address of the intermediate device and the identifier of the region.

12. The method according to claim 10 or 11, characterized in that, The method further includes: The entry device receives the range of BFR identifiers within the destination Autonomous System (AS) domain sent by the intermediate device. The destination AS domain is the AS domain to which the multicast message contained in the region needs to be sent. The forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

13. The method according to claim 12, characterized in that, The method further includes: The entry device determines the forwarding table entry based on the range of BFR identifiers within the destination AS domain and the identifier of the region.

14. The method according to any one of claims 9 to 13, characterized in that, The multicast message contains the identifier of the region, and the ingress device obtains the identifier of the region corresponding to the received multicast message by: the ingress device obtaining the identifier of the region from the multicast message; or The multicast message contains the identifier of the intermediate device. The process by which the ingress device obtains the identifier of the region corresponding to the received multicast message includes: the ingress device obtaining the identifier of the region corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message.

15. An apparatus for transmitting multicast messages, characterized in that, The device is disposed in the intermediate equipment, and the device includes: The first obtaining module is used to obtain the identifier of the region corresponding to the multicast message based on the multicast message from the ingress device, wherein the region contains one or more Autonomous System (AS) domains; The second obtaining module is used to obtain the address of the next-hop device based on the identifier of the region and the forwarding table entry, wherein the forwarding table entry contains the identifier of the region and the address of the next-hop device; The first sending module is used to send the multicast message based on the address of the next-hop device.

16. The apparatus according to claim 15, characterized in that, The multicast message includes the identifier of the region, and the first obtaining module is used to obtain the identifier of the region from the multicast message; or The multicast message includes the identifier of the intermediate device, and the first obtaining module is used to obtain the identifier of the region corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message.

17. The apparatus according to claim 15 or 16, characterized in that, The device further includes: A first receiving module is configured to receive the address of the next-hop device and the identifier of the region to which the next-hop device belongs, sent by the next-hop device; and The third obtaining module is used to obtain the forwarding table entry based on the identifier of the region and the address of the next-hop device.

18. The apparatus according to claim 15 or 16, characterized in that, The device further includes: A first receiving module is configured to receive the identifier of the next-hop device and the identifier of the area to which the next-hop device belongs, sent by the next-hop device; and The third obtaining module is used to obtain the address of the next-hop device based on the identifier of the next-hop device; The third obtaining module is used to obtain the forwarding table entry based on the identifier of the region and the address of the next-hop device.

19. The apparatus according to claim 17 or 18, characterized in that, The first receiving module is used to receive the range of Bit Forwarding Router (BFR) identifiers within the destination AS domain sent by the next-hop device. The destination AS domain is the AS domain to which the next-hop device belongs, which is included in the area. The forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

20. The apparatus according to claim 19, characterized in that, The multicast message also includes the range of the BFR identifier, and the second obtaining module is used to determine the forwarding table entry based on the identifier of the region and the range of the BFR identifier.

21. The apparatus according to any one of claims 15 to 20, characterized in that, The device further includes: The second sending module is used to send the address of the intermediate device and the identifier of the region to which the intermediate device belongs to the entry device.

22. The apparatus according to claim 21, characterized in that, The second sending module is further configured to send the range of BFR identifiers within the AS domain to which the intermediate device belongs to the entry device, wherein the AS domain to which the intermediate device belongs is included in the region to which the intermediate device belongs.

23. An apparatus for transmitting multicast messages, characterized in that, The device is located at the inlet equipment, and the device includes: The first obtaining module is used to obtain the identifier of the region corresponding to the received multicast message, wherein the region contains one or more Autonomous System (AS) domains; The second obtaining module is used to obtain, based on the identifier of the region and the forwarding table entry, the address of the intermediate device for forwarding the multicast message to the region, wherein the forwarding table entry includes the identifier of the region and the address of the intermediate device; The first sending module is used to send the multicast message based on the address of the intermediate device.

24. The apparatus according to claim 23, characterized in that, The device further includes: A first receiving module is configured to receive the address of the intermediate device and the identifier of the region sent by the intermediate device; and The third obtaining module is used to obtain the forwarding table entry based on the address of the intermediate device and the identifier of the region.

25. The apparatus according to claim 23, characterized in that, The device further includes: A first receiving module is configured to receive the identifier of the intermediate device and the identifier of the region sent by the intermediate device; and The third obtaining module is used to determine the address of the intermediate device based on the identifier of the intermediate device; The third obtaining module is used to obtain the forwarding table entry based on the address of the intermediate device and the identifier of the region.

26. The apparatus according to claim 24 or 25, characterized in that, The second receiving module is also used for: The intermediate device receives the range of BFR identifiers within the destination Autonomous System (AS) domain, where the destination AS domain is the AS domain to which the multicast message needs to be sent, and the forwarding table entry also includes the range of BFR identifiers within the destination AS domain.

27. The apparatus according to claim 26, characterized in that, The second obtaining module is used to determine the forwarding table entry based on the range of BFR identifiers within the target AS domain and the identifier of the region.

28. The apparatus according to any one of claims 23 to 27, characterized in that, The multicast message contains the identifier of the region, and the first obtaining module is used to obtain the identifier of the region from the multicast message; or The multicast message contains the identifier of the intermediate device, and the first obtaining module is used to obtain the identifier of the region corresponding to the identifier of the intermediate device based on the identifier of the intermediate device in the multicast message.

29. A system, characterized in that, The system includes the apparatus according to any one of claims 15 to 22 and the apparatus according to any one of claims 23 to 28.

Images