Communication methods and devices

Abstract

This application provides a communication method and apparatus. The method includes: when a first service packet sent by a first user-side device is received through a first interface, determining a first VPN instance bound to the first interface; obtaining the corresponding first VPN SID from the routing table of the first VPN instance; when it is determined that the first service packet will be forwarded through an SRv6 path, performing SRv6 encapsulation on the first service packet to obtain a second service packet; if a first VPN SID exists in the SID list and an encryption mapping table entry matching the first VPN SID exists in the local encryption mapping table, obtaining an IPSec SA identifier from the encryption mapping table entry; encrypting the first service packet included in the second service packet using the IPSec SA corresponding to the IPSec SA identifier to obtain a third service packet; and forwarding the third service packet to the next-hop network device through the SRv6 path.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0002] Segment Routing over IPv6 Traffic Engineering (SRv6 TE) provides a flexible method for selecting forwarding paths to meet diverse user needs. When multiple forwarding paths exist between the source and destination nodes within an SRv6 network, utilizing SRv6 TE to select these paths not only facilitates network management and planning for administrators but also effectively reduces the forwarding load on network devices.

[0003] In practical applications, in addition to flexible path planning, users also need to encrypt and protect the transmitted service flow. To encrypt and protect the transmitted service flow, an IPSec tunnel is established between each pair of Endpoint nodes on the forwarding path, and each Endpoint node forwards the service packets through the Internet Protocol Security (IPSec) tunnel.

[0004] However, the above-mentioned scheme for encrypting and protecting business flows also exposes the following problems: 1) IPSec tunnels need to be created in segments along the entire forwarding path, which is inconvenient for network deployment; 2) The IPSec SA negotiated between each pair of endpoint nodes is different, and during the forwarding process, it has to go through multiple encryption and decryption processes, which affects forwarding performance. Summary of the Invention

[0005] In view of this, this application provides a communication method and apparatus to solve the problems of existing encryption protection schemes, such as the inconvenience of segmented creation of IPSec tunnels, inconvenient network deployment, and multiple encryption and decryption processes during forwarding, which affect forwarding performance.

[0006] In a first aspect, this application provides a communication method applied to a first network device, the first network device including a first interface, the method comprising:

[0007] When a first service message sent by a first user-side device is received through the first interface, the first VPN instance bound to the first interface is determined according to the first interface.

[0008] Retrieve the corresponding first VPN SID from the routing table of the first VPN instance;

[0009] When it is determined that the first service packet is forwarded through the SRv6 path, the first service packet is encapsulated in SRv6 to obtain a second service packet. The second service packet includes a list of SIDs indicating the SRv6 forwarding path and the first service packet.

[0010] If the first VPN SID exists in the SID list and there is an encryption mapping table entry in the local encryption mapping table that matches the first VPN SID, then obtain the IPSec SA identifier from the encryption mapping table entry.

[0011] The first service packet included in the second service packet is encrypted using the IPSec SA identifier corresponding to the IPSec SA to obtain a third service packet. The third service packet includes the SID list and the encrypted first service packet.

[0012] The third service packet is forwarded to the next-hop network device via the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device.

[0013] The first network device has established the SRv6 path and IPSec tunnel with the second network device.

[0014] Secondly, this application provides a communication device applied to a first network device, the first network device including a first interface, the device comprising:

[0015] The determining unit, when receiving a first service message sent by a first user-side device through the first interface, determines a first VPN instance bound to the first interface based on the first interface.

[0016] The first acquisition unit is used to acquire the corresponding first VPN SID from the routing table of the first VPN instance;

[0017] An encapsulation unit is configured to perform SRv6 encapsulation processing on the first service packet when it is determined that the first service packet is forwarded through an SRv6 path, to obtain a second service packet. The second service packet includes a SID list indicating the SRv6 forwarding path and the first service packet.

[0018] The second acquisition unit is configured to acquire the IPSec SA identifier from the encryption mapping table entry if the first VPN SID exists in the SID list and an encryption mapping table entry matching the first VPN SID exists in the local encryption mapping table.

[0019] An encryption unit is used to encrypt the first service packet included in the second service packet by using the IPSec SA identifier corresponding to the IPSec SA to obtain a third service packet, wherein the third service packet includes the SID list and the encrypted first service packet;

[0020] The sending unit is configured to forward the third service packet to the next-hop network device via the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device.

[0021] The first network device has established the SRv6 path and IPSec tunnel with the second network device.

[0022] Thirdly, this application provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, which in turn cause the processor to perform the method provided in the first aspect of this application.

[0023] Therefore, by applying the communication method and apparatus provided in this application, when a first service packet sent by a first user-side device is received through a first interface, the first network device determines a first VPN instance bound to the first interface based on the first interface; in the routing table of the first VPN instance, the first network device obtains the corresponding first VPN SID; when it is determined that the first service packet will be forwarded through an SRv6 path, the first network device performs SRv6 encapsulation processing on the first service packet to obtain a second service packet, which includes a list of SIDs indicating the SRv6 forwarding path and the first service packet; if a first VPN SID exists in the SID list and an encrypted mapping table entry matching the first VPN SID exists in the local encrypted mapping table, the first network device obtains the IPSec SA identifier from the encrypted mapping table entry; and forwards the first service packet through the IPSec path. The first network device encrypts the first service packet included in the second service packet to obtain a third service packet. The third service packet includes the SID list and the encrypted first service packet. The first network device forwards the third service packet to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device. The first network device has established an SRv6 path and an IPSec tunnel with the second network device.

[0024] In this way, by establishing a mapping relationship between VPN SID and IPSec SA, the system ensures that interested service flows are encrypted and protected during transmission, achieving flexible and efficient service orchestration. During forwarding, there is no need for multiple layers of encapsulation of service packets; encryption and SRv6 functionality are integrated to ensure efficient traffic forwarding. At the same time, it also solves the problems of existing encryption protection schemes, such as segmented creation of IPSec tunnels, inconvenient network deployment, and multiple encryption / decryption processes during forwarding, which affect forwarding performance. Attached Figure Description

[0025] Figure 1 A flowchart illustrating the communication method provided in the embodiments of this application;

[0026] Figure 2 This is a schematic diagram of the communication network topology provided in an embodiment of this application;

[0027] Figure 3 A structural diagram of the communication device provided in the embodiments of this application;

[0028] Figure 4 The network device hardware structure provided in the embodiments of this application. Detailed Implementation

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0030] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0031] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0032] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 1 , Figure 1 A flowchart illustrating a communication method provided in an embodiment of this application. This method is applied to a first network device. The communication method provided in an embodiment of this application may include the following steps.

[0033] Step 110: When a first service message sent by a first user-side device is received through the first interface, determine the first VPN instance bound to the first interface according to the first interface.

[0034] Specifically, the first network device includes a first interface and is connected to a first user-side device (e.g., a CE device) through the first interface. Through the first interface, the first network device receives a first service message sent by the first user-side device.

[0035] When the first service message arrives at the first interface, the first network device determines the first VPN instance bound to the first interface based on the first interface.

[0036] Step 120: Obtain the corresponding first VPN SID from the routing table of the first VPN instance;

[0037] Specifically, according to the description in step 110, after the first network device determines the first VPN instance bound to the first interface, it searches for a routing table entry matching the destination address in the IPv4 routing table of the first VPN instance based on the destination address included in the first service packet. Using the found routing table entry, the first network device obtains the corresponding first VPN SID.

[0038] In this embodiment, the first VPN SID is the VPN SID configured in the routing table of the second VPN instance within the second network device. This first VPN SID is synchronized from the second network device to the first network device via BGP protocol messages. The BGP protocol messages also include information such as the RT identifier, host address, and second network device address, enabling the first network device to traverse local Import RT identifiers based on the RT identifier, and generate a host route to the host under the local first VPN instance indicated by the same local Import Route Target (Import RT) identifier, and store the first VPN SID in the IPv4 routing table of the first VPN instance.

[0039] Step 130: When it is determined that the first service packet is forwarded through the SRv6 path, the first service packet is encapsulated in SRv6 to obtain a second service packet. The second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet.

[0040] Specifically, according to the description of step 120, after the first network device finds the routing table entry, it obtains the next hop and outgoing interface from the matching routing table entry.

[0041] In this embodiment, the outgoing interface indication is a pre-configured SRv6 Policy within the first network device. At this time, the first network device determines to forward the first service packet via the SRv6 Policy. The first network device obtains the SID list from the SRv6 Policy and, according to the existing SRv6 protocol, encapsulates an SRH header and an IPv6 header on the outer layer of the first service packet to obtain the second service packet. The SRH header stores the SID list included in the SRv6 Policy, which indicates the forwarding path from the first network device to the second network device. The second network device is the upstream network device leading to the device indicated by the destination address.

[0042] In this step, we will use SRv6 Policy as an example of SRv6 path. In practical applications, SRv6 path can also be other forms such as SRv6 BE.

[0043] Step 140: If the first VPN SID exists in the SID list and there is an encryption mapping table entry in the local encryption mapping table that matches the first VPN SID, then obtain the IPSec SA identifier from the encryption mapping table entry.

[0044] Specifically, according to the descriptions of steps 120 and 130, after the first network device obtains the first VPN SID and the SID list, it first determines whether the first VPN SID exists in the SID list. If the first VPN SID exists in the SID list, the first network device continues to determine whether there is an encryption mapping table entry in the local encryption mapping table that matches the first VPN SID.

[0045] If an encrypted mapping table entry matching the first VPN SID exists, the first network device obtains the IPSec SA identifier from the encrypted mapping table entry.

[0046] Understandably, if the first VPN SID does not exist in the SID list, the first network device will forward the second service packet according to the existing SRv6 protocol and will not continue with further judgment.

[0047] Step 150: Using the IPSec SA corresponding to the IPSec SA identifier, encrypt the first service packet included in the second service packet to obtain a third service packet. The third service packet includes the SID list and the encrypted first service packet.

[0048] Specifically, according to the description of step 140, after the first network device obtains the IPSec SA identifier, it encrypts the first service packet included in the second service packet through the IPSec SA corresponding to the IPSec SA identifier to obtain the third service packet.

[0049] For example, the first network device uses the ESP protocol to encrypt the first service packet, while the IPv6 header and SRH header encapsulated on the outer layer of the first service packet are not encrypted. The first network device inserts an ESP header between the SRH header and the first service packet, and encapsulates an ESP trailer at the end of the first service packet to obtain the third service packet. The encryption algorithms used by the ESP protocol include DES, 3DES, and AES. Additionally, as an option, the ESP protocol also provides authentication services, using authentication algorithms including HMAC-MD5 and HMAC-SHA1.

[0050] It is understandable that the ESP protocol is a security protocol supported by both the first and second network devices. The IPSec SA is formed after the first network device and the second network device have performed IKE negotiation in advance.

[0051] Step 160: Forward the third service packet to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device.

[0052] Specifically, according to the description of step 150, after the first network device obtains the third service packet, it forwards the third service packet to the next hop network device according to the forwarding path indicated by the SID list.

[0053] Understandably, in order to enable forwarding, the first network device also encapsulates the MAC header on the outer layer of the IPv6 header, so that the third service packets can be forwarded hop by hop.

[0054] After receiving the third service packet, the next-hop network device updates the destination address in the IPv6 header according to the existing SRv6 protocol, and continues to forward the third service packet on the forwarding path until the second network device receives the third service packet.

[0055] After receiving the third service packet, the second network device looks up the destination address in its local SID table based on the destination address in the IPv6 header and determines the VPN instance to which the destination address belongs. This VPN instance is the second VPN instance within the second network device. This destination address is also the aforementioned first VPN SID.

[0056] According to the existing SRv6 protocol, the second network device first decapsulates the third service packet to obtain the encrypted first service packet. The second network device then obtains the SPI from the ESP header included in the encrypted first service packet. Based on the SPI, the second network device retrieves the encryption mapping table entry that matches the SPI from its local encryption mapping table, and retrieves the IPSec SA previously negotiated with the first network device from it.

[0057] According to the IPSec SA, the second network device decrypts the encrypted first service packet to obtain the first service packet. Based on the destination address included in the first service packet, the second network device searches for a routing table entry matching the destination address in the IPv4 routing table of the second VPN instance, and obtains the next hop and outgoing interface from the matching routing table entry.

[0058] The second network device sends a first service message to the accessed second user-side device (e.g., CE device) through the second interface indicated by the outgoing interface.

[0059] Therefore, by applying the communication method provided in this application, when a first service packet sent by a first user-side device is received through a first interface, the first network device determines a first VPN instance bound to the first interface based on the first interface; in the routing table of the first VPN instance, the first network device obtains the corresponding first VPN SID; when it is determined that the first service packet will be forwarded through an SRv6 path, the first network device performs SRv6 encapsulation processing on the first service packet to obtain a second service packet, which includes a list of SIDs indicating the SRv6 forwarding path and the first service packet; if a first VPN SID exists in the SID list and an encrypted mapping table entry matching the first VPN SID exists in the local encrypted mapping table, the first network device obtains the IPSec SA identifier from the encrypted mapping table entry; and uses the IPSec SA identifier to obtain the corresponding IPSec... SA, the first network device encrypts the first service message included in the second service message to obtain a third service message, which includes a SID list and the encrypted first service message; through the SRv6 path, the first network device forwards the third service message to the next-hop network device, so that the next-hop network device forwards the third service message to the second network device; wherein, the first network device has established an SRv6 path and an IPSec tunnel with the second network device.

[0060] In this way, by establishing a mapping relationship between VPN SID and IPSec SA, the system ensures that interested service flows are encrypted and protected during transmission, achieving flexible and efficient service orchestration. During forwarding, there is no need for multiple layers of encapsulation of service packets; encryption and SRv6 functionality are integrated to ensure efficient traffic forwarding. At the same time, it also solves the problems of existing encryption protection schemes, such as segmented creation of IPSec tunnels, inconvenient network deployment, and multiple encryption / decryption processes during forwarding, which affect forwarding performance.

[0061] Optionally, in this embodiment of the application, before performing step 110, the first network device will also receive a private network route sent by the second network device and generate a host route locally based on the private network route.

[0062] Specifically, the second user-side device wants to synchronize its private network routes with the second network device. The second user-side device generates a second BGP protocol message (e.g., a BGP Update message, where the second BGP protocol message is only used to distinguish it from other BGP protocol messages, and in practical applications, it can also be called the first BGP protocol message). This second BGP protocol message includes a host address and an RT identifier, and the host address is the address of the second user-side device.

[0063] The second user-side device sends a second BGP protocol message to the second interface of the second network device it accesses. When the second BGP protocol message arrives at the second interface, the second network device, based on the RT identifier, traverses its local Import RTs and determines the Import RT with the same RT identifier from the local Import RTs. In this embodiment, the determined Import RT indicates the second VPN instance.

[0064] In the IPv4 routing table of the second VPN instance, the second network device obtains the first VPN SID. Simultaneously, the second network device generates a host route to the host (the second user-side device) within the IPv4 routing table of the second VPN instance. This host route includes a destination address field, an outgoing interface field, and a next-hop field. The destination address field stores the host address, the outgoing interface field stores the identifier of the second interface, and the next-hop field stores the interface address of the third interface. This third interface is the interface through which the second user-side device accesses the second network device.

[0065] The second network device also generates a first BGP protocol message (e.g., a BGP Update message), which includes a host address, an RT identifier, a first VPNSID configured in the IPv4 routing table of the second VPN instance indicated by the RT identifier, and the address of the second network device.

[0066] The second network device synchronizes the first BGP protocol message with the first network device.

[0067] After receiving the first BGP protocol message, the first network device obtains the host address, RT identifier, first VPNSID, and the address of the second network device. Based on the RT identifier, the first network device traverses its local Import RTs and identifies the Import RT with the same RT identifier. The identified Import RT indicates the first VPN instance. In the IPv4 routing table of the first VPN instance, the first network device stores the first VPN SID and generates a host route to the host (the second user-side device). This host route also includes a destination address field, an outgoing interface field, and a next-hop field. Specifically, the destination address field stores the host address, the outgoing interface field stores the identifier of the pre-configured SRv6 Policy, and the next-hop field stores the address of the second network device.

[0068] It should be noted that, in one implementation, after the first network device receives the first BGP protocol message, it can store the identifier of the SRv6 Policy in the outgoing interface field according to the local pre-configured routing policy, so that when a service message destined for the host is received later, the service message will be diverted to the SRv6 Policy for forwarding.

[0069] The above routing policy has configured the address of the second user-side device, the endpoint attribute and color attribute of the SRv6 Policy, so that after the first network device receives the first BGP protocol message, it matches the routing policy according to the host address and generates a host route locally.

[0070] In another implementation, the first BGP protocol message also includes an SRv6 Policy identifier. When generating host routes, the first network device can store this SRv6 Policy identifier in the outgoing interface field, so that when it subsequently receives service packets destined for the second user-side device, it can redirect the service packets to the SRv6 Policy for forwarding.

[0071] Understandably, after generating the host route, the first network device continues to synchronize the host route with the first user-side device, so that the first user-side device can generate a host route to the host (the second user-side device) locally and distribute the host route to its local IP routing table. This generation process can refer to existing route generation processes and will not be repeated here.

[0072] Optionally, in this embodiment of the application, the first network device will negotiate IPSec SA with the second network device before performing step 110.

[0073] Specifically, after the first network device generates the host route, it initiates the process of negotiating the IPSec SA with the second network device.

[0074] According to the existing IKE protocol, in the first phase of negotiation, a channel is established between the first network device and the second network device, which is authenticated by both parties and protects the security of communication data; that is, an IKE SA is established. In the second phase of negotiation, the first network device and the second network device use the IKE SA established in the first phase to provide IPsec negotiation security services, that is, to negotiate an IPsec SA and establish an IPsec SA for the final secure transmission of IP data.

[0075] In this embodiment of the application, the first network device and the second network device have established IKESA in accordance with the existing IKE protocol, which will not be repeated here.

[0076] After establishing an IKE SA, the first network device generates a first IKE protocol message, which includes the first SA attributes supported by the first network device (e.g., the security protocol used (AH, ESP, or a combination of both), the encapsulation mode of the protocol message (transport mode or tunnel mode), the authentication algorithm (HMAC-MD5 or HMAC-SHA1), the encryption algorithm (DES, 3DES, or AES), the shared key for protecting data in a specific stream, and the key's time to life), a first VPN SID, and a second VPN SID.

[0077] The first IKE protocol message includes a Client Initiator Identifier (IDci) field and a Client Responder (IDcr) field. The IDci field carries the second VPN SID, and the IDcr field carries the first VPN SID. The second VPN SID is the VPN SID configured in the IPv4 router of the first VPN instance on the first network device.

[0078] Understandably, the first IKE protocol message also includes a first random number, a first message sequence number, and a first hash value. This first hash value is obtained by the first network device performing a hash calculation on the first random number, the first message sequence number, the first VPN SID, and the second VPN SID.

[0079] The first network device sends the first IKE protocol message to the second network device via IKE SA.

[0080] After receiving the first IKE protocol message, the second network device obtains the first SA attribute, the first VPN SID, and the second VPN SID supported by the first network device. Based on the first SA attribute, the second network device selects a second SA attribute that it supports (for each sub-attribute, the second network device selects one sub-attribute that it supports).

[0081] The second network device generates a second IKE protocol message, which includes a second SA attribute supported by the second network device, a first VPN SID, and a second VPN SID.

[0082] The second IKE protocol message also includes an IDci field and an IDcr field. The IDci field is used to carry the second VPN SID, and the IDcr field is used to carry the first VPN SID.

[0083] Understandably, the second IKE protocol message also includes a first random number, a second random number, a second message sequence number, and a second hash value. This second hash value is obtained by the second network device after performing a hash calculation on the first random number, the second random number, the second message sequence number, the first VPN SID, and the second VPN SID.

[0084] The second network device sends a second IKE protocol message to the first network device via IKE SA.

[0085] After receiving the second IKE protocol message, the first network device obtains the second SA attribute, the first VPN SID, and the second VPN SID from it. Based on the second SA attribute, the first network device determines each sub-attribute supported by the second network device. The first network device generates a third IKE protocol message and sends it to the second network device again via the IKE SA. This third IKE protocol message is used to notify the second network device that the first network device has completed IPSec SA negotiation with the second network device.

[0086] Understandably, the third IKE protocol message also includes a first random number, a second random number, a third message sequence number, and a third hash value. This third hash value is obtained by the first network device after hashing the first random number, the second random number, and the third message sequence number.

[0087] After receiving the third IKE protocol message, the second network device determines that it has completed IPSec SA negotiation with the first network device.

[0088] Optionally, in this embodiment, after sending a third IKE protocol message to the second network device, the first network device will also generate an encrypted mapping entry. This encrypted mapping entry is used to store the mapping relationship between the IPSec SA and the VPN SID. The encrypted mapping entry includes the IPSec SA identifier of the negotiated IPSec SA and the first VPN SID.

[0089] The first network device stores the encrypted mapping entries in its local encrypted mapping table.

[0090] Optionally, the encrypted mapping entry may also include information such as the second VPN SID, SPI, key, and algorithm.

[0091] Understandably, after receiving the third IKE protocol message, the second network device also generates an encryption mapping entry and stores it in its local encryption mapping table. The encryption mapping entry generated by the second network device, like the one generated by the first network device, includes the IPSec SA identifier of the negotiated IPSec SA and the second VPN SID. This encryption mapping entry also includes information such as the first VPN SID, SPI, key, and algorithm.

[0092] Therefore, by carrying the VPN SID configured under the VPN instance in the IKE protocol message, the negotiated IPSec SA can be used to encrypt the service messages when forwarding the service messages under the VPN instance, thus ensuring service security.

[0093] In practical applications, the communication method of this application embodiment can also be used in networking scenarios such as EVPN VPLS over SRv6 and EVPN VPWS over SRv6. In this case, different types of VPN SIDs are configured for different scenarios. For example, in the EVPN VPLS over SRv6 networking scenario, the VPN SID can be configured as an End.DT2U type SID; in the EVPN VPWS over SRv6 networking scenario, the VPN SID can be configured as an End.DX2 type SID. IPSec SA can also provide encrypted protection for service flows in the above networking scenarios.

[0094] The communication method provided in the embodiments of this application will be described in detail below. See also... Figure 2 , Figure 2 This is a schematic diagram of a communication network topology provided in an embodiment of this application. Figure 2The network consists of CE1, PE1, P, PE2, and CE2. CE1 and CE2 are user-side devices, while PE1, P, and PE2 are network-side devices. Each device uses its own loopback address. For example, CE1's IPv4 address is 11.11.11.11 / 32, and PE1's IPv6 address is 2001:DB8:1::1 / 128. CE1 and PE1 establish an EBGP neighbor relationship, as do CE2 and PE2. PE1 and PE2 establish a BGP neighbor relationship and an IPSec tunnel.

[0095] PE1 includes interface 1 (address: 10.1.1.1 / 24), which is connected to interface 3 (address: 10.1.1.2 / 24) of CE1. Interface 1 is bound to VPN1. PE2 includes interface 2 (address: 10.2.1.1 / 24), which is connected to interface 4 (address: 10.2.1.2 / 24) of CE2. Interface 2 is bound to VPN1.

[0096] PE1 and PE2 belong to AS100. A bidirectional SRv6 TE Policy is established between the two devices. This SRv6 TE Policy can be used to carry IP L3VPNv4 services. PE1 is configured as follows:

[0097] Segment-routing IPv6

[0098] Segment-list PE1-PE2

[0099] Index5 sid ipv6 2001:DB8:100::1

[0100] Index10 sid ipv6 2001:DB8:200::2

[0101] Srv6-te policy policy1 endpoint 2001:DB8:3::3color101

[0102] Candidate-path preference 200

[0103] Segment-list PE1-PE2

[0104] Similarly, the PE2 configuration is as follows:

[0105] Segment-routing IPv6

[0106] Segment-list PE2-PE1

[0107] Index5 sid ipv6 2001:DB8:300::1

[0108] Index10 sid ipv6 2001:DB8:200::1

[0109] Srv6-te policy policy1 endpoint 2001:DB8:1::1color101

[0110] Candidate-path preference 200

[0111] Segment-list PE2-PE1

[0112] Understandably, the 2001:DB8:100::1 configuration on PE1 is of type End.X SID, used to represent the link between PE1 and P; similarly, the 2001:DB8:300::1 configuration on PE2 is of type End.X SID, used to represent the link between PE2 and P; the 2001:DB8:200::1 configuration on P is of type End.X SID, used to represent the link between P and PE1; and the 2001:DB8:200::2 configuration on P is of type End.X SID, used to represent the link between P and PE2. For example... Figure 2 In the diagram, the arrow above the End.X SID indicates the direction of the link represented by that End.X SID.

[0113] Within PE1, a VPN SID1 (2001:DB8:100::100) of type End.DT4 is also configured in the IPv4 routing table of VPN1; similarly, within PE2, a VPN SID2 (2001:DB8:300::300) of type End.DT4 is also configured in the IPv4 routing table of VPN1.

[0114] CE2 wants to synchronize IPv4 private network routes with PE2. CE2 generates BGP protocol message 1, which includes CE2's address (22.22.22.22 / 32) and RT identifier (1:1). CE2 sends BGP protocol message 1 to interface 2. When BGP protocol message 2 arrives at interface 2, PE2, based on the RT identifier (1:1), traverses its local Import RTs and determines the Import RT with the same RT identifier from its local Import RTs. In this embodiment, the determined Import RT indicates VPN1 within PE2.

[0115] In VPN1's IPv4 routing table, PE2 retrieves the VPN SID2 configured in its IPv4 routing table. Simultaneously, PE2 generates a host route to CE2 within VPN1's IPv4 routing table. This host route includes a destination address field, an outgoing interface field, and a next-hop field. Specifically, the destination address field stores the CE2 address (22.22.22.22 / 32), the outgoing interface field stores the identifier of interface 2, and the next-hop field stores the address of interface 4. Interface 4 is the interface through which CE2 connects to PE2.

[0116] PE2 also generates BGP protocol message 2, which includes the host address, RT identifier, VPN SID2, and PE2's address.

[0117] Through P, PE2 synchronizes BGP protocol message 2 to PE2.

[0118] After receiving BGP protocol message 2, PE1 obtains the host address, RT identifier, VPN SID2, and PE2's address from it. Based on the RT identifier, PE1 traverses its local Import RTs and identifies the Import RT with the same RT identifier. The identified Import RT indicates the VPN within PE1. In VPN1's IPv4 routing table, PE1 stores VPNSID2 and generates a route to the host, i.e., to CE2. This host route also includes a destination address field, an outgoing interface field, and a next-hop field. Specifically, the destination address field stores the CE2 address (22.22.22.22 / 32), the outgoing interface field stores the identifier of the pre-configured SRv6 Policy (policy1), and the next-hop field stores the PE2 address (2001:DB8:3::3).

[0119] In one implementation of this application embodiment, after PE1 receives BGP protocol message 2, it can store the identifier of SRv6 Policy in the outgoing interface field according to the pre-configured routing policy. This allows subsequent service messages destined for CE2 to be routed to the SRv6 Policy for forwarding. The routing policy includes the endpoint attribute, color attribute, and CE2's address in the SRv6 Policy, enabling PE1 to match the routing policy with the host address after receiving BGP protocol message 2 and generate a host route locally.

[0120] In another implementation, BGP protocol message 2 also includes an SRv6 Policy identifier. When generating host routes, PE1 can store this SRv6 Policy identifier in the outgoing interface field, so that when it subsequently receives service packets destined for CE2, it can redirect the service packets to the SRv6 Policy for forwarding.

[0121] After PE1 generates a host route, it continues to synchronize the host route with CE1, so that CE1 can generate a host route to CE2 locally and distribute the host route to its local IP routing table. This generation process can refer to existing route generation processes and will not be repeated here.

[0122] After PE1 generates the host route, it initiates the process of negotiating the IPSec SA with PE2.

[0123] According to the existing IKE protocol, in the first phase of negotiation, PE1 and PE2 establish a channel that ensures mutual authentication and secure protection of communication data, i.e., establish an IKE SA. In the second phase of negotiation, PE1 and PE2 use the IKE SA established in the first phase to provide security services for IPsec negotiation, i.e., negotiate an IPsec SA, and establish an IPsec SA for the final secure transmission of IP data.

[0124] In this embodiment of the application, PE1 and PE2 have established IKE SA in accordance with the existing IKE protocol, which will not be repeated here.

[0125] After establishing the IKE SA, PE1 generates IKE protocol message 1, which includes the SA attributes 1 supported by PE1 (e.g., the security protocol used (AH, ESP, or a combination of both), the encapsulation mode of the protocol message (transport mode or tunnel mode), the authentication algorithm (HMAC-MD5 or HMAC-SHA1), the encryption algorithm (DES, 3DES, or AES), the shared key for protecting data in a specific stream, and the key's time to life), VPN SID1, and VPN SID2.

[0126] The IKE protocol message 1 includes the IDci field and the IDcr field. The IDci field is used to carry VPN SID1, and the IDcr field is used to carry VPN SID2.

[0127] Understandably, IKE protocol message 1 also includes random number 1, message sequence number 1, and hash value 1. Hash value 1 is obtained by PE1 through hash calculation of random number 1, message sequence number 1, VPN SID1, and VPN SID2. Random number 1 is randomly generated by PE1.

[0128] PE1 sends IKE protocol message 1 to PE2 via IKE SA.

[0129] After receiving IKE protocol message 1, PE2 obtains the SA attribute 1, VPN SID1, and VPNSID2 supported by PE1 from it. Based on SA attribute 1, PE2 selects the SA attribute 2 it supports (PE2 selects one sub-attribute it supports within each sub-attribute).

[0130] PE2 generates IKE protocol message 2, which includes SA attribute 2 supported by PE2, VPN SID1, and VPN SID2.

[0131] The IKE protocol message 2 also includes the IDci and IDcr fields. The IDci field is used to carry VPN SID2, and the IDcr field is used to carry VPN SID2.

[0132] Understandably, IKE protocol message 2 also includes random number 1, random number 2, message sequence number 2, and hash value 2. Hash value 2 is obtained by PE2 through hash calculation of random number 1, random number 2, message sequence number 2, VPN SID1, and VPN SID2. Random number 2 is randomly generated by PE2.

[0133] PE2 sends IKE protocol message 2 to PE1 via IKE SA.

[0134] After receiving IKE protocol message 2, PE1 retrieves SA attribute 2, VPN SID1, and VPN SID2 from it. Based on SA attribute 2, PE1 determines each sub-attribute supported by PE2. PE1 generates IKE protocol message 3 and sends it to PE2 again via IKE SA. This IKE protocol message 3 is used to notify PE2 that PE1 has completed IPSec SA negotiation with PE2.

[0135] Understandably, IKE protocol message 3 also includes random number 1, random number 2, message sequence number 3, and hash value 3. This hash value 3 is obtained by PE1 after hashing random number 1, random number 2, and message sequence number 3.

[0136] After receiving IKE protocol message 3, PE2 confirms that it has completed IPSec SA negotiation with PE1.

[0137] After sending IKE protocol message 3 to PE2, PE1 will also generate an encrypted mapping entry, which is used to store the mapping relationship between IPSec SA and VPN SID. The encrypted mapping entry includes the negotiated IPSec SA identifier, VPN SID1, and VPN SID2.

[0138] PE1 stores the encryption mapping entry in its local encryption mapping table. Similarly, after receiving IKE protocol message 3, PE2 also generates an encryption mapping entry and stores it in its local encryption mapping table. The encryption mapping entry generated by PE2 is the same as that generated by PE1.

[0139] CE1 wants to communicate with CE2. CE1 generates service message 1. Service message 1 includes the source address of CE1 (11.11.11.11 / 32) and the destination address of CE2 (22.22.22.22 / 32).

[0140] PE1 receives service packet 1 through interface 1. Based on interface 1, PE1 determines VPN1, which is bound to interface 1. After determining VPN1, PE1 searches for a routing table entry matching the destination address in VPN1's IPv4 routing table, based on the destination address included in service packet 1. Using the found routing table entry, PE1 obtains VPN SID2, which was synchronized by PE2 via BGP protocol packet 2.

[0141] After PE1 finds the routing table entry, it obtains the next hop and outgoing interface from the matching routing table entry.

[0142] In this embodiment, the outgoing interface is indicated by the pre-configured SRv6 Policy1 within PE1. At this time, PE1 determines to forward service packet 1 via SRv6 Policy1. PE1 obtains the SID list from SRv6 Policy1 and, according to the existing SRv6 protocol, encapsulates an SRH header and an IPv6 header on the outer layer of service packet 1 to obtain service packet 2.

[0143] In this embodiment, PE1 first encapsulates an SRH header on the outer layer of service message 1. The SRH header stores the SID list included in SRv6 Policy1. The SID list is used to indicate the forwarding path from PE1 to PE2, and includes the following SIDs: SID[0] = 2001:DB8:300::300, SID[1] = 2001:DB8:200::2, and SID[2] = 2001:DB8:100::1. SID[0] stores the VPN SID2 configured under VPN1 in PE2, and SID[1] and SID[0] store the SIDs representing the links.

[0144] PE1 further encapsulates the IPv6 header outside the SRH header. This IPv6 header includes the source address 2001:DB8:1::1 and the destination address 2001:DB8:200::2.

[0145] After obtaining VPN SID2 and the SID list, PE1 first determines whether VPN SID2 exists in the SID list. In this embodiment, VPN SID2 exists in the SID list, and PE1 then determines whether there is an encrypted mapping entry in the local encrypted mapping table that matches VPN SID2.

[0146] If an encryption mapping entry matching VPN SID2 exists, PE1 obtains the IPSec SA identifier from the encryption mapping entry. Using the IPSec SA corresponding to the IPSec SA identifier, PE1 encrypts service packet 1, which is included in service packet 2, to obtain service packet 3.

[0147] In this embodiment, PE1 uses the ESP protocol to encrypt service packet 1, while the IPv6 header and SRH header encapsulated on the outer layer of service packet 1 are not encrypted. PE1 inserts an ESP header between the SRH header and service packet 1, and encapsulates an ESP tail at the end of service packet 1 to obtain service packet 3. The encryption algorithms used by the ESP protocol include DES, 3DES, and AES. Optionally, the ESP protocol also provides authentication services, using authentication algorithms including HMAC-MD5 and HMAC-SHA1.

[0148] After PE1 encrypts service message 1, it looks up the local SID table based on the SID[2] in the SID list and determines that the type of the SID is End.X SID. PE1 forwards service message 3 to P according to the forwarding method indicated by the existing End.X SID type.

[0149] Understandably, in order to achieve forwarding, PE1 also encapsulates the MAC header on the outer layer of the IPv6 header, so that service packet 3 can be forwarded hop by hop.

[0150] After receiving service message 3, P updates the destination address in the IPv6 header according to the existing SRv6 protocol, thus obtaining service message 4. P continues to forward service message 4 to PE2 on the forwarding path.

[0151] After receiving service packet 4, PE2 looks up the destination address in its local SID table based on the IPv6 header and determines the VPN1 to which the destination address belongs. Following the existing SRv6 protocol, PE2 decapsulates service packet 4 to obtain the decrypted service packet 1. PE2 then retrieves the SPI from the ESP header of the encrypted service packet 1. Based on the SPI, PE2 retrieves the matching encryption mapping entry from its local encryption mapping table and obtains the IPSec SA identifier previously negotiated with PE1.

[0152] Based on the IPSec SA corresponding to the IPSec SA identifier, PE2 decrypts the encrypted service packet 1 to obtain service packet 1. Based on the destination address included in service packet 1, PE2 searches for a routing table entry matching the destination address in VPN1's IPv4 routing table, and obtains the next hop and outgoing interface from the matching routing table entry.

[0153] PE2 sends service message 1 to CE2 through interface 2 indicated by the outgoing interface.

[0154] Based on the same inventive concept, embodiments of this application also provide a communication device corresponding to the communication method. See also Figure 3 , Figure 3 The communication apparatus provided in this application embodiment is applied to a first network device, the first network device including a first interface, the apparatus comprising:

[0155] When the determining unit 310 receives a first service message sent by the first user-side device through the first interface, it determines the first VPN instance bound to the first interface based on the first interface.

[0156] The first acquisition unit 320 is used to acquire the corresponding first VPNSID from the routing table of the first VPN instance;

[0157] The encapsulation unit 330 is used to encapsulate the first service packet with SRv6 when it is determined that the first service packet is forwarded through the SRv6 path, so as to obtain a second service packet. The second service packet includes a SID list for indicating the SRv6 forwarding path and the first service packet.

[0158] The second acquisition unit 340 is configured to acquire the IPSecSA identifier from the encryption mapping table entry if the first VPN SID exists in the SID list and an encryption mapping table entry matching the first VPN SID exists in the local encryption mapping table.

[0159] The encryption unit 350 is used to encrypt the first service packet included in the second service packet by using the IPSec SA identifier corresponding to the IPSec SA to obtain a third service packet, wherein the third service packet includes the SID list and the encrypted first service packet.

[0160] The sending unit 360 is used to forward the third service packet to the next-hop network device through the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device.

[0161] The first network device has established the SRv6 path and IPSec tunnel with the second network device.

[0162] Optionally, the device further includes:

[0163] The receiving unit (not shown in the figure) is used to receive a first BGP protocol message sent by the second network device. The first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in the routing table of the second VPN instance in the second network device indicated by the RT identifier, and the address of the second network device.

[0164] A determining unit (not shown in the figure) is used to traverse local Import RTs according to the RT identifier, and determine the Import RT that is the same as the RT identifier from the local Import RTs. The determined Import RT indicates the first VPN instance.

[0165] A generation unit (not shown in the figure) is used to generate a host route to the host indicated by the host address in the routing table of the first VPN instance. The host route includes the host address and the address of the second network device.

[0166] A storage unit (not shown in the figure) is used to store the first VPNSID in the routing table of the first VPN instance;

[0167] The first BGP protocol message is sent by the second network device after receiving the second BGP protocol message sent by the second user-side device. The second BGP protocol message includes the host address and the RT identifier.

[0168] Optionally, the sending unit 360 is further configured to send a first IKE protocol message to the second network device, the first IKE protocol message including a first SA attribute supported by the first network device, a first VPN SID and a second VPN SID;

[0169] The receiving unit (not shown in the figure) is further configured to receive a second IKE protocol message sent by the second network device, the second IKE protocol message including a second SA attribute supported by the second network device, the first VPN SID and the second VPN SID;

[0170] The sending unit 360 is further configured to send a third IKE protocol message to the second network device, the third IKE protocol message being used to enable the second network device to determine that it has completed IPSec SA negotiation with the first network device.

[0171] Wherein, the second SA attribute is the SA attribute supported by the second network device selected by the second network device from the first SA attribute; the second VPN SID is the VPNSID configured in the routing table of the first VPN instance.

[0172] Optionally, the first IKE protocol message or the second IKE protocol message may include a client initiator identifier and a client responder identifier, respectively;

[0173] The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

[0174] Optionally, the storage unit (not shown in the figure) is further configured to store the mapping relationship between the negotiated IPSec SA identifier and the first VPN SID in the encrypted mapping table entry.

[0175] Therefore, by applying the communication device provided in this application, when a first service packet sent by a first user-side device is received through a first interface, the first network device determines a first VPN instance bound to the first interface based on the first interface; in the routing table of the first VPN instance, the first network device obtains the corresponding first VPN SID; when it is determined that the first service packet will be forwarded through an SRv6 path, the first network device performs SRv6 encapsulation processing on the first service packet to obtain a second service packet, which includes a list of SIDs indicating the SRv6 forwarding path and the first service packet; if a first VPN SID exists in the SID list and an encrypted mapping table entry matching the first VPN SID exists in the local encrypted mapping table, the first network device obtains the IPSec SA identifier from the encrypted mapping table entry; and through the IPSec SA identifier corresponding to the IPSec... SA, the first network device encrypts the first service message included in the second service message to obtain a third service message, which includes a SID list and the encrypted first service message; through the SRv6 path, the first network device forwards the third service message to the next-hop network device, so that the next-hop network device forwards the third service message to the second network device; wherein, the first network device has established an SRv6 path and an IPSec tunnel with the second network device.

[0176] In this way, by establishing a mapping relationship between VPN SID and IPSec SA, the system ensures that interested service flows are encrypted and protected during transmission, achieving flexible and efficient service orchestration. During forwarding, there is no need for multiple layers of encapsulation of service packets; encryption and SRv6 functionality are integrated to ensure efficient traffic forwarding. At the same time, it also solves the problems of existing encryption protection schemes, such as segmented creation of IPSec tunnels, inconvenient network deployment, and multiple encryption / decryption processes during forwarding, which affect forwarding performance.

[0177] Based on the same inventive concept, embodiments of this application also provide a network device, such as... Figure 4 As shown, the system includes a processor 410, a transceiver 420, and a machine-readable storage medium 430. The machine-readable storage medium 430 stores machine-executable instructions that can be executed by the processor 410. The processor 410 is prompted by the machine-executable instructions to execute the communication method provided in the embodiments of this application. (The foregoing...) Figure 3 The communication device shown can be used as follows: Figure 4 The hardware structure of the network device shown is implemented.

[0178] The aforementioned computer-readable storage medium 430 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 430 may also be at least one storage device located remotely from the aforementioned processor 410.

[0179] The processor 410 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0180] In this embodiment of the application, the processor 410 reads the machine-executable instructions stored in the machine-readable storage medium 430, and is prompted by the machine-executable instructions to enable the processor 410 itself and the transceiver 420 to execute the communication method described in the foregoing embodiment of the application.

[0181] In addition, this application provides a machine-readable storage medium 430 that stores machine-executable instructions. When called and executed by the processor 410, the machine-executable instructions cause the processor 410 itself and the transceiver 420 to execute the communication method described in the aforementioned application.

[0182] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0183] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0184] For the embodiments of communication devices and machine-readable storage media, since the methods involved are basically similar to those of the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0185] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method is applied to a first network device, the first network device including a first interface, the method comprising: When a first service message sent by a first user-side device is received through the first interface, the first VPN instance bound to the first interface is determined according to the first interface. Retrieve the corresponding first VPN SID from the routing table of the first VPN instance; When it is determined that the first service packet is forwarded through the SRv6 path, the first service packet is encapsulated in SRv6 to obtain a second service packet. The second service packet includes a list of SIDs indicating the SRv6 forwarding path and the first service packet. If the first VPN SID exists in the SID list and there is an encryption mapping table entry in the local encryption mapping table that matches the first VPN SID, then obtain the IPSec SA identifier from the encryption mapping table entry. The first service packet included in the second service packet is encrypted using the IPSec SA identifier corresponding to the IPSec SA to obtain a third service packet. The third service packet includes the SID list and the encrypted first service packet. The third service packet is forwarded to the next-hop network device via the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device. The first network device has established the SRv6 path and IPSec tunnel with the second network device.

2. The method according to claim 1, characterized in that, When a first service message sent by a user-side device is received through the first interface, before determining the first VPN instance bound to the first interface based on the first interface, the method further includes: The system receives a first BGP protocol message sent by the second network device. The first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in the routing table of the second VPN instance in the second network device indicated by the RT identifier, and the address of the second network device. Based on the RT identifier, traverse the local Import RTs and determine the Import RT that is the same as the RT identifier from the local Import RTs. The determined Import RT indicates the first VPN instance. In the routing table of the first VPN instance, a host route is generated to reach the host indicated by the host address, the host route including the host address and the address of the second network device; The first VPN SID is stored in the routing table of the first VPN instance; The first BGP protocol message is sent by the second network device after receiving the second BGP protocol message sent by the second user-side device. The second BGP protocol message includes the host address and the RT identifier.

3. The method according to claim 2, characterized in that, When a first service message sent by a user-side device is received through the first interface, before determining the first VPN instance bound to the first interface based on the first interface, the method further includes: Send a first IKE protocol message to the second network device. The first IKE protocol message includes a first SA attribute supported by the first network device, the first VPN SID, and the second VPN SID. Receive a second IKE protocol message sent by the second network device, the second IKE protocol message including a second SA attribute supported by the second network device, the first VPN SID and the second VPN SID; Send a third IKE protocol message to the second network device, the third IKE protocol message being used to enable the second network device to determine that it has completed IPSec SA negotiation with the first network device; Wherein, the second SA attribute is the SA attribute supported by the second network device selected by the second network device from the first SA attribute; the second VPN SID is the VPN SID configured in the routing table of the first VPN instance.

4. The method according to claim 3, characterized in that, Both the first IKE protocol message and the second IKE protocol message include a client initiator identifier and a client responder identifier, respectively; The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

5. The method according to claim 3, characterized in that, After sending the third IKE protocol message to the second network device, the method further includes: The mapping relationship between the negotiated IPSec SA identifier and the first VPN SID is stored in the encrypted mapping table entry.

6. A communication device, characterized in that, The device is applied to a first network device, the first network device including a first interface, the device comprising: The determining unit, when receiving a first service message sent by a first user-side device through the first interface, determines a first VPN instance bound to the first interface based on the first interface. The first acquisition unit is used to acquire the corresponding first VPN SID from the routing table of the first VPN instance; An encapsulation unit is configured to perform SRv6 encapsulation processing on the first service packet when it is determined that the first service packet is forwarded through an SRv6 path, to obtain a second service packet. The second service packet includes a SID list indicating the SRv6 forwarding path and the first service packet. The second acquisition unit is configured to acquire the IPSec SA identifier from the encryption mapping table entry if the first VPN SID exists in the SID list and an encryption mapping table entry matching the first VPN SID exists in the local encryption mapping table. An encryption unit is used to encrypt the first service packet included in the second service packet by using the IPSec SA identifier corresponding to the IPSec SA to obtain a third service packet, wherein the third service packet includes the SID list and the encrypted first service packet; The sending unit is configured to forward the third service packet to the next-hop network device via the SRv6 path, so that the next-hop network device forwards the third service packet to the second network device. The first network device has established the SRv6 path and IPSec tunnel with the second network device.

7. The apparatus according to claim 6, characterized in that, The device further includes: The receiving unit is configured to receive a first BGP protocol message sent by the second network device. The first BGP protocol message includes a host address, an RT identifier, a first VPN SID configured in the routing table of the second VPN instance in the second network device indicated by the RT identifier, and the address of the second network device. The determining unit is configured to traverse local Import RTs based on the RT identifier, and determine the Import RT that is the same as the RT identifier from the local Import RTs, wherein the determined Import RT indicates the first VPN instance; The generation unit is configured to generate a host route to the host indicated by the host address in the routing table of the first VPN instance, wherein the host route includes the host address and the address of the second network device; A storage unit is used to store the first VPN SID in the routing table of the first VPN instance; The first BGP protocol message is sent by the second network device after receiving the second BGP protocol message sent by the second user-side device. The second BGP protocol message includes the host address and the RT identifier.

8. The apparatus according to claim 7, characterized in that, The sending unit is further configured to send a first IKE protocol message to the second network device, the first IKE protocol message including a first SA attribute supported by the first network device, the first VPN SID and the second VPN SID; The receiving unit is further configured to receive a second IKE protocol message sent by the second network device, the second IKE protocol message including a second SA attribute supported by the second network device, the first VPN SID and the second VPN SID; The sending unit is further configured to send a third IKE protocol message to the second network device, the third IKE protocol message being used to enable the second network device to determine that it has completed IPSec SA negotiation with the first network device. Wherein, the second SA attribute is the SA attribute supported by the second network device selected by the second network device from the first SA attribute; the second VPN SID is the VPN SID configured in the routing table of the first VPN instance.

9. The apparatus according to claim 8, characterized in that, Both the first IKE protocol message and the second IKE protocol message include a client initiator identifier and a client responder identifier, respectively; The client initiator identifier carries the second VPN SID, and the client responder identifier carries the first VPN SID.

10. The apparatus according to claim 8, characterized in that, The storage unit is further configured to store the mapping relationship between the negotiated IPSecSA identifier and the first VPN SID in the encrypted mapping table entry.

Images