CN119071196A

CN119071196A - Message transmission method, device and system

Info

Publication number: CN119071196A
Application number: CN202310638085.5A
Authority: CN
Inventors: 朱彤; 王海波; 杨平安
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-05-31
Filing date: 2023-05-31
Publication date: 2024-12-03
Also published as: WO2024244974A1

Abstract

The application discloses a message transmission method, device and system, and belongs to the technical field of networks. The first device generates a message including an MPLS header, a device identification of the first device, and a message payload, the device identification being encapsulated between the MPLS header and the message payload. And the first equipment sends the message to the second equipment through the LSP established between the first equipment and the second equipment. Because 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 according to the device identifier. Thereby realizing accurate statistics of network traffic in the incoming direction.

Description

Message transmission method, device and system

Technical Field

The present application relates to the field of network technologies, and in particular, to a method, an apparatus, and a system for transmitting a message.

Background

Traffic statistics is a basic function of communication networks. By counting the network traffic, the quality and health of the network operation can be analyzed. Traffic statistics may also be used to hierarchically locate network faults to reduce fault scope. But it is difficult to implement accurate statistics on network traffic on network devices in some network scenarios that forward based on multiprotocol label switching (multiprotocol label switching, MPLS) technology, such as an ethernet virtual private network (Ethernet virtual private network, EVPN) based on MPLS (abbreviated as EVPN over MPLS) scenario and a layer 3virtual private network,L3VPN (abbreviated as MPLS L3 VPN) based on MPLS.

Disclosure of Invention

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

In a first aspect, a method for transmitting a message is provided. The method includes that a first device generates a message, wherein the message comprises an MPLS header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. The first device sends a message to the second device through a label switched path (label SWITCHED PATH, LSP) established between the first device and the second device.

In the application, when a first device generates a message, a device identifier of the first device is encapsulated between an MPLS header and a message payload of the message, and then the generated message is sent to a second device through an LSP established between the first device and the second device. Because 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 according to the device identifier. That is, the second device, as the egress device of the packet on the label switching path, can accurately identify the ingress device of the packet on the label switching path as the first device. The application can realize accurate statistics of network traffic in the network scene of forwarding based on MPLS technology. For example, in an EVPN over MPLS scenario or an MPLS L3VPN scenario, an egress device on a label switched path can accurately count network traffic in an ingress direction.

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

In a specific implementation, the message includes a control word, where the control word is used to carry the device identifier. The realization mode does not need to change the format of the original MPLS message, and only needs to configure the capability of analyzing the control word and identifying the equipment identifier in the second equipment and configure the capability of setting the control word as the equipment identifier in the first equipment.

In a specific implementation, the message includes a control word, and the device identifier is contiguous with the control word. This implementation does not require changing the original control word and does not affect the function of the original control word.

In a specific implementation, a stack bottom label of the MPLS header is used to indicate that a device identifier is adjacent to the stack bottom label. In one particular implementation, the bottom label may indicate, separately, that the device identifier is adjacent to the bottom label. Or the label at the bottom of the stack and other labels in the label stack jointly indicate that the label adjacent to the label at the bottom of the stack is a device identification. For example, the bottom label is a designated extended special purpose label, and the extended special purpose label and the previous extended label together indicate that the bottom label is adjacent to the bottom label and is a device identifier.

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

In the application, the first equipment and the second equipment can realize that the equipment identifier of the first equipment is carried in the message sent to the second equipment by the first equipment through capability negotiation. Or the capability of the first device to carry the device identifier of the first device in the generated message and the capability of the second device to parse the device identifier in the received message may also be configured manually.

An implementation, 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 the message.

In one particular implementation, the control word is a4 byte control word. The 4 byte control word is used to carry the device identification of the first device. The main idea of this embodiment is that the control word capability is negotiated between the first device and the second device, and that the second device uses the control word information to determine that the message originates from the first device by carrying the device identification of the first device in the control word, so that the message arrives at the second device.

In a specific implementation, the control word is an 8-byte long control word, 4 bytes of the long control word are used to carry the original control word, and the other 4 bytes of the long control word are used to carry the device identifier of the first device. In a specific implementation, the high 4 bytes of the long control word are used to carry the original control word, and the low 4 bytes of the long control word are used to carry the device identification of the first device. The main idea of this embodiment is that the first device negotiates the long control word capability with the second device, the original control word is carried in the high 4 bytes of the long control word, and the device identification of the first device is carried in the low 4 bytes of the long control word, so that after the message arrives at the second device, the second device can determine that the message comes from the first device by using the low 4 bytes of the long control word.

In another implementation, 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 after a stack label of the message.

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

In a specific implementation, the stack bottom label is a specific extended special-purpose label (eSPL), and when the label stack of the message carries the eSPL, the label stack further carries a special label, and the special label is used for indicating that the label adjacent to the label stack is the eSPL. The main idea of this embodiment is that an extended tag indication capability is negotiated between the first device and the second device, and eSPL indicated by the stack bottom indicates that 4 bytes after the tag stack carry the device identification of the first device, so that after the message arrives at the second device, the second device can determine that the message comes from the first device by using 4 bytes after the stack bottom tag.

In a specific implementation, the first device receives capability negotiation information sent by the second device, and the capability negotiation information comprises a border gateway protocol (border gateway protocol, BGP) EVPN route sent by the second device, wherein the BGP EVPN route comprises a capability negotiation extended community attribute, and the capability negotiation extended community attribute is used for carrying the capability negotiation information.

The application can be applied to EVPN over MPLS scene, and the capability negotiation information can be issued in BGP EVPN route.

In a specific implementation, the first device receives the capability negotiation information sent by the second device, and the method comprises the step that the first device receives a BGP L3VPN route sent by the second device, wherein the BGP L3VPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

The application can be applied to MPLS L3VPN scene, and the capability negotiation information can be issued in the L3VPN route.

In one particular implementation, a first device sends a capability negotiation response to a second device. The capability negotiation response indicates that the first device has the capability of carrying the device identification of the first device in the message. In this way, the second device can clearly know whether the first device has the capability of carrying the device identifier in the message, and the capability negotiation reliability can be improved.

In a specific implementation, the first device is an in-operator edge device, and the second device is an out-operator edge device.

In a second aspect, a method for transmitting a message is provided. The method comprises the steps that a second device receives a message sent by a third device through an LSP established between the second device and a first device, wherein the third device is a label switching device positioned between the first device and the second device on the LSP, the message comprises an MPLS header, a device identifier of the first device and a message payload, and the device identifier is packaged between the MPLS header and the message payload. The second device analyzes the message to obtain the device identifier of the first device.

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

In the application, because 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 analyzing the message, and the message is determined to be sent by the first device according to the device identifier of the first device. That is, the second device, as the egress device of the packet on the label switching path, can accurately identify the ingress device of the packet on the label switching path as the first device. The application can realize accurate statistics of network traffic in the network scene of forwarding based on MPLS technology. For example, in an EVPN over MPLS scenario or an MPLS L3VPN scenario, an egress device on a label switched path can accurately count network traffic in an ingress direction.

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

In a specific implementation, the message includes a control word, and the device identifier is contiguous with the control word.

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

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

In one implementation, 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 the message.

In one particular implementation, the control word is a 4 byte control word.

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

In one specific implementation, the bottom label is a preconfigured static label, or a dynamic label assigned by the second device, or a designated bSPL.

In a specific implementation, the label at the bottom of the stack is designated eSPL, and when the label stack of the message carries the eSPL, the label stack also carries a special label, where the special label is used to indicate that the label adjacent to the special label is eSPL.

In a specific implementation, an implementation manner of sending capability negotiation information by a second device to a first device includes that the second device sends a BGP EVPN route to the first device, where the BGP EVPN route includes a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used to carry capability negotiation information.

In a specific implementation, the implementation mode of sending the capability negotiation information to the first device by the second device comprises that the second device sends a BGP L3VPN route to the first device, wherein the BGP L3VPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

In one particular implementation, a second device receives a capability negotiation response sent by a first device.

In a third aspect, a method for transmitting a message is provided. The method includes that a first device receives capability negotiation information sent by a second device, wherein the capability negotiation information is used for negotiating between the first device and the second device a capability of carrying a device identifier of the first device in an MPLS message sent by the first device to the second device.

In the application, the first equipment and the second equipment realize that the equipment identifier of the first equipment is carried in the message sent to the second equipment by the first equipment through capability negotiation.

In one particular implementation, the control word is a 4 byte control word.

In a specific implementation, an implementation manner of receiving capability negotiation information sent by a second device by a first device includes that the first device receives a BGP EVPN route sent by the second device, where the BGP EVPN route includes a capability negotiation extension group attribute, and the capability negotiation extension group attribute is used to carry the capability negotiation information.

In a specific implementation, the implementation manner of receiving the capability negotiation information sent by the second device by the first device includes that the first device receives 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 the capability negotiation information.

In one particular implementation, a first device sends a capability negotiation response to a second device.

In a fourth aspect, a method for transmitting a message is provided. The method includes the steps that the second equipment generates capability negotiation information, wherein the capability negotiation information is used for negotiating the capability of carrying the equipment identification of the first equipment in the MPLS message sent by the first equipment to the second equipment between the first equipment and the second equipment. The second device sends the capability negotiation information to the first device.

In one particular implementation, the control word is a 4 byte control word.

In a fifth aspect, a first device is provided. The first device comprises a plurality of functional modules that interact to implement the method of the first aspect and embodiments thereof described above. The plurality of functional modules may be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules may be arbitrarily combined or divided based on the specific implementation. The plurality of functional modules include a processing module and a sending module. In a specific implementation, the plurality of functional modules further includes a receiving module.

The processing module is used for generating a message, wherein the message comprises an MPLS header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. And the sending module is used for sending the message to the second equipment through the LSP established between the first equipment and the second equipment.

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

In a specific implementation, 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 the message.

In one particular implementation, the control word is a 4 byte control word.

In a specific implementation, 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 label of the message.

In a specific implementation, the label at the bottom of the stack is designated eSPL, and when the label stack of the message carries eSPL, the label stack also carries a special label, where the special label is used to indicate that the label adjacent to the special label is eSPL.

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 extension group attribute, and the capability negotiation extension group attribute is used to carry capability negotiation information.

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 extension community attribute, and the capability negotiation extension community attribute is used to carry capability negotiation information.

In a sixth aspect, a second device is provided. The second device comprises a plurality of functional modules that interact to implement the method of the second aspect and embodiments thereof described above. The plurality of functional modules may be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules may be arbitrarily combined or divided based on the specific implementation. The plurality of functional modules includes a receiving module and a processing module. In a specific implementation, the plurality of functional modules further includes a transmitting module.

And the receiving module is used for receiving a message sent by a third device through the LSP established between the second device and the first device, wherein the third device is a label switching device positioned between the first device and the second device on the LSP, the message comprises an MPLS header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload. And the processing module is used for analyzing the message to obtain the equipment identifier of the first equipment.

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

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

In one particular implementation, the control word is a 4 byte control word.

In one specific implementation, the bottom label is a preconfigured static label, or a dynamic label assigned by the first device, or a designated bSPL.

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.

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 configured to carry capability negotiation information.

In a seventh aspect, a first device is provided. The first device comprises a plurality of functional modules that interact to implement the method of the third aspect and embodiments thereof. The plurality of functional modules may be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules may be arbitrarily combined or divided based on the specific implementation. The plurality of functional modules includes a receiving module. In a specific implementation, the plurality of functional modules further includes a transmitting module.

And the receiving module is used for receiving the capability negotiation information sent by the second equipment, wherein the capability negotiation information is used for negotiating the capability of carrying the equipment identifier of the first equipment in the MPLS message sent by the first equipment to the second equipment between the first equipment and the second equipment.

In one particular implementation, the control word is a 4 byte control word.

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

In an eighth aspect, a second device is provided. The second device comprises a plurality of functional modules that interact to implement the method of the fourth aspect and embodiments thereof. The plurality of functional modules may be implemented based on software, hardware, or a combination of software and hardware, and the plurality of functional modules may be arbitrarily combined or divided based on the specific implementation. The plurality of functional modules include a processing module and a sending module. In a specific implementation, the plurality of functional modules further includes a receiving module.

And the processing module is used for generating capability negotiation information, wherein the capability negotiation information is used for negotiating the capability of carrying the device identifier of the first device in the MPLS message sent by the first device to the second device between the first device and the second device. And the sending module is used for sending the capability negotiation information to the first equipment.

In one particular implementation, the control word is a 4 byte control word.

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.

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

A ninth aspect provides a message transmission system, comprising a first device for implementing the method in the first aspect or any possible implementation manner of the first aspect, and a second device for implementing the method in the second aspect or any possible implementation manner of the second aspect, or the first device for implementing the method in the third aspect or any possible implementation manner of the third aspect, and the second device for implementing the method in the fourth aspect or any possible implementation manner of the fourth aspect.

In a tenth aspect, a network device is provided that includes a communication interface and a processor coupled to the communication interface. According to the communication interface and the processor, the method of the first aspect or any possible implementation manner of the first aspect, or the method of the second aspect or any possible implementation manner of the second aspect, or the method of the third aspect or any possible implementation manner of the third aspect, or the method of the fourth aspect or any possible implementation manner of the fourth aspect is implemented.

In an eleventh aspect, there is provided a computer readable storage medium having instructions stored thereon which, when executed by a processor, implement the method of the first aspect or any of the possible implementations of the first aspect, or implement the method of the second aspect or any of the possible implementations of the second aspect, or implement the method of the third aspect or any of the possible implementations of the third aspect, or implement the method of the fourth aspect or any of the possible implementations of the fourth aspect.

A twelfth aspect provides a computer program product comprising a computer program which, when executed by a processor, implements the method of the first aspect or any of the possible implementations of the first aspect, or implements the method of the second aspect or any of the possible implementations of the second aspect, or implements the method of the third aspect or any of the possible implementations of the third aspect, or implements the method of the fourth aspect or any of the possible implementations of the fourth aspect.

A thirteenth aspect provides a chip comprising programmable logic circuitry and/or program instructions, which when run implements the method of the first aspect or any of the possible implementations of the first aspect or the method of the second aspect or any of the possible implementations of the third aspect or any of the possible implementations of the fourth aspect.

Drawings

Fig. 1 is a schematic diagram of issuing a MAC address in an EVPN over MPLS scenario in the related art;

fig. 2 is a schematic diagram of packet transmission in an EVPN over MPLS scenario in the related art;

fig. 3 is a schematic diagram of IP address distribution in MPLS L3VPN scenario in the related art;

fig. 4 is a schematic diagram of packet transmission in a MPLS L3VPN scenario in the related art;

Fig. 5 is a schematic diagram of an application scenario provided in an embodiment of the present application;

fig. 6 is a flow chart of a message transmission method according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an MPLS packet according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of another MPLS packet according to an embodiment of the present application;

Fig. 9 is a schematic structural diagram of yet another MPLS packet according to an embodiment of the present application;

Fig. 10 is a schematic structural diagram of yet another MPLS packet according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a BGP update message according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a capability negotiation extension community attribute provided by an embodiment of the present application;

Fig. 13 is a schematic diagram of packet transmission in an EVPN over MPLS scenario according to an embodiment of the present application;

FIG. 14 is a schematic diagram of another capability negotiation extension community attribute provided by an embodiment of the present application;

fig. 15 is a schematic diagram of another packet transmission in an EVPN over MPLS scenario according to an embodiment of the present application;

FIG. 16 is a schematic diagram of a further capability negotiation extension community attribute provided by an embodiment of the application;

fig. 17 is a schematic diagram of a message transmission in an EVPN over MPLS scenario according to an embodiment of the present application;

FIG. 18 is a schematic diagram of a further capability negotiation extension community attribute provided by an embodiment of the present application;

fig. 19 is a schematic diagram of a message transmission in an EVPN over MPLS scenario according to an embodiment of the present application;

fig. 20 is a flow chart of another message transmission method according to an embodiment of the present application;

fig. 21 is a flow chart of another method for transmitting a message according to an embodiment of the present application;

fig. 22 is a flow chart of another method for transmitting a message according to an embodiment of the present application;

fig. 23 is a flow chart of another message transmission method according to an embodiment of the present application;

fig. 24 is a schematic structural diagram of a message transmission device according to an embodiment of the present application;

Fig. 25 is a schematic structural diagram of another message transmission device according to an embodiment of the present application;

fig. 26 is a schematic structural diagram of another message transmission device according to an embodiment of the present application;

fig. 27 is a schematic structural diagram of another message transmission device according to an embodiment of the present application;

Fig. 28 is a block diagram of a message transmission device according to an embodiment of the present application;

Fig. 29 is a block diagram of another message transmission apparatus according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail with reference to the accompanying drawings.

Currently, hosts located at different sites can communicate across sites. One site may be considered as a local area network, for example, a single-segment (single-segment) local area network, or a multi-segment (multiple-segment) local area network. Different sites may be deployed in different regions. One or more hosts may be deployed within a site. A host refers to a terminal device on which a client is installed, such as a smart phone, tablet, desktop computer, internet of things (internet of things, ioT) device, network device, workstation, server, or the like.

Hosts within a site typically belong to a private network. Different hosts within a site may belong to the same private network or different private networks. Hosts within a private network are typically configured with an intranet address. Because the intranet addresses of different private networks may overlap, the intranet addresses configured by hosts within a private network are generally only available for communication within the private network. The private network may be deployed across sites, i.e., one private network may include multiple hosts deployed at different sites. For example, a private network is distributed between site a and site B, where site a and site B are connected by an operator network, and then the private network is described as including a host at site a and a host at site B. The private network may be implemented using a virtual private network (virtual private network, VPN). For a private network, the hosts deployed in the private network are intranet hosts, while the carrier network and other private networks are external networks. The operator network for connecting different sites may be a wide area backbone network or a metropolitan area network established using MPLS technology, among others. The private network here may be a private network of an enterprise. The network of the enterprise at a site is an intra-enterprise network, and the multiple networks of the enterprise deployed at multiple sites are referred to as the private network of the enterprise or a multi-site private network.

For private networks distributed among multiple sites, if an intranet host of one site is to send a message to an intranet host of another site, the transmission of the message needs to pass through an external network between two sites. An intranet host at a site needs to communicate with an external network through the edge access device at the site. The edge access devices of a site are commonly referred to as Customer Edge (CE) devices. The CE device may be, for example, a router, a switch, a gateway, or the like. Taking an external network as an operator network, for example, CE devices of each site are respectively connected to one Provider Edge (PE) device. When an intranet host of one site sends a message to an intranet host of another site, the message firstly reaches CE equipment of the local site, then is transmitted to connected PE equipment by the CE equipment of the local site, then reaches PE equipment at a far end after being transmitted through an operator network, then is transmitted to CE equipment at the far end by the PE equipment at the far end, and finally is transmitted to the intranet host of the far end by the CE equipment at the far end.

Alternatively, hosts at different sites may communicate over a two-tier network or a three-tier network. The different hosts communicate through a two-layer network, i.e., the different hosts communicate based on media access Control (MEDIA ACCESS Control, MAC) routing. The different hosts communicate via a three-tier network, i.e., the different hosts communicate via internet protocol (Internet Protocol, IP) routes.

The EVPN technology is a VPN technology for two-layer network interconnection. Because the EVPN can solve the problem that the conventional virtual private local area network (local area network, LAN) service (virtual PRIVATE LAN SERVICE, VPLS) does not support dual-homing network load sharing, and can avoid the disadvantage of full connection between public network Pseudowires (PW), rapid convergence of routes is realized, and the EVPN is widely applied to networks in recent years. Among them, VPLS is a two-layer VPN technology based on MPLS and ethernet technology. Unlike the mechanism by which the conventional two-layer virtual private network (layer 2virtual private network,L2VPN) learns MAC addresses through the forwarding plane, EVPN introduces a control plane. The EVPN transfers the process of issuing MAC addresses between two-layer networks of different sites from the forwarding plane to the control plane by extending the multiprotocol border gateway protocol (multiprotocol border gateway protocol, MP-BGP). EVPN is functionally different from conventional L2VPN due to implementation principle differences. In the EVPN over MPLS scenario, MAC routing is delivered to a far-end PE device through a control plane.

L3VPN technology is a VPN technology for three-layer network interconnection.

For example, fig. 1 is a schematic diagram of issuing a MAC address in an EVPN over MPLS scenario in the related art. Fig. 2 is a schematic diagram of packet transmission in an EVPN over MPLS scenario in the related art. Fig. 3 is a schematic diagram of IP address distribution in a MPLS L3VPN scenario in the related art. Fig. 4 is a schematic diagram of packet transmission in a MPLS L3VPN scenario in the related art. In the scenario shown in fig. 1 to 4, the operator network includes three PE devices PE1 to PE3, and two operator (P) devices P1 and P2. Wherein the P device is not shown in fig. 1 and 3. PE1 is coupled to P1 and P2, respectively. P1, P2, PE2 and PE3 are connected in pairs. CE1 connects PE1 to access the communication network. CE2 dual homing connects PE2 and PE3 to access the communication network, i.e. PE2 and PE3 are dual homing access devices for CE 2.

In the scenario shown in fig. 1 and fig. 2, BGP EVPN peering relationships are established between each two of PE1, PE2, and PE3. As shown in fig. 1, after learning the MAC1 from CE1, PE1 distributes the private network Label1 to PE2 and PE3 at the far end, respectively. As shown in fig. 2, CE2 sends a two-layer message with destination MAC address DMAC (e.g., MAC 1) and source MAC address SMAC to CE 1. If the message is sent to PE1 by PE2 through P1, PE2 generates MPLS message, the MPLS message includes MPLS header and message payload, the MPLS header includes public network Label LSP1 distributed by P1 and private network Label1 distributed by PE1, and two layers of message sent by CE2 are encapsulated in the message payload. After receiving the MPLS packet sent by PE2, P1 may pop up the public network label LSP1, and then continue sending the MPLS packet to PE 1. The message received by the PE1 finally comprises an MPLS header and a message payload, wherein the MPLS header comprises a private network Label1 distributed by the PE 1. If the message is sent to PE1 by PE3 through P2, PE3 generates MPLS message, the MPLS message includes MPLS header and message payload, the MPLS header includes public network Label LSP2 distributed by P2 and private network Label1 distributed by PE1, and two layers of message sent by CE2 are encapsulated in the message payload. After receiving the MPLS packet sent by PE3, P2 may pop up the public network label LSP2, and then continue sending the MPLS packet to PE 1. The message received by the PE1 finally comprises an MPLS header and a message payload, wherein the MPLS header comprises a private network Label1 distributed by the PE 1. That is, no matter the two-layer message sent by CE2 to CE1 is forwarded by PE2 or by PE3, the private network Label carried by the MPLS packet received by PE1 is Label1, so that PE1 cannot distinguish whether the traffic is from PE2 or PE3 in the incoming direction. The message structure shown in fig. 2 is for illustration only, and the MPLS header of the MPLS message received by the actual PE1 may also include an encapsulated outer MAC header. The private network label is also called VPN label, and the public network label is also called LSP label.

For ease of understanding, only one P device is depicted between PE devices in the scenario shown in fig. 2 and 4, and those skilled in the art will appreciate that multiple P devices may be included between PE devices. The MPLS technology described in the present application may be a conventional MPLS technology, or may be a Segment Routing (SR) MPLS (SR-MPLS) technology based on an MPLS forwarding plane.

In the scenario shown in fig. 3 and fig. 4, BGP L3VPN peering relations are established between each two of PE1, PE2, and PE3. As shown in fig. 3, after learning the IP1 from CE1, PE1 distributes the private network Label2 to the remote PE2 and PE3, respectively. As shown in fig. 4, CE2 sends three-layer packets with destination IP address as destination IP (e.g., IP 1) and source IP address as source IP to CE 1. If the message is sent to PE1 by PE2 through P1, PE2 generates MPLS message, the MPLS message includes MPLS header and message payload, the MPLS header includes public network Label LSP1 distributed by P1 and private network Label2 distributed by PE1, three layers of message sent by CE2 are encapsulated in the message payload. After receiving the MPLS packet sent by PE2, P1 may pop up the public network label LSP1, and then continue sending the MPLS packet to PE 1. The message received by the PE1 finally comprises an MPLS header and a message payload, wherein the MPLS header comprises a private network Label2 distributed by the PE 1. If the message is sent to PE1 by PE3 through P2, PE3 generates MPLS message, the MPLS message includes MPLS header and message payload, the MPLS header includes public network Label LSP2 distributed by P2 and private network Label2 distributed by PE1, and three layers of message sent by CE2 are encapsulated in the message payload. After receiving the MPLS packet sent by PE3, P2 may pop up the public network label LSP2, and then continue sending the MPLS packet to PE 1. The message received by the PE1 finally comprises an MPLS header and a message payload, wherein the MPLS header comprises a private network Label2 distributed by the PE 1. That is, no matter the three-layer message sent by CE2 to CE1 is forwarded by PE2 or by PE3, the private network Label carried by the MPLS message received by PE1 is Label2, so that PE1 cannot distinguish whether the traffic is from PE2 or PE3 in the incoming direction. The message structure shown in fig. 4 is for illustration only, and the MPLS header of the MPLS message received by the actual PE1 may also include an encapsulated outer MAC header.

From the above, it is difficult for network devices to implement accurate statistics of network traffic in the ingress direction in some network scenarios that forward based on MPLS technology, such as EVPN over MPLS scenarios and MPLS L3VPN scenarios. Based on this, the present application provides a technical solution, when a network device generates a message, a device identifier of the network device is encapsulated between an MPLS header and a message payload of the message, and then the generated message is sent to other network devices through an LSP established between the network device and the other network devices. Because the message received by other network equipment carries the equipment identifier of the network equipment, the other network equipment can analyze the message to obtain the equipment identifier of the network equipment, and determine that the message is sent by the network equipment according to the equipment identifier, thereby realizing accurate statistics of network traffic in the incoming direction.

The technical scheme of the application is described in detail from the aspects of application scenes, method flows, virtual devices, entity devices, systems and the like.

The application scenario related to the embodiment of the present application is illustrated below.

The application scene of the application comprises a communication network and a station 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, for example, may be a data center network (DATA CENTER network, DCN), a metropolitan area network, a wide area network, or a local area network, and may be used to carry EVPN service and/or L3VPN service. That is, the application scenario of the present application may be an EVPN over MPLS scenario, or may also be an MPLS L3VPN scenario. Furthermore, the communication network may be an operator network or an enterprise self-established network.

The communication network provided by the application comprises a plurality of network devices for service forwarding, and the plurality of network devices are in communication connection. Each network device may be a switch or a router. Wherein the plurality of network devices includes an edge network device and a core network device. The edge network device is at the edge of the communication network for the station to access the communication network. The core network device is connected between different edge network devices and used for forwarding service between the different edge network devices. Optionally, the station is connected to an edge network device of the communication network through an edge access device, which may be a switch, a router or a gateway, etc., to access the communication network through the edge access device. In the embodiment of the application, the communication network is taken as an operator network for illustration, the edge network equipment is PE equipment, the core network equipment is P equipment, the edge access equipment is CE equipment, and one or more hosts are deployed in a site accessed to the communication network.

For example, fig. 5 is a schematic diagram of an application scenario provided in an embodiment of the present application. As shown in fig. 5, the application scenario includes two CE devices, CE1 to CE2, connected to a communication network (MPLS VPN is shown in fig. 5). The communication network comprises three PE devices PE 1-PE 3 and two P devices P1 and P2. PE1 is coupled to P1 and P2, respectively. P1, P2, PE2 and PE3 are connected in pairs. CE1 connects PE1 to access the communication network. CE2 dual homing connects PE2 and PE3 to access the communication network, i.e. PE2 and PE3 are dual homing access devices for CE 2. CE1 is an edge access device of site 1 for accessing hosts 1 and 2 within site 1 to the communication network. CE2 is an edge access device of site 2 for accessing hosts 3 and 4 within site 2 to the communication network. The application scenario shown in fig. 5 may be the application scenario shown in fig. 1 or fig. 2, and the MPLS VPN is EVPN over MPLS. Or the application scenario shown in fig. 5 may be an application scenario as shown in fig. 3 or fig. 4, the MPLS VPN is an MPLS L3VPN.

Optionally, each of PE1, PE2, and PE3 is BGP neighbor. In the embodiment of the application, two PE devices are BGP neighbors, and a BGP peer relationship is established between the two PE devices. Or the communication network also comprises a route reflector, the two PE devices are BGP neighbors of each other, or the two PE devices respectively establish BGP peer relationship with the route reflector, i.e. the two PE devices are indirectly connected with each other through the route reflector. The routing reflector is used for forwarding messages transmitted between different PE devices, and the routing reflector does not modify the received messages in the forwarding process. In the case where the application scenario shown in fig. 5 is an EVPN over MPLS scenario, for example, in the scenario shown in fig. 1 or fig. 2, PE1, PE2, and PE3 are BGP EVPN neighbors, and the BGP peer relationship established between the devices is BGP EVPN peer relationship. In the case where the application scenario shown in fig. 5 is an MPLS L3VPN scenario, for example, in the case shown in fig. 3 or fig. 4, PE1, PE2, and PE3 are BGP L3VPN neighbors of each other, and the BGP peer relationship established between the devices is BGP L3VPN peer relationship.

Optionally, one or more forwarding instances are configured in a PE device in the communication network. Different forwarding instances in the same device work independently for achieving route isolation. In the embodiment of the present application, the forwarding instance in the PE device may be a two-layer forwarding instance, which is also called an EVPN instance (EVPN INSTANCE, EVI) (corresponding to a two-layer forwarding domain), and the two-layer forwarding instance can issue the MAC route. An EVI may be composed of one or more Bridge Domains (BDs). Or the forwarding instance in the PE device may also be a three-layer forwarding instance, which is also called a virtual routing forwarding (virtual routing forwarding, VRF) instance (corresponding to a three-layer forwarding domain), and the three-layer forwarding instance can publish an IP route. Wherein each forwarding instance is configured with a route target (route target), which may also be referred to as vpn-target. Route target is a BGP extended community attribute, and each forwarding instance needs to configure both outbound and inbound Route targets. When the exit direction route target value of the local forwarding instance configuration is equal to the entry direction route target value of the opposite forwarding instance configuration, the local end and the opposite end can exchange BGP routes with each other. In the embodiment of the application, two PE devices which are BGP EVPN neighbors are configured with EVIs belonging to the same EVPN, and in this case, the two PE devices may also be referred to as the two PE devices belonging to the same EVPN. Two PE devices that are BGP L3VPN neighbors to each other are configured with VRF instances that belong to the same L3VPN, and in this case, the two PE devices may also be referred to as the two PE devices belong to the same L3VPN.

Optionally, after the PE device learns the MAC route (or IP route) from the CE device, the learned MAC route (or IP route) and its corresponding private network label need to be published in the communication network. There are various ways in which the PE device assigns a private network label to a MAC route (or IP route). For example, the PE device may allocate a private network label to each forwarding instance configured in the PE device, and then the private network labels corresponding to all MAC routes (or IP routes) issued by the same forwarding instance in the PE device are the same private network label. Or the PE device may assign a private network label for each MAC route (or IP route) separately. Or the PE device may allocate a private network label to each CE accessed, so that the private network label corresponding to all MAC routes (or IP routes) learned by the PE device from the same CE device is the same private network label. Or the PE device may allocate a private network label for the broadcast domain, so that the private network label corresponding to all MAC routes issued by the PE device in the broadcast domain is the same private network label. The mode of distributing the private network label to the PE equipment is not limited by the embodiment of the application.

The following illustrates the method flow of an embodiment of the present application.

For example, fig. 6 is a schematic flow chart of a message transmission method according to an embodiment of the present application. As shown in fig. 6, method 600 includes steps 601 through 604. Device 1 and device 2 in method 600 are each network edge devices of an MPLS VPN network, and may be, for example, routers, switches, gateways, or the like. An LSP is established between device 1 and device 2, and device 3 is a label switching device located between device 1 and device 2 on the LSP. In the scenario where the MPLS VPN network is an operator network, device 1 in method 600 is an ingress operator edge device (INGRESS PE) and device 2 in method 600 is an egress operator edge device (egress PE). In the scenario where the MPLS VPN network is a data centre network, device 1 in method 600 is an ingress gateway and device 2 in method 600 is an egress gateway. The embodiment of the application does not limit the implementation scene of the MPLS VPN network and the equipment type of the network edge equipment. For example, the method 600 may be applied in an application scenario as shown in fig. 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.

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

Wherein, the message generated by the device 1 is an MPLS message. MPLS packets include a packet header and a packet payload (payload). The header includes the MPLS header and the device identification of device 1. The message payload is an inner layer message of the MPLS message. The inner layer message may be a two-layer message or a three-layer message, and is typically an original data message sent by the user edge device. The three-layer message may be an IPv4 message or an IPv6 message. In the embodiment of the application, the message part positioned in front of the message payload in the MPLS message is called the message header of the MPLS message.

Alternatively, the device identification of device 1 is the router identification (router ID) of device 1. Or the device identification of the device 1 may also be information capable of uniquely identifying the device 1 in the communication network, such as an IP address of the device 1, a hardware address of the device 1, or a MAC address of the device 1. The embodiment of the application does not limit the type of the equipment identifier. The length of the device identifier of the device 1 may be 2 bytes, 4 bytes, 6 bytes, 8 bytes, or the like, and the embodiment of the present application does not limit the length of the device identifier. For example, the device identification of device 1 is the router ID of device 1, and accordingly, the device identification of device 1 is 4 bytes in length. The following embodiments of the present application will each be described by taking a device identifier with a length of 4 bytes as an example.

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

Alternatively, the device identifier of the device 1 may be disposed at a different location in the MPLS packet, and the following three possible implementations are illustrated as examples of the embodiment of the present application. Wherein the set-up location of the device identity in the MPLS packet may be defined in a protocol or standard. Or the network edge devices may negotiate with each other to determine the location of the device identification in the MPLS packet.

In a first possible implementation, the message generated by the device 1 includes a control word, which is used to carry the device identifier of the device 1. In other words, the device identity of device 1 is the control word in the message. In this implementation, the message generated by the device 1 may be as shown in fig. 8, for example. Optionally, the control word is a 4 byte control word. The realization mode does not need to change the format of the original MPLS message, and only needs to configure the capability of analyzing the control word and identifying the equipment identifier in the network edge equipment of the receiving side and configure the capability of setting the control word as the equipment identifier in the network edge equipment of the transmitting side.

In a second possible implementation, the message generated by the device 1 comprises a control word, to which the device identification of the device 1 is adjacent. Optionally, the device identification of device 1 is located after the control word. The control word here refers to the original control word of 4 bytes. In this implementation, the message generated by the device 1 may be as shown in fig. 9, for example. Optionally, the message generated by the device 1 comprises 8 bytes of long control words. 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 the device 1. For example the high 4 bytes of the long control word are used to carry the original control word and the low 4 bytes of the long control word are used to carry the device identification of device 1, i.e. the device identification of device 1 is in the low 4 bytes of the long control word. This implementation does not require changing the original control word and does not affect the function of the original control word.

In a third possible implementation manner, a stack bottom label of an MPLS header in a packet generated by the device 1 indicates a device identifier for the device 1 adjacent to the stack bottom label. In other words, the device identification of device 1 is immediately after the bottom label of the MPLS header. In this implementation, the message generated by the device 1 may be as shown in fig. 10, for example.

Alternatively, the bottom label may separately indicate the device identification for device 1 immediately following the bottom label. Such as a static label pre-configured as a bottom label, or a dynamic label assigned by device 2, or a specified basic special purpose label (bSPL). In the case where the stack bottom label is a preconfigured static label, the static label is preconfigured in each of the devices 1 and 2. The static label preconfigured in the device 1 is used for carrying the label stack bottom of the message sent to the device 2, so as to indicate that the static label carries the device identifier of the device 1. The static label preconfigured in the device 2 is used for analyzing the stack bottom label of the message received by the device 2 so as to judge whether the stack bottom label carries the device identifier of the device for sending the message. In the case of a dynamic label assigned to device 2 by the bottom label, device 2 may generate the dynamic label and send it to device 1. In the case where the bottom label is specified bSPL, the specified bSPL may be defined in a standard or protocol, for example, where the standard or protocol defines that the bottom label is indicated as carrying the device identifier after the bottom label when bSPL, which is the bottom label, takes on a specified label value. The embodiment of the application does not limit the specific value of the appointed label value.

Or the bottom label together with other labels in the label stack indicates the device identity for device 1 next to the bottom label. For example, the label at the bottom of the stack is a designated extended special purpose label (eSPL), and when the label stack of the message carries the label eSPL, the label stack also carries a special label, and the special label is used for indicating that the label adjacent to the special label is eSPL. That is, the bottom label indicates, together with the special label, the device identification for device 1 next to the bottom label, specifically, the special label indicates that the label next to the special label is eSPL, and the specified eSPL (bottom label) indicates the device identification for device 1 next to the eSPL. The special tag may be an extension tag (XL) with a tag value of 15. In the case where the bottom label is specified eSPL, the specified eSPL may be defined in a standard or protocol, for example, where the standard or protocol defines that the bottom label is indicated as carrying the device identifier after the bottom label when eSPL, which is the bottom label, takes on a specified label value. Optionally, eSPL has a value range of 16 to 1048, and any tag value in the range may be defined as the specified tag value. The embodiment of the application does not limit the specific value of the appointed label value.

In the EVPN over MPLS scene, the message payload of the MPLS message transmitted between network devices in the communication network is a two-layer message. In order to avoid that the two-layer message is misidentified as an IPv4 message or an IPv6 message by network devices in the communication network, a Control Word (CW) capability may be negotiated between network edge devices, and a network edge device on the transmitting side may insert a control word between the MPLS header and the message payload. The length of the control word is 4 bytes, and the control word is usually set to be all 0, so that the problem that the intermediate network equipment (such as P equipment) in the communication network erroneously recognizes the two-layer message as an IPv4 message or an IPv6 message, and thus the message is disordered due to incorrect load sharing can be avoided. The definition and function of the control word may be specifically explained by referring to a request comment (request for comments, RFC) document with reference number 7432 (abbreviated as RFC 7432), and the embodiments of the present application are not described herein.

Alternatively, in the case where the device 1 and the device 2 are BGP EVPN neighbors, if CW capability is negotiated between the device 1 and the device 2, the device 1 may carry the device identifier of the device 1 in a message in the first possible implementation manner or the second possible implementation manner described above. Or the device 1 may also use the third possible implementation described above to carry the device identifier of the device 1 in a message. In the first possible implementation manner, if the value of the first 4 bits (bit) of the device identifier of the device 2 is 4 (corresponding to binary system: 0100) or 6 (corresponding to binary system: 0110), the value of the first 4 bits of the device identifier may be mapped to be non-4 and non-6, so as to avoid that the intermediate network device in the communication network erroneously recognizes the received two-layer message as an IPv4 message or an IPv6 message. For example, if the value of the first 4 bits of the device identification of device 2 is 4, then 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 identification of device 2 is 6, the value of this first 4 bits may be mapped to 15 (corresponding to binary: 1111).

Alternatively, in the case where the device 1 and the device 2 are BGP L3VPN neighbors, the device 1 may use the third possible implementation to carry the device identifier of the device 1 in a packet. That is, the third implementation described above is generic to EVPN over MPLS scenarios and MPLS L3VPN scenarios.

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

Taking the application scenario shown in fig. 5 as an example, assume that the host 3 in the site 2 and the host 1 in the site 1 belong to the same private network, and when the host 3 needs to send a data packet to the host 1 across sites, the data packet sequentially passes through the CE2, the MPLS VPN network and the CE1, and finally reaches the host 1. Wherein, the transmission paths of CE2 to CE1 in the MPLS VPN network have 4 paths, including transmission path 1:CE2→PE2→P1→PE1→CE1, transmission path 2 CE2→PE2→P2→PE1→CE1, transmission path 3 CE2→PE3→P1→PE1→CE1, and transmission path 4 CE2→PE3→P2→PE1→CE1. Assuming that the device 2 is PE1 in the application scenario shown in fig. 5, the device 1 is PE2 in the application scenario shown in fig. 5, after the PE2 receives the data packet sent by the CE2, an MPLS packet containing the data packet is generated, and then the PE2 sends the generated MPLS packet to the PE1, where the MPLS packet may be transmitted through the transmission path 1 or the transmission path 2.

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

Step 603, the device 2 parses the message to obtain the device identifier of the device 1.

Optionally, after the device 2 receives the message sent by the device 3 through the LSP established between the device 2 and the device 1, the device identifier of the device 1 may be obtained by parsing the corresponding setting location according to the setting location of the device identifier in the header, which is determined by negotiating with the device 1, or the setting location of the device identifier defined in the protocol or standard in the header.

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

In combination with the second possible implementation manner in step 601, device 2 obtains the device identifier of device 1 by parsing the field in the message that is next to the control word. For example, device 2 may parse the 4-byte content in the message immediately following the control word to obtain the device identification of device 1.

In combination with the third possible implementation manner in the step 601, the device 2 first parses the label stack of the message, and after determining that the bottom label of the label stack indicates that the bottom label is adjacent to the bottom label as the device identifier, the device 2 further parses the field adjacent to the bottom label to obtain the device identifier of the device 1. For example, device 2 may parse the 4 bytes of content in the message immediately following the stack bottom label to obtain the device identification of device 1.

Step 604, the device 2 determines that the message is from the device 1 according to the device identifier.

Since the device 1 device identifier is carried in the message received by the device 2, the device 2 can determine that the message is from the device 1. And further, the flow statistics of the message from the device 1 can be realized. In combination with the example in step 602, for PE1, after receiving an MPLS packet sent by P1 or P2, PE1 can only determine that the MPLS packet is from PE2 or PE3 according to the VPN label in the MPLS packet, and can determine that the MPLS packet is from PE2 according to the device identifier of PE2 carried in the MPLS packet, that is, PE1 can distinguish whether the traffic is from PE2 or PE3, so as to implement accurate statistics on network traffic in the incoming direction.

Or the device 2 may not perform flow statistics on the message from the device 1, for example, the obtained device identifier and the flow information may be uniformly reported to the control device, and the control device may perform flow statistics on the message from different devices according to different device identifiers.

In the message transmission method provided by the embodiment of the application, when the network equipment generates a message, the equipment identifier of the network equipment is encapsulated between the MPLS header and the message payload of the message, and then the generated message is sent to other network equipment. Because the message received by the other network device carries the device identifier of the network device, the other network device can analyze the message to obtain the device identifier, and determine that the message is sent by the network device according to the device identifier. And further, accurate statistics of network traffic can be realized in a network scene of forwarding based on the MPLS technology. For example, in an EVPN over MPLS scene or an MPLS L3VPN scene, accurate statistics on network traffic is realized.

Alternatively, the capability of device 1 to carry the device identification of device 1 in the generated MPLS packet, and the capability of device 2 to parse the device identification in the received MPLS packet may be manually configured. Or the capability of carrying the device identity of the device 1 in a message may also be negotiated between the device 1 and the device 2. For example, before the above-mentioned step 601 is performed, the device 2 generates capability negotiation information for negotiating between the device 1 and the device 2a capability carrying the device identification of the device 1 in an MPLS packet sent by the device 1 to the device 2, and then the device 2 sends the capability negotiation information to the device 1. Specifically, the capability negotiation information indicates that the device 1 carries the device identifier of the device 1 in the message sent to the device 2, and that the device 2 has the capability of resolving the device identifier carried by the message. Optionally, the capability negotiation information further indicates a setting position of the device identity of the device 1 in the message.

Alternatively, the device 1 transmits a capability negotiation response to the device 2 after receiving the capability negotiation information transmitted by the device 2. The capability negotiation response indicates that the device 1 has the capability to carry the device identity of the device 1 in a message. In this way, the device 2 can clearly know whether the device 1 has the capability of carrying the device identifier in the message, and the capability negotiation reliability can be improved.

Or device 1 may not respond to the capability negotiation information sent by device 2. After the subsequent device 2 receives the message, it can determine whether the designated location of the received message carries the device identifier of the network edge device that sends the message. For example, in the first possible implementation manner in step 601, the device 2 may determine whether the control word is a device identifier according to whether the control word of the received packet is all 0. If the control word of the message is all 0, the device 2 determines that the message does not carry the device identifier. If the control word of the message is not all 0, the device 2 determines that the control word of the message is the device identifier of the network edge device that sends the message.

Optionally, the capability negotiation information sent by the device 2 to the device 1 is carried in a BGP update message, for example, may be carried in an extended community attribute of the BGP update message, that is, the device 2 may negotiate with the device 1 using the BGP update message to carry the capability of the device 1 for the device identification in a message. Or the capability negotiation information sent by device 2 to device 1 may also be carried in messages implemented based on other protocols, such as the path computation element protocol (Path Computation Element Protocol, PCEP). Or the capability negotiation information sent by the device 2 to the device 1 may also be carried in a message in a custom format. The following embodiments of the present application are described with reference to the disclosure of capability negotiation information carried in an extended community attribute of BGP update messages. The embodiment of the application refers to the extended community attribute carrying the capability negotiation information as the capability negotiation extended community attribute.

For example, fig. 11 is a schematic structural diagram of a BGP update message according to an embodiment of the present application. As shown in fig. 11, the BGP update message includes an ethernet header (ETHERNET HEADER), an IP header (IP header), a transmission control protocol (Transmission Control Protocol, TCP) header (TCP HEADER), BGP packets, and a frame check sequence (FRAME CHECK sequence, FCS). Wherein, the BGP data packet comprises a BGP head and a BGP message field. The BGP header includes a flag (maker) field, a length (length) field, and a type (type) field (not shown). The BGP message fields include an address family identifier (ADDRESS FAMILY IDENTIFIER), a subsequent address family identifier (subsequence ADDRESS FAMILY IDENTIFIER), a next-hop network address length (length of next hop network address), a next-hop network address (next hop network address), a reserved (reserved) field, network layer reachability information (network layer reachability information, NLRI), capability negotiation extension community attributes, and other path attributes (path attributes). Wherein the address family identifier, the subsequent address family identifier, the next hop network address length, the next hop network address, the reserved field, and the NLRI are collectively referred to as a multiprotocol reachable NLRI (mp_reach_nlri) attribute. Optionally, the capability negotiation extension community attribute includes a type field, a subtype field, a flag bit field, and a reserved field. It may be defined that when the type field and the subtype field of the extended community attribute are certain values, it is indicated that the extended community attribute is a capability negotiation extended community attribute, i.e. the extended community attribute carries the capability negotiation information described above. In addition, a flag bit field of the capability negotiation extension community attribute may be used to indicate the location of the device identity in the message. Different bits of the flag bit field may be used to indicate different set positions of the device identification in the message. The explanation of other fields in the BGP message field may refer to definitions in RFC 4760 document, and embodiments of the present application are not described herein.

In a first implementation scenario, device 1 and device 2 belong to the same EVPN, i.e., EVI instances belonging to the same EVPN are configured in device 1 and device 2. In other words, device 1 and device 2 are BGP EVPN neighbors to each other. This implementation scenario is the EVPN over MPLS scenario described above. Device 2 may send a BGP EVPN route to device 1 that includes a capability negotiation extension community attribute for carrying capability negotiation information. That is, the capability negotiation information may be published in BGP EVPN routes.

Alternatively, the BGP EVPN route may be a Type1 route (Ethernet auto-discovery route), a Type2 route (MAC/IP route), or a Type3 route (integrated multicast Ethernet label route (inclusive multicast ETHERNET TAG route)) defined in BGP NLRI. Wherein Type1 routing is used to describe the link state and overhead of the device. The Type2 route is used to advertise a host MAC address, a host address resolution protocol (Address Resolution Protocol, ARP) map (i.e., a correspondence between IP addresses and MAC addresses), or a host IP address, i.e., the Type2 route may be used to advertise two-layer routing information and/or three-layer routing information. When a Type2 route is used to advertise a host ARP map, the Type2 route may also be referred to as an ARP Type route. When a Type2 route is used to advertise a host IP address, the Type2 route may also be referred to as an integrated route and bridging (INTEGRATED ROUTING AND BRIDGE, IRB) Type route. Type3 routing is used to build BUM (broadcast), unknown unicast (unknown-unicast), multicast (multicast) trees between network edge devices such as PEs. Of course, the BGP EVPN route may be another type of route defined in BGP NLRI, or may be another type of route that is evolved later, which is not limited by the type of BGP EVPN route in the embodiment of the present application. BGP EVPN routes may carry NLRI in BGP message fields shown in fig. 11.

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

Alternatively, the control word is a 4 byte control word. The 4 byte control word is used to carry the device identification of the device 1. The main idea of this embodiment is that the device 1 negotiates control word capabilities with the device 2, by carrying the device identification of the device 1 in the control word, so that after a message arrives at the device 2, the device 2 can determine that the message comes from the device 1 using the control word information.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the device identification of device 1 is set in the 4 byte control word. For example, taking the length of the flag bit field of the capability negotiation extension group attribute as an example, fig. 12 is a schematic diagram of the configuration of the capability negotiation extension group attribute according to the embodiment of the present application. As shown in fig. 12, by setting the 15 th bit of the flag bit of the capability negotiation extended community attribute to 1, the remaining bits are set to 0 to indicate that the 4-byte control word in the message is set to the device identification of device 1. In this case, the device 1 may generate a message as shown in fig. 8.

For example, in the application scenario shown in fig. 5, the MAC address of the host 3 is SMAC, the MAC address of the host 1 is DMAC, and the destination MAC address of the message sent by the host 3 to the host 1 is DMAC, and the source MAC address is SMAC. The private network labels allocated by PE1 for PE2 and PE3 are Label 1. The public network label allocated by P1 is LSP1, and the public network label allocated by P2 is LSP2. Fig. 13 may refer to a transmission process of a message sent by the host 3 to the host 1 between CE2 and CE1, and fig. 13 is a schematic diagram of message transmission in an EVPN over MPLS scenario according to an embodiment of the present application. Referring to the example shown in fig. 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 through P1, the message generated by PE2 carries a public network Label LSP1, a private network Label1, and a Control Word (CW), where the control word carries a device identifier (CW (PE 2)) of PE 2. Correspondingly, after receiving the message from the PE2, the PE1 analyzes the control word in the message to obtain the equipment identifier of the PE2, and further determines that the message is sent by the PE 2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 carries a public network Label LSP2, a private network Label1 and a control word, and the control word carries the equipment identifier of PE 3. Correspondingly, after receiving the message from the PE3, the PE1 analyzes the control word in the message to obtain the equipment identifier of the PE3, and further determines that the message is sent by the PE 3. Thus, PE1 can support traffic statistics for ingress direction differentiated PEs.

Alternatively, the control word is an 8-byte long control word, 4 bytes of which are used to carry the original control word, and the other 4 bytes of which are used to carry the device identification of the device 1. The main idea of this embodiment is that the device 1 negotiates the long control word (long control word, LCW) capability with the device 2, carrying the original control word at the high 4 bytes of the long control word, and the device identification of the device 1 at the low 4 bytes of the long control word, so that after a message arrives at the device 2, the device 2 can determine that the message comes from the device 1 using the low 4 bytes of the long control word.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the device identification of device 1 is set in the low 4 bytes of the long control word. For example, taking the length of the flag bit field of the capability negotiation extension group attribute as an example, fig. 14 is a schematic diagram of the configuration of another capability negotiation extension group attribute according to the embodiment of the present application. As shown in fig. 14, by setting the 14 th bit of the flag bit of the capability negotiation extended community attribute to 1, the remaining bits are set to 0 to indicate that the low 4 bytes of the long control word in the message are set to the device identification of device 1. In this case, the device 1 may generate a message as shown in fig. 9.

For example, in the application scenario shown in fig. 5, the MAC address of the host 3 is SMAC, the MAC address of the host 1 is DMAC, and the destination MAC address of the message sent by the host 3 to the host 1 is DMAC, and the source MAC address is SMAC. The private network labels allocated by PE1 for PE2 and PE3 are Label 1. The public network label allocated by P1 is LSP1, and the public network label allocated by P2 is LSP2. Fig. 15 may refer to a transmission process of a message sent by the host 3 to the host 1 between CE2 and CE1, and fig. 15 is another schematic diagram of message transmission in an EVPN over MPLS scenario according to an embodiment of the present application. Referring to the example shown in fig. 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 through P1, the message generated by PE2 will carry a public network Label LSP1, a private network Label1, and a Long Control Word (LCW), where the high 4 bytes of the long control word carry the original control word (LCW (0)), and the low 4 bytes of the long control word carry the device identifier (LCW (PE 2)) of PE 2. Correspondingly, after receiving the message from the PE2, the PE1 analyzes the low 4 bytes of the long control word in the message to obtain the equipment identifier of the PE2, and further determines that the message is sent by the PE 2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 carries the public network Label LSP2, the private network Label1, and a Long Control Word (LCW), the high 4 bytes of the long control word carrying the original control word (LCW (0)), and the low 4 bytes of the long control word carrying the device identifier of PE3 (LCW (PE 3)). Correspondingly, after receiving the message from the PE3, the PE1 analyzes the low 4 bytes of the long control word in the message to obtain the equipment identifier of the PE3, and further determines that the message is sent by the PE 3. Thus, PE1 can support traffic statistics for ingress direction differentiated PEs.

In a second possible implementation manner in the first implementation scenario, the capability negotiation information sent by the device 2 to the device 1 is used to negotiate between the device 1 and the device 2 a capability of carrying the device identifier of the device 1 after the stack bottom label of the message.

Optionally, the bottom label is a preconfigured static label, or a dynamic label assigned by device 2, or a designated bSPL. The main idea of this embodiment is that a tag indication capability is negotiated between device 1 and device 2, and the 4 bytes after the stack of tags are indicated by the bottom tag to carry the device identification of device 1, so that after a message arrives at device 2, device 2 can determine that the message came from device 1 using the 4 bytes after the bottom tag.

Optionally, the capability negotiation information sent by the device 2 to the device 1 further indicates that the stack bottom label is set to the above-mentioned preconfigured static label, or the dynamic label assigned by the device 2, or the assigned bSPL, and indicates that the device identifier of the device 1 is set to 4 bytes after the stack bottom label. For example, taking the length of the flag bit field of the capability negotiation extension group attribute as 16 bits (0-15 bits) as an example, fig. 16 is a schematic structural diagram of another capability negotiation extension group attribute according to an embodiment of the present application. As shown in fig. 16, by setting the 13 th bit of the flag bit of the capability negotiation extended community attribute to 1, the remaining bits to 0, this indicates that the bottom label in the message is set to be designated bSPL, and the 4 bytes after the bottom label are set to the device identification of device 1. In this case, the device 1 may generate a message as shown in fig. 10, where the stack bottom label is specified bSPL.

For example, in the application scenario shown in fig. 5, the MAC address of the host 3 is SMAC, the MAC address of the host 1 is DMAC, and the destination MAC address of the message sent by the host 3 to the host 1 is DMAC, and the source MAC address is SMAC. The private network labels allocated by PE1 for PE2 and PE3 are Label 1. The public network label allocated by P1 is LSP1, and the public network label allocated by P2 is LSP2. The transmission process of the message sent by the host 3 to the host 1 between the CE2 and the CE1 may refer to fig. 17, and fig. 17 is a schematic diagram of another message transmission in the EVPN over MPLS scenario according to an embodiment of the present application. Referring to the example shown in fig. 2, when CE2 sends a packet with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the packet is sent from PE2 to PE1 through P1, the packet generated by PE2 carries a public network Label LSP1, a private network Label1, and some stack bottom Label (LabelS), and 4 bytes after the stack bottom Label carry the device identifier (PE 2) of PE 2. Correspondingly, after receiving the message from the PE2, the PE1 analyzes the stack bottom label of the message to determine that 4 bytes after the stack bottom label carry the device identifier, and then obtains the device identifier of the PE2 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by the PE 2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 will carry the public network Label LSP2, the private network Label1 and some kind of stack bottom Label (LabelS), and 4 bytes after the stack bottom Label carry the device identifier (PE 3) of PE 3. Correspondingly, after receiving the message from the PE3, the PE1 analyzes the stack bottom label of the message to determine that 4 bytes after the stack bottom label carry the device identifier, and then obtains the device identifier of the PE3 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by the PE 3. Thus, PE1 can support traffic statistics for ingress direction differentiated PEs.

Optionally, the label at the bottom of the stack is designated eSPL, and when the label stack of the message carries the eSPL, the label stack also carries a special label, where the special label is used to indicate that the label adjacent to the special label is eSPL. The main idea of this embodiment is that an extended tag indication capability is negotiated between device 1 and device 2, and eSPL indicated by the bottom of the stack indicates that the 4 bytes following the tag stack carry the device identification of device 1, so that after a message arrives at device 2, device 2 can determine that the message came from device 1 using the 4 bytes following the bottom of the stack tag.

Optionally, the capability negotiation information sent by device 2 to device 1 also indicates that the bottom of stack tag is set to the specified eSPL, and indicates that the device identification of device 1 is set 4 bytes after the bottom of stack tag. For example, taking the length of the flag bit field of the capability negotiation extension group attribute as 16 bits (0-15 bits) as an example, fig. 18 is a schematic structural diagram of still another capability negotiation extension group attribute according to an embodiment of the present application. As shown in fig. 18, by setting the 12 th bit of the flag bit of the capability negotiation extended community attribute to 1, the remaining bits to 0 indicate that the bottom label in the message is set to be designated eSPL, and the extension label (XL) is set before eSPL, and 4 bytes after the bottom label are set as the device identification of device 1. In this case, the device 1 may generate a message as shown in fig. 10, where the stack bottom label is specified eSPL.

For example, in the application scenario shown in fig. 5, the MAC address of the host 3 is SMAC, the MAC address of the host 1 is DMAC, and the destination MAC address of the message sent by the host 3 to the host 1 is DMAC, and the source MAC address is SMAC. The private network labels allocated by PE1 for PE2 and PE3 are Label1. The public network label allocated by P1 is LSP1, and the public network label allocated by P2 is LSP2. Fig. 19 may be referred to in the transmission process of the message sent by the host 3 to the host 1 between CE2 and CE1, and fig. 19 is a schematic diagram of another message transmission in the EVPN over MPLS scenario according to an embodiment of the present application. Referring to the example shown in fig. 2, when CE2 sends a packet with a destination MAC address of DMAC and a source MAC address of SMAC to CE1, if the packet is sent from PE2 to PE1 through P1, the packet generated by PE2 carries a public network Label LSP1, a private network Label1, an extension Label (XL), and a designated eSPL, and eSPL is a stack bottom Label, where 4 bytes after the stack bottom Label carry a device identifier (PE 2) of PE 2. Correspondingly, after receiving the message from the PE2, the PE1 analyzes the expansion label of the message to determine that eSPL is carried after the expansion label, analyzes eSPL as the stack bottom label to determine that 4 bytes after the stack bottom label carry the device identifier, and obtains the device identifier of the PE2 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by the PE 2. If the message is sent from PE3 to PE1 through P2, the message generated by PE3 carries a public network Label LSP2, a private network Label1, an extension Label (XL), and a designated eSPL, where eSPL is a stack bottom Label, and 4 bytes after the stack bottom Label carry the device identifier (PE 3) of PE3. Correspondingly, after receiving the message from the PE3, the PE1 analyzes the expansion label of the message to determine that eSPL is carried after the expansion label, analyzes the eSPL serving as the stack bottom label to determine that 4 bytes after the stack bottom label carry the device identifier, and obtains the device identifier of the PE3 from the 4 bytes after the stack bottom label, thereby determining that the message is sent by the PE3. Thus, PE1 can support traffic statistics for ingress direction differentiated PEs.

In a second implementation scenario, device 1 and device 2 belong to the same L3VPN, i.e. device 1 and device 2 are configured with VRF instances belonging to the same L3 VPN. In other words, device 1 and device 2 are BGP L3VPN neighbors to each other. This implementation scenario is the MPLS L3VPN scenario described above. The device 2 may send a BGP L3VPN route to the device 1, the BGP L3VPN route comprising a capability negotiation extension community attribute for carrying capability negotiation information. That is, the capability negotiation information may be published in the L3VPN route. The L3VPN route may carry the NLRI in the BGP message field shown in fig. 11.

In one possible implementation manner in the second implementation scenario described above, the capability negotiation information sent by the device 2 to the device 1 is used to negotiate between the device 1 and the device 2 the capability of carrying the device identifier of the device 1 after the stack bottom label in the message. Optionally, the bottom label is a preconfigured static label, or a dynamic label assigned by device 2, or a designated bSPL. Or the label at the bottom of the stack is designated 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 for indicating that the label adjacent to the special label is eSPL. For a specific explanation of this implementation, reference may be made to the second possible implementation in the first implementation scenario, and the embodiments of the present application are not described herein. It should be noted that, in the first implementation scenario, the messages transmitted across sites between hosts are two-layer messages (based on MAC routing), and in the second implementation scenario, the messages transmitted across sites between hosts are three-layer messages (based on IP routing).

The sequence of the steps of the message transmission method provided by the embodiment of the application can be properly adjusted, and the steps can be correspondingly increased or decreased according to the situation. Any method of modification within the scope of the present disclosure will be readily apparent to those skilled in the art, and are intended to be encompassed within the scope of the present disclosure.

Fig. 20 is a flowchart of another method for transmitting a message according to an embodiment of the present application, where an application scenario of the method includes at least a first device and a second device. For example, the application scenario may be an application scenario shown in fig. 5, the first device may be, for example, PE2 or PE3 shown in fig. 5, and the second device may be, for example, PE1 shown in fig. 5. The method is particularly useful for implementing the method 600 shown in the corresponding embodiment of fig. 6. As shown in fig. 20, the method includes, but is not limited to, the following steps 2001 to 2002.

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

In step 2002, the first device sends a message to the second device through an LSP established between the first device and the second device.

When the method is specifically used to implement the method 600 shown in fig. 6 and described above, the first device may be, for example, device 1, and the second device may be, for example, device 2. For the specific implementation of steps 2001 to 2002, reference may be made to steps 601 to 602 in the method 600, which are not described herein.

In a specific implementation, the method further comprises the step that the first equipment receives capability negotiation information sent by the second equipment, wherein the capability negotiation information is used for negotiating the capability of carrying the equipment identifier of the first equipment in the message between the first equipment and the second equipment. The specific implementation of this step may refer to the related description in the embodiment shown in fig. 6, and will not be described herein.

In one particular implementation, the control word is a 4 byte control word.

In a specific implementation, the implementation manner of receiving the capability negotiation information sent by the second device by the first device includes that the first device receives a BGP EVPN route sent by the second device, where the BGP EVPN route includes a capability negotiation extension group attribute, and the capability negotiation extension group attribute is used to carry the capability negotiation information.

In a specific implementation, the first device is an in-operator edge device INGRESS PE and the second device is an out-operator edge device egress PE.

Fig. 21 is a flow chart of another method for transmitting a message according to an embodiment of the present application, where an application scenario of the method includes at least a first device and a second device. For example, the application scenario may be an application scenario shown in fig. 5, the second device may be a PE1 shown in fig. 5, the first device may be a PE2 or a PE3 shown in fig. 5, and the third device may be a P1 or a P2 shown in fig. 5, for example. The method is particularly useful for implementing the method 600 shown in the corresponding embodiment of fig. 6. As shown in fig. 21, the method includes, but is not limited to, the following steps 2101 to 2102.

In step 2101, the second device receives, through an LSP established between the second device and the first device, a packet sent by a third device, where the third device is a label switching device located between the first device and the second device on the LSP, where the packet includes 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.

Step 2102, the second device parses the message to obtain a device identifier of the first device.

When the method is specifically used to implement the method 600 shown in fig. 6 and described above, the second device may be, for example, device 2, and the first device may be, for example, device 1. For the specific implementation of steps 2101 to 2102, reference may be made to steps 602 to 603 in method 600, which are not described here again.

In a specific implementation, the method further comprises the step that the second device determines that the message is from the first device according to the device identification of the first device so as to conduct flow statistics on the message from the first device. For a specific implementation of this step, reference may be made to step 604 in method 600, which is not described here again.

In a specific implementation, the method further comprises the step that the second device sends capability negotiation information to the first device, wherein the capability negotiation information is used for negotiating the capability of carrying the device identifier of the first device in the message between the first device and the second device. The specific implementation of this step may refer to the related description in the embodiment shown in fig. 6, and will not be described herein.

In one particular implementation, the control word is a 4 byte control word.

In a specific implementation, an implementation manner of sending capability negotiation information by a second device to a first device includes that 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.

In a specific implementation, the implementation mode of sending the capability negotiation information to the first device by the second device comprises the step that the second device sends a BGP L3VPN route to the first device, wherein the BGP L3VPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

Fig. 22 is a flow chart of another method for transmitting a message according to an embodiment of the present application, where an application scenario of the method includes at least a first device and a second device. For example, the application scenario may be an application scenario shown in fig. 5, the first device may be, for example, PE2 or PE3 shown in fig. 5, and the second device may be, for example, PE1 shown in fig. 5. The method is particularly useful for implementing the method 600 shown in the corresponding embodiment of fig. 6. As shown in fig. 22, the method includes, but is not limited to, the following step 2201.

Step 2201, 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 an MPLS packet sent by the first device to the second device.

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

In one particular implementation, the control word is a 4 byte control word.

Fig. 23 is a flow chart of another method for transmitting a message according to an embodiment of the present application, where an application scenario of the method includes at least a first device and a second device. For example, the application scenario may be an application scenario shown in fig. 5, the second device may be a PE1 shown in fig. 5, and the first device may be a PE2 or a PE3 shown in fig. 5, for example. The method is particularly useful for implementing the method 600 shown in the corresponding embodiment of fig. 6. As shown in fig. 23, the method includes, but is not limited to, the following steps 2301 to 2302.

In step 2301, the second device generates capability negotiation information, where the capability negotiation information is used to negotiate, between the first device and the second device, a capability of carrying a device identifier of the first device in an MPLS packet sent by the first device to the second device.

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

In one particular implementation, the control word is a 4 byte control word.

In one particular implementation, a first device receives a capability negotiation response sent by a second device.

The virtual device according to the embodiment of the present application is illustrated below.

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

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

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, a capability that carries a device identifier of the first device in a packet.

In one particular implementation, the control word is a 4 byte control word.

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 group attribute, and the capability negotiation extended group attribute is used to carry capability negotiation information.

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

Fig. 25 is a schematic structural diagram of another message transmission device according to an embodiment of the present application. The message transmission device is, for example, a first device. As shown in fig. 25, 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 further includes a sending module 2503.

A receiving module 2501, configured to receive, through an LSP established between the second device and the first device, a packet sent by a third device, where the third device is a label switching device located between the first device and the second device on the LSP, where the packet includes 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 processing module 2502 is configured to parse the message to obtain a device identifier of the first device.

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

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, a capability that carries a device identifier of the first device in a packet.

In one particular implementation, the control word is a 4 byte control word.

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.

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 configured to carry capability negotiation information.

Fig. 26 is a schematic structural diagram of another message transmission device according to an embodiment of the present application. The message transmission device is, for example, a first device. As shown in fig. 26, the message transmission device 2600 includes, but is not limited to, a receiving module 2601. Optionally, the message transmission device 2600 further includes a sending module 2602.

A receiving module 2601, 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 an MPLS packet sent by the first device to the second device.

In one particular implementation, the control word is a 4 byte control word.

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.

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.

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

Fig. 27 is a schematic structural diagram of another message transmission device according to an embodiment of the present application. The message transmission device is, for example, a first device. As shown in fig. 27, 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 further includes a receiving module 2703.

A processing module 2701 is configured to generate capability negotiation information, where the capability negotiation information is used to negotiate, between the first device and the second device, a capability of carrying a device identifier of the first device in an MPLS packet sent by the first device to the second device. A sending module 2702, configured to send the capability negotiation information to the first device.

In one particular implementation, the control word is a 4 byte control word.

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

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

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

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

The following exemplifies the hardware configuration related to the embodiment of the present application.

Fig. 28 is a block diagram of a message transmission device 2800 according to an embodiment of the present application. The message transmission device 2800 is a network device. In one implementation, the message transmitting apparatus 2800 may be a network edge device. As shown in fig. 28, the apparatus 2800 includes a processor 2801 and a memory 2802.

Memory 2802 for storing computer readable instructions;

Processor 2801, which invokes the computer readable instructions, may perform all of the operations performed by device 1 or device 2 in method 600 shown in fig. 6, as indicated by the computer readable instructions.

In a specific embodiment, the apparatus 2800 may also include a communication interface 2803. Wherein the memory 2802, the processor 2801 and the communication interface 2803 are communicatively coupled to each other.

Fig. 29 is a block diagram of another message transmission apparatus 2900 according to an embodiment of the present application. The message transmission apparatus 2900 is a network device. In one implementation, the message transmission apparatus 2900 may be a network edge device. As shown in fig. 29, the apparatus 2900 includes a communication interface 2901, and a processor 2902 connected to the communication interface 2901. Depending on the communication interface 2901 and the processor 2902, the message transmission apparatus 2900 may perform all of the operations performed by device 1 or device 2 in the method 600 shown in fig. 6. The communication interface 2901 is used for performing a transmission/reception operation, and the processor 2902 is used for performing an operation other than the transmission/reception operation. For example, when the apparatus 2900 is the device 1 in the method shown in fig. 6, the communication interface 2901 is used to send a message to the device 2, and the processor 2902 is used to generate the message.

In an embodiment of the application, the processor may be a central processing unit (central processing unit, CPU). A processor may include one or more processing cores that execute various functional applications and data processing by running computer programs. The processor may be coupled to the memory and the communication interface via a communication bus.

The processor may further comprise a hardware chip. The hardware chip may be an Application SPECIFIC INTEGRATED Circuits (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (FPGA) GATE ARRAY, generic array logic (GENERIC ARRAY logic, GAL), or any combination thereof. In one embodiment, the hardware chip may be used to implement encryption/decryption operations.

The memory may include volatile memory (RAM), such as random access memory (random access memory). The memory may also include a non-volatile memory (non-volatile memory), such as a flash memory (flash memory), a hard disk (HARD DISK DRIVE, HDD) or a Solid State Disk (SSD). The memory may also comprise a combination of the above types of memories.

The communication interface may be plural and used for communication with other devices. The communication interface may include a wired communication interface, a wireless communication interface, or a combination thereof. The wired communication interface may be, for example, an ethernet interface. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (wireless local area network, WLAN) interface, a cellular network communication interface, a combination thereof, or the like.

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

The system of the embodiment of the present application is exemplified below.

The embodiment of the application also provides a message transmission system, which comprises a first device and a second device, wherein the first device can be, for example, device 1 in method 600 shown in fig. 6, and the second device can be, for example, device 2 in method 600 shown in fig. 6. Or the first device may be, for example, the message transmission apparatus 2400 shown in fig. 24, and the second device may be, for example, the message transmission apparatus 2500 shown in fig. 25. Alternatively, the first device may be, for example, the message transmission apparatus 2600 shown in fig. 26, and the second device may be, for example, the message transmission apparatus 2700 shown in fig. 27.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

In embodiments of the present application, the terms "first," "second," and "third" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.

The term "and/or" in the present application is merely an association relation describing the association object, and indicates that three kinds of relations may exist, for example, a and/or B may indicate that a exists alone, while a and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

It should be noted that, the information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data for analysis, stored data, presented data, etc.), and signals related to the present application are all authorized by the user or are fully authorized by the parties, and the collection, use, and processing of the related data is required to comply with the relevant laws and regulations and standards of the relevant countries and regions.

The foregoing description of the preferred embodiments of the present application is not intended to limit the application, but is intended to cover any modifications, equivalents, alternatives, and improvements within the spirit and principles of the application.

Claims

1. A method for transmitting a message, the method comprising:

The method comprises the steps that a first device generates a message, wherein the message comprises a multiprotocol label switching (MPLS) header, a device identifier of the first device and a message payload, and the device identifier is encapsulated between the MPLS header and the message payload;

And the first equipment sends the message to the second equipment.

2. The method of claim 1, wherein the device identification of the first device is a router identification, router ID, of the first device.

3. A method according to claim 1 or 2, wherein the message comprises a control word for carrying the device identification.

4. A method according to claim 1 or 2, wherein the message comprises a control word, the device identity being contiguous with the control word.

5. A method according to claim 1 or 2, wherein a bottom label of the MPLS header is used to indicate the device identity adjacent to the bottom label.

6. The method according to any one of claims 1-5, further comprising:

The first device receives capability negotiation information sent by the second device, wherein the capability negotiation information is used for negotiating the capability of carrying the device identifier of the first device in a message between the first device and the second device.

7. The method of claim 6, wherein the capability negotiation information is used to negotiate between the first device and the second device a capability to carry a device identification of the first device in a control word of a message.

8. The method of claim 7, wherein the control word is a 4 byte control word.

9. The method of claim 7, wherein the control word is an 8-byte long control word, 4 bytes of the long control word being used to carry an original control word, and the other 4 bytes of the long control word being used to carry a device identification of the first device.

10. The method of claim 6, wherein the capability negotiation information is used to negotiate between the first device and the second device a capability to carry a device identification of the first device after a bottom label of a message.

11. The method of claim 10, wherein the bottom of stack label is a pre-configured static label, or a dynamic label assigned by the second device, or a designated basic special purpose label bSPL.

12. The method of claim 10 wherein the bottom label is a designated extended special purpose label eSPL, and when the packet label stack carries the eSPL, the label stack further carries a special label, where the special label is used to indicate that a label next to the packet is the eSPL.

13. The method according to any of claims 6-12, wherein the first device receiving capability negotiation information sent by the second device comprises:

And the first equipment receives a border gateway protocol Ethernet virtual private network BGP EVPN route sent by the second equipment, wherein the BGP EVPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

14. The method according to any of claims 6, 10-12, wherein the first device receiving capability negotiation information sent by the second device comprises:

And the first equipment receives a border gateway protocol three-layer virtual private network BGP L3VPN route sent by the second equipment, wherein the BGP L3VPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

15. The method according to any of claims 1-14, wherein the first device is an in-operator edge device INGRESS PE and the second device is an out-operator edge device egress PE.

16. A method for transmitting a message, the method comprising:

A second device receives a message sent by a third device through a label switched path LSP established between the second device and a first device, wherein the third device is a label switched device positioned between the first device and the second device on the LSP, the message comprises a multiprotocol label switching MPLS head, a device identifier of the first device and a message payload, and the device identifier is packaged between the MPLS head and the message payload;

and the second equipment analyzes the message to obtain the equipment identifier of the first equipment.

17. The method of claim 16, wherein the method further comprises:

And the second equipment determines that the message comes from the first equipment according to the equipment identification of the first equipment so as to carry out flow statistics on the message coming from the first equipment.

18. The method of claim 16 or 17, wherein the device identification of the first device is a router ID of the first device.

19. The method according to any of claims 16-18, wherein the message comprises a control word, the control word being used to carry the device identification.

20. The method according to any of claims 16-18, wherein the message comprises a control word, the device identification being contiguous with the control word.

21. The method of any of claims 16-18, wherein a bottom label of the MPLS header is used to indicate that the device is identified adjacent to the bottom label.

22. The method according to any one of claims 16-21, further comprising:

The second device sends capability negotiation information to the first device, wherein the capability negotiation information is used for negotiating the capability of carrying the device identifier of the first device in a message between the first device and the second device.

23. The method of claim 22, wherein the capability negotiation information is used to negotiate between the first device and the second device a capability to carry a device identification of the first device in a control word of a message.

24. The method of claim 23, wherein the control word is a 4 byte control word.

25. The method of claim 23, wherein the control word is an 8-byte long control word, 4 bytes of the long control word being used to carry an original control word, and the other 4 bytes of the long control word being used to carry a device identification of the first device.

26. The method of claim 22, wherein the capability negotiation information is used to negotiate between the first device and the second device a capability to carry a device identification of the first device after a bottom label of a message.

27. The method of claim 26, wherein the bottom of stack label is a pre-configured static label, or a dynamic label assigned by the second device, or a designated basic special purpose label bSPL.

28. The method of claim 26 wherein said bottom label is a designated extended special purpose label eSPL, said label stack further carrying a special label indicating that the next adjacent label is said eSPL when said eSPL is carried in the label stack of the message.

29. The method of any of claims 22-28, wherein the second device sending capability negotiation information to the first device comprises:

And the second device sends a border gateway protocol Ethernet virtual private network BGP EVPN route to the first device, wherein the BGP EVPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

30. The method of any of claims 22, 26-28, wherein the second device sending capability negotiation information to the first device comprises:

And the second device sends a border gateway protocol three-layer virtual private network BGP L3VPN route to the first device, wherein the BGP L3VPN route comprises a capability negotiation extension community attribute, and the capability negotiation extension community attribute is used for carrying the capability negotiation information.

31. The method according to any of claims 16-30, wherein the first device is an in-operator edge device INGRESS PE and the second device is an out-operator edge device egress PE.

32. A method for transmitting a message, the method comprising:

The method comprises the steps that a first device receives capability negotiation information sent by a second device, wherein the capability negotiation information is used for negotiating the capability of carrying a device identifier of the first device in a multiprotocol label switching MPLS message sent by the first device to the second device between the first device and the second device.

33. A method for transmitting a message, the method comprising:

the second equipment generates capability negotiation information, wherein the capability negotiation information is used for negotiating the capability of carrying the equipment identifier of the first equipment in a multiprotocol label switching MPLS message sent by the first equipment to the second equipment between the first equipment and the second equipment;

The second device sends the capability negotiation information to the first device.

34. A messaging system comprising a first device for performing the method of any of claims 1 to 15 and a second device for performing the method of any of claims 16 to 31, or the first device for performing the method of claim 32 and the second device for performing the method of claim 33.

35. A network device, comprising:

Communication interface, and

A processor connected to the communication interface;

A method according to any one of claims 1 to 33, implemented in accordance with the communication interface and the processor.

36. A computer readable storage medium having instructions stored thereon which, when executed by a processor, implement the method of any of claims 1 to 33.

37. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of claims 1 to 33.