WO2019105462A1

WO2019105462A1 - Method and apparatus for sending packet, method and apparatus for processing packet, pe node, and node

Info

Publication number: WO2019105462A1
Application number: PCT/CN2018/118580
Authority: WO
Inventors: 王玉保
Original assignee: 中兴通讯股份有限公司
Priority date: 2017-11-30
Filing date: 2018-11-30
Publication date: 2019-06-06
Also published as: CN109861924B; CN109861924A

Abstract

The present application provides a method and apparatus for sending a packet, a method and apparatus for processing a packet, a PE node, and a node. The method for sending a packet comprises: receiving a first packet from an access circuit (AC); processing the first packet to obtain at least one second packet, wherein the second packet comprises a first Internet protocol (IP) address, the first IP address being an IP address obtained after a second IP address is modified by using a predetermined entropy value, wherein the predetermined entropy value is used for identifying the entropy of the first packet; and sending the second packet.

Description

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

The present application claims priority to Chinese Patent Application No. JP-A No. No. No. No. No. No. No.

Technical field

The present application relates to the field of communications, for example, to a method for transmitting and processing a message, a PE node, and a node.

Background technique

In a virtual private network (VPN) service, network nodes are divided into service-aware nodes and non-service-aware nodes, which are Provider Edge (PE) nodes and scalable virtual local area networks. A VXLAN Tunnel End Point (VTEP) node or a Network Virtualization Edge (NVE) node, a non-service-aware node, that is, a PE node or a single-layer network (underlay) network node.

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

The LAG and the ECMP technology generally use the quintuple of the Internet Protocol (IP) packet, the source IP, the destination IP, the protocol type, the source port, and the destination port, as the feature field. The hash is calculated and used as the entropy value of the IP packet, and the arithmetic remainder operation is performed according to the entropy value to select a forwarding path for the packet from the plurality of forwarding paths. The information used to select the forwarding path for packets in load balancing is called entropy. Entropy works in the form of entropy values during load balancing routing.

However, for the VPN service, the quintuple defaults only the entropy of the underlay network, and the load balancing algorithm does not consider the entropy in the overlay network.

1 is a topology diagram of a virtual eXtensible Local Area Network (VXLAN) service defined by RFC 7348 in the related art. The VXLAN service shown in FIG. 1 is taken as an example. For a non-service-aware node P1, the same pair of <source PEs All VPN traffic flows between the destination PEs, whether they belong to different services or whether they are different flows in the same service, are selected by the load balancing algorithm of the LAG connected to the P2 node by the P1 node. On the same forwarding path (because the quintuple is equal), the degree of load balancing will be lower and the flow characteristics of the message cannot be reflected.

In view of the above technical problems in the related art, an effective solution has not yet been proposed.

Summary of the invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

The embodiment of the present application provides a method for sending and processing a message, a PE node, and a node, so as to avoid at least the flow characteristics of the overlay message in the underlay packet transmission process in the related art.

An embodiment of the present application provides a method for sending a packet, where the method includes: receiving a first packet from an access circuit AC; processing the first packet to obtain at least one second packet; wherein, the second packet The text includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify the entropy of the first packet; Message.

An embodiment of the present application provides a method for processing a packet, where the method includes: receiving a third packet sent by a first service provider edge device PE, where the third packet is a first PE pair from the first PE. The packet obtained by processing the fourth packet received by the access circuit AC, the third packet includes: a first Internet Protocol IP address; and the first IP address is an IP obtained by modifying the second IP address by using a predetermined entropy value. The address, the predetermined entropy value is used to identify the entropy of the fourth packet; and the third packet is processed.

An embodiment of the present application provides a packet sending apparatus, where the apparatus includes: a receiving module, configured to receive a first packet from an access circuit AC; and a processing module configured to process the first packet to obtain at least one a second packet, where the second packet includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying the second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify The entropy of the first packet; the sending module is configured to send the second packet.

An embodiment of the present application provides a packet processing apparatus, where the apparatus includes: a receiving module, configured to receive a third packet sent by a first service provider edge device PE, where the third packet is a first PE pair And receiving, by the fourth packet received by the access circuit AC of the first PE, the third packet includes: a first Internet Protocol IP address; the first IP address is a predetermined entropy value to the second IP address. The IP address obtained by the modification, the predetermined entropy value is used to identify the entropy of the fourth packet, and the processing module is configured to process the third packet.

The embodiment of the present application provides a provider edge PE node, including: a communication interface, configured to receive a first packet from an access circuit AC; and a processor configured to process the first packet to obtain at least one second a packet, where the second packet includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying the second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify the first Entropy of the message; the communication interface is set to send the second message.

The embodiment of the present application 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 connection of the first PE pair from the first PE. The packet obtained by processing the fourth packet received by the circuit AC, the third packet includes: a first Internet Protocol IP address; and the first IP address is an IP address obtained by modifying the second IP address by using a predetermined entropy value. The predetermined entropy value is used to identify the entropy of the fourth message; the processor is configured to process the third message.

The embodiment of the present application provides a packet processing system, including: a first node and a second node, where the first node is configured to receive a first packet from the access circuit AC, and perform the first packet Processing the at least one second packet and sending the second packet to the second node; wherein the second packet includes: a first Internet Protocol IP address; the first IP address is used An IP address obtained by modifying a second IP address by a predetermined entropy value; wherein the predetermined entropy value is used to identify an entropy of the first packet; and the second node is configured to receive the second packet After the text, the second message is processed.

The embodiment of the present application provides a storage medium, where the storage medium includes a stored program, where the program is executed to perform the method described in any one of the above.

The embodiment of the present application provides a processor, where the processor is configured to run a program, where the program is executed to perform the method described in any of the above.

Other aspects will be apparent upon reading and understanding the drawings and detailed description.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the present application, and are intended to be a part of this application. In the drawing:

1 is a topological diagram of a VXLAN service defined by RFC 7348 in the related art;

2 is a topological diagram of a VXLAN EVPN MAC-VRF service defined by a draft-ietf-bess-evpn-overlay ([EVPN Overlay]) in the related art;

3 is a topological diagram of a VXLAN EVPN IP-VRF service defined by draft-ietf-bess-evpn-prefix-advertisement ([EVPN Prefix]) in the related art;

4 is a topological diagram of an EVPN VPWS service defined by RFC 8214 in the related art;

FIG. 5 is a schematic flowchart of a packet sending method according to an embodiment of the present application;

FIG. 6 is a schematic flowchart of a method for processing a packet in a packet sending process to a P1 node according to an embodiment of the present application;

7 is a schematic flowchart of a method for processing a packet in a process of sending a packet to a PE2 node according to an embodiment of the present application;

FIG. 8 is a structural block diagram of a device for transmitting a message according to an embodiment of the present application;

FIG. 9 is a structural block diagram of a processing apparatus for a message according to an embodiment of the present application;

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

FIG. 11 is a structural block diagram of a node according to an embodiment of the present application;

FIG. 12 is a schematic structural diagram of a PE node according to an exemplary embodiment of the present application;

FIG. 13 is a schematic structural diagram of a non-service aware node according to an exemplary embodiment of the present application;

FIG. 14 is a simplified diagram of a VXLAN package and an SRv6 package according to an exemplary embodiment of the present application; FIG.

15 is a detailed detailed view of a VXLAN package and an SRv6 package according to an exemplary embodiment of the present application;

16 is a diagram of a possible encapsulation format of an Entropy Routing Header (ERH) according to an exemplary embodiment of the present application;

FIG. 17 is a comparison diagram of an SRH header format and an SRH header format of an SRv6 package according to an exemplary embodiment of the present application.

Detailed ways

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

It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or order.

Ethernet Virtual Private Network (EVPN) service is an important VPN service. RFC7432 defines its control plane framework, including Ethernet Auto-discovery Route and media access control. Four routes such as the Medium Access Control/Internet Protocol Advertisement Route (MAC/IP Advertisement Route), the Inclusive Multicast Ethernet Tag Route, and the Ethernet Segment Route They are called RT-1, RT-2, RT-3, and RT-4 routes, respectively. The draft-ietf-bess-evpn-prefix-advertisement defines the IP Prefix Route of the EVPN service, which is called RT-5 routing.

In RFC6790, the factor used for load balancing in the message is called entropy, and the method of carrying the label containing the entropy value in the message, the tag containing the entropy value includes the entropy of the overlay network, but the method depends on For Multi-Protocol Label Switching (MPLS) technology, the underlay network must support MPLS technology, that is, it depends on MPLS encapsulation. In an IPv4 network that does not support MPLS technology, the related technology does not carry entropy in the packet, so the load balancing is uneven.

In addition, in an IPv6 network that does 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 it is from RFC2460 In the decades between RFC3697 and RFC6437, the specific usage details of this field have not been clearly defined by the standard. Therefore, the field carrying entropy value in practice requires that all non-business-aware nodes in the underlay network support this field. Used for load balancing routing and not for other purposes, or pseudo-randomness of entropy values can interfere with the achievement of other purposes.

The entropy value of the RFC6790 refers to the entropy value generated according to the feature field of the body of the message, so that the context information of the message is lacking, and the context information includes the interface that the packet enters the device, the service to which the message belongs, and the message. The node to which the text belongs, etc., therefore, there is room for further improvement in the uniformity of load balancing.

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

In order to avoid the above situation, the present application provides the following embodiments:

Example 1

An embodiment of the present application provides a method for sending a packet, which may be applied to the topology described in FIG. 1 , but is not limited thereto. For example, the method may also be applied to the topology shown in FIG. 2 and FIG. 3 . The topology shown in FIG. 4 or the topology shown in FIG. 4, wherein FIG. 2 is an extensible virtual local area network virtual private network media access control virtual route forwarding defined by [EVPN Overlay] in the related art (Virtual Extensible Local Area Network Ethernet Virtual Private Network Medium Access Control-Virtual Routing Forwarding (VXLAN EVPN MAC-VRF) service topology; Figure 3 is an Ethernet virtual private network prefix [EVPN Prefix] defined in the related art, scalable virtual local area network Ethernet virtual private network Internet protocol virtual Topology diagram of the virtual eXtensible Local Area Network Ethernet Virtual Private Network Internet Protocol (Virtual Routing Forwarding, VXLAN EVPN IP-VRF) service; FIG. 4 is an Ethernet virtual private network virtual private line service defined by RFC8214 in related art (Ethernet Virtual Private Network Virtual Private Wire Service, EVPN VPWS) Topology diagram of the service. The execution body of the sending method may be a PE node, and the topology shown in FIG. 1 is taken as an example. The execution body of the sending method may be a PE1 node, a PE2 node, or a PE3 node, as shown in FIG. 1, and is not limited thereto.

The following is the execution body of the sending method is the PE1 node shown in FIG. 1 , and the sending process of the packet is from the Customer Edge 1 (CE1) to the underlay network via the Provider Edge 1 (PE1) node. The non-service aware node P1 transmission is described as an example. FIG. 5 is a schematic flowchart of a packet sending method according to an embodiment of the present application. As shown in FIG. 5, the method includes step S502, step S504, and step S506.

In step S502, the PE1 node receives the first packet from the access circuit (AC) of the PE1 node; wherein the access circuit (AC) is an interface between the PE node and the customer edge (CE) node. And a sub-interface or a virtual circuit, wherein the PE node includes a VTEP node and an NVE node.

In step S504, the PE1 node processes the first packet to obtain at least one second packet, where the second packet includes: a first Internet Protocol (IP) address; and the first IP address uses a predetermined entropy value. An IP address obtained by modifying the second IP address, where the predetermined entropy value is used to identify the entropy of the first packet;

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

It should be noted that the entropy value E (such as the predetermined entropy value) identifies the entropy of the packet P (such as the first packet), and the entropy value E is the specified algorithm F pair and the packet P. Calculating a value obtained by the corresponding at least one specified information, and when any one of the specified information corresponding to the message P randomly changes, the entropy value E calculated by the algorithm F also has The probability of the reservation changes.

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

The first IP address included in the second packet to be sent is an IP address obtained by modifying the second IP address by using a predetermined entropy value, where the predetermined entropy value is used to identify the entropy of the first packet. That is, by carrying the entropy value information related to the entropy of the first packet in the first IP of the second packet, the node receiving the second packet can benefit from the predetermined entropy value to a certain extent Differentiate whether the first packet encapsulated in the received second packet belongs to a different data stream, for example, whether it belongs to a different service, whether it belongs to a different <source MAC, destination MAC> binary group, that is, in the second packet. The flow characteristics of the first packet encapsulated in the transmission process can be reflected in the transmission process, thereby avoiding the situation that the flow characteristics of the overlay message cannot be reflected in the underlay packet transmission process in the related art, 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 locations of the second packet: source IP, destination IP, and Internet Protocol version 6 IPv6 option header. By placing the first IP address in at least one of the source IP address, the destination IP address, and the Internet Protocol version 6 IPv6 option header, that is, by carrying the entropy value of the first packet in the second packet. At least one of the source IP address, the destination IP address, and the Internet Protocol version 6 IPv6 option header, and the MPLS encapsulation of the packet is not required, that is, in the IPv4 or IPv6 network that does not support MPLS, the packet is implemented. The method of carrying the entropy value further avoids the uneven load balancing in the IPv4 and IPv6 underlay networks without requiring the non-service-aware node upgrade in the underlay network and not relying on the MPLS technology.

In an embodiment, if the first IP address is in the IPv6 option header of the second packet, indicating whether the predetermined entropy value exists in the IPv6 option header by using one of the following manners: The Next-header field in the IPv6 header of the second message indicates that it is indicated by a field in the IPv6 option header.

It should be noted that the foregoing IPv6 header may be an IPv6 option header or an IPv6 mandatory header, which is not limited thereto.

It should be noted that the second IP address may be the source IP or the destination IP of the second packet obtained by processing the first packet when the function switch of the application is not opened, but not Limited to this. 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 second IP address is modified with the predetermined entropy value in the IPv6 option. A copy of the head.

It should be noted that the processing in the above step S504 may be expressed as: encapsulation, modification, but is not limited thereto.

It should be noted that modifying the second IP address by using the predetermined entropy value includes at least one of replacing a value of a specified position in the second IP address with a predetermined entropy value, wherein the predetermined entropy value is One of: an eigen-entropy value, a context entropy value, and a comprehensive entropy value; replacing the result obtained by calculating the predetermined entropy value with a value of a specified position in the second IP address, replacing the second IP address a value of the specified location, wherein the predetermined entropy value is one of: an eigenenic entropy value, a context entropy value, and a comprehensive entropy value; and the value of the specified location in the second IP address is encrypted with the predetermined entropy value The predetermined entropy value is an eigen-entropy value; wherein the eigen-entropy value is an entropy value obtained by hash calculation of at least one feature field in the first packet; the context entropy value An entropy value obtained by mapping at least one feature configuration information corresponding to the AC; the integrated entropy value is calculated by using an eigen-entropy value of the first packet and a context entropy value of the first packet Entropy value.

It should be noted that the entropy value of the FRC6790 refers to the entropy value generated according to the feature field of the text body, so that the context information of the packet is lacking, and the context information includes the interface of the packet entering the device and the packet to which the packet belongs. The service, the node to which the message belongs, and the like, and in the embodiment of the present application, when the predetermined entropy value is the context entropy value or the integrated entropy value, that is, the context entropy is carried in the first IP of the second packet. The value or the integrated entropy value further improves the uniformity of load balancing.

In an embodiment of the present application, the predetermined entropy value includes an eigen-entropy value, and the value of the specified position in the second IP address is encrypted by using a predetermined entropy value, that is, the second eigen-entropy value of the first packet is used. The IP address is encrypted. The entropy of the first packet is added to the packet, and the IP address on the PE1 node is encrypted. The non-service-aware node in the underlay network is not required to be upgraded and does not depend on MPLS technology. In this case, the load balancing unevenness in the IPv4 and IPv6 underlay networks is avoided, and the IP address is not exposed.

It should be noted that the foregoing feature 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 the IPv6 of the first packet; The source media access control (MAC) and the destination MAC address of the first packet; the Ethernet type (ethertype) of the first packet, the virtual local area network identity (VLAN ID), and the 802.1p priority. level. The 802.1p priority refers to a priority field defined by 802.1p, and includes a priority in a tag whose Tag Protocol Identifier (TPID) is 0x8100 or 0x88a8.

The feature configuration information corresponding to the AC may include at least one of the following: information obtained by the AC mapping; node-level configuration information obtained by the node where the AC is located; and information obtained by mapping the primary interface to which the AC belongs; Information obtained by hashing the Ethernet segment identifier (ESI) corresponding to the primary interface to which the AC belongs; the ESI itself corresponding to the primary interface to which the AC belongs; the primary interface to which the AC belongs ESI IP corresponding to the ESI, wherein the ESI IP is an IP address configured for the ESI, and the ESI IP corresponds to an ESI IP corresponding to an ESI other than the ESI on a node to which the ESI belongs Different from each other.

In the embodiment of the present application, the foregoing comprehensive entropy value may be obtained according to at least one of the following methods, but is not limited thereto: performing a bitwise logical exclusive OR operation on the eigenenic entropy value and the context entropy value to obtain a Calculating a comprehensive entropy value; calculating the eigeng entropy value, the context entropy value, and any N constants to obtain the integrated entropy value; wherein N is an integer greater than or equal to 1.

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

In an embodiment of the present application, the service type of the AC may include at least one of: a VPN forwarded based on a MAC header of the first packet in a virtual private network (VPN); VPN forwarded by the IP header of a message (how to refer to the VPN forwarded based on the IP header of the first packet in the VPN, see the exemplary embodiment 9); the VPN forwarded according to the configuration information on the AC in the VPN (See Example 11 for how to forward a VPN in accordance with the configuration information on the AC in the VPN).

In an embodiment of the present application, the foregoing step S504 may also be performed as at least one of the following, but is not limited thereto: the PE1 node performs an Extensible Virtual Local Area Network (VXLAN) encapsulation on the first packet; The first packet is encapsulated in a VXLAN Generic Protocol Extensions (GPE); the PE1 node performs Generic Network Virtualization Encapsulation (Geneve) on the first packet; and the PE1 node pairs the first packet. The packet is subjected to Network Virtualization using Generic Routing Encapsulation (NVGRE). The PE1 node encapsulates the first packet with the SRv6 (Segment Routing instantiated on the IPv6 data plane, SRv6).

It should be noted that the segment route SRv6 may be "implemented by IPv6 data plane" or "SRv6refers to Segment Routing instantiated on the IPv6 data plane".

It should be noted that the above description is made with PE1 as the execution subject, but the present invention is not limited to PE1 as the execution subject, and may be PE2, PE3, etc., and is not limited.

An embodiment of the present application further provides a method for processing a message, and the processing method of the packet may also be applied to the topology shown in any of the foregoing FIG. 1 to FIG. 4, and the following still takes FIG. 1 as an example. For example, the execution body of the packet processing method may be any one of PE1, PE2, PE3, P1, and P2 in FIG. 1, where P1 and P2 are non-service-aware nodes, and the following is performed by the processing method. The main body is the P1 node shown in FIG. 1, and the packet transmission process is described as an example from the PE1 node to the non-service-aware node P1 or the PE2 in the underlay network. FIG. 6 is a schematic flowchart of a method for processing a packet in a packet sending process to a P1 node according to an embodiment of the present application. As shown in FIG. 6, the method includes steps S602 and S604.

In step S602, the P1 node receives a third packet sent by the first service provider edge device (PE), where the third packet is an access circuit of the first PE pair from the first PE. (AC) The received packet is processed by the fourth packet, where the third packet includes: a first Internet Protocol (IP) address; the first IP address is a predetermined entropy value to the second IP address. And performing the modified IP address, where the predetermined entropy value is used to identify the entropy of the fourth packet.

In step S604, the P1 node processes the third message.

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

The first IP address included in the received third packet is an IP address obtained by modifying the second IP address by using a predetermined entropy value, where the predetermined entropy value is used to identify the fourth packet. Entropy; that is, by carrying the entropy value information related to the entropy of the fourth packet in the IP of the third packet, so that P1 can distinguish the encapsulated different second packet encapsulated by the predetermined entropy value to some extent. Whether the first packet belongs to a different data stream, for example, whether it belongs to a different service, whether it belongs to a different <source MAC, destination MAC> binary group, that is, the first packet encapsulated in the second packet transmission process The flow characteristics of the packet can avoid the situation that the flow characteristics of the overlay message cannot be reflected in the underlay packet transmission process in the related art, and the degree of load balancing is improved.

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

It should be noted that, in a case where the first IP address is located in an 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: The Next-header field indication in the IPv6 header of the third message is indicated by a field in the IPv6 option header.

It should be noted that the destination IP address of the third packet is a remote IP address on the node that receives the third packet, that is, the execution entity of the processing method may be a P1 node, and the foregoing step S604 may be represented by at least one of the following The P1 node selects the load balancing forwarding information according to the first IP address, and the P1 node forwards the third packet according to the load balancing forwarding information; the P1 node and the predetermined entropy carried in the first IP address The binary bits corresponding to the values are respectively regarded as predetermined values, and the third packet is subjected to other processing than forwarding; the P1 node directly forwards the third packet.

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 foregoing predetermined entropy value may be the same as the meaning or interpretation of the predetermined entropy value in the embodiment shown in FIG. 5 above, and details are not described herein again.

FIG. 7 is a schematic flowchart of a method for processing a packet in a packet sending process to a PE2 node according to an embodiment of the present application. As shown in FIG. 7, the method includes steps S702 and S704.

In step S702, the PE2 node receives the third packet sent by the first service provider edge device PE, where the third packet is the access circuit of the first PE pair from the first PE (AC) a packet obtained by processing the received fourth packet, where the third packet includes: a first Internet Protocol (IP) address; the first IP address is a modification of the second IP address by using a predetermined entropy value The obtained IP address, the predetermined entropy value is used to identify the entropy of the fourth packet.

In step S704, the PE2 node processes the third message.

It should be noted that, in the foregoing step S702, the PE2 may directly receive the third packet sent by the PE1, or may receive the third packet sent by the PE1 by using the P1 or P2 forwarding manner, but is not limited thereto.

It should be noted that, in a case where the first IP address is located in an 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: The Next-header field in the IPv6 header of the three messages indicates the field in the header of the IPv6 option.

In the case that the destination IP address of the third packet is the IP address configured for the PE2 node, that is, the processing subject of the third packet is PE2, the foregoing step S704 may be performed as follows: The binary bit of the first IP address modified by the predetermined entropy value is set to a predetermined value; wherein the predetermined values set by different binary bits are the same or different; the predetermined entropy value is recalculated and recalculated The predetermined entropy value decrypts a portion of the first IP address in the third packet that is encrypted by the predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; The IPv6 option header stripping of the first IP address in the third packet is stripped; the third packet is directly processed.

It should be noted that, for the above-mentioned predetermined entropy value, the interpretation of the eigen-entropy value and the like can refer to the explanation of the predetermined entropy value and the eigen-entropy value in the embodiment shown in FIG. 5, and details are not described herein again, thank you.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware. Based on such understanding, the technical solution of the present application, which is essential or contributes to the related art, may be embodied in the form of a software product stored in a storage medium such as a read only memory/random access memory. (Read Only Memory/Random Access Memory, ROM/RAM), a disk, and an optical disk, including instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform each implementation of the present application. The method described in the example.

Example 2

In this embodiment, a device for transmitting a message is provided, and the device is configured to implement the foregoing embodiments and example embodiments, and details are not described herein. As used hereinafter, the term "module" is a combination of at least one of software and hardware that can perform a predetermined function. The apparatus described in the following embodiments may be implemented in software, but hardware, or a combination of software and hardware, is also possible and conceivable.

It should be noted that the sending apparatus of the packet provided by the embodiment of the present application may be located on the PE node shown in any one of FIG. 1 to FIG. 4, such as the PE1 node, the PE2 node, or the PE3 node shown in FIG. Not limited to this.

FIG. 8 is a structural block diagram of a device for transmitting a message according to an embodiment of the present application. As shown in FIG. 8, the device includes a receiving module 82, a processing module 84, and a sending module 86.

The receiving module 82 is configured to receive the first message from the access circuit (AC).

The processing module 84 is connected to the receiving module 82, and configured to process the first packet to obtain at least one second packet. The second packet includes: a first Internet Protocol (IP) address. The first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify an entropy of the first packet.

The sending module 86 is connected to the processing module 84 and configured to send the second packet.

It should be noted that the access circuit (AC) is an interface, a sub-interface, or a virtual circuit between a PE node and a customer edge (CE) node, where the PE node includes a VTEP node and an NVE node; entropy The value E (such as the above-mentioned predetermined entropy value) identifies the entropy of the packet P (such as the first packet), and the entropy value E is the at least one specified information corresponding to the packet P by the specified algorithm F. The calculated value is performed, and when any one of the specified information corresponding to the message P is randomly changed, the entropy value E calculated by the algorithm F also has a predetermined probability to change.

It should be noted that, in a case where the first IP address is located in an 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: The Next-header field in the IPv6 header of the second message indicates that it is indicated by a field in the IPv6 option header.

It should be noted that the above processing may be expressed as: encapsulation, modification, but not limited thereto.

In an embodiment of the present application, the predetermined entropy value includes an eigen-entropy value, and the value of the specified position in the second IP address is encrypted by using a predetermined entropy value, that is, the second eigen-entropy value of the first packet is used. The IP address is encrypted. The entropy of the first packet is added to the packet and the IP address on the PE1 node is encrypted. The non-service-aware node in the underlay network is not required to be upgraded and does not depend on MPLS technology. In this case, the load balancing in the IPv4 and IPv6 underlay networks is not uniform, and the IP address is not exposed.

It should be noted that the foregoing feature field may include at least one of the following: source IP, destination IP, protocol type, source port, destination port, IPv4 ToS field, and IPv6 flow label (Flow-1abel) of the first packet. a field; a source media access control (MAC) of the first packet, a destination MAC; an ethertype of the first packet, an inner and outer virtual local area network identifier (VLAN ID), and an 802.1p priority; The 802.1p priority refers to a priority field defined by 802.1p, and includes a priority in a tag whose Tag Protocol Identifier (TPID) is 0x8100 or 0x88a8.

The feature configuration information corresponding to the AC may include at least one of the following: information obtained by the AC mapping; node-level configuration information obtained by the node where the AC is located; and information obtained by mapping the primary interface to which the AC belongs; Information obtained by hashing the Ethernet segment identifier (ESI) corresponding to the primary interface to which the AC belongs; the ESI itself corresponding to the primary interface to which the AC belongs; the ESI IP corresponding to the ESI corresponding to the primary interface to which the AC belongs, The ESI IP is an IP address configured for the ESI, and the ESI IP is different from the ESI IP corresponding to other ESIs on the node to which the ESI belongs.

In the embodiment of the present application, the processing module 84 may be further configured to obtain the foregoing comprehensive entropy value according to at least one of the following methods, but is not limited thereto: performing bitwise by the eigen entropy value and the context entropy value Performing a logical exclusive OR operation to obtain the integrated entropy value; calculating by the eigen-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 . It should be noted that the above calculation may be hashed, but is not limited thereto.

In an embodiment of the present application, the service type of the AC may include at least one of: a VPN forwarded based on a MAC header of the first packet in a virtual private network (VPN); A VPN forwarded by the IP header of a packet; a VPN forwarded in the VPN according to the configuration information on the AC.

In an embodiment of the present application, the processing module 84 may be configured as at least one of the following, but is not limited thereto: performing an Extensible Virtual Local Area Network (VXLAN) encapsulation on the first packet; The packet is subjected to VXLAN General Protocol Extension (GPE) encapsulation; the first packet is subjected to a general network virtualization encapsulation (Geneve); and the first packet is subjected to network virtualization for network virtualization (Gene Virtualization using Generic Routing) Encapsulation, NVGRE); extending the SRv6 encapsulation of the first packet.

The embodiment of the present application further provides a processing device for a message that can be used in the topology shown in any of the above-mentioned FIG. 1 to FIG. 4, and it should be noted that the processing device for the topology message may be located in FIG. 1 to A PE node (such as PE1, PE2, and PE3 is not limited to this) or a non-service-aware node (P1 or P2), and FIG. 9 is a processing device of a packet according to an embodiment of the present application. The block diagram, as shown in FIG. 9, includes a receiving module 92 and a processing module 94.

The receiving module 92 is configured to receive a third packet sent by the first service provider edge device PE, where the third packet is an access circuit (AC) of the first PE pair from the first PE The received packet is processed by the received fourth packet, where the third packet includes: a first Internet Protocol (IP) address; the first IP address is modified by using a predetermined entropy value to obtain the second IP address. The IP address, the predetermined entropy value is used to identify the entropy of the fourth packet.

The processing module 94 is connected to the receiving module 92 and configured to process the third packet.

It should be noted that the third message corresponds to the second message in the embodiment shown in FIG. 8 , and the fourth message corresponds to the first message in the embodiment shown in FIG. 8 . The PE node where the device shown in FIG. 8 is located in the first PE is not limited thereto.

And the first IP address included in the received third packet is an IP address obtained by modifying the second IP address by using a predetermined entropy value, where the predetermined entropy value is used to identify the fourth packet. Entropy; that is, by carrying the entropy value information related to the entropy of the fourth packet in the IP of the third packet, so that P1 can distinguish the encapsulated different second packet encapsulated by the predetermined entropy value to some extent. Whether the first packet belongs to a different data stream, for example, whether it belongs to a different service, whether it belongs to a different <source MAC, destination MAC> binary group, that is, the first packet encapsulated in the second packet transmission process The flow characteristics of the packet can avoid the situation that the flow characteristics of the overlay message cannot be reflected in the underlay packet transmission process in the related art, and the degree of load balancing is improved.

It should be noted that, in a case where the first IP address is located in an 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: The Next-header field indication in the IPv6 header of the three messages is indicated by the field in the IPv6 option header.

It should be noted that the destination IP address of the third packet is the remote IP address of the node that receives the third packet, that is, the processing device is located in the P1 node, and the processing module 94 may be configured to be at least one of the following: The first IP address selects the load balancing forwarding information, and the third packet is forwarded according to the load balancing forwarding information; and the binary bits corresponding to the predetermined entropy value carried in the first IP address are respectively regarded as a predetermined value, performing processing other than forwarding on the third packet; directly forwarding the third packet.

It should be noted that the foregoing 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 address of the third packet is an IP address configured for the PE node, that is, the processing device is located in the PE node, the processing module 94 may be configured to set at least one of the following: The binary bits in the first IP address modified by the predetermined entropy value are set to a predetermined value; wherein the predetermined values set by different binary bits are the same or different; the predetermined entropy value is recalculated, and Calculating, by the predetermined entropy value, a portion of the first IP address in the third packet that is encrypted by the predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; The IPv6 option header including the first IP address in the third packet is stripped; the third packet is directly processed.

It should be noted that the foregoing predetermined entropy value may be the same as the meaning or interpretation of the predetermined entropy value in the embodiment shown in FIG. 8 above, and details are not described herein again.

It should be noted that the foregoing multiple modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the multiple modules are The form of any combination is located in a different processor.

Example 3

The embodiment of the present application further provides a PE node, which may be a PE node as 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. According to the structure diagram of the PE node provided by the embodiment of the present application, as shown in FIG. 10, the PE node includes a communication interface 1002 and a processor 1004.

The communication interface 1002 is configured to receive the first message from the access circuit (AC).

The processor 1004 is connected to the communication interface 1002, and is configured to process the first packet to obtain at least one second packet. The second packet includes: a first Internet Protocol (IP) address; the first IP address. The address is an IP address obtained by modifying the second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify the entropy of the first packet.

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

The first IP address included in the second packet sent by the PE node is an IP address obtained by modifying the second IP address by using a predetermined entropy value, where the predetermined entropy value is used to identify the first packet. Entropy; that is, by carrying the entropy value information related to the entropy of the first packet in the first IP of the second packet, so that the node receiving the second packet can benefit from the predetermined entropy value to a certain extent Whether the first packet encapsulated in the received second packet belongs to a different data stream, for example, whether it belongs to a different service, whether it belongs to a different <source MAC, destination MAC> binary group, that is, in the second report. The transmission process of the text can reflect the flow characteristics of the first packet encapsulated in the text, so that the flow characteristics of the overlay message cannot be reflected in the underlay packet transmission process in the related art, and the degree of load balancing is improved.

It should be noted that the access circuit (AC) is an interface, a sub-interface, or a virtual circuit between a PE node and a client edge CE node, where the PE node includes a VTEP node and an NVE node; and an entropy value E The entropy of the packet P (such as the foregoing first packet) is determined by the entropy value E, and the at least one specified information corresponding to the packet P is calculated by the specified algorithm F. The obtained value, and when any one of the specified information corresponding to the message P is randomly changed, the entropy value E calculated by the algorithm F also has a predetermined probability of change.

It should be noted that the foregoing feature field may include at least one of the following: a source IP, a destination IP, a protocol type, a source port, a destination port, an IPv4 ToS field, and a Flow-1abel field of the IPv6. a source media access control (MAC) and a destination MAC address of the first packet, an ethertype of the first packet, an inner and outer virtual local area network identifier (VLAN ID), and an 802.1p priority; The 802.1p priority refers to the priority field defined by 802.1p, including the priority in the tag with the Tag Protocol Identifier (TPID) of 0x8100 or 0x88a8.

In the embodiment of the present application, the processor 1004 may be further configured to obtain the foregoing comprehensive entropy value according to at least one of the following methods, but is not limited thereto: performing bitwise by the eigen entropy value and the context entropy value Performing a logical exclusive OR operation to obtain the integrated entropy value; calculating by the eigen-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 . It should be noted that the above calculation may be hashed, but is not limited thereto.

In an embodiment of the present application, the processor 1004 may be configured as at least one of the following, but is not limited thereto: performing an extensible virtual local area network (VXLAN) encapsulation on the first packet; The packet is subjected to VXLAN General Protocol Extension (GPE) encapsulation; the first packet is subjected to a general network virtualization encapsulation (Geneve); and the first packet is subjected to network virtualization for network virtualization (Gene Virtualization using Generic Routing) Encapsulation, NVGRE); extending the SRv6 encapsulation of the first packet.

The embodiment of the present application further provides a node, which may be a PE node (such as PE1, PE2, PE3 is not limited to this) or a non-service aware node (P1 or P2) as shown in any one of FIG. 1 to FIG. FIG. 11 is a structural block diagram of a node according to an embodiment of the present application. As shown in FIG. 11, the device includes a communication interface 1102 and a processor 1104.

The communication interface 1102 is configured to receive a third packet sent by the first serving provider edge device PE, where the third packet is a fourth packet received by the first PE from the access circuit (AC) of the first PE. And processing the obtained packet, the third packet includes: a first Internet Protocol (IP) address; the first IP address is an IP address obtained by modifying the second IP address by using a predetermined entropy value, and the predetermined entropy value is used for identifying The entropy of the fourth message.

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

It should be noted that the third message corresponds to the second message in the embodiment shown in FIG. 10, and the fourth message corresponds to the first message in the embodiment shown in FIG. The first PE described above is the PE node shown in FIG. 10, but is not limited thereto.

It should be noted that the destination IP address of the third packet is the remote IP address of the node that receives the third packet, that is, the node is a non-service aware node, and the processor 1104 may be configured as at least one of the following Selecting the load balancing forwarding information according to the first IP address, and forwarding the third packet according to the load balancing forwarding information; respectively, the binary bits corresponding to the predetermined entropy value carried in the first IP address are respectively Considering a predetermined value, performing processing other than forwarding on the third packet; directly forwarding the third packet.

When the destination IP address of the third packet is an IP address configured for the PE node, that is, the foregoing node is a PE node, the processor 1104 may be configured to be at least one of the following: The binary bit of the first IP address modified by the predetermined entropy value is set to a predetermined value; wherein the predetermined values set by different binary bits are the same or different; the predetermined entropy value is recalculated and recalculated The predetermined entropy value decrypts a portion of the first IP address in the third packet that is encrypted by the predetermined entropy value; wherein the predetermined entropy value is an intrinsic entropy value; The IPv6 option header stripping of the first IP address in the third packet is stripped; the third packet is directly processed.

It should be noted that the foregoing predetermined entropy value may be the same as the meaning or interpretation of the predetermined entropy value in the embodiment shown in FIG. 10 above, and details are not described herein again.

Example 4

The embodiment of the present application further provides a packet processing system, including: a first node and a second node; wherein the first node is configured to receive a first packet from an access circuit (AC), where The first packet is processed to obtain at least one second packet, and the second packet is sent to the second node, where the second packet includes: a first Internet Protocol (IP) address; The first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value; wherein the predetermined entropy value is used to identify an entropy of the first packet; and the second node is set to After receiving the second packet, processing the second packet.

It should be noted that the first node may be the PE node shown in FIG. 10 in the foregoing Embodiment 3, and the second node may be the node shown in FIG. 11 in the foregoing Embodiment 3 (PE node or non-service sensing). node). For the explanation of the first node and the second node, refer to Embodiment 3, and details are not described herein again.

Example 5

The embodiment of the present application further provides a storage medium including a stored program, wherein the program runs to perform the method described in any of the above.

In this embodiment, the foregoing storage medium may include, but is not limited to, a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk. A variety of media that can store program code.

Embodiments of the present application also provide a processor configured to execute a program, wherein the program executes the steps of any of the above methods when executed.

For specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and example embodiments, and details are not described herein again.

In order to better understand the embodiments of the present application, the present application will be further explained below in conjunction with the embodiments of the examples.

The entropy IP transceiver node provided by the exemplary embodiment of the present application is used as a PE node, and the non-service-aware node of the relevant underlay network is not upgraded, and the underlay network is not required to support the MPLS technology, thereby avoiding non-service awareness of the related underlay network. The load balancing on the node cannot reflect the flow characteristics of the overlay packet. In addition, since the entropy value can be carried in at least one of the source IP and the destination IP, it is possible to avoid load balancing unevenness and the need to upgrade the non-service-aware node of the relevant underlay network and the requirement that the underlay network support the MPLS technology. Under the premise of not requiring non-service-aware node upgrade in the underlay network, the use of unified technology avoids uneven load balancing in IPv4 and IPv6 underlay networks. Since the context entropy value is identified, the degree of uniformity of the load balancing is further improved by further carrying the context entropy value. Further, by encrypting the source IP or the destination IP with the intrinsic entropy value of the Overlay packet, the entropy of the Overlay packet is added to the underlay IP header, and the IP address on the PE node is encrypted, which can be simultaneously improved. In the above case, the effect of the entropy value is achieved to achieve a comprehensive effect.

12 is a schematic structural diagram of a PE node according to an exemplary embodiment of the present application. As shown in FIG. 12, the system includes: a VPN infrastructure module, an entropy IP first plug-in module, and an entropy IP second plug-in module, where entropy IP is second. The plug-in module is optional, that is, the PE node may include an entropy IP second plug-in module, or may not include an entropy IP second plug-in module, and specifically includes or does not include an entropy IP second plug-in module, and may be set as needed, and Not limited.

It should be noted that the VPN infrastructure module may be similar to the functions performed by the receiving module 82 and the sending module 86, and may complete some functions of the processing module 84, and may complete the functions of the communication interface 1002 and the portion of the processor 1004. The function, or the functions performed by the communication interface 1102 described above and some functions of the processor 1104, may be completed, but are not limited thereto.

The entropy IP first plug-in module may perform some functions of the processing module 84 or the processor 1004, such as a function of modifying a second IP using a predetermined entropy value; the entropy IP second plug-in module may complete the processor 1104. Some features, but not limited to this.

FIG. 13 is a schematic structural diagram of a non-service-aware node according to an exemplary embodiment of the present application. As shown in FIG. 13, the method includes: an IP basic setting module and an entropy IP third plug-in module. It should be noted that the entropy IP third plug-in module is optional, that is, the non-service-aware node may include an entropy IP third plug-in module, or may not include an entropy IP third plug-in module, and specifically includes or does not include entropy IP. The three plug-in modules can be set as needed, and are not limited.

It should be noted that the IP basic setting module may complete some functions of the communication interface 1102 and the processor 1104. The entropy IP third plug-in module may perform some functions of the processor 1104, but is not limited thereto.

The functions of the above modules included in the above PE node or non-service aware node may be described in detail by the following exemplary embodiments.

Example embodiment 1

The implementation of the PE node of the method and apparatus (system) of transmitting and using the entropy value of the inner layer message in the outer IP header will be further described in detail with reference to FIG.

1: Implement the VPN infrastructure module.

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

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

Except for special instructions, this module has the same human machine interface and processing flow as RFC7348 described above.

It is worth mentioning that an EVPN control plane module obtained by the above method is used for the configuration of the VXLAN tunnel, the configuration of the EVPN instance, the binding configuration of the AC and the EVPN instance, and the VXLAN tunnel. Binding configuration of the EVPN instance. The EVPN instance is identified by the VNI and the VNI is configured by the user. The VXLAN tunnel uses the VPN Router ID of the node as the source IP and the VPN Router ID of the peer node as the destination IP. The VPN Router ID is an IP address of a loopback interface. For the sake of simplicity, without loss of generality, this module sets a node with only one VPN Router ID.

As a software implementation, the module needs to implement a plug-in mechanism, and when the module forwards the first packet according to the RFC7432 process, the IP packet is added to the first packet, and the X-th message is obtained. The packet does not encapsulate the link layer forwarding information (such as the Ethernet header). Then, the X-th entropy IP first plug-in module is used to modify the source IP address and the destination IP address in the IP encapsulation to obtain the Yth packet, and then obtain the Yth packet. And continuing to forward the yth message according to the process of the RFC7432, including encapsulating the link layer forwarding information and other forwarding information according to the destination IP address of the yth message, and obtaining the second packet (corresponding to the foregoing embodiment) a second message or a third message), and sending the second message. The plugin mechanism can be a function call, a callback function, a polymorphic function, or a standalone plugin.

Except for the plug-in mechanism, the forwarding plane of the module is the same as that of the forwarding plane of the RFC7348, including the BUM packet forwarding process, the MAC learning process, and the unicast forwarding and forwarding process.

In addition, the IP address of the VPN Router ID must be a loopback interface address, the loopback interface address can be configured with a subnet mask, and the value of each bit of the subnet mask is not required to be 1 . It is worth mentioning that when the low N bit value of the subnet mask is 0, the loopback interface will form a route prefix corresponding to the subnet mask in the IP routing table, and in the underlay network. The route prefix is advertised; and the node considers that the packet with the destination IP address matching the route prefix is the packet of the loopback interface and the packet whose destination IP address is the IP address of the loopback interface. The same processing.

In addition, without loss of generality, in the present exemplary embodiment, the underlay network is set to be an IPv4 network. Therefore, the source IP address and the destination IP address of the VXLAN tunnel are both IPv4 addresses.

In addition, the destination IP of the received third packet (equivalent to the second packet or the third packet in the foregoing embodiment) matches the interface corresponding to the interface where the source IP address of the EVPN tunnel is located. When the route prefix is connected, the third packet is matched to the tunnel, and the source IP of the third packet is matched to the destination IP address of the EVPN tunnel.

2: A specific method of implementing the entropy IP first plug-in.

Different from RFC7348, the module further calculates a 5-bit entropy value by using a hash operation based on the source MAC address of the first packet, and replaces the destination IP address of the IP packet input by the VPN infrastructure module with the obtained entropy value. The lower 5 digits of the original value.

3: The specific method for implementing the entropy IP second plug-in module is as follows: This example embodiment does not need this module.

The implementation of the non-service-aware P-node of the method and apparatus (system) of transmitting and using the entropy value of the inner-layer message in the outer IP header is further described in detail with reference to FIG.

1: Implement the IP infrastructure module.

The basic IPv4 routing and the IPv4 forwarding function are implemented according to the related technologies. The IPv4 forwarding function includes an MC-LAG-based load balancing function, and the load balancing uses the received IP packet (corresponding to the second packet in the foregoing embodiment). Or the IP quintuple of the third packet is used as an entropy factor to perform a hash calculation 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 packet. However, if the source IP or the destination IP of the IP packet already contains the entropy of the inner packet, the entropy factor automatically includes the entropy of the inner packet, and the new entropy value is obtained. Includes the entropy of the inner message.

This module also does not need to call the entropy IP third plugin.

2: The specific method for implementing the entropy IP third plug-in module is as follows. This module does not exist at this node. Generally, such nodes are related nodes.

Taking the VPN topology shown in Figure 1 as an example, the network and service deployment process includes the following six steps.

In the first step, the PE node is selected as the PE1, PE2, and PE3 nodes, and the non-service aware node is selected as the P1 and P2 nodes, and the underlay network type is selected. The network and service deployment process sections in each of the exemplary embodiments of the present application use the nodes defined in the exemplary embodiment as the PE1, PE2, PE3, P1, and P2 nodes, and details are not described herein again. The underlay network type selected in this example embodiment is an IPv4 network.

The second step is to configure and publish the VPN Router ID of each PE node. Configure a loopback interface for each PE node, configure an IP address and a corresponding subnet mask for the loopback interface, and use the IP address of the loopback interface as the VPN router ID of the PE and use the VPN Router ID. The route prefix generated by the corresponding subnet mask is reachable in the underlay network (can be pinged); the VPN router ID and corresponding route prefix of each PE are different. In this example, the subnet mask of the loopback interface is a 27-bit subnet mask, and the value of the host identification part of the IP address of each loopback interface is 1.

In the third step, a normal VXLAN network as shown in FIG. 1 is established and each VXLAN tunnel is configured. Among them, there is only one bidirectional tunnel between the same pair of PE nodes. The VXLAN tunnel is configured to use the VPN router ID of the target PE node as the destination IP address of the VXLAN tunnel, and the VPN router ID is used as the source IP address of the VXLAN tunnel. It is worth noting that the VXLAN tunnel configured in this way takes the VXLAN tunnel between PE1 and PE3 as an example. On PE1, the source IP address of the tunnel is the VPN Router ID of PE1, and the destination IP address is the VPN Router ID of PE3. On PE3, the source IP address of the tunnel is the VPN Router ID of PE3, and the destination IP address is the VPN Router ID of PE1.

In the fourth step, a VXLAN service is established as shown in FIG. Each of the six interfaces, such as AC1, AC2, AC3, AC4, AC5, and AC6, is bound to the VXLAN service as an access circuit, and the VXLAN tunnels are bound to the VXLAN service.

In the fifth step, the access side loop is eliminated. The PEs receive the BUM packets received by the PE3 from the AC3 (equivalent to the first packet or the fourth packet in the foregoing embodiment). For example, PE3 will copy one copy of PE1 and PE2. When PE1 and PE2 send packets to CE1, one of the nodes can discard one of them. This is to deploy an MC-LAG on the physical interface to which AC1 and AC2 belong. The session is blocked by the physical interface of AC1 and AC2. After the MC-LAG is enabled, CE1 will not receive two BUM packets. The Layer 2 loop between CE1, PE1, and PE2 also disappears. In the same way, a multi-chassis-link Aggregation Group (MC-LAG) session is also deployed on the physical interfaces to which AC3 and AC4 belong. Without losing the generality, it is assumed that the two MC-LAG connections are blocked by the physical interface where AC1 is located and the physical port where AC5 is located.

In the sixth step, after the above steps, the VXLAN service is established, and the data packet can be used to verify the forwarding behavior and effect on the PE node and the non-service aware node defined in the exemplary embodiment.

Taking the VPN topology shown in Figure 1 as an example, the end-to-end packet forwarding process includes the following three steps.

The first step is when the PE1 node receives a Broadcast Unknown-unicast & Multicast (BUM) message B1 from the local AC1 (equivalent to the first packet or the fourth packet in the foregoing embodiment). The PE node forwards the B1 message according to the forwarding process defined in RFC7348, and respectively copies two copies B1b of the B1 message (corresponding to the second message or the third message in the foregoing embodiment) and B1c (equivalent to The second packet or the third packet in the foregoing embodiment is sent to the PE2 and the PE3, and the B1b and the B1c packets are added with a VXLAN encapsulation, and the VXLAN encapsulation is external to the B1 packet. The eigen-entropy value of the B1 message is included in the layer IP header, and the eigen-entropy value is an entropy value calculated by the feature field of the B1 text body.

The second step, without loss of generality, assumes that a non-service aware node P1 in the underlay network first receives the B1c message before the PE3 node receives the B1c message, because the P1 node does not To perceive the inner layer packet, it will still forward the B1c packet according to the destination IP address of the B1c packet, as in the case of forwarding the normal IP packet, without losing the generality. In this example, the P1 node is configured to press the B1c packet. The destination IP derived forwarding result is that the B1c message is forwarded from the link aggregation group (LAG) between the P1 node and the P2 node shown in FIG. Further, the P1 node calculates the load sharing entropy value according to the quintuple corresponding to the outermost IP header of the B1c packet, as in the case of forwarding the normal IP packet, but the outermost destination IP address of the B1c packet is The entropy of the B1 message has been included. Therefore, the entropy value of the B1c message calculated on the P1 node will automatically contain the entropy of the B1 message. In this way, the entropy value of the B1 message and the entropy value of the B1c message change when the feature field of the inner B1 packet takes a different value, so the load sharing process on the P1 node is given. The egress forwarding information finally selected by the B1c packet will also change, that is, the load sharing on the P1 node is more uniform, because before the PE1 implements this application, no matter how the B1 packet changes, the P1 junction The egress forwarding information obtained by clicking the B1c packet is the same. The balance of the load sharing on the P1 node is improved by the entropy of the inner B1 message added by the PE1 to the outer IP header of the B1c message.

In the third step, when the PE3 node receives the B1c packet, the VPN infrastructure module can perform performance statistics on the B1c packet, and the algorithm for performing performance statistics on the B1c packet is not included in the B1c packet. The entropy values are different and different performance statistics counters are used, because for the PE3 nodes, the entropy values used in the present exemplary embodiment are pseudo-random, which is meaningless.

It can be seen from the above second step that in the embodiment of the present application, no change is made to the P1 node, and the load sharing effect on the P1 node is improved. Also, this application does not use any MPLS technology.

Example embodiment 2

1: Implement the VPN infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 1, except where explicitly stated.

Different from the exemplary embodiment 1, the module sets the underlay network to be an IPv6 network. It is worth mentioning that this means that the source IP address and destination IP address of the VXLAN tunnel configured in this module are both IPv6 addresses.

Different from the exemplary embodiment 1, the plug-in mechanism of the module is further processed after receiving the third packet and performing link layer error detection processing and IP layer error detection processing on the third packet. Before the third packet, the entropy IP second plug-in module is called to modify the source IP and the destination IP in the IP encapsulation, and then the modified packet continues to be processed according to the processing flow in RFC7348.

2: The specific method of implementing the entropy IP first plug-in module is as follows.

Different from the first embodiment, the module uses the hash value of the interface name of the physical interface to which the ingress AC of the first packet belongs, as the 32-bit entropy value of the first packet.

Different from the exemplary embodiment 1, the source IP address and the destination IP of the VXLAN package used in this module are both IPv6 addresses and conform to the format defined in RFC7348 Section 5 Figure 2.

Different from the exemplary embodiment 1, the module uses the source IP field of the second packet as the entropy IP, and the entropy IP is the IP obtained by replacing the lower 32 bits of the source IP input by the VPN infrastructure module with the entropy value. address.

It should be noted that, in the embodiment of the present application, a certain field is used as the entropy IP, which refers to using the field as a carrier of the entropy of the first packet, by using the entropy value of the first packet to entropy. The IP is modified such that the entropy of the first packet is carried in the entropy IP.

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

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

The implementation of the non-service-aware P-node of the method and apparatus (system) of transmitting and using the entropy value of the inner layer message in the outer IP header is further described in detail with reference to FIG.

1: Implement the IP infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 1, except where specifically stated.

Different from the exemplary embodiment 1, the module is implemented as a software, and needs to implement a plug-in mechanism, which is set to call the entropy IP third plug-in module to obtain two IP address values, one of which is a source IP substitute value, and the other is a destination IP replacement. value. The plugin mechanism can be a function call, a callback function, a polymorphic function, or a standalone plugin.

Different from the first embodiment, the module performs link layer error detection processing and IP layer error detection processing on the third packet, and performs source other than load balancing and the third packet. When the IP or destination IP address is processed, the IP infrastructure is invoked to obtain the source IP substitute value and the destination IP substitute value of the third packet, and the source IP substitute value (or destination IP substitute value) is replaced by the source IP substitute value The source IP value (or destination IP value) of the third packet participates in the processing related to the source IP (or destination IP) address.

The processing related to the source IP address of the third packet, including the processing of the third text body, and the processing of other messages generated by the third packet triggering, for example, when the third newspaper When the TTL of the text is exhausted or the destination IP of the third packet is unreachable, the node may respond to the source IP address of the third packet with an ICMP message.

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

The main function of this module is to return the source IP substitute value and the destination IP substitute value according to the source IP and destination IP of the IP packet input by the IP infrastructure module. The algorithm for determining the source IP substitute value and the destination IP substitute value is as follows: if the source IP takes the entropy mask to 0, the source IP substitute value is the value of the source IP itself; if the destination IP takes the entropy mask If the value is 0, the destination IP substitute value is the value of the destination IP itself. If the source IP entropy mask is not 0, the source IP address and the source IP take the inverse of the entropy mask. a logical AND operation, and the lowest binary position of the obtained result is 1 as the source IP substitute value; if the destination IP entropy mask is not 0, the entropy mask is taken with the destination IP address and the destination IP The inverse of the code performs a bitwise logical AND operation, and the lowest binary position of the obtained result is 1 as the destination IP substitute value.

In this example, the source IP entropy mask and the destination IP entropy mask are both IPv6 address formats, and the source IP takes the entropy mask hexadecimal value as 0x0FFFFFFFF. The value of the destination IP entropy mask is 0.

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

It is worth noting that this module does not change the messages entered by the IP infrastructure.

Taking the VPN service shown in Figure 1 as an example, the processing steps of the network and service deployment process are as follows.

This step is the same as the corresponding step in the exemplary embodiment 1, except where specifically stated.

With the example embodiment 1, only the underlay network is an IPv6 network, and the loopback interface where each VPN router ID is located is configured with a 96-bit subnet mask, and the source IP address and the destination IP address of the VXLAN tunnel are both IPv6 addresses.

Taking the VPN topology shown in Figure 1 as an example, the processing steps of the end-to-end packet forwarding process are as follows.

This step is the same as the corresponding step in the exemplary embodiment 1. The phenomenon that the load balancing effect of the P1 node is improved in the present application is: when the B1 packet enters the EVPN instance from different ACs of the PE1, the corresponding B1c packet is finally obtained at the P1 node. The export forwarding information is also different. This phenomenon is completely because PE1 adds the context entropy of the B1 message to the outer IP of the B1c message, and the context entropy is obtained by hashing the interface name of the ingress AC of the B1 message.

Example embodiment 3

The implementation of the PE node of the method and apparatus (system) of transmitting and using the entropy value of the inner layer message in the outer IP header will be further described in detail below with reference to FIG.

1: Implement the VPN infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 2 except where explicitly stated.

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

Different from the exemplary embodiment 2, the module encapsulates the first packet into the second packet, and the encapsulation format is a Geneve encapsulation format, which is defined in the draft-ietf-nvo3-geneve; It defines how to convert a message from a VXLAN package to a Geneve package without changing the basic business effects. This partial conversion is a related technology. Whether to superimpose the functions unique to the Geneve package (relative to RFC7348) is a combination application of the Geneve technology and the present embodiment, and has nothing to do with the present exemplary embodiment itself. For the sake of simplicity, the present exemplary embodiment only considers the common capabilities of the Geneve package and the VXLAN package. The situation within the scope.

Different from the example embodiment 2, the module uses the result of the hash calculation of the destination MAC of the first packet as the 8-bit entropy value of the first packet.

Different from the exemplary embodiment 2, the module uses the source IP field of the first packet as the entropy IP, and the entropy IP is a bitwise logical difference between the entropy value and the lower 8 bits of the source IP input by the VPN infrastructure module. Or operate the resulting IP address.

This module is the same as the exemplary embodiment 2 except where specifically stated.

Different from the example embodiment 2, the position of the binary bit to be modified in the third packet determined by the module is the lower 8 bits of the source IP. Further, the module determines the modification of the binary bit of the location to restore it to its value prior to being modified by the entropy IP first plugin. Specifically, the restoring method is: first, recalculating the entropy value of the fourth packet carried by the IP header inner layer of the third packet by using an algorithm in the entropy IP first plug-in module, and then using The entropy value is subjected to a bitwise logical exclusive OR operation with the binary bits of the position.

It is worth noting that, because the VPN infrastructure itself is an implementation of the RFC7348 VXLAN, the RFC7348 is based on VXLAN data packets for learning the remote MAC entries. If the source IP is not subjected to entropy processing, the remote MAC Entries will frequently drift between different ciphertexts of the same source IP because the VPN infrastructure module does not know that these ciphertexts are the same IP address, it is treated as a different IP address; for the same reason, different source IP addresses are Encrypted ciphertexts may happen to be the same, and they are treated as the same IP address by the VPN infrastructure module, which can be problematic. In this embodiment, the source IP is restored, which is undoubtedly a decryption process, and is also used to remove the inner layer packet (corresponding to the first packet or the fourth packet in the foregoing embodiment) included in the source IP. Entropy.

1: Implement the IP infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 2 except where specifically stated.

Different from the example embodiment 2, the module adopts an IPv4 routing and forwarding technology, and forwards IPv4 packets.

Different from the example embodiment 2, in the module, the source IP entropy mask and the destination IP entropy mask are both IPv4 address formats, and the source IP takes an entropy mask, and its hexadecimal value is 0x0FF. The destination IP takes an entropy mask and has a value of 0.

As in the first embodiment, only the loopback interface where each VPN router ID is located is configured with a 24-bit subnet mask. At the same time, Geneve needs to be deployed in the network and applied to the EVPN instance.

Take the VPN topology shown in Figure 1 as an example. The processing steps of the end-to-end packet forwarding process are as follows:

This step is the same as the corresponding step in the exemplary embodiment 1.

Example embodiment 4

1: Implement the VPN infrastructure module.

Different from the example embodiment 2, the encapsulation format used by the module to encapsulate the first packet into the second packet is a VXLAN GPE encapsulation format, and the format is defined in draft-ietf-nvo3-vxlan-gpe. The draft defines how to convert messages from VXLAN encapsulation to VXLAN GPE encapsulation without changing the basic business effects. This part of the conversion belongs to the related technology. Whether the function unique to the VXLAN GPE package is superimposed (relative to RFC7348) is a combination of the VXLAN GPE technology and the present exemplary embodiment, and is independent of the present exemplary embodiment. For the sake of simplicity, the present exemplary embodiment only considers the VXLAN GPE package and the RFC7348 package. The situation within the scope of public competence.

Different from the example embodiment 2, when the Ethernet payload of the inner layer packet is an IPv6 packet, the module uses the quintuple <source IP, destination IP, protocol type, source port number, destination port number> and the flow of the IPv6 header. The 1abel field jointly performs the hash calculation as the 20-bit entropy value of the first message.

Different from the exemplary embodiment 2, the module uses the destination IP field of the second packet as the entropy IP, and the entropy IP is a bitwise logical difference between the entropy value and the lower 20 bits of the destination IP input by the VPN infrastructure module. Or operation, the result is stored in the lower 20 bits of the destination IP address.

It is worth noting that the bitwise logical XOR operation is actually a simple encryption algorithm.

Different from the example embodiment 2, the position of the binary bit to be modified in the third packet determined by the module is the lower 20 bits of the destination IP. Further, the module determines the modification of the binary bit of the location to restore it to its value prior to being modified by the entropy IP first plugin. Specifically, the restoring method is: first, recalculating the entropy value of the fourth packet carried by the IP header inner layer of the third packet by using an algorithm in the entropy IP first plug-in module, and then using The entropy value is subjected to a bitwise logical exclusive OR operation with the binary bits of the position, and the result is stored in the lower 20 bits of the destination IP of the third message.

1: Implement the IP infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 2.

Different from the example embodiment 2, in the module, the source IP entropy mask and the destination IP entropy mask are both IPv6 address formats, and the source IP takes an entropy mask, and its hexadecimal value is 0. The destination IP takes an entropy mask, and its hexadecimal value is 0x0FFFFF.

In the same manner as the second embodiment, only the loopback interface of each VPN router ID is configured with a 108-bit subnet mask. At the same time, VXLAN GPE needs to be deployed in the network and applied to the EVPN instance.

This step is the same as the corresponding step in the exemplary embodiment 2.

Example embodiment 5

1: The specific method of implementing the VPN infrastructure module is as follows.

Different from the example embodiment 2, the module generates an IP address, which is called a VNI IP address, by using the VPN router ID and the VNI configured on the EVPN instance, and the VNI IP address is 104 as the high 104 of the VPN Router ID. The VNI is the lower 24 bits; wherein the VNI is not equal to the lower 24 bits of the VPN Router ID.

Different from the example embodiment 2, the template encapsulates the first packet into the second packet with the NVGRE (Network Virtualization Using Generic Routing Encapsulation) format, which is defined in RFC7637, draft-ietf -bess-evpn-overlay defines how to convert a message from a VXLAN package to an NVGRE package without changing the basic business effects. This part of the conversion belongs to the related technology. Whether the function of the NVGRE package is superimposed (relative to RFC7348) belongs to the combination of the NVGRE technology and the present exemplary embodiment, and is independent of the present exemplary embodiment. For the sake of simplicity, the present exemplary embodiment only considers the common capability of the NVGRE package and the RFC7348 package. The situation within the scope.

Different from the example embodiment 2, the module replaces the outermost destination IP address 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 address include the EVPN instance. The VNI is the context entropy value of the first packet, which is carried by the second packet.

Different from the exemplary embodiment 2, the module returns the message input by the VPN infrastructure module to the VPN infrastructure module intact.

It is worth mentioning that the lower 24 bits of the destination IP, although containing the context entropy value of the inner message, do not need to be cleared because the value is indeed the VXLAN through which the third message passes. The IP address of an interface (specifically, an EVPN instance interface) on the source node of the tunnel (that is, the first PE) corresponds to an IP address, and the destination IP address is indeed IP reachable. The IP address of the entropy value does not meet this condition.

1: Implement the IP infrastructure module.

Different from the exemplary embodiment 1, the module uses IPv6 routing and forwarding technology to process IPv6 packets.

As in the example embodiment 1, this module is not required for this node.

This step is the same as the corresponding step in the exemplary embodiment 2 except where specifically stated.

As in the second embodiment, only the 104-bit subnet mask is configured on the loopback interface where each VPN router ID is located.

This step is the same as the corresponding step in the exemplary embodiment 2.

Example embodiment 6

This module is the same as the module of the same name in the exemplary embodiment 5 except where specifically stated.

Different from the example embodiment 5, the EVPN instance of the module also corresponds to a virtual interface of the same name, which is called an EVPN instance interface. The EVPN instance interface has all the functions of the related loopback interface. It is worth mentioning that this means that the IP address of the EVPN instance interface is added to the routing table as a local host route, and the IP address mask configured on the EVPN instance interface is added to the route as a local direct route prefix. In the table, and from the local host route and the route entry corresponding to the local direct route prefix, it is known that it is a route generated according to which interface (must be an EVPN instance interface).

Different from the example embodiment 5, the VNI configured on the EVPN instance of the module is only regarded as a value identifying the EVPN instance, and does not have the role of the VNI in the RFC 7348. Instead, the method described in the exemplary embodiment 5 is directly adopted. The VNI IP is configured on the EVPN instance interface as the IP address of the corresponding EVPN instance interface.

Different from the example embodiment 5, each VXLAN tunnel in the present exemplary embodiment is dedicated to one service, and each service deploys one VXLAN tunnel for each remote node in the service; specifically, each of the exemplary embodiments The source IP address of the VXLAN tunnel is the IP address of the EVPN instance interface corresponding to the EVPN instance to which the VXLAN tunnel belongs. The destination IP address is the IP address of the EVPN instance interface corresponding to the EVPN instance to which the VXLAN tunnel belongs.

The module used to encapsulate the first packet into the second packet has the same UDP header and VXLAN header as the VXLAN package used in the exemplary embodiment 5, and thus has the same function as the End.DX2 type Function in SRv6. Format; this encapsulation format is referred to herein as a Type A extended SRv6 package, as shown in Figure 14, format B in Figure 15, where Figure 15 is the expansion of Figure 14, including source IP to Ethernet layer payload data. A detailed comparison of the fields between the fields and related fields in the VXLAN package.

Correspondingly, when the third packet is received by the module, if the destination IP address of the third packet is a local direct route, and the route is generated by an EVPN instance interface, the third packet is considered to be a type A extension. The SRv6 is encapsulated, and the third packet is forwarded in the EVPN instance corresponding to the EVPN instance interface. When forwarding, except for the encapsulation decapsulation, each field in the format B in Fig. 15 has the same effect as the field of the same name in the format A in Fig. 15 unless otherwise specified.

Different from the example embodiment 5, the module maps the sub-interface VLAN information on the ingress AC to the 24-bit entropy value of the fourth packet by: the upper 12 bits of the entropy value are taken outside the configuration on the ingress AC. Layer ID, the lower 12 bits take the inner VLAN ID configured on the ingress AC. When the inner VLAN ID does not exist, the lower 12 bits take 0x3FF, and the outer VLAN ID does not exist. When the high 12 bits take 0x3FF.

Different from the exemplary embodiment 5, the module uses the source IP field of the second packet as the entropy IP, and the entropy IP is obtained by replacing the lower 24 bits of the source IP that will be obtained by the RFC7348 process by using the 24-bit entropy value. IP address.

It is worth noting that the module does not modify the destination IP field of the packet input by the VPN infrastructure module. However, the field itself already contains the EVPN service information to which the packet belongs. The DIP is automatically compared with the example embodiment 5. Has more entropy.

It should be noted that the module does not modify the upper 104 bits of the source IP field of the second packet. Therefore, the upper 104 bits of the destination IP learned by the MAC learning process are not different from the related technologies. The upper 104 bits can match the second packet to the destination PE node to the associated EVPN instance.

This module is the same as the exemplary embodiment 5 except where it is specifically described.

Different from the exemplary embodiment 5, the module returns the message input by the VPN infrastructure module to the VPN infrastructure module intact.

It is worth noting that, because the source IP address of the packet input by the VPN infrastructure module includes the VLAN ID information corresponding to an AC at the remote end, the information is used for performance statistics, so that the packets from different remote ACs can be obtained. The text is counted on different counters, making performance statistics more accurate.

1: Implement the IP infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 5.

In the same manner as the example embodiment 5, except that: each EVPN instance corresponds to an EVPN instance interface, and the interface is configured with an IPv6 address and a 104-bit IPv6 address mask, and a 104-bit IPv6 route prefix generated by any two EVPN instance interfaces. None of them match. The source IP address and destination IP address of each VXLAN tunnel are the IP addresses of an EVPN instance interface. In addition, the requirements of the exemplary embodiment 5 must be met.

It is worth noting that each EVPN instance has only one corresponding EVPN instance interface, and each EVPN instance interface has only one corresponding EVPN instance.

This step is the same as the corresponding step in the exemplary embodiment 5.

In the example embodiment 6, whether the lower 24 bits of the IPv6 address configured for the EVPN instance interface are equal to the VNI value of the corresponding EVPN instance does not affect the role of the IPv6 address, because whether or not there is such a relationship The IPv6 address has a one-to-one correspondence with the EVPN instance. The manner in which the description is taken in the example embodiment 6 is only to make the one-to-one correspondence more intuitive and obvious, and does not constitute an improper limitation of the exemplary embodiment.

Example embodiment 7

1: Implement the VPN infrastructure module.

The VXLAN EVPN service is implemented by draft-ietf-bess-evpn-overlay ([EVPN overlay]), and the control plane module of the obtained VXLAN EVPN service is the control plane part of the VPN infrastructure module.

Similarly, if the VXLAN EVPN service is implemented by [EVPN overlay], the forwarding plane module of the obtained 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 the MP-BGP protocol L2VPN EVPN address family configuration, the configuration of the EVPN instance, the binding configuration of the AC and the EVPN instance, and the ESI related configuration. The EVPN instance is identified by the VNI and the VNI is configured by the user.

It is worth mentioning that the VXLAN tunnel and its binding relationship with the EVPN instance are dynamically generated by the MP-BGP session according to the [EVPN Overlay] protocol.

The requirements of the plug-in mechanism of this module are the same as those of the exemplary embodiment 1.

The configuration requirements and functional requirements of the IP address of the VPN Router ID and the loopback interface and their subnet masks are the same as those in the first embodiment.

This module is the same as that of the exemplary embodiment 3 except where it is specifically described.

Different from the example embodiment 3, the module performs hash calculation based on the source MAC address, the VLAN ID, the 802.1p priority, and the ethertype corresponding to the payload, to obtain the 5-bit eigen-entropy of the first packet. Value, then, the module performs hash calculation based on the interface name of the primary interface to which the ingress AC of the first packet belongs, and obtains a 5-bit context entropy value, and performs a bitwise logical exclusive OR operation with the prime number 29 Performing a bitwise logical exclusive OR operation to obtain a 5-bit integrated entropy value, and then performing a bitwise logical difference between the lower 5 bits of the destination IP of the second packet input by the VPN infrastructure module and the integrated entropy value Or operation, the result is stored in the former.

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 the module is the lower 5 bits of the destination IP.

The implementation of the non-service-aware P-node of the method and apparatus (system) of transmitting and using the entropy value of the inner layer message in the outer IP header is described in further detail with reference to FIG.

1: Implement the IP infrastructure module.

This module is the same as the module of the same name in the exemplary embodiment 3.

This module is the same as the module of the same name in the exemplary embodiment 3 except where specifically stated.

Different from the example embodiment 3, in the module, the source IP entropy mask and the destination IP entropy mask are both IPv6 address formats, and the source IP takes an entropy mask, and the hexadecimal value thereof is 0. The destination IP takes an entropy mask, and its hexadecimal value is 0x01F.

Taking the EVPN topology shown in Figure 2 as an example, the network and service deployment process includes the following six steps.

The first step is the same as the corresponding step in the exemplary embodiment 1, except that the underlay network is IPv4.

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

In the third step, the VXLAN EVPN network shown in Figure 1 is established. The configuration of the Multi-Protocol Border Gateway Protocol (MP-BGP) session is configured between the PE1, the PE2, and the PE3, and the related configuration of the L2VPN EVPN address family is enabled. For the sake of simplicity, by adjusting the configuration of the Border Gateway Protocol (BGP), EVPN RT-3 routing can dynamically generate all VXLAN tunnels required by the service. For the sake of simplicity, the VXLAN tunnel generated by the RT-3 route can be adjusted to meet the following rules by simply adjusting the BGP configuration: only one bidirectional VXLAN tunnel is generated between any two PE nodes; any bidirectional VXLAN tunnel Both ends of the tunnel use the VPN router ID of the node as the source IP address of the VXLAN tunnel, and the tunnel source IP address of one end of the same bidirectional VXLAN tunnel is exactly the tunnel destination IP address of the other end. The IP is exactly the tunnel source IP at the other end. Similarly, by adjusting the BGP configuration, the RT-3 route can also generate all the binding relationships between all the VXLAN tunnels and the EVPN instance; these are all related technologies, and those skilled in the art should be able to understand the specific methods involved.

In the fourth step, a VXLAN EVPN service is established as shown in Figure 1, and the same VNI is assigned to the VXLAN EVPN service at each PE node. The six interfaces, such as AC1, AC2, AC3, AC4, AC5, and AC6, are bound to the VXLAN EVPN service as access circuits. After the above configuration is completed, the MP-BGP session starts to exchange the RT-3 route according to the signaling process defined by [EVPN Overlay], so that the VXLAN tunnel between the nodes is established and bound to the VXLAN EVPN service.

In the fifth step, the access side loop is eliminated. The physical interface that CE1 accesses to PE1 and PE2 is mapped to the same ESI (referred to as ESI1) and ESI1 related configuration, thereby triggering the MP-BGP session to perform DF negotiation according to the RT-4 route described in [EVPN Overlay]. And RT-1 routing is released. Similarly, the physical interface that CE2 accesses to PE1 and PE2 is also mapped to the same ESI (denoted as ESI2) and the ESI2-related configuration. Without loss of generality, the present example embodiment assumes that the result of the DF negotiation is that AC1 and AC5 are interfaces of the non-DF roles of ESI1 and ESI2, respectively, in the service. Since the PE node of the present exemplary embodiment implements the [EVPN Overlay] protocol, after configuring the ESI related configuration and completing the relevant signaling process, the two ESI related loops are also released.

In the sixth step, after the above steps, the VXLAN EVPN service is established, and the data packet can be used to verify the forwarding behavior and effect on the PE node and the non-service aware node defined in the exemplary embodiment.

The EVPN topology shown in Figure 2 is used as an example. The end-to-end packet forwarding process includes the following three steps.

The first step is the same as that of the exemplary embodiment 1, except that the forwarding plane flow is executed by [EVPN Overlay].

The second step is the same as that of the exemplary embodiment 1, except that the forwarding plane flow is executed by [EVPN Overlay].

The third step is the same as that of the exemplary embodiment 1, except that the forwarding plane flow is executed by [EVPN Overlay].

In the third step of the end-to-end message forwarding process, it has been proved that the application does not make any changes to the P1 node, thereby improving the load sharing effect on the P1 node. Also, this application does not use any MPLS technology.

Example embodiment 8

1: Implement the VPN infrastructure module.

This module is the same as the exemplary embodiment 7, except where specifically stated.

Different from the exemplary embodiment 7, the module sets the underlay network to be an IPv6 network.

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

This module is the same as the exemplary embodiment 4 except where specifically stated.

Different from the example embodiment 4, the module performs a hash calculation based on the ESI (10 bytes) corresponding to the primary interface to which the ingress AC of the first packet belongs, as the entropy value of the first packet. The module uses the source IP field of the second packet as the entropy IP, and the lower 32 bits of the source IP perform a bitwise logical exclusive OR operation with the entropy value, and the obtained result is stored in the former.

Different from the exemplary 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 the module is the lower 32 bits of the source IP.

1: Implement the IP infrastructure module.

It should be noted that although the lower 32 bits of the source IP of the third packet are ciphertexts encrypted by the entropy value and the node cannot decrypt the same, the source IP is the first PE. The IP address of a loopback interface, and the loopback interface is configured with a 96-bit mask. Therefore, regardless of the value of the ciphertext part of the source IP, it is a reachable IP address, therefore, It cannot be de-entropy-processed, and it does not affect forwarding.

Taking the VPN service shown in Figure 2 as an example, the processing steps of the network and service deployment process are as follows.

This step is the same as the corresponding step in the exemplary embodiment 7, except where specifically stated.

Different from the example embodiment 7, the underlay network of the example is an IPv6 network, and the loopback interface of each VPN router ID is configured with a 96-bit subnet mask, and the source IP address and the destination IP address of the VXLAN tunnel are both IPv6 addresses.

Taking the VPN topology shown in Figure 2 as an example, the processing steps of the end-to-end packet forwarding process are as follows.

This step is the same as the corresponding step in the exemplary embodiment 7.

Example embodiment 9

1: Implement the VPN infrastructure module.

The VXLAN EVPN service is implemented by [EVPN overlay] and draft-ietf-bess-evpn-prefix-advertisement ([EVPN prefix]), and the control plane module of the obtained VXLAN EVPN service is the control plane part of the VPN infrastructure module.

Similarly, if the VXLAN EVPN service is implemented by [EVPN overlay] and [EVPN prefix], the forwarding plane module of the obtained 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 the configuration of the BGP L2VPN EVPN address family, the configuration of the IP-VRF instance, and the binding configuration of the AC and the IP-VRF instance. The VRF instance is identified by the VNI and the VNI is from the user configuration. The VXLAN tunnel uses the VPN Router ID of the node as the source IP at the source node and the VPN Router ID of the destination node as the destination IP address. The VPN Router ID is an IP address of a loopback interface. For the sake of simplicity, without loss of generality, this module sets a node with only one VPN Router ID.

It is worth mentioning that, for the sake of simplicity, in the case of the patent without loss of generality, this module only needs to implement the function corresponding to the interface-less model of IP-VRF to IP-VRF, therefore, in this module The AC interface of the IP-VRF is still a normal 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 the required VXLAN tunnels. Without loss of generality, for simplicity, the VXLAN tunnel generated by RT-5 routing can be adjusted by the following rules: Only one bidirectional VXLAN tunnel is generated between any two PE nodes; any bidirectional VXLAN tunnel Both ends of the tunnel use the VPN router ID of the node as the source IP address of the VXLAN tunnel, and the tunnel source IP address of one end of the same bidirectional VXLAN tunnel is exactly the tunnel destination IP address of the other end. The IP is exactly the tunnel source IP at the other end. Similarly, by adjusting the BGP configuration, the RT-5 route can also generate all the binding relationships between all the VXLAN tunnels and the EVPN instance; these are all related technologies, and those skilled in the art should be able to understand the specific methods involved.

As a software implementation, this module needs to implement a plug-in mechanism. When the module forwards according to the [EVPN prefix] process, the IP encapsulation from the first packet to the second packet is completed, and the plug-in is invoked in the IP encapsulation. The source IP and destination IP are modified. The plugin can be a function call, a callback function, a polymorphic function, or a standalone plugin.

Except for the plug-in mechanism, this module has the same forwarding process as the forwarding module corresponding to [EVPN prefix].

In addition, the IP address of the VPN Router ID must be a loopback interface address, and the loopback interface address is configured with a 96-bit mask, so a 96-bit route is formed, and a 96-bit route prefix is issued in the underlay network; When the node receives a packet whose destination IP matches the 96-bit route, it considers that the packet is the same as the packet whose destination IP is the loopback interface.

In addition, without loss of generality, in the present exemplary embodiment, the underlay network is set to be an IPv6 network. Therefore, the source IP address and the destination IP address of the VXLAN tunnel are both IPv6 addresses.

This module is the same as the exemplary embodiment 8 except where it is specifically described.

Different from the exemplary embodiment 8, the module uses the hash value obtained by hashing based on the IP quintuple field of the first message and the ToS field in the Ipv4 header as the final 32-bit entropy value.

The module returns the message input by the VPN infrastructure module to the VPN infrastructure module intact.

1: Implement the IP infrastructure module.

Taking the EVPN topology shown in Figure 3 as an example, the network and service deployment process includes the following six steps.

The first step is the same as that of the exemplary embodiment 7, except that the underlay network type selected in the present exemplary embodiment is an IPv6 network.

The second step is the same as the example 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 exemplary embodiment 7, except that the route that generates the VXLAN tunnel and binds the generated VXLAN tunnel to the EVPN instance is an RT-5 route instead of an RT-3 route.

In the fourth step, a VXLAN L3 EVPN service is established as shown in Figure 1, and the same VNI is assigned to the VXLAN L3 EVPN service at each PE node. The three interfaces, AC1, AC2, and AC3, are bound to the VXLAN L3 EVPN service as access circuits. After the above configuration is completed, the MP-BGP session starts to exchange the RT-5 route according to the signaling process defined by [EVPN Prefix], so that the VXLAN tunnel between the nodes is established and bound to the VXLAN L3 EVPN service.

Step 5: Configure the IP address of the AC interface. Configure an IP address for each AC. This IP address is in the same subnet as the IP address of the corresponding CE and is different from the IP address of the corresponding CE. For the sake of simplicity, the example embodiment sets each CE as an IPv4 host. Therefore, the EVPN prefix in the RT-5 route advertised by the MP-BGP session is an IPv4 prefix, but the source of the VXLAN tunnel generated by the RT-5 route. Both the IP and destination IP addresses are IPv6 addresses.

In the sixth step, after the above steps, the VXLAN L3 EVPN service is established, and the data packet can be used to verify the forwarding behavior and effect on the PE node and the non-service aware node defined in the exemplary embodiment.

The EVPN topology shown in Figure 3 is used as an example. The end-to-end packet forwarding process includes the following three steps.

In the first step, when the PE1 node receives an IPv4 packet B1 from the local AC1, the PE node forwards the B1 packet according to the forwarding process defined by the [EVPN prefix] without loss of generality, assuming that the packet is based on the B1 packet. The destination IP address should be forwarded to PE3. B1 is packaged as B1c and forwarded to PE3.

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

The third step is the same as that of the exemplary embodiment 1, except that the forwarding plane flow is executed by [EVPN prefix].

Example embodiment 10

1: Implement the VPN infrastructure module.

This module is the same as the example embodiment 6 except where it is specifically described.

Different from the exemplary embodiment 6, the encapsulation format used by the module is compared with the encapsulation format used by the module, and the SRH header is added. The position of the SRH header is shown in the format C in FIG. 17, and the format B in the figure is used in the exemplary embodiment 6. format. The SRH header is a segmentation routing header defined by the IETF in the draft-ietf-6man-segment-routing-header ([SRH]), and the format of the SRH header is defined in [SRH], including the Flags field and the Segment. List field.

Different from the example embodiment 6, the module directly uses the ESI (10 bytes) corresponding to the primary interface to which the entry AC of the first packet belongs, as the lower 10 bytes of the 16-byte entropy value, and the first report. The 6-byte hash value generated by the source MAC address, destination MAC address, Ehertype, and VLAN ID is the upper 6 bytes of the 16-byte entropy value.

Different from the exemplary embodiment 6, the encapsulation format used by the module is compared with the encapsulation format used by the module, and the SRH header is added. The position of the SRH header is shown in the format C in FIG. 17, and the format B in the figure is used in the exemplary embodiment 6. format. The SRH header is a segmentation routing header defined by the IETF in the draft-ietf-6man-segment-routing-header ([SRH]), and the format of the SRH header is defined in [SRH], including flags (Flags). Field and Segment List fields. The value of the Flags field in the SRH added by the module satisfies the following condition: the result of the bitwise logical AND operation with the predetermined constant TBD1 is not 0, where TBD1 is defined by the IETF, and the possible value of TBD1 is 1. 2, 4 and 128, etc. The Segment List field is an IPv6 address array. The array in the SRH header added by this module has only one element, that is, Segment List[0]. The value of the Segment List[0] in the SRH header added by this 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, and strips the SRH header, and copies the value of the next header field in the SRH header to In the IPv6 header, another packet is obtained and returned to the VPN infrastructure module for processing. The lower 10 bytes of the entropy value is the entry AC of the fourth packet carried by the third packet. The corresponding ESI can be used for packet statistics, and the statistics of the packets from different remote ESIs are recorded in different counters, thereby improving the accuracy of packet statistics.

If the result of the logical AND operation of the Flags field of the SRH header and the predetermined constant TBD1 is 0, no processing is performed on the message, and the processing is directly performed to the VPN infrastructure module.

It is worth mentioning that the destination IP of the third packet is actually a local segment identifier (SID) on the PE node configuring the destination IP, and the local SID concept is draft-filsfils- The local SID concept described in section 4 of spring-srv6-network-programming-01([srv6-program]). This module actually defines a new type of SRv6 Function corresponding to the local SID, which is the SRv6 Fucntion concept described in [srv6-program] Section 4. The new SRv6 Function indicates that the Segment List[0] field in the SRH header is different from the destination IP, and the Segment List[0] field is an IP address that is not routable in the underlay network, and cannot be like other SRv6 Functions. The destination IP field of the third packet is covered by a Segment List[0] field. The present example may be used in conjunction with the SR-Policy function of the SRv6. In this case, according to the packet encapsulation specification of the SR-Policy, the destination IP of the third packet is not the destination PE node at the beginning (ie, the module). The local SID on the execution entity, but the destination IP of the third packet is modified in the SRv6 forwarding process through each non-service aware node or destination PE node, and finally the destination PE node The point becomes the local SID, and the third message is processed according to the rules of the new SRv6 Fuction.

1: Implement the IP infrastructure module.

Different from the example embodiment 2, in the process of forwarding the IP packet whose destination IP is not the local interface IP, the module calls the SRH header if the IPv6 header is included in the load balancing path selection. The entropy IP third plug-in module obtains the entropy value, and performs load balancing with source IP, destination IP, and the entropy value.

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

If the result of the bitwise logical AND operation between the Flags field in the SRH header and the undetermined constant TBD1 is not 0, the SRH header is considered to contain an entropy value, and the entropy value is from the SRH header. Read, no set to consider the entropy value is 0. The method for reading the entropy value corresponding to the VPN infrastructure module in the exemplary embodiment is: reading a value of a Segment List[0] in the SRH header as the entropy value.

This step is the same as the corresponding step in the exemplary embodiment 6, except where specifically stated.

Unlike the example embodiment 6, the subnet mask of the first EVPN instance interface configuration is 128 bits.

This step is the same as the corresponding step in the exemplary embodiment 6.

Example embodiment 11

1: Implement the VPN infrastructure module.

The VXLAN encapsulated EVPN VPWS service is implemented according to RFC8214 and [EVPN overlay], and the control plane module of the obtained EVPN VPWS service is the control plane part of the VPN infrastructure module. The [EVPN overlay] mainly provides guidance for the format of the packet, and the service processing procedure complies with RFC8214.

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

It is worth mentioning that the EVPN VPWS control plane module obtained by the above method includes the configuration of the BGP L2VPN EVPN address family, the configuration of the EVI instance corresponding to the EVPN VPWS, and the configuration of each VPWS service instance in the EVI instance. The binding configuration of the AC and the VPWS service instance, the ESI related configuration, and the VPN Router ID configuration. The VPN Router ID is an IP address of a loopback interface. For the sake of simplicity, without loss of generality, this module sets a node with only one VPN Router ID. The control plane part of the module obtained by the above method also establishes a forwarding entry of each VPWS service instance in each of the EVI instances with the participation of BGP routes.

In particular, it is not necessary to statically configure the VXLAN tunnel in the control plane part of the module obtained by the above method. By adjusting the BGP configuration, the RT-1 route can dynamically generate all required VXLAN tunnels. Without loss of generality, for simplicity, the VXLAN tunnel generated by RT-1 routing can be adjusted by the following rules: Only one bidirectional VXLAN tunnel is generated between any two PE nodes; any bidirectional VXLAN tunnel Both ends of the tunnel use the VPN router ID of the node as the source IP address of the VXLAN tunnel, and the tunnel source IP address of one end of the same bidirectional VXLAN tunnel is exactly the tunnel destination IP address of the other end. The IP is exactly the tunnel source IP at the other end. Similarly, by adjusting the BGP configuration, the RT-1 route can also generate all the binding relationships between all the VXLAN tunnels and the EVI instance; these are all related technologies, and those skilled in the art should be able to understand the specific method.

It is particularly worth mentioning that, in the forwarding plane part of the module obtained by the above method, the first packet is only used to determine the local AC that receives the packet, and after determining the local AC, the first packet The fields in the text are no longer applied to the selection of message forwarding information.

As a software implementation, the module needs to implement a plug-in mechanism, and set the entropy IP first after the IP encapsulation of the first packet to the second packet is completed when the module forwards according to the EVPN VPWS service forwarding process. The plug-in modifies the source IP and the destination IP in the IP encapsulation, and, when receiving the third packet and processing the third packet, invokes the entropy IP second plug-in to source IP and destination in the IP encapsulation IP is modified. The plugin can be a function call, a callback function, a polymorphic function, or a standalone plugin.

Except for the plug-in mechanism, this module has the same forwarding process as the corresponding forwarding module in RFC8214 and [EVPN overlay].

This module is the same as the exemplary embodiment 10 except where specifically stated.

Different from the exemplary embodiment 10, the module is based on the lower 16 bits of the Local Discriminator value field in the Type 4 or Category 5 ESI corresponding to the primary interface to which the entry AC of the first message belongs. The lower 16 bits of the entropy value use the lower 16 bits of the source MAC of the first message as the upper 16 bits of the entropy value.

Different from the exemplary embodiment 10, the module does not insert the SRH header at the position where the third message is inserted into the SRH header, but inserts a new IPv6 routing option header, which is called an entropy route header. , ERH) header, and, in order to quickly eliminate the case of the IPv6 option header without entropy, reduce the processing burden on the IPv6 option header of the non-service-aware node, define a predetermined constant TBD2, when the next header in the IPv6 header When the value of the field is the predetermined regular TBD2, it indicates that the next header is a routing header, and the routing header may contain an entropy value. The value of the TBD2 is determined by the IETF. One possible format of the ERH header is shown in FIG. 16; wherein an Entropy Value field is used to carry the entropy value. The router type (Route-type) field of the ERH header takes a value of a predetermined constant TBD3, and the value of the TBD3 is determined by an IETF. The Reserved2 field in the ERH header takes a value of 0xFF, Reserved3, Reserved4, and Reserved5 fields. The value of the Next Header and the Header Extension Length (Hdr Ext Len) field is filled in according to the field definition of the routing header in RFC2460.

It is worth noting that the access circuit (AC) of the EVPN VPWS service is not limited to the Ethernet type interface. When the access circuit (AC) is a Frame Relay (FR) data link connection identifier (Data) When the Link Connection Identifier (DLCI) identifies the access circuit, or the access circuit (AC) is an Asynchronous Transfer Mode (ATM), a Virtual Path Identifier (VPI) or a virtual channel identifier ( The DLCI, VPI, or VCI may also be used to calculate an eigen-entropy value of the first packet when the access channel is identified by the Virtual Channel Identifier (VCI). How to configure such an EVPN VPWS service is not an innovation of the present application. Therefore, it is not exemplified in this specification. It should be clear to those skilled in the art how to extend the use of entropy values to non-Ether types according to the present exemplary embodiment. EVPN VPWS business.

Directly stripping the ERH header of the third packet, and copying the value of the next header field in the ERH header to the IPv6 header to obtain another packet; and returning the obtained packet to the VPN infrastructure. Module.

1: Implement the IP infrastructure module.

Different from the example embodiment 2, in the process of forwarding the IP packet whose destination IP is not the local interface IP, the module performs the load balancing path selection if the value of the next header field in the IPv6 header is Referring to TBD2, the first IPv6 option header is considered to be a routing header, and may include an entropy value, so the entropy IP third plugin is called to obtain the inner entropy value, if the value of the next header field in the IPv6 header is Instead of the TBD2, the Entropy IP third plug-in module is not called to obtain the entropy value.

Different from the example embodiment 2, in the case that the entropy value is successfully obtained according to the above method, the load balancing is performed by the source IP, the destination IP, and the entropy value in the module, and if the entropy value is not obtained according to the above method, Load balancing with 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, and the value of the Entropy Value field is the entropy value. If the value of the Route-type field in the first routing header of the third packet is not equal to the predetermined constant TBD3, the inner entropy value of the third packet is considered to be zero.

Taking the EVPN VPWS topology shown in Figure 4 as an example, the network and service deployment process includes the following six steps.

The second step is the same as the example 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 exemplary embodiment 7, except that the route that generates the VXLAN tunnel and binds the generated VXLAN tunnel to the EVPN instance is an RT-1 route instead of an RT-3 route.

In the fourth step, an EVPN VPWS service is established as shown in FIG. 4, and the same VNI is specified for the EVPN VPWS service at each PE node. The three interfaces, AC1, AC2, and AC3, are bound to the EVPN VPWS service as access circuits. After the above configuration is completed, the MP-BGP session starts to interact with the RT-1 route according to the signaling procedure defined in RFC8214, so that the VXLAN tunnel between the nodes is established and bound to the EVPN VPWS service.

The fifth step is to configure ESI. The same as the exemplary embodiment 7, except that the signaling flow is the flow in RFC8214.

In the sixth step, after the above steps, the EVPN VPWS service is established, and the data packet can be used to verify the forwarding behavior and effect on the PE node and the non-service aware node defined in the exemplary embodiment.

Taking the EVPN VPWS topology shown in Figure 4 as an example, the end-to-end packet forwarding process includes the following three steps.

In the first step, when the PE1 node receives an IPv4 packet B1 from the local AC1, the PE node forwards the B1 packet according to the forwarding procedure defined in RFC8214, without loss of generality, assuming that the packet is based on the B1 packet. The EVPN instance should forward it to PE3. PE1 then encapsulates B1 as B1c and forwards it to PE3.

The second step is the same as the corresponding step in the exemplary embodiment 1, except that B1 is an Ethernet message and the feature field is the source MAC of the B1 message.

The third step is the same as in the exemplary embodiment 1, except that the forwarding plane flow is performed in accordance with RFC 8124.

Example embodiment 12

1: Implement the VPN infrastructure module.

Different from the exemplary embodiment 8, each ESI in the module has a corresponding interface with the same name, called an ESI interface, and the IP address of the interface has the full function of the loopback interface address.

Different from the exemplary embodiment 8, the module directly adopts the whole ESI IP corresponding to the primary interface to which the ingress AC of the first packet belongs, as a 128-bit entropy value. The ESI IP is an IP address configured on an ESI interface corresponding to the ESI corresponding to the primary interface to which the ingress AC belongs;

Unlike the exemplary embodiment 8, the module fills in the ESI IP as the entropy value using all 128 bits of the source IP.

The module directly returns the third message to the VPN infrastructure module for processing.

It is noted that the entropy value of the source IP bearer of the third packet is a complete body of the ESI IP corresponding to the primary interface to which the local AC of the fourth packet belongs, and the ESI IP is in the underlay. The network is reachable. Therefore, although it has the full effect of entropy, it also has the complete function of an IP address. Therefore, there is no need to regard ESI IP as zero here. However, the general entropy value often has pseudo-randomness and does not have a complete IP address. Therefore, it is better for non-traffic-aware nodes to treat such pseudo-random entropy values as zero.

1: Implement the IP infrastructure module.

This step is the same as the corresponding step in the exemplary embodiment 8, except where specifically stated.

Different from the example embodiment 8, the loopback interface of each VPN router ID in this example embodiment is configured with a 128-bit subnet mask.

Take the VPN topology shown in Figure 2 as an example. The processing steps of the end-to-end packet forwarding process are as follows:

This step is the same as the corresponding step in the exemplary embodiment 8.

Those skilled in the art will appreciate that the various modules or steps of the present application described above can be implemented in a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. They may be implemented in program code executable by a computing device, such that they may be stored in a storage device for execution by a computing device, and in some instances, illustrated or described in a different order than those illustrated herein. The steps are either made into individual integrated circuit modules, or a plurality of modules or steps are made into a single integrated circuit module. Thus, the application is not limited to any particular combination of hardware and software.

Claims

A method for sending a message, including:

Receiving the first packet from the access circuit AC;

Processing the first packet to obtain at least one second packet, where the second packet includes: a first Internet Protocol IP address; the first IP address is a second using a predetermined entropy value The IP address obtained by modifying the IP address; wherein the predetermined entropy value is used to identify an entropy of the first packet;

Sending the second message.
The method of claim 1, wherein the first IP address is located in at least one of the following locations of the second message: source IP, destination IP, and Internet Protocol version 6 IPv6 option header.
The method of claim 1 wherein modifying the second IP address using the predetermined entropy value comprises at least one of:

And replacing, by the predetermined entropy value, a value of a specified position in the second IP address, wherein the predetermined entropy value is one of: an eigen entropy value, a context entropy value, and a comprehensive entropy value;

And replacing, by the result of the predetermined entropy value and the value of the specified location in the second IP address, a value of the specified location in the second IP address, wherein the predetermined entropy value is one of: Intrinsic entropy value, context entropy value and comprehensive entropy value;

Encrypting a value of a specified position in the second IP address by using the predetermined entropy value, wherein the predetermined entropy value is an intrinsic entropy value;

The eigen-entropy value is an entropy value calculated by at least one feature field in the first packet, and the context entropy value is obtained by mapping at least one feature configuration information corresponding to the AC. An entropy value; the integrated entropy value is an entropy value calculated from an eigen-entropy value of the first packet and a context entropy value of the first packet.
The method of claim 3 wherein said feature field comprises at least one of:

The source IP address, the destination IP address, the protocol type, the source port, the destination port, the IPv4 service type ToS field, and the IPv6 flow label Flow-label field of the first packet;

Source media access control MAC and destination MAC of the first packet;

The Ethernet type ethertype of the first packet, the inner and outer virtual LAN identifier VLAN ID, and the 802.1p priority.
The method according to claim 3, wherein the feature configuration information corresponding to the AC comprises at least one of the following:

Information obtained by the AC mapping;

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

Information obtained by mapping the primary interface to which the AC belongs;

Information obtained by hash calculation by the Ethernet segment identifier ESI corresponding to the primary interface to which the AC belongs;

The ESI itself corresponding to the primary interface to which the AC belongs;

An ESI IP corresponding to the ESI corresponding to the primary interface to which the AC belongs, where the ESI IP is an IP address configured for the ESI, and the ESI IP and the node to which the ESI belongs are in addition to the ESI The ESI IPs corresponding to the external ESIs are different from each other.
The method of claim 3 wherein said integrated entropy value is obtained in accordance with at least one of:

Performing a bitwise logical exclusive OR operation on the eigen-entropy value and the context entropy value to obtain the comprehensive entropy value;

Calculating from the eigen-entropy value, the context entropy value, and any N constants to obtain the integrated entropy value; wherein N is an integer greater than or equal to 1.
The method according to claim 2, wherein, in a case where the first IP address is located in an IPv6 option header of the second message, whether the reservation exists in the IPv6 option header is indicated by one of the following Entropy value:

Indicated by the next header Next-header field in the IPv6 header of the second packet;

Indicated by the field in the IPv6 option header.
The method according to claim 1, wherein the service type to which the AC belongs includes at least one of the following:

a VPN forwarded based on the MAC header of the first packet in the virtual private network VPN;

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

A VPN that forwards according to the configuration information on the AC in the VPN.
The method of claim 1, wherein processing the first message comprises at least one of the following:

Performing an expandable virtual local area network (VXLAN) encapsulation on the first packet;

Performing a VXLAN general protocol extended GPE encapsulation on the first packet;

Performing a general network virtualization encapsulation Geneve encapsulation on the first packet;

Generating a universal routing encapsulation NVGRE encapsulation of the first packet for network virtualization;

The segmented route SRv6 encapsulation implemented on the IPv6 data plane is performed on the first packet.
A method for processing a message, comprising:

Receiving, by the service provider edge device PE, the first packet, where the first packet is a packet obtained by the PE processing the second packet received by the access circuit AC of the PE, where The first packet includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value, and the predetermined entropy value is used to identify the second packet. Entropy of text

Processing the first message.
The method of claim 10, wherein the first IP address is located in at least one of the following locations of the first message: source IP, destination IP, and Internet Protocol version 6 IPv6 option header.
The method according to claim 10, wherein, if the first IP address is located in an IPv6 option header of the first packet, indicating whether the IPv6 option header is present in the IPv6 option header Predetermined entropy value:

Indicated by the next header Next-header field in the IPv6 header of the first packet;

Indicated by the field in the IPv6 option header.
The method according to claim 10, wherein when the destination IP of the first packet is an IP address configured for a node that receives the first packet, processing the first packet includes:

Setting a binary bit of the first IP address in the first packet modified by the predetermined entropy value to a predetermined value; wherein, the predetermined values set by different binary bits are the same or different;

Recalculating the predetermined entropy value, and decrypting, by the recalculated predetermined entropy value, a portion of the first IP address in the first packet that is encrypted by the predetermined entropy value; The predetermined entropy value is an intrinsic entropy value;

Stripping the IPv6 option header containing the first IP address in the first packet;

Processing the first message directly.
The method according to claim 10, wherein when the destination IP of the first packet is a remote IP address on a node that receives the first packet, the first packet is processed, including at least the following One of: selecting load balancing forwarding information according to the first IP address, and forwarding the first packet according to the load balancing forwarding information;

The binary bits corresponding to the predetermined entropy value carried in the first IP address are respectively regarded as predetermined values, and the first packet is subjected to processing other than forwarding;

Forwarding the first packet directly.
A message sending device includes:

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

The processing module is configured to process the first packet to obtain at least one second packet, where the second packet includes: a first Internet Protocol IP address; the first IP address is a usage reservation The IP address obtained by modifying the second IP address by the entropy value; wherein the predetermined entropy value is used to identify the entropy of the first packet;

The sending module is configured to send the second packet.
The apparatus of claim 15, wherein the first IP address is located in at least one of the following locations of the second message: source IP, destination IP, and Internet Protocol version 6 IPv6 option header.
A message processing device, comprising:

The receiving module is configured to receive the first packet sent by the service provider edge device PE, where the first packet is processed by the PE to process the second packet received by the access circuit AC of the PE. The first message includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value, where the predetermined entropy value is used Identifying an entropy of the fourth packet;

And a processing module, configured to process the first packet.
The apparatus of claim 17, wherein the first IP address is located in at least one of the following locations of the first message: a source IP, a destination IP, and an Internet Protocol version 6 IPv6 option header.
A provider edge PE node, including:

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

The processor is configured to process the first packet to obtain at least one second packet, where the second packet includes: a first Internet Protocol IP address; the first IP address is a usage reservation The IP address obtained by modifying the second IP address by the entropy value; wherein the predetermined entropy value is used to identify the entropy of the first packet;

The communication interface is configured to send the second message.
A node that includes:

a communication interface, configured to receive a message sent by the service provider edge device PE, where the first packet is processed by the PE to process a second packet received by the access circuit AC of the PE. a packet, the first packet includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying a second IP address by using a predetermined entropy value, where the predetermined entropy value is used to identify Entropy of the second message;

a processor configured to process the first message.
A message processing system includes: a first node and a second node; wherein

The first node is configured to receive a first packet from the access circuit AC, process the first packet to obtain at least one second packet, and send the second packet to the second node. The second packet includes: a first Internet Protocol IP address; the first IP address is an IP address obtained by modifying a second IP address using a predetermined entropy value; wherein the predetermined entropy value is used And identifying an entropy of the first packet;

The second node is configured to process the second packet after receiving the second packet.
A storage medium, the storage medium comprising a stored program, wherein the program is executed to perform the method of any one of claims 1 to 14.
A processor, the processor being arranged to run a program, wherein the program is executed to perform the method of any one of claims 1 to 14.