CN109861924B

CN109861924B - Message sending and processing method and device, PE node and node

Info

Publication number: CN109861924B
Application number: CN201711243807.8A
Authority: CN
Inventors: 王玉保
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2017-11-30
Filing date: 2017-11-30
Publication date: 2022-06-21
Anticipated expiration: 2037-11-30
Also published as: WO2019105462A1; CN109861924A

Abstract

The invention provides a method and a device for sending and processing a message, a PE node and a node; the method for sending the message comprises the following steps: receiving a first message from a first access circuit AC; processing the first message to obtain one or more second messages; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message; and sending the second message. The problem that the flow characteristics of the message cannot be embodied in the message transmission process in the related technology can be solved, and the load balancing degree is improved.

Description

Message sending and processing method and device, PE node and node

Technical Field

The present invention relates to the field of communications, and in particular, to a method and an apparatus for sending and processing a packet, a PE node, and a node.

Background

In one VPN service, a Network node is divided into a service-aware node and a non-service-aware node, where the service-aware node is a PE node, a virtual extensible local area Network (VXLAN Tunnel End Point, VTEP) node, or a Network Virtual Edge (NVE) node, and the non-service-aware node is a PE node or a single-layer Network (underlay) Network node.

In order to improve the bandwidth utilization of an operator network, operators often deploy load sharing technologies, wherein two widely used load sharing technologies are called Link Aggregation Group (LAG) and Equal Cost Multi-Path (ECMP).

When load balancing is performed by the LAG and ECMP techniques, a quintuple < source IP, destination IP, protocol type, source port, destination port > of an IP packet is generally used as a characteristic field to perform hash calculation and used as an entropy value of the IP packet, and arithmetic remainder operation is performed according to the entropy value to select a forwarding path for the packet from a plurality of forwarding paths. Information used to select a forwarding path for a packet in load balancing is called entropy, which acts in the form of an entropy value in the load balancing routing process.

However, for VPN traffic, the quintuple contains by default only the entropy of the underlay network, and obviously, the load balancing algorithm does not take into account the entropy in the Overlay network.

Fig. 1 is a topology diagram of VXLAN services defined by RFC7348 in the related art, taking the VXLAN services shown in fig. 1 as an example, for a non-service-aware node P1, all VPN service flows between the same pair of < source PE and destination PE >, whether they belong to different services or not, and whether they belong to different flows in the same service or not, are selected on the same forwarding path by the load balancing algorithm of the LAG in which the P1 node is connected to the P2 node (because the five tuples thereof are equal), and the degree of load balancing is relatively low, and the flow characteristics of the message cannot be represented.

In view of the above technical problems in the related art, no effective solution has been proposed at present.

Disclosure of Invention

Embodiments of the present invention provide a method and an apparatus for sending and processing a packet, a PE node, and a node, so as to at least solve a technical problem in the related art that a flow characteristic of an overlay packet cannot be reflected in an underlay packet transmission process.

The embodiment of the invention provides a message sending method, which comprises the following steps: receiving a first message from a first access circuit AC; processing the first message to obtain one or more second messages; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message; and sending the second message.

The embodiment of the invention provides a message processing method, which comprises the following steps: receiving a third message sent by a first Provider Edge (PE), wherein the third message is obtained by processing a fourth message received from a first Access Circuit (AC) of the first PE by the first PE, and the third message comprises: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message; and processing the third message.

The embodiment of the invention provides a message sending device, which comprises: a receiving module, configured to receive a first packet from a first access circuit AC; the processing module is used for processing the first message to obtain one or more second messages; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message; and the sending module is used for sending the second message.

The embodiment of the invention provides a message processing device, which comprises: a receiving module, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by a first PE processing a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message; and the processing module is used for processing the third message.

An embodiment of the present invention provides a PE node, including: a communication interface for receiving a first message from a first access circuit AC; the processor is used for processing the first message to obtain one or more second messages; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message; and the communication interface is used for sending the second message.

An embodiment of the present invention provides a node, including: a communication interface, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by a first PE processing a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message; and the processor is used for processing the third message.

An embodiment of the present invention provides a message processing system, including: a first node and a second node; the first node is configured to receive a first packet from a first access circuit AC, process the first packet to obtain one or more second packets, and send the second packets to the second node; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message; and the second node is used for processing the second message after receiving the second message.

An embodiment of the present invention provides a storage medium, where the storage medium includes a stored program, and where the program executes any one of the methods described above.

The embodiment of the invention provides a processor, which is used for running a program, wherein the program executes the method described in any one of the above.

According to the invention, the first IP address included in the sent second message is the IP address obtained by modifying the second IP address by using the preset entropy value, wherein the preset entropy value is used for identifying the entropy of the first message; that is, entropy information related to entropy of the first packet is carried in the first IP of the second packet, so that a node receiving the second packet can distinguish whether the first packet encapsulated in different received second packets belongs to different data streams to a certain extent, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the flow characteristics of the first packet encapsulated by the second packet can be embodied in the transmission process of the second packet, and thus the problem that the flow characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art can be solved, and the degree of load balancing is improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

fig. 1 is a topology diagram of VXLAN services defined by RFC7348 in the related art;

fig. 2 is a topology diagram of VXLAN EVPN MAC-VRF service defined by draft-ietf-bess-EVPN-Overlay (hereinafter abbreviated as "EVPN Overlay") in the related art;

fig. 3 is a topology diagram of a VXLAN EVPN IP-VRF service defined by draft-ietf-less-EVPN-Prefix-advertisement (hereinafter abbreviated as "EVPN Prefix") in the related art;

fig. 4 is a topology diagram of EVPN VPWS service defined by RFC8214 in the related art;

fig. 5 is a schematic flowchart of a message sending method according to an embodiment of the present invention;

fig. 6 is a schematic flowchart of a message processing method in a process of sending a message from a PE1 node to a P1 node according to an embodiment of the present invention;

fig. 7 is a schematic flowchart of a message processing method in a process of sending a message from a PE1 node to a PE2 node according to an embodiment of the present invention;

fig. 8 is a block diagram of a message sending apparatus according to an embodiment of the present invention;

fig. 9 is a block diagram of a message processing apparatus according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a PE node according to an embodiment of the present invention;

FIG. 11 is a block diagram of a node provided in accordance with an embodiment of the present invention;

fig. 12 is a schematic structural diagram of a PE node provided in accordance with a preferred embodiment of the present invention;

fig. 13 is a schematic structural diagram of a non-traffic-aware node provided in accordance with a preferred embodiment of the present invention;

fig. 14 is a simplified comparison of VXLAN packaging and SRv6 packaging provided in accordance with a preferred embodiment of the present invention;

fig. 15 is a detailed comparison of VXLAN encapsulation and SRv6 encapsulation provided in accordance with a preferred embodiment of the present invention;

FIG. 16 is a diagram of one possible packing format for an ERH (inverse Routing header) header provided in accordance with a preferred embodiment of the present invention;

fig. 17 is a comparison of SRv 6-encapsulated SRH header format with and without SRH header format provided in accordance with a preferred embodiment of the present invention.

Detailed Description

The invention will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

EVPN service is an important VPN service, RFC7432 defines its control plane framework, in which four routes, such as Ethernet Auto-discovery Route, MAC/IP Advertisement Route, Inclusive Multicast Ethernet Tag Route, Ethernet Segment Route, are called RT-1, RT-2, RT-3 and RT-4 routes, respectively. The draft-ietf-less-EVPN-Prefix-advertisement defines the IP Prefix Route of the EVPN service to be called as the RT-5 Route.

RFC6790 refers to a factor for load balancing in a message as entropy, and the method carries a label containing an entropy value in the message, where the label containing the entropy includes entropy of an overlay network, but the method depends on MPLS technology, and requires that an underlay network must support MPLS technology, that is, it depends on MPLS encapsulation. In the IPv4 network that does not support the MPLS technology, there is no method for carrying entropy in the packet in the related art, so the load balancing is not uniform.

Furthermore, in IPv6 networks that do not support MPLS technology, the Flow-label field of the IPv6 header is designed to replace the function of the Type of Service (ToS) field of the IPv4 header, but since the specific details of use of this field have not been well defined by the standard for decades from RFC2460 to RFC3697 to RFC6437, this field carries entropy values that in practice require that all non-traffic-aware nodes in the underlay network support this field for load-balanced routing and not for other purposes, or that the pseudo-randomness of the entropy values interferes with the achievement of other purposes.

The entropy of the existing RFC6790 refers to the entropy generated according to the characteristic field of the message itself, so that the representation of the context information of the message is lacked, and the context information includes an interface of the message entering device, a service to which the message belongs, a node to which the message belongs, and the like, so that there is room for further improving the uniformity of the load balancing.

In some cases, users do not want to expose their own specific IP addresses in the underlay network.

In order to overcome the above problems, the present invention provides the following embodiments:

example 1

An embodiment of the present invention provides a method for sending a packet, where the method may be applied to the topology described in fig. 1, but is not limited to this, and for example, the method may also be applied to the topology shown in fig. 2, the topology shown in fig. 3, or the topology shown in fig. 4, where fig. 2 is a topology diagram of a VXLAN EVPN MAC-VRF service defined by [ EVPN Overlay ] in the related art; fig. 3 is a topology diagram of VXLAN EVPN IP-VRF service defined by EVPN Prefix in the related art; fig. 4 is a topology diagram of EVPN VPWS service defined by RFC8214 in the related art. The main execution body of the transmission method may be a PE node, and taking the topology shown in fig. 1 as an example, the main execution body of the transmission method may be a PE1 node, a PE2 node, or a PE3 node shown in fig. 1, but is not limited thereto.

The following description will be given taking as an example that the main execution body of the transmission method is the PE1 node shown in fig. 1, and the transmission flow of the message is transmitted from the CE1 to the non-service-aware node P1 in the underlay network via the PE1 node. Fig. 5 is a schematic flowchart of a message sending method according to an embodiment of the present invention, and as shown in fig. 5, the method includes:

step S502, the PE1 node receives a first message from the first access circuit AC of the PE1 node; the access circuit AC is an interface or a subinterface or a virtual circuit between the PE node and a customer edge CE node, wherein the PE node comprises a VTEP node and an NVE node.

Step S504, PE1 node processes the first message to obtain one or more second messages; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message;

in step S506, the PE1 node sends a second message to the P1 node.

It should be noted that, an entropy value E (such as the predetermined entropy value) identifies an entropy of a message P (such as the first message), which means that the entropy value E is a value obtained by calculating one or more pieces of specifying information corresponding to the message P by using a specified algorithm F, and when any one of the pieces of specifying information corresponding to the message P is randomly changed, the entropy value E calculated by using the algorithm F also has a predetermined probability to be changed.

It should be noted that the predetermined probability is determined by the algorithm F, the total number of bits occupied by all the specifying information, the total number of bits occupied by the changed specifying information, and the total number of bits occupied by the entropy value E.

Through the steps, the first IP address included in the sent second message is the IP address obtained by modifying the second IP address by using the preset entropy value, wherein the preset entropy value is used for identifying the entropy of the first message; that is, entropy information related to entropy of the first packet is carried in the first IP of the second packet, so that a node receiving the second packet can distinguish whether the first packet encapsulated in different received second packets belongs to different data streams to a certain extent, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the flow characteristics of the first packet encapsulated by the second packet can be embodied in the transmission process of the second packet, and thus the problem that the flow characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art can be solved, and the degree of load balancing is improved.

It should be noted that, the first IP address may be located in at least one of the following positions of the second packet: source IP, destination IP, internet protocol version 6 IPv6 option header. The method for carrying the entropy values in the messages is realized by placing the first IP address at least one of the source IP, the destination IP and the IPv6 option header of the Internet protocol version 6 of the second message, namely, by carrying the entropy values of the first message in at least one of the source IP, the destination IP and the IPv6 option header of the second message, without MPLS encapsulation of the messages, namely, in an IPv4 or IPv6 network which does not support MPLS, so that the problem of uneven load balance in the IPv4 and IPv6underlay networks is solved under the condition that non-service perception node upgrading in the underlay networks is not needed and the MPLS technology is not relied.

Optionally, in a case that the first IP address is located in an IPv6 option header of the second packet, indicating whether the predetermined entropy value exists in the IPv6 option header by one of: indicated by a Next-header field in the IPv6 header of the second message, indicated by a field in the IPv6 option header.

The IPv6 header may be an IPv6 option header or an IPv6 mandatory header, but is not limited thereto.

It should be noted that the second IP address may be a source IP or a destination IP of the second packet obtained by performing corresponding processing on the first packet when the function switch of the present invention is not turned on, but is not limited thereto. When the first IP address is in the IPv6 option header, the second IP address may be copied into an IPv6 option header, and the copy of the second IP address in the IPv6 option header modified with the predetermined entropy value.

Note that, the processing in step S504 may be expressed as: packaging, modifying, but not limited to.

It is noted that modifying the second IP address using the predetermined entropy value includes at least one of: replacing a value for a specified location in the second IP address with a predetermined entropy value, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value; replacing the value of the designated location in the second IP address with a result of a calculation of the predetermined entropy value and the value of the designated location in the second IP address, wherein the predetermined entropy value is one of: intrinsic entropy, context entropy, synthetic entropy; encrypting the value of the specified position in the second IP address by using the preset entropy value, wherein the preset entropy value is an intrinsic entropy value; the intrinsic entropy value is an entropy value obtained by performing hash calculation on one or more characteristic fields in the first message; the context entropy value is an entropy value obtained by mapping one or more pieces of feature configuration information corresponding to the first AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the first message and the context entropy value of the first message.

It should be noted that the entropy value of the FRC6790 refers to an entropy value generated according to a characteristic field of a message itself, so that there is no embodiment of context information of the message, where the context information includes an interface of a message entering device, a service to which the message belongs, a node to which the message belongs, and the like.

In the embodiment of the invention, the predetermined entropy value comprises an intrinsic entropy value, the value of the designated position in the second IP address is encrypted by the predetermined entropy value, namely the second IP address is encrypted by the intrinsic entropy value of the first message, the entropy of the first message is added into the message, and the IP address on the PE1 node is encrypted, so that the problem of uneven load balance in IPv4 and IPv6underlay networks can be solved without upgrading non-service perception nodes in the underlay networks and without depending on MPLS technology, and the IP addresses can be ensured not to be exposed.

It should be noted that the characteristic field may include at least one of the following: a source IP, a destination IP, a protocol type, a source port, a destination port, a ToS field of IPv4 and a Flow-label field of IPv6 of the first message; the source media access control MAC and the destination MAC of the first message; the Ethernet type, the inner and outer layer virtual local area network identification VLAN ID and the 802.1p priority of the first message. The 802.1p priority refers to a priority field defined by 802.1p, and includes a priority in a Tag with a Tag Protocol Identifier (TPID) of 0x8100 or 0x88a 8.

The feature configuration information corresponding to the first AC may include at least one of: information mapped by the first AC; node level configuration information obtained by a node where the first AC is located; information mapped by a master interface to which the first AC belongs; the information is obtained by carrying out Hash calculation on the Ethernet segmented identifier ESI corresponding to the main interface to which the first AC belongs; ESI itself corresponding to the main interface to which the first AC belongs; ESI IPs corresponding to ESIs corresponding to a main interface to which the first AC belongs, where the ESI IPs are one IP address configured for the ESI, and the ESI IPs are different from ESI IPs corresponding to other ESIs on a node to which the ESI belongs.

In an embodiment of the present invention, the comprehensive entropy value may be obtained according to at least one of the following methods, but is not limited thereto: carrying out bitwise logical XOR operation on the intrinsic entropy and the context entropy to obtain the comprehensive entropy; calculating by the intrinsic entropy, the context entropy and any N constants to obtain the comprehensive entropy; wherein N is an integer greater than or equal to 1.

It should be noted that the above calculation may be a hash calculation, but is not limited thereto.

In an embodiment of the present invention, the service type to which the first AC belongs may include at least one of: a Virtual Private Network (VPN) forwarded based on the MAC header of the first packet in the VPN; a VPN forwarded in a VPN based on the IP header of the first packet (see preferred embodiment 9 for how to give a VPN forwarded in a VPN based on the IP header of the first packet); a VPN where forwarding is performed according to the configuration information on the first AC in the VPN (see preferred embodiment 11 for how to forward a VPN where forwarding is performed according to the configuration information on the first AC in the VPN).

In an embodiment of the present invention, the step S504 may also be expressed as at least one of the following, but is not limited thereto: the PE1 node packages the first message by an extensible virtual local area network VXLAN; the PE1 node performs VXLAN general protocol extension GPE encapsulation on the first message; the PE1 node performs general Network Virtualization Encapsulation (Generic Network Virtualization Encapsulation, referred to as "general") on the first message; the PE1 node performs Network Virtualization general Routing Encapsulation (NVGRE for short) Encapsulation on the first packet; the PE1 node encapsulates the first packet by extension SRv6(Segment Routing insulated on the IPv6 dataplane, SRv6 for short).

It should be noted that the Segment route SRv6 may be "implemented in IPv6 data plane" or "implemented in IPv6 data plane" (SRv6 relays to Segment Routing established on the IPv6 data plane).

Although the above description has been made with PE1 as the execution agent, the present invention is not limited to PE1 as the execution agent, and PE2, PE3, and the like may be used, and the present invention is not limited thereto.

An embodiment of the present invention further provides a method for processing a packet, where the method may also be applied to the topology shown in any one of fig. 1 to fig. 4, and the following description still takes fig. 1 as an example, an execution main body of the method for processing a packet may be any one of a PE1, a PE2, a PE3, a P1, and a P2 in fig. 1, where both P1 and P2 are non-service aware nodes, the execution main body of the method is a P1 node shown in fig. 1, and a transmission flow of a packet is described as an example of transmitting a packet from a PE1 node to a non-service aware node P1 or to a PE2 in an underlay network. Fig. 6 is a schematic flowchart of a message processing method in a process of sending a message from a PE1 node to a P1 node according to an embodiment of the present invention, as shown in fig. 6, the method includes:

step S602, a P1 node receives a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by the first PE processing a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

in step S604, the P1 node processes the third packet.

It should be noted that the first PE may be a PE1 node. The third packet corresponds to the second packet in the embodiment shown in the transmission method of the packet, and the fourth packet corresponds to the first packet in the embodiment of the transmission method of the packet.

According to the method, the first IP address included in the received third message is the IP address obtained by modifying the second IP address by using the preset entropy value, wherein the preset entropy value is used for identifying the entropy of the fourth message; that is, the entropy information related to the entropy of the fourth packet is carried in the IP of the third packet, so that the P1 can distinguish, to a certain extent, whether the first packet encapsulated in different received second packets belongs to different data streams, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the stream characteristics of the encapsulated first packet can be embodied in the transmission process of the second packet, thereby solving the problem that the stream characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art, and improving the degree of load balancing.

It should be noted that the first IP address is located in at least one of the following positions of the third packet: source IP, destination IP, internet protocol version 6 IPv6 option header.

It should be noted that, in the case that the first IP address is located in the IPv6 option header of the second packet, whether the predetermined entropy value exists in the IPv6 option header is indicated by one of the following manners: indicated by a Next-header field in an IPv6 header of the third packet, and indicated by a field in the IPv6 option header.

It should be noted that the destination IP of the third packet is a remote IP address on a node receiving the third packet, that is, the execution subject of the processing method may be a P1 node, and the step S604 may be at least one of the following: the P1 node selects load balancing forwarding information according to the first IP address, and the P1 node forwards the third message according to the load balancing forwarding information; the node P1 regards the binary digits corresponding to the predetermined entropy carried in the first IP address as predetermined values, and performs other processing except forwarding on the third packet; and the P1 node directly forwards the third message.

It should be noted that the load balancing forwarding information may be information that the P1 node selects a forwarding path for the third packet in the load balancing process.

It should be noted that the predetermined entropy may be the same as the predetermined entropy in the embodiment shown in fig. 5, and the description thereof is omitted here.

Fig. 7 is a schematic flowchart of a message processing method in a process of sending a message from a PE1 node to a PE2 node according to an embodiment of the present invention, as shown in fig. 7, the method includes:

in step S702, a PE2 node receives a third packet sent by a first service provider edge device PE, where the third packet is obtained by the first PE processing a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

in step S704, the PE2 node processes the third packet.

It should be noted that, the step S702 may be represented as: PE2 directly receives the third packet sent by PE1, or may receive the third packet sent by PE1 by means of forwarding in P1 or P2, but is not limited thereto.

It should be noted that, in the case that the first IP address is located in the IPv6 option header of the second packet, whether the predetermined entropy value exists in the IPv6 option header is indicated by one of the following manners: indicated by the Next-header field in the IPv6 header of the third packet, through a field in the IPv6 option header.

When the destination IP of the third packet is the IP address configured for the PE2 node, that is, in the case that the execution body for processing the third packet is PE2, the step S704 may be as follows: setting binary bits in the first IP address in the third message, which are modified by the predetermined entropy value, to a predetermined value; wherein the preset values set by different binary bits are the same or different; recalculating the predetermined entropy value, and decrypting the part encrypted by the predetermined entropy value in the first IP address in the third message by using the recalculated predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; stripping an IPv6 option header in the third message that includes the first IP address; and directly processing the third message.

It should be noted that, for the explanation of the above predetermined entropy, the intrinsic entropy, etc., reference may be made to the explanation of the predetermined entropy, the intrinsic entropy, etc. in the embodiment shown in fig. 5, which is not described herein again, and thanks to the explanation.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

Example 2

In this embodiment, a message sending apparatus is further provided, and the apparatus is used to implement the foregoing embodiments and preferred embodiments, and details of which have been already described are omitted. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

It should be noted that the sending apparatus of the packet provided in the embodiment of the present invention may be located on a PE node shown in any one of fig. 1 to fig. 4, such as a PE1 node, a PE2 node, or a PE3 node shown in fig. 1, but is not limited thereto.

Fig. 8 is a block diagram of a structure of a message sending apparatus according to an embodiment of the present invention, and as shown in fig. 8, the apparatus includes:

a receiving module 82, configured to receive a first message from the first access circuit AC;

a processing module 84, connected to the receiving module 82, configured to process the first packet to obtain one or more second packets; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message;

and a sending module 86, connected to the processing module 84, for sending the second message.

By the device, the first IP address included in the sent second message is the IP address obtained by modifying the second IP address by using the preset entropy value, wherein the preset entropy value is used for identifying the entropy of the first message; that is, entropy information related to entropy of the first packet is carried in the first IP of the second packet, so that a node receiving the second packet can distinguish whether the first packet encapsulated in different received second packets belongs to different data streams to a certain extent, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the flow characteristics of the first packet encapsulated by the second packet can be embodied in the transmission process of the second packet, and thus the problem that the flow characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art can be solved, and the degree of load balancing is improved.

It should be noted that the access circuit AC is an interface or a subinterface or a virtual circuit between the PE node and the customer edge CE node, where the PE node includes a VTEP node and an NVE node; the entropy value E (e.g., the predetermined entropy value) identifies the entropy of the message P (e.g., the first message), and means that the entropy value E is a value calculated by a specific algorithm F on one or more pieces of specific information corresponding to the message P, and when any one of the pieces of specific information corresponding to the message P changes randomly, the entropy value E calculated by the algorithm F also changes with a predetermined probability.

It should be noted that, the first IP address may be located in at least one of the following positions of the second packet: source IP, destination IP, internet protocol version 6 IPv6 option header. The method for carrying the entropy values in the messages is realized by placing the first IP address at least one of the source IP, the destination IP and the IPv6 option header of the version 6 of the Internet protocol of the second message, namely, carrying the entropy values of the first message in at least one of the source IP, the destination IP and the IPv6 option header of the version 6 of the Internet protocol of the second message without MPLS encapsulation, namely, in an IPv4 or IPv6 network which does not support MPLS, so that the problem of uneven load balance in the IPv4 and IPv6underlay networks is solved under the condition that the upgrading of non-service perception nodes in the underlay networks is not needed and the MPLS technology is not relied.

It should be noted that, in the case that the first IP address is located in the IPv6 option header of the second packet, whether the predetermined entropy value exists in the IPv6 option header is indicated by one of the following manners: indicated by a Next-header field in the IPv6 header of the second message, indicated by a field in the IPv6 option header.

It should be noted that the above processing may be expressed as: packaging, modifying, but not limited to.

It is noted that modifying the second IP address using the predetermined entropy value includes at least one of: replacing a value of a specified location in the second IP address with a predetermined entropy value, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value; replacing the value of the designated location in the second IP address with a result of a calculation of the predetermined entropy value and the value of the designated location in the second IP address, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value; encrypting the value of the specified position in the second IP address by using the preset entropy value, wherein the preset entropy value is an intrinsic entropy value; the intrinsic entropy value is an entropy value obtained by performing hash calculation on one or more characteristic fields in the first message; the context entropy value is an entropy value obtained by mapping one or more feature configuration information corresponding to the first AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the first message and the context entropy value of the first message.

In the embodiment of the present invention, the predetermined entropy includes an intrinsic entropy, and the value of the specified position in the second IP address is encrypted by the predetermined entropy, that is, the second IP address is encrypted by the intrinsic entropy of the first message, and the entropy of the first message is added to the message and the IP address on the PE1 node is encrypted, so that the problem of uneven load balance in IPv4 and IPv6underlay networks can be solved without upgrading non-service aware nodes in the underlay networks and without relying on MPLS technology, and the IP address can be ensured not to be exposed.

It should be noted that the characteristic field may include at least one of the following: a source IP, a destination IP, a protocol type, a source port, a destination port, a ToS field of IPv4 and a Flow-label field of IPv6 of the first message; the source media access control MAC and the destination MAC of the first message; the Ethernet type, the inner and outer layer virtual local area network identification VLAN ID and the 802.1p priority of the first message; the 802.1p priority refers to a priority field defined by 802.1p, and includes a priority in a Tag with a Tag Protocol Identifier (TPID) of 0x8100 or 0x88a 8.

The feature configuration information corresponding to the first AC may include at least one of: information mapped by the first AC; node level configuration information obtained by a node where the first AC is located; information mapped by a master interface to which the first AC belongs; information obtained by performing hash calculation on an Ethernet segment identifier ESI corresponding to a main interface to which the first AC belongs; ESI itself corresponding to the main interface to which the first AC belongs; ESI IPs corresponding to ESIs corresponding to a main interface to which the first AC belongs, where the ESI IPs are one IP address configured for the ESI, and the ESI IPs are different from ESI IPs corresponding to other ESIs on a node to which the ESI belongs.

In an embodiment of the present invention, the processing module 84 may be further configured to obtain the integrated entropy according to at least one of the following methods, but is not limited thereto: carrying out bitwise logical XOR operation on the intrinsic entropy and the context entropy to obtain the comprehensive entropy; calculating by the intrinsic entropy value, the context entropy value and any N constants to obtain the comprehensive entropy value; wherein N is an integer greater than or equal to 1. It should be noted that the above calculation may be a hash calculation, but is not limited thereto.

In an embodiment of the present invention, the service type to which the first AC belongs may include at least one of: a Virtual Private Network (VPN) forwarded based on the MAC header of the first packet in the VPN; a VPN forwarded based on the IP header of the first packet in the VPN; and the VPN is forwarded in the VPN according to the configuration information on the first AC.

In an embodiment of the present invention, the processing module 84 may be further used for at least one of the following, but is not limited thereto: performing extensible virtual local area network VXLAN packaging on the first message; carrying out VXLAN general protocol extension GPE encapsulation on the first message; performing general network virtualization encapsulation (Geneve encapsulation) on the first message; performing Network Virtualization using general Routing Encapsulation (NVGRE for short) Encapsulation on the first message; and expanding SRv6 and packaging the first message.

An embodiment of the present invention further provides a device for processing a packet in a topology shown in any one of fig. 1 to 4, where it should be noted that the device for processing a topology packet may be located in a PE node (for example, PE1, PE2, and PE3 are not limited thereto) or a non-service sensing node (P1 or P2) shown in any one of fig. 1 to 4, and fig. 9 is a block diagram of a structure of the device for processing a packet provided in an embodiment of the present invention, and as shown in fig. 9, the device includes:

a receiving module 92, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by processing, by the first PE, a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

and a processing module 94, connected to the receiving module 92, for processing the third packet.

The third packet corresponds to the second packet in the embodiment shown in fig. 8, and the fourth packet corresponds to the first packet in the embodiment shown in fig. 8. The first PE is not limited to the PE node where the device shown in fig. 8 is located.

By the device, the first IP address included in the received third message is the IP address obtained by modifying the second IP address by using the preset entropy value, wherein the preset entropy value is used for identifying the entropy of the fourth message; that is, the entropy information related to the entropy of the fourth packet is carried in the IP of the third packet, so that the P1 can distinguish, to a certain extent, through the predetermined entropy, whether the first packet encapsulated in different second packets received belongs to different data streams, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > duplets, that is, the stream characteristics of the encapsulated first packet can be embodied in the transmission process of the second packet, and thus the problem that the stream characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art can be solved, and the degree of load balancing is improved.

It should be noted that, in the case that the first IP address is located in the IPv6 option header of the second packet, whether the predetermined entropy value exists in the IPv6 option header is indicated by one of the following manners: indicated by a Next-header field in the IPv6 header of the third packet, indicated by a field in the IPv6 option header.

It should be noted that, the destination IP of the third packet is a remote IP address on a node receiving the third packet, that is, the processing device is located in the node P1, and the processing module 94 may be further configured to at least one of: selecting load balancing forwarding information according to the first IP address, and forwarding the third message according to the load balancing forwarding information; respectively regarding binary digits corresponding to the predetermined entropy carried in the first IP address as predetermined values, and performing other processing except forwarding on the third message; and directly forwarding the third message.

It should be noted that the load balancing forwarding information may be information for selecting a forwarding path for the third packet in the load balancing process.

When the destination IP of the third packet is an IP address configured for the PE node, that is, when the processing apparatus is located in the PE node, the processing module 94 may be further configured to at least one of: setting binary bits in the first IP address in the third message, which are modified by the predetermined entropy value, to a predetermined value; wherein the preset values set by different binary bits are the same or different; recalculating the predetermined entropy value, and decrypting the part encrypted by the predetermined entropy value in the first IP address in the third message by using the recalculated predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; stripping an IPv6 option header in the third message that includes the first IP address; and directly processing the third message.

It should be noted that the predetermined entropy may be the same as the predetermined entropy in the embodiment shown in fig. 8, and the description thereof is omitted here.

It should be noted that, the above modules may be implemented by software or hardware, and for the latter, the following may be implemented, but not limited to: the modules are all positioned in the same processor; alternatively, the modules are respectively located in different processors in any combination.

Example 3

An embodiment of the present invention further provides a PE node, where the PE node may be a PE node shown in any one of fig. 1 to 4, such as a PE1 node, a PE2 node, or a PE3 node shown in fig. 1, and fig. 10 is a schematic structural diagram of the PE node provided in an embodiment of the present invention, and as shown in fig. 10, the PE node includes:

a communication interface 1002, configured to receive a first message from a first access circuit AC;

a processor 1004 connected to the communication interface 1002, configured to process the first packet to obtain one or more second packets; wherein, the second message includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message;

the communication interface 1002 is further configured to send a second message.

Through the PE node, the first IP address included in the sent second message is an IP address obtained by modifying the second IP address by using a preset entropy value, wherein the preset entropy value is used for identifying the entropy of the first message; that is, entropy information related to entropy of the first packet is carried in the first IP of the second packet, so that a node receiving the second packet can distinguish whether the first packet encapsulated in different received second packets belongs to different data streams to a certain extent, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the flow characteristics of the first packet encapsulated by the second packet can be embodied in the transmission process of the second packet, and thus the problem that the flow characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art can be solved, and the degree of load balancing is improved.

It should be noted that the access circuit AC is an interface, a subinterface, or a virtual circuit between the PE node and the customer edge CE node, where the PE node includes a VTEP node and an NVE node; the entropy value E (e.g., the predetermined entropy value) identifies the entropy of the message P (e.g., the first message), and means that the entropy value E is a value calculated by a specific algorithm F on one or more pieces of specific information corresponding to the message P, and when any one of the pieces of specific information corresponding to the message P changes randomly, the entropy value E calculated by the algorithm F also changes with a predetermined probability.

It should be noted that, the first IP address may be located in at least one of the following positions of the second packet: source IP, destination IP, internet protocol version 6 IPv6 option header. The entropy value of the first message is carried in at least one of the source IP, the target IP and the IPv6 option header of the second message, namely the entropy value of the first message is carried in at least one of the source IP, the target IP and the IPv6 option header of the second message, the message does not need to be subjected to MPLS encapsulation, namely a method for carrying the entropy value in the message is realized in an IPv4 or IPv6 network which does not support MPLS, and the problem of uneven load balance in IPv4 and IPv6underlay networks is solved under the condition that the upgrading of non-service perception nodes in the underlay networks is not needed and the MPLS technology is not relied.

It is noted that modifying the second IP address using the predetermined entropy value includes at least one of: replacing a value for a specified location in the second IP address with a predetermined entropy value, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value; replacing the value of the designated location in the second IP address with a result of a calculation of the predetermined entropy value and the value of the designated location in the second IP address, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value; encrypting the value of the specified position in the second IP address by using the preset entropy value, wherein the preset entropy value is an intrinsic entropy value; the intrinsic entropy value is an entropy value obtained by performing hash calculation on one or more characteristic fields in the first message; the context entropy value is an entropy value obtained by mapping one or more pieces of feature configuration information corresponding to the first AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the first message and the context entropy value of the first message.

In an embodiment of the present invention, the processor 1004 may be further configured to obtain the comprehensive entropy according to at least one of the following methods, but is not limited thereto: carrying out bitwise logical XOR operation on the intrinsic entropy and the context entropy to obtain the comprehensive entropy; calculating by the intrinsic entropy, the context entropy and any N constants to obtain the comprehensive entropy; wherein N is an integer greater than or equal to 1. It should be noted that the above calculation may be a hash calculation, but is not limited thereto.

In an embodiment of the present invention, the processor 1004 may be further configured to at least one of the following, but is not limited thereto: performing extensible virtual local area network VXLAN packaging on the first message; carrying out VXLAN general protocol extension GPE encapsulation on the first message; performing general network virtualization encapsulation (Geneve encapsulation) on the first message; performing Network Virtualization using general Routing Encapsulation (NVGRE for short) Encapsulation on the first message; and expanding SRv6 and packaging the first message.

An embodiment of the present invention further provides a node, where the node may be a PE node (for example, PE1, PE2, and PE3 are not limited thereto) or a non-service aware node (P1 or P2) shown in any one of fig. 1 to fig. 4, and fig. 11 is a block diagram of a structure of the node according to the embodiment of the present invention, and as shown in fig. 11, the apparatus includes:

the communication interface 1102 is configured to receive a third packet sent by the first service provider edge device PE, where the third packet is a packet obtained by the first PE processing a fourth packet received from the first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying the second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

and the processor 1104 is connected to the communication interface 1102 and configured to process the third packet.

Through the node, modifying the second IP address by using a predetermined entropy value through a first IP address included in the received third message, wherein the predetermined entropy value is used for identifying the entropy of the fourth message; that is, the entropy information related to the entropy of the fourth packet is carried in the IP of the third packet, so that the P1 can distinguish, to a certain extent, whether the first packet encapsulated in different received second packets belongs to different data streams, for example, whether the first packet belongs to different services, and whether the first packet belongs to different < source MAC, destination MAC > tuples, that is, the stream characteristics of the encapsulated first packet can be embodied in the transmission process of the second packet, thereby solving the problem that the stream characteristics of the overlay packet cannot be embodied in the transmission process of the underlay packet in the related art, and improving the degree of load balancing.

The third packet corresponds to the second packet in the embodiment shown in fig. 10, and the fourth packet corresponds to the first packet in the embodiment shown in fig. 10. The first PE is the PE node shown in fig. 10, but is not limited thereto.

It should be noted that, the destination IP of the third packet is a remote IP address on a node receiving the third packet, that is, the node is a non-service-aware node, and the processor 1104 is further configured to at least one of: selecting load balancing forwarding information according to the first IP address, and forwarding the third message according to the load balancing forwarding information; respectively regarding binary digits corresponding to the predetermined entropy carried in the first IP address as predetermined values, and performing other processing except forwarding on the third message; and directly forwarding the third message.

When the destination IP of the third packet is an IP address configured for a PE node, that is, when the node is a PE node, the processor 1104 is further configured to at least one of: setting binary bits in the first IP address in the third message, which are modified by the predetermined entropy value, to a predetermined value; wherein the preset values set by different binary bits are the same or different; recalculating the predetermined entropy value, and decrypting the part encrypted by the predetermined entropy value in the first IP address in the third message by using the recalculated predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; stripping an IPv6 option header in the third message that includes the first IP address; and directly processing the third message.

It should be noted that the predetermined entropy may be the same as the predetermined entropy in the embodiment shown in fig. 10, and the description thereof is omitted here.

Example 4

The embodiment of the present invention further provides a system for processing a packet, including: a first node and a second node; the first node is configured to receive a first packet from a first access circuit AC, process the first packet to obtain one or more second packets, and send the second packets to the second node; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message; and the second node is used for processing the second message after receiving the second message.

It should be noted that the first node may be a PE node shown in fig. 10 in the foregoing embodiment 3, and the second node may be a node (PE node or non-traffic-aware node) shown in fig. 11 in the foregoing embodiment 3. For the explanation of the first node and the second node, see embodiment 3 for details, which are not described herein again.

Example 5

An embodiment of the present invention further provides a storage medium including a stored program, where the program executes any one of the methods described above.

Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing program codes, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Embodiments of the present invention also provide a processor configured to execute a program, where the program executes to perform any of the steps in the method.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

For a better understanding of the embodiments of the present invention, the present invention is further explained below with reference to preferred embodiments.

The technical scheme provided by the preferred embodiment of the invention can at least achieve the following technical effects: by adopting the entropy IP transceiving node provided by the preferred embodiment of the invention as the PE node, the problem that the flow characteristics of overlay messages cannot be reflected by load balance on the non-service-aware node of the existing underlay network is solved on the premise that the non-service-aware node of the existing underlay network is not upgraded and the underlay network is not required to support the MPLS technology. In addition, because the entropy value can be carried in the source IP and/or the destination IP, the defects that the load balance is uneven, the existing non-service-aware node of the underlay network needs to be upgraded and the underlay network is required to support the MPLS technology can be overcome, and the effect of using a unified technology to solve the problem of uneven load balance in the IPv4 and IPv6underlay networks on the premise that the upgrading of the non-service-aware node in the underlay network is not needed is achieved. Since the context entropy value is identified, the uniformity of the load balancing is further improved by further carrying the context entropy value. Furthermore, by encrypting the source IP or the destination IP by using the intrinsic entropy value of the Overlay message, the entropy of the Overlay message is added in the underlay IP header, and the IP address on the PE node is encrypted, so that the problems can be solved at the same time, and the effect of the entropy value can achieve a comprehensive effect.

Fig. 12 is a schematic structural diagram of a PE node according to a preferred embodiment of the present invention, as shown in fig. 12, including: the PE node comprises a VPN infrastructure module, an entropy IP first plug-in module and an entropy IP second plug-in module, wherein the entropy IP second plug-in module is optional, that is, the PE node may include the entropy IP second plug-in module or may not include the entropy IP second plug-in module, specifically includes or does not include the entropy IP second plug-in module, and may be set as needed, and is not limited.

The VPN infrastructure module may be similar to the receiving module 82 and the sending module 86, may also perform a part of the functions of the processing module 84, may perform a part of the functions of the communication interface 1002 and the processor 1004, or may perform a part of the functions of the communication interface 1102 and the processor 1104, but is not limited thereto.

The entropy IP first plug-in module may perform a portion of the functions of the processing module 84 or the processor 1004, such as modifying a second IP using a predetermined entropy value; the entropy IP second plug-in module may perform part of the functions of the processor 1104, but is not limited thereto.

Fig. 13 is a schematic structural diagram of a non-traffic-aware node according to a preferred embodiment of the present invention, as shown in fig. 13, including: an IP basic setting module and an entropy IP third plug-in module; it should be noted that the entropy IP third plugin module is optional, that is, the non-service-aware node may include the entropy IP third plugin module, may also not include the entropy IP third plugin module, specifically includes or does not include the entropy IP third plugin module, and may be set as needed, and is not limited.

The IP infrastructure module may perform part of the functions of the communication interface 1102 and the processor 1104, and the entropy IP third plug-in module may perform part of the functions of the processor 1104, but the invention is not limited thereto.

The role of the above-described modules included in the above-described PE node or non-traffic-aware node can be described in detail by the following preferred embodiments.

Preferred embodiment 1

The implementation of the PE node according to the technical solution of the method and apparatus (system) for transmitting and using the entropy value of the inner layer packet in the outer IP header will be further described in detail with reference to fig. 12:

1: implementing the VPN infrastructure module:

if the common VXLAN service is implemented according to RFC7348, the control plane module of the obtained VXLAN service is the control plane and man-machine interface part of the VPN infrastructure module.

Similarly, if the VXLAN service is implemented according to RFC7348, the forwarding plane module of the resulting VXLAN service is the forwarding plane portion of the VPN infrastructure module.

Except for special description, the module is the same as the human-computer interface and the processing flow corresponding to the RFC 7348.

It is worth mentioning that the EVPN control plane module obtained by the above method can be used for the configuration of the VXLAN tunnel, the configuration of the EVPN instance, the binding configuration of the AC and the EVPN instance, the binding configuration of the VXLAN tunnel and the EVPN instance, and the like, wherein the EVPN instance is identified by the VNI, and the VNI is configured by the user. And the VPN Router ID of the node at which the VXLAN tunnel is located is used as a source IP on the nodes at the two ends of the VXLAN tunnel, and the VPN Router ID of the opposite node is used as a destination IP. The VPN Router ID is an IP address of a loopback interface. For simplicity of description, without loss of generality, this module sets a node to have only one VPN Router ID.

When the module forwards the first packet according to the RFC7432 flow, the module needs to implement a plug-in mechanism, which is used to add IP encapsulation to the first packet to obtain an X-th packet, where the X-th packet has no link layer forwarding information (such as an ethernet header) encapsulated yet, then call the entropy IP first plug-in module with the X-th packet to modify the source IP and the destination IP in the IP encapsulation to obtain a Y-th packet, and then forward the Y-th packet continuously according to the RFC7432 flow, where other forwarding information, such as link layer forwarding information encapsulated according to the destination IP of the Y-th packet, is included to obtain a second packet (equivalent to the second packet or the third packet in the above embodiment), and send the second packet. The plug-in mechanism can be a function call, a callback function, a polymorphic function or an independent plug-in.

Except for a plug-in mechanism, the forwarding plane of the module is the same as the processing flow of the forwarding plane corresponding to RFC7348, wherein the processing flow includes a BUM message forwarding flow, an MAC learning flow, a unicast forwarding and forwarding flow and the like.

In addition, the IP address as the VPN Router ID must be a loopback interface address, which can configure a subnet mask, and it is not necessary that each binary bit of the subnet mask has a value of 1. It is worth mentioning that, when the low N-bit binary bit value of the subnet mask is 0, the loopback interface will form a routing prefix corresponding to the subnet mask in the IP routing table, and issue the routing prefix in the underlay network; when receiving a message with a destination IP matching the routing prefix, the node considers the message as the packet of the loopback interface and performs the same processing as the message with the destination IP as the IP address of the loopback interface.

Furthermore, without loss of generality, in the preferred embodiment, the underlay network is set to be an IPv4 network, and therefore, the source IP and the destination IP of the VXLAN tunnel are both IPv4 addresses.

In addition, when the destination IP of the received third packet (which is equivalent to the second packet or the third packet in the above embodiment) matches the direct routing prefix corresponding to the interface where the source IP of the EVPN tunnel is located, the module considers that the third packet matches the tunnel without checking whether the source IP of the third packet matches the destination IP of the EVPN tunnel.

2: the specific method for realizing the entropy IP first plug-in comprises the following steps:

different from RFC7348, this module also calculates 5-bit entropy value by some hash operation based on the source MAC of the first packet, and replaces the lower 5-bit original value of the destination IP of the IP packet input by the VPN infrastructure module with the obtained entropy value;

3: the specific method for realizing the entropy IP second plug-in module is as follows:

this module is not required for the preferred embodiment.

The implementation of the non-service-aware P node in the technical solution of the method and apparatus (system) for transmitting and using the entropy of the inner packet in the outer IP header is described in further detail with reference to fig. 13:

1: implementing the IP infrastructure module:

the basic IPv4 routing and IPv4 forwarding functions are implemented according to the prior art, where the IPv4 forwarding function includes a load balancing function based on MC-LAG, and the load balancing uses an IP quintuple of a received IP packet (corresponding to the second packet or the third packet in the above embodiment) as an entropy calculation factor to perform hash calculation, so as to obtain an entropy value of the IP packet.

It is worth mentioning that the module does not sense whether the IP packet has the entropy of the inner layer packet. However, if the source IP or the destination IP of the IP packet already contains the entropy of the inner packet, the entropy of the inner packet is automatically contained in the entropy calculation factor, and the entropy of the inner packet is also contained in the obtained new entropy value.

This module also does not need to call the entropy IP third plug-in.

2: the specific method for realizing the entropy IP third plug-in module is as follows:

the present module does not exist on such nodes, which are typically existing nodes.

Taking the VPN topology shown in fig. 1 as an example, the network and service deployment process includes:

firstly, selecting the PE nodes as PE1, PE2 and PE3 nodes, selecting the non-service perception nodes as P1 and P2 nodes, and selecting an underlay network type. The network and the service deployment process in each preferred embodiment of the present invention use the nodes defined in the preferred embodiment as the PE1, PE2, PE3, P1, and P2 nodes, which are not described again herein. The type of underlay network selected by the preferred embodiment is an IPv4 network.

And step two, configuring and issuing VPN Router ID of each PE node. Configuring a loopback interface for each PE node, configuring an IP address and a corresponding subnet mask for the loopback interface, using the IP address of the loopback interface as the VPN Router ID of the PE, and enabling the routing prefix generated by the VPN Router ID and the corresponding subnet mask to be routing reachable (capable of ping) in the underlay network; the VPN Router ID of each PE and the corresponding routing prefix are different. In this preferred embodiment, the subnet mask of the loopback interface is a 27-bit subnet mask, and the host identifier part of the IP address of each loopback interface has a value of 1.

And thirdly, establishing the common VXLAN network shown in the figure 1 and configuring each VXLAN tunnel. Wherein, only one bidirectional tunnel is arranged between the same pair of PE nodes. When the VXLAN tunnel is configured to a specified target PE node, the VPN Router ID of the target PE node is used as the destination IP address of the VXLAN tunnel, and the VPN Router ID of the target PE node is used as the source IP address of the VXLAN tunnel. It is noted that the VXLAN tunnel configured in this way, taking the VXLAN tunnel between PE1 and PE3 as an example, the source IP of the tunnel is the VPN Router ID of PE1 and the destination IP is the VPN Router ID of PE3 when viewed on PE1, and the source IP of the tunnel is the VPN Router ID of PE3 when viewed on PE3 and the destination IP is the VPN Router ID of PE 1.

Step four, a VXLAN service is established as shown in fig. 1. And 6 interfaces such as AC1, AC2, AC3, AC4, AC5 and AC6 are used as access circuits to bind the VXLAN services, and each VXLAN tunnel is bound to the VXLAN services.

And fifthly, eliminating the loop at the access side. Since each PE node uses entry replication for BUM messages received from each AC interface, taking the BUM message (equivalent to the first message or the fourth message in the above embodiment) received by PE3 from AC3 as an example, PE3 replicates one copy for each of PE1 and PE2, and when PE1 and PE2 send packets to CE1, one copy of PE is discarded, this is achieved by deploying an MC-LAG session on a physical port to which AC1 and AC2 belong to block one physical port to which AC1 and AC2 belong, after MC-LAG is enabled, CE1 does not receive two copies of BUM messages, and the two-layer loop between CE1, PE1, and PE2 also disappears. Similarly, an MC-LAG session is also deployed on the physical port to which the AC3 and the AC4 belong. Without loss of generality, it is assumed that the two MC-LAG connections block the physical port on which AC1 resides and the physical port on which AC5 resides, respectively.

Sixthly, through the above steps, the VXLAN service is established, and forwarding behaviors and effects on the PE node and the non-service-aware node defined in the preferred embodiment can be verified by using the data message.

Taking the VPN topology shown in fig. 1 as an example, the end-to-end packet forwarding process includes:

first, when a PE1 node receives a BUM message B1 (corresponding to the first message or the fourth message in the foregoing embodiment) from a local AC1, the PE node forwards the B1 message according to a forwarding flow defined by RFC7348, and sends two copies B1B (corresponding to the second message or the third message in the foregoing embodiment) and B1c (corresponding to the second message or the third message in the foregoing embodiment) of the B1 message to the PE2 and the PE3, respectively, and VXLAN encapsulation is added to both the B1B and the B1c messages compared with the B1 message, an outer IP header of the VXLAN encapsulation includes an intrinsic entropy value of the B1 message, where the intrinsic entropy value is an entropy value calculated by a characteristic field of the B1 message itself.

Secondly, without loss of generality, assuming that a non-service-aware node P1 in the underlay network receives the B1c message before the PE3 node receives the B1c message, since the P1 node does not sense the inner layer message, it will still forward the B1c message according to the destination IP of the B1c message as it would forward the normal IP message, and without loss of generality, the preferred embodiment sets that the forwarding result obtained by the P1 node according to the destination IP of the B1c message is to forward the B1c message from the link aggregation group LAG between the P1 node and the P2 node shown in fig. 1. Further, the node P1 calculates the load sharing entropy according to the quintuple corresponding to the outermost IP header of the B1c message, as in the case of forwarding the normal IP message, but since the entropy of the B1 message is already included in the outermost destination IP of the B1c message, the entropy of the B1c message calculated at the node P1 will automatically include the entropy of the B1 message. Thus, as the characteristic fields of the inner layer B1 messages take different values, the entropy values of the B1 messages and the entropy values of the B1c messages both change, and thus the load sharing process on the P1 node also changes the finally selected egress forwarding information of the B1c messages, that is, the load sharing on the P1 node is more uniform, because the egress forwarding information obtained by the B1c messages on the P1 node is the same no matter how the B1 messages change before the PE1 does not implement the present invention. Obviously, with the help of the entropy of the inner B1 packet added by PE1 to the outer IP header of the B1c packet, the load sharing balance on the P1 node is improved.

Thirdly, when the PE3 node receives the B1c message, the VPN infrastructure module may perform performance statistics on the B1c message, and the algorithm for performing performance statistics on the B1c message does not use different performance statistics counters due to different entropy values included in the B1c, because the entropy value used in the preferred embodiment is pseudo-random and is meaningless for the PE3 node.

Obviously, as can be seen from the second step, the load sharing effect on the P1 node is improved without any modification to the P1 node in the embodiment of the present invention. Also, the present invention does not use any MPLS technology.

Preferred embodiment 2

1: implementing the VPN infrastructure module:

this module is the same as the module of the preferred embodiment 1, except where explicitly stated.

Unlike the preferred embodiment 1, the module sets the underlay network as an IPv6 network. It is worth mentioning that this means that the source IP and the destination IP of the VXLAN tunnel configured by this module are both IPv6 addresses.

Different from the preferred embodiment 1, the plug-in mechanism of this module further calls the entropy IP second plug-in module to modify the source IP and the destination IP in the IP encapsulation after receiving the third packet and performing the link layer error detection processing and the IP layer error detection processing on the third packet and before processing the third packet, and then continues to process the modified packet according to the processing flow in RFC 7348.

2: the specific method for realizing the entropy IP first plug-in module is as follows:

this module is the same as the module of the same name in preferred embodiment 1 except where explicitly stated.

Different from the preferred embodiment 1, this module uses the hash value of the interface name of the physical port to which the entry AC of the first packet belongs as the 32-bit entropy value of the first packet;

unlike preferred embodiment 1, the source IP and destination IP of VXLAN encapsulation used by this module are both IPv6 addresses and conform to the format defined in RFC7348Section 5Figure 2.

Different from the preferred embodiment 1, this module uses the source IP field of the second packet as an entropy IP, where the entropy IP is an IP address obtained by replacing the lower 32 bits of the source IP input by the VPN infrastructure module with the entropy value;

it is to be noted that, in the embodiment of the present invention, the use of a field as an entropy IP refers to use of the field as a carrier of the entropy of the first packet, and the entropy of the first packet is carried in the entropy IP by modifying the entropy IP by using the entropy value of the first packet.

the module determines the position of the binary bit to be modified in the third message, and modifies the binary bit at the position. Limited to the implementation of the entropy IP first plug-in module, this module determines that the binary bit that needs to be modified in the third packet is the lower 32 bits of the source IP address, and correspondingly, this module further determines that, for each bit that needs to be modified, the modification of this bit is specifically to clear this bit.

The implementation of the non-service aware P-node in the technical solution of the method and apparatus (system) for transmitting and using entropy of inner layer packet in outer IP header will be further described in detail with reference to fig. 13:

1: implementing the IP infrastructure module:

except where specifically noted, this module is identical to the module of the same name in preferred embodiment 1.

Different from the preferred embodiment 1, the module is implemented as software, and a plug-in mechanism is required to be implemented to call the entropy IP third plug-in module to obtain two IP address values, one of which is a source IP replacement value and the other is a destination IP replacement value. The plug-in mechanism can be a function call, a callback function, a polymorphic function or an independent plug-in.

Unlike preferred embodiment 1, after performing link layer error detection processing and IP layer error detection processing on the third packet and when performing processing related to the source IP or destination IP address of the third packet except for load balancing, the module calls the IP infrastructure to obtain a source IP alternative value and a destination IP alternative value of the third packet, and replaces the source IP value (or destination IP value) of the third packet with the source IP alternative value (or destination IP alternative value) to participate in the processing related to the source IP (or destination IP) address.

The processing related to the source IP of the third packet includes processing of the third packet itself, and also processing of other packets generated by being triggered by the third packet, for example, when the TTL of the third packet is exhausted or the destination IP of the third packet is not reachable, the node may reply an ICMP message to the source IP of the third packet.

the module is mainly used for returning a source IP substitution value and a destination IP substitution value according to the source IP and the destination IP of the IP message input by the IP infrastructure module. The algorithm for determining the source IP alternative value and the destination IP alternative value is as follows:

if the entropy mask of the source IP is 0, the source IP substitute value is the value of the source IP;

if the entropy mask of the target IP is 0, the target IP substitute value is the value of the target IP;

if the source IP entropy-taking mask is not 0, performing bitwise logical AND operation by using the source IP address and the inverse code of the source IP entropy-taking mask, and taking the lowest binary position of the obtained result as a source IP substitute value after being 1;

if the target IP entropy-taking mask is not 0, performing bitwise logical AND operation on the target IP address and the inverse code of the target IP entropy-taking mask, and taking the lowest binary position of the obtained result as a target IP substitute value after being 1;

in the preferred embodiment, the source IP entropy mask and the destination IP entropy mask are both in IPv6 address format, and the 16-ary value of the source IP entropy mask is 0x0FFFFFFFF, and the value of the destination IP entropy mask is 0.

The module then returns the source IP replacement value and the destination IP replacement value to the IP infrastructure module.

It is noted that the present module does not alter the incoming messages of the IP infrastructure.

Taking the VPN service shown in fig. 1 as an example, the processing steps of the network and service deployment flow part are as follows:

except where otherwise specified, this step is the same as the corresponding step in preferred embodiment 1;

as in the preferred embodiment 1, except that the underlay network is an IPv6 network, the loopback interface where each VPN Router ID is located is configured with a 96-bit subnet mask, and the source IP and the destination IP of the VXLAN tunnel are both IPv6 addresses.

Taking the VPN topology shown in fig. 1 as an example, the processing steps of the end-to-end message forwarding flow part are as follows:

this step is the same as the corresponding step in preferred embodiment 1. Except for the phenomenon that the load balancing effect of the invention on the P1 node is improved: when the B1 packets enter the EVPN instance from different ACs of PE1, the resulting egress forwarding information of the corresponding B1c packets on the P1 node is also different. This is completely because PE1 adds the context entropy of the B1 packet to the outer IP of the B1c packet, and the context entropy is obtained by hashing the interface name of the entry AC of the B1 packet.

Preferred embodiment 3

The implementation of the PE node according to the technical solution of the method and apparatus (system) for transmitting and using the entropy value of the inner layer packet in the outer IP header is described in further detail below with reference to fig. 12:

1: implementing the VPN infrastructure module:

this module is the same as the module of the same name in the preferred embodiment 2 except where explicitly stated.

Different from the preferred embodiment 2, the underlay network technology adopted by the module is the IPv6 technology.

Different from the preferred embodiment 2, the encapsulation format used by the present module to encapsulate the first packet into the second packet is a gene encapsulation format, and the format is defined in draft-ietf-nvo 3-gene; the draft also defines how to convert the message from VXLAN encapsulation to gene encapsulation without changing the basic business effect, which part of the conversion belongs to the prior art. Whether the functionality specific to the Geneve package is superimposed (relative to RFC7348) belongs to the combined application of the Geneve technology and this embodiment, independent of the preferred embodiment itself, for simplicity the preferred embodiment only considers cases within the common capabilities of the Geneve package and VXLAN packages.

Different from the preferred embodiment 2, this module uses the result of the hash calculation performed by the destination MAC of the first packet as the 8-bit entropy of the first packet;

different from the preferred embodiment 2, this module uses the source IP field of the first packet as an entropy IP, where the entropy IP is an IP address obtained by performing bitwise logical xor operation on the entropy value and the lower 8 bits of the source IP input by the VPN infrastructure module;

except where specifically noted, this module is the same as in preferred embodiment 2;

different from the preferred embodiment 2, the position of the binary bit that needs to be modified in the third packet determined by the module is the lower 8 bits of the source IP. Further, the present module determines the modification of the binary bits of the location by restoring them to their values prior to modification by the entropy IP first plug-in. Specifically, the recovery method comprises the following steps: firstly, recalculating the entropy value of the fourth message carried by the IP header inner layer of the third message by using an algorithm in the entropy IP first plug-in module, and then carrying out bitwise logical XOR operation on the entropy value and the binary bit of the position.

Notably, because the VPN infrastructure itself is an implementation of RFC7348VXLAN, RFC7348 is based on VXLAN data messages for the learning of remote MAC entries, which would frequently drift between different ciphertexts of the same source IP if the source IP were not entropy-removed, because the VPN infrastructure module does not know that these ciphertexts are the same IP address, which is treated as a different IP address; similarly, ciphertexts with different source IP addresses encrypted may happen to be the same, and at this time, they are also regarded as the same IP address by the VPN infrastructure module, which also has a problem. This is undoubtedly a decryption process besides restoring the source IP, and also aims to remove the entropy of the inner layer packet (corresponding to the first packet or the fourth packet in the above embodiment) included in the source IP.

1: implementing the IP infrastructure module:

except where specifically noted, this module is identical to the module of the same name in the preferred embodiment 2.

Different from the preferred embodiment 2, the module uses IPv4 routing and forwarding technology, and forwards the IPv4 message.

except where otherwise noted, this module is identical to the module of the same name in preferred embodiment 2.

Unlike the preferred embodiment 2, in this block, the source IP entropy-taking mask and the destination IP entropy-taking mask are both in IPv4 address format, and the source IP entropy-taking mask has a value of 0x0FF in its 16-ary value, and the destination IP entropy-taking mask has a value of 0.

Taking the VPN service shown in fig. 1 as an example, the processing steps of the network and the service deployment flow part are as follows:

as in the preferred embodiment 1, only the loopback interfaces where the VPN Router IDs are located are configured with 24-bit subnet masks. Meanwhile, Geneve needs to be deployed in the network and applied to the EVPN instance.

this step is the same as the corresponding step in preferred embodiment 1.

Preferred embodiment 4

The following describes in detail the implementation of the PE node according to the technical solution of the method and apparatus (system) for transmitting and using the entropy of the inner layer packet in the outer IP header with reference to fig. 12:

1: implementing the VPN infrastructure module:

except for the specific description, the present module is the same as the module of the same name in the preferred embodiment 2;

different from the preferred embodiment 2, the encapsulation format used by the present module to encapsulate the first packet into the second packet is VXLAN GPE encapsulation format, which is defined in draft-ietf-nvo3-VXLAN-GPE, and how to convert the packet from VXLAN encapsulation to VXLAN GPE encapsulation is defined in the draft without changing the basic service effect, and this part of conversion belongs to the prior art. Whether or not the functionality specific to VXLAN GPE encapsulation is superimposed (relative to RFC7348) belongs to the combination of VXLAN GPE technology with the preferred embodiment, independent of the preferred embodiment itself, and for simplicity the preferred embodiment considers only the case where VXLAN GPE encapsulation is within the common capabilities of RFC7348 encapsulation.

different from the preferred embodiment 2, when the ethernet load of the inner layer packet is an IPv6 packet, the module uses a result obtained by performing hash calculation on a quintuple < source IP, destination IP, protocol type, source port number, destination port number > and a Flow-label field of an IPv6 header together as the 20-bit entropy value of the first packet;

different from the preferred embodiment 2, this module uses the destination IP field of the second packet as an entropy IP, where the entropy IP is obtained by performing bitwise logical xor operation on the entropy value and the lower 20 bits of the destination IP input by the VPN infrastructure module, and storing the obtained result in the lower 20 bits of the destination IP address;

it is noted that the bitwise logical exclusive-or operation is actually a simple encryption algorithm.

different from the preferred embodiment 2, the position of the binary bit that needs to be modified in the third packet determined by the module is the lower 20 bits of the destination IP. Further, the present module determines the modification method of the binary bit of said position to restore it to its value before it was modified by the entropy IP first plug-in. Specifically, the restoration method comprises the following steps: firstly, recalculating the entropy value of the fourth message carried by the IP header inner layer of the third message by using an algorithm in the entropy IP first plug-in module, then carrying out bitwise logical XOR operation on the entropy value and the binary bit of the position, and storing the result in the lower 20 bits of the destination IP of the third message.

1: implementing the IP infrastructure module:

this module is the same as the module of the same name in the preferred embodiment 2.

Unlike preferred embodiment 2, in this module, the source IP entropy-taking mask and the destination IP entropy-taking mask are both in IPv6 address format, and the source IP entropy-taking mask has a 16-ary value of 0 and the destination IP entropy-taking mask has a 16-ary value of 0x0 FFFFF.

as in the preferred embodiment 2, only the loopback interface where each VPN Router ID is located is configured with a 108-bit subnet mask. Meanwhile, VXLAN GPEs need to be deployed in the network and applied to the EVPN instance.

this step is the same as the corresponding step in preferred embodiment 2.

Preferred embodiment 5

1: the specific method for implementing the VPN infrastructure module is as follows:

except for special description, the module is the same as the module with the same name in the preferred embodiment 2;

different from the preferred embodiment 2, this module generates an IP address, called VNI IP address, by combining the VPN Router ID with the VNI configured on the EVPN instance, where the VNI IP address uses the high 104 bits of the VPN Router ID as the high 104 bits and uses the VNI as the low 24 bits; wherein the VNI is not equal to the lower 24 bits of the VPN Router ID.

Different from the preferred embodiment 2, an encapsulation format used by the present module to encapsulate the first packet into the second packet is NVGRE (network Virtualization Using Generic Routing encapsulation), the format is defined in RFC7637, and how to convert a packet from VXLAN encapsulation to NVGRE encapsulation is defined in draft-ietf-less-evpn-overlay without changing a basic service effect, which belongs to the prior art. Whether NVGRE encapsulation specific functionality (with respect to RFC7348) is superimposed or not belongs to the combination of NVGRE technology and the preferred embodiment, independently of the preferred embodiment itself, and for simplicity, the preferred embodiment considers only the situation within the common capabilities of NVGRE encapsulation and RFC7348 encapsulation.

except where specially stated, this module is the same as the module of the same name in the preferred embodiment 2;

unlike the preferred embodiment 2, this module replaces the outermost destination IP of the packet input by the VPN infrastructure module with the VNI IP, so that the lower 24 bits of the final outermost destination IP include the VNI of the EVPN instance, where the VNI is the context entropy of the first packet and is carried by the second packet.

unlike the preferred embodiment 2, this module returns the message input by the VPN infrastructure module to the VPN infrastructure module as it is.

It should be noted that the reason why the lower 24 bits in the destination IP do not need to be cleared although they contain the context entropy of the inner layer packet is that the value does correspond to the IP address of an interface (specifically, an EVPN instance interface) on the source node (i.e., the first PE) of the VXLAN tunnel through which the third packet passes, and thus the destination IP address is actually IP reachable, whereas the IP address containing the entropy does not meet this condition.

1: implementing the IP infrastructure module:

except where otherwise noted, this module is the same as the module of the same name in preferred embodiment 1.

Different from the preferred embodiment 1, the module can process the IPv6 message by using the IPv6 routing and forwarding technology.

this module is not required for this node, as in the preferred embodiment 1.

except where otherwise specified, this step is the same as the corresponding step in preferred embodiment 2;

as in the preferred embodiment 2, only the loopback interfaces where the VPN Router IDs are located are configured with 104-bit subnet masks.

this step is the same as the corresponding step in preferred embodiment 2.

Preferred embodiment 6

except for special points, the module is the same as the module with the same name in the preferred embodiment 5;

different from the preferred embodiment 5, the EVPN instance of the module also corresponds to a virtual interface with the same name, which is called EVPN instance interface, and the EVPN instance interface has all functions of the existing loopback interface. It is worth mentioning that this means: the IP address of the EVPN instance interface is added to a routing table as a local host route, the IP address mask configured on the EVPN instance interface is added to the routing table as a local direct-connection routing prefix, and the route generated according to which interface (necessarily the EVPN instance interface) is known from the routing entries corresponding to the local host route and the local direct-connection routing prefix.

Unlike in the preferred embodiment 5, the VNI configured on the EVPN instance of this module is only regarded as a numerical value for identifying the EVPN instance, and does not have the role of the VNI in RFC7348, but instead, the VNI IP described in the preferred embodiment 5 is directly configured on the EVPN instance interface as the IP address of the corresponding EVPN instance interface;

different from the preferred embodiment 5, each VXLAN tunnel in the preferred embodiment is dedicated to one service, and each service deploys one VXLAN tunnel for each remote node in the service; specifically, in the preferred embodiment, the source IP of each VXLAN tunnel is an IP address of an EVPN instance interface corresponding to an EVPN instance to which the VXLAN tunnel belongs, and the destination IP is an IP address of an EVPN instance interface corresponding to an EVPN instance to which the VXLAN tunnel belongs on a destination node;

compared with the VXLAN encapsulation adopted in the preferred embodiment 5, the encapsulation used by the module to encapsulate the first message into the second message removes the UDP header and the VXLAN header, so that the encapsulation has the same format as the end.dxla 2 type Function in SRv 6; this encapsulation format is referred to in the present invention as type a extension SRv6 encapsulation, as shown in fig. 14, format B in fig. 15, where fig. 15 is an expansion of fig. 14, including a detailed comparison of the fields between the source IP to ethernet layer payload data with the relevant fields in VXLAN encapsulation;

correspondingly, when the module receives a third message, if a destination IP of the third message hits a local direct-connection route and the route is generated by an EVPN instance interface, the third message is considered to be encapsulated by the a-type extension SRv6, and the third message is forwarded in the EVPN instance corresponding to the EVPN instance interface. At the time of forwarding, except for encapsulation and decapsulation, each field in the format B in fig. 15 has the same function as the field with the same name in the format a in fig. 15 except for the special description.

different from the preferred embodiment 5, this module maps the sub-interface VLAN information on the ingress AC to the 24-bit entropy of the fourth packet, and the method is: the upper 12 bits of the entropy value are an outer layer VLAN ID configured on the inlet AC, the lower 12 bits are an inner layer VLAN ID configured on the inlet AC, when the inner layer VLAN ID does not have corresponding configuration, the lower 12 bits are 0x3FF, and when the outer layer VLAN ID does not have corresponding configuration, the upper 12 bits are 0x3 FF;

different from the preferred embodiment 5, this module uses the source IP field of the second packet as an entropy IP, where the entropy IP is an IP address obtained by replacing the lower 24 bits of the source IP to be obtained by forwarding according to the RFC7348 flow with the 24-bit entropy value;

it should be noted that the destination IP field of the message input by the VPN infrastructure module is not modified by this module, but the field itself already contains EVPN service information to which the message belongs, and DIP automatically has more entropy than in preferred embodiment 5.

It should be noted that the module does not modify the high-order 104 bits of the source IP field of the second packet, so that the high-order 104 bits of the destination IP learned by the MAC learning procedure are not different from those in the prior art, and the high-order 104 bits of the destination IP enable the second packet to be matched with the destination PE node to which the EVPN instance belongs.

except where specifically noted, this module is the same as in preferred embodiment 5;

unlike the preferred embodiment 5, this module returns the message input by the VPN infrastructure module to the VPN infrastructure module as it is.

It should be noted that, because the source IP of the packet input by the VPN infrastructure module includes the VLAN ID information corresponding to a remote AC, the information is used for performance statistics, so that packets from different remote ACs can be counted on different counters, and thus, the performance statistics data is more accurate.

1: implementing the IP infrastructure module:

this module is the same as the module of the same name in the preferred embodiment 5.

as in preferred embodiment 5, except as follows: each EVPN instance corresponds to an EVPN instance interface, an IPv6 address and a 104-bit IPv6 address mask are configured for the interface, and 104-bit IPv6 routing prefixes generated by any two EVPN instance interfaces are not matched. The source IP and destination IP of each VXLAN tunnel are IP addresses for an EVPN instance interface, in addition to which the preferred embodiment 5 requirements must be met.

It is noted that each EVPN instance has only one corresponding EVPN instance interface, and each EVPN instance interface also has only one corresponding EVPN instance.

this step is the same as the corresponding step in preferred embodiment 5.

Obviously, in the preferred embodiment 6, whether the lower 24 bits of the IPv6 address configured for the EVPN instance interface therein are equal to the VNI value of the corresponding EVPN instance does not affect the role of the IPv6 address, because the IPv6 address already has a one-to-one correspondence with the EVPN instance, regardless of whether there is such a relationship. This description of preferred embodiment 6 is provided for the sake of clarity and clarity only and should not be construed as unduly limiting this preferred embodiment.

Preferred embodiment 7

1: implementing the VPN infrastructure module:

and realizing VXLAN EVPN service according to draft-ietf-bess-EVPN-overlay (hereinafter abbreviated as 'EVPN overlay'), wherein a control surface module of the obtained VXLAN EVPN service is the control surface part of the VPN infrastructure module.

And similarly, realizing the VXLAN EVPN service according to the EVPN overlay, and obtaining a forwarding face module of the VXLAN EVPN service, namely the forwarding face part of the VPN infrastructure module.

It is worth mentioning that the EVPN control plane module obtained by the above method includes contents such as MP-BGP protocol L2VPN EVPN address family related configuration, EVPN instance configuration, AC-EVPN instance binding configuration, ESI related configuration, and the like, where the EVPN instance uses VNI as an identifier, and the VNI is configured by a user.

It is worth mentioning that the VXLAN tunnel and the binding relationship between the VXLAN tunnel and the EVPN instance in the module are dynamically generated by the MP-BGP session according to the EVPN Overlay protocol.

The requirements of the module for the plug-in mechanism are the same as in the preferred embodiment 1.

The configuration requirements and the functional requirements of the module for the VPN Router ID and the IP address of the loopback interface and the subnet mask thereof are the same as those of the preferred embodiment 1.

except where specifically noted, this module is the same as in preferred embodiment 3;

different from the preferred embodiment 3, this module performs hash calculation based on the source MAC of the first packet, the VLAN ID, the 802.1p priority, and the ethertype corresponding to the load to obtain a 5-bit intrinsic entropy value of the first packet, then performs hash calculation based on the interface name of the main interface to which the entry AC of the first packet belongs to obtain a 5-bit context entropy value, performs bitwise logical xor operation on the context entropy value and the context entropy value, performs bitwise logical xor operation on the prime number 29 to obtain a 5-bit comprehensive entropy value, then performs bitwise logical xor operation on the lower 5 bits of the destination IP of the second packet input by the VPN infrastructure module and the comprehensive entropy value, and stores the result in the former.

the module determines that the position of the binary bit which needs to be cleared before the processing related to the IP address in the third message is the lower 5 bits of the destination IP.

1: implementing the IP infrastructure module:

this module is the same as the module of the same name in the preferred embodiment 3.

except where otherwise noted, this module is identical to the module of the same name in preferred embodiment 3.

Unlike preferred embodiment 3, in this block, the source IP entropy-taking mask and the destination IP entropy-taking mask are both in IPv6 address format, and the source IP entropy-taking mask has a 16-ary value of 0 and the destination IP entropy-taking mask has a 16-ary value of 0x 01F.

Taking the EVPN topology shown in fig. 2 as an example, the network and service deployment process includes:

the first step is the same as the corresponding step in the preferred embodiment 1, except that the underlay network is IPv 4.

The second step is the same as the corresponding step in preferred embodiment 1, except that the loopback interface where the VPN Router ID is located is configured with a 27-bit subnet mask.

Third, the VXLAN EVPN network shown in fig. 1 is established. Including configuring MP-BGP sessions pairwise among PE1, PE2, PE3, and enabling correlation configuration of L2VPN EVPN address families. For simplicity, the configuration of BGP is adjusted so that EVPN RT-3 routes can dynamically generate all VXLAN tunnels needed for traffic. Without loss of generality, for simplicity, the BGP configuration may be adjusted such that the VXLAN tunnel generated by RT-3 routing complies with the following rules: only one bidirectional VXLAN tunnel is generated between any two PE nodes; both ends of any two-way VXLAN tunnel use the VPN Router ID of the node as the source IP of the VXLAN tunnel, and at both ends of the same two-way VXLAN tunnel, the source IP of the tunnel at one end is just the destination IP of the tunnel at the other end, and the destination IP of the tunnel at one end is just the source IP of the tunnel at the other end. Similarly, by adjusting the BGP configuration, the RT-3 routing can also generate all the binding relationships between all VXLAN tunnels and EVPN instances; these are all prior art and the particular methods involved will be apparent to those skilled in the art.

And step four, establishing a VXLAN EVPN service according to the figure 1, and assigning the same VNI for the VXLAN EVPN service on each PE node. And 6 interfaces such as AC1, AC2, AC3, AC4, AC5, AC6 and the like are used as access circuits to bind the VXLAN EVPN service. After the above configuration is completed, the MP-BGP session starts exchanging RT-3 routes according to the signaling flow defined by EVPN Overlay, resulting in VXLAN tunnels between nodes being established and bound to the VXLAN EVPN service.

And fifthly, eliminating the loop at the access side. The physical interfaces of CE1 accessing PE1 and PE2 are mapped to the same ESI (marked as ESI1) and ESI1 related configuration, so as to trigger the MP-BGP session to perform DF negotiation and RT-1 route distribution according to the RT-4 route described in [ EVPN Overlay ]. Similarly, the physical interfaces to PE1 and PE2 for CE2 also map to the same ESI (denoted ESI2), and ESI2 related configurations. Without loss of generality, the preferred embodiment assumes that the result of DF negotiation is that AC1 and AC5 are interfaces to the non-DF roles of ESI1 and ESI2, respectively, in the service. Because the PE node of the preferred embodiment implements the EVPN Overlay protocol, after ESI-related configuration is configured and the related signaling flow is completed, both ESI-related loops are also released.

Sixthly, through the above steps, the VXLAN EVPN service is established, and forwarding behaviors and effects on the PE node and the non-service-aware node defined in the preferred embodiment can be verified by using the data message.

Taking the EVPN topology shown in fig. 2 as an example, the end-to-end packet forwarding process includes:

the first step is the same as the preferred embodiment 1 except that the forwarding plane flow is performed as EVPN Overlay.

The second step is the same as the preferred embodiment 1 except that the forwarding plane flow is performed as EVPN Overlay.

The third step is the same as in the preferred embodiment 1 except that the forwarding plane flow is performed as EVPN Overlay.

Obviously, in the third step of the end-to-end message forwarding process, it has been proved that the load sharing effect on the P1 node is improved without any change to the P1 node. Also, the present invention does not use any MPLS technology.

Preferred embodiment 8

1: implementing the VPN infrastructure module:

this module is the same as in preferred embodiment 7 except where specifically noted;

different from the preferred embodiment 7, the module sets the underlay network as an IPv6 network;

it is worth mentioning that this means that the source IP and the destination IP of the VXLAN tunnel dynamically generated by this module are both IPv6 addresses.

except where specifically noted, this module is the same as in preferred embodiment 4;

different from the preferred embodiment 4, this module performs a hash calculation based on ESI (10 bytes) corresponding to the main interface to which the entry AC of the first packet belongs, and uses the hash calculation result as the entropy value of the first packet. The module uses the source IP field of the second message as the entropy IP, the low 32 bits of the source IP and the entropy value are subjected to bitwise logical XOR operation, and the obtained result is stored in the former.

unlike in the preferred embodiment 4, the position of the binary bit that needs to be cleared before the processing related to the IP address in the third message determined by this module is the lower 32 bits of the source IP.

1: implementing the IP infrastructure module:

It should be noted that, although the lower 32 bits of the source IP of the third packet are ciphertext encrypted by an entropy value and the node cannot decrypt the ciphertext, because the source IP is an IP address of a loopback interface on the first PE and the loopback interface is configured with a 96-bit mask, the source IP is an IP address reachable by a route no matter what value the ciphertext portion in the source IP is, and therefore, the node cannot perform entropy removal processing on the source IP and cannot affect forwarding.

Taking the VPN service shown in fig. 2 as an example, the processing steps of the network and the service deployment flow part are as follows:

except where otherwise specified, this step is the same as the corresponding step in preferred embodiment 7;

different from the preferred embodiment 7, the underlay network of the preferred embodiment is an IPv6 network, a subnet mask with 96 bits is configured on a loopback interface where each VPN Router ID is located, and the source IP and the destination IP of the VXLAN tunnel are both IPv6 addresses.

Taking the VPN topology shown in fig. 2 as an example, the processing steps of the end-to-end message forwarding flow part are as follows:

this step is the same as the corresponding step in preferred embodiment 7.

Preferred embodiment 9

1: implementing the VPN infrastructure module:

and realizing VXLAN EVPN service according to [ EVPN overlay ] and draft-ietf-less-EVPN-prefix-advertisement (hereinafter abbreviated as "[ EVPN prefix ]"), and obtaining a control surface module of the VXLAN EVPN service, namely a control surface part of the VPN infrastructure module.

Similarly, the VXLAN EVPN service is realized according to [ EVPN overlap ] and [ EVPN prefix ], and the forwarding plane module of the VXLAN EVPN service is the forwarding plane part of the VPN infrastructure module.

It is worth mentioning that the EVPN control plane module obtained by the above method includes content such as BGP protocol L2VPN EVPN address family correlation configuration, IP-VRF instance configuration, and binding configuration between AC and IP-VRF instance, where the IP-VRF instance uses VNI as an identifier, and the VNI is configured by a user. The VXLAN tunnel takes the VPN Router ID of the node as a source IP and takes the VPN Router ID of the destination node as a destination IP on the source node of the VXLAN tunnel. The VPN Router ID is an IP address of a loopback interface. For simplicity of description, without loss of generality, this module sets a node to have only one VPN Router ID.

It is worth mentioning that, for simplicity, under the condition of not losing generality to the patent, the module only needs to implement the function corresponding to the interface-less model from the IP-VRF to the IP-VRF, and therefore, the AC interface of the IP-VRF in the module is still a common sub-interface and does not include the IRB interface described in [ EVPN prefix ];

it is worth mentioning that the control plane part of the module obtained by the above method does not need to statically configure the VXLAN tunnel, and the RT-5 route can dynamically generate all required VXLAN tunnels. Without loss of generality, for simplicity, the BGP configuration may be adjusted such that the VXLAN tunnel generated by RT-5 routing complies with the following rules: only one bidirectional VXLAN tunnel is generated between any two PE nodes; the VPN Router ID of the node at which the two-way VXLAN tunnel is located is used as the source IP of the VXLAN tunnel at both ends of any two-way VXLAN tunnel, and at both ends of the same two-way VXLAN tunnel, the source IP of the tunnel at one end is exactly the destination IP of the tunnel at the other end, and the destination IP of the tunnel at one end is exactly the source IP of the tunnel at the other end. Similarly, by adjusting the BGP configuration, the RT-5 route can also generate all the binding relationships between all VXLAN tunnels and EVPN instances; these are all prior art and the particular methods involved will be apparent to those skilled in the art.

The module is implemented as software, and a plug-in mechanism is required to be implemented, which is used for calling the plug-in to modify a source IP and a destination IP in IP encapsulation after completing IP encapsulation from a first message to a second message when the module forwards according to an [ EVPN prefix ] flow. The plug-in can be a function call, a callback function, a polymorphic function or an independent plug-in.

Except for a plug-in mechanism, the forwarding flow of the module is the same as that of the [ EVPN prefix ] corresponding forwarding module.

In addition, the IP address as the VPN Router ID must be a loopback interface address configured with 96-bit mask, so that a 96-bit route is formed and a 96-bit route prefix is published in the underlay network; and when receiving a message with a destination IP matching the 96-bit route, the node considers the message as the message of the loopback interface and processes the same as the message with the destination IP as the loopback interface.

Furthermore, without loss of generality, in the preferred embodiment, the underlay network is set to be an IPv6 network, and therefore, the source IP and the destination IP of the VXLAN tunnel are both IPv6 addresses.

except where specifically noted, this module is the same as in preferred embodiment 8;

different from the preferred embodiment 8, the module uses a hash value obtained by performing hash operation based on the IP five tuple field of the first packet and the ToS field in the header of Ipv4 as a final 32-bit entropy value.

the module returns the message input by the VPN infrastructure module to the VPN infrastructure module as it is;

1: implementing the IP infrastructure module:

Taking the EVPN topology shown in fig. 3 as an example, the network and service deployment process includes:

the first step is the same as the preferred embodiment 7 except that the type of underlay network selected by the preferred embodiment is an IPv6 network.

Second, the same as in the preferred embodiment 7 except that the subnet mask of the loopback interface where the VPN Router ID is located is a 96-bit subnet mask.

The third step is the same as in the preferred embodiment 7 except that the VXLAN tunnel is generated and the generated VXLAN tunnel is bound to the EVPN instance for the RT-5 route instead of the RT-3 route.

Step four, a VXLAN 3EVPN service is established as shown in fig. 1, and the same VNI is assigned to the VXLAN 3EVPN service on each PE node. The 3 interfaces of AC1, AC2, AC3 and the like are used as access circuits to bind the VXLAN L3EVPN service. After the above configuration is completed, the MP-BGP session starts communicating RT-5 routes according to the signaling flow defined by EVPN Prefix, resulting in VXLAN tunnels between nodes being established and bound to the VXLAN 3EVPN traffic.

And step five, configuring the IP address of the AC interface. Each AC is configured with an IP address that is within the same subnet as, and different from, the IP address of the corresponding CE. For simplicity, the preferred embodiment sets each CE as an IPv4 host, and therefore, the EVPN prefix in the RT-5 route issued by the MP-BGP session is an IPv4 prefix, but the source IP and the destination IP of the VXLAN tunnel generated by the RT-5 route are both IPv6 addresses.

Sixthly, through the above steps, the vxl 3EVPN service is established, and forwarding behaviors and effects on the PE node and the non-service-aware node defined in the preferred embodiment can be verified by using a data message.

Taking the EVPN topology shown in fig. 3 as an example, the end-to-end packet forwarding process includes:

first, when a PE1 node receives an IPv4 message B1 from a local AC1, the PE node forwards a B1 message according to a forwarding flow defined by [ EVPN prefix ], and assuming that the message should be forwarded to the PE3 according to a destination IP address of the B1 message without loss of generality. B1 was packaged as B1c and forwarded to PE 3.

The second step is the same as the corresponding step in the preferred embodiment 1, except that B1 is an IPv4 message and the feature field is the IPv4 quintuple of the B1 message.

The third step is the same as in the preferred embodiment 1 except that the forwarding plane flow is performed as [ EVPN prefix ].

Preferred embodiment 10

1: implementing the VPN infrastructure module:

except where specifically noted, this module is the same as in preferred embodiment 6;

unlike the preferred embodiment 6, the encapsulation format used by this module is compared with the encapsulation format used by it, and an SRH header is added, and the position of the SRH header is shown as the format C in fig. 17, where the format B is the format used by the preferred embodiment 6. The SRH header is a Segment routing header defined by IETF in draft-IETF-6man-Segment-routing-header (hereinafter abbreviated as "" SRH ""), and the format of the SRH header is defined in the [ SRH ], and comprises a Flags field and a Segment List field.

unlike preferred embodiment 6, this module directly uses ESI (10 bytes) corresponding to the main interface to which the entry AC of the first packet belongs as the lower 10 bytes of the 16-byte entropy value, and uses a hash value of 6 bytes generated by the source MAC, the destination MAC, the ethertype, and the VLAN ID of the first packet as the upper 6 bytes of the 16-byte entropy value.

Unlike the preferred embodiment 6, the packaging format used by the module is compared with the packaging format used by the module, and an SRH header is added, and the position of the SRH header is shown as format C in fig. 17, where format B is the format used by the preferred embodiment 6. The SRH header is a Segment routing header defined by IETF in draft-IETF-6man-Segment-routing-header (hereinafter referred to as 'SRH'), and the format of the SRH header is defined in the 'SRH', and comprises Flags fields and Segment List fields. The values of the Flags field in the SRH added by the module meet the following conditions: the result of bitwise logical and operation with a predetermined constant TBD1 is not 0, wherein, TBD1 is defined by IETF, and TBD1 may take several values, such as 1, 2, 4, and 128. Wherein, the Segment List field is an IPv6 address array, the array in the SRH head added by the module has only one element, namely Segment List [0], and the Segment List [0] value in the SRH head added by the module is the entropy value.

the module reads the entropy value from the Segment List [0] field of the SRH header of the third message, strips the SRH header off, copies the value of the next header field in the SRH header to the IPv6 header, obtains another message, and returns the another message to the VPN infrastructure module for processing, where the lower 10 bytes of the entropy value are ESIs corresponding to the entry AC of the fourth message carried by the third message, and may be used for message statistics, and records statistical data of messages from different ESIs at the far end into different counters, thereby improving the accuracy of message statistics;

and if the result of carrying out the bit-connection logic and operation on the Flags field of the SRH header and the preset constant TBD1 is 0, directly handing over the message to the VPN infrastructure module for processing without any processing.

It should be noted that the destination IP of the third packet is actually a local SID on the PE node configured with the destination IP, and the local SID concept is the local SID concept in section 4 of draft-filters-spring-srv 6-network-programming-01 (hereinafter referred to as "srv 6-program"). This module actually defines a new SRv6Function corresponding to the local SID, the SRv6Function concept being the SRv6Function concept described in [ srv6-program ] Section 4. This new SRv6Function indicates that the Segment List [0] field in the SRH header is an IP address that is not routable in the underlay network if it is different from the destination IP, and the destination IP field of the third packet cannot be overwritten with the Segment List [0] field as with the other SRv6 Function. This preferred embodiment may be used in combination with the SR-Policy function of SRv6, at this time, according to the message encapsulation specification of the SR-Policy, the destination IP of the third message is not the local SID on the destination PE node (i.e., the execution main body of this module) at first, but the destination IP of the third message is modified in the SRv6 forwarding flow through each non-service aware node or destination PE node, and finally becomes the local SID on the destination PE node, and the third message is processed according to the rule of the novel SRv6 function.

1: implementing the IP infrastructure module:

Different from the preferred embodiment 2, in the process of forwarding an IP packet whose destination IP is not a local interface IP, when performing load balancing path selection, if an IPv6 packet header includes the SRH header, the module calls the entropy IP third plug-in module to obtain the entropy value, and performs load balancing by using the source IP, the destination IP, and the entropy value.

As in the preferred embodiment 2, in this module, when the IP packet does not contain an SRH header, the IP quintuple is still used for load balancing.

and if the result of bitwise logical AND operation between the Flags field in the SRH header and the undetermined constant TBD1 is not 0, determining that the SRH header contains an entropy value, reading the entropy value from the SRH header, and determining that the entropy value is 0 if not. In this preferred embodiment, the method for reading out the entropy value corresponding to the VPN infrastructure module includes: reading a value of Segment List [0] in the SRH header as the entropy value.

except where otherwise specified, this step is the same as the corresponding step in preferred embodiment 6;

unlike preferred embodiment 6, the subnet mask configured for the first EVPN instance interface is 128 bits.

this step is the same as the corresponding step in preferred embodiment 6.

Preferred embodiment 11

1: implementing the VPN infrastructure module:

and (3) realizing the EVPN VPWS service packaged by the VXLAN according to RFC8214 and [ EVPN overlay ], and obtaining a control plane module of the EVPN VPWS service, namely a control plane part of the VPN infrastructure module. Wherein, the [ EVPN overlay ] mainly provides guidance for the format of the message, and the service processing flow conforms to RFC 8214.

Similarly, the EVPN VPWS service encapsulated by VXLAN is implemented according to RFC8214 and [ EVPN overlay ], and then the forwarding plane module of the obtained EVPN VPWS service is the forwarding plane part of the VPN infrastructure module.

It is worth mentioning that the EVPN VPWS control plane module obtained by the above method includes content such as BGP protocol L2VPN EVPN address family related configuration, configuration of an EVI instance corresponding to the EVPN VPWS, configuration of each VPWS service instance in the EVI instance, binding configuration of an AC and the VPWS service instance, ESI related configuration, and VPN Router ID configuration. The VPN Router ID is an IP address of a loopback interface. For simplicity of description, without loss of generality, this module sets a node to have only one VPN Router ID. The control plane part of the module obtained by the method can also establish a forwarding table entry of each VPWS service instance in each EVI instance under the participation of BGP routing.

Particularly, the control plane part of the module obtained by the method does not need to statically configure the VXLAN tunnel, and the RT-1 route can dynamically generate all needed VXLAN tunnels by adjusting the configuration of BGP. Without loss of generality, for simplicity, the BGP configuration may be adjusted such that the VXLAN tunnel generated by RT-1 routing complies with the following rules: only one bidirectional VXLAN tunnel is generated between any two PE nodes; the VPN Router ID of the node at which the two-way VXLAN tunnel is located is used as the source IP of the VXLAN tunnel at both ends of any two-way VXLAN tunnel, and at both ends of the same two-way VXLAN tunnel, the source IP of the tunnel at one end is exactly the destination IP of the tunnel at the other end, and the destination IP of the tunnel at one end is exactly the source IP of the tunnel at the other end. Similarly, by adjusting the BGP configuration, the RT-1 route can also generate all the binding relationships between all VXLAN tunnels and the EVI instance; these are all prior art and the particular methods involved will be apparent to those skilled in the art.

In particular, in the forwarding plane portion of the module obtained by the above method, the first message is only used to determine a local AC that receives the message, and after the local AC is determined, a field in the first message is no longer used to select message forwarding information.

The module is implemented as software, and a plug-in mechanism is required to be implemented, where the plug-in mechanism is used to call an entropy IP first plug-in to modify a source IP and a destination IP in an IP encapsulation after completing IP encapsulation from a first packet to a second packet when the module forwards the EVPN VPWS service forwarding flow, and to call an entropy IP second plug-in to modify the source IP and the destination IP in the IP encapsulation when the third packet is received and the third packet is processed. The plug-in can be a function call, a callback function, a polymorphic function or an independent plug-in.

Except for a plug-in mechanism, the module is the same as the forwarding flow of a corresponding forwarding module in RFC8214 and [ EVPN overlay ].

except where specifically noted, this module is the same as the preferred embodiment 10;

different from the preferred embodiment 10, this module uses the lower 16 bits of the Local descriptor value field in the 4 th type or 5 th type ESI corresponding to the main interface to which the entry AC of the first packet belongs as the lower 16 bits of the entropy value, and uses the lower 16 bits of the source MAC of the first packet as the upper 16 bits of the entropy value.

Unlike the preferred embodiment 10, this module inserts not the SRH Header at the position where it inserts the SRH Header into the third packet, but inserts a new IPv6 routing option Header, which is called an ERH (Entropy routing Header) Header, and, in order to quickly exclude the case where there is no Entropy in the IPv6 option Header, reduces the processing load of the non-service-aware node on the IPv6 option Header, and defines a predetermined constant TBD2, and when the value of the next Header field in the IPv6 Header is the predetermined constant TBD2, it indicates that the next Header is a routing Header, and the routing Header may contain an Entropy. The value of TBD2 is determined by IETF. One possible format of the ERH header is shown in fig. 16; wherein the control Value field is used for carrying the Entropy Value. The value of a Route-type field of the ERH Header is a predetermined constant TBD3, the value of the TBD3 is determined by IETF, the value of a Reserved2 field in the ERH Header is 0xFF, the values of Reserved3, Reserved4 and Reserved5 fields are 0, and the values of a Next Header and an Hdr Ext Len field are filled in according to the field definition of the routing Header in RFC 2460.

It should be noted that the access circuit AC of the EVPN VPWS service is not limited to an ethernet type interface, and when the access circuit AC is an access circuit identified by a frame relay FR data link connection identifier DLCI, or an access circuit AC is an access circuit identified by an asynchronous transfer mode ATM virtual path identifier VPI or virtual channel identifier VCI, the DLCI, VPI, or VCI may also be used to calculate the intrinsic entropy value of the first packet. How to configure such EVPN VPWS service is not an innovative point of the present invention, and therefore, it is not an example in this specification, and it should be clear to those skilled in the art how to extend the use of entropy values to non-ethernet type EVPN VPWS service according to the preferred embodiment.

directly stripping the ERH header of the third message, and copying the value of the next header field in the ERH header to the IPv6 header to obtain another message; and returning the obtained message to the VPN infrastructure module.

1: implementing the IP infrastructure module:

Different from the preferred embodiment 2, in the process of forwarding an IP packet whose destination IP is not a local interface IP, when performing load balancing path selection, if the value of the next header field in the IPv6 packet header is the TBD2, the first IPv6 option header is considered as a routing header, and may include an entropy value, and then an entropy IP third plug-in is invoked to obtain the inner layer entropy value, otherwise, the entropy IP third plug-in module is not invoked to obtain the entropy value.

Unlike in the preferred embodiment 2, in the case of successfully obtaining the entropy value by the above method, the load balancing is performed in this block by the source IP, the destination IP, and the entropy value, otherwise, the load balancing is still performed by the IP quintuple.

if the Value of the Route-type field in the first routing header of the third packet is equal to the predetermined constant TBD3, it indicates that it is an ERH header, where the Value of the entry Value field is the Entropy Value. Otherwise, the inner layer entropy value of the third message is considered to be 0.

Taking the EVPN VPWS topology shown in fig. 4 as an example, the network and service deployment process includes:

the first step is the same as the preferred embodiment 7 except that the type of underlay network selected in the preferred embodiment is an IPv6 network.

Second, the same as the preferred embodiment 7 except that the subnet mask of the loopback interface where the VPN Router ID is located is a 128-bit subnet mask.

The third step is the same as in the preferred embodiment 7 except that the VXLAN tunnel is generated and the generated VXLAN tunnel is bound to the EVPN instance for the RT-1 route instead of the RT-3 route.

And a fourth step of establishing an EVPN VPWS service as shown in fig. 4, and assigning the same VNI to the EVPN VPWS service on each PE node. And the 3 interfaces of AC1, AC2, AC3 and the like are used as access circuits to bind the EVPN VPWS service. After the above configuration is completed, the MP-BGP session starts inter-RT-1 routing according to the signaling flow defined in RFC8214, resulting in VXLAN tunnels between nodes being established and bound to the EVPN VPWS service.

And step five, configuring ESI. Same as the preferred embodiment 7 except that the signaling flow is that in RFC 8214.

And sixthly, establishing the EVPN VPWS service through the steps, and verifying the forwarding behaviors and effects on the PE node and the non-service-aware node defined in the preferred embodiment by using a data message.

Taking the EVPN VPWS topology shown in fig. 4 as an example, the end-to-end packet forwarding process includes:

first, when a PE1 node receives an IPv4 message B1 from a local AC1, the PE node forwards a B1 message according to a forwarding flow defined in RFC8214, assuming that the EVPN instance according to the B1 message should be forwarded to the PE3 without loss of generality. PE1 then encapsulates B1 into B1c and forwards to PE 3.

The second step is the same as the corresponding step in the preferred embodiment 1, except that B1 is an ethernet packet and the characteristic field is the source MAC of the B1 packet.

The third step is the same as the preferred embodiment 1 except that the forwarding plane flow is performed as in RFC 8124.

Preferred embodiment 12

The implementation of the PE node according to the technical solution of the method and apparatus (system) for transmitting and using the entropy value of the inner packet in the outer IP header will be further described in detail with reference to fig. 12:

1: implementing the VPN infrastructure module:

unlike the preferred embodiment 8, each ESI in this module has a corresponding homonymous interface, called ESI interface, on which the configured IP address has the full role of the loopback interface address.

different from the preferred embodiment 8, this module directly uses the whole of the ESI IP corresponding to the main interface to which the entry AC of the first packet belongs as the 128-bit entropy value. The ESI IP is an IP address configured on an ESI interface corresponding to the ESI corresponding to the main interface to which the entrance AC belongs;

unlike the preferred embodiment 8, this block populates the ESI IP with all 128 bits of the source IP as entropy values.

the module directly returns the third message to the VPN infrastructure module for continuous processing;

it should be noted that, because the entropy value carried by the source IP of the third packet is an integral body of the ESI IP corresponding to the main interface to which the local AC of the fourth packet belongs, and the ESI IP is routable in the underlay network, although it has all functions of entropy value, it also has a complete function of an IP address at the same time, and thus the ESI IP does not need to be regarded as zero here. However, the general entropy value is often pseudo-random and does not have the effect of a complete IP address, and therefore it is preferable to treat such a pseudo-random entropy value as zero at a non-traffic-aware node.

The implementation of the non-service aware P-node in the technical solution of the method and apparatus (system) for transmitting and using entropy of inner layer packet in outer IP header will be further described in detail with reference to fig. 6:

1: implementing the IP infrastructure module:

except where otherwise specified, this step is the same as the corresponding step in preferred embodiment 8;

different from the preferred embodiment 8, 128-bit subnet masks are configured on the loopback interfaces where the VPN Router IDs are located in the preferred embodiment.

this step is the same as the corresponding step in the preferred embodiment 8.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for sending a message is characterized by comprising the following steps:

receiving a first message from a first access circuit AC;

processing the first message to obtain one or more second messages; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message;

sending the second message;

the modifying the second IP address using the predetermined entropy value comprises at least one of:

replacing a value for a specified location in the second IP address with the predetermined entropy value, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value;

replacing the value of the designated location in the second IP address with a result of a calculation of the predetermined entropy value and the value of the designated location in the second IP address, wherein the predetermined entropy value is one of: an intrinsic entropy value, a context entropy value, a synthetic entropy value;

encrypting the value of the specified position in the second IP address by using the preset entropy value, wherein the preset entropy value is an intrinsic entropy value;

wherein the intrinsic entropy is an entropy obtained by calculating one or more characteristic fields in the first message; the context entropy value is an entropy value obtained by mapping one or more feature configuration information corresponding to the first access circuit AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the first message and the context entropy value of the first message.

2. The method of claim 1, wherein the first IP address is located in at least one of the following locations of the second packet: source IP, destination IP, internet protocol version 6 IPv6 option header.

3. The method of claim 1, wherein the characteristic field comprises at least one of:

a source IP, a destination IP, a protocol type, a source port, a destination port, a traffic type ToS field of IPv4 and a Flow label Flow-label field of IPv6 of the first message;

the source media access control MAC and the destination MAC of the first message;

the Ethernet type, the inner and outer layer virtual local area network identification VLAN ID and the 802.1p priority of the first message.

4. The method of claim 1, wherein the feature configuration information corresponding to the first AC comprises at least one of:

information mapped by the first AC;

node level configuration information obtained by a node where the first AC is located;

information mapped by a master interface to which the first AC belongs;

information obtained by performing hash calculation on an Ethernet segment identifier ESI corresponding to a main interface to which the first AC belongs;

ESI itself corresponding to the main interface to which the first AC belongs;

esip corresponding to ESI corresponding to a main interface to which the first AC belongs, where the ESI IP is an IP address configured for the ESI, and the ESI IP is different from esips corresponding to other ESIs on a node to which the ESI belongs.

5. The method of claim 1, wherein the integrated entropy value is obtained in at least one of:

carrying out bitwise logical XOR operation on the intrinsic entropy and the context entropy to obtain the comprehensive entropy;

calculating by the intrinsic entropy, the context entropy and any N constants to obtain the comprehensive entropy; wherein N is an integer greater than or equal to 1.

6. The method of claim 2, wherein, in the case that the first IP address is located in an IPv6 option header of the second packet, indicating whether the predetermined entropy value is present in the IPv6 option header by one of:

and indicating by a Next-header field in an IPv6 header of the second message, and indicating by a field in the IPv6 option header.

7. The method of claim 1, wherein the traffic class to which the first AC belongs comprises at least one of:

a Virtual Private Network (VPN) forwarded based on the MAC header of the first packet in the VPN;

a VPN forwarded based on the IP header of the first packet in the VPN;

and the VPN is forwarded in the VPN according to the configuration information on the first AC.

8. The method of claim 1, wherein processing the first packet comprises at least one of:

performing extensible virtual local area network VXLAN packaging on the first message;

carrying out VXLAN general protocol extension GPE encapsulation on the first message;

performing general network virtualization encapsulation (Geneve encapsulation) on the first message;

performing Network Virtualization General Routing Encapsulation (NVGRE) on the first message;

and performing segmented routing SRv6 encapsulation on the first packet, wherein the encapsulation is realized on an IPv6 data plane.

9. A method for processing a message is characterized by comprising the following steps:

receiving a third packet sent by a first Provider Edge (PE), where the third packet is a packet obtained by the first PE processing a fourth packet received from a first Access Circuit (AC) of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

processing the third message;

wherein, the intrinsic entropy is an entropy obtained by calculating one or more characteristic fields in the fourth message; the context entropy value is an entropy value obtained by mapping one or more feature configuration information corresponding to the first access circuit AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the fourth message and the context entropy value of the fourth message.

10. The method of claim 9, wherein the first IP address is located in at least one of the following locations of the third packet: source IP, destination IP, internet protocol version 6 IPv6 option header.

11. The method of claim 9, wherein in the case that the first IP address is located in an IPv6 option header of the third packet, indicating whether the predetermined entropy value is present in the IPv6 option header by one of:

indicated by a Next-header field in an IPv6 header of the third packet, and indicated by a field in the IPv6 option header.

12. The method of claim 9, wherein processing the third packet when the destination IP of the third packet is an IP address configured for a node receiving the third packet comprises:

setting binary bits in the first IP address in the third message, which are modified by the predetermined entropy value, to a predetermined value; wherein the preset values set by different binary bits are the same or different;

recalculating the predetermined entropy value, and decrypting the part encrypted by the predetermined entropy value in the first IP address in the third message by using the recalculated predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value;

stripping the IPv6 option header in the third message containing the first IP address;

and directly processing the third message.

13. The method of claim 9, wherein processing the third packet when the destination IP of the third packet is a remote IP address on a node receiving the third packet comprises at least one of:

selecting load balancing forwarding information according to the first IP address, and forwarding the third message according to the load balancing forwarding information;

respectively regarding binary digits corresponding to the predetermined entropy carried in the first IP address as predetermined values, and performing other processing except forwarding on the third message;

and directly forwarding the third message.

14. A message transmission apparatus, comprising:

a receiving module, configured to receive a first packet from a first access circuit AC;

the processing module is used for processing the first message to obtain one or more second messages; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message;

a sending module, configured to send the second packet;

15. The apparatus of claim 14, wherein the first IP address is located in at least one of the following locations of the second packet: source IP, destination IP, internet protocol version 6 IPv6 option header.

16. A message processing apparatus, comprising:

a receiving module, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by processing, by the first PE, a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

the processing module is used for processing the third message;

replacing the value of the designated location in the second IP address with a result of a calculation of the predetermined entropy value and the value of the designated location in the second IP address, wherein the predetermined entropy value is one of: intrinsic entropy, context entropy, synthetic entropy;

encrypting the value of the designated position in the second IP address by using the preset entropy value, wherein the preset entropy value is an intrinsic entropy value;

17. The apparatus of claim 16, wherein the first IP address is located in at least one of the following locations of the third packet: source IP, destination IP, internet protocol version 6 IPv6 option header.

18. A PE node, comprising:

a communication interface for receiving a first message from a first access circuit AC;

the processor is used for processing the first message to obtain one or more second messages; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; the predetermined entropy value is used for identifying the entropy of the first message;

the communication interface is used for sending the second message;

replacing a value for a specified location in the second IP address with the predetermined entropy value, wherein the predetermined entropy value is one of: intrinsic entropy, context entropy, synthetic entropy;

19. A node, comprising:

a communication interface, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a packet obtained by a first PE processing a fourth packet received from a first access circuit AC of the first PE, and the third packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value, and the preset entropy value is used for identifying the entropy of the fourth message;

a processor, configured to process the third packet;

the intrinsic entropy value is obtained by calculating one or more characteristic fields in the first message; the context entropy value is an entropy value obtained by mapping one or more feature configuration information corresponding to the first access circuit AC; the comprehensive entropy value is an entropy value obtained by jointly calculating the intrinsic entropy value of the first message and the context entropy value of the first message.

20. A message processing system, comprising: a first node and a second node; wherein the content of the first and second substances,

the first node is configured to receive a first packet from a first access circuit AC, process the first packet to obtain one or more second packets, and send the second packets to the second node; wherein the second packet includes: a first internet protocol, IP, address; the first IP address is obtained by modifying a second IP address by using a preset entropy value; wherein the predetermined entropy value is used for identifying the entropy of the first message;

the second node is used for processing the second message after receiving the second message;

21. A storage medium, comprising a stored program, wherein the program when executed performs the method of any one of claims 1 to 13.