WO2024244974A1 - Packet transmission method and apparatus, and system - Google Patents

Abstract

The present application relates to the technical field of networks, and discloses a packet transmission method and apparatus, and a system. A first device generates a packet, the packet comprises an MPLS header, a device identifier of the first device, and a packet payload, and the device identifier is encapsulated between the MPLS header and the packet payload. The first device sends a packet to a second device by means of an LSP established between the first device and the second device. Since the packet received by the second device carries the device identifier of the first device, the second device can parse the packet to obtain the device identifier of the first device, and determine, according to the device identifier, that the packet is sent by the first device. Thus, accurate statistics of network traffic is realized in an incoming direction.

Description

Message transmission method, device and system

This application claims priority to Chinese patent application No. 202310638085.5, filed on May 31, 2023, with invention name “Message Transmission Method, Device and System”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of network technology, and in particular to a message transmission method, device and system.

Background Art

Traffic statistics is a basic function of communication networks. By counting network traffic, the quality and health of network operation can be analyzed. Traffic statistics can also be used to locate network faults in a hierarchical manner to narrow the scope of the fault. However, in some network scenarios based on multiprotocol label switching (MPLS) technology for forwarding, such as Ethernet virtual private network (EVPN) based on MPLS (abbreviated as: EVPN over MPLS) scenarios and layer 3 virtual private network (L3VPN) based on MPLS (abbreviated as: MPLS L3VPN) scenarios, it is difficult to achieve accurate statistics of network traffic on network devices.

Summary of the invention

The present application provides a message transmission method, device and system.

In a first aspect, a message transmission method is provided. The method includes: a first device generates a message, the message includes an MPLS header, a device identifier of the first device, and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The first device sends the message to the second device through a label switched path (LSP) established between the first device and the second device.

In the present application, when the first device generates a message, it encapsulates the device identifier of the first device between the MPLS header and the message payload of the message, and then sends the generated message to the second device through the LSP established between the first device and the second device. Since the message received by the second device carries the device identifier of the first device, the second device can parse the message to obtain the device identifier of the first device, and determine that the message is sent by the first device based on the device identifier. In other words, the second device, as the egress device of the message on the label switching path, can accurately identify that the ingress device of the message on the label switching path is the first device. The present application can achieve accurate statistics of network traffic in a network scenario based on MPLS technology for forwarding. For example, in an EVPN over MPLS scenario or an MPLS L3VPN scenario, the egress device on the label switching path can accurately count network traffic in the ingress direction.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry the device identifier. This implementation does not need to change the format of the original MPLS message, and only requires configuring the second device with the ability to parse the control word and identify the device identifier, and configuring the first device with the ability to set the control word as the device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word. This implementation does not need to change the original control word and does not affect the function of the original control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label. In a specific implementation, the bottom label can independently indicate that the device identifier is adjacent to the bottom label. Alternatively, the bottom label and other labels in the label stack jointly indicate that the device identifier is adjacent to the bottom label. For example, if the bottom label is a designated extended special-purpose label, the extended special-purpose label and the preceding extended label jointly indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the first device receives capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message.

In the present application, the first device and the second device can carry the device identifier of the first device in the message sent from the first device to the second device through capability negotiation. Alternatively, the capability of the first device to carry the device identifier of the first device in the generated message and the capability of the second device to parse the device identifier in the received message can also be manually configured.

In one implementation, the capability negotiation information is used to negotiate between a first device and a second device the capability of carrying a device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word. The 4-byte control word is used to carry the device identification of the first device. The main idea of this implementation scheme is that the first device and the second device negotiate the control word capability, and carry the device identification of the first device in the control word, so that after the message reaches the second device, the second device can determine that the message comes from the first device by using the control word information.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identification of the first device. In a specific implementation, the upper 4 bytes of the long control word are used to carry the original control word, and the lower 4 bytes of the long control word are used to carry the device identification of the first device. The main idea of this implementation scheme is that the first device and the second device negotiate the long control word capability, the upper 4 bytes of the long control word carry the original control word, and the lower 4 bytes of the long control word carry the device identification of the first device, so that after the message arrives at the second device, the second device can use the lower 4 bytes of the long control word to determine that the message comes from the first device.

In another implementation manner, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the bottom label is a pre-configured static label, or a dynamic label assigned by the second device, or a specified base special-purpose label (bSPL). The main idea of this implementation scheme is that the first device and the second device negotiate a label indication capability, and the 4 bytes after the bottom label indication label stack carry the device identification of the first device, so that after the message arrives at the second device, the second device can determine that the message comes from the first device using the 4 bytes after the bottom label.

In a specific implementation, the label at the bottom of the stack is a designated extended special-purpose label (eSPL). When the label stack of the message carries the eSPL, the label stack also carries a special label, which is used to indicate that the subsequent adjacent label is the eSPL. The main idea of this implementation scheme is that the first device and the second device negotiate an extended label indication capability, and the 4 bytes after the eSPL indication label stack designated by the bottom of the stack carry the device identification of the first device. In this way, after the message arrives at the second device, the second device can determine that the message comes from the first device by using the 4 bytes after the label at the bottom of the stack.

In a specific implementation, a first device receives capability negotiation information sent by a second device, including: the first device receives a border gateway protocol (BGP) EVPN route sent by the second device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

This application can be applied to EVPN over MPLS scenarios, and capability negotiation information can be published in BGP EVPN routing.

In a specific implementation, a first device receives capability negotiation information sent by a second device, including: the first device receives a BGP L3VPN route sent by the second device, the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

This application can be applied to MPLS L3VPN scenarios, and capability negotiation information can be published in L3VPN routing.

In a specific implementation, the first device sends a capability negotiation response to the second device. The capability negotiation response indicates that the first device has the capability to carry the device identifier of the first device in the message. In this way, the second device can clearly know whether the first device has the capability to carry the device identifier in the message, which can improve the reliability of capability negotiation.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In a second aspect, a message transmission method is provided. The method includes: a second device receives a message sent by a third device through an LSP established between the second device and the first device, the third device is a label switching device located between the first device and the second device on the LSP, the message includes an MPLS header, a device identifier of the first device, and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The second device parses the message to obtain the device identifier of the first device.

In a specific implementation, the second device determines that the message comes from the first device according to the device identifier of the first device, so as to perform traffic statistics on the message from the first device.

In the present application, since the message received by the second device carries the device identification of the first device, the second device can obtain the device identification of the first device by parsing the message, and determine that the message is sent by the first device based on the device identification of the first device. In other words, the second device, as the egress device of the message on the label switching path, can accurately identify the ingress device of the message on the label switching path as the first device. The present application can achieve accurate statistics of network traffic in a network scenario based on MPLS technology forwarding. For example, in an EVPN over MPLS scenario or an MPLS L3VPN scenario, the egress device on the label switching path can accurately count the network traffic in the ingress direction.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the second device sends capability negotiation information to the first device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message.

In one implementation, the capability negotiation information is used to negotiate between a first device and a second device the capability of carrying a device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In another implementation manner, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP EVPN route to the first device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP L3VPN route to the first device, and the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the second device receives a capability negotiation response sent by the first device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In a third aspect, a message transmission method is provided, comprising: a first device receiving capability negotiation information sent by a second device, the capability negotiation information being used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device.

In the present application, the first device and the second device negotiate capabilities to implement a message sent from the first device to the second device that carries the device identifier of the first device.

In one implementation, the capability negotiation information is used to negotiate between a first device and a second device the capability of carrying a device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In another implementation manner, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, a method for a first device to receive capability negotiation information sent by a second device includes: the first device receives a BGP EVPN route sent by the second device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, a method for a first device to receive capability negotiation information sent by a second device includes: the first device receives a BGP L3VPN route sent by the second device, the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the first device sends a capability negotiation response to the second device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In a fourth aspect, a message transmission method is provided. The method includes: a second device generates capability negotiation information, and the capability negotiation information is used The first device and the second device are used to negotiate a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device. The second device sends the capability negotiation information to the first device.

In one implementation, the capability negotiation information is used to negotiate between a first device and a second device the capability of carrying a device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In another implementation manner, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP EVPN route to the first device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP L3VPN route to the first device, and the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the second device receives a capability negotiation response sent by the first device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In a fifth aspect, a first device is provided. The first device includes multiple functional modules, and the multiple functional modules interact with each other to implement the method in the above-mentioned first aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on specific implementations. The multiple functional modules include a processing module and a sending module. In a specific implementation, the multiple functional modules also include a receiving module.

The processing module is used to generate a message, the message includes an MPLS header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The sending module is used to send the message to the second device through the LSP established between the first device and the second device.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the receiving module is used to receive capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the receiving module is specifically used to receive the BGP EVPN route sent by the second device, and the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module is specifically used to receive a BGP L3VPN route sent by the second device, where the BGP L3VPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry capability negotiation information.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In a sixth aspect, a second device is provided. The second device includes multiple functional modules, and the multiple functional modules interact with each other to implement the method in the above-mentioned second aspect and its various embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on the specific implementation. The multiple functional modules include a receiving module and a processing module. In a specific implementation, the multiple functional modules also include a sending module.

The receiving module is used to receive a message sent by a third device through an LSP established between the second device and the first device, the third device is a label switching device located between the first device and the second device on the LSP, and the message includes an MPLS header, a device identifier of the first device, and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The processing module is used to parse the message to obtain the device identifier of the first device.

In a specific implementation, the processing module is further used to determine that the message comes from the first device according to the device identifier of the first device, so as to perform traffic statistics on the message from the first device.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the sending module is used to send capability negotiation information to the first device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the sending module is specifically used to send a BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module is specifically used to send a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In the seventh aspect, a first device is provided. The first device includes multiple functional modules, and the multiple functional modules interact with each other to implement the method in the third aspect and its respective embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on the specific implementation. The multiple functional modules include a receiving module. In a specific implementation, the multiple functional modules also include a sending module.

The receiving module is used to receive capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in an MPLS message sent by the first device to the second device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the receiving module is specifically used to receive a BGP EVPN route sent by a second device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module is specifically used to receive a BGP L3VPN route sent by a second device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module is used to send a capability negotiation response to the second device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In an eighth aspect, a second device is provided. The second device includes a plurality of functional modules, and the plurality of functional modules interact with each other to implement the method in the fourth aspect and each embodiment thereof. The plurality of functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules can be arbitrarily combined or divided based on a specific implementation. The plurality of functional modules include a processing module and a sending module. In a specific implementation, the plurality of functional modules also include a receiving module.

The processing module is used to generate capability negotiation information, which is used to negotiate between the first device and the second device on the capability of carrying the device identifier of the first device in the MPLS message sent by the first device to the second device. The sending module is used to send the capability negotiation information to the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the sending module is specifically used to send a BGP EVPN route to a first device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module is specifically used to send a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module is used to receive a capability negotiation response sent by the first device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

In the ninth aspect, a message transmission system is provided, including: a first device and a second device, wherein the first device is used to implement the method in the first aspect or any possible implementation of the first aspect, and the second device is used to implement the method in the second aspect or any possible implementation of the second aspect; or, the first device is used to implement the method in the third aspect or any possible implementation of the third aspect, and the second device is used to implement the method in the fourth aspect or any possible implementation of the fourth aspect.

In a tenth aspect, a network device is provided, comprising: a communication interface; and a processor connected to the communication interface. According to the communication interface and the processor, the method in the first aspect or any possible implementation of the first aspect is implemented, or the method in the second aspect or any possible implementation of the second aspect is implemented, or the method in the third aspect or any possible implementation of the third aspect is implemented, or the method in the fourth aspect or any possible implementation of the fourth aspect is implemented.

In the eleventh aspect, a computer-readable storage medium is provided, on which instructions are stored. When the instructions are executed by a processor, the method in the first aspect or any possible implementation of the first aspect is implemented, or the method in the second aspect or any possible implementation of the second aspect is implemented, or the method in the third aspect or any possible implementation of the third aspect is implemented, or the method in the fourth aspect or any possible implementation of the fourth aspect is implemented.

In the twelfth aspect, a computer program product is provided, including a computer program. When the computer program is executed by a processor, it implements the method in the first aspect or any possible implementation of the first aspect, or implements the method in the second aspect or any possible implementation of the second aspect, or implements the method in the third aspect or any possible implementation of the third aspect, or implements the method in the fourth aspect or any possible implementation of the fourth aspect.

In the thirteenth aspect, a chip is provided, which includes a programmable logic circuit and/or program instructions. When the chip is running, it implements the method in the first aspect or any possible implementation of the first aspect, or implements the method in the second aspect or any possible implementation of the second aspect, or implements the method in the third aspect or any possible implementation of the third aspect, or implements the method in the fourth aspect or any possible implementation of the fourth aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of publishing MAC addresses in an EVPN over MPLS scenario in the related art;

FIG2 is a schematic diagram of message transmission in an EVPN over MPLS scenario in the related art;

FIG3 is a schematic diagram of issuing IP addresses in an MPLS L3VPN scenario in the related art;

FIG4 is a schematic diagram of message transmission in an MPLS L3VPN scenario in the related art;

FIG5 is a schematic diagram of an application scenario provided by an embodiment of the present application;

FIG6 is a flow chart of a message transmission method provided in an embodiment of the present application;

7 is a schematic diagram of the structure of an MPLS message provided in an embodiment of the present application;

FIG8 is a schematic diagram of the structure of another MPLS message provided in an embodiment of the present application;

FIG9 is a schematic diagram of the structure of another MPLS message provided in an embodiment of the present application;

10 is a schematic diagram of the structure of another MPLS message provided in an embodiment of the present application;

11 is a schematic diagram of the structure of a BGP update message provided in an embodiment of the present application;

12 is a schematic diagram of the structure of a capability negotiation extended group attribute provided in an embodiment of the present application;

FIG13 is a schematic diagram of message transmission in an EVPN over MPLS scenario provided by an embodiment of the present application;

14 is a schematic diagram of the structure of another capability negotiation extended group attribute provided in an embodiment of the present application;

FIG15 is another schematic diagram of message transmission in an EVPN over MPLS scenario provided by an embodiment of the present application;

16 is a schematic diagram of the structure of another capability negotiation extended group attribute provided in an embodiment of the present application;

FIG17 is another schematic diagram of message transmission in an EVPN over MPLS scenario provided by an embodiment of the present application;

18 is a schematic diagram of the structure of another capability negotiation extended group attribute provided in an embodiment of the present application;

FIG19 is a schematic diagram of another message transmission in an EVPN over MPLS scenario provided by an embodiment of the present application;

FIG20 is a schematic diagram of a flow chart of another message transmission method provided in an embodiment of the present application;

FIG21 is a flow chart of another message transmission method provided in an embodiment of the present application;

FIG22 is a flow chart of another message transmission method provided in an embodiment of the present application;

FIG23 is a flow chart of another message transmission method provided in an embodiment of the present application;

FIG24 is a schematic diagram of the structure of a message transmission device provided in an embodiment of the present application;

FIG25 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application;

FIG26 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application;

FIG27 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application;

FIG28 is a block diagram of a message transmission device provided in an embodiment of the present application;

Figure 29 is a block diagram of another message transmission device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

Currently, hosts located at different sites can communicate across sites. A site can be considered as a local area network, such as a single subnet local area network or a multiple subnet local area network. Different sites can be deployed in different regions. One or more hosts can be deployed in a site. A host refers to a terminal device with a client installed, such as a smartphone, tablet computer, desktop computer, Internet of Things (IoT) device, network device, workstation or server.

Hosts within a site usually belong to a private network. Different hosts within a site can belong to the same private network or different private networks. Hosts within a private network are usually configured with an intranet address. Since the intranet addresses of different private networks can overlap, the intranet addresses configured for hosts within a private network can generally only be used to communicate within the private network. Private networks can be deployed across sites, that is, a private network can include multiple hosts deployed at different sites. For example, a private network is distributed and deployed at site A and site B, and site A and site B are connected through a carrier network, which means that the private network includes hosts located at site A and hosts located at site B. Private networks can be implemented using virtual private networks (VPN). For a private network, hosts deployed in the private network are intranet hosts, while carrier networks and other private networks are external networks. Among them, the carrier network used to connect different sites can be a wide area backbone network or a metropolitan area network established using MPLS technology. The private network here can be a private network of an enterprise. The network of an enterprise at a certain site is the enterprise's internal network, and the multiple networks of the enterprise deployed at multiple sites are called the enterprise's private network or multi-site private network.

For a private network distributed in multiple sites, if the intranet host of one site wants to send a message to the intranet host of another site, the transmission of the message needs to pass through the external network between the two sites. The intranet host of a site needs to communicate with the external network through the edge access device of the site. The edge access device of the site is usually called a customer edge (CE) device. CE devices can be, for example, routers, switches, or gateways. Taking the external network as an operator network as an example, the CE device of each site is connected to a provider edge (PE) device. When the intranet host of one site sends a message to the intranet host of another site, the message first reaches the CE device of the local site, and then is transmitted by the CE device of the local site to the connected PE device. Then, the message reaches the remote PE device after being transmitted through the operator network, and then is transmitted by the remote PE device to the CE device of the remote site, and finally, the CE device of the remote site is transmitted to the intranet host of the remote site.

Optionally, hosts at different sites can communicate via a Layer 2 network or a Layer 3 network. Hosts communicate via a Layer 2 network, i.e., hosts communicate based on Media Access Control (MAC) routing. Hosts communicate via a Layer 3 network, i.e., hosts communicate based on Internet Protocol (IP) routing.

EVPN technology is a VPN technology used for Layer 2 network interconnection. Since EVPN can solve the problem that traditional virtual private LAN service (VPLS) does not support dual-homing network load sharing, and can avoid the drawbacks of full connection between public network pseudo wires (PW), and achieve rapid routing convergence, it has been widely used in the network in recent years. Among them, VPLS is a Layer 2 VPN technology based on MPLS and Ethernet technology. Different from the mechanism of learning MAC addresses through the forwarding plane in traditional Layer 2 virtual private network (L2VPN), EVPN introduces the control plane. EVPN transfers the MAC address publishing process between Layer 2 networks of different sites from the forwarding plane to the control plane by extending the multiprotocol border gateway protocol (MP-BGP). Compared with traditional L2VPN, EVPN has some functional differences due to differences in implementation principles. In the EVPN over MPLS scenario, MAC routes are delivered to the remote PE devices through the control plane.

L3VPN technology is a VPN technology used for interconnecting three-layer networks.

For example, FIG1 is a schematic diagram of publishing a MAC address in an EVPN over MPLS scenario in the related art. FIG2 is a schematic diagram of message transmission in an EVPN over MPLS scenario in the related art. FIG3 is a schematic diagram of publishing an IP address in an MPLS L3VPN scenario in the related art. FIG4 is a schematic diagram of message transmission in an MPLS L3VPN scenario in the related art. In the scenarios shown in FIG1 to FIG4, the operator network includes three PE devices, PE1 to PE3, and two operator (provider, P) devices, P1 and P2. The P device is not shown in FIG1 and FIG3. PE1 is connected to P1 and P2 respectively. P1, P2, PE2 and PE3 are connected in pairs. CE1 is connected to PE1 to access the communication network. CE2 is dual-homed to PE2 and PE3 to access the communication network, that is, PE2 and PE3 are dual-homed access devices of CE2.

In the scenarios shown in Figures 1 and 2, PE1, PE2, and PE3 establish BGP EVPN peer relationships with each other. As shown in Figure 1, after PE1 learns MAC1 from CE1, it allocates a private network label Label1 and sends it to the remote PE2 and PE3 respectively. As shown in Figure 2, CE2 sends a Layer 2 message with a destination MAC address of DMAC (for example, MAC1) and a source MAC address of SMAC to CE1. If the message is sent from PE2 to PE1 through P1, PE2 generates an MPLS message, which includes an MPLS header and a message payload. The MPLS header includes the public network label LSP1 allocated by P1 and the private network label Label1 allocated by PE1. The Layer 2 message sent by CE2 is encapsulated in the message payload. After P1 receives the MPLS message sent by PE2, it can pop out the public network label LSP1 and then continue to send the MPLS message to PE1. Finally, the message received by PE1 includes an MPLS header and a message payload. The MPLS header includes the private network label Label1 assigned by PE1. If the message is sent from PE3 to PE1 through P2, PE3 generates an MPLS message. The MPLS message includes an MPLS header and a message payload. The MPLS header includes the public network label LSP2 assigned by P2 and the private network label Label1 assigned by PE1. The Layer 2 message sent by CE2 is encapsulated in the message payload. After P2 receives the MPLS message sent by PE3, it can encapsulate the public network label LSP2 and the private network label Label1 assigned by PE1. Label LSP2 pops up, and then continues to send the MPLS message to PE1. The message finally received by PE1 includes an MPLS header and a message payload. The MPLS header includes the private network label Label1 assigned by PE1. In other words, no matter whether the Layer 2 message sent by CE2 to CE1 is forwarded by PE2 or PE3, the private network label carried by the MPLS message finally received by PE1 is Label1. Therefore, PE1 cannot distinguish whether the traffic comes from PE2 or PE3 in the inbound direction. The message structure shown in Figure 2 is only used as an example. The MPLS header of the actual MPLS message received by PE1 may also include an encapsulated outer MAC header. Among them, the private network label is also called a VPN label, and the public network label is also called an LSP label.

For ease of understanding, only one P device is drawn between PE devices in the scenarios shown in FIG2 and FIG4 , and those skilled in the art can understand that multiple P devices can be included between PE devices. The MPLS technology described in this application can be a traditional MPLS technology or a segment routing (SR) MPLS (abbreviated as: SR-MPLS) technology based on the MPLS forwarding plane.

In the scenarios shown in Figures 3 and 4, BGP L3VPN peer relationships are established between PE1, PE2, and PE3. As shown in Figure 3, after PE1 learns IP1 from CE1, it allocates a private network label Label2 and sends it to the remote PE2 and PE3 respectively. As shown in Figure 4, CE2 sends a Layer 3 message to CE1 with the destination IP address being the destination IP (for example, IP1) and the source IP address being the source IP. If the message is sent from PE2 to PE1 via P1, PE2 generates an MPLS message, which includes an MPLS header and a message payload. The MPLS header includes the public network label LSP1 allocated by P1 and the private network label Label2 allocated by PE1. The Layer 3 message sent by CE2 is encapsulated in the message payload. After P1 receives the MPLS message sent by PE2, it can pop out the public network label LSP1 and continue to send the MPLS message to PE1. Finally, the message received by PE1 includes an MPLS header and a message payload. The MPLS header includes the private network label Label2 assigned by PE1. If the message is sent from PE3 to PE1 through P2, PE3 generates an MPLS message. The MPLS message includes an MPLS header and a message payload. The MPLS header includes the public network label LSP2 assigned by P2 and the private network label Label2 assigned by PE1. The three-layer message sent by CE2 is encapsulated in the message payload. After P2 receives the MPLS message sent by PE3, it can pop out the public network label LSP2 and continue to send the MPLS message to PE1. Finally, the message received by PE1 includes an MPLS header and a message payload. The MPLS header includes the private network label Label2 assigned by PE1. In other words, no matter whether the three-layer message sent by CE2 to CE1 is forwarded by PE2 or PE3, the private network label carried by the MPLS message received by PE1 is Label2. Therefore, PE1 cannot distinguish whether the traffic comes from PE2 or PE3 in the inbound direction. The message structure shown in FIG. 4 is only used for exemplary description. In reality, the MPLS message received by PE1 may also include an encapsulated outer MAC header before the MPLS header.

As can be seen from the above, in some network scenarios based on MPLS technology for forwarding, such as EVPN over MPLS scenarios and MPLS L3VPN scenarios, it is difficult for network devices to achieve accurate statistics of network traffic in the inbound direction. Based on this, the present application provides a technical solution, in which the network device encapsulates the device identifier of the network device between the MPLS header and the payload of the message when generating a message, and then sends the generated message to other network devices through the LSP established between the network device and other network devices. Since the message received by other network devices carries the device identifier of the network device, other network devices can parse the message to obtain the device identifier of the network device, and determine that the message is sent by the network device based on the device identifier, thereby achieving accurate statistics of network traffic in the inbound direction.

The following is a detailed introduction to the technical solution of this application from multiple angles, including application scenarios, method flow, virtual devices, physical devices, and systems.

The following is an illustration of the application scenarios involved in the embodiments of the present application.

The application scenarios of the present application include a communication network and a site connected to the communication network. The communication network is an MPLS VPN network, also known as an MPLS BGP VPN network. The communication network is a bearer network, such as a data center network (DCN), a metropolitan area network, a wide area network or a local area network, which can be used to carry EVPN services and/or L3VPN services. In other words, the application scenario of the present application can be an EVPN over MPLS scenario, or it can also be an MPLS L3VPN scenario. In addition, the communication network can be an operator network or an enterprise-built network.

The communication network provided in the present application includes multiple network devices for service forwarding, and the multiple network devices are communicatively connected. Each network device may be a switch or a router. Among them, the multiple network devices include edge network devices and core network devices. The edge network device is at the edge of the communication network and is used for sites to access the communication network. The core network device is connected between different edge network devices and is used to forward services between different edge network devices. Optionally, the site is connected to the edge network device of the communication network through an edge access device to access the communication network through the edge access device. The edge access device may be a switch, a router or a gateway, etc. The embodiment of the present application is described by taking the communication network as an operator network as an example, the edge network device is a PE device, the core network device is a P device, the edge access device is a CE device, and one or more hosts are deployed in the site accessing the communication network.

For example, Figure 5 is a schematic diagram of an application scenario provided by an embodiment of the present application. As shown in Figure 5, the application scenario includes a communication network (Figure 5 shows MPLS VPN) and two CE devices CE1 to CE2 connected to the communication network. The communication network includes three PE devices PE1 to PE3, and two P devices P1 and P2. PE1 is connected to P1 and P2 respectively. P1, P2, PE2 and PE3 are connected in pairs. CE1 connects PE1 to access the communication network. CE2 dual-homes PE2 and PE3 to access the communication network, that is, PE2 and PE3 are dual-home access devices of CE2. CE1 is an edge access device for site 1, used to connect host 1 and host 2 in site 1 to the communication network. CE2 is an edge access device for site 2, used to connect host 3 and host 4 in site 2 to the communication network. The application scenario shown in Figure 5 may be the application scenario shown in Figure 1 or Figure 2, Then the MPLS VPN is EVPN over MPLS. Alternatively, the application scenario shown in FIG5 may be the application scenario shown in FIG3 or FIG4 , then the MPLS VPN is MPLS L3VPN.

Optionally, PE1, PE2, and PE3 are BGP neighbors of each other. In the embodiment of the present application, two PE devices are BGP neighbors of each other, which may be a BGP peer relationship established between the two PE devices. Alternatively, the communication network also includes a route reflector, and the two PE devices are BGP neighbors of each other, or the two PE devices respectively establish a BGP peer relationship with the route reflector, that is, the two PE devices are indirectly communicated through the route reflector. Among them, the route reflector is used to forward messages transmitted between different PE devices, and the route reflector does not modify the received messages during the forwarding process. In the application scenario shown in Figure 5, the EVPN over MPLS scenario, for example, in the scenario shown in Figure 1 or Figure 2, PE1, PE2, and PE3 are BGP EVPN neighbors of each other, and the BGP peer relationship established between the devices is a BGP EVPN peer relationship. In the application scenario shown in FIG5 , which is an MPLS L3VPN scenario, for example, in the scenario shown in FIG3 or FIG4 , PE1, PE2, and PE3 are each other's BGP L3VPN neighbors, and the BGP peer relationship established between the devices is a BGP L3VPN peer relationship.

Optionally, one or more forwarding instances are configured in the PE device in the communication network. Different forwarding instances in the same device work independently to achieve route isolation. In the embodiment of the present application, the forwarding instance in the PE device can be a layer 2 forwarding instance, also known as an EVPN instance (EVPN instance, EVI) (corresponding to a layer 2 forwarding domain), and the layer 2 forwarding instance can publish MAC routes. An EVI can be composed of one or more bridge domains (bridge domain, BD). Alternatively, the forwarding instance in the PE device can also be a layer 3 forwarding instance, also known as a virtual routing forwarding (virtual routing forwarding, VRF) instance (corresponding to a layer 3 forwarding domain), and the layer 3 forwarding instance can publish IP routes. Among them, each forwarding instance is configured with a route target (route target), which can also be called vpn-target. Route target is a BGP extended community attribute, and each forwarding instance needs to be configured with two types of route targets, the outbound direction and the inbound direction. When the outbound route target value configured by the local forwarding instance is equal to the inbound route target value configured by the opposite forwarding instance, the local end and the opposite end can exchange BGP routes with each other. In the embodiment of the present application, two PE devices that are BGP EVPN neighbors are configured with EVIs belonging to the same EVPN. In this case, the two PE devices can also be said to belong to the same EVPN. Two PE devices that are BGP L3VPN neighbors are configured with VRF instances belonging to the same L3VPN. In this case, the two PE devices can also be said to belong to the same L3VPN.

Optionally, after the PE device learns the MAC route (or IP route) from the CE device, it needs to publish the learned MAC route (or IP route) and its corresponding private network label in the communication network. There are many ways for the PE device to assign private network labels to MAC routes (or IP routes). For example, the PE device can assign a private network label to each forwarding instance configured in the PE device, so the private network labels corresponding to all MAC routes (or IP routes) published by the same forwarding instance in the PE device are the same private network label. Alternatively, the PE device can assign a private network label to each MAC route (or IP route). Alternatively, the PE device can assign a private network label to each accessed CE, so the private network labels corresponding to all MAC routes (or IP routes) learned by the PE device from the same CE device are the same private network label. Alternatively, the PE device can assign a private network label to a broadcast domain, so the private network labels corresponding to all MAC routes published by the PE device in the broadcast domain are the same private network label. The embodiment of the present application does not limit the way in which the PE device assigns private network labels.

The following is an example of the method flow of the embodiment of the present application.

For example, FIG6 is a flow chart of a message transmission method provided by an embodiment of the present application. As shown in FIG6, method 600 includes steps 601 to 604. Device 1 and device 2 in method 600 are network edge devices of the MPLS VPN network, such as routers, switches, or gateways. An LSP is established between device 1 and device 2, and device 3 is a label switching device located between device 1 and device 2 on the LSP. In the scenario where the MPLS VPN network is an operator network, device 1 in method 600 is an ingress operator edge device (ingress PE), and device 2 in method 600 is an egress operator edge device (egress PE). In the scenario where the MPLS VPN network is a data center network, device 1 in method 600 is an ingress gateway, and device 2 in method 600 is an egress gateway. The embodiment of the present application does not limit the implementation scenario of the MPLS VPN network and the device type of the network edge device. For example, the method 600 can be applied to the application scenario shown in FIG5. For example, device 1 in method 600 is PE2 or PE3 shown in FIG. 5 , device 2 in method 600 is PE1 shown in FIG. 5 , and device 3 in method 600 is P1 or P2 shown in FIG. 5 .

Step 601: Device 1 generates a message, which includes an MPLS header, a device identifier of device 1 and a message payload. The device identifier is encapsulated between the MPLS header and the message payload.

Among them, the message generated by device 1 is an MPLS message. The MPLS message includes a message header and a message payload. The message header includes an MPLS header and a device identifier of device 1. The message payload is an inner message of the MPLS message. The inner message can be a layer 2 message or a layer 3 message, which is usually an original data message sent by a user edge device. The layer 3 message can be an IPv4 message or an IPv6 message. In the embodiment of the present application, the message portion of the MPLS message located before the message payload is called the message header of the MPLS message.

Optionally, the device identification of device 1 is a router identification (router ID) of device 1. Alternatively, the device identification of device 1 may also be a router identification (router ID) of device 1. The information that can uniquely identify device 1 in the communication network, such as the IP address of device 1, the hardware address of device 1, or the MAC address of device 1. The embodiment of the present application does not limit the type of device identification. The length of the device identification of device 1 can be 2 bytes, 4 bytes, 6 bytes, or 8 bytes, etc., and the embodiment of the present application does not limit the length of the device identification. For example, the device identification of device 1 is the router ID of device 1, and accordingly, the length of the device identification of device 1 is 4 bytes. The following embodiments of the present application are all described by taking the length of the device identification as 4 bytes as an example.

Optionally, after receiving the original data message sent by the user edge device, device 1 generates an MPLS message. For example, Figure 7 is a schematic diagram of the structure of an MPLS message provided in an embodiment of the present application. As shown in Figure 7, the MPLS message includes a message header and a message payload. Among them, the message header includes a MAC header, an MPLS header and a device identifier of device 1. The MPLS header includes an LSP label (optional) and a VPN label. The message payload is the original data message received by device 1 from the user edge device.

Optionally, the device identifier of device 1 can be set at different positions in the MPLS message. The embodiment of the present application is described by taking the following three possible implementation methods as examples. Among them, the setting position of the device identifier in the MPLS message can be defined in the protocol or standard. Alternatively, the network edge devices can negotiate to determine the setting position of the device identifier in the MPLS message.

In a first possible implementation, the message generated by device 1 includes a control word, and the control word is used to carry the device identification of device 1. In other words, the device identification of device 1 is the control word in the message. In this implementation, the message generated by device 1 can be shown in Figure 8, for example. Optionally, the control word is a 4-byte control word. This implementation does not require changing the format of the original MPLS message, but only requires configuring the ability to parse the control word and identify the device identification in the network edge device on the receiving side, and configuring the ability to set the control word as the device identification in the network edge device on the sending side.

In a second possible implementation, the message generated by device 1 includes a control word, and the device identification of device 1 is adjacent to the control word. Optionally, the device identification of device 1 is located after the control word. The control word here refers to the original control word of 4 bytes. Under this implementation, the message generated by device 1 can be shown in Figure 9, for example. Optionally, the message generated by device 1 includes an 8-byte long control word. The 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identification of device 1. For example, the upper 4 bytes of the long control word are used to carry the original control word, and the lower 4 bytes of the long control word are used to carry the device identification of device 1, that is, the device identification of device 1 is in the lower 4 bytes of the long control word. This implementation does not require changing the original control word and will not affect the function of the original control word.

In a third possible implementation, the stack bottom label of the MPLS header in the message generated by device 1 indicates that the device identifier of device 1 is adjacent to the stack bottom label. In other words, the device identifier of device 1 is adjacent to the stack bottom label of the MPLS header. In this implementation, the message generated by device 1 may be, for example, as shown in FIG. 10 .

Optionally, the bottom label can separately indicate that the device ID of device 1 is adjacent to the bottom label. For example, the bottom label is a pre-configured static label, or a dynamic label assigned by device 2, or a specified basic special purpose label (bSPL). In the case where the bottom label is a pre-configured static label, the static label is pre-configured in device 1 and device 2 respectively. The static label pre-configured in device 1 is used to carry the bottom of the label stack of the message sent to device 2, so as to indicate that the device ID of device 1 is carried after the static label. The static label pre-configured in device 2 is used to parse the bottom label of the message received by device 2, so as to determine whether the device ID of the device sending the message is carried after the bottom label. In the case where the bottom label is a dynamic label assigned by device 2, device 2 can generate the dynamic label and send it to device 1. In the case where the bottom label is a specified bSPL, the specified bSPL can be defined in the standard or protocol, such as the standard or protocol definition: when the bSPL as the bottom label takes a specified label value, it indicates that the device ID is carried after the bottom label. The embodiment of the present application does not limit the specific value of the specified label value.

Alternatively, the bottom label and other labels in the label stack together indicate that the device identifier of device 1 is adjacent to the bottom label. For example, when the bottom label is a designated extended special purpose label (eSPL), when the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the label adjacent thereto is the eSPL. That is to say, the bottom label and the special label together indicate that the device identifier of device 1 is adjacent to the bottom label of the stack. Specifically, the special label indicates that the label adjacent to the special label is the eSPL, and the designated eSPL (bottom label) indicates that the device identifier of device 1 is adjacent to the eSPL. The special label may be an extension label (XL) with a label value of 15. When the bottom label of the stack is a designated eSPL, the designated eSPL may be defined in a standard or protocol, such as a standard or protocol definition: when the eSPL as the bottom label takes a designated label value, it indicates that the device identifier is carried after the bottom label of the stack. Optionally, the value range of eSPL is 16 to 1048, and any label value therein may be defined as the designated label value. The embodiment of the present application does not limit the specific value of the designated label value.

In the EVPN over MPLS scenario, the payload of the MPLS message transmitted between network devices in the communication network is a Layer 2 message. To prevent the Layer 2 message from being mistakenly identified as an IPv4 message or an IPv6 message by the network devices in the communication network, the network edge devices can negotiate the control word (CW) capability. The network edge device on the sending side can insert the control word between the MPLS header and the message payload. The control word is 4 bytes long and is usually set to all 0s. This can prevent the intermediate network devices (such as P devices) in the communication network from misidentifying the Layer 2 message as an IPv4 message or an IPv6 message. The control word is misidentified as an IPv4 message or an IPv6 message, thereby performing incorrect load sharing and causing message disorder. The definition and function of the control word can be explained in detail in the request for comments (RFC) numbered 7432 (abbreviated as RFC 7432), which will not be described in detail in the present application.

Optionally, when device 1 and device 2 are BGP EVPN neighbors, if CW capability is negotiated between device 1 and device 2, device 1 may carry the device identifier of device 1 in the message using the first possible implementation or the second possible implementation. Alternatively, device 1 may carry the device identifier of device 1 in the message using the third possible implementation. When device 1 uses the first possible implementation, in order to avoid conflict with the original function of the control word, if the value of the first 4 bits (bits) of the device identifier of device 2 is 4 (corresponding to binary: 0100) or 6 (corresponding to binary: 0110), the value of the first 4 bits of the device identifier may be mapped to non-4 and non-6, so as to prevent the intermediate network device in the communication network from misidentifying the received layer 2 message as an IPv4 message or an IPv6 message. For example, if the value of the first 4 bits of the device identifier of device 2 is 4, the value of the first 4 bits may be mapped to 14 (corresponding to binary: 1110). If the value of the first 4 bits of the device identifier of device 2 is 6, the value of the first 4 bits may be mapped to 15 (corresponding to binary: 1111).

Optionally, when device 1 and device 2 are BGP L3VPN neighbors, device 1 can use the third possible implementation to carry the device identifier of device 1 in the message. That is, the third implementation is applicable to both EVPN over MPLS scenarios and MPLS L3VPN scenarios.

Step 602: Device 1 sends the message to device 2 through the LSP established between device 1 and device 2.

Taking the application scenario shown in FIG5 as an example, assuming that host 3 in site 2 and host 1 in site 1 belong to the same private network, when host 3 needs to send a data packet to host 1 across sites, the data packet will pass through CE2, MPLS VPN network and CE1 in sequence, and finally reach host 1. Among them, there are 4 transmission paths from CE2 to CE1 in the MPLS VPN network, including transmission path 1: CE2→PE2→P1→PE1→CE1, transmission path 2: CE2→PE2→P2→PE1→CE1, transmission path 3: CE2→PE3→P1→PE1→CE1, and transmission path 4: CE2→PE3→P2→PE1→CE1. Assuming that device 2 is PE1 in the application scenario shown in FIG5, and device 1 is PE2 in the application scenario shown in FIG5, after PE2 receives the data packet sent by CE2, it generates an MPLS packet containing the data packet, and then PE2 sends the generated MPLS packet to PE1, and the MPLS packet can be transmitted through transmission path 1 or transmission path 2.

After receiving the message sent by device 1, device 3 located between device 1 and device 2 continues to send the message to device 2 based on the MPLS protocol.

Step 603: Device 2 parses the message and obtains the device identification of device 1.

Optionally, after device 2 receives the message sent by device 3 through the LSP established between device 2 and device 1, it can parse the device identifier of device 1 from the corresponding setting position based on the setting position of the device identifier in the message header determined by negotiation with device 1, or the setting position of the device identifier in the message header defined in the protocol or standard.

In combination with the first possible implementation manner in step 601 above, device 2 obtains the device identification of device 1 by parsing the control word in the message.

In combination with the second possible implementation of step 601, device 2 obtains the device identification of device 1 by parsing the field adjacent to the control word in the message. For example, device 2 can parse the 4-byte content adjacent to the control word in the message to obtain the device identification of device 1.

In combination with the third possible implementation in step 601, device 2 first parses the label stack of the message, and after determining that the bottom label of the label stack indicates that the device identifier is adjacent to the bottom label, device 2 further parses the field adjacent to the bottom label to obtain the device identifier of device 1. For example, device 2 can parse the 4-byte content adjacent to the bottom label in the message to obtain the device identifier of device 1.

Step 604: Device 2 determines that the message comes from device 1 according to the device identifier.

Since the message received by device 2 carries the device identifier of device 1, device 2 can determine that the message comes from device 1. Then, traffic statistics can be performed on the message from device 1. Combined with the example in the above step 602, for PE1, after PE1 receives the MPLS message sent by P1 or P2, it can only determine that the MPLS message comes from PE2 or PE3 according to the VPN label in the MPLS message, and can clearly determine that the MPLS message comes from PE2 according to the device identifier of PE2 carried in the MPLS message, that is, PE1 can distinguish whether the traffic comes from PE2 or PE3, and then can achieve accurate statistics of network traffic in the inbound direction.

Alternatively, device 2 may not perform traffic statistics on the messages from device 1. For example, the obtained device identification and traffic information may be uniformly reported to the control device, and the control device may perform traffic statistics on the messages from different devices according to different device identifications.

In the message transmission method provided in the embodiment of the present application, when a network device generates a message, it encapsulates the device identification of the network device between the MPLS header and the message payload of the message, and then sends the generated message to other network devices. Since the message received by other network devices carries the device identification of the network device, other network devices can parse the message to obtain the device identification, and determine that the message is sent by the network device based on the device identification. Therefore, it is possible to achieve accurate statistics of network traffic in a network scenario based on MPLS technology forwarding. For example, in an EVPN over MPLS scenario or an MPLS L3VPN scenario, accurate statistics of network traffic can be achieved.

Optionally, the device 1 carries the device identification of the device 1 in the generated MPLS message, and the device 2 parses the received MPLS message. The capability of the device identifier in the text can be manually configured. Alternatively, the capability of carrying the device identifier of device 1 in the message can be negotiated between device 1 and device 2. For example, before the execution of the above step 601, device 2 generates capability negotiation information, and the capability negotiation information is used to negotiate between device 1 and device 2 the capability of carrying the device identifier of device 1 in the MPLS message sent by device 1 to device 2, and then device 2 sends the capability negotiation information to device 1. Specifically, the capability negotiation information indicates that device 1 carries the device identifier of device 1 in the message sent to device 2, and that device 2 has the capability to parse the device identifier carried in the message. Optionally, the capability negotiation information also indicates the setting position of the device identifier of device 1 in the message.

Optionally, after receiving the capability negotiation information sent by device 2, device 1 sends a capability negotiation response to device 2. The capability negotiation response indicates that device 1 has the capability to carry the device identification of device 1 in the message. In this way, device 2 can clearly know whether device 1 has the capability to carry the device identification in the message, which can improve the reliability of capability negotiation.

Alternatively, device 1 may not respond to the capability negotiation information sent by device 2. After device 2 subsequently receives the message, it can determine by itself whether the designated position of the received message carries the device identification of the network edge device that sent the message. For example, in the first possible implementation method of step 601 above, device 2 can determine whether the control word of the received message is a device identification based on whether the control word of the received message is all 0. If the control word of the message is all 0, device 2 determines that the message does not carry a device identification. If the control word of the message is not all 0, device 2 determines that the control word of the message is the device identification of the network edge device that sent the message.

Optionally, the capability negotiation information sent by device 2 to device 1 is carried in a BGP update (BGP update) message, for example, it can be carried in an extended group attribute of the BGP update message, that is, device 2 can use the BGP update message to negotiate with device 1 the ability to carry the device identifier of device 1 in the message. Alternatively, the capability negotiation information sent by device 2 to device 1 can also be carried in a message based on other protocols, such as the Path Computation Element Protocol (PCEP). Alternatively, the capability negotiation information sent by device 2 to device 1 can also be carried in a message in a custom format. The following embodiments of the present application are described by taking the example of carrying the capability negotiation information in an extended group attribute of the BGP update message. In the embodiments of the present application, the extended group attribute that carries the capability negotiation information is referred to as the capability negotiation extended group attribute.

For example, FIG. 11 is a schematic diagram of the structure of a BGP update message provided in an embodiment of the present application. As shown in FIG. 11, the BGP update message includes an Ethernet header, an IP header, a Transmission Control Protocol (TCP) header, a BGP data packet, and a frame check sequence (FCS). Among them, the BGP data packet includes a BGP header and a BGP message field. The BGP header includes a maker field, a length field, and a type field (not shown in the figure). The BGP message field includes an address family identifier, a subsequent address family identifier, a next hop network address length, a next hop network address, a reserved field, a network layer reachability information (NLRI), a capability negotiation extended community attribute, and other path attributes. Among them, the address family identifier, the subsequent address family identifier, the next-hop network address length, the next-hop network address, the reserved field and the NLRI are collectively referred to as the multi-protocol reachable NLRI (MP_REACH_NLRI) attribute. Optionally, the capability negotiation extended group attribute includes a type field, a subtype field, a tag bit field and a reserved field. It can be defined that when the type field and the subtype field of the extended group attribute are a certain value, it indicates that the extended group attribute is a capability negotiation extended group attribute, that is, the extended group attribute carries the above-mentioned capability negotiation information. In addition, the tag bit field of the capability negotiation extended group attribute can be used to indicate the setting position of the device identifier in the message. Different bits of the tag bit field can be used to indicate different setting positions of the device identifier in the message. The interpretation of other fields in the BGP message field can refer to the definition in the RFC 4760 document, and the embodiments of the present application will not be repeated here.

In the first implementation scenario, device 1 and device 2 belong to the same EVPN, that is, device 1 and device 2 are configured with EVI instances belonging to the same EVPN. In other words, device 1 and device 2 are BGP EVPN neighbors. This implementation scenario is the above-mentioned EVPN over MPLS scenario. Device 2 can send a BGP EVPN route to device 1, and the BGP EVPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry capability negotiation information. In other words, capability negotiation information can be published in the BGP EVPN route.

Optionally, the BGP EVPN route can be a Type 1 route (Ethernet auto-discovery route), a Type 2 route (MAC/IP route), or a Type 3 route (inclusive multicast Ethernet tag route) defined in the BGP NLRI. Among them, the Type 1 route is used to describe the link status and cost of the device. The Type 2 route is used to announce the host MAC address, the host Address Resolution Protocol (ARP) mapping (that is, the correspondence between the IP address and the MAC address) or the host IP address, that is, the Type 2 route can be used to announce the Layer 2 routing information and/or the Layer 3 routing information. When the Type 2 route is used to announce the host ARP mapping, the Type 2 route can also be called an ARP type route. When the Type 2 route is used to announce the host IP address, the Type 2 route can also be called an integrated routing and bridge (IRB) type route. Type 3 routing is used to establish network edge devices (such as PE) Of course, the above-mentioned BGP EVPN route can also be other types of routes defined in BGP NLRI, or other types of routes evolved subsequently. The embodiment of the present application does not limit the type of BGP EVPN route. The BGP EVPN route can carry the NLRI in the BGP message field shown in FIG. 11.

In the first possible implementation manner of the first implementation scenario, the capability negotiation information sent by device 2 to device 1 is used to negotiate between device 1 and device 2 the capability of carrying the device identifier of device 1 in the control word of the message.

Optionally, the control word is a 4-byte control word. The 4-byte control word is used to carry the device identification of device 1. The main idea of this implementation scheme is that device 1 and device 2 negotiate the control word capability, and by carrying the device identification of device 1 in the control word, after the message arrives at device 2, device 2 can determine that the message comes from device 1 by using the control word information.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the device identification of device 1 is set in the 4-byte control word. For example, taking the length of the tag bit field of the capability negotiation extended group attribute as 16 bits (0 to 15 bits), Figure 12 is a schematic diagram of the structure of a capability negotiation extended group attribute provided by an embodiment of the present application. As shown in Figure 12, by setting the 15th bit of the tag bit of the capability negotiation extended group attribute to 1 and the remaining bits to 0, it is indicated that the 4-byte control word in the message is set to the device identification of device 1. In this case, device 1 can generate a message as shown in Figure 8.

For example, in the application scenario shown in FIG5 , the MAC address of host 3 is SMAC, and the MAC address of host 1 is DMAC. Then, the destination MAC address of the message sent by host 3 to host 1 is DMAC and the source MAC address is SMAC. The private network labels assigned by PE1 to PE2 and PE3 are both Label1. The public network label assigned by P1 is LSP1, and the public network label assigned by P2 is LSP2. The transmission process of the message sent by host 3 to host 1 between CE2 and CE1 can be referred to FIG13 , which is a schematic diagram of message transmission in an EVPN over MPLS scenario provided by an embodiment of the present application. Referring to the example shown in FIG2 , when CE2 sends a message with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the message is sent from PE2 to PE1 via P1, the message generated by PE2 will carry the public network label LSP1, the private network label Label1 and the control word (CW), and the control word carries the device identifier of PE2 (CW(PE2)). Accordingly, after PE1 receives a message from PE2, it parses the control word in the message to obtain the device ID of PE2, and then determines that the message is sent by PE2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 will carry the public network label LSP2, the private network label Label1 and the control word, and the control word carries the device ID of PE3. Accordingly, after PE1 receives a message from PE3, it parses the control word in the message to obtain the device ID of PE3, and then determines that the message is sent by PE3. Therefore, PE1 can support traffic statistics that distinguish PEs in the inbound direction.

Optionally, the control word is an 8-byte long control word, 4 bytes of which are used to carry the original control word, and the other 4 bytes of which are used to carry the device identification of device 1. The main idea of this implementation scheme is that device 1 and device 2 negotiate the long control word (LCW) capability, carry the original control word in the upper 4 bytes of the long control word, and carry the device identification of device 1 in the lower 4 bytes of the long control word, so that after the message arrives at device 2, device 2 can determine that the message comes from device 1 using the lower 4 bytes of the long control word.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the device identification of device 1 is set in the lower 4 bytes of the long control word. For example, taking the length of the tag bit field of the capability negotiation extended group attribute as 16 bits (0 to 15 bits), Figure 14 is a schematic diagram of the structure of another capability negotiation extended group attribute provided by an embodiment of the present application. As shown in Figure 14, by setting the 14th bit of the tag bit of the capability negotiation extended group attribute to 1 and the remaining bits to 0, it is indicated that the lower 4 bytes of the long control word in the message are set to the device identification of device 1. In this case, device 1 can generate a message as shown in Figure 9.

For example, in the application scenario shown in Figure 5, the MAC address of host 3 is SMAC, and the MAC address of host 1 is DMAC. The destination MAC address of the message sent by host 3 to host 1 is DMAC, and the source MAC address is SMAC. The private network labels assigned by PE1 to PE2 and PE3 are both Label1. The public network label assigned by P1 is LSP1, and the public network label assigned by P2 is LSP2. The transmission process of the message sent by host 3 to host 1 between CE2 and CE1 can be referred to Figure 15, which is another schematic diagram of message transmission in the EVPN over MPLS scenario provided in an embodiment of the present application. Referring to the example shown in FIG2 , when CE2 sends a message with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the message is sent from PE2 to PE1 via P1, the message generated by PE2 will carry the public network label LSP1, the private network label Label1 and the long control word (LCW), the upper 4 bytes of which carry the original control word (LCW(0)), and the lower 4 bytes of which carry the device identifier of PE2 (LCW(PE2)). Accordingly, after PE1 receives the message from PE2, it parses the lower 4 bytes of the long control word in the message to obtain the device identifier of PE2, and then determines that the message is sent by PE2. If the message is sent from PE3 to PE1 via P2, the message generated by PE3 will carry the public network label LSP2, the private network label Label1, and the long control word (LCW). The upper 4 bytes of the long control word carry the original control word (LCW(0)), and the lower 4 bytes of the long control word carry the device identifier of PE3 (LCW(PE3)). Accordingly, after PE1 receives the message from PE3, it parses the lower 4 bytes of the long control word in the message to obtain the device identifier of PE3, and then determines that the message is sent by PE3. Therefore, PE1 can support traffic statistics that distinguish PEs in the inbound direction.

In the second possible implementation manner of the first implementation scenario, the capability negotiation information sent by device 2 to device 1 is used to negotiate the capability between device 1 and device 1. Device 2 negotiates with device 1 to carry the device identifier of device 1 after the bottom label of the packet.

Optionally, the bottom label is a pre-configured static label, or a dynamic label assigned by device 2, or a specified bSPL. The main idea of this implementation scheme is that device 1 and device 2 negotiate a label indication capability, and the 4 bytes after the bottom label indication label stack carry the device ID of device 1. In this way, after the message arrives at device 2, device 2 can determine that the message comes from device 1 using the 4 bytes after the bottom label.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the stack bottom label is set to the above-mentioned pre-configured static label, or the dynamic label assigned by device 2, or the specified bSPL, and indicates that the device identifier of device 1 is set to the 4 bytes after the stack bottom label. For example, taking the length of the tag bit field of the capability negotiation extended group attribute as 16 bits (0 to 15 bits), Figure 16 is a structural schematic diagram of another capability negotiation extended group attribute provided by an embodiment of the present application. As shown in Figure 16, by setting the 13th bit of the tag bit of the capability negotiation extended group attribute to 1 and the remaining bits to 0, it is indicated that the stack bottom label in the message is set to the specified bSPL, and the 4 bytes after the stack bottom label are set to the device identifier of device 1. In this case, device 1 can generate a message as shown in Figure 10, in which the stack bottom label is the specified bSPL.

For example, in the application scenario shown in FIG5 , the MAC address of host 3 is SMAC, and the MAC address of host 1 is DMAC. Then, the destination MAC address of the message sent by host 3 to host 1 is DMAC and the source MAC address is SMAC. The private network labels assigned by PE1 to PE2 and PE3 are both Label1. The public network label assigned by P1 is LSP1, and the public network label assigned by P2 is LSP2. The transmission process of the message sent by host 3 to host 1 between CE2 and CE1 can be referred to FIG17 , which is another schematic diagram of message transmission in the EVPN over MPLS scenario provided by an embodiment of the present application. Referring to the example shown in FIG2 , when CE2 sends a message with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the message is sent from PE2 to PE1 via P1, the message generated by PE2 will carry the public network label LSP1, the private network label Label1 and a certain bottom-of-stack label (LabelS) mentioned above, and the 4 bytes after the bottom-of-stack label carry the device identifier of PE2 (PE2). Accordingly, after PE1 receives a message from PE2, it parses the stack bottom label of the message to determine that the 4 bytes after the stack bottom label carry a device identifier, and then obtains the device identifier of PE2 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by PE2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 will carry the public network label LSP2, the private network label Label1, and a certain stack bottom label (LabelS) mentioned above, and the 4 bytes after the stack bottom label carry the device identifier of PE3 (PE3). Accordingly, after PE1 receives a message from PE3, it parses the stack bottom label of the message to determine that the 4 bytes after the stack bottom label carry a device identifier, and then obtains the device identifier of PE3 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by PE3. Therefore, PE1 can support traffic statistics that differentiate PEs in the inbound direction.

Optionally, the label at the bottom of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, which is used to indicate that the subsequent adjacent label is the eSPL. The main idea of this implementation scheme is that device 1 and device 2 negotiate an extended label indication capability, and the 4 bytes after the eSPL indication label stack specified at the bottom of the stack carry the device ID of device 1. In this way, after the message arrives at device 2, device 2 can determine that the message comes from device 1 using the 4 bytes after the label at the bottom of the stack.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the stack bottom label is set to a specified eSPL, and indicates that the device identifier of device 1 is set to the 4 bytes after the stack bottom label. For example, taking the length of the tag bit field of the capability negotiation extended group attribute as 16 bits (0 to 15 bits), Figure 18 is a structural schematic diagram of another capability negotiation extended group attribute provided by an embodiment of the present application. As shown in Figure 18, by setting the 12th bit of the tag bit of the capability negotiation extended group attribute to 1 and the remaining bits to 0, it is indicated that the stack bottom label in the message is set to the specified eSPL, and an extension label (XL) is set before the eSPL, and the 4 bytes after the stack bottom label are set to the device identifier of device 1. In this case, device 1 can generate a message as shown in Figure 10, in which the stack bottom label is the specified eSPL.

For example, in the application scenario shown in Figure 5, the MAC address of host 3 is SMAC, and the MAC address of host 1 is DMAC, then the destination MAC address of the message sent by host 3 to host 1 is DMAC, and the source MAC address is SMAC. The private network labels assigned by PE1 to PE2 and PE3 are both Label1. The public network label assigned by P1 is LSP1, and the public network label assigned by P2 is LSP2. The transmission process of the message sent by host 3 to host 1 between CE2 and CE1 can be referred to Figure 19, which is another schematic diagram of message transmission in the EVPN over MPLS scenario provided in an embodiment of the present application. Referring to the example shown in FIG2 , when CE2 sends a message with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the message is sent from PE2 to PE1 via P1, the message generated by PE2 will carry a public network label LSP1, a private network label Label1, an extended label (XL) and a specified eSPL, the eSPL being the bottom label, and the 4 bytes after the bottom label carrying the device identifier of PE2 (PE2). Accordingly, after PE1 receives the message from PE2, it parses the extended label of the message to determine that the extended label carries the eSPL, parses the eSPL as the bottom label to determine that the 4 bytes after the bottom label carry the device identifier, and then obtains the device identifier of PE2 from the 4 bytes after the bottom label, thereby determining that the message is sent by PE2. If the message is sent from PE3 to PE1 via P2, the message generated by PE3 will carry the public network label LSP2, the private network label Label1, the extended label (XL) and the specified eSPL. The eSPL is the bottom label, and the 4 bytes after the bottom label carry the device identifier of PE3 (PE3). Accordingly, after PE1 receives the message from PE3, it parses the extended label of the message to determine that the extended label carries the eSPL, parses the eSPL as the bottom label to determine that the 4 bytes after the bottom label carry the device identifier, and then obtains the device identifier of PE3 from the 4 bytes after the bottom label, thereby determining that the message is sent by PE3. Therefore, PE1 can support the inbound Traffic statistics to different PEs.

In the second implementation scenario, device 1 and device 2 belong to the same L3VPN, that is, device 1 and device 2 are configured with VRF instances belonging to the same L3VPN. In other words, device 1 and device 2 are BGP L3VPN neighbors. This implementation scenario is the above-mentioned MPLS L3VPN scenario. Device 2 can send a BGP L3VPN route to device 1, and the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information. In other words, the capability negotiation information can be published in the L3VPN route. The L3VPN route can carry the NLRI in the BGP message field shown in Figure 11.

In a possible implementation manner under the above-mentioned second implementation scenario, the capability negotiation information sent by device 2 to device 1 is used to negotiate between device 1 and device 2 the capability of carrying the device identifier of device 1 after the bottom label of the stack in the message. Optionally, the bottom label of the stack is a pre-configured static label, or a dynamic label assigned by device 2, or a specified bSPL. Alternatively, the bottom label of the stack is a specified eSPL, and when the label stack of the message carries the eSPL, the label stack also carries a special label, which is used to indicate that the subsequent adjacent label is an eSPL. The specific explanation of this implementation manner can be referred to the second possible implementation manner under the above-mentioned first implementation scenario, and the embodiments of the present application will not be repeated here. It is worth distinguishing that the message transmitted across sites between hosts in the above-mentioned first implementation scenario is a layer 2 message (based on MAC routing), while the message transmitted across sites between hosts in the second implementation scenario is a layer 3 message (based on IP routing).

The sequence of the steps of the message transmission method provided in the embodiment of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. Any technical personnel familiar with the technical field can easily think of a change within the technical scope disclosed in the present application, and all of them should be included in the protection scope of the present application.

FIG20 is a flow chart of another message transmission method provided by an embodiment of the present application, wherein the application scenario of the method includes at least a first device and a second device. For example, the application scenario may be, for example, the application scenario shown in FIG5 , the first device may be, for example, PE2 or PE3 shown in FIG5 , and the second device may be, for example, PE1 shown in FIG5 . The method may be specifically used to implement the method 600 shown in the corresponding embodiment of FIG6 . As shown in FIG20 , the method includes but is not limited to the following steps 2001 to 2002.

Step 2001: A first device generates a message, which includes an MPLS header, a device identifier of the first device, and a message payload, wherein the device identifier is encapsulated between the MPLS header and the message payload.

Step 2002: The first device sends a message to the second device through the LSP established between the first device and the second device.

When the method is specifically used to implement the method 600 shown in Fig. 6, the first device may be, for example, device 1, and the second device may be, for example, device 2. The specific implementation process of steps 2001 to 2002 may refer to steps 601 to 602 in method 600, which will not be repeated here.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the method further includes: the first device receives capability negotiation information sent by the second device, and the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in the message. The specific implementation process of this step can refer to the relevant description in the embodiment shown in Figure 6, and will not be repeated here.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, a method for a first device to receive capability negotiation information sent by a second device includes: the first device receives a BGP EVPN route sent by the second device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, a first device receives capability negotiation information sent by a second device, including: the first device receives the capability negotiation information sent by the second device. The BGP L3VPN route sent by the second device includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry capability negotiation information.

In a specific implementation, the first device is the ingress operator edge device ingress PE, and the second device is the egress operator edge device egress PE.

FIG21 is a flow chart of another message transmission method provided by an embodiment of the present application, wherein the application scenario of the method includes at least a first device and a second device. For example, the application scenario may be, for example, the application scenario shown in FIG5 , the second device may be, for example, PE1 shown in FIG5 , the first device may be, for example, PE2 or PE3 shown in FIG5 , and the third device may be, for example, P1 or P2 shown in FIG5 . The method may be specifically used to implement the method 600 shown in the corresponding embodiment of FIG6 . As shown in FIG21 , the method includes, but is not limited to, the following steps 2101 to 2102.

Step 2101: The second device receives a message sent by a third device through an LSP established between the second device and the first device. The third device is a label switching device located between the first device and the second device on the LSP. The message includes an MPLS header, a device identifier of the first device, and a message payload. The device identifier is encapsulated between the MPLS header and the message payload.

Step 2102: The second device parses the message to obtain the device identification of the first device.

When the method is specifically used to implement the method 600 shown in Fig. 6, the second device may be, for example, device 2, and the first device may be, for example, device 1. The specific implementation process of steps 2101 to 2102 may refer to steps 602 to 603 in method 600, and will not be repeated here.

In a specific implementation, the method further includes: the second device determines that the message comes from the first device according to the device identifier of the first device, so as to perform traffic statistics on the message from the first device. The specific implementation process of this step can refer to step 604 in method 600, which will not be repeated here.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the method further includes: the second device sends capability negotiation information to the first device, and the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in the message. The specific implementation process of this step can be referred to the relevant description in the embodiment shown in Figure 6, and will not be repeated here.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, a method for a second device to send capability negotiation information to a first device includes: the second device sends a BGP EVPN route to the first device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP L3VPN route to the first device, the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

FIG22 is a flow chart of another message transmission method provided by an embodiment of the present application, wherein the application scenario of the method includes at least a first device and a second device. For example, the application scenario may be, for example, the application scenario shown in FIG5 , the first device may be, for example, PE2 or PE3 shown in FIG5 , and the second device may be, for example, PE1 shown in FIG5 . The method may be specifically used to implement the method 600 shown in the corresponding embodiment of FIG6 . As shown in FIG22 , the method includes, but is not limited to, the following steps 2201.

Step 2201: A first device receives capability negotiation information sent by a second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, a method for a first device to receive capability negotiation information sent by a second device includes: the first device receives a BGP EVPN route sent by the second device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, a method for a first device to receive capability negotiation information sent by a second device includes: the first device receives a BGP L3VPN route sent by the second device, the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the first device sends a capability negotiation response to the second device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

FIG23 is a flow chart of another message transmission method provided by an embodiment of the present application, wherein the application scenario of the method includes at least a first device and a second device. For example, the application scenario may be, for example, the application scenario shown in FIG5 , the second device may be, for example, PE1 shown in FIG5 , and the first device may be, for example, PE2 or PE3 shown in FIG5 . The method may be specifically used to implement the method 600 shown in the corresponding embodiment of FIG6 . As shown in FIG23 , the method includes, but is not limited to, the following steps 2301 to 2302.

Step 2301: The second device generates capability negotiation information, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device.

Step 2302: The second device sends the capability negotiation information to the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP EVPN route to the first device, the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the method for the second device to send capability negotiation information to the first device includes: the second device sends a BGP L3VPN route to the first device, and the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information.

In a specific implementation, the first device receives a capability negotiation response sent by the second device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

The following is an example of a virtual device according to an embodiment of the present application.

FIG24 is a schematic diagram of the structure of a message transmission device provided in an embodiment of the present application. The message transmission device is, for example, a first device. As shown in FIG. 24 , the message transmission device 2400 includes but is not limited to a processing module 2401 and a sending module 2402. Optionally, the message transmission device 2400 further includes a receiving module 2403.

The processing module 2401 is used to generate a message, the message includes an MPLS header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The sending module 2402 is used to send a message to the second device through the LSP established between the first device and the second device.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the receiving module 2403 is used to receive capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a message.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the receiving module 2403 is specifically used to receive the BGP EVPN route sent by the second device, and the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module 2403 is specifically used to receive the BGP L3VPN route sent by the second device, and the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

FIG25 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application. The message transmission device is, for example, a first device. As shown in FIG25 , the message transmission device 2500 includes but is not limited to a receiving module 2501 and a processing module 2502. Optionally, the message transmission device 2500 also includes a sending module 2503.

The receiving module 2501 is used to receive a message sent by a third device through an LSP established between the second device and the first device, where the third device is a label switching device located between the first device and the second device on the LSP, and the message includes an MPLS header, a device identifier of the first device, and a message payload, where the device identifier is encapsulated between the MPLS header and the message payload. The processing module 2502 is used to parse the message to obtain the device identifier of the first device.

In a specific implementation, the processing module 2502 is further configured to determine, according to the device identifier of the first device, that the message comes from the first device, so as to perform traffic statistics on the message from the first device.

In a specific implementation, the device identifier of the first device is a router identifier of the first device.

In a specific implementation, the message includes a control word, and the control word is used to carry a device identifier.

In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word.

In a specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label.

In a specific implementation, the sending module 2503 is used to send capability negotiation information to the first device, where the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a message.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the sending module 2503 is specifically used to send a BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module 2503 is specifically used to send a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

FIG26 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application. The message transmission device is, for example, a first device. As shown in FIG26 , the message transmission device 2600 includes but is not limited to a receiving module 2601. Optionally, the message transmission device 2600 also includes a sending module 2602.

The receiving module 2601 is used to receive capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the receiving module 2601 is specifically used to receive a BGP EVPN route sent by a second device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module 2601 is specifically used to receive a BGP L3VPN route sent by a second device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module 2602 is configured to send a capability negotiation response to the second device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

FIG27 is a schematic diagram of the structure of another message transmission device provided in an embodiment of the present application. The message transmission device is, for example, a first device. As shown in FIG27 , the message transmission device 2700 includes but is not limited to a processing module 2701 and a sending module 2702. Optionally, the message transmission device 2700 also includes a receiving module 2703.

The processing module 2701 is used to generate capability negotiation information, which is used to negotiate between the first device and the second device about the capability of carrying the device identifier of the first device in the MPLS message sent by the first device to the second device. The sending module 2702 is used to send the capability negotiation information to the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device in a control word of a message.

In a specific implementation, the control word is a 4-byte control word.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device.

In a specific implementation, the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message.

In a specific implementation, the stack bottom label is a pre-configured static label, or a dynamic label allocated by the first device, or a specified bSPL.

In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL.

In a specific implementation, the sending module 2702 is specifically used to send a BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the sending module 2702 is specifically used to send a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

In a specific implementation, the receiving module 2703 is configured to receive a capability negotiation response sent by the first device.

In a specific implementation, the first device is an inbound operator edge device, and the second device is an outbound operator edge device.

Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

The following is an illustration of the hardware structure involved in the embodiments of the present application.

FIG28 is a block diagram of a message transmission device 2800 provided in an embodiment of the present application. The message transmission device 2800 is a network device. In one implementation, the message transmission device 2800 may be a network edge device. As shown in FIG28 , the device 2800 includes: a processor 2801 and a memory 2802.

Memory 2802, for storing computer readable instructions;

The processor 2801 is used to call the computer-readable instructions and execute all operations performed by the device 1 or the device 2 in the method 600 shown in FIG. 6 according to the instructions of the computer-readable instructions.

In a specific implementation manner, the device 2800 may further include a communication interface 2803. The memory 2802, the processor 2801 and the communication interface 2803 are communicatively connected with each other.

Figure 29 is a block diagram of another message transmission device 2900 provided in an embodiment of the present application. The message transmission device 2900 is a network device. In one implementation, the message transmission device 2900 may be a network edge device. As shown in Figure 29, the device 2900 includes: a communication interface 2901; and a processor 2902 connected to the communication interface 2901. According to the communication interface 2901 and the processor 2902, the message transmission device 2900 can perform all operations performed by device 1 or device 2 in the method 600 shown in Figure 6. Among them, the communication interface 2901 is used to implement the sending and receiving operations, and the processor 2902 is used to implement operations other than sending and receiving. For example, when the device 2900 is the device 1 in the method shown in Figure 6, the communication interface 2901 is used to send a message to the device 2, and the processor 2902 is used to generate a message.

In the embodiment of the present application, the processor may be a central processing unit (CPU). The processor may include one or more processing cores, and the processor executes various functional applications and data processing by running computer programs. The processor may be connected to the memory and the communication interface through a communication bus.

The processor may further include a hardware chip. The hardware chip may be an application specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. In a specific implementation, the hardware chip may be used to implement encryption/decryption operations.

The memory may include volatile memory, such as random access memory (RAM). The memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD). The memory may also include a combination of the above types of memory.

There may be multiple communication interfaces, and the communication interfaces are used to communicate with other devices. The communication interfaces may include wired communication interfaces, wireless communication interfaces, or a combination thereof. Among them, the wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof, etc.

In the above embodiments, all or part of the embodiments may be implemented by hardware, firmware, or any combination thereof. When software is involved in the specific implementation process, it may be embodied in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiments of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., an SSD), etc.

The following is an example of the system of the embodiment of the present application.

The embodiment of the present application further provides a message transmission system, including: a first device and a second device, wherein the first device may be, for example, the device 1 in the method 600 shown in FIG6 , and the second device may be, for example, the device 2 in the method 600 shown in FIG6 . Alternatively, the first device may be, for example, the message transmission device 2400 shown in FIG24 , and the second device may be, for example, the message transmission device 2500 shown in FIG25 . Alternatively, the first device may be, for example, the message transmission device 2600 shown in FIG26 , and the second device may be, for example, the message transmission device 2700 shown in FIG27 .

A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

In the embodiments of the present application, the terms “first”, “second” and “third” are used for descriptive purposes only and should not be understood as indicating or implying relative importance.

The term "and/or" in this application is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character "/" in this article generally indicates that the associated objects before and after are in an "or" relationship.

It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

The above description is only an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the concept and principle of the present application shall be included in the protection scope of the present application.

Claims (37)

A message transmission method, characterized in that the method comprises: The first device generates a message, wherein the message includes a multi-protocol label switching (MPLS) header, a device identifier of the first device, and a message payload, wherein the device identifier is encapsulated between the MPLS header and the message payload; The first device sends the message to the second device. The method according to claim 1 is characterized in that the device identifier of the first device is a router identifier router ID of the first device. The method according to claim 1 or 2 is characterized in that the message includes a control word, and the control word is used to carry the device identification. The method according to claim 1 or 2 is characterized in that the message includes a control word, and the device identifier is adjacent to the control word. The method according to claim 1 or 2 is characterized in that the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label. The method according to any one of claims 1 to 5, characterized in that the method further comprises: The first device receives capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message. The method according to claim 6 is characterized in that the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identification of the first device in a control word of a message. The method according to claim 7 is characterized in that the control word is a 4-byte control word. The method according to claim 7 is characterized in that the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identification of the first device. The method according to claim 6 is characterized in that the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom label of the message. The method according to claim 10 is characterized in that the bottom-of-stack label is a pre-configured static label, or a dynamic label allocated by the second device, or a designated basic special purpose label bSPL. The method according to claim 10 is characterized in that the bottom label of the stack is a specified extended special purpose label eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL. The method according to any one of claims 6 to 12, wherein the first device receives the capability negotiation information sent by the second device, comprising: The first device receives a Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN route sent by the second device, where the BGP EVPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information. The method according to any one of claims 6, 10-12, characterized in that the first device receives the capability negotiation information sent by the second device, comprising: The first device receives a Border Gateway Protocol Layer 3 Virtual Private Network BGP L3VPN route sent by the second device, wherein the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information. The method according to any one of claims 1 to 14 is characterized in that the first device is an ingress operator edge device ingress PE, and the second device is an egress operator edge device egress PE. A message transmission method, characterized in that the method comprises: The second device receives a message sent by a third device through a label switching path LSP established between the second device and the first device, the third device being a label switching device located between the first device and the second device on the LSP, the message comprising a multi-protocol label switching MPLS header, a device identifier of the first device, and a message payload, the device identifier being encapsulated between the MPLS header and the message payload; The second device parses the message to obtain the device identification of the first device. The method according to claim 16, characterized in that the method further comprises: The second device determines, according to the device identifier of the first device, that the message comes from the first device, so as to perform traffic statistics on the message from the first device. The method according to claim 16 or 17 is characterized in that the device identifier of the first device is the router identifier router ID of the first device. The method according to any one of claims 16 to 18 is characterized in that the message includes a control word, and the control word is used to carry the device identification. The method according to any one of claims 16 to 18, characterized in that the message includes a control word, and the device identifier is adjacent to the control word. The method according to any one of claims 16 to 18 is characterized in that the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label. The method according to any one of claims 16 to 21, characterized in that the method further comprises: The second device sends capability negotiation information to the first device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a message. The method according to claim 22 is characterized in that the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identification of the first device in the control word of the message. The method according to claim 23 is characterized in that the control word is a 4-byte control word. The method according to claim 23 is characterized in that the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identification of the first device. The method according to claim 22 is characterized in that the capability negotiation information is used to negotiate between the first device and the second device the capability of carrying the device identifier of the first device after the bottom stack label of the message. The method according to claim 26, characterized in that the bottom label of the stack is a pre-configured static label, or the second device Assigned dynamic label, or designated basic special purpose label bSPL. The method according to claim 26 is characterized in that the bottom label of the stack is a specified extended special purpose label eSPL. When the label stack of the message carries the eSPL, the label stack also carries a special label, and the special label is used to indicate that the subsequent adjacent label is the eSPL. The method according to any one of claims 22 to 28, wherein the second device sends capability negotiation information to the first device, comprising: The second device sends a Border Gateway Protocol Ethernet Virtual Private Network BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information. The method according to any one of claims 22, 26-28, characterized in that the second device sends capability negotiation information to the first device, comprising: The second device sends a Border Gateway Protocol Layer 3 Virtual Private Network BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended group attribute, and the capability negotiation extended group attribute is used to carry the capability negotiation information. The method according to any one of claims 16-30 is characterized in that the first device is an ingress operator edge device (PE), and the second device is an egress operator edge device (PE). A message transmission method, characterized in that the method comprises: The first device receives capability negotiation information sent by the second device, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a Multi-Protocol Label Switching (MPLS) message sent by the first device to the second device. A message transmission method, characterized in that the method comprises: The second device generates capability negotiation information, where the capability negotiation information is used to negotiate between the first device and the second device a capability of carrying a device identifier of the first device in a multi-protocol label switching MPLS message sent by the first device to the second device; The second device sends the capability negotiation information to the first device. A message transmission system, characterized in that it includes: a first device and a second device, the first device is used to execute the method as claimed in any one of claims 1 to 15, and the second device is used to execute the method as claimed in any one of claims 16 to 31; or, the first device is used to execute the method as claimed in claim 32, and the second device is used to execute the method as claimed in claim 33. A network device, comprising: a communication interface; and a processor connected to the communication interface; According to the communication interface and the processor, the method according to any one of claims 1 to 33 is implemented. A computer-readable storage medium, characterized in that instructions are stored on the computer-readable storage medium, and when the instructions are executed by a processor, the method described in any one of claims 1 to 33 is implemented. A computer program product, characterized in that it comprises a computer program, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 33.