NFV access method, device, system and storage medium

Abstract

The present application provides an NFV access method, device, system, and storage medium. In the present application, a gateway device is provided between a client VPC and a service VPC to intercept data packets from a client instance in the client VPC requesting access to an NFV instance in the service VPC, perform two-layer tunnel encapsulation on the data packets, encapsulate the tenant information of the client instance as inner-layer tunnel information in the inner layer, and present the data packets to the outside world as a gateway device. This allows the virtual switch where the NFV instance is located to no longer process the inner-layer tunnel information, making the tenant information of the client instance invisible. User access to the NFV instance is no longer restricted by the access resource specifications such as the virtual network card supported by the virtual switch, allowing more users to access the NFV instance and achieving a larger-scale NFV instance.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to an NFV access method, device, system, and storage medium. Background Art

[0002] Network Function Virtualization (NFV) is a network service virtualization technology that decouples the software functions and hardware platforms of network devices to avoid supply binding. At the same time, because the iteration efficiency of software functions is higher, NFV technology has developed rapidly.

[0003] Since the rise of cloud computing, NFV technology has become a foundational technology for building cloud computing networks, driven by the need for rapid iteration. To date, NFV technology in cloud networks has evolved through two generations. The first generation was built using physical servers, with NFV network elements deployed on them. However, because the supply of physical servers was still constrained by the hardware supply cycle, NFV technology has gradually evolved to the second generation, based on cloud-native resources. NFV network elements are no longer deployed on physical servers, but on various cloud computing instances. Leveraging the massive availability of cloud computing resources, NFV network elements are built on demand and readily available, achieving elastic optimization.

[0004] However, currently, when NFV network elements on the cloud use cloud computing instances as carriers, they are subject to certain constraints in terms of user access. They can only connect to a limited number of users and cannot achieve larger-scale NFV network elements. Summary of the Invention

[0005] Multiple aspects of the present application provide an NFV access method, device, system, and storage medium to solve the user access problem of NFV network elements on the cloud, allowing more users to access and realize larger-scale NFV network elements.

[0006] An embodiment of the present application provides an NFV access system, comprising: a first gateway device interconnected between a client virtual private cloud (VPC) and a service VPC; the client VPC comprises a client instance and a first virtual switch (VS) that provides data forwarding services for the client instance, and the service VPC comprises an NFV instance that carries an NFV network element and a second VS that provides data forwarding services for the NFV instance; the first gateway device is configured to intercept data packets from the client instance accessing the NFV instance via the first VS, perform inner tunnel encapsulation on the data packets using tenant information to which the client instance belongs as inner tunnel information, perform outer tunnel encapsulation on the packets encapsulated through the inner tunnel using identity information of the first gateway device, and send the packets encapsulated through the outer tunnel to the second VS, so that the second VS forwards the packets to the NFV instance to achieve access to the NFV instance.

[0007] An embodiment of the present application also provides an NFV access method, which is applied to a first gateway device. The method includes: intercepting a data packet of a client instance accessing an NFV instance via a first virtual switch VS; performing an inner tunnel encapsulation on the data packet using the tenant information to which the client instance belongs as inner tunnel information; performing an outer tunnel encapsulation on the packet encapsulated by the inner tunnel using the identity information of the first gateway device; and sending the packet encapsulated by the outer tunnel to a second VS corresponding to the NFV instance, so that the second VS forwards it to the NFV instance to achieve access to the NFV instance.

[0008] An embodiment of the present application also provides an NFV access method, which is applied to a second gateway device, and the method includes: receiving a first tunnel message sent by a first virtual switch VS, where the first tunnel message is obtained by the first VS performing tunnel encapsulation on a data message of a client instance accessing an NFV instance, and the tunnel information of the first tunnel message includes tenant information to which the client instance belongs; re-encapsulating the first tunnel message into a second tunnel message, and sending the second tunnel message and the tenant information to which the client instance belongs to the first gateway device, so that the first gateway device uses the tenant information to which the client instance belongs as inner tunnel information to perform inner tunnel encapsulation on the data message, and uses the identity information of the first gateway device to perform outer tunnel encapsulation on the message after the inner tunnel encapsulation, and then forwards it to the NFV instance through the second VS to realize access to the NFV instance.

[0009] An embodiment of the present application provides a gateway device, comprising: a memory and a processor, the memory being used to store a computer program; the processor being coupled to the memory and being used to execute the computer program, causing the processor to implement the steps in the NFV access method executed by the first gateway device, or the steps in the NFV access method executed by the second gateway device.

[0010] An embodiment of the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor implements the steps in the NFV access method executed by the first gateway device, or the steps in the NFV access method executed by the second gateway device.

[0011] In an embodiment of the present application, a gateway device is set between the client VPC and the service VPC, which is responsible for intercepting data packets from the client instance in the client VPC requesting access to the NFV instance in the service VPC, and performing two-layer tunnel encapsulation on the data packets, encapsulating the tenant information to which the client instance belongs as the inner tunnel information into the inner layer, and presenting it to the outside in a unified manner as a gateway device. This allows the virtual switch where the NFV instance is located to no longer process the inner tunnel information, and the tenant information to which the client instance belongs cannot be seen. User access to the NFV instance is no longer restricted by the access resource specifications such as the virtual network card supported by the virtual switch, allowing more users to access the NFV instance and realize larger-scale NFV instances. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0013] Figure 1 This is a schematic diagram of the structure of an NFV system based on cloud native resources;

[0014] Figure 2 A schematic diagram of the structure of an NFV access system provided in an embodiment of the present application;

[0015] Figure 3 A schematic diagram of the structure of another NFV access system provided in an embodiment of the present application;

[0016] Figure 4 A schematic diagram of an application scenario of an NFV access system provided by an exemplary embodiment of the present application;

[0017] Figure 5 A flowchart of an NFV access method provided in an embodiment of the present application;

[0018] Figure 6A flowchart of another NFV access method provided in an embodiment of the present application;

[0019] Figure 7 A schematic diagram of the structure of an NFV access device provided in an embodiment of the present application;

[0020] Figure 8 A schematic diagram of the structure of another NFV access device provided in an embodiment of the present application;

[0021] Figure 9 A schematic diagram of the structure of a gateway device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] Figure 1 This is a structural diagram of an NFV system based on cloud native resources. Figure 1 As shown, the system includes: multiple VPCs; VPC is a logically isolated network environment built on a physical network using virtualization technology. Among them, the physical network includes various physical resources, such as physical machines, switches or gateways. One or more VPCs can be deployed on the physical resources in a region, and the same VPC is usually deployed in one region. In this embodiment, service instances are deployed in each VPC, and these service instances can access each other. In the embodiment of the present application, the VPC is divided from the perspective of the service instance, and multiple VPCs are divided into client VPC11 and service VPC12. Among them, the client VPC11 can be one or more, and the service VPC12 can be one or more. Each client VPC11 belongs to a tenant, and different client VPC11 can belong to the same tenant or different tenants, and there is no limitation on this.

[0024] In various embodiments of the present application, service VPC 12 refers to a VPC capable of providing NFV network elements based on cloud-native resources. This VPC includes at least one NFV network element, such as a server load balancing (SLB), a network address translation (NAT), and a transit router (TR). These NFV network elements are hosted on a cloud computing instance. For ease of description and distinction, the cloud computing instance hosting the NFV network elements in service VPC 12 is referred to as an NFV instance. In this embodiment, an NFV instance represents the NFV network element hosted on the NFV instance. NFV instances can be various cloud computing instances, such as virtual machines (VMs), containers, bare metal servers, Elastic Compute Services (ECSs), or field programmable gate array (FPGA)-based cloud computing services. Cloud computing instances of different specifications can be used to provide different types of NFV network elements. For example, a seven-layer SLB requires higher computing power, so a computing-type ECS can be used as the carrier, while a four-layer SLB requires higher forwarding throughput, so a network-type ECS can be used as the carrier.

[0025] In each embodiment of the present application, client VPC 11 refers to a VPC that provides client instances. Client instances within this VPC are cloud computing instances that require services provided by NFV network elements, and may include, but are not limited to, VMs, ECSs, service modules, or application instances. Each client VPC 11 includes at least one client instance, hosted on one or more physical machines. Each physical machine is also deployed with a virtual switch (VS) that provides data forwarding services for the client instances on that physical machine. Accordingly, service VPC 12 includes at least one NFV instance, with one or more instances of the same type hosted on one or more physical machines. Each physical machine is also deployed with a VS that provides data forwarding services for the NFV instances on that physical machine. Specifically, the VS may employ an Open Virtual Switch (OVS). For ease of distinction and description, the VS that provides data forwarding services for client instances in client VPC 11 is referred to as a first VS, and the VS that provides data forwarding services for NFV instances in service VPC 12 is referred to as a second VS.

[0026] In this embodiment, the basic functions of the NFV instance include high availability of Equal Cost Multi-path (ECMP) and multi-tenant access. Figure 1 In the system shown, the ECMP capability of the NFV instance opens up the network connectivity between the tenants on the cloud and the NFV instance through the ENI-bonding technology, that is, an elastic network interface (ENI) is deployed in each client VPC11. The ENI has a private IP address, and the ENI can be mounted on the NFV instance. The NFV instance is represented by the private IP address of the ENI and the port number of the NFV instance, so that the client instance in the client VPC11 can access the NFV instance through the ENI. Among them, the ENIs mounted on the same NVF instance in different client VPC11 can have the same private IP address or different private IP addresses, and there is no limitation on this. In this embodiment, different ENIs represent different tenants, and there is a one-to-one correspondence between ENIs and tenants.

[0027] exist Figure 1 In the system shown, multi-tenant access uses ENI-Trunking technology to add different Virtual Local Area Network (VLAN) tags (TAGs) to traffic from different ENIs (traffic from different ENIs represents traffic from different tenants) when forwarding it to the NFV instance. That is, different tenants are identified by different VLAN tags to achieve isolation between tenants.

[0028] exist Figure 1 In the system shown, the NFV access or access process based on the above ENI-bonding and ENI-Trunking technologies is as follows:

[0029] When a client instance in the client VPC requests access to an NFV instance in the service VPC, the data packet first arrives at the VS where the client instance resides (i.e., the first VS). Based on pre-configured routing information, the first VS forwards the data packet to the VS where the NFV instance resides (i.e., the second VS). When the data packet arrives at the second VS where the NFV instance resides, the second VS determines whether multiple NFV instances can jointly process the data packet. If so, it uses a hash algorithm to select a target path from the multiple paths and forwards the data packet to the corresponding NFV instance for processing. If a path or an NFV instance fails, the path is automatically deleted, thereby achieving ECMP high availability. This process is called ENI-Bonding.

[0030] Among them, the general forwarding process after selecting the target path is: first determine whether the data packet is the first data packet in a data flow. If so, the CPU of the second VS performs software forwarding processing and establishes the session information of the data flow. The session information records the five-tuple and egress port information of the data flow. The egress port information corresponds to the destination NFV instance. Subsequent data packets in the data flow can be directly forwarded to the destination NFV instance by directly searching the established session information.

[0031] In the above process, there may be multiple client instances of different tenants requesting to access the same NFV instance, and the data packets of different tenants come from different ENIs, such as Figure 1 As shown in , the second VS will receive data packets from different ENIs; further, in order to allow the NFV instance to distinguish data packets from different tenants, the second VS will map the source VPC ID in the data packet to a VLAN ID, such as Figure 1 As shown in Figure 1, different VLAN IDs are used to distinguish data packets from different tenants. This process is called ENI-Trunking. The number of ENIs supported by the second VS determines the number of VLANs, which in turn determines the number of different tenants that the NFV instance can access.

[0032] The preceding data packet processing process shows that packets from the client instance to the NFV instance must be processed by the second VS. The network IO capability of the second VS directly affects the number of tenants that the NFV network element can access. The network IO capability of the second VS mainly refers to the ENI specifications and session specifications that the second VS can support. Since cloud computing instances are developed for IT-type applications, which are computing applications with high requirements for central processing units (CPUs) and memory resources but low network communication needs, cloud computing instances primarily match computing applications. Therefore, the VSs that provide data forwarding services for cloud computing instances support relatively low ENI and session specifications. Currently, mainstream VSs support only dozens of ENIs and around one million sessions. Even the VSs with the highest network capabilities only support around 1,000 ENIs and 10 million sessions. Actual NFV instances can handle tens of thousands of users and hundreds of millions of flows (sessions). Therefore, the gap between the network I / O capabilities of the VS and the capabilities of the NFV instance can reach 10 or even 100 times. This seriously constrains the NFV instance, resulting in resource waste and limiting the user access specifications of the NFV instance.

[0033] In view of the above problems, the present invention provides a new NFV access system. Figure 2 As shown, the NFV access system includes: client VPC 21, service VPC 22, and a first gateway device 23 interconnected between client VPC 21 and service VPC 22. The description of client VPC 21 and service VPC 22 is the same as that of client VPC 11 and service VPC 12 in the previous embodiment and will not be repeated here.

[0034] In this embodiment, the client VPC 21 includes at least a client instance, a first VS that can provide data forwarding services for the client instance, and an ENI of the NFV instance mounted on the service VPC 22; wherein the client instance can initiate access to the NFV instance through the ENI mounted on the NFV instance, and the data packet accessing the NFV instance is forwarded to the NFV instance via the first VS. The process of the client instance accessing the NFV instance in this embodiment is similar to Figure 1 The access process in the illustrated system is different. In this embodiment, the data packet from the client instance accessing the NFV instance via the first VS no longer directly travels from the first VS to the second VS. Instead, the first gateway device 23 intercepts the data packet from the client instance accessing the NFV instance via the first VS. After intercepting the data packet, the first gateway device 23 performs inner tunnel encapsulation on the data packet using the tenant information of the client instance as the inner tunnel information. The first gateway device 23 then performs outer tunnel encapsulation on the packet after the inner tunnel encapsulation using the identity information of the first gateway device. The packet after the inner tunnel encapsulation is then sent to the second VS, which forwards it to the NFV instance, thereby enabling access to the NFV instance. The tenant information of the client instance can be any information that uniquely identifies the tenant to which the client instance belongs, such as, but not limited to, the ID of the client VPC or the ID of the tenant to which the client instance belongs.

[0035] In this embodiment, a first gateway device is set between the client VPC and the service VPC, which is responsible for intercepting the data message of the client instance requesting access to the NFV instance, and performing two-layer tunnel encapsulation on the data message, encapsulating the tenant information of the client instance as the inner tunnel information into the inner layer, and presenting it to the outside in a unified manner as the first gateway device. This allows the second VS where the NFV instance is located to no longer process the inner tunnel information, and the tenant information of the client instance is invisible. User access to the NFV instance is no longer restricted by the ENI specifications supported by the second VS, allowing more tenants to access the NFV instance and realize larger-scale NFV instances.

[0036] In the embodiment of the present application, the implementation method of the first gateway device is not limited, and the method of intercepting the data packet of the client instance accessing the NFV instance through the first VS may also vary depending on the implementation method of the first gateway device. The following examples illustrate:

[0037] In an optional embodiment A1, each client VPC is associated with a traditional gateway device. For ease of distinction, this traditional gateway device is referred to as a VPC gateway device (VGW). The VGW is responsible for maintaining and distributing routing information corresponding to each client instance in the client VPC. In a traditional solution, when a data packet from a client instance arrives at the first VS, the first VS determines whether the routing information corresponding to the data packet exists locally. If not, the data packet is sent to the VGW. The VGW forwards the data packet based on pre-maintained routing information and distributes the routing information corresponding to the data packet to the first VS. The first VS then forwards subsequent packets based on the distributed routing information. In this embodiment, the VGW associated with the client VPC can be functionally improved to implement a new gateway device, namely the first gateway device. In this embodiment, the VGW is improved with respect to forwarding functionality for accessing NFV instances. All data packets accessing NFV instances are uniformly forwarded by the VGW, and the VGW no longer distributes routing information required to access the NFV instance to the first VS.

[0038] Based on the above, when a client instance accesses an NFV instance, it can send a data packet to the first VS via the ENI corresponding to the NFV instance. The first VS tunnel-encapsulates the data packet sent by the client instance to obtain a first tunnel message. In this embodiment, the tunnel information in various tunnel messages includes at least a source address, a destination address, and a virtual network identifier (VNI). The source address indicates the source end of the tunnel, the destination address indicates the destination end of the tunnel, and the VNI information is a network identifier that can be used to represent different information in different tunnel messages. In the tunnel information of the first tunnel message, the source address is the IP address of the first VS, the destination address is the IP address of the first gateway device, and the VNI information indicates the tenant information to which the client instance belongs.

[0039] Because the first VS does not have the routing information corresponding to the client instance locally, the first VS sends the first tunnel message to the first gateway device, namely the VGW. The first gateway device, namely the VGW, receives the first tunnel message sent by the first VS. The action of receiving the first tunnel message can be considered as intercepting the data message of the client instance accessing the NFV instance through the first VS. After receiving the first tunnel message, it does not forward the message like a traditional VGW. Instead, it obtains the tenant information of the client instance from the tunnel information of the first tunnel message, uses the tenant information of the client instance as the inner tunnel information to perform inner tunnel encapsulation on the data message, and uses the identity information of the first gateway device to perform outer tunnel encapsulation on the message after the inner tunnel encapsulation. The message after the outer tunnel encapsulation is sent to the second VS, so that the second VS forwards it to the NFV instance, thereby achieving access to the NFV instance. In this embodiment, the first gateway device is an improved VGW.

[0040] In another optional embodiment A2, the first gateway device may be a newly added gateway device, which is mainly responsible for intercepting and encapsulating two-layer tunnels for data packets from the client instance to the NFV instance, and may be called an NFV gateway device (ie, NFV-GW). Figure 3 As shown, the NVF access system also includes: a second gateway device 24, which is a traditional gateway device associated with the client VPC. For the sake of distinction, the traditional gateway device is called a VPC gateway device (VGW). Figure 3 In the figure, the second gateway device is VGW and the first gateway device is NFV-GW. It should be noted that there can be a one-to-one correspondence between the client VPC and the second gateway device 24 (ie, one client VPC is associated with one second gateway device 24, such as Figure 4 As shown), it can also be a many-to-one relationship (ie, multiple client VPCs are associated with the same second gateway device 24, such as Figure 3 As shown in the figure, the second gateway device (i.e., VGW) is interconnected with the first VS and the first gateway device (i.e., NFV-GW). The first gateway device (i.e., NFV-GW) is also interconnected with the second VS. In this embodiment, not only is a first gateway device added, but the second gateway device is also functionally improved. The second gateway device cooperates with the first VS to assist the first gateway device in intercepting data packets from the client instance to the NFV instance when the client instance accesses the NFV instance.

[0041] Based on the above, when a client instance accesses an NFV instance, it can send a data packet to the first VS via the ENI corresponding to the NFV instance. The first VS tunnel-encapsulates the data packet sent by the client instance to generate a first tunnel message. A description of the first tunnel message is provided above and will not be repeated here. Since the first VS does not have local routing information corresponding to the client instance, it sends the first tunnel message to the second gateway device, namely, the VGW.

[0042] The second gateway device, i.e., the VGW, receives the first tunnel message sent by the first VS, obtains the tenant information of the client instance from the tunnel information in the first tunnel message, re-encapsulates the first tunnel message into a second tunnel message, and sends the second tunnel message and the tenant information of the client instance to the first gateway device, i.e., the NFV-GW. In this embodiment, the second gateway device does not send the routing information required to access the NFV instance to the first VS. All data messages accessing the NFV instance are forwarded and processed by the second gateway device and the first gateway device. The tunnel information in the second tunnel message includes at least the source address, destination address, and VNI information. The source address is the IP address of the second network device (i.e., the VGW), the destination address is the IP address of the first gateway device, and the VNI information is the tenant information of the client instance. In this embodiment, the manner in which the second gateway device (i.e., VGW) sends the tenant information to which the client instance belongs to the first gateway device (i.e., NFV-GW) is not limited. For example, the tenant information to which the client instance belongs can be sent to the first gateway device (i.e., NFV-GW) through the VNI information in the tunnel information of the second tunnel message, or the tenant information to which the client instance belongs can be sent to the first gateway device (i.e., NFV-GW) through a control plane message.

[0043] The first gateway device (i.e., NFV-GW) can receive the second tunnel message and tenant information of the client instance sent by the second gateway device (i.e., VGW). The action of receiving the second tunnel message can be considered as intercepting the data message of the client instance accessing the NFV instance via the first VS. Based on this, after receiving the second tunnel message, the first gateway device can parse the data message from it, and use the tenant information of the client instance as the inner tunnel information to perform an inner tunnel encapsulation on the data message. The message after the inner tunnel encapsulation is then performed an outer tunnel encapsulation on the message with the identity information of the first gateway device, and the message after the outer tunnel encapsulation is sent to the second VS, so that the second VS forwards it to the NFV instance, thereby achieving access to the NFV instance. In this embodiment, the first gateway device is an NFV-GW, which is different from the improved VGW.

[0044] Regardless of which of the above implementation methods is adopted by the first gateway device, a method in which the first gateway device uses the tenant information of the client instance as the inner tunnel information to perform inner tunnel encapsulation on the data message includes: using the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information respectively, and using the tenant information of the client instance as the VNI information of the inner tunnel information, and performing inner tunnel encapsulation on the data message. Correspondingly, a method in which the first gateway device uses the identity information of the first gateway device to perform outer tunnel encapsulation on the message after the inner tunnel encapsulation includes: using the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer tunnel information, and using the identification information of the first gateway device as the VNI information of the outer tunnel information, and performing outer tunnel encapsulation on the message after the inner tunnel encapsulation.

[0045] Further optionally, both the inner tunnel encapsulation and the outer tunnel encapsulation described above may use, but are not limited to, the following tunnel protocols: Generic Network Virtualization Encapsulation (GENEVE), Virtual Extensible Local Area Network (VXLAN), or Segment Routing IPv6 (SRv6). The tunnel protocols used by the inner tunnel encapsulation and the outer tunnel encapsulation may be the same or different, and this is not limited.

[0046] In some optional embodiments, in order to reduce the intrusion of the first gateway device (i.e., NFV-GW) into the client instance, the ENI of the cloud computing instance can be simulated for the first gateway device, that is, a simulated ENI is configured for the first gateway device, and the simulated ENI can also be called fake-ENI. The MAC address corresponding to the fake-ENI is configured on the first VS to implement the encapsulation of the tenant information by the first gateway device through the fake-ENI, that is, the identification information of the first gateway device can be the simulated ENI information of the first gateway device. Based on this, combined with Figure 3 The detailed access process of the NFV instance provided in the embodiment of the present application is as follows:

[0047] Specifically, to reduce modifications to the tenant side, the functionality of the client instance remains unchanged. When the client instance needs to access the NFV instance, it sends a data packet normally. When the data packet arrives at the first VS, the first VS searches the local routing table and finds that there is no routing information corresponding to the data packet. It then forwards the data packet to the VGW corresponding to the client's VPC. Specifically, the first VS tunnel-encapsulates the data packet based on the MAC address corresponding to the locally configured fake-ENI, obtaining a first tunnel packet with the source address being the IP address of the first VS and the destination address being the IP address of the VGW. The first tunnel packet is sent to the VGW. The VNI field in the first tunnel packet carries the tenant information to which the client instance belongs. In addition, the first tunnel packet also carries the MAC address corresponding to the fake-ENI. In this embodiment, the VGW does not send routing information to the first VS. As a result, all data packets sent from the client instance to the NFV instance are sent to the VGW.

[0048] The VGW locally pre-configures a specific forwarding table entry for accessing the NFV instance. The next hop in the forwarding table entry points to the NFV-GW, so that all data packets accessing the NFV instance will be forwarded to the NFV-GW. Specifically, the VGW parses the data packet from the first tunnel packet and re-encapsulates the data packet through the tunnel to obtain a second tunnel packet with the source address being the IP address of the VGW and the destination address being the NFV-GW. The second tunnel packet is then sent to the NFV-GW. It is noted that data packets accessing other cloud computing instances or other service VPCs can be processed according to traditional processes and are not limited to this. The VGW can also send tenant information to the NFV-GW via a control plane message.

[0049] After receiving the second tunnel message, the NFV-GW parses the data message from it and performs two layers of tunnel encapsulation on the data message, namely, inner tunnel encapsulation and outer tunnel encapsulation. The inner tunnel encapsulation is used to encapsulate the tenant information to which the client instance belongs, and the outer tunnel encapsulation is used to encapsulate the tunnel information required to forward the data message. In this embodiment, the tunnel technology used for tunnel encapsulation is not limited. For example, whether it is inner tunnel encapsulation or outer tunnel encapsulation, it can adopt but is not limited to: GENEVE, VXLAN or SRv6. Any tunnel protocol that can identify multiple tenants is applicable to the embodiment of this application. The source address of the inner tunnel information is the IP address of the NFV-GW, the destination address is the IP address of the NFV instance to be accessed, and the inner VNI information is the tenant information to which the client instance belongs; the source address of the outer tunnel information is the IP address of the NFV-GW, the destination address is the IP address of the second VS, and the outer VNI information is the fake-ENI of the NFV-GW.

[0050] In this embodiment, the NFV-GW uses fake-ENI to implement ENI-bonding with the second VS. Specifically, the second VS allocates an interface bound to the fake-ENI to the NFV-GW, facilitating communication between the two. For ease of description, this interface is referred to as the ENI-bonding interface. Based on this, the NFV-GW sends packets encapsulated through both the inner and outer tunnels to the second VS via the ENI-bonding interface between it and the second VS. The second VS then processes the packets encapsulated through both tunnels.

[0051] The second VS only processes the outer tunnel information and determines whether the message is the first message of the data flow based on the outer tunnel information. If so, the CPU of the second VS performs software forwarding processing and establishes a forwarding session (session) for the data flow. The session records the five-tuple of the data flow (the five-tuple is the five-tuple in the outer tunnel information) and the egress port information. The egress port information corresponds to the destination NFV instance. Subsequent messages in the data flow search for the established session information and forward them directly to the destination NFV instance.

[0052] In this embodiment, an NFV-GW is added. This NFV-GW cooperates with the VGW associated with the client VPC to encapsulate the tenant information of the client instance into the inner layer by adding a layer of tunnel encapsulation. From the perspective of the second VS, it sees the fake ENI corresponding to the NFV-GW and no longer processes the inner tunnel information. Therefore, even if ENI-bonding technology is used, the second VS only needs one ENI and one VLAN ID. The session information only records the five-tuple corresponding to the outer tunnel, and this five-tuple remains unchanged throughout the access process. This significantly reduces the requirements of different tenants for the ENI and session specifications supported by the second VS when accessing the NFV instance, effectively solving the constraints of the second VS on ENI and session specifications. From the perspective of the NFV instance, because the second VS only sees the NFV-GW, it presents a single tenant and a single flow, effectively solving the problem of the NFV instance being constrained by the network IO capabilities of the second VS and facilitating the NFV instance to connect to more users.

[0053] The following combination Figure 4 The application scenario and system architecture shown, and Figure 4 The message encapsulation process shown in FIG is used to describe in detail the NFV access process provided in the embodiment of the present application:

[0054] exist Figure 4In this example, two client VPCs are used. Each client VPC includes a client ECS and a first VS, and each client VPC is connected to a VGW. The two client VPCs are designated as the first client VPC and the second client VPC, and the two VGWs are designated as the first VGW and the second VGW, respectively. The two VGWs are interconnected with the NFV-GW. The NFV-GW is connected to two service VPCs, each of which includes an NFV ECS and a second VS. The two service VPCs are designated as the first service VPC and the second service VPC, respectively. The NFV ECS in the second service VPC is implemented based on the ECS, and the NFV ECS in the first service VPC is implemented based on an FPGA, but these are not limited to these. The client ECS is used as an example for client instances. Similarly, the NFV ECS is the ECS that carries NFV network elements, and is used as an example for NFV instances.

[0055] To maintain compatibility with ENIs and maintain the processing logic of the first VS, the NFV-GW uses a simulated ENI, or fake-ENI, deployed in each client VPC. This fake-ENI points to the NFV-GW. The NFV-GW can have different fake-ENIs, each corresponding to an NFV ECS in a different service VPC, to implement ECMP.

[0056] The client ECS sends a data packet to access the NFV ECS, such as Figure 4 As shown, the message format of the data message includes: a payload part, a TCP / UDP packet header, IP packet header information (IP hdr) and Ethernet packet header information (Ethhdr), and the data message arrives at the first VS.

[0057] The first VS performs tunnel encapsulation to obtain the first tunnel message, such as Figure 4 As shown, the message format of the first tunnel message includes: a payload part, a TCP / UDP header, an IP header information (IP hdr), VXLAN tunnel information (tunnel encapsulation takes VXLAN as an example, but is not limited to this), a MAC address corresponding to the fake-ENI, and an Ethernet header information (Eth hdr). The first tunnel message arrives at the first or second VGW. Among them, the first VS is pre-configured with a MAC address corresponding to the fake-ENI, but the identifier (ID) of the fake-ENI cannot be determined. The source address of the VXLAN tunnel information is the IP address of the first VS, the destination address is the IP address of the first or second VGW, and the VNI information is the tenant information to which the client ECS belongs.

[0058] The first or second VGW parses the data message from the first tunnel message and re-encapsulates the data message into a tunnel to obtain a second tunnel message. Figure 4 As shown, the message format of the second tunnel message includes: a payload, a TCP / UDP header, an IP header (IP HDR), the MAC address corresponding to the fake-ENI, VXLAN tunnel information (Tunnel encapsulation uses VXLAN as an example, but is not limited to this), and Ethernet header information (Eth HDR). The second tunnel message reaches the NFV-GW. The source address of the VXLAN tunnel information is the IP address of the first or second VGW, the destination address is the IP address of the NFV-GW, and the VNI information is the tenant information to which the client ECS belongs.

[0059] A MAC-fake-ENI conversion table is configured on the NFV-GW. The fake-ENI ID corresponding to the MAC address is recorded in the forwarding table. Figure 4 In the figure, the fake-ENI ID corresponding to MAC address 0:0:0:0:0:1 is 1, and the fake-ENI ID corresponding to MAC address 0:0:0:0:0:2 is 2. The NFV-GW is also configured with a fake-ENI ECMP table, which records the NFV ECS corresponding to different fake-ENI IDs. Figure 4 In the diagram, the ECMP table records fake-ENI ID 1 corresponding to ECS IP 1 and fake-ENI ID 2 corresponding to FPGA IP 2 as an example. ECS IP 1 represents the NFV ECS implemented based on ECS in the second service VPC, and FPGA IP 2 represents the NFV ECS implemented based on FPGA in the first service VPC.

[0060] In addition, a fake-ENI forwarding table is also configured on the NFV-GW, in which the export encapsulation information corresponding to different fake-ENI IDs is recorded. Figure 4 In the figure, the forwarding table records that fake-ENI ID 1 corresponds to the first VGW using VXLAN for tunnel encapsulation, and fake-ENI ID 2 corresponds to the first VGW using VXLAN for tunnel encapsulation. Figure 4 The forwarding table shown in the table refers to the tunnel protocol used by the outer tunnel encapsulation. The tunnel protocol used by the inner tunnel encapsulation is not shown in the table and can be recorded in other ways or by using a default protocol. In the embodiment of the present application, the inner tunnel encapsulation uses the GENEVE protocol as an example.

[0061] In addition, a fake-ENI IP address mapping table is also configured on the NFV-GW, in which the IP address information of the NFV ECS and the second VS corresponding to different fake-ENI IDs is recorded. Figure 4 In the example, the mapping table records that fake-ENI ID 1 corresponds to the IP address of the second VS in the second service VPC is 1.1.1.1, and the IP address of the NFV ECS (i.e., ECSIP1) is 2.1.1.1; fake-ENI ID 2 corresponds to the IP address of the second VS in the first service VPC is 1.2.2.2, and the IP address of the NFV ECS (i.e., FPGA IP2) is 2.2.2.2.

[0062] It is noted here that the above four information tables can be implemented as one information table, or two or three information tables. In addition to the information table method, other methods that can record the above correspondence or mapping relationships can also be used, and there is no limitation on this.

[0063] Based on the above correspondence or mapping relationship, NFV-GW can query the MAC-fake-ENI conversion table according to the MAC address corresponding to the fake-ENI contained in the second tunnel message to obtain the fake-ENI ID corresponding to the MAC address to implement ECMP; then, according to the determined fake-ENI ID, query the fake-ENI ECMP table, fake-ENI forwarding table and fake-ENI IP address mapping table to determine the corresponding tunnel encapsulation information and the IP address of the corresponding NFV ECS and the IP address of the corresponding second VS, and complete the inner and outer two-layer tunnel encapsulation based on this information to obtain the third tunnel message. Figure 4As shown, the message format obtained after inner tunnel encapsulation includes: payload, TCP / UDP header, IP header information (IP hdr), GENEVE tunnel information (inner tunnel information), and Ethernet header information (Eth hdr). Further encapsulation through the outer tunnel results in a third tunnel message with a message format including: payload, TCP / UDP header, IP header information (IP hdr), GENEVE tunnel information (inner tunnel information), VXLAN tunnel information (outer tunnel information), and Ethernet header information (Eth hdr). This third tunnel message arrives at the second VS. The source address of the VXLAN tunnel information is the IP address of the NFV-GW, the destination address is the IP address information of the second VS in the IP address mapping table of the fake-ENI, and the VNI information is the VNI corresponding to the NFV-GW; accordingly, the source address of the GENEVE tunnel information is the IP address of the NFV-GW, the destination address is the IP address of the NFV ECS in the IP address mapping table of the fake-ENI, and the VNI information is the tenant information to which the client ECS belongs.

[0064] After removing the outer tunnel information, the second VS sends the message to the corresponding NFV ECS. The NFV ECS can determine the tenant information of the client ECS that initiates the access request based on the GENEVE tunnel information and process the message according to the NFV service provided by the NFV ECS.

[0065] In this embodiment, an NFV-GW is added to cooperate with the VGW to guide the tenant's traffic to the NFV-GW without affecting the tenant side. An additional layer of tunnel encapsulation is added to encapsulate information such as tenant identification in the tunnel. The VS of the NFV ECS is presented with a single user and a single flow. This can effectively solve the problem of NFV ECS being constrained by the VS network IO capability, increase the number of tenants accessed by the NFV ECS, and facilitate the realization of a larger-scale NFV ECS.

[0066] Figure 5 A flow chart of an NFV access method provided in an embodiment of the present application. The method is applied to a first gateway device, such as Figure 5 As shown, the method includes:

[0067] 501. Intercept a data packet from a client instance accessing an NFV instance via a first virtual switch VS;

[0068] 502. Perform inner tunnel encapsulation on the data message using the tenant information to which the client instance belongs as inner tunnel information;

[0069] 503. Perform outer tunnel encapsulation on the message encapsulated by the inner tunnel using the identity information of the first gateway device;

[0070] 504. Send the message encapsulated by the outer tunnel to the second VS corresponding to the NFV instance, so that the second VS forwards it to the NFV instance, thereby achieving access to the NFV instance.

[0071] In an optional embodiment, the above-mentioned interception of the data packet of the client instance accessing the NFV instance through the first virtual switch VS includes: receiving a first tunnel packet sent by the first VS, the first tunnel packet is obtained by the first VS performing tunnel encapsulation on the data packet, and the tunnel information of the first tunnel packet includes the tenant information to which the client instance belongs.

[0072] In an optional embodiment, the above-mentioned interception of the data packet of the client instance accessing the NFV instance through the first virtual switch VS includes: receiving a second tunnel packet sent by the second gateway device and the tenant information to which the client instance belongs, the second tunnel packet is obtained by the second gateway device performing tunnel encapsulation on the first tunnel packet, the first tunnel packet is obtained by the first VS performing tunnel encapsulation on the data packet, and the tunnel information of the first tunnel packet includes the tenant information to which the client instance belongs.

[0073] In an optional embodiment, the above-mentioned inner tunnel encapsulation of the data packet using the tenant information to which the client instance belongs as the inner tunnel information includes: using the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information respectively, and using the tenant information to which the client instance belongs as the virtual network identifier VNI information of the inner tunnel information to perform inner tunnel encapsulation on the data packet.

[0074] In an optional embodiment, the above-mentioned outer tunnel encapsulation of the message after inner tunnel encapsulation using the identity information of the first gateway device includes: using the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer tunnel information, using the identification information of the first gateway device as the VNI information of the outer tunnel information, and performing outer tunnel encapsulation of the message after inner tunnel encapsulation.

[0075] In an optional embodiment, the inner tunnel encapsulation or the outer tunnel encapsulation adopts GENEVE, or VXLAN, or SRv6, and the inner tunnel encapsulation and the outer tunnel encapsulation use the same or different technologies.

[0076] In an optional embodiment, the tenant information to which the above-mentioned client instance belongs is the ID of the client VPC or the ID of the tenant, and the identification information of the first gateway device is the simulated ENI information of the first gateway device, that is, the ID of the fake-ENI, or the VNI corresponding to the first gateway device.

[0077] In an optional embodiment, the method further includes: obtaining a MAC address corresponding to the fake-ENI of the first gateway device from the first tunnel message or the second tunnel message, determining the fake-ENI ID corresponding to the MAC address in the first tunnel message or the second tunnel message based on a conversion table between MAC addresses and fake-ENI IDs, determining corresponding tunnel encapsulation information and the IP address of the corresponding NFV ECS and the IP address of the corresponding second VS based on the determined fake-ENI ID; and performing inner tunnel encapsulation and outer tunnel encapsulation on the data message in sequence based on the corresponding tunnel encapsulation information and the IP address of the corresponding NFV ECS and the IP address of the corresponding second VS. The inner tunnel encapsulation of the data message mainly refers to using the IP address of the first gateway device as the source address in the inner tunnel information, the IP address of the corresponding NFV ECS as the destination address in the inner tunnel information, and the tenant information to which the client instance belongs as the VNI information in the inner tunnel information, and performing inner tunnel encapsulation on the data message. Performing outer tunnel encapsulation on the message encapsulated by the inner tunnel mainly refers to using the IP address of the first gateway device as the source address in the outer tunnel information, the IP address corresponding to the second VS as the destination address of the outer tunnel information, and the VNI of the first gateway device as the VNI information in the outer tunnel information, and performing outer tunnel encapsulation on the message encapsulated by the inner tunnel.

[0078] Figure 6 A flow chart of another NFV access method provided in an embodiment of the present application. The method is applied to a second gateway device, such as Figure 6 As shown, the method includes:

[0079] 601. Receive a first tunnel message sent by a first VS. The first tunnel message is obtained by the first VS by tunnel encapsulating a data message for a client instance to access an NFV instance. Tunnel information in the first tunnel message includes tenant information to which the client instance belongs.

[0080] 602. Re-encapsulate the first tunnel message into a second tunnel message, and send the second tunnel message and the tenant information to which the client instance belongs to the first gateway device, so that the first gateway device uses the tenant information to which the client instance belongs as the inner tunnel information to perform inner tunnel encapsulation on the data message, and uses the identity information of the first gateway device to perform outer tunnel encapsulation on the message after the inner tunnel encapsulation, and then forwards it to the NFV instance through the second VS to achieve access to the NFV instance.

[0081] For the detailed implementation methods and technical effects of each step in the above method embodiments, please refer to the description of the aforementioned embodiments and will not be repeated here.

[0082] It should be noted that in some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The serial numbers of the operations, such as 501, 502, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0083] Figure 7 This is a structural diagram of an NFV access device provided in an embodiment of the present application. Figure 7 As shown, the device includes: an interception module 71, an inner encapsulation module 72, an outer encapsulation module 73 and a sending module 74.

[0084] The interception module 71 is configured to intercept data packets from a client instance accessing an NFV instance via the first virtual switch (VS). The inner encapsulation module 72 is configured to perform inner tunnel encapsulation on the data packets, using the tenant information of the client instance as inner tunnel information. The outer encapsulation module 73 is configured to perform outer tunnel encapsulation on the packets encapsulated via the inner tunnel, using the identity information of the first gateway device. The sending module 74 is configured to send the packets encapsulated via the outer tunnel to the second VS corresponding to the NFV instance, so that the second VS forwards the packets to the NFV instance, enabling access to the NFV instance.

[0085] In an optional embodiment, the above-mentioned interception module 71 is specifically used to: receive a first tunnel message sent by the first VS, the first tunnel message is obtained by the first VS tunnel encapsulating the data message, and the tunnel information of the first tunnel message includes tenant information to which the client instance belongs.

[0086] In an optional embodiment, the above-mentioned interception module 71 is specifically used to: receive a second tunnel message sent by the second gateway device and the tenant information to which the client instance belongs, the second tunnel message is obtained by the second gateway device performing tunnel encapsulation on the first tunnel message, the first tunnel message is obtained by the first VS performing tunnel encapsulation on the data message, and the tunnel information of the first tunnel message includes the tenant information to which the client instance belongs.

[0087] In an optional embodiment, the above-mentioned inner layer encapsulation module 72 is specifically used to: use the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner layer tunnel information respectively, and use the tenant information to which the client instance belongs as the virtual network identifier VNI information of the inner layer tunnel information to perform inner layer tunnel encapsulation on the data packet.

[0088] In an optional embodiment, the above-mentioned outer layer encapsulation module 73 is specifically used to: use the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer layer tunnel information, use the identification information of the first gateway device as the VNI information of the outer layer tunnel information, and perform outer layer tunnel encapsulation on the message after inner layer tunnel encapsulation.

[0089] In an optional embodiment, the inner tunnel encapsulation or the outer tunnel encapsulation adopts GENEVE, or VXLAN, or SRv6, and the inner tunnel encapsulation and the outer tunnel encapsulation use the same or different technologies.

[0090] In an optional embodiment, the tenant information to which the above-mentioned client instance belongs is the ID of the client VPC or the ID of the tenant, and the identification information of the first gateway device is the simulated ENI information of the first gateway device, or the VNI corresponding to the first gateway device.

[0091] Figure 8 This is a structural diagram of another NFV access device provided in an embodiment of the present application. Figure 8 As shown, the device includes: a receiving module 81, an encapsulation module 82 and a sending module 83.

[0092] Receiving module 81 is configured to receive a first tunnel message sent by a first virtual switch (VS). The first tunnel message is obtained by the first VS performing tunnel encapsulation on a data message from a client instance accessing an NFV instance. The tunnel information of the first tunnel message includes tenant information to which the client instance belongs. Encapsulating module 82 is configured to re-encapsulate the first tunnel message into a second tunnel message. Sending module 83 is configured to send the second tunnel message and the tenant information to the first gateway device, so that the first gateway device can use the tenant information to perform inner tunnel encapsulation on the data message using the tenant information as inner tunnel information. Furthermore, the first gateway device can perform outer tunnel encapsulation on the message after the inner tunnel encapsulation using the identity information of the first gateway device, and then forward the message to the NFV instance via the second VS to achieve access to the NFV instance.

[0093] For the detailed implementation methods and technical effects of each module in the above-mentioned device embodiments, please refer to the description of the aforementioned embodiments and will not be repeated here.

[0094] Figure 9This is a schematic diagram of the structure of a gateway device provided in an embodiment of the present application. The gateway device can be implemented as a first gateway device, such as Figure 9 As shown, the gateway device includes: a memory 91 and a processor 92.

[0095] The memory 91 is used to store computer programs and can be configured to store various other data to support operations on the gateway device. Examples of such data include instructions, messages, pictures, videos, etc. for any application or method operating on the gateway device.

[0096] The processor 92 is coupled to the memory 91 and is used to execute the computer program in the memory 91, so as to: intercept the data packet of the client instance accessing the NFV instance through the first virtual switch VS; perform an inner tunnel encapsulation on the data packet using the tenant information to which the client instance belongs as the inner tunnel information; perform an outer tunnel encapsulation on the packet after the inner tunnel encapsulation using the identity information of the first gateway device; and send the packet after the outer tunnel encapsulation to the second VS corresponding to the NFV instance, so that the second VS forwards it to the NFV instance, thereby realizing access to the NFV instance.

[0097] In an optional embodiment, when intercepting a data packet of a client instance accessing an NFV instance via a first virtual switch VS, the processor 92 is specifically used to: receive a first tunnel packet sent by the first VS, where the first tunnel packet is obtained by tunnel encapsulating the data packet by the first VS, and the tunnel information of the first tunnel packet includes tenant information to which the client instance belongs.

[0098] In an optional embodiment, when intercepting a data packet of a client instance accessing an NFV instance via a first virtual switch VS, the processor 92 is specifically configured to: receive a second tunnel packet sent by a second gateway device and tenant information to which the client instance belongs, wherein the second tunnel packet is obtained by tunnel encapsulating the first tunnel packet by the second gateway device, and the first tunnel packet is obtained by tunnel encapsulating the data packet by the first VS, and the tunnel information of the first tunnel packet includes tenant information to which the client instance belongs.

[0099] In an optional embodiment, when the processor 92 uses the tenant information to which the client instance belongs as the inner tunnel information to perform inner tunnel encapsulation on the data packet, it is specifically used to: use the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information respectively, and use the tenant information to which the client instance belongs as the virtual network identifier VNI information of the inner tunnel information to perform inner tunnel encapsulation on the data packet.

[0100] In an optional embodiment, when the processor 92 uses the identity information of the first gateway device to perform outer tunnel encapsulation on the message encapsulated by the inner tunnel, it is specifically used to: use the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer tunnel information, and use the identification information of the first gateway device as the VNI information of the outer tunnel information, and perform outer tunnel encapsulation on the message encapsulated by the inner tunnel.

[0101] In an optional embodiment, the inner tunnel encapsulation or the outer tunnel encapsulation adopts GENEVE, or VXLAN, or SRv6, and the inner tunnel encapsulation and the outer tunnel encapsulation use the same or different technologies.

[0102] In an optional embodiment, the tenant information to which the above-mentioned client instance belongs is the ID of the client VPC or the ID of the tenant, and the identification information of the first gateway device is the simulated ENI information of the first gateway device, or the VNI corresponding to the first gateway device.

[0103] In an optional embodiment, the first tunnel message or the second tunnel message also includes a MAC address corresponding to the fake-ENI of the first gateway device, and the processor 92 is further configured to: obtain the MAC address corresponding to the fake-ENI of the first gateway device from the first tunnel message or the second tunnel message, determine the fake-ENI ID corresponding to the MAC address in the first tunnel message or the second tunnel message based on a conversion table between MAC addresses and fake-ENI IDs, determine the corresponding tunnel encapsulation information and the IP address of the corresponding NFV ECS and the IP address of the corresponding second VS based on the determined fake-ENI ID; and sequentially perform inner tunnel encapsulation and outer tunnel encapsulation on the data message based on the corresponding tunnel encapsulation information and the IP address of the corresponding NFV ECS and the IP address of the corresponding second VS. The inner tunnel encapsulation of the data message primarily involves using the IP address of the first gateway device as the source address in the inner tunnel information, the IP address of the corresponding NFV ECS as the destination address in the inner tunnel information, and the tenant information of the client instance as the VNI information in the inner tunnel information, to perform inner tunnel encapsulation on the data message. Performing outer tunnel encapsulation on the message encapsulated by the inner tunnel mainly refers to using the IP address of the first gateway device as the source address in the outer tunnel information, the IP address corresponding to the second VS as the destination address of the outer tunnel information, and the VNI of the first gateway device as the VNI information in the outer tunnel information, and performing outer tunnel encapsulation on the message encapsulated by the inner tunnel.

[0104] like Figure 9 As shown, the gateway device also includes: a communication component 93, a power supply component 94 and other components. Figure 9Only some components are shown schematically, which does not mean that the gateway device only includes Figure 9 Components shown.

[0105] The embodiment of the present application also provides a gateway device, the structure of which is similar to Figure 9 The structure of the gateway device shown is the same or similar, so it will not be described in detail. Figure 9 The difference between the illustrated gateway devices lies in the different functions implemented by the processor executing the computer program stored in the memory. The gateway device of this embodiment, when executed by the processor in the memory, can implement the following actions: receiving a first tunnel message sent by a first VS, the first tunnel message being obtained by the first VS performing tunnel encapsulation on a data message from a client instance accessing an NFV instance, the tunnel information of the first tunnel message including tenant information of the client instance; re-encapsulating the first tunnel message into a second tunnel message, and sending the second tunnel message and the tenant information of the client instance to the first gateway device, so that the first gateway device performs inner tunnel encapsulation on the data message using the tenant information of the client instance as inner tunnel information; performing outer tunnel encapsulation on the message after the inner tunnel encapsulation using the identity information of the first gateway device, and forwarding the message to the NFV instance via the second VS, thereby enabling access to the NFV instance.

[0106] Accordingly, the embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement Figure 5 or Figure 6 The steps in the method shown.

[0107] Accordingly, the embodiment of the present application further provides a computer program product, including a computer program / instruction, which, when executed by a processor, enables the processor to implement Figure 5 or Figure 6 The steps in the method shown.

[0108] The above-mentioned memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0109] The above-mentioned communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0110] The power supply assembly provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0111] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) that contain computer-usable program code.

[0112] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0113] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0115] In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0116] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0117] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0118] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A network function virtualization NFV access system, characterized in that: include: The first gateway device that interconnects the client virtual private cloud (VPC) and the service VPC; The client VPC includes a client instance and a first virtual switch VS that provides data forwarding services for the client instance. The service VPC includes an NFV instance that carries an NFV network element and a second VS that provides data forwarding services for the NFV instance. The first gateway device is configured to intercept a data packet from the client instance accessing the NFV instance via the first VS, use the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information, use the tenant information to which the client instance belongs as the virtual network identifier (VNI) information of the inner tunnel information, and perform inner tunnel encapsulation on the data packet; Using the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer tunnel information, using the identification information of the first gateway device as the VNI information of the outer tunnel information, and performing outer tunnel encapsulation on the message after the inner tunnel encapsulation; The message encapsulated by the outer tunnel is sent to the second VS, so that the second VS forwards it to the NFV instance to achieve access to the NFV instance.

2. The system according to claim 1, wherein: When intercepting a data packet from the client instance accessing the NFV instance via the first VS, the first gateway device is specifically configured to: A first tunnel message sent by the first VS is received, where the first tunnel message is obtained by the first VS performing tunnel encapsulation on the data message, and tunnel information of the first tunnel message includes tenant information to which the client instance belongs.

3. The system according to claim 1, wherein: Also includes: a second gateway device interconnected with the first VS and the first gateway device; The second gateway device is configured to receive a first tunnel message sent by the first VS, where the first tunnel message is obtained by tunnel encapsulating the data message by the first VS, and tunnel information of the first tunnel message includes tenant information to which the client instance belongs, re-encapsulate the first tunnel message into a second tunnel message, and send the second tunnel message and the tenant information to which the client instance belongs to the first gateway device; When intercepting the data message of the client instance accessing the NFV instance through the first VS, the first gateway device is specifically used to: receive the second tunnel message sent by the second gateway device and the tenant information to which the client instance belongs.

4. A network function virtualization NFV access method, applied to a first gateway device, characterized in that: The method comprises: intercepting a data packet from the client instance to access the NFV instance via the first virtual switch VS; Using the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information respectively, using the tenant information to which the client instance belongs as the virtual network identifier VNI information of the inner tunnel information, and performing inner tunnel encapsulation on the data message; The address information of the first gateway device and the address information of the second VS are used as the source address and destination address of the outer tunnel information, the identification information of the first gateway device is used as the VNI information of the outer tunnel information, and the message after the inner tunnel encapsulation is encapsulated in the outer tunnel; The message encapsulated by the outer tunnel is sent to the second VS corresponding to the NFV instance, so that the second VS forwards it to the NFV instance to achieve access to the NFV instance.

5. The method according to claim 4, characterized in that Intercepting a data packet from the client instance to access the NFV instance via the first virtual switch VS, including: A first tunnel message sent by the first VS is received, where the first tunnel message is obtained by the first VS performing tunnel encapsulation on the data message, and tunnel information of the first tunnel message includes tenant information to which the client instance belongs.

6. The method according to claim 4, characterized in that Intercepting a data packet from the client instance to access the NFV instance via the first virtual switch VS, including: Receive a second tunnel message sent by a second gateway device and the tenant information to which the client instance belongs, where the second tunnel message is obtained by the second gateway device performing tunnel encapsulation on the first tunnel message, and the first tunnel message is obtained by the first VS performing tunnel encapsulation on the data message, and the tunnel information of the first tunnel message includes the tenant information to which the client instance belongs.

7. The method according to claim 4, characterized in that The inner tunnel encapsulation or the outer tunnel encapsulation uses the general network virtualization encapsulation GENEVE, or the virtual extended local area network VXLAN, or the segment routing SRv6 based on IPv6, and the inner tunnel encapsulation and the outer tunnel encapsulation use the same or different technologies.

8. A network function virtualization NFV access method, applied to a second gateway device, characterized in that: The method comprises: receiving a first tunnel message sent by a first virtual switch (VS), where the first tunnel message is obtained by the first VS performing tunnel encapsulation on a data message for a client instance to access an NFV instance, and tunnel information of the first tunnel message includes tenant information to which the client instance belongs; The first tunnel message is re-encapsulated into a second tunnel message, and the second tunnel message and the tenant information to which the client instance belongs are sent to the first gateway device, so that the first gateway device uses the address information of the first gateway device and the address information of the NFV instance as the source address and destination address of the inner tunnel information respectively, and uses the tenant information to which the client instance belongs as the virtual network identifier VNI information of the inner tunnel information to perform inner tunnel encapsulation on the data message; uses the address information of the first gateway device and the address information of the second VS as the source address and destination address of the outer tunnel information, uses the identification information of the first gateway device as the VNI information of the outer tunnel information, performs outer tunnel encapsulation on the message after inner tunnel encapsulation, and forwards it to the NFV instance through the second VS to realize access to the NFV instance.

9. A gateway device, characterized in that: include: A memory and a processor, the memory being used to store a computer program; the processor being coupled to the memory and being used to execute the computer program, causing the processor to implement the steps in the method according to any one of claims 4 to 7, or the steps in the method according to claim 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to implement the steps of the method according to any one of claims 4 to 7 or the steps of the method according to claim 8.

Images