Packet transmission method and apparatus, and system

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

[0001] This application claims priority to Chinese patent application number 202310638085.5, filed on May 31, 2023, entitled “Message Transmission Method, Device and System,” the entire contents of which are incorporated herein by reference. Technical Field

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

[0003] Traffic statistics are a fundamental function of communications networks. By collecting statistics on network traffic, the quality and health of network operations 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 that use multiprotocol label switching (MPLS) technology for forwarding, such as Ethernet virtual private networks (EVPN) over MPLS and Layer 3 virtual private networks (L3VPN) over MPLS, it is difficult to accurately collect network traffic statistics on network devices.

[0004] Summary of the Invention

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

[0006] In a first aspect, a message transmission method is provided. The method includes: a first device generating a message, the message including 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. The first device sends the message to a second device via a label switched path (LSP) established between the first and second devices.

[0007] 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 where forwarding is based on MPLS technology. 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.

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

[0009] In one specific implementation, the message includes a control word that carries the device identifier. This implementation does not require changing the original MPLS message format; it 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.

[0010] In a specific implementation, the message includes a control word, and the device identifier is adjacent to the control word. This implementation does not require changing the original control word and does not affect the function of the original control word.

[0011] In one specific implementation, the bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the bottom label. In one 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 can collectively 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 collectively indicate that the device identifier is adjacent to the bottom label.

[0012] 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.

[0013] In this application, the first device and the second device can implement capability negotiation to enable the first device's device identifier to be carried in a message sent from the first device to the second device. Alternatively, the first device's ability to carry the first device's device identifier in a generated message and the second device's ability to parse the device identifier in a received message can also be manually configured.

[0014] 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.

[0015] In one specific implementation, the control word is a 4-byte control word. This 4-byte control word carries the device identification of the first device. The main idea of ​​this implementation is that the first device and the second device negotiate control word capabilities. By carrying the device identification of the first device in the control word, when a message reaches the second device, the second device can use the control word information to determine that the message originated from the first device.

[0016] In one specific implementation, the control word is an 8-byte long control word, 4 bytes of which are used to carry the original control word, and the remaining 4 bytes of which are used to carry the device identifier of the first device. In another 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 identifier of the first device. The main idea of ​​this implementation scheme is that the first device and the second device negotiate long control word capabilities, with the upper 4 bytes of the long control word carrying the original control word and the lower 4 bytes of the long control word carrying the device identifier of the first device. In this way, after the message reaches 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.

[0017] In another 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 packet.

[0018] In one specific implementation, the bottom label is a preconfigured static label, a dynamic label assigned by the second device, or a designated base special-purpose label (bSPL). The key concept behind this implementation is that the first and second devices negotiate a label indication capability, where the bottom label indicates the first device's device identifier in the four bytes following the label stack. This allows the second device to determine that the message originated from the first device using the four bytes following the bottom label.

[0019] In one specific implementation, the bottom label is a designated extended special-purpose label (eSPL). When the message's label stack carries the eSPL, the label stack also carries a special label that indicates that the subsequent adjacent label is the eSPL. The key concept behind this implementation is that a first device and a second device negotiate an extended label indication capability. The four bytes following the eSPL designated at the bottom of the stack indicate the first device's device identifier. This allows the second device to determine that the message originated from the first device using the four bytes following the bottom label.

[0020] In a specific implementation, the first device receives capability negotiation information sent by the 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 capability negotiation information.

[0021] This application can be applied to EVPN over MPLS scenarios, and capability negotiation information can be advertised in BGP EVPN routes.

[0022] In a specific implementation, the first device receives capability negotiation information sent by the 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 community attribute, and the capability negotiation extended community attribute is used to carry capability negotiation information.

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

[0024] In one specific implementation, the first device sends a capability negotiation response to the second device. The capability negotiation response indicates that the first device is capable of carrying the first device's device identifier in the message. This allows the second device to clearly know whether the first device is capable of carrying the device identifier in the message, thereby improving the reliability of capability negotiation.

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

[0026] In a second aspect, a message transmission method is provided. The method includes: a second device receiving a message sent by a third device via an LSP established between the second device and a first device, where 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, with the device identifier encapsulated between the MPLS header and the message payload. The second device parses the message to obtain the device identifier of the first device.

[0027] 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.

[0028] In the present application, since the message received by the second device carries the device identifier of the first device, the second device can obtain the device identifier of the first device by parsing the message and determine that the message was sent by the first device based on the device identifier 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 network scenarios that forward based on MPLS technology. 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.

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

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

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

[0032] 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.

[0033] 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 about the capability of carrying the device identifier of the first device in a message.

[0034] 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.

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

[0036] 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.

[0037] In another 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 packet.

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

[0039] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0040] In a specific implementation, the second device sends capability negotiation information to the first device, including: the second device sends a BGP EVPN route to the first 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.

[0041] In a specific implementation, the second device sends capability negotiation information to the first device by sending a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information.

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

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

[0044] 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.

[0045] In the present application, the first device and the second device negotiate capabilities so that the message sent from the first device to the second device carries the device identifier of the first device.

[0046] 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.

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

[0048] 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.

[0049] In another 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 packet.

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

[0051] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0052] In a specific implementation, the implementation method of the first device receiving the capability negotiation information sent by the second device includes: the first device receives the 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.

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

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

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

[0056] In a fourth aspect, a message transmission method is provided. The method includes: a second device generating capability negotiation information, the capability negotiation information being used to negotiate between a first device and a 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; and the second device sending the capability negotiation information to the first device.

[0057] 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.

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

[0059] 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.

[0060] In another 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 packet.

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

[0062] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0063] In a specific implementation, the second device sends capability negotiation information to the first device, including: the second device sends a BGP EVPN route to the first 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.

[0064] In a specific implementation, the second device sends capability negotiation information to the first device by sending a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information.

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

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

[0067] In a fifth aspect, a first device is provided. The first device includes multiple functional modules that interact with each other to implement the method of the 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 the specific implementation. 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.

[0068] The processing module is configured to generate a message, wherein the message 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. The sending module is configured to send the message to the second device via the LSP established between the first device and the second device.

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

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

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

[0072] 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.

[0073] In a specific implementation, the receiving module is configured 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.

[0074] 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.

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

[0076] 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.

[0077] 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 packet.

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

[0079] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0080] In a specific implementation, the receiving module is specifically configured to receive a 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 capability negotiation information.

[0081] In a specific implementation, the receiving module is specifically configured 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.

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

[0083] In a sixth aspect, a second device is provided. The second device includes multiple functional modules that interact with each other to implement the method of the second 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 and a processing module. In a specific implementation, the multiple functional modules also include a sending module.

[0084] The receiving module is configured to receive a message sent by a third device via 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, with the device identifier encapsulated between the MPLS header and the message payload. The processing module is configured to parse the message to obtain the device identifier of the first device.

[0085] In a specific implementation, the processing module is further configured to determine, based on 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.

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

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

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

[0089] 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.

[0090] In a specific implementation, the sending module is configured 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.

[0091] 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.

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

[0093] 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.

[0094] 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 packet.

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

[0096] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0097] In a specific implementation, the sending module is specifically configured to send a BGP EVPN route to the first device, where 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.

[0098] In a specific implementation, the sending module is specifically configured to send a BGP L3VPN route to the first 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.

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

[0100] In a seventh aspect, a first device is provided. The first device includes multiple functional modules that interact with each other to implement the method of 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.

[0101] The receiving module is configured 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 the device identifier of the first device in an MPLS message sent by the first device to the second device.

[0102] 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.

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

[0104] 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.

[0105] 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 packet.

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

[0107] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0108] In a specific implementation, the receiving module is specifically configured to receive a 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 capability negotiation information.

[0109] In a specific implementation, the receiving module is specifically configured 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.

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

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

[0112] In an eighth aspect, a second device is provided. The second device includes multiple functional modules that interact with each other to implement the method of the fourth 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 processing module and a sending module. In a specific implementation, the multiple functional modules also include a receiving module.

[0113] The processing module is configured to generate capability negotiation information for negotiating between the first device and the second device on the capability of carrying the device identifier of the first device in an MPLS message sent by the first device to the second device. The sending module is configured to send the capability negotiation information to the first device.

[0114] 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.

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

[0116] 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.

[0117] 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 packet.

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

[0119] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0120] In a specific implementation, the sending module is specifically configured to send a BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extended community attribute, where the capability negotiation extended community attribute is used to carry capability negotiation information.

[0121] In a specific implementation, the sending module is specifically configured to send a BGP L3VPN route to the first 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.

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

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

[0124] 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.

[0125] In a tenth aspect, a network device is provided, comprising: a communication interface; and a processor connected to the communication interface. The method of the first aspect or any possible implementation of the first aspect, the method of the second aspect or any possible implementation of the second aspect, the method of the third aspect or any possible implementation of the third aspect, or the method of the fourth aspect or any possible implementation of the fourth aspect are implemented based on the communication interface and the processor.

[0126] 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.

[0127] In the twelfth aspect, a computer program product is provided, comprising a computer program, which, when executed by a processor, 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.

[0128] 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

[0129] FIG1 is a schematic diagram of publishing a MAC address in an EVPN over MPLS scenario in the related art;

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

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

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

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

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

[0135] FIG7 is a schematic diagram of the structure of an MPLS message provided in an embodiment of the present application;

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

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

[0138] FIG10 is a schematic diagram of the structure of another MPLS message provided in an embodiment of the present application;

[0139] FIG11 is a schematic diagram of the structure of a BGP update message provided in an embodiment of the present application;

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

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

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

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

[0144] FIG16 is a schematic structural diagram of another capability negotiation extended group attribute provided in an embodiment of the present application;

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

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

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

[0148] FIG20 is a flow chart of another message transmission method provided in an embodiment of the present application;

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

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

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

[0152] FIG24 is a schematic structural diagram of a message transmission device provided in an embodiment of the present application;

[0153] FIG25 is a schematic structural diagram of another message transmission device provided in an embodiment of the present application;

[0154] FIG26 is a schematic structural diagram of another message transmission device provided in an embodiment of the present application;

[0155] FIG27 is a schematic structural diagram of another message transmission device provided in an embodiment of the present application;

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

[0157] Figure 29 is a block diagram of another message transmission device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0159] Currently, hosts located at different sites can communicate across sites. A site can be considered a local area network (LAN), which can be a single-subnet LAN or a multi-subnet LAN. Different sites can be deployed in different regions. A site can contain one or more hosts. A host is a terminal device with a client installed, such as a smartphone, tablet, desktop computer, Internet of Things (IoT) device, network equipment, workstation, or server.

[0160] Hosts within a site typically 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 typically configured with an intranet address. Because intranet addresses of different private networks can overlap, the intranet address configured for hosts within a private network can generally only be used for communication within that private network. Private networks can be deployed across sites, meaning that a single private network can include multiple hosts deployed at different sites. For example, a private network is deployed across Site A and Site B, connected by a carrier network. This 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 (VPNs). For a private network, hosts deployed within the private network are considered intranet hosts, while the carrier network and other private networks are considered external networks. 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 an enterprise's private network. The enterprise network at a certain site is called the enterprise's internal network. The enterprise's multiple networks deployed at multiple sites are called the enterprise's private network or multi-site private network.

[0161] For a private network distributed across multiple sites, if an intranet host at one site wants to send a message to an intranet host at another site, the message must be transmitted through the external network between the two sites. The intranet host at one site needs to communicate with the external network through the edge access device at that site. The edge access device at a 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 at each site is connected to a provider edge (PE) device. When an intranet host at one site sends a message to an intranet host at another site, the message first arrives at the CE device at the local site, is then transmitted by the CE device at the local site to the connected PE device, and then the message is transmitted via the operator network to the remote PE device. The remote PE device then transmits the message to the CE device at the remote site, and finally the CE device at the remote site transmits the message to the intranet host at the remote site.

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

[0163] EVPN is a VPN technology used for Layer 2 network interconnection. EVPN has been widely adopted in recent years because it addresses the lack of support for dual-homing load balancing in traditional virtual private LAN (VPLS) services, avoids the drawbacks of fully connected public network pseudowires (PWs), and achieves rapid routing convergence. VPLS is a Layer 2 VPN technology based on MPLS and Ethernet technologies. Unlike traditional Layer 2 virtual private networks (L2VPNs), which learn MAC addresses through the forwarding plane, EVPN introduces a control plane. By extending the Multiprotocol Border Gateway Protocol (MP-BGP), EVPN shifts the MAC address distribution process between Layer 2 networks at different sites from the forwarding plane to the control plane. Compared to traditional L2VPNs, EVPN differs in some functionality due to differences in implementation principles. In EVPN over MPLS scenarios, MAC routes are transmitted to remote PE devices via the control plane.

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

[0165] For example, Figure 1 is a schematic diagram of MAC address issuance in an EVPN over MPLS scenario in the related art. Figure 2 is a schematic diagram of message transmission in an EVPN over MPLS scenario in the related art. Figure 3 is a schematic diagram of IP address issuance in an MPLS L3VPN scenario in the related art. Figure 4 is a schematic diagram of message transmission in an MPLS L3VPN scenario in the related art. In the scenarios shown in Figures 1 to 4, the operator network includes three PE devices, PE1 to PE3, and two provider (P) devices, P1 and P2. The P devices are not shown in Figures 1 and 3. 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 for CE2.

[0166] 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 assigns a private network label, Label1, and sends it to remote PE2 and PE3. As shown in Figure 2, CE2 sends a Layer 2 packet to CE1 with a destination MAC address, DMAC (for example, MAC1), and a source MAC address, SMAC. If this packet is sent from PE2 to PE1 via P1, PE2 generates an MPLS packet consisting of an MPLS header and a payload. The MPLS header includes the public network label, LSP1, assigned by P1, and the private network label, Label1, assigned by PE1. The Layer 2 packet sent by CE2 is encapsulated in this payload. After receiving the MPLS packet from PE2, P1 removes the public network label, LSP1, and continues to send the MPLS packet to PE1. The message received by PE1 ultimately includes an MPLS header and a payload. The MPLS header includes the private network label Label1 assigned by PE1. If this message is sent from PE3 to PE1 via P2, PE3 generates an MPLS message. This MPLS message includes an MPLS header and a 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 this payload. After receiving the MPLS message from PE3, P2 can remove the public network label LSP2 and continue sending the MPLS message to PE1. The message received by PE1 ultimately includes an MPLS header and a payload. The MPLS header includes the private network label Label1 assigned by PE1. In other words, regardless of 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 received by PE1 is Label1. Therefore, PE1 cannot distinguish whether the inbound traffic originates from PE2 or PE3. The packet structure shown in Figure 2 is only for illustrative purposes. In practice, the MPLS packet received by PE1 may also include an encapsulated outer MAC header before the MPLS header. The private network label is also called a VPN label, and the public network label is also called an LSP label.

[0167] For ease of understanding, only one P device is shown between PE devices in the scenarios shown in Figures 2 and 4. Those skilled in the art will appreciate that multiple P devices may be included between PE devices. The MPLS technology described herein may be a traditional MPLS technology or a segment routing (SR) MPLS technology based on the MPLS forwarding plane (abbreviated as SR-MPLS).

[0168] In the scenarios shown in Figures 3 and 4, PE1, PE2, and PE3 establish BGP L3VPN peer relationships with each other. As shown in Figure 3, after PE1 learns IP1 from CE1, it assigns a private network label, Label2, and sends it to remote PE2 and PE3. As shown in Figure 4, CE2 sends a Layer 3 packet to CE1 with the destination IP address (for example, IP1) and the source IP address (the source IP). If this packet is sent from PE2 to PE1 via P1, PE2 generates an MPLS packet consisting of an MPLS header and a payload. The MPLS header includes the public network label LSP1 assigned by P1 and the private network label Label2 assigned by PE1. The Layer 3 packet sent by CE2 is encapsulated in this payload. After receiving the MPLS packet from PE2, P1 removes the public network label LSP1 and continues to send the MPLS packet to PE1. The packet received by PE1 ultimately includes an MPLS header and a payload. The MPLS header includes the private network label Label2 assigned by PE1. If this packet is sent from PE3 to PE1 via P2, PE3 generates an MPLS packet. This MPLS packet includes an MPLS header and a payload. The MPLS header includes the public network label LSP2 assigned by P2 and the private network label Label2 assigned by PE1. The Layer 3 packet sent by CE2 is encapsulated in this payload. After receiving the MPLS packet from PE3, P2 can remove the public network label LSP2 and continue sending the MPLS packet to PE1. The packet received by PE1 ultimately includes an MPLS header and a payload. The MPLS header includes the private network label Label2 assigned by PE1. In other words, regardless of whether the Layer 3 packet sent by CE2 to CE1 is forwarded by PE2 or PE3, the private network label carried by the MPLS packet received by PE1 is Label2. Therefore, PE1 cannot distinguish whether the inbound traffic originates from PE2 or PE3. The message structure shown in FIG4 is only used for exemplary description. In practice, the MPLS message received by PE1 may further include an encapsulated outer MAC header before the MPLS header.

[0169] As can be seen from the above, in some network scenarios that currently use 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 whereby, when a network device generates a message, it encapsulates the device identifier of the network device between the MPLS header and the payload of the message, and then sends the generated message to other network devices via the LSP established between the network device and the other network devices. Since the message received by the other network devices carries the device identifier of the network device, the other network devices can parse the message to obtain the device identifier of the network device, and determine that the message was sent by the network device based on the device identifier, thereby achieving accurate statistics of network traffic in the inbound direction.

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

[0171] The following examples illustrate the application scenarios involved in the embodiments of the present application.

[0172] The application scenarios of the present application include a communication network and a site accessing 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.

[0173] The communication network provided by the present application includes multiple network devices for service forwarding, and the multiple network devices are communicatively connected. Each network device can 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 can be a switch, a router or a gateway, etc. The embodiment of the present application is explained 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.

[0174] 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 an MPLS VPN) and two CE devices, CE1 and 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 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 for CE2. CE1 is the edge access device at site 1, used to connect host 1 and host 2 at site 1 to the communication network. CE2 is the edge access device at site 2, used to connect host 3 and host 4 at site 2 to the communication network. The application scenario shown in Figure 5 can be the application scenario shown in Figure 1 or Figure 2, in which case the MPLS VPN is EVPN over MPLS. Alternatively, the application scenario shown in FIG. 5 may be the application scenario shown in FIG. 3 or FIG. 4 , and the MPLS VPN is an MPLS L3VPN.

[0175] 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 that a BGP peer relationship is 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 connected to each other through the route reflector. 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, which is an 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.

[0176] Optionally, one or more forwarding instances are configured in the PE device in the communication network. Different forwarding instances in the same device operate independently to achieve route isolation. In an 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 (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 (BDs). Alternatively, the forwarding instance in the PE device can also be a Layer 3 forwarding instance, also known as a virtual routing forwarding (VRF) instance (corresponding to a Layer 3 forwarding domain), and the Layer 3 forwarding instance can publish IP routes. Each forwarding instance is configured with a route target, also known as a vpn-target. Route target is a BGP extended community attribute, and each forwarding instance needs to be configured with two types of route targets, one in the outbound direction and one inbound direction. Only when the outbound route target value configured for the local forwarding instance is equal to the inbound route target value configured for the peer forwarding instance can the local and peer ends exchange BGP routes with each other. In the embodiments of the present application, if two PE devices that are BGP EVPN neighbors are configured with an EVI belonging to the same EVPN, then the two PE devices can also be said to belong to the same EVPN. If two PE devices that are BGP L3VPN neighbors are configured with a VRF instance belonging to the same L3VPN, then the two PE devices can also be said to belong to the same L3VPN.

[0177] 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 multiple 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 that 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 that 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 that 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.

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

[0179] For example, Figure 6 is a flow chart of a message transmission method provided by an embodiment of the present application. As shown in Figure 6, method 600 includes steps 601 to 604. Device 1 and device 2 in method 600 are respectively 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 a carrier network, device 1 in method 600 is an ingress carrier edge device (ingress PE), and device 2 in method 600 is an egress carrier 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, method 600 can be applied to the application scenario shown in Figure 5. 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 .

[0180] 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.

[0181] 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 the inner layer message of the MPLS message. The inner layer message can be a Layer 2 message or a Layer 3 message, typically the original data message sent by the 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 referred to as the message header of the MPLS message.

[0182] Optionally, the device identification of device 1 is the router identification (router ID) of device 1. Alternatively, the device identification of device 1 may also be 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 may be 2 bytes, 4 bytes, 6 bytes, or 8 bytes, etc. 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 using the length of the device identification as 4 bytes as an example.

[0183] 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. 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.

[0184] Optionally, the device identifier of device 1 can be set at different locations within the MPLS message. The present application embodiment illustrates the following three possible implementations. The location where the device identifier is set within the MPLS message can be defined in a protocol or standard. Alternatively, the network edge devices can negotiate to determine the location where the device identifier is set within the MPLS message.

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

[0186] 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 4-byte control word. 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.

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

[0188] Optionally, the bottom label can independently indicate that the device identifier following the bottom label is device 1. For example, the bottom label can be a preconfigured static label, a dynamic label assigned by device 2, or a designated basic special purpose label (bSPL). If the bottom label is a preconfigured static label, both device 1 and device 2 are preconfigured with the same static label. The static label preconfigured by device 1 is carried at the bottom of the label stack in packets sent to device 2, indicating that the static label carries the device identifier of device 1. The static label preconfigured by device 2 is used to parse the bottom label of packets received by device 2 to determine whether the bottom label carries the device identifier of the device sending the packet. If the bottom label is a dynamic label assigned by device 2, device 2 can generate the dynamic label and send it to device 1. If the bottom label is a designated bSPL, the designated bSPL can be defined in a standard or protocol. For example, the standard or protocol defines that when the bSPL value of the bottom label is a designated label value, it indicates that the bottom label carries the device identifier. The embodiment of the present application does not limit the specific value of the specified tag value.

[0189] 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, if 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. In other words, 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 can be an extension label (XL) with a label value of 15. In the case where the bottom label of the stack is a designated eSPL, the designated eSPL can be defined in a standard or protocol. For example, the standard or protocol defines that when the eSPL as the bottom label takes a designated label value, it indicates that the bottom label of the stack carries a device identifier. Optionally, the value range of eSPL is 16 to 1048, and any label value therein can be defined as the designated label value. The embodiment of the present application does not limit the specific value of the designated label value.

[0190] In the EVPN over MPLS scenario, the message payload of the MPLS message transmitted between the network devices in the communication network is a Layer 2 message. In order 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, and 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 in the communication network (such as P devices) from mistakenly identifying the Layer 2 message as an IPv4 message or an IPv6 message, thereby performing incorrect load sharing and causing message disorder. For a specific explanation of the definition and function of the control word, please refer to the request for comments (RFC) numbered 7432 (abbreviated as: RFC 7432) document, which will not be repeated here in the embodiments of the present application.

[0191] Optionally, when device 1 and device 2 are BGP EVPN neighbors, if CW capability has been negotiated between device 1 and device 2, device 1 may use the first or second possible implementation method to carry the device identifier of device 1 in the message. Alternatively, device 1 may use the third possible implementation method to carry the device identifier of device 1 in the message. When device 1 uses the first possible implementation method, 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 a value other than 4 and 6, so as to prevent intermediate network devices 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).

[0192] 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 and MPLS L3VPN scenarios.

[0193] Step 602: Device 1 sends the message to Device 2 via the LSP established between Device 1 and Device 2.

[0194] Taking the application scenario shown in Figure 5 as an example, assume that host 3 at site 2 and host 1 at 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 sequentially pass through CE2, the MPLS VPN network, and CE1, ultimately reaching host 1. There are four transmission paths from CE2 to CE1 in the MPLS VPN network: 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. Assume that device 2 is PE1 in the application scenario shown in Figure 5, and device 1 is PE2 in the application scenario shown in Figure 5. After receiving the data packet sent by CE2, PE2 generates an MPLS packet containing the data packet. PE2 then sends the generated MPLS packet to PE1. The MPLS packet can be transmitted via either transmission path 1 or transmission path 2.

[0195] 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.

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

[0197] 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.

[0198] 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.

[0199] In conjunction with the second possible implementation of step 601, device 2 obtains the device ID of device 1 by parsing the field adjacent to the control word in the message. For example, device 2 can parse the 4 bytes adjacent to the control word in the message to obtain the device ID of device 1.

[0200] In conjunction with the third possible implementation of step 601, device 2 first parses the label stack of the message. 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 following the bottom label to obtain the device identifier of device 1. For example, device 2 may parse the 4 bytes following the bottom label in the message to obtain the device identifier of device 1.

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

[0202] Because the message received by device 2 carries the device identifier of device 1, device 2 can determine that the message comes from device 1. This allows traffic statistics to be collected for messages from device 1. Referring to the example in step 602 above, for PE1, after receiving an MPLS message sent by P1 or P2, PE1 can only determine whether the MPLS message comes from PE2 or PE3 based on the VPN label in the MPLS message. However, the device identifier of PE2 carried in the MPLS message allows it to clearly determine that the MPLS message comes from PE2. In other words, PE1 can distinguish whether the traffic comes from PE2 or PE3, thereby enabling accurate statistics of network traffic in the inbound direction.

[0203] 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.

[0204] In the message transmission method provided in an embodiment of the present application, when a network device generates a message, it encapsulates its device identifier between the MPLS header and the message payload, and then sends the generated message to other network devices. Because the message received by the other network device carries the device identifier of the network device, the other network device can parse the message to obtain the device identifier and, based on the device identifier, determine that the message was sent by the network device. This enables accurate network traffic statistics in MPLS-based forwarding scenarios, such as EVPN over MPLS or MPLS L3VPN scenarios.

[0205] Optionally, the ability of device 1 to carry the device identifier of device 1 in the generated MPLS message and the ability of device 2 to parse the device identifier in the received MPLS message can be manually configured. Alternatively, the ability to carry the device identifier of device 1 in the message can also be negotiated between device 1 and device 2. For example, before the above-mentioned step 601 is executed, device 2 generates capability negotiation information, which is used to negotiate between device 1 and device 2 on the ability to carry 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 ability 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.

[0206] 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 identifier of device 1 in the message. In this way, device 2 can clearly know whether device 1 has the capability to carry the device identifier in the message, which can improve the reliability of capability negotiation.

[0207] 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 identifier 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 identifier 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 identifier. If the control word of the message is not all 0, device 2 determines that the control word of the message is the device identifier of the network edge device that sent the message.

[0208] Optionally, the capability negotiation information sent by device 2 to device 1 is carried in a 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 explained by taking the example of carrying capability negotiation information in an extended group attribute of a BGP update message. In the embodiments of the present application, the extended group attribute that carries capability negotiation information is referred to as a capability negotiation extended group attribute.

[0209] For example, Figure 11 is a structural diagram of a BGP update message provided in an embodiment of the present application. As shown in Figure 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, network layer reachability information (NLRI), a capability negotiation extended community attribute, and other path attributes. Among them, the address family identifier, subsequent address family identifier, next-hop network address length, next-hop network address, reserved field and NLRI are collectively referred to as the Multi-Protocol Reachable NLRI (MP_REACH_NLRI) attribute. Optionally, the capability negotiation extended community attribute includes a type field, a subtype field, a flag bit field and a reserved field. It can be defined that when the type field and subtype field of the extended community attribute are certain values, it indicates that the extended community attribute is a capability negotiation extended community attribute, that is, the extended community attribute carries the above-mentioned capability negotiation information. In addition, the flag bit field of the capability negotiation extended community attribute can be used to indicate the setting position of the device identifier in the message. Different bits of the flag 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 definitions in the RFC 4760 document, and the embodiments of the present application will not be repeated here.

[0210] In the first implementation scenario, Device 1 and Device 2 belong to the same EVPN. Specifically, Device 1 and Device 2 are configured with the same EVI instance. In other words, Device 1 and Device 2 are BGP EVPN neighbors. This implementation scenario is the aforementioned EVPN over MPLS scenario. Device 2 can send a BGP EVPN route to Device 1. This BGP EVPN route includes the Capabilities Negotiation Extended Community attribute, which carries capability negotiation information. In other words, capability negotiation information can be advertised in BGP EVPN routes.

[0211] 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 (i.e., 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 Layer 2 routing information and / or 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 routes are used to establish BUM (broadcast, unknown unicast, multicast) trees between network edge devices (such as PEs). Of course, the aforementioned BGP EVPN routes may also be other types of routes defined in the BGP NLRI, or may be other types of routes subsequently evolved. The present embodiment does not limit the type of BGP EVPN routes. BGP EVPN routes may carry the NLRI in the BGP message field shown in FIG11 .

[0212] In a first possible implementation manner under the first implementation scenario described above, 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.

[0213] Optionally, the control word is a 4-byte control word. This 4-byte control word carries the device identification of device 1. The main idea of ​​this implementation is that device 1 and device 2 negotiate control word capabilities. By carrying the device identification of device 1 in the control word, when a message arrives at device 2, device 2 can use the control word information to determine that the message comes from device 1.

[0214] 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 structural diagram 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.

[0215] 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 label assigned by PE1 to PE2 and PE3 is 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 seen in Figure 13, 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 Figure 2, 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). 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 PE2's device ID, thereby confirming that the message was 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 control word, which carries PE3's device ID. Accordingly, after PE1 receives a message from PE3, it parses the control word in the message to obtain PE3's device ID, thereby confirming that the message was sent by PE3. Therefore, PE1 can support PE-specific traffic statistics in the inbound direction.

[0216] Optionally, the control word is an 8-byte long control word, where 4 bytes of the long control word are used to carry the original control word, and the remaining 4 bytes of the long control word are used to carry the device identifier of device 1. The main idea of ​​this implementation is that device 1 and device 2 negotiate long control word (LCW) capabilities, with the upper 4 bytes of the long control word carrying the original control word and the lower 4 bytes of the long control word carrying the device identifier of device 1. In this way, when a message arrives at device 2, device 2 can use the lower 4 bytes of the long control word to determine that the message comes from device 1.

[0217] Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the device identifier 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 structural diagram 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 identifier of device 1. In this case, device 1 can generate a message as shown in Figure 9.

[0218] 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 label assigned by PE1 to PE2 and PE3 is 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 seen in Figure 15, which is another schematic diagram of message transmission in an EVPN over MPLS scenario provided in an embodiment of the present application. Referring to the example shown in Figure 2, 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 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 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 was 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 was sent by PE3. Therefore, PE1 can support traffic statistics for different PEs in the inbound direction.

[0219] In a second possible implementation manner of the first implementation scenario, the capability negotiation information sent by device 2 to device 1 is used to negotiate between devices 1 and 2 the capability of carrying the device identifier of device 1 after the bottom label of the packet.

[0220] Optionally, the bottom label is a preconfigured static label, a dynamic label assigned by device 2, or a specified bSPL. The key concept behind this implementation is that device 1 and device 2 negotiate a label indication capability, where the 4 bytes following the bottom label indicate the label stack and carry the device ID of device 1. This allows device 2 to determine that the packet originated from device 1 using the 4 bytes following the bottom label.

[0221] 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 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.

[0222] 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 label assigned by PE1 to PE2 and PE3 is 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 seen in Figure 17, which is another 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 Figure 2, 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 one of the aforementioned bottom-of-stack labels (LabelS). The 4 bytes following the bottom-of-stack label carry the device identifier of PE2 (PE2). Accordingly, after receiving a packet from PE2, PE1 parses the packet's bottom label to determine that the 4 bytes following the bottom label carry a device identifier. It then obtains PE2's device identifier from the 4 bytes following the bottom label, thereby confirming that the packet was sent by PE2. If the packet is sent from PE3 to PE1 via P2, the packet generated by PE3 will carry the public network label LSP2, the private network label Label1, and one of the aforementioned bottom labels (LabelS). The 4 bytes following the bottom label carry PE3's device identifier (PE3). Accordingly, after receiving a packet from PE3, PE1 parses the packet's bottom label to determine that the 4 bytes following the bottom label carry a device identifier. It then obtains PE3's device identifier from the 4 bytes following the bottom label, thereby confirming that the packet was sent by PE3. Therefore, PE1 can support PE-specific traffic statistics in the inbound direction.

[0223] Optionally, the bottom label in the stack is a designated eSPL. When the packet's label stack carries this eSPL, the label stack also carries a special label that indicates that the subsequent adjacent label is the eSPL. The key idea behind this implementation is that Device 1 and Device 2 negotiate an extended label indication capability. The four bytes following the designated eSPL at the bottom of the stack indicate the device identifier of Device 1. When a packet arrives at Device 2, Device 2 can use the four bytes following the bottom label to determine that the packet originated from Device 1.

[0224] 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 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.

[0225] 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 label assigned by PE1 to PE2 and PE3 is 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 seen in Figure 19, which is another schematic diagram of message transmission in an EVPN over MPLS scenario provided in an embodiment of the present application. Referring to the example shown in Figure 2, when CE2 sends a message to CE1 with a destination MAC address of DMAC and a source MAC address of SMAC, 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, the extended label (XL), and the specified eSPL. The eSPL is the bottom label, and the 4 bytes following the bottom label carry the device identifier of PE2 (PE2). Accordingly, after receiving the message from PE2, PE1 parses the extended label of the message to determine that it carries the eSPL. It then parses the eSPL as the bottom label to determine that the 4 bytes following the bottom label carry the device identifier. It then obtains the device identifier of PE2 from the 4 bytes following the bottom label, thereby determining that the message was 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 following the bottom label carry PE3's device identifier (PE3). Accordingly, after receiving the message from PE3, PE1 parses the extended label in the message to determine that it carries the eSPL. It then parses the eSPL, which is the bottom label, to determine that the 4 bytes following the bottom label carry the device identifier. It then obtains PE3's device identifier from the 4 bytes following the bottom label, thereby confirming that the message was sent by PE3. Therefore, PE1 can support PE-specific traffic statistics in the inbound direction.

[0226] 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 same as the MPLS L3VPN scenario described above. Device 2 can send a BGP L3VPN route to Device 1. This BGP L3VPN route includes a capability negotiation extended community attribute, which is used to carry capability negotiation information. In other words, capability negotiation information can be advertised in the L3VPN route. The L3VPN route can carry the NLRI in the BGP message field shown in Figure 11.

[0227] In a possible implementation method 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 in the message. Optionally, the bottom label is a pre-configured static label, or a dynamic label assigned by device 2, or a specified bSPL. Alternatively, the bottom label 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 method can be referred to the second possible implementation method 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 messages transmitted between hosts across sites in the above-mentioned first implementation scenario are layer-2 messages (based on MAC routing), while the messages transmitted between hosts across sites in the second implementation scenario are layer-3 messages (based on IP routing).

[0228] The order of the steps of the message transmission method provided in the embodiments of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. Any method that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application.

[0229] Figure 20 is a schematic flow diagram of another message transmission method provided in an embodiment of the present application. The application scenario of this method includes at least a first device and a second device. For example, the application scenario may be the application scenario shown in Figure 5, where the first device may be, for example, PE2 or PE3 shown in Figure 5, and the second device may be, for example, PE1 shown in Figure 5. This method can be specifically used to implement method 600 shown in the corresponding embodiment of Figure 6. As shown in Figure 20, this method includes but is not limited to the following steps 2001 to 2002.

[0230] Step 2001: A first device generates a message, which 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.

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

[0232] When the method is specifically used to implement method 600 shown in Figure 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 can refer to steps 601 to 602 in method 600 and will not be repeated here.

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

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

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

[0236] 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.

[0237] In one specific implementation, the method further includes: the first device receiving 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. The specific implementation process of this step can be referred to the relevant description of the embodiment shown in Figure 6 and is not further described here.

[0238] 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.

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

[0240] 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.

[0241] 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 packet.

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

[0243] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

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

[0245] In a specific implementation, the first device receives capability negotiation information sent by the 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 community attribute, and the capability negotiation extended community attribute is used to carry capability negotiation information.

[0246] In a specific implementation, the first device is an ingress provider edge device (PE), and the second device is an egress provider edge device (PE).

[0247] Figure 21 is a flow chart of another message transmission method provided in 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 the application scenario shown in Figure 5, wherein the second device may be, for example, PE1 shown in Figure 5, the first device may be, for example, PE2 or PE3 shown in Figure 5, and the third device may be, for example, P1 or P2 shown in Figure 5. The method may be specifically used to implement method 600 shown in the corresponding embodiment of Figure 6. As shown in Figure 21, the method includes but is not limited to the following steps 2101 to 2102.

[0248] Step 2101: The second device receives a message sent by the third device through the 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.

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

[0250] When the method is specifically used to implement method 600 shown in Figure 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 can refer to steps 602 to 603 in method 600 and will not be repeated here.

[0251] In a specific implementation, the method further includes: the second device determining that the message comes from the first device based on 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 be referred to step 604 in method 600 and will not be repeated here.

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

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

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

[0255] 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.

[0256] In one specific implementation, the method further includes: the second device sending 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. The specific implementation process of this step can be referred to the relevant description of the embodiment shown in Figure 6 and is not further described here.

[0257] 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.

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

[0259] 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.

[0260] 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 packet.

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

[0262] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0263] In a specific implementation, the second device sends capability negotiation information to the first device by sending a BGP EVPN route to the first device, where 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.

[0264] In a specific implementation, the second device sends capability negotiation information to the first device by sending a BGP L3VPN route to the first 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.

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

[0266] Figure 22 is a schematic flow diagram of another message transmission method provided in an embodiment of the present application. The application scenario of this method includes at least a first device and a second device. For example, the application scenario may be the application scenario shown in Figure 5, where the first device may be, for example, PE2 or PE3 shown in Figure 5, and the second device may be, for example, PE1 shown in Figure 5. This method can be specifically used to implement method 600 shown in the corresponding embodiment of Figure 6. As shown in Figure 22, this method includes but is not limited to the following steps 2201.

[0267] Step 2201: A first device receives capability negotiation information sent by a second device. 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.

[0268] 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.

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

[0270] 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.

[0271] 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 packet.

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

[0273] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0274] In a specific implementation, the implementation method of the first device receiving the capability negotiation information sent by the second device includes: the first device receives the 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.

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

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

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

[0278] Figure 23 is a schematic flow diagram of another message transmission method provided in an embodiment of the present application. The application scenario of this method includes at least a first device and a second device. For example, the application scenario may be the application scenario shown in Figure 5, the second device may be, for example, PE1 shown in Figure 5, and the first device may be, for example, PE2 or PE3 shown in Figure 5. This method can be specifically used to implement method 600 shown in the corresponding embodiment of Figure 6. As shown in Figure 23, this method includes but is not limited to the following steps 2301 to 2302.

[0279] 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 about the capability of carrying the device identifier of the first device in an MPLS message sent by the first device to the second device.

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

[0281] 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.

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

[0283] 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.

[0284] 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 packet.

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

[0286] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0287] In a specific implementation, the second device sends capability negotiation information to the first device, including: the second device sends a BGP EVPN route to the first 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.

[0288] In a specific implementation, the second device sends capability negotiation information to the first device by sending a BGP L3VPN route to the first device, where the BGP L3VPN route includes a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information.

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

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

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

[0292] 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 FIG24 , 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 also includes a receiving module 2403.

[0293] The processing module 2401 is configured to generate a message, the message including 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. The sending module 2402 is configured to send the message to the second device via the LSP established between the first device and the second device.

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

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

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

[0297] 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.

[0298] In a specific implementation, the receiving module 2403 is configured 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.

[0299] 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.

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

[0301] 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.

[0302] 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 packet.

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

[0304] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0305] In a specific implementation, the receiving module 2403 is specifically configured to receive a 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 capability negotiation information.

[0306] In a specific implementation, the receiving module 2403 is specifically configured 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.

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

[0308] 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.

[0309] Receiving module 2501 is configured to receive a message sent by a third device via 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, with the device identifier encapsulated between the MPLS header and the message payload. Processing module 2502 is configured to parse the message and obtain the device identifier of the first device.

[0310] In a specific implementation, the processing module 2502 is further configured to determine, based on 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.

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

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

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

[0314] 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.

[0315] In a specific implementation, the sending module 2503 is configured 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 on the capability of carrying the device identifier of the first device in a message.

[0316] 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.

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

[0318] 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.

[0319] 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 packet.

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

[0321] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0322] In a specific implementation, the sending module 2503 is specifically configured to send a BGP EVPN route to the first device, where 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.

[0323] In a specific implementation, the sending module 2503 is specifically configured to send a BGP L3VPN route to the first 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.

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

[0325] 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.

[0326] The receiving module 2601 is configured to receive 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 on the capability of carrying the device identifier of the first device in an MPLS message sent by the first device to the second device.

[0327] 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.

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

[0329] 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.

[0330] 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 packet.

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

[0332] In a specific implementation, the bottom label of the stack is a specified eSPL. When the label stack of the packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

[0333] In a specific implementation, the receiving module 2601 is specifically configured to receive a 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 capability negotiation information.

[0334] In a specific implementation, the receiving module 2601 is specifically configured 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.

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

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

[0337] 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.

[0338] The processing module 2701 is configured to generate capability negotiation information for use in negotiating between a first device and a second device regarding the capability of carrying the device identifier of the first device in an MPLS message sent by the first device to the second device. The sending module 2702 is configured to send the capability negotiation information to the first device.

[0339] 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.

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

[0341] 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.

[0342] 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 packet.

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

[0344] In a specific implementation, the bottom label of the stack is a designated eSPL. When the label stack of a packet carries the eSPL, the label stack also carries a special label. The special label is used to indicate that the subsequent adjacent label is the eSPL.

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

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

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

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

[0349] Regarding the apparatus 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.

[0350] The following is an example of the hardware structure involved in the embodiments of the present application.

[0351] Figure 28 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 Figure 28 , the device 2800 includes a processor 2801 and a memory 2802.

[0352] Memory 2802, for storing computer-readable instructions;

[0353] The processor 2801 is configured 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 FIG6 according to the instructions of the computer-readable instructions.

[0354] In a specific implementation, the apparatus 2800 may further include a communication interface 2803. The memory 2802, the processor 2801 and the communication interface 2803 are communicatively connected to each other.

[0355] 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 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 device 1 in the method shown in Figure 6, the communication interface 2901 is used to send messages to device 2, and the processor 2902 is used to generate messages.

[0356] In the embodiments 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 via a communication bus.

[0357] 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 embodiment, the hardware chip may be used to implement encryption / decryption operations.

[0358] Memory can include volatile memory, such as random access memory (RAM). Memory can also include non-volatile memory, such as flash memory, a hard disk drive (HDD), or a solid-state drive (SSD). Memory can also include a combination of the aforementioned types of memory.

[0359] There may be multiple communication interfaces, each used to communicate with other devices. The communication interfaces may include wired communication interfaces, wireless communication interfaces, or a combination thereof. For example, the wired communication interface may be 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.

[0360] In the above embodiments, all or part of the embodiments can be implemented by hardware, firmware, or any combination thereof. When software is involved in the specific implementation process, it can be embodied in the form of a computer program product in whole or in part. 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 embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can 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 can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can 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 (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, an SSD).

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

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

[0363] Those 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 a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0364] 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.

[0365] In this application, the term "and / or" simply describes an association between related objects, indicating that three possible relationships exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0366] 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 the relevant laws, regulations and standards of relevant countries and regions.

[0367] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the concepts and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. 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.

2. The method according to claim 1, characterized in that The device identifier of the first device is a router identifier of the first device.

3. The method according to claim 1 or 2, characterized in that: The message includes a control word, and the control word is used to carry the device identifier.

4. The method according to claim 1 or 2, characterized in that: The message includes a control word, and the device identifier is adjacent to the control word.

5. The method according to claim 1 or 2, characterized in that: The stack bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the stack bottom label.

6. 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.

7. The method according to claim 6, characterized in that 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 control word of a message.

8. The method according to claim 7, characterized in that The control word is a 4-byte control word.

9. The method according to claim 7, 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.

10. The method according to claim 6, characterized in that The capability negotiation information is used to negotiate between the first device and the second device a capability of carrying the device identifier of the first device after the stack bottom label of the message.

11. The method according to claim 10, characterized in that The stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a designated basic special purpose label bSPL.

12. The method according to claim 10, characterized in that The bottom label 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. The special label is used to indicate that the subsequent adjacent label is the eSPL.

13. The method according to any one of claims 6 to 12, characterized in that: The first device receiving the capability negotiation information sent by the second device includes: 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.

14. The method according to any one of claims 6, 10-12, characterized in that: The first device receiving the capability negotiation information sent by the second device includes: The first device receives a Border Gateway Protocol Layer 3 Virtual Private Network (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 the capability negotiation information.

15. The method according to any one of claims 1 to 14, characterized in that: The first device is an ingress provider edge device (PE), and the second device is an egress provider edge device (PE).

16. 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.

17. 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.

18. The method according to claim 16 or 17, characterized in that The device identifier of the first device is a router identifier of the first device.

19. The method according to any one of claims 16 to 18, characterized in that: The message includes a control word, and the control word is used to carry the device identifier.

20. 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.

21. The method according to any one of claims 16 to 18, characterized in that: The stack bottom label of the MPLS header is used to indicate that the device identifier is adjacent to the stack bottom label.

22. 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.

23. The method according to claim 22, characterized in that 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 control word of a message.

24. The method according to claim 23, characterized in that The control word is a 4-byte control word.

25. The method according to claim 23, 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.

26. The method according to claim 22, characterized in that The capability negotiation information is used to negotiate between the first device and the second device a capability of carrying the device identifier of the first device after the stack bottom label of the message.

27. The method according to claim 26, characterized in that The stack bottom label is a pre-configured static label, or a dynamic label allocated by the second device, or a designated basic special purpose label bSPL.

28. The method according to claim 26, characterized in that The bottom label 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. The special label is used to indicate that the subsequent adjacent label is the eSPL.

29. The method according to any one of claims 22 to 28, characterized in that: The second device sending capability negotiation information to the first device includes: 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 community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information.

30. The method according to any one of claims 22, 26-28, characterized in that: The second device sending capability negotiation information to the first device includes: 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 community attribute, and the capability negotiation extended community attribute is used to carry the capability negotiation information.

31. The method according to any one of claims 16 to 30, characterized in that: The first device is an ingress provider edge device (PE), and the second device is an egress provider edge device (PE).

32. 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.

33. 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.

34. A message transmission system, characterized in that: include: A first device and a second device, wherein the first device is used to execute the method according to any one of claims 1 to 15, and the second device is used to execute the method according to any one of claims 16 to 31; or, the first device is used to execute the method according to claim 32, and the second device is used to execute the method according to claim 33.

35. A network device, characterized in that: include: Communication interface; as well as 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.

36. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed by the processor, the method according to any one of claims 1 to 33 is implemented.

37. A computer program product, characterized in that The method comprises a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 33.

Images