WO2024045537A1

WO2024045537A1 - Message transmission method and network device

Info

Publication number: WO2024045537A1
Application number: PCT/CN2023/079614
Authority: WO
Inventors: 谢经荣; 段方红; 张耀坤
Original assignee: 华为技术有限公司
Priority date: 2022-08-31
Filing date: 2023-03-03
Publication date: 2024-03-07
Also published as: CN117675440A

Abstract

Provided in the embodiments of the present application are a message transmission method and a network device. The method comprises: an ingress node receiving a first message, which is sent by a user edge device, wherein the first message contains a first message header and a payload, and the first message header comprises multicast source group information; the ingress node acquiring tunnel information according to the multicast source group information and a correlation, wherein the correlation comprises the multicast source group information and the tunnel information; the ingress node obtaining a second message according to the payload and the tunnel information, wherein the second message contains the payload and a second message header, which corresponds to the tunnel information, and the second message does not comprise the first message header; and the ingress node sending the second message through a tunnel corresponding to the tunnel information.

Description

Message transmission methods and network equipment

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on August 31, 2022, with application number 202211063430.9 and application name "Message transmission method and network equipment", the entire content of which is incorporated by reference. in this application.

Technical field

This application relates to the field of communications, and in particular to message transmission methods and network equipment.

Background technique

With the development of communication technology, the demand for the use of multicast technology in scenarios such as live video broadcast and video conferencing is increasing. On the one hand, multicast technology can provide point-to-multipoint forwarding in the network, effectively reducing network redundant traffic and reducing network load. On the other hand, it can reduce the load on servers and processors in the application platform, reducing the impact of the increase in the number of users. Impact on multicast sources. The network frame based on multicast technology can include user networks and backbone networks. The backbone network can use different tunnels for packet transmission. For example, the backbone network can support one or more tunnels. Multicast packets from user networks need to be encapsulated when entering the backbone network. The encapsulated packets are transmitted through the tunnel in the backbone network. When the encapsulated packet leaves the backbone network, the multicast packet is obtained through decapsulation. Multicast packets are forwarded to the user network where the multicast receiver is located. The backbone network can be a network running a Multicast Virtual Private Network VPN (MVPN) or an Ethernet Virtual Private Network (Ethernet VPN, EVPN). The above-mentioned multicast packet transmission method has the problem of high transmission overhead.

Contents of the invention

This application provides a message transmission method and network equipment, which can reduce the transmission overhead of multicast messages in the backbone network.

In a first aspect, this application provides a message transmission method, including: an entry node receives a first message sent by a user edge device, where the first message includes a first message header and a payload, and the first message The message header includes multicast source group information; the entry node obtains tunnel information according to the multicast source group information and the corresponding relationship, where the corresponding relationship includes the multicast source group information and the tunnel information; The entry node obtains a second message according to the payload and the tunnel information. The second message includes the payload and a second message header corresponding to the tunnel information. The second message does not include the The first message header is provided; the ingress node sends the second message through the tunnel corresponding to the tunnel information.

The method provided by this application is applicable to a network architecture based on multicast technology. The network architecture may include a user network and a backbone network. The backbone network includes an entry node, an intermediate node, and an exit node. The entry node and the exit node are the same as those in the backbone network. The edge node of the user network for message exchange. In the embodiment of this application, the message sent by the CE device is recorded as the first message. The entrance node encapsulates the received first message to obtain the second message header, and adds the first message header of the first message to Delete, get the second message and forward it. In the backbone network, depending on the actual settings of the ingress node, intermediate node, and egress node, the second message may be forwarded to the egress node through one or more intermediate nodes, or the second message may be forwarded by the ingress node to the egress node. When the second packet reaches the egress node, the egress node The packet is encapsulated to obtain the first packet header, and the second packet header is deleted to obtain the first packet. The first header in the first message may be an Internet Protocol version 6 (IPv6) header or an Internet Protocol version 4 (IPv4) header. The multicast source group information is the source address and destination address in the first message, and the destination address is the multicast group address.

The corresponding relationship is the relationship between the multicast source group information and the tunnel information of each node in the backbone network, and can be established by the ingress node. Furthermore, the tunnel information determined based on the correspondence relationship corresponds to the second packet header. When different tunnel correspondence scenarios are adopted between the ingress node and the egress node, the tunnel information and the second packet header can be expressed in different ways, such as In a scenario where an IP multicast tunnel is used between an ingress node and an egress node, for example, the ingress node encapsulates based on Internet Protocol (IP). Further, the ingress node can encapsulate based on IPv6, and the resulting second message header includes IPv6 header, the IPv6 header includes the source address and destination address corresponding to the tunnel information, where the destination address is the multicast group address corresponding to the multicast tree; bit index based on IPv6 encapsulation is explicitly copied between the ingress node and the egress node. (Bit Index Explicit Replication IPv6 Encapsulation, BIERv6) In the scenario of a multicast tunnel, the BIERv6 header includes the source address and destination address corresponding to the tunnel information, where the destination address is a unicast address, or the BIERv6 header may include the source address corresponding to the tunnel information. The source address, excluding the destination address; in the scenario where a Multiprotocol Label Switching point-to-multipoint (MPLS P2MP) tunnel is used between the ingress node and the egress node, the tunnel information and the second report The header corresponds to the MPLS label. In the scenario where a BIER multicast tunnel is used between the ingress node and the egress node, the tunnel information and the second header correspond to the upstream MPLS label.

In a possible implementation manner, the second message header includes an IPv6 header and a Generic Routing Encapsulation (GRE) header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the second message header includes an IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the second message header includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the second message header includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the destination address is the address of the next hop of the entry node in the multicast tree or the destination address is the multicast group address corresponding to the multicast tree.

In a possible implementation manner, the second message header corresponding to the tunnel information is a Multiprotocol Label Switching (MPLS) header, and the MPLS header includes the entry node in the multicast tree. The MPLS label of the next hop node or the MPLS label corresponding to the multicast tree.

In a possible implementation manner, the second message header corresponding to the tunnel information includes a Bit Index Explicit Replication (BIER) header and a label, and the BIER header includes the information related to the tunnel information. The identifier of the egress node corresponding to the information, and the label is used to identify the multicast source group information.

In a possible implementation manner, the method further includes: the ingress node notifying the egress node of the corresponding relationship. In another possible implementation manner, the corresponding relationship may be static configuration of the entry node and the exit node respectively.

In a possible implementation manner, the method further includes: the ingress node notifying the egress node of indication information, where the indication information is used to instruct restoration of the multicast source group information. Wherein, the indication information is used to instruct to restore the multicast source group information, that is, the indication information is at least used to instruct the egress node to restore the multicast source group information of the first packet header, so that The egress node obtains the first message according to the indication information and the second message.

In a possible implementation manner, the ingress node notifying the corresponding relationship to the egress node includes: the ingress node sends a Border Gateway Protocol (Border Gateway Protocol, BGP) message to the egress node, and the BGP message includes the corresponding relationship. For example, the BGP message is Border Gateway Protocol-Multicast VPN (BGP-MVPN) signaling or Border Gateway Protocol-Ethernet VPN (BGP-EVPN) ) signaling.

In the embodiment of this application, the entrance node deletes the first message header and encapsulates the second message header to obtain a second message. The second message is transmitted in the backbone network. When it reaches the egress node, the egress node deletes the second message. Second packet header, restore the first packet header to obtain the first packet. In this way, during the transmission of the backbone network, the second packet no longer needs to carry the first packet header, which can reduce the time of packet transmission in the backbone network. overhead.

In a second aspect, this application provides a message transmission method, including: an egress node receiving a second message, the second message including a payload and a second message header corresponding to tunnel information; the egress node Obtain multicast source group information according to the corresponding relationship and the tunnel information corresponding to the second message header, where the corresponding relationship includes the tunnel information and the multicast source group information; the egress node obtains the multicast source group information according to the Multicast source group information and the payload are obtained in a first message, the first message includes a first message header and the payload, the first message header includes the multicast source group information, and the The first message does not include the second message header.

In a possible implementation manner, the second message header includes an IPv6 header and a GRE header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, before the egress node obtains the first message according to the multicast source group information and the payload, the method further includes: the egress node receives a third message, and the third message The message includes the payload and a third message header corresponding to the tunnel information; the egress node obtains the multicast source group information according to the corresponding relationship and the tunnel information corresponding to the third message header, The third message header is an MPLS header, and the MPLS header includes the MPLS label allocated by the egress node for the multicast tree or the MPLS label corresponding to the multicast tree.

In a possible implementation manner, the second message header corresponding to the tunnel information includes a BIER header and a label, the BIER header includes an identification of the egress node corresponding to the tunnel information, and the label is To identify the multicast source group information.

In a possible implementation manner, the method further includes: the egress node obtains the corresponding relationship advertised by the ingress node.

In a possible implementation manner, the method further includes: the egress node receiving indication information advertised by the ingress node, where the indication information is used to instruct restoration of the multicast source group information.

In a possible implementation manner, the egress node obtaining the corresponding relationship advertised by the ingress node includes: The egress node receives the BGP message sent by the ingress node, and the BGP message includes the corresponding relationship.

In a possible implementation manner, the BGP message is BGP-MVPN signaling or BGP-EVPN signaling.

In a third aspect, the present application provides a network device. The network device is provided at an entrance node. The network device includes: a receiving module configured to receive a first message sent by a user edge device. The first message Containing a first packet header and a payload, the first packet header including multicast source group information; a processing module configured to obtain tunnel information according to the multicast source group information and a corresponding relationship, the corresponding relationship including all The multicast source group information and the tunnel information; the processing module is also configured to obtain a second message according to the load and the tunnel information, where the second message includes the payload and the tunnel information. a second message header corresponding to the information, the second message not including the first message header; and a sending module configured to send the second message through the tunnel corresponding to the tunnel information.

In a possible implementation manner, the second message header is an MPLS header, and the MPLS header includes the MPLS label of the next hop node of the entry node in the multicast tree or the MPLS label corresponding to the multicast tree.

In a possible implementation manner, the second message header includes a BIER header and a label, the BIER header includes an identification of the egress node corresponding to the tunnel information, and the label is used to identify the group Source group information.

In a possible implementation manner, the sending module is also configured to notify the egress node of the corresponding relationship.

In a possible implementation manner, the sending module is further configured to notify the egress node of indication information, where the indication information is used to instruct restoration of the multicast source group information.

In a possible implementation manner, the sending module is specifically configured to send a BGP message to the egress node, where the BGP message includes the corresponding relationship.

In a possible implementation manner, the BGP message is BGP-MVPN signaling or Border Gateway Protocol-BGP-EVPN signaling.

In a fourth aspect, the present application provides a network device. The network device is provided at an egress node. The network device includes: a receiving module configured to receive a second message. The second message includes a payload and a tunnel link. a second message header corresponding to the information; a processing module configured to obtain multicast source group information according to the corresponding relationship and the tunnel information corresponding to the second message header, where the corresponding relationship includes the tunnel information and the tunnel information corresponding to the second message header; The multicast source group information; the processing module is also configured to obtain a first message according to the multicast source group information and the payload, where the first message includes a first message header and the payload, The first message header includes the multicast source group information, and the first message does not include the second message header.

In a possible implementation manner, the second packet header corresponding to the tunnel information includes an IPv6 header and a GRE header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the second message header corresponding to the tunnel information includes an IPv4 header and GRE header, the IPv4 header includes the source address and destination address corresponding to the tunnel information.

In a possible implementation manner, the second packet header corresponding to the tunnel information includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the second packet header corresponding to the tunnel information includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible implementation manner, the receiving module is also configured to receive a third message, the third message including the payload and a third message header corresponding to the tunnel information; the processing module , and is further configured to obtain the multicast source group information according to the corresponding relationship and the tunnel information corresponding to the third message header, where the third message header is a multi-protocol label switching MPLS header, and the The MPLS header includes the MPLS label allocated by the egress node for the multicast tree or the MPLS label corresponding to the multicast tree.

In a possible implementation manner, the receiving module is also configured to obtain the corresponding relationship advertised by the entry node.

In a possible implementation manner, the receiving module is further configured to receive indication information advertised by the ingress node, where the indication information is used to instruct restoration of the multicast source group information.

In a possible implementation manner, the receiving module is specifically configured to receive a BGP message sent by the ingress node, where the BGP message includes the corresponding relationship.

In a fifth aspect, the present application provides a network device. The network device includes a communication interface and a processor. The communication interface is used to execute the method described in any of the foregoing aspects and any possible implementation of any aspect. Regarding the transceiver operation involved, the processor is configured to perform other operations other than the transceiver operation involved in the method described in any of the above aspects and any possible implementation of any aspect. For example, when the network device described in the fifth aspect is configured at the entrance node to execute the method described in the first aspect, the processor is configured to obtain tunnel information according to the multicast source group information and the corresponding relationship, and the corresponding relationship includes The multicast source group information and the tunnel information are used to obtain a second message according to the payload and the tunnel information. The second message includes the payload and a second message corresponding to the tunnel information. header, the second message does not include the first message header, the communication interface is used to receive the first message sent by the user edge device, the first message includes the first message header and payload, The first message header includes multicast source group information, and a second message is obtained according to the payload and the tunnel information. The second message includes the payload and a second message corresponding to the tunnel information. header, the second message does not include the first message header. When the network device described in the fifth aspect is configured at the egress node to perform the method described in the second aspect, the communication interface is used to receive a second message, and the second message includes a payload and a second message corresponding to the tunnel information. message header, the processor is configured to obtain multicast source group information according to the corresponding relationship and the tunnel information corresponding to the second message header, where the corresponding relationship includes the tunnel information and the multicast source group Information, obtain a first message according to the multicast source group information and the payload, the first message includes a first message header and the payload, the first message header includes the multicast source Group information, the first message does not include the second message header.

In a sixth aspect, this application provides a communication system used for message transmission, including: a network device provided at an entry node provided by the third aspect, and a network provided at an exit node provided by the fourth aspect. Equipment, the network equipment provided at the entry node is used to perform some or all of the operations performed by the first device in the first aspect and any possible implementation of the first aspect; the network equipment provided at the exit node For performing part or all of the operations performed by the second device in the second aspect and any possible implementation of the second aspect.

In a possible implementation manner, the system further includes a network device provided at the intermediate node, configured to receive the second message forwarded by the network device provided at the entrance node, and forward the second message .

In a seventh aspect, the present application provides a computer-readable storage medium that stores instructions that, when run on a processor, implement the method described in any of the foregoing aspects and any of the foregoing aspects. Some or all of the operations included in any possible implementation of the aspect.

In an eighth aspect, the application provides a computer program product, which includes instructions that, when run on a processor, implement the method described in any of the foregoing aspects and any possible method of any of the foregoing aspects. Some or all of the operations included in the implementation.

In a ninth aspect, this application provides a chip including: an interface circuit and a processor. The interface circuit is connected to the processor, and the processor is configured to cause the chip to perform some or all of the operations included in the method described in any of the foregoing aspects and any possible implementation of any of the foregoing aspects. .

Description of drawings

In order to explain the technical solutions of the embodiments of the present application more clearly, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is a schematic structural diagram of a backbone network provided by an embodiment of the present application;

Figure 2 is a schematic diagram of a network architecture provided by an embodiment of the present application;

Figure 3 is a schematic flowchart of a message transmission method provided by an embodiment of the present application;

Figure 4 is a schematic structural diagram of an encapsulated and decapsulated message provided by an embodiment of the present application;

Figure 5 is a schematic flow chart of another message transmission method provided by an embodiment of the present application;

Figure 6 is a schematic structural diagram of another encapsulated and decapsulated message provided by an embodiment of the present application;

Figure 7 is a schematic structural diagram of another encapsulation and decapsulation message provided by an embodiment of the present application;

Figure 8 is a schematic structural diagram of another encapsulated and decapsulated message provided by an embodiment of the present application;

Figure 9 is a configuration method provided by an embodiment of the present application;

Figure 10 is a schematic structural diagram of another encapsulated and decapsulated message provided by an embodiment of the present application;

Figure 11 is a schematic structural diagram of an entry node provided by an embodiment of the present application;

Figure 12 is a schematic structural diagram of an exit node provided by an embodiment of the present application;

Figure 13 is a schematic structural diagram of a network device 30 provided by an embodiment of the present application;

FIG. 14 is a schematic structural diagram of a network device 40 provided by an embodiment of the present application.

Detailed ways

In order to enable those skilled in the art to better understand the solutions in this application, the following will be combined with the examples in this application The accompanying drawings clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments.

The term "and/or" in this article is just an association relationship that describes related objects, indicating that three relationships can exist. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and they exist alone. B these three situations.

The terms “first” and “second” in the description and claims of the embodiments of this application are used to distinguish different objects, rather than to describe a specific order of objects. For example, the first target object, the second target object, etc. are used to distinguish different target objects, rather than to describe a specific order of the target objects.

In the embodiments of this application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "such as" in the embodiments of the present application is not to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the words "exemplary" or "such as" is intended to present the concept in a concrete manner.

In the description of the embodiments of this application, unless otherwise specified, the meaning of “plurality” refers to two or more. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

In order to facilitate understanding, the relevant nouns or terms used in the embodiments of this application are explained below:

1. Multicast technology

A technology that can achieve efficient point-to-multipoint transmission in the network. Multicast technology can effectively save network bandwidth and reduce the network load of data transmission.

2. Specified source mode protocol independent multicast (Protocol Independent Multicast-Source-Specific Multicast, PIM-SSM)

PIM-SSM is an extension of the traditional PIM protocol and supports receiving multicast service flows from multicast sources. SSM represents the multicast service of a specific source. In SSM, only the multicast packets of the specific source requested by the receiver can be forwarded. To the receiver, the multicast receiver can specify to receive or reject traffic from a specific multicast source when joining the multicast source.

3. Tunnel

Tunneling technology is a way of transmitting data between networks by using the Internet infrastructure, including the entire process of data encapsulation, transmission and decapsulation. The logical path that encapsulated data takes when transmitted over the network is called a tunnel.

4. GRE

The GRE protocol encapsulates data packets of network layer protocols (such as IPv4 and IPv6) so that these encapsulated data packets can be transmitted in network layer protocols such as IP. GRE uses tunneling technology. Depending on the transmission protocol, , can be divided into two tunnel modes: GRE over IPv4 and GRE over IPv6.

5. MPLS

MPLS is a tunnel technology suitable for networks such as the backbone network in this application. It can perform label switching on the backbone network. MPLS can support multiple network protocols, such as IPv4, IPv6, and Internet Packet Exchange (IPX). protocol and connectionless network protocol (ConnectionLess Network Protocol, CLNP), etc.

6.BIER

It is a new multicast technology based on bit index explicit replication. In the scenario where BIER multicast tunnel is used between the entry node and the exit node, the backbone network is equivalent to the BIER domain. Usually, the BIER domain includes routers with three roles: The ingress router that receives multicast packets is the Bit Forwarding Ingress Router (BFIR), the last hop router leaving the BIER domain is the Bit Forwarding Egress Router (BFER), and other intermediate routers are collectively called Bit Forwarding Egress Router (BFER). Bit Forwarding Router (BFR), where, BFIR and BFER belong to edge BFR. For example, corresponding to the backbone network provided by the embodiment of the present application, BFIR is set at the entrance node position, BFER is set at the exit node position, and BFR is set at the intermediate node position. In the scenario where BIER multicast tunnel is used, multicast packet transmission is a kind of stateless multicast forwarding. Since BFR does not have any multicast information, there is no need to maintain the multicast status or establish a multicast forwarding tree. Relying on The bit string in the forwarding table and multicast message is copied and forwarded.

7. BitString

The bits in BitString are used to correspond to the identification of BFER. Since each edge BFR of the BIER domain is configured with a BIER Forwarding Router Identifier (BFR-ID), the BFR-ID value range is an integer from 1 to 65535. , therefore, the BitString composed of the BFR-ID of the bit forwarding egress router forms the egress node set, and the position or index of each Bit in the BitString is used to determine the BFER.

8. Bit Index Explicit Replication IPv6 encapsulation (BIERv6) based on IPv6 encapsulation

BIERv6 is a new multicast technology. In the scenario where BIERv6 tunnel is used between the ingress node and the egress node, the backbone network encapsulates the set of egress nodes in a message in the form of a bit string and sends it to the intermediate node. The intermediate node does not need To maintain multicast status, there is no need to build a multicast distribution tree. Instead, copying and forwarding are completed based on the bit strings carried in the packets matching the forwarding table.

9. IPv6 extension header

The IPv6 extension header is an optional header. The IPv6 extension header includes the routing header (Routing Header, RH), the destination options header (Destination Options Header, DOH), etc.

The embodiments of the present application may be applied to a multicast network, which includes a user network and a backbone network. The user network may be a network running IPv6 or IPv4, and the backbone network may be a network running MVPN or EVPN. The backbone network provided by the embodiments of this application can use different tunnels for packet transmission. A backbone network can support the use of one or more tunnels. Under this network architecture, multicast packets in the user network enter the backbone. When the packet is connected to the network, it can be encapsulated according to the encapsulation method corresponding to the tunnel used by the backbone network. When the packet leaves the backbone network, it can be decapsulated in the method corresponding to the encapsulation. Figure 1 is a schematic structural diagram of a backbone network provided by an embodiment of the present application. As shown in Figure 1, the backbone network includes a network device 100 disposed at an entry node, abbreviated as the entry node 100, and a network device 200 disposed at an intermediate node. , abbreviated as the intermediate node 200 and the network device 300 set at the egress node, abbreviated as the egress node 300, wherein the entry node 100 receives the message sent by the user network and encapsulates the message, and sends it to the intermediate node 200 , after being forwarded or copied and forwarded by the intermediate node 200, it is sent to the egress node 300, and then the egress node 300 decapsulates the message and sends the decapsulated message to the user network. In some instances, when the backbone network uses different tunnel corresponding scenarios, it supports multiple encapsulation methods, such as IP+GRE encapsulation, IP encapsulation, MPLS encapsulation, etc. With the introduction of stateless multicast, the backbone network The network can also support the use of BIER encapsulation (RFC8279, RFC8296, RFC8556) or the use of BIERv6 encapsulation. For example, the entry node 100 can encapsulate the received message using IP+GRE, and the message is encapsulated with an IP header+GRE header; or use IP for encapsulation, and the message is encapsulated with an IP header; or use It is encapsulated in MPLS mode, and the packet is encapsulated with an MPLS header. However, after the entry node 100 encapsulates the message, the overhead of transmitting the message in the backbone network will increase, which will put certain pressure on the network bandwidth. For example, the multicast service in the user network is based on IPv6, and the multicast packet received from the user network is an IPv6 packet. After the entrance node 100 receives the IPv6 packet, it will For IP tunnels, determine to use IPv6 encapsulation method to encapsulate the received packets. That is, an IPv6 header is encapsulated on the IPv6 message. Therefore, the multicast message is encapsulated with two IPv6 headers, which will occupy a total of 80 bytes, which is equivalent to adding 40 bytes of transmission overhead after entering the backbone network; for another example, The multicast message received by the entrance node 100 is an IPv6 message. According to the tunnel adopted by the backbone network, it is an IP tunnel and supports the IPv6 + extension header encapsulation method. Therefore, the IPv6 header + extension header needs to be encapsulated on the IPv6 message, where , the extension header can be DOH, and the header length of the encapsulated IPv6 message can reach 128 bytes, which is equivalent to an increase of 84 bytes of transmission overhead. In order to reduce the transmission overhead of packets in the backbone network, in some instances, the entrance node will delete the source address and destination address in the received multicast packet. However, this method will make the multicast packet not conform to the standard format. Problems that are prone to message errors are difficult to locate and affect the deployment and use of the solution. Therefore, embodiments of the present application provide a message transmission method, which can effectively reduce the message transmission overhead in the backbone network and solve the problem of bandwidth waste on the basis that the message format conforms to the specifications. Figure 2 is a schematic diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 2, the network architecture includes a backbone network and a user network. The backbone network includes an entrance node 1000, intermediate nodes (including intermediate nodes 2001 and Intermediate node 2002), exit node (including exit node 1 marked as 3001 in Figure 2, exit node 2 marked as 3002 in Figure 2, and exit node 3 marked as 3003 in Figure 2), the user network includes Customer Edge (CE) equipment ( Including CE device 1 marked as 4001 in Figure 2, CE device 2 marked as 4002 in Figure 2, and CE device 3 marked as 4003 in Figure 2), the user network may also include a server connected to each CE device. In the network architecture scenario provided in Figure 2, the packet sent by CE1 to the backbone network is a multicast packet encapsulated with an IP header as an example. The entry node 1000 encapsulates the multicast packet sent by CE device 1. At the same time, the IP header of the multicast message is deleted. The ingress node 1000 forwards the encapsulated message. The encapsulated message is forwarded by the intermediate node 2001 and the intermediate node 2002. Finally, it can be decapsulated by the egress node 1 and encapsulate the IP header. , obtain the multicast message, and then send it to the CE device corresponding to the multicast address of the multicast message in the user network, such as sending it to CE device 2. Further, if the destination address of the multicast message received by the entrance node 1000 is multicast group address 1, and both CE device 2 and CE device 3 are added to the multicast group address, then the following figure can be used: As shown in 2, egress node 1 sends a multicast message to CE device 2 according to the destination address of the multicast message, and egress node 3 sends a multicast message to CE device 3 according to the destination address of the multicast message. The method provided by the embodiment of the present application can be applied to the scenario provided in Figure 2, but is not limited thereto.

Figure 3 is a schematic flowchart of a message transmission method provided by an embodiment of the present application. As shown in Figure 3, the method includes:

S101. The entry node receives a first message sent by the user edge device. The first message includes a first message header and a payload, and the first message header includes multicast source group information.

The first message is a multicast message including multicast source group information. The multicast source group information includes the source address S and the destination address in the multicast message. The destination address is the multicast group address, denoted as G, multicast The source group information is denoted as (S, G). Taking the scenario shown in Figure 2 as an example, the entrance node 1000 can be used to receive the multicast message sent by the CE device 1, and this message can be recorded as the first message. The first header in the first message received by the entrance node 1000 may belong to the IPv6 header or the IPv4 header. For example, the first message header belongs to the IPv6 header, that is, the C-IP Header belongs to IPv6. Table 1 shows IPv6. An illustration of each header field.

Table 1

As shown in Table 1, the IPv6 header includes the following parts:

Version number (Version, Ver): The version number of IPv6 is 6, and Ver occupies 4 bits;

Transmission type (Traffic Class, TC): used to distinguish the types and priorities of different IPv6 messages, TC accounts for 8 bits;

Flow Label (FL): A "flow" identifies the packet from the source address to the destination address. The "flow" from source address A to destination address B is the same "flow" and its packets have the same flow label, FL. Occupies 20 bits;

Payload Length (PL): used to identify the length of other parts of the message except the IPv6 header. If the message is encapsulated with an extension header, the length of the PL identifier is the length of the extension header plus the payload. PL occupies 16 bits. (bit).

Next Header (NH): It can indicate the next header field immediately following this IPv6 header and is used to describe the existence and type of other extension headers after the IPv6 header. NH occupies 8 bits;

Hop Limit (HL): used to set the upper limit of the number of routers that packets can pass through. It can be initialized to a value. Each router reduces the value by 1 when forwarding packets. When it is reduced to 0, the limit is reached. Discard the message, HL occupies 8 bits;

Source Address (SA): carries the address of the user equipment sending IPv6 messages, SA occupies 128 bits;

Destination Address (DA): carries the address of the user equipment that receives IPv6 messages. DA occupies 128 bits.

For example, the first packet header belongs to the IPv4 header, that is, the C-IP Header belongs to IPv4. Table 2 shows the fields of the IPv4 header. As shown in Table 2, the IPv4 header includes the following parts:

Table 2

As shown in Table 2, the IPv4 header includes the following parts:

Version number (version, Ver): The version number of IPv4 is 4, set to 0100, Ver accounts for 4 bits;

Header length (Internet Header Length, IHL): IHL is used to identify the length of the IPv4 header, in 32-bit units. It can have up to 15 32-bit words, and the minimum value of a valid header is 5. IHL occupies 4 bits. );

Type of Service (TOS): The first 6 bits of this field are the differentiated service field, and the last 2 bits are the congestion notification field or indication bit, used to indicate the quality of service, and TOS occupies 8 bits;

Total Length: Used to identify the total length of the message, in bytes. Through the total length field and the IHL field, the starting position and length of the data part of the message can be determined, and then the start of the data part can be determined. and the end position, the total length accounts for 16 bits (bit);

Identifier is used to identify the group to which the segment belongs. Segment identifiers in the same group are the same, and the identifier occupies 16 bits;

Flags: Represents fragmentation-related information, and flags occupy 3 bits;

Fragment Offset (FO) is used for reordering and identifying the position of each fragment being fragmented relative to the original data. FO occupies 13 bits;

Time to Live (TTL) is used to identify the maximum survival time. Each time a packet passes through a router, the TTL field is subtracted by 1 until it reaches 0 and is discarded. Usually measured in hops, TTL accounts for 8 bits;

Protocol is used to identify the upper layer protocol type encapsulated by the IP layer. The protocol occupies 8 bits;

Header Checksum (Header Checksum), this field is a checksum code calculated based on the IP header. It is used for header error checking. The data part is not checked. The header checksum occupies 16 bits;

Source Address (SA): carries the address of the user device that sends IPv4 messages, SA occupies 32 bits;

Destination Address (DA): carries the address of the user equipment that receives IPv4 messages. DA occupies 128 bits;

Optional fields (options) are used to provide some control functions, and the length of optional fields is variable;

Padding: In the case of optional fields, the header length may not be an integer multiple of 32 bits. The 32 bits are padded by filling in 0 in the padding field.

Each field in the IPv4 header may be as shown in Table 2, or there may be no optional fields and padding fields. Table 2 is not used as an example.

S102. The entrance node obtains tunnel information according to the multicast source group information and the corresponding relationship. The corresponding relationship includes the multicast source group information and tunnel information.

The tunnel information includes information indicating the tunnel through which the message is propagated in the backbone network. When the backbone network uses different tunnels, the tunnel information is expressed in the second message header in a corresponding form.

In some examples, the entry node establishes a corresponding relationship. Returning to the scenario in Figure 2, if the entry node 1000 receives the first message sent by CE device 1, the first message header includes multicast source group information (S1, G1), where the source address in the multicast source group information corresponds to the address of CE device 1 or the server connected to CE device 1, denoted as S1, the group address in the multicast source group information is denoted as G1, CE device 2 and CE Device 3 has all joined the multicast group; or, if the entrance node 1000 receives the first message sent by CE device 1, the multicast source group information included in the first message header is (S1, G2), where , the source address in the multicast source group information corresponds to the address of CE device 1 or the server connected to CE device 1, denoted as S1, the group address in the multicast source group information is G2, and CE device 2 has joined the multicast group. The above are examples applicable to the scenario in Figure 2, but the embodiment of the present application is not limited to the CE device shown in Figure 2. For example, in some other scenarios, based on the CE device 2 and CE device 3 shown in Figure 2, The user network may also be equipped with CE devices such as CE device 4 and CE device 5. When the entry node receives the first message sent by CE device 1, the multicast source group information in the first message header is the multicast source group information. (S1, G3), where S1 indicates that the source address in the multicast source group information is CE device 1 or the address of the server connected to CE device 1, the group address in the multicast source group information is G3, CE device 3 and CE Device 4 has joined the multicast group. From the above example, we can know that the group addresses G1, G2, and G3 in the multicast source group information respectively represent the multicast addresses obtained by different CE devices joining the multicast group.

S103. The entrance node obtains a second message according to the payload and tunnel information. The second message includes the payload and the second message header corresponding to the tunnel information. The second message does not include the first message header.

The tunnel information determined based on the correspondence relationship corresponds to the second packet header. When different tunnel correspondences are used between the ingress node and the egress node, the tunnel information and the second packet header can correspond to different representation methods. For example, at the ingress node In the scenario where an IP multicast tunnel is used between the ingress node and the egress node, for example, the ingress node can be encapsulated based on IPv6. The obtained second message header includes an IPv6 header, and the IPv6 header includes the source address and destination address corresponding to the tunnel information, where the destination The address is the multicast group address corresponding to the multicast tree. In this case, the entry node establishes a corresponding relationship between the multicast source group information (S1, G1) and the tunnel information (S, D) in the IPv6 header, which is recorded as the first corresponding relationship, where the multicast source group information (S1, G1) Refer to the above example, which will not be elaborated here. Tunnel information (S, D), refer to the scene in Figure 2. The source address S in the tunnel information corresponds to the entry node, which can be recorded as S-P1, and the destination address D of the tunnel information. is the multicast group address, which can be recorded as D-P1. Exit node 1, exit node 2 and exit node 3 have all joined the multicast group corresponding to D-P1. In this case, the tunnel information can be recorded as (S-P1 , D-P1), or the source address corresponds to the ingress node, recorded as S-P1, and the group address is recorded as D-P2. Both egress node 1 and egress node 2 have joined the multicast group corresponding to D-P2. In this case Under, the tunnel information can be recorded as (S-P1, D-P2). The above are examples applicable to the scenario in Figure 2. However, the embodiment of the present application is not limited to the entry node and exit node settings shown in Figure 2. For example, based on In addition to the entry node shown in Figure 2, other entry nodes can be set up in the backbone network. In this case, the source address in the tunnel information corresponds to this entry node, which can be recorded as S-P2, and the group address is recorded as D-P2. , egress node 1 and egress node 2 join the multicast group corresponding to D-P2. In this case, the tunnel information can be recorded as (S-P2, D-P2).

An example of the corresponding relationship, such as an example of the first corresponding relationship, can be shown in Table 3:

table 3

If the multicast source group information obtained by the entrance node according to the first message is (S1, G1), then the tunnel information obtained according to the first correspondence is (S-P1, D-P1), and the second message includes (S-P1, D-P1) corresponding second message header. If the multicast source group information obtained according to the first message is (S1, G3), then the tunnel information obtained according to the first correspondence is (S-P2, D-P2), and the second message includes the same as (S -P2, D-P2) corresponding second message header. Table 3 is an example of a first correspondence relationship adapted to the above scenario, and the specific implementation is not limited to the use of Table 3.

In the scenario where a BIERv6 multicast tunnel is used between the ingress node and the egress node, the second packet header is the BIERv6 header. The BIERv6 header includes the source address and destination address corresponding to the tunnel information, where the destination address is a unicast address. Alternatively, the BIERv6 header may only include the source address corresponding to the tunnel information, but not the destination address. The entry node establishes a corresponding relationship between the multicast source group information (S, G) and the tunnel information in the BIERv6 header, which is recorded as the second correspondence. For example, the BIERv6 header includes the source address and destination address corresponding to the tunnel information. The destination When the address is a unicast address, it can be the next hop address of the entry node in the multicast tree. When the next hop of the entry node is an intermediate node, the unicast address is sent to the intermediate node in the message, and the intermediate node determines the address according to the group. The address of the next hop of the broadcast tree is changed until the intermediate node sends the unicast address to the exit node, and the unicast address is changed to the address corresponding to the exit node. In this case, the tunnel information may change during the transmission of the message. For example, the ingress node obtains the information based on the multicast source group information (S1, G1) and the second corresponding relationship. The tunnel information is (S-P1, D-P1). This tunnel information can be recorded as the first tunnel information. The entrance node obtains the second message based on the first tunnel information (S-P1, D-P1). The second message The header includes the source address S-P1 and the destination address D-P1 corresponding to the first tunnel information, where the destination address D-P1 is the address of the intermediate node corresponding to the next hop of the entry node in the multicast tree. The second message is After the intermediate node of the next hop receives the message, the intermediate node obtains the destination address based on the address of the next hop of the multicast tree. Assuming that the next hop of the intermediate node is an exit node, it obtains the destination address based on the address of the exit node and obtains a new The tunnel information can be recorded as the second tunnel information. The intermediate node updates the destination address corresponding to the second tunnel information in the second message header according to the second tunnel information to obtain the third message. The intermediate node sends the third message to the egress node. After receiving the third message, the egress node decapsulates the message. For another example, the second packet header is a BIERv6 header. Preferably, the second correspondence established by the entrance node includes the multicast source group information (S1, G1) and the tunnel information source address in the BIERv6 header, that is, the BIERv6 header only includes When the source address corresponding to the tunnel information does not include the destination address, since the BIERv6 header does not include the destination address, there is no need for the intermediate node to change the destination address. The intermediate node only forwards the second message. Similarly, the second message established on the egress node The corresponding relationship is the same as that of the ingress node, including multicast source group information (S1, G1) and the tunnel information source address in the BIERv6 header, such as S-P1. Further, after receiving the second message, the egress node obtains the multicast source group information (S1, G1) based on the tunnel information source address S-P1 in the BIERv6 header and the second corresponding relationship, and then obtains the multicast source group information (S1, G1) based on the multicast source group information ( S1, G1) encapsulates the first message header and deletes the BIERv6 header to obtain the first message.

In the scenario where an MPLS P2MP tunnel is used between the ingress node and the egress node, the third correspondence established by the ingress node includes the correspondence between the multicast source group information (S1, G1) and the MPLS label. The MPLS label includes the first MPLS label value. , the second packet header encapsulated by the entry node may be an MPLS header. The MPLS header includes an MPLS label corresponding to the tunnel information. The MPLS label may be represented by the first MPLS label value. Further, in the MPLS P2MP tunnel scenario, the corresponding node When a multicast tree is established, such as an MPLS P2MP tree (tunnel), the entry node can establish a fourth corresponding relationship based on the multicast source group information (S, G) obtained from the first message and the identification of the MPLS P2MP tree (tunnel). And notify the egress node of the fourth corresponding relationship; the ingress node also saves all bifurcation information of the MPLS P2MP tree, and the bifurcation information includes one or more bifurcation information of each node on the MPLS P2MP tree (tunnel), where, The nodes on the MPLS P2MP tree (tunnel) correspond to the entry node, intermediate node or exit node in the backbone network. One or more bifurcations of each node correspond to the path between nodes in the backbone network. The entry node can be based on the MPLS P2MP tree. The bifurcation information of the (tunnel) corresponds to assigning the first label value to the identifier of the MPLS P2MP tree (tunnel) to establish the fifth correspondence between the identifier of the MPLS P2MP tree (tunnel) and the first label value. In summary, the entry node can According to the fourth corresponding relationship between the multicast source group information (S, G) and the identifier of the MPLS P2MP tree (tunnel), and the fifth corresponding relationship between the identifier of the MPLS P2MP tree (tunnel) and the first MPLS label value, the multicast source is established The third correspondence between the group information (S, G) and the first MPLS label value. It should be noted that after the second message sent by the entrance node is received by the intermediate node corresponding to the next branch of the entrance node in the MPLS P2MP tree (tunnel), the intermediate node will respond according to the next branch of the MPLS P2MP tree (tunnel). fork, update the MPLS label corresponding to the tunnel information in the second message header, and obtain the third message. Assume that the next fork of the intermediate node in the MPLS P2MP tree (tunnel) corresponds to the egress node, then the intermediate node forwards to the egress node The third message is sent, and the egress node decapsulates the third message after receiving it. The egress node may establish a fourth corresponding relationship based on the advertisement of the ingress node. The egress node may also establish a sixth corresponding relationship between the identifier of the MPLS P2MP tree (tunnel) and the second MPLS label value, where the second MPLS label value may be egress point is the label value assigned to the identifier of the MPLS P2MP tree (tunnel). In summary, the egress node can establish the multicast source group information (S, G) and the second MPLS label value based on the fourth correspondence relationship and the sixth correspondence relationship. The seventh correspondence. Since the identity of the MPLS P2MP tree (tunnel) is determined, the entry node and the egress node respectively establish a third corresponding relationship based on the identity of the MPLS P2MP tree (tunnel), and the seventh correspondence relationship, the same multicast source group information (S, G) can be determined correspondingly. It should be noted that the second MPLS label value corresponding to the multicast source group information in the seventh correspondence relationship on different egress nodes, such as the multicast source group information (S1, G1), can be different, as long as the second MPLS label value can be received after receiving the first After three messages, the multicast source group information (S1, G1) can be determined by establishing the seventh corresponding relationship on the egress node and the second MPLS label value in the third message header.

In the scenario where a BIER multicast tunnel is used between the ingress node and the egress node, the second packet header includes the upstream MPLS label, and the tunnel information corresponds to the second packet header through the upstream MPLS label. For example, the second packet encapsulated by the ingress node The header can be a BIER header + an upstream MPLS label. In the backbone network, the ingress node is the upstream node, and the upstream MPLS label is the MPLS label of the ingress node. In this scenario, the ingress node can establish the eighth correspondence between the multicast source group information (S, G) and the upstream MPLS label, such as , the entry node establishes the eighth correspondence between the multicast source group information (S1, G1) and the upstream MPLS label, and determines the upstream MPLS label according to the multicast source group information (S1, G1) in the first message and the eighth correspondence. , fill in the corresponding label value in the upstream MPLS label that encapsulates the second message; the eighth correspondence established on the egress node includes the correspondence between the multicast source group information (S, G) and the upstream MPLS label. The egress node is based on The upstream MPLS label encapsulated in the second packet determines the multicast source group information (S, G), and the eighth correspondence relationship established on the egress node may be established based on parameters advertised by the ingress node.

The second message obtained by the entry node can be encapsulated according to the encapsulation format supported by the tunnel. The following describes in detail how the entry node obtains the second message by giving examples of different encapsulation formats.

For example, the backbone network can use PIM-SSM signaling to establish a network capable of running MVPN. In the tunnel supported by the backbone network, packets whose encapsulation format refers to RFC6513 12.1.1 can be transmitted, such as packets encapsulated with IPv4 headers. , packets encapsulated with IPv6 header, packets encapsulated with IPv6 header + GRE header, etc. When a multicast message in the user network is sent to the entrance node, the entrance node encapsulates the received message. The encapsulated part of the entrance node is mainly used to transmit the message in the tunnel of the backbone network, so the message reaches the egress When the node is connected, the encapsulated part is deleted. The transmission method provided by the embodiment of the present application can reduce the overhead of transmitting messages in the backbone network caused by encapsulation by the entry node. Figure 4 is a schematic structural diagram of an encapsulation and decapsulation message provided by an embodiment of the present application. Taking the entry node encapsulating the IPv6 header + GRE header as an example, as shown in Figure 4, the multicast message received by the entry node is as shown in Figure 4 As shown in (a), the multicast message is the first message, including the first message header and payload. The first message header is used to encapsulate and transmit the message in the user network, so it can be recorded As the C-IP header (Header), in the same way, the payload can also be recorded as C-Payload. The entry node deletes the C-IP Header of the first message and encapsulates the second message header. The second message header includes P- IP Header+GRE header, where the second message header is suitable for transmission in the backbone network, and the P-IP Header belongs to the IPv6 header. As shown in Figure 4(b), the second message obtained by the entry node includes P-IP Header, GRE header and C-Payload, and the second message does not include the C-IP Header. After the second message reaches the egress node, as shown in Figure 4(c), the egress node changes the P- Deleting the IP Header and GRE header and encapsulating the C-IP Header is equivalent to the egress node restoring the second message to the first message including the C-IP Header and C-Payload, excluding the P-IP Header and GRE header. In the encapsulation method provided by the embodiment of this application, the entry node deletes the first message header (C-IP Header). When the second message is transmitted in the backbone network, it does not include the first message header, thus reducing the The cost of transmitting the second packet in the backbone network.

Further, since the entry node deletes the C-IP Header, when the second message is transmitted to the exit node, the C-IP Header needs to be encapsulated at the exit node. Therefore, after the entry node deletes the C-IP Header, the encapsulated second message The header should at least include the source address and destination address corresponding to the tunnel information. The destination address can be a multicast address, so that the egress node can obtain the C-IP Header based on the first corresponding relationship established between the tunnel information and the egress node. Multicast source group information, encapsulating C-IP Header. It should be noted that the second message header includes the P-IP Header+GRE belonging to the IPv6 header. Header is applicable to the scenario where an IP multicast tunnel is used between the ingress node and the egress node. The first corresponding relationship established between the ingress node and the egress node can refer to the above example, and refer to Table 3. For example, the ingress node sets the The tunnel information obtained from the information (S1, G2) and the first correspondence is (S-P1, D-P2). The source address corresponding to the second packet header and the tunnel information is S-P1 and the destination address is D-P2. In the same way, after the egress node receives the second message, it can obtain the first message header based on the source address corresponding to the second message header and the tunnel information, which is S-P1, the destination address is D-P2, and the first correspondence. Corresponding multicast source group information (S1, G2).

It should be noted that the first corresponding relationship can be a static configuration of the ingress node and the egress node, or it can be announced by the ingress node to the egress node. For example, the ingress node can notify the egress node by sending a BGP message to the egress node. BGP The message includes a first correspondence relationship, where the BGP message may be BGP-MVPN signaling or BGP-EVPN signaling. In the embodiment of this application, the backbone network is a network running MVPN as an example, and the BGP message is BGP-MVPN signaling. In practical applications, the implementation is not limited to using BGP-MVPN.

In the following, the first header of the first message includes the C-IP Header, and the C-IP Header belongs to the IPv6 header. The second header of the second message includes the P-IP Header+GRE header, and the P-IP Header belongs to IPv6 header is explained. The entry node deletes the C-IP Header of the first message as shown in Figure 4(a). The entry node encapsulates the second message header. The second message header includes the P-IP Header and GRE header. The second message obtained after encapsulation is shown in Figure 4(b), including P-IP Header, GRE header and C-Payload. In the example below, when the entry node encapsulates the second message header, that is, the P-IP Header and the GRE header, a possible example of filling in the content in each field is as follows:

P-IP Header Ver: The version number of IPv6 is 6.

TC of P-IP Header: Copy the TC field in the C-IP Header to the TC field of the P-IP Header, or set the TC value according to the local configuration policy. If the TC value in the local configuration policy is equal to 1, set it to 1. .

FL of P-IP Header: Copy the FL field in the C-IP Header to the FL field of the P-IP Header, or set the FL value according to the local configuration policy.

PL of P-IP Header: It can be obtained based on the PL field value in C-IP Header plus the length of the GRE header.

NH of P-IP Header: indicates the next header field that follows, that is, indicates the GRE header.

HL of P-IP Header: Copy the HL field in the C-IP Header to the HL field of the P-IP Header, or set the HL value according to the local configuration policy.

SA and DA of P-IP Header: Set the SA field and DA field through the SA field and DA field in the C-IP Header and the corresponding relationship. For example, you can obtain multicast through the SA field and DA field in the C-IP Header. Source group information (S1, G2). According to the multicast source group information (S1, G2) and the first corresponding relationship, the tunnel information is (S-P1, D-P2). Fill in the SA field of the P-IP Header with S- P1, fill in the DA field of P-IP Header with D-P2.

Protocol of the GRE header: Convert the Protocol value of the GRE header according to the NH value in the C-IP Header. For example, the NH in the C-IP Header is 4, indicating that the C-Payload is a message with an IPv4 header. The Protocol value can be set to 0x0800 according to the format.

When encapsulating the second header, the settings of each field can be configured statically. The local configuration policy can be that the ingress node configures preset values for different fields. For example, the preset value of the TC field configured in the local configuration policy is equal to 1.

Further, the ingress node may notify the egress node of indication information, and the indication information is used to instruct the restoration of the multicast source group information. For example, the indication information may instruct the egress node to restore the multicast source group information according to the first correspondence relationship and the second message header obtained by the egress node. tunnel information, obtain the multicast source group information, and fill in the contents of the SA field and DA field of the C-IP Header when encapsulating the first message header based on the multicast source group information, which is equivalent to restoring the deletion of the entry node. The first message header of multicast source group information. Further, the ingress node may also notify the egress node of deletion and restoration instruction information. The deletion and restoration instruction information may further instruct the egress node to delete the second message header and obtain the first message according to the fields of the second message header or the local configuration policy. Contents that need to be set for each field in the header, such as instructing the egress node to obtain the value of the NH field in the first header based on the Protocol field of the GRE header, etc.

It should be noted that after receiving the indication information, the egress node can save the indication information, and after receiving the second message, obtain the first message according to the indication information and the second message. Optionally, a relationship can be established between the entry node and the exit node. After the relationship is established, the entry node can notify the exit node to use the same encapsulation method as the entry node to decapsulate the second message. It can also notify the exit node that the entry node The encapsulation method corresponding to the first message header of the received first message is such that the egress node encapsulates the first message according to the encapsulation method corresponding to the first message header. This encapsulation method can be defined as compact. ) encapsulation method, or the encapsulation method called delete-restore.

S104. The entrance node sends the second message through the tunnel corresponding to the tunnel information.

The entrance node can send the second message through the tunnel corresponding to the tunnel information (S-P1, D-P2). If the destination address D-P2 of the IPv6 header in the second message header is the multicast group address corresponding to the multicast tree, Returning to the scenario shown in Figure 2, both egress node 1 and egress node 2 have joined the multicast group corresponding to D-P2, which is equivalent to when egress node 1 and egress node 2 receive the second message. The header is deleted and the first header is encapsulated to obtain the first message.

The destination address of the tunnel information can also be the next hop address of the entry node in the multicast tree. For example, in the scenario shown in Figure 2, the entry node 1000, the intermediate node 2001, the intermediate node 2002, the exit node 1 and the exit For the case of using a BIERv6 multicast tunnel between nodes 3, refer to the example above of using a BIERv6 multicast tunnel between the ingress node and the egress node. If the destination address is the unicast address of the next hop node, The ingress node sends the second message through the tunnel corresponding to the tunnel information. When it reaches the corresponding egress node, the corresponding egress node may receive the third message. The corresponding egress node may receive the second message according to the tunnel information in the third message. Obtain the multicast source group information and encapsulate the first message header; in the second message sent by the ingress node through the tunnel corresponding to the tunnel information, if the second message header corresponds to the tunnel information source address does not include the destination address, the egress node What is received is the second message. The egress node obtains the multicast source group information based on the second correspondence and the tunnel information source address, and encapsulates the first message header.

In the embodiment of this application, both P-IP Header and C-IP Header headers belong to IPv6 headers. The entry node deletes the C-IP Header header in Figure 4(a) and encapsulates the P-IP header as shown in Figure 4(b). Header and GRE header, the effect is equivalent to "replacing" the C-IP Header with the P-IP Header and GRE header, instead of adding the encapsulated P-IP Header and GRE header when the message enters the backbone network, which can reduce The overhead of packet transmission in the backbone network.

Figure 5 is a schematic flowchart of another message transmission method provided by an embodiment of the present application. As shown in Figure 5, the method includes:

S105. The egress node receives a second message, where the second message includes a payload and a second message header corresponding to the tunnel information.

The exit node receives the second message as shown in Figure 4(b). The second message includes C-Payload, P-IP Header and GRE header, but does not include C-IP Header. As shown in Figure 4(c), the exit node deletes the P-IP Header and GRE header of the second message and encapsulates the C-IP Header to obtain the first message including C-IP Header and C-Payload, which is quite The first message is restored at the egress node. The encapsulation method provided by the embodiments of this application can send messages that comply with the standard format to the CE device.

S106. The egress node obtains multicast source group information based on the tunnel information and corresponding relationship corresponding to the second packet header. The corresponding relationship includes tunnel information and multicast source group information.

The corresponding relationship may be a first corresponding relationship, including tunnel information and multicast source group information, and the egress node Based on the tunnel information corresponding to the packet header and the first correspondence, the multicast source group information can be obtained. Returning to the scenario shown in Figure 2, in the scenario where an IP multicast tunnel is used between the entry node 1000, the intermediate node 2001, the intermediate node 2002, the exit node 1 and the exit node 3, for example, the exit node 3 receives the second message, the tunnel information (S-P1, D-P2) obtained according to the second message header, where the destination address included in the second message header is the multicast group address corresponding to the multicast tree, where the multicast tree It includes an ingress node 1000, an egress node 1 and an egress node 3. The egress node 3 can obtain the multicast source group information (S1, G2) based on the tunnel information (S-P1, D-P2) and the first corresponding relationship.

Or, in the scenario where BIERv6 multicast tunnel is used between the entrance node 1000, the intermediate node 2001, the intermediate node 2002, the exit node 1 and the exit node 3, since the entrance node to the intermediate node 2001, the intermediate node 2001 to the intermediate node 2002, the intermediate node The packets sent from node 2002 to egress node 1 and from intermediate node 2002 to egress node 3 all belong to IPv6 headers, and the destination addresses in the IPv6 headers are all unicast addresses. The second purpose of the packets sent from entry node 1000 to intermediate node 2001 is The address belongs to intermediate node 2001. When intermediate node 2001 sends the third message to intermediate node 2002, the destination address of the third message is changed to that of intermediate node 2002. The destination address of the fourth message sent by the intermediate node to exit node 1 is changed to exit node 1. , when the intermediate node 2002 sends the fifth message to the egress node 3, the destination address of the fifth message is changed to that of the egress node 3. However, for egress node 1 and egress node 3, the fourth and fifth messages received are both "BIERv6 tunnel" messages, and the group is determined based on the source address and the second correspondence in the tunnel information of the message. The first message can be obtained by using the multicast source group information. Since the second correspondence is the correspondence between the multicast source group information (S, G) and the source address in the tunnel information, regardless of whether the destination address in the message changes or not, the egress The node can obtain the group source group information (S, G) based on the source address of the tunnel information and the second corresponding relationship, and can encapsulate the first message header accordingly to obtain the first message.

It should be noted that the first correspondence relationship and the second correspondence relationship can be static configurations of the egress node, or they can be saved after obtaining the first correspondence relationship or the second correspondence relationship advertised by the entry node. The egress node can receive the information sent by the entry node. BGP message, the BGP message includes the first corresponding relationship or the BGP message includes the second corresponding relationship. The BGP message is BGP-MVPN signaling or BGP-EVPN signaling.

Further, the egress node receives the indication information advertised by the ingress node, and the indication information is used to instruct to restore the multicast source group information. When the egress node receives the second message, it can restore the multicast source group information according to the instruction information, and set the first message header (C-IP Header in the following example) based on the source address in the multicast source group information. SA field, set the DA field of the first packet header (C-IP Header in the following example) based on the multicast group address in the multicast source group information.

S107. The egress node obtains the first message according to the multicast source group information and payload. The first message includes the first message header and payload. The first message header includes the multicast source group information. The first message does not include the first message. Two message headers.

The following takes the P-IP Header and C-IP Header as both IPv6 headers as an example. The second header of the second message received by the egress node includes the IPv6 header and the GRE header. Delete them as shown in Figure 4(b). The P-IP Header and GRE header are encapsulated into the C-IP Header to obtain the first message as shown in Figure 4(c). The first message includes C-IP Header and C-Payload. In the example below, the exit node When encapsulating the first message header, that is, the C-IP Header, an example of encapsulating each field of the C-IP Header is as follows:

C-IP Header Version: The version number of IPv6 is 6.

TC of C-IP Header: Copy the TC field in the P-IP Header to the TC field of the C-IP Header, or set the TC value according to the local configuration policy. If the ingress node sets the TC value in the P-IP Header according to the local configuration policy, The TC field is set to 1, and the egress node can copy 1. There is no need to restore the TC field content when the first packet entered the backbone network;

FL of C-IP Header: Copy the FL field in the P-IP Header to the FL field of the C-IP Header, or set the FL value according to the local configuration policy.

PL of C-IP Header: It can be obtained by subtracting the length of the GRE header from the PL field value in the P-IP Header.

NH of C-IP Header: indicates the next header field, which needs to be converted according to the Protocol field in the GRE header. For example, the Protocol value of the GRE header is 0x0800, indicating that the C-Payload carries IPv4. Then NH is 4.

HL of C-IP Header: Copy the HL field in the P-IP Header to the HL field of the C-IP Header, or set the HL value according to the local configuration policy.

SA and DA of C-IP Header: Set the SA field and DA field through the SA field and DA field in the P-IP Header and the corresponding relationship. For example, you can obtain the tunnel information through the SA field and DA field in the P-IP Header ( S-P1, D-P2), find the first corresponding relationship to obtain the multicast source group information (S1, G2), fill in the SA field of the C-IP Header with S1, and fill in the DA field of the C-IP Header with G2.

In one example, the settings of each field when encapsulating the first packet header may be statically configured by the egress node, and the local configuration policy for setting the fields may also be preset in advance. In another example, the egress node fills in the corresponding field of the multicast source group information in the first message header during encapsulation according to the instruction information sent by the ingress node, or the egress node fills in the corresponding field of the multicast source group information in the first message header according to the deletion and restoration instruction information sent by the ingress node. Indicates how the fields in the first packet header are set according to the fields in the second packet header or the local configuration policy. In another example, the local configuration policy for setting fields is preset in advance, and the egress node receives the instruction information and can set the corresponding fields according to the correspondence indicated by the instruction information and other configured information. Further, after receiving the indication information, the egress node can save it first, and when receiving the second message, obtain the first message according to the instruction of the indication information. For example, if the egress node receives indication information through BGP-MVPN signaling, the indication information may be the first corresponding relationship or the second corresponding relationship. The egress node can also restore the second message to the first message through preset configuration. The embodiments of this application are only illustrative and not limiting.

The egress node provided by the embodiment of this application can obtain the first message based on the received second message, and then send the first message to the CE device, which can ensure that the message sent to the user network is consistent with the message received by the backbone network entry node. The message format is consistent. In this way, the format of the message received by the user network is standardized and does not affect the message analyzer on the network link to parse the message, thereby ensuring the maintainability of the message transmission solution (such as facilitating Locating packet errors) will not affect the deployment and application of the packet transmission solution.

In some examples, the backbone network uses the tunnel type established by PIM-SSM signaling as the MVPN tunnel bearer. The packet encapsulation format can refer to the encapsulation format of RFC6513 12.1.1. Figure 6 is provided by the embodiment of this application. Another schematic diagram of the encapsulation and decapsulation message structure is shown in Figure 6. The message received by the entry node is in the format shown in Figure 6(a). The first message includes the first message header (C-IP Header) and C-Payload, C-IP Header belongs to the IPv6 header. The entry node deletes the C-IP Header of the received first message and encapsulates the second message header, as shown in Figure 6(b). The second message includes C-Payload, P-IP Header and GRE header, and , the second message does not include the C-IP Header. P-IP Header belongs to IPv4 header. After the second message reaches the egress node, the egress node deletes the P-IP Header and GRE header of the second message, encapsulates the C-IP Header, and obtains the first message as shown in Figure 6(c). The first message Including C-IP Header and C-Payload.

The following description takes the first packet header (C-IP Header) as an IPv6 header, the second packet header as a P-IP Header and a GRE header, and the P-IP Header as an IPv4 header. The entry node receives the Delete C-IP after one message Header, the entrance node determines that the second message header includes an IPv4 header and a GRE header, where the IPv4 header includes the source address and destination address corresponding to the tunnel information. The source address and destination address corresponding to the tunnel information can be based on the C-IP Header. The multicast source group information and the first corresponding relationship are determined. The first corresponding relationship can refer to the above embodiment and will not be repeated here. The entrance node encapsulates the IPv4 header and the GRE header to obtain the second message, as shown in Figure 5(b) As shown, the second message includes C-Payload, P-IP Header and GRE header. In the following field examples, the first message header is recorded as C-IP Header, and the IPv4 header of the second message header is recorded as P-IP Header, an example of each field when encapsulating P-IP Header and GRE header is as follows:

Ver of P-IP Header: IPv4 version number is 4;

IHL of P-IP Header: can be set to 5 according to the requirements of IPv4 header;

TOS of P-IP Header: Copy the TC field (8bit) in the C-IP Header to the TOS field (8bit) of the P-IP Header, or set the TOS value according to the local configuration policy;

Total Length of P-IP Header: It can be obtained according to the Payload Length field value in C-IP Header, plus the length of the GRE header and the length of the IPv4 header;

P-IP Header's Identifier: Set according to the requirements of the IPv4 header, and set to 0 considering non-fragmentation;

Flags of P-IP Header: Set according to the requirements of the IPv4 header, and set to 010 (binary) considering the situation of non-fragmentation;

P-IP Header's FO: Set according to the requirements of the IPv4 header, and set to 0 considering the case of no fragmentation;

TTL of P-IP Header: Copy the HL field (8bit) in C-IP to the TTL field (8bit) of P-IP, or set the TTL value according to the local configuration policy;

Protocol of P-IP Header: Set according to the Next Header value in C-IP. For example, the Next Header in C-IP Header is 17, indicating that the C-Payload is a payload with a UDP header, and the P-IP header is Protocol value is set to 17;

Header Checksum of P-IP Header: This field is set based on the checksum calculated from the IPv4 header, or is set to 0;

SA and DA of P-IP Header: Set the SA field and DA field through the SA field and DA field in the C-IP Header and the corresponding relationship. You can refer to the above example.

GRE header Protocol: Convert the GRE header Protocol value based on the NH value in C-IP.

When encapsulating the second packet header, the settings of each field can be configured statically, and the local configuration policy can also be preset in advance. The values exemplified here are examples. The specific field settings can be adjusted according to the needs of the actual usage scenario, except Values other than the version number are not limited to this.

In this embodiment, the P-IP Header belongs to the IPv4 header and the C-IP Header belongs to the IPv6 header. Therefore, the entry node deletes the C-IP Header and then encapsulates the P-IP Header and GRE header, as shown in Figure 6(b), which is equivalent to The C-IP Header is "replaced" with the P-IP Header. After the transmission reaches the egress node in the backbone network, the egress node deletes the P-IP Header and GRE header to restore the C-IP Header. The egress node can pass the aforementioned MVPN The signaling transfers the corresponding relationship and indication information. The indication information is used to instruct the restoration of the multicast source group information. Encapsulation and decapsulation in the backbone network are completed by the ingress node and egress node, thereby reducing the time required for message transmission in the backbone network. overhead. It should be noted that the first correspondence relationship can be a static configuration of the egress node, or it can be pre-stored after obtaining the first correspondence relationship advertised by the ingress node. The multicast source group information is obtained through the first correspondence relationship and the tunnel information, and the third correspondence relationship is set. The method of a message header can be configured by the egress node or saved after receiving the indication information.

In the field examples below, the first packet header is recorded as C-IP Header, and the egress node deletes the P-IP Header and GRE header. An example of each field when encapsulating the C-IP Header is as follows:

C-IP Header Version: IPv6 version number is 6;

TC of C-IP Header: Copy the TOS field in the P-IP Header to the TC field of the C-IP Header, or set the TC value according to the local configuration policy;

C-IP Header's FL: Set the FL value according to the local configuration policy;

PL of C-IP Header: It can be obtained by subtracting the length of the GRE header from the PL field value in the P-IP Header and then subtracting the length of the IPv4 header;

NH of C-IP Header: Copy the Protocol field (8bit) in the P-IP Header to the Next Header field (8bit) of the C-IP Header;

HL of C-IP Header: Copy the TTL field in the P-IP Header to the HL field of the C-IP Header, or set the HL value according to the local configuration policy;

SA and DA of C-IP Header: Set the SA field and DA field through the SA field and DA field in the P-IP Header and the corresponding relationship. The method is as shown in the above example and will not be repeated here.

The values of each field when encapsulating the first message header can be statically configured by the egress node, and the local configuration policy used to set the fields can also be preset in advance. When encapsulating the first message header, each field may also be determined by the egress node based on the instruction information sent by the ingress node or the instruction to delete and restore the instruction information.

Further, the IPv4 header includes the source address and destination address corresponding to the tunnel information. In addition to the DA field listed in the above example, which is the multicast group address corresponding to the multicast tree, the DA field can also be the entry node next to the multicast tree. Jump address.

In the above example, the first packet header (C-IP Header) belongs to the IPv6 header, and the P-IP Header in the second packet header belongs to the IPv6 header and IPv4 header respectively. The first packet header (C-IP Header) belongs to If the IPv4 header and the P-IP Header in the second header belong to the IPv6 header or the IPv4 header, you can refer to the above example and by analogy to obtain the values of each field in the second header and the fields when restoring the first header. The value of will not be described in detail. Similarly, the embodiments of this application provide all examples, taking the first packet header (C-IP Header) as an example of an IPv6 header. The first packet header (C-IP Header) belongs to the IPv6 header. The situation that IP Header) belongs to the IPv4 header can be deduced based on the examples provided in this application. It will not be repeated in the embodiments of this application. However, the situation that the first message header (C-IP Header) belongs to the IPv4 header is also within the protection scope of this application. Inside.

In some examples, the encapsulation of backbone network packets can refer to the encapsulation method of RFC6513 12.1.3. In the following, the first packet header (C-IP Header) belongs to the IPv6 header, and the second packet header is the MPLS header. Note: As a P-MPLS header, the MPLS header may include three layers of labels. The embodiment of this application takes the MPLS header including one layer of labels as an example for explanation. Furthermore, the C-Payload may include one layer of IPv4 header or IPv6 header. Figure 7 is a schematic structural diagram of another encapsulation and decapsulation message provided by the embodiment of the present application. Returning to the scenario of Figure 2, take the first message header IPv6 header of the first message sent by CE device 1 to the entrance node, As an example, the C-Payload includes the IPv6 header. The entry node receives the first message as shown in Figure 7(a), deletes the C-IP Header of the first message, and then performs MPLS encapsulation, that is, encapsulates the second message. header (P-MPLS header), and obtain the second message as shown in Figure 7(b). The second message includes the P-MPLS header and C-Payload. After receiving the second message, the egress node deletes the P- MPLS header, encapsulate the C-IP Header to obtain the first message as shown in Figure 7(c).

The entry node performs MPLS encapsulation. This embodiment of the present application performs MPLS encapsulation. Table 4 shows the fields included in the MPLS header.

Table 4

As shown in Table 4, the MPLS header includes the following parts:

Label value Label: used to set the label number, Label occupies 20 bits;

Experimental bit Exp: can be used to represent service quality, Exp occupies 3 bits (bit);

The bottom bit S of the stack is used to indicate whether the current label is at the bottom of the stack. By setting different values at the bottom bit of the stack, multiple labels can be included in the same packet to form a label stack. For example, an IPv6 packet can be determined to have a label with S = 0. To stack data packets, MPLS can encapsulate labels up to three times in the data packet, and S occupies 1 bit;

Time to live TTL: The TTL field or Hop Limit field value in the C-IP Header is copied to the TTL field in the label stack. TTL occupies 8 bits.

The second header corresponding to the tunnel information is an MPLS header. The MPLS header can refer to the format of Table 4. The MPLS header includes the MPLS label corresponding to the multicast tree or the MPLS header includes the next hop node of the entry node in the multicast tree. MPLS label, for example, indicates the next hop node or multicast tree of the entry node in the multicast tree through the label value. Since the tunnel is established based on the protocol through hop-by-hop nodes, back to the scenario in Figure 2, assume that the tunnel is the entrance node 1000, its next-hop intermediate node 2001, the next-hop node 2002 of the intermediate node 2001, and the intermediate node The next hop egress node 1 of 2002 was established and supported the establishment of the RFC6513 protocol. When the RFC6513 protocol was established, the backbone network used the same control plane tunnel identifier, but each node would assign a different data plane identifier based on the tunnel identifier. Among them, the control plane is used to control and manage the operation of all network protocols, and the data plane is used for data processing and data forwarding. Therefore, the MPLS labels of each hop in the backbone network are different. The entry node establishes the third corresponding relationship with reference to the method in the above embodiment. For example, when the label value in the MPLS header indicates that the entry node is the next hop node of the multicast tree, the entry node 1000 can allocate the label 10001 to the next hop node, that is, the intermediate node 2001; , the entry node can allocate labels of 10001 to all nodes in the multicast tree corresponding to (S1, G1) in the MPLS label distribution tree for the multicast source group information (S1, G1).

It should be noted that the multicast source group information obtained by the entry node can be obtained from the C-IP Header to be deleted or from the IPv6 header contained in the C-Payload. Preferably, the group information obtained by the entry node The source group information obtains the multicast source group information from the C-IP Header.

In the field setting examples below, the first packet header is recorded as C-IP Header, and the second packet header (MPLS header) is recorded as P-MPLS header. This is a type of setting of each field when encapsulating the P-MPLS header. Examples are as follows:

Label of P-MPLS header: According to the SA field and DA field in the C-IP Header and the third corresponding relationship, the corresponding MPLS label is obtained and the MPLS label field is set, such as setting 10001;

Exp of the P-MPLS header: Set a value according to the requirements of the P-MPLS header to represent the quality of service;

S in the P-MPLS header: includes a layer of labels based on the P-MPLS header, set to 1;

TTL of P-MPLS header: Copy the HL field (8 bits) in C-IP to the TTL field (8 bits) of P-IP, or set the TTL value according to the local configuration policy.

When encapsulating P-MPLS, the settings of each field can be configured statically, and the local configuration policy can also be preset in advance. The setting values exemplified here are examples. The specific field setting values can be adjusted according to the needs of the actual usage scenario. The numerical value required in the above example is limited.

In this embodiment, the C-IP Header belongs to the IPv6 header, so the entry node deletes the C-IP Header and then encapsulates P-MPLS. The effect of the header is equivalent to "replacing" the C-IP Header with the MPLS header. In the backbone network, after the second packet is transmitted and reaches the egress node, the egress node then replaces the P-IP header as shown in Figure 7(b). The MPLS header is deleted, and the C-IP Header shown in Figure 7(c) is encapsulated to obtain the first message. The egress node can receive the instruction information transmitted by the ingress node through BGP-MVPN signaling or BGP-EVPN to obtain the fourth correspondence relationship and restore the multicast source group information. After the egress node obtains the fourth correspondence relationship advertised by the ingress node, it can obtain the fourth correspondence relationship according to the egress node The established sixth corresponding relationship and the received fourth corresponding relationship are obtained and saved. The entry node establishing the third corresponding relationship and the exit node establishing the seventh corresponding relationship can refer to the above example, which will not be described again here. The egress node can also pre-store the indication information, store it after receiving the indication information, and when receiving the second message, obtain the first message header according to the restored multicast source group information indicated by the indication information and the seventh corresponding relationship. Encapsulation and decapsulation in the backbone network are completed by the ingress node and egress node, thereby reducing the overhead of packet transmission in the backbone network.

In the following field setting examples, the second packet header is recorded as the P-MPLS header, and the first message header is recorded as the C-IP Header. An example of the setting of each field when encapsulating the C-IP Header is as follows:

C-IP Header Version: IPv6 version number is 6;

C-IP Header's TC: Set the TC value according to the local configuration policy;

C-IP Header's FL: Set the FL value according to the local configuration policy;

C-IP Header's PL: It can be set according to the IPv4 or IPv6 header in C-Payload. For example, the encapsulation header included in C-Payload belongs to the IPv6 header, and it can be set through the Payload Length field of the IPv6 header in C-Payload. Add the IPv6 header length 40 to get the Payload Length field as the C-IP header. Similarly, if the encapsulation header included in the C-Payload belongs to the IPv4 header, you can add the Payload Length field of the IPv4 header in the C-Payload. The IPv4 header length is obtained as the Payload Length field of the C-IP header;

C-IP Header's NH: needs to be set according to the IPv4 header or IPv6 header in C-Payload. For example, the encapsulation header included in C-Payload belongs to the IPv6 header, then the Next Header field is set to 41. Similarly, if the encapsulation header included in C-Payload If the included encapsulation header belongs to the IPv4 header, the Next Header field is set to 4;

C-IP Header's HL: Set the HL value according to the local configuration policy;

SA and DA of C-IP Header: Set the SA field and DA field through the MPLS label value and the seventh corresponding relationship. For example, the multicast source group information (S1, G2) can be obtained from the third corresponding relationship through the MPLS label value of 10001. ), set the SA field and DA field accordingly.

Figure 8 is a schematic structural diagram of another encapsulation and decapsulation message provided by the embodiment of the present application. In some examples, the encapsulation format of the backbone network message can refer to the encapsulation method of draft-xie-bier-ipv6-encapsulation-09. As shown in Figure 8, the message received by the entry node is as shown in Figure 8(a). The first message includes C-IP Header and C-Payload. The entry node deletes the C- of the first message received. IP Header, encapsulates P-IP Header and extension header to obtain the second message header, as shown in Figure 8(b). The second message includes P-IP Header, extension header and C-Payload, and, the second message The message does not include the C-IP Header. After the second message reaches the egress node, the egress node deletes the P-IP Header and extension header of the second message and encapsulates the C-IP Header to obtain the first message, as shown in Figure 8 ( As shown in c), the first message includes C-IP Header and C-Payload.

The entry node encapsulates P-IP Header and extension header. The currently defined and used IPv6 extension headers include Hop-by-hop Options Header, DOH, Routing Header, and Fragment Header. ), authentication header (Authentication Header) and Encapsulated Security Payload Header (ESP). In the embodiment of this application, the extension header is DOH as an example for explanation. DOH carries optional information specific to the destination address of the data packet. In this example, DOH carries the optional information of the destination address through the BIER option of stateless forwarding or BitString. In the scenario shown in Figure 2, there are 4 edge BFRs, and each edge BFR needs to be configured with a unique value of 1 to 256. Among them, there are 3 BFERs. These 3 destination node sets can be represented by setting a 256-bit or 32-byte BitString. Each bit in the BitString is used to identify a BFER, such as the exit node in Figure 2. The BFR-ID of 1=1, the BFR-ID of egress node 2=2, and the BFR-ID of egress node 3=3. Among them, BFR-ID=1 can be identified by using the rightmost bit as 1 in BitString. BFR-ID=2 can be identified by using the second bit from right to left as 1 in BitString. BFR-ID=3 can be identified by using the third bit from right to left as 1 in BitString. In the embodiment of this application, the target address can be set in the DA field of the IPv6 header. In some packets that are not encapsulated with the target address, the BFER identified by different bits in the BitString can also be used to indicate that the packet is to leave the backbone network and be sent to The CE device is the corresponding egress node.

Take the C-IP Header as an IPv6 header, the P-IP Header as an IPv6 header, the extension header is DOH, and DOH contains the BIER option or BitString for stateless forwarding as an example. In the field setting examples below, the first header is recorded as C-IP Header, and the second header includes P-IP Header and DOH. An example of setting each field when encapsulating P-IP Header and DOH is as follows :

P-IP Header's Ver: The version number of IPv6 is 6;

TC of P-IP Header: Copy the TC field in the C-IP Header to the TC field of the P-IP Header, or set the TC value according to the local configuration policy. If the TC value in the local configuration policy is equal to 1, set it to 1. ;

FL of P-IP Header: Copy the FL field in the C-IP Header to the FL field of the P-IP Header, or set the FL value according to the local configuration policy;

P-IP Header's PL: The setting of the Payload Length field can be obtained based on the Payload Length field value in the C-IP Header plus the length of the DOH;

NH of P-IP Header: indicates the next header field that follows, in this case, indicates DOH;

HL of P-IP Header: Copy the HL field in the C-IP Header to the HL field of the P-IP Header, or set the HL value according to the local configuration policy;

SA and DA of P-IP Header: Set the SA field and DA field through the SA field and DA field in the C-IP Header and the corresponding relationship. For example, you can obtain multicast through the SA field and DA field in the C-IP Header. Source group information (S1, G2), according to the first corresponding relationship, the tunnel information is (S-P1, D-P2), fill in the SA field with S-P1, and fill in the DA field with D-P2;

DOH: Contains BIER options or BitString for stateless forwarding.

It should be noted that the above field settings are based on DOH as an example. Among other types of extension headers included in the P-IP Header belonging to the IPv6 header, if it is necessary to set the Next Header field, copy the Next Header field in the C-IP Header. into it. For the settings of each field in other types of extension headers included in the P-IP Header belonging to the IPv6 header, refer to draft-xie-bier-ipv6-encapsulation, which will not be described in detail here.

Further, the second message header obtained by the egress node includes an IPv6 header and an IPv6 extension header. The IPv6 header includes a source address and a destination address corresponding to the tunnel information, where the destination address is the next hop of the ingress node in the multicast tree. The address or destination address is the multicast group address corresponding to the multicast tree.

The second header of the second message received by the egress node includes P-IP Header and DOH. Delete the P-IP Header and DOH as shown in Figure 8(b), and encapsulate the C-IP Header to obtain Figure 8 For the first message shown in (c), in the field setting example below, the first message header is recorded as C-IP Header, and the P-IP Header included in the second message header belongs to the IPv6 header, encapsulating C-IP An example of setting each field of the Header is as follows:

C-IP Header Version: IPv6 version number is 6;

TC of C-IP Header: Copy the TC field in the P-IP Header to the TC field of the C-IP Header, or set the TC value according to the local configuration policy. If the ingress node sets the TC value in the P-IP Header according to the local configuration policy, Set the TC field to 1 and copy 1 to the egress node. There is no need to restore the TC field content when the first packet entered the backbone network;

FL of C-IP Header: Copy the FL field in the P-IP Header to the FL field of the C-IP Header, or set the FL value according to the local configuration policy;

PL of C-IP Header: It can be obtained by subtracting the length of DOH from the PL field value in P-IP Header;

NH of C-IP Header: indicates the next header field that follows. If the encapsulation header contained in C-Payload belongs to the IPv6 header, NH is 41;

HL of C-IP Header: Copy the HL field in the P-IP Header to the HL field of the C-IP Header, or set the HL value according to the local configuration policy;

SA and DA of C-IP Header: Set the SA field and DA field through the SA field and DA field in the P-IP Header and the corresponding relationship. For example, you can obtain the tunnel information through the SA field and DA field in the P-IP Header. Yes (S-P1, D-P2) obtains the multicast source group information (S1, G2) based on the first corresponding relationship, fills in the SA field of the C-IP Header with S1, and fills in the DA field of the C-IP Header with G2.

In one example, when encapsulating the first message header, the settings of each field may be statically configured by the egress node, and the local configuration policy used to set the fields may also be preset in advance. In another example, the egress node fills in the corresponding field of the multicast source group information in the first message header during encapsulation according to the instruction information sent by the ingress node, or the egress node fills in the corresponding field of the multicast source group information in the first message header according to the deletion and restoration instruction information sent by the ingress node. Indicates how the fields in the first packet header are set based on the fields in the second packet header or the local configuration policy. In another example, the local configuration policy for setting fields is preset in advance, and the instruction information received by the egress node can set the corresponding fields according to the corresponding relationship indicated by the instruction information and other configured information. Further, after receiving the indication information, the egress node can save it first, and when receiving the second message, restore the first message according to the instruction of the indication information. For example, if the egress node receives indication information through BGP-MVPN signaling, the indication information may indicate the first corresponding relationship. The egress node can also restore the second message to the first message through preset configuration. The embodiments of this application are only illustrative and not limiting.

Further, the embodiment of this application provides an example of static configuration indication information that can be applied to various encapsulation formats mentioned above. The entry node can dynamically forward all multicast traffic under the same virtual routing (Virtual Routing Forwarding, VRF). That is, corresponding tunnel information is allocated to the multicast source group information (S, G). Optionally, when configuring the entry node, the VRF to which the multicast traffic belongs can also be indicated in the corresponding relationship, such as an identifier that can be used. For example, the identifier is VRF1. The VRF to which the multicast traffic belongs can be identified by the name of the VRF and the integer corresponding to the ID number of the VRF. It should be noted that during the message sending process, the VRF identifier should meet the requirements of the message transmission protocol to ensure The VRF identifier may be a routing table (route-target) identifier, which can be defined with reference to RFC4364. The VRF identifier is recorded as VRF1. Figure 9 is a configuration method provided by an embodiment of the present application. As shown in Figure 9, the method includes:

S201. The entry node configures the VRF and establishes a corresponding relationship.

Its specific configuration is as follows:

That is, the entry node enables the SA field and DA field of the C-IP Header in Figure 8(a) to pop up, and dynamically allocates addresses from the address range of the local owner (locator a1) to correspond to each multicast traffic, for example, The corresponding relationship obtained by the entry node can be (2001:A:1:1::1001, VRF1, S1v6, G1v6), where the IPv6 address of the P-IP Header in Figure 8(b) = 2001:A:1:1: :1001, that is, the tunnel information in the second header is 2001:A:1:1::1001, VRF1 can be a routing table object defined according to RFC4364, and the source address in the multicast source group information of the C-IP Header is S1v6, that is, the SA field in the first packet header is S1v6, and the destination address in the multicast source group information of the C-IP Header, that is, the multicast address is G1v6, that is, the DA field in the first packet header is G1v6.

S202. The entry node notifies the exit node of the corresponding relationship.

Taking the ingress node as node A and the egress node as node D as an example, node A and node D can establish a BGP neighbor relationship with each other. Node A can send BGP messages to the egress node. The BGP messages include corresponding relationships. For example, node A can send BGP-MVPN's S-PMSI A-D routing message. The S-PMSI A-D routing message contains (VRF identification, C-IP Header's SA field, C-IP Header's DA field, P-IP Header's IPv6 address), where, The SA field of the C-IP Header is the source address S1v6 in the multicast source group information, the DA field of the C-IP Header is the destination address G1v6 in the multicast source group information, and the IPv6 address of the P-IP Header is the address 2001 of the tunnel information: A:1:1::1001. The A node may also carry deletion and restoration indication information in the S-PMSI A-D routing message, and the deletion and restoration indication information may be used to instruct the D node to restore the first message header. A node can carry this indication information through BGP attribute value type length (Type length value, TLV).

S203. The egress node establishes the corresponding relationship between the multicast source group information and the tunnel information according to the advertisement.

For example, the entry node is node A and the exit node is node D. Node D receives the above message and establishes the corresponding relationship between the SA field and DA field of C-IP and P-IP. For example, the D node is configured with the VRF1 identifier. VRF1 is the identifier of the local VRF1, which can be the name of VRF1, or the integer value of the ID number of VRF1. The D node determines the corresponding message based on the VRF identifier in the message and its own configured VRF identifier. Which VRF, because the VRF identification of the D node is VRF1, which is the same as the VRF identification in the message, the D node can determine the VRF according to the (VRF identification, C-IP Header's SA, C-IP Header's DA, P-IP Header's IPv6 address), determine the following correspondence under VRF1: (2001:A:1:1::1001, VRF1, S1v6, G1v6), and node D saves this correspondence.

S204. The entry node receives the first message, encapsulates the message according to the corresponding relationship, and obtains the second message.

For example, when the entrance node receives the first message sent by CE device 1 in Figure 2, the IPv6 header multicast message is received. According to the corresponding relationship between the multicast source group information and the entrance node, that is, (VRF identification, C-IP Header SA field, C-IP Header's DA field, P-IP Header's IPv6 address) are encapsulated to obtain the second message. For example, in the first header of the IPv6 multicast message, SA=S1v6, DA=G1v6, according to the corresponding relationship, you can set the IPv6 address of the P-IP Header to 2001:A:1:1::1001 in the tunnel information of the second header, encapsulate the second header and delete the first header to get the Two messages.

S205. The egress node receives the second message, deletes the second message header, encapsulates the first message header, and obtains the first message.

The egress node receives the second message. The second message may be an encapsulation format in various examples provided by the embodiments of this application. For the message in the format, if the tunnel information of the second message is set to 2001:A:1:1::1001, based on the pre-stored (VRF identification, C-IP Header's SA field, C-IP Header's DA field, the corresponding value of the P-IP Header's IPv6 address), such as (S1v6, G1v6, 2001:A:1:1::1001), you can get the multicast source group information (S1v6, G1v6), that is, the multicast source group information The source address is S1v6, the multicast address of the multicast source group information is G1v6, set the corresponding field in the first packet header, obtain the first packet, and forward it to the CE device. The content of other fields in the first message can be set according to the local configuration policy, or can be set according to the method indicated by the deletion and restoration instruction information, which is not limited in this application.

Figure 10 is a schematic structural diagram of another encapsulation and decapsulation message provided by the embodiment of the present application. In the embodiment of the present application, there can be multiple types of BIER encapsulation. In one example, the BIER message can be encapsulated through MPLS. This kind of encapsulation can be called BIER-MPLS encapsulation. In another example, the BIER message can be encapsulated through IPv6, and this encapsulation can be called BIERv6 encapsulation. This application takes BIER-MPLS encapsulation as an example. The entry node deletes the first message header and encapsulates the BIER header and the upstream label. The upstream label is the upstream MPLS label. In the backbone network, the entry node is the upstream node. The upstream label (upstream MPLS label) is the label of the ingress node. The upstream MPLS label and upstream MPLS label encapsulation format can refer to the BIER-MPLS MVPN encapsulation method using RFC8296 and RFC8556. BIER is suitable for MPLS networks. As shown in Figure 10, the message received by the entry node is in the format shown in Figure 10(a). The first message includes the first message header (C-IP Header) and C-Payload. C-IP Header Belonging to the IPv6 header, the entry node deletes the C-IP Header of the received first message, and encapsulates the P-BIER Header and upstream label to obtain the second message. The second message is shown in Figure 10(b), including C -Payload, P-BIER Header and upstream label, and the second message does not include the C-IP Header. Taking the upstream label as the upstream MPLS label as an example, after the second message reaches the egress node, the egress node will The P-BIER Header and upstream label are deleted, and the C-IP Header is encapsulated to obtain the first message as shown in Figure 10(c). The first message includes C-IP Header and C-Payload.

The entry node encapsulates BIER Header. Table 5 shows the fields of the BIER Header encapsulated by the entry node:

table 5

As shown in Table 5, BIER Header includes the following parts:

Bit Index Forwarding Table identification (BIFT-ID): used for bit index forwarding. The egress node can determine which SD the message belongs to, the BSL used and the method for forwarding the message based on the BIFT ID in the BIER Header. A collection of node or configured BFR IDs. BIFT-ID can correspond to a combination of sub-domain (Sub-Domain, SD), bit string length (Bit String Length, BSL) and set identifier (Set Identifier, SI). Different BIFT IDs can correspond to different SD, BSL and SI combinations;

BSL: is the length of the bit string included in the BIER Header;

Proto: You can set 2 to indicate that the BIER Header is followed by the "upstream MPLS label", you can set 4 to indicate that the packets sent by the CE device behind the BIER Header are IPv4 packets, or you can set 6 to indicate that the packets sent by the CE device behind the BIER Header are IPv4 packets. The message is an IPv4 message;

Bit string BitString: used to identify the multicast service BFER set, so that the egress node determines whether the received second message is a message sent to the node based on the BitString field;

In addition to the above fields, the BIER header can also include Ver, Differentiated Services Code Point (DSCP), TTL, Entropy, Operation Administration and Maintenance (OAM), TC, stack (S) The fields are not described in detail here. The fields in Table 5 are only examples and are not limited.

The second header corresponding to the tunnel information includes a BIER header and an upstream label, such as an upstream MPLS label. The BIER header includes the identity of the egress node corresponding to the tunnel information. The upstream MPLS label is used to identify the multicast source group information. The BIER header refers to The format of Table 5, the upstream MPLS label refers to the MPLS header format of Table 4.

For example, the upstream MPLS label can be used to identify the multicast source group information, and then determine the VPN to which the corresponding CE device belongs based on the multicast source group information. The upstream MPLS label can be used to identify the multicast source group. For information, please refer to the example of the MPLS label, which will not be described again here.

The entry node can set the assigned label value in the Label field of the encapsulated upstream MPLS label. The field settings of the upstream MPLS label refer to the settings of each field in the MPLS header encapsulation in the above example, which will not be described again here. The BIER header includes the identification of the exit node corresponding to the tunnel information. The ID of the exit node can be set correspondingly in BitString at the entry node. As shown in Figure 2, the exit node IDs are ID=1, ID=2 and ID=3 respectively. . The settings of other fields in the BIER header can refer to the requirements of RFC8296 and RFC8556, and are set according to the C-IP Header field in the first received message, or according to the local configuration policy settings, which will not be expanded.

The egress node receives the second message, deletes the encapsulated BIER header and upstream MPLS label, restores the first message header, and obtains the first message. The second message header includes the P-BIER Header and the upstream MPLS label. The first message The header is recorded as C-IP Header. An example of setting each field when encapsulating C-IP Header is as follows:

C-IP Header Version: IPv6 version number is 6;

C-IP Header's TC: Set the TC value according to the local configuration policy;

C-IP Header's FL: Set the FL value according to the local configuration policy;

C-IP Header's PL: It can be set according to whether the encapsulation header contained in C-Payload belongs to IPv4 header or IPv6 header. For example, if the encapsulation header contained in C-Payload belongs to IPv6 header, it can be added through the Payload Length field of IPv6 header. The IPv6 header length 40 is used to obtain the Payload Length field of the C-IP header. Similarly, if the encapsulation header contained in the C-Payload belongs to the IPv4 header, the Payload Length field of the IPv4 header plus the IPv4 header length can be used to obtain the C-IP header. -Payload Length field of IP header;

C-IP Header's NH: needs to be set according to the IPv4 header or IPv6 header in C-Payload. For example, the encapsulation header contained in C-Payload belongs to the IPv6 header, then the Next Header field is set to 41. Similarly, if the C-Payload If the included encapsulation header belongs to the IPv4 header, the Next Header field is set to 4;

C-IP Header's HL: Set the HL value according to the local configuration policy;

SA and DA of C-IP Header: Set the SA field and DA field through the Label field and the corresponding relationship. For example, you can obtain the multicast source group information (S1, G2) from the corresponding relationship through 10001 in the Label field. The obtained The source address of the multicast source group information corresponds to the SA field, and the destination address corresponds to the DA field.

It should be noted that this encapsulation format does not limit the C-Payload content in the first message. The C-Payload received by the entry node can be a payload with a User Datagram Protocol (UDP) header. It can also be a complete packet containing an IPv4 or IPv6 header, and the format of the C-Payload after the upstream MPLS label will not affect the forwarding process of the packet.

In the embodiment of this application, the first message header (C-IP Header) belongs to the IPv6 header, and the second message header is the P-BIER Header and the upstream label. The entry node deletes the C-IP Header header and encapsulates the P-BIER Header and upstream label, the effect is equivalent to "replacing" the C-IP Header with the P-BIER Header and upstream label. The egress node then deletes the P-BIER Header and the upstream label, and encapsulates the C-IP Header. In the embodiment of this application, the upstream label is an upstream MPLS label as an example. The effect is equivalent to the egress node recovering the first packet and entering it into the backbone. The first message of the network has the same format as the first message after leaving the backbone network, and the transmission overhead in the backbone network can be reduced.

Embodiments of the present application provide a network device. The network device is installed at an entry node and can be used to implement the corresponding functions of the entry node in the above method. Figure 11 is a schematic structural diagram of a network device 10 provided by an embodiment of the present application. The network device It can be used to perform methods S101 to S104 or S201 to S205 in the above embodiments. When the network device is used to perform methods S101 to S104 or methods S201 to S205 in the above embodiments, it is equivalent to the examples in this method. entry node. The network device 10 includes: a receiving module 101, a processing module 102 and a sending module 103:

The receiving module 101 is configured to receive a first message sent by the user edge device. The first message includes a first message header and a payload, and the first message header includes multicast source group information.

The processing module 102 is configured to obtain tunnel information according to multicast source group information and corresponding relationships, where the corresponding relationships include multicast source group information and tunnel information.

The processing module 102 is also configured to obtain a second message according to the payload and the tunnel information. The second message includes the payload and the second message header corresponding to the tunnel information. The second message does not include the first message header.

The sending module 103 is configured to send the second message through the tunnel corresponding to the tunnel information.

In a possible manner, the second packet header corresponding to the tunnel information includes an IPv6 header and a GRE header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible manner, the second packet header corresponding to the tunnel information includes an IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information.

In a possible manner, the second message header corresponding to the tunnel information includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In a possible manner, the second packet header corresponding to the tunnel information includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.

In one possible way, the destination address is the next hop address of the entry node in the multicast tree or the destination address is the multicast group address corresponding to the multicast tree.

In one possible way, the second message header corresponding to the tunnel information is a multi-protocol label switching MPLS header. The MPLS header includes the MPLS label of the next hop node of the entry node in the multicast tree or the MPLS corresponding to the multicast tree. Label.

In one possible way, the second message header corresponding to the tunnel information includes a bit index explicit copy BIER header and a label. The BIER header includes the identity of the egress node corresponding to the tunnel information. The label is used to identify the multicast source group. information.

In one possible way, the sending module 103 is also used to notify the egress node of the corresponding relationship.

For example, the sending module 103 is also configured to notify the egress node of indication information, where the indication information is used to instruct the restoration of the multicast source group information.

Further, the sending module 103 is specifically configured to send a BGP message to the egress node, where the BGP message includes the corresponding relationship.

In a possible manner, the BGP message is BGP-MVPN signaling or BGP-EVPN signaling.

When the network device 10 is used to perform the above method, it can be applied to the application scenarios shown in Figures 2 to 11, for example, it can be the entry node 1000 in the scenario shown in Figure 2. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. Each functional module in the embodiment of the present application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. For example, in the above embodiment, the sending module, receiving module and processing module may be the same module or different modules. The above integrated modules can be implemented in the form of hardware, such as chips, or in the form of software function modules.

In addition, the embodiment of the present application also provides a network device. The network device is installed at the egress node. The network device can be used to execute the methods S105 to S107 in the above embodiment, or perform S201 to S205. Figure 12 is an embodiment of the present application. A schematic structural diagram of a network device 20 is provided. When the network device is used to execute methods S105 to S107 or methods S201 to S205 in the above embodiment, it is equivalent to the egress node exemplified in the method. The network device 20 includes: a receiving module 201 and a processing module 202.

The receiving module 201 is configured to receive a second message, where the second message includes a payload and a second message header corresponding to the tunnel information.

The processing module 202 is configured to obtain the multicast source group information according to the tunnel information corresponding to the second message header and the corresponding relationship. The corresponding relationship includes the tunnel information and the multicast source group information.

The processing module 202 is also configured to obtain a first message according to the multicast source group information and payload. The first message includes a first message header and a payload. The first message header includes multicast source group information. The first message Does not include the second header.

In a possible way, the receiving module 201 is also configured to receive a third message, the third message includes a payload and a third message header corresponding to the tunnel information; the processing module 202 is also configured to receive the third message according to the third message. The tunnel information and corresponding relationship corresponding to the header are used to obtain the multicast source group information. The corresponding relationship includes tunnel information and multicast source group information. The third header corresponding to the tunnel information is the multi-protocol label switching MPLS header. The MPLS header includes The MPLS label assigned by the egress node to the multicast tree or the MPLS label corresponding to the multicast tree.

In one possible way, the receiving module 201 is also used to obtain the corresponding relationship advertised by the entry node.

For example, the receiving module 201 is also configured to receive indication information advertised by the entry node, where the indication information is used to instruct restoration of the multicast source group information.

Further, the receiving module 201 is specifically configured to receive a Border Gateway Protocol BGP message sent by the ingress node, where the BGP message includes a corresponding relationship.

When the network device 20 is used to perform the above method, it can be applied to the application scenarios shown in Figures 2 to 11, for example, it can be the egress node 200 in the scenario shown in Figure 2. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. Each functional module in the embodiment of the present application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module. For example, in the above embodiment, the receiving module and the processing module may be the same module or different modules. The above integrated modules can be implemented in the form of hardware, such as chips, or in the form of software function modules.

In addition, the embodiment of the present application also provides a network device 30, as shown in FIG. 13. FIG. 13 is a schematic structural diagram of the network device 30 provided by the embodiment of the present application. The network device 30 includes a communication interface 301 and a processor 302 connected to the communication interface 301 . The communication interface is, for example, a device such as a transceiver. The network device 30 can be used to perform the method in the above embodiment. Specifically, the network device 30 may be configured at the ingress node to perform the operations performed by the ingress node in methods S101 to S104 and S201 to S205. The network device 30 may also be configured at the egress node to perform the operations at the egress from methods S105 to S107 and S201 to S205. The operation performed by the node. Among them, the communication interface 301 is used to perform the sending and receiving operations by the entry node in the method. The processor 302 is configured to perform operations other than the sending and receiving operations performed by the entry node in the method. Among them, the communication interface 301 is used to perform the sending and receiving operations performed by the entry node in methods S101 to S104 and S201 to S205. The processor 302 is configured to perform operations other than the sending and receiving operations performed by the entry node in methods S101 to S104 and S201 to S205. For example, when the network device 30 is configured at the entrance node to perform an operation, tunnel information is obtained according to the multicast source group information and the corresponding relationship. The corresponding relationship includes the multicast source group information and tunnel information, and is also used to obtain the third channel information based on the load and tunnel information. Two packets, the second packet includes the payload and the second packet header corresponding to the tunnel information, and the second packet does not include the first packet header. Communication interface 301 is used to receive the first message sent by the user edge device. The first message includes a first message header and a payload. The first message header includes multicast source group information. It is also used to pass the corresponding tunnel information. tunnel to send the second message. When the network device 30 is configured to perform operations at the egress node, the communication interface 301 is used to perform the sending and receiving operations performed by the egress node in methods S105 to S107 and S201 to S205. The processor 302 is configured to perform operations other than the sending and receiving operations performed by the egress node in methods S105 to S107 and S201 to S205. The communication interface 301 is configured to receive a second message, where the second message includes a payload and a second message header corresponding to the tunnel information. The processor 302 is configured to obtain the multicast source group information according to the tunnel information and the corresponding relationship corresponding to the second message header. The corresponding relationship includes the tunnel information and the multicast source group information, and is also used to obtain the multicast source group information according to the multicast source group information and the load. The first message includes a first message header and a payload, the first message header includes multicast source group information, and the first message does not include a second message header.

In addition, this embodiment of the present application also provides a network device 40, as shown in Figure 14. Figure 14 is a schematic structural diagram of a network device 40 provided by an embodiment of the present application. As shown in Figure 14, the network device 40 may include a processor 401, a memory 402 coupled to the processor 401, and a transceiver 403. The transceiver 403 may be a communication interface, an optical module, etc., and is used to receive messages or data information, etc. The processor 401 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP, and is used to perform steps related to forwarding processing in the device exemplified in the above embodiments. The processor may also be an application-specific integrated circuit (application-specific integrated circuit). specific integrated circuit (ASIC), programmable logic device (PLD) or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a general array logic (GAL) or any combination thereof. The processor 401 may refer to one processor or may include multiple processors. The memory 402 may include volatile memory (volatile memory), such as random-access memory (RAM); the memory may also include non-volatile memory (non-volatile memory), such as read-only memory (read- only memory (ROM), flash memory (flash memory), hard disk drive (HDD) or solid-state drive (SSD); the memory 402 may also include a combination of the above types of memory. The memory 402 may refer to one memory or may include multiple memories for storing program instructions. In one embodiment, computer readable instructions are stored in the memory 402, and the computer readable instructions include a plurality of software modules, such as a sending module, a processing module and a receiving module. After executing each software module, the processor 401 can perform corresponding operations according to the instructions of each software module. In this embodiment, the operations performed by the software module actually refer to operations performed by the processor 401 according to the instructions of the software module. Optionally, the processor 401 can also store program codes or instructions for executing the solutions of the embodiments of the present application. In this case, the processor 401 does not need to read the program codes or instructions from the memory 402.

The network device 40 can be used to perform the method in the above embodiment. Specifically, the network device 40 can be configured at the entry node to perform operations performed by the entry node in methods S101 to S104 and S201 to S205, and the network device 40 can be configured at the exit node to perform operations from methods S105 to S107 and S201 to S205 by the exit node. The operation performed. For example, when the network device 40 performs operations as a device set at an ingress node, the processor 401 is configured to execute relevant instructions in the memory 402 to obtain tunnel information according to the multicast source group information and the corresponding relationship. The corresponding relationship includes the multicast source group information and tunnel information, and obtain a second message based on the payload and tunnel information. The second message includes the payload and the second message header corresponding to the tunnel information. The second message does not include the first message header. For example, when the network device 40 operates as a device set at an egress node, the processor 401 is configured to execute relevant instructions in the memory 402 and obtain the multicast source group information according to the tunnel information and corresponding relationship corresponding to the second message header. , the corresponding relationship includes tunnel information and multicast source group information, and the first message is obtained according to the multicast source group information and payload. The first message includes the first message header and payload, and the first message header includes the multicast source group. Information, the first packet does not include the second packet header.

Embodiments of the present application also provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When run on a processor, any one of the methods in any of the foregoing embodiments can be implemented. some or all operations.

Embodiments of the present application also provide a computer program product, including a computer program that, when run on a processor, implements part or all of the operations in any of the methods in any of the foregoing embodiments.

Embodiments of the present application also provide a message transmission system, which can be applied in the scenario shown in Figure 2, including: the system includes at least one network device provided at the entry node and at least one network device provided at the exit node. equipment. As shown in Figure 2, the system may also include network equipment and CE equipment provided at intermediate nodes. Among them, the network device provided at the entry node is a network device corresponding to Figure 11, Figure 13 or Figure 14, and the network device provided at the entry node is a network device with a structure corresponding to Figure 12, Figure 13 or Figure 14. The above communication system is used to implement part or all of the operations in any of the methods of any of the foregoing embodiments.

The embodiment of the present application also provides another communication system, including at least one memory and at least one processor. The at least one memory stores instructions, and the at least one processor executes the instructions, so that the communication system implements the foregoing embodiments. Some or all of the operations in any of the methods of any of the embodiments.

An embodiment of the present application also provides a chip, including: an interface circuit and a processor. The interface circuit is connected to a processor, and the processor is used to cause the chip to perform part or all of the operations in any of the methods of any of the foregoing embodiments.

Embodiments of the present application also provide a chip system, including: a processor, the processor is coupled to a memory, and the memory is used to store programs or instructions. When the programs or instructions are executed by the processor, the chip system implements any of the foregoing embodiments. Some or all of the operations in any of the methods of an embodiment.

Optionally, there may be one or more processors in the chip system. The processor can be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in memory.

Optionally, there may be one or more memories in the chip system. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited by the embodiments of the present application. For example, the memory may be a non-transitory processor, such as a read-only memory ROM, which may be integrated with the processor on the same chip, or may be separately provided on different chips. The embodiment of the present application covers the type of memory, and The arrangement of the memory and processor is not specifically limited.

For example, the chip system can be an FPGA, an ASIC, a system on chip (SoC), a CPU, an NP, or a digital signal processing circuit (digital signal processor, DSP), it can also be a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips.

The terms "first", "second", "third", etc. (if present) in the description and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific sequence. Or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances so that the embodiments described herein can be practiced in sequences other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus that encompasses a series of steps or units and need not be limited to those explicitly listed. Those steps or elements may instead include other steps or elements not expressly listed or inherent to the process, method, product or apparatus.

It should be understood that in the various embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its functions and internal logic, and should not be used in the embodiments of the present application. The implementation process constitutes any limitation.

Those skilled in the art should realize that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Storage media can be any available media that can be accessed by a general purpose or special purpose computer.

The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above-mentioned specific implementations. The above-mentioned specific implementations are only illustrative and not restrictive. Those of ordinary skill in the art will Inspired by this application, many forms can be made without departing from the purpose of this application and the scope protected by the claims, all of which fall within the protection of this application.

Claims

A message transmission method, characterized by including:

The entry node receives the first message sent by the user edge device, the first message includes a first message header and a payload, and the first message header includes multicast source group information;

The entry node obtains tunnel information according to the multicast source group information and the corresponding relationship, where the corresponding relationship includes the multicast source group information and the tunnel information;

The entry node obtains a second message according to the payload and the tunnel information. The second message includes the payload and a second message header corresponding to the tunnel information. The second message does not including the first message header;

The ingress node sends the second message through the tunnel corresponding to the tunnel information.
The method according to claim 1, characterized in that the second message header includes an Internet Protocol version 6 IPv6 header and a general routing encapsulation GRE header, and the IPv6 header includes a source address corresponding to the tunnel information and Destination address.
The method of claim 1, wherein the second message header includes an Internet Protocol version 4 IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information.
The method of claim 1, wherein the second message header includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The method of claim 1, wherein the second message header includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The method according to any one of claims 2 to 5, characterized in that the destination address is the address of the next hop of the entry node in the multicast tree or the destination address is the multicast group corresponding to the multicast tree. address.
The method according to claim 1, characterized in that the second message header includes a multi-protocol label switching MPLS header, and the MPLS header includes the MPLS label of the next hop node of the entry node in the multicast tree or MPLS label corresponding to the multicast tree.
The method according to claim 1, wherein the second message header includes a bit index explicit copy BIER header and a label, and the BIER header includes an identification of the egress node corresponding to the tunnel information, The label is used to identify the multicast source group information.
The method according to any one of claims 1 to 8, characterized in that the method further includes:

The ingress node sends a Border Gateway Protocol BGP message to the egress node, where the BGP message includes the corresponding relationship.
The method of claim 9, further comprising:

The ingress node notifies the egress node of indication information, where the indication information is used to instruct restoration of the multicast source group information.
The method according to claim 9 or 10, characterized in that the BGP message is Border Gateway Protocol-Multicast Virtual Private Network BGP-MVPN signaling or Border Gateway Protocol-Ethernet Virtual Private Network BGP-EVPN signaling.
A message transmission method, characterized by including:

The egress node receives a second message, where the second message includes a payload and a second message header corresponding to the tunnel information;

The egress node obtains the multicast source group information based on the corresponding relationship and the tunnel information corresponding to the second message header. Information, the corresponding relationship includes the tunnel information and the multicast source group information;

The egress node obtains a first message according to the multicast source group information and the payload. The first message includes a first message header and the payload. The first message header includes the group Broadcast source group information, the first packet does not include the second packet header.
The method according to claim 12, characterized in that the second message header includes an Internet Protocol version 6 IPv6 header and a general routing encapsulation GRE header, and the IPv6 header includes a source address corresponding to the tunnel information and Destination address.
The method of claim 12, wherein the second message header includes an Internet Protocol version 4 IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information.
The method according to claim 12, wherein the second message header includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The method of claim 12, wherein the second message header includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The method according to any one of claims 13 to 16, characterized in that the destination address is the address of the next hop of the entry node in the multicast tree or the destination address is the multicast group corresponding to the multicast tree. address.
The method according to claim 12, characterized in that before the egress node obtains the first message according to the multicast source group information and the payload, it further includes:

The egress node receives a third message, where the third message includes the payload and a third message header corresponding to the tunnel information;

The egress node obtains the multicast source group information according to the corresponding relationship and the tunnel information corresponding to the third message header, where the third message header includes a multi-protocol label switching MPLS header, and the The MPLS header includes the MPLS label allocated by the egress node for the multicast tree or the MPLS label corresponding to the multicast tree.
The method according to claim 12, characterized in that the second message header includes a bit index explicit copy BIER header and a label, the BIER header includes an identification of an egress node corresponding to the tunnel information, and the The label is used to identify the multicast source group information.
The method according to any one of claims 12 to 19, characterized in that the method further includes:

The egress node obtains the Border Gateway Protocol BGP message sent by the ingress node, and the BGP message includes the corresponding relationship.
The method of claim 20, further comprising:

The egress node receives the indication information advertised by the ingress node, and the indication information is used to instruct to restore the multicast source group information.
The method according to claim 20 or 21, characterized in that the BGP message is Border Gateway Protocol-Multicast Virtual Private Network BGP-MVPN signaling or Border Gateway Protocol-Ethernet Virtual Private Network BGP-EVPN signaling.
A network device, characterized in that the network device is installed at an entry node and includes:

A receiving module, configured to receive a first message sent by the user edge device, where the first message includes a first message header and a payload, and the first message header includes multicast source group information;

A processing module configured to obtain tunnel information according to the multicast source group information and the corresponding relationship, where the corresponding relationship includes the multicast source group information and the tunnel information;

The processing module is further configured to obtain a second message according to the payload and the tunnel information. The second message includes the payload and a second message header corresponding to the tunnel information. The second message does not include the first message header;

A sending module, configured to send the second message through the tunnel corresponding to the tunnel information.
The network device according to claim 23, wherein the second message header includes an Internet Protocol version 6 IPv6 header and a general routing encapsulation GRE header, and the IPv6 header includes a source address corresponding to the tunnel information. and destination address.
The network device according to claim 23, wherein the second message header includes an Internet Protocol version 4 IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information. .
The network device according to claim 23, wherein the second message header includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The network device according to claim 23, wherein the second message header includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The network device according to any one of claims 24 to 27, characterized in that the destination address is the address of the next hop of the entry node in the multicast tree or the destination address is the multicast corresponding to the multicast tree. Group address.
The network device according to claim 23, characterized in that the second message header includes a multi-protocol label switching MPLS header, and the MPLS header includes the MPLS label of the next hop node of the entry node in the multicast tree. Or the MPLS label corresponding to the multicast tree.
The network device according to claim 23, wherein the second message header includes a bit index explicit copy BIER header and a label, and the BIER header includes an identification of the egress node corresponding to the tunnel information. , the label is used to identify the multicast source group information.
The network device according to any one of claims 23 to 30, characterized in that,

The sending module is also configured to send a Border Gateway Protocol BGP message to the egress node, where the BGP message includes the corresponding relationship.
The network device according to claim 31, characterized in that,

The sending module is also configured to notify the egress node of indication information, where the indication information is used to instruct restoration of the multicast source group information.
The network device according to claim 31 or 32, characterized in that the BGP message is Border Gateway Protocol-Multicast Virtual Private Network BGP-MVPN signaling or Border Gateway Protocol-Ethernet Virtual Private Network BGP-EVPN signaling.
A network device, characterized in that the network device is installed at an egress node, including:

A receiving module, configured to receive a second message, where the second message includes a payload and a second message header corresponding to the tunnel information;

A processing module configured to obtain multicast source group information according to the corresponding relationship and the tunnel information corresponding to the second message header, where the corresponding relationship includes the tunnel information and the multicast source group information;

The processing module is also configured to obtain a first message according to the multicast source group information and the payload. The first message includes a first message header and the payload. The first message header The multicast source group information is included, and the first message does not include the second message header.
The network device according to claim 34, wherein the second message header includes an Internet Protocol version 6 IPv6 header and a general routing encapsulation GRE header, and the IPv6 header includes a source address corresponding to the tunnel information. address and destination address.
The network device according to claim 34, wherein the second message header includes a fourth version Internet Protocol IPv4 header and a GRE header, and the IPv4 header includes a source address and a destination address corresponding to the tunnel information. .
The network device according to claim 34, wherein the second message header includes an IPv6 header and an IPv6 extension header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The network device according to claim 34, wherein the second message header includes an IPv6 header, and the IPv6 header includes a source address and a destination address corresponding to the tunnel information.
The network device according to any one of claims 35 to 38, characterized in that the destination address is the address of the next hop of the entry node in the multicast tree or the destination address is the multicast corresponding to the multicast tree. Group address.
The network device according to claim 34, characterized in that:

The receiving module is also configured to receive a third message, where the third message includes the payload and a third message header corresponding to the tunnel information;

The processing module is also configured to obtain the multicast source group information according to the corresponding relationship and the tunnel information corresponding to the third message header, where the third message header includes multi-protocol label switching MPLS The MPLS header includes the MPLS label allocated by the egress node for the multicast tree or the MPLS label corresponding to the multicast tree.
The network device according to claim 34, wherein the second message header includes a bit index explicit copy BIER header and a label, and the BIER header includes an identification of an egress node corresponding to the tunnel information, so The label is used to identify the multicast source group information.
The network device according to any one of claims 34 to 41, characterized in that,

The receiving module is also configured to obtain the Border Gateway Protocol BGP message sent by the entry node, where the BGP message includes the corresponding relationship.
The network device according to claim 42, characterized in that:

The receiving module is also configured to receive indication information advertised by the entry node, where the indication information is used to instruct restoration of the multicast source group information.
The network device according to claim 42 or 43, characterized in that the BGP message is Border Gateway Protocol-Multicast Virtual Private Network BGP-MVPN signaling or Border Gateway Protocol-Ethernet Virtual Private Network BGP-EVPN signaling.