Virtual domain within shared devices

Abstract

In one example, a method includes receiving configuration data by a computing device defining: an external virtual domain for network functions, which is connected to a public network and managed by the provider of the computing device; a virtual domain for network functions, which is separate from the external virtual domain, configured with a secure tunnel interface, connected to a customer network, and managed by the customer of the computing device provider; the external virtual domain, which implements a route-based virtual private network, forwarding encrypted network traffic received from the public network via a secure tunnel to the secure tunnel interface configured in the virtual domain; the virtual domain decrypting the encrypted network traffic to generate network traffic; and the virtual domain forwarding the network traffic to the customer network.

Description

[0001] Cross-references

[0002] This application claims the benefit of U.S. Patent Application No. 17 / 008,027, filed August 31, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to data centers, and more specifically, to the use of virtual domains within shared devices that apply network functions. Background Technology

[0004] Data center providers can utilize facilities such as data centers or data warehouses, where multiple customers of the provider provide connectivity and / or location of networks, servers, and storage devices within the facility with minimal cost and complexity, and interconnect to various telecommunications, cloud, and (multiple) other network service providers. Such data centers can be shared by multiple customers. By interconnecting on such facilities, the provider's customers, including telecommunications providers, Internet Service Providers (ISPs), application service providers, service providers, content providers, and other providers, as well as enterprises, can enjoy lower latency and have the freedom to focus on their core business.

[0005] Network operators, such as data center providers, can offer network functions that can be applied to packets traversing the switching infrastructure of data centers managed by the data center provider. Network functions can be implemented using specialized hardware devices, such as firewalls or routers, sometimes referred to as physical network functions (PNFs), or using network function virtualization (NFV) architectures or infrastructure (NFVI) that may include virtualized network functions (VNFs). For example, network functions (PNFs or VNFs) can provide firewalls, routing, carrier-grade network address translation (CG-NAT), video performance enhancement proxies, Transmission Control Protocol (TCP) optimization and header enrichment, caching, load balancing, or other network functions. VNFs can be executed by one or more virtual machines, containers, or other execution environments within the NFV infrastructure. In this way, virtualized network functions can be executed by servers, switches, storage devices, and cloud computing infrastructure. Summary of the Invention

[0006] In general, this disclosure describes techniques for using virtual domains within a device shared among multiple customers of a data center provider to provide secure virtual private networks, inter-customer network forwarding, and network functions. Devices providing network functions (such as PNFs and VNFs) can provide domain isolation for customer networks coupled to that device. Customer networks can be associated with customers of the data center provider, which may include enterprises, network service providers, cloud service providers, and other customers. Customer devices associated with customer networks can coexist within the data center provider's data center and be connected to the data center switching infrastructure, or can be connected to the data center via a network service provider or other connections to the data center switching infrastructure.

[0007] In some examples, a data center provider can deploy devices and configure them for multiple virtual domains and external virtual domains for a given customer. The external virtual domains act as gateways to external networks (such as the networks of an internet service provider or cloud service provider whose virtual domains are not linked to the device). Co-located customer networks within the data center can reach customer branch offices via the external virtual domains. Furthermore, the data center provider can configure the device using pre-configured connections between pairs of virtual domains to enable packet routing between virtual domains linked to customer networks. Such pre-configured connections can include connections between a customer's virtual domain and external virtual domains, enabling the customer's customer network to reach external networks.

[0008] In some examples, the device integrates secure Virtual Private Network (VPN) functionality by implementing route-based VPN technology and terminating secure VPN tunnels within a virtual domain. In contrast to deployments where a secure VPN gateway terminates secure VPN tunnels (e.g., decrypts encrypted traffic in other operations) and forwards the decrypted traffic to the destination network, an external virtual domain configured within the device applies route-based VPN to encrypted traffic received at the external virtual domain, routing the encrypted traffic to the device's virtual domain, which is linked to the destination network of the encrypted traffic. This virtual domain is configured with a secure tunnel interface and decrypts the traffic before forwarding it to the destination network. In practice, the device supports secure VPNs across multiple virtual domains with secure VPN tunnel endpoints.

[0009] The aspects described above, as well as the others described herein, can provide one or more technological advantages that present at least one practical application. For example, isolating a customer's virtual domain and terminating a secure VPN tunnel within that customer's specific virtual domain can improve the security of the customer's business because unencrypted business to multiple customers does not traverse the public link. Furthermore, this technological advantage arises solely from a single device shared by multiple customers. As another example, as mentioned above, these technologies can facilitate multi-tenancy on a single device while simultaneously enabling secure business processing. Therefore, data center providers can deploy a single device (or lease the single device to a reseller) that can be securely shared among multiple different customers of the data center provider, thereby increasing device utilization and, at least in some cases, leading to high efficiency.

[0010] In one example, a computing device includes processing circuitry coupled to memory, the processing circuitry and memory being configured to implement: a network function; an external virtual domain for the network function, the external virtual domain being connected to a public network and managed by a provider of the computing device; and a virtual domain for the network function, separate from the external virtual domain, configured with a secure tunnel interface, connected to a customer network and managed by a customer of the provider of the computing device, wherein the external virtual domain implements a route-based virtual private network to forward encrypted network traffic received from the public network via a secure tunnel to the secure tunnel interface configured in the virtual domain, and wherein the virtual domain is configured to decrypt the encrypted network traffic to generate network traffic and forward the network traffic to the customer network.

[0011] In one example, a computing device includes processing circuitry coupled to memory, the processing circuitry and memory being configured to implement: a network function; a first virtual domain for the network function, the first virtual domain being connected to a first customer network and managed by a first customer of the computing device provider; a second virtual domain for the network function, the second virtual domain being separate from the first virtual domain, connected to a second customer network and managed by a second customer of the computing device provider; and a virtual domain connection that enables network traffic to be forwarded from the first virtual domain to the second virtual domain, the virtual domain connection being configured by the computing device provider.

[0012] In one example, a method includes receiving configuration data from a computing device defining: an external virtual domain for network functions, connected to a public network and managed by the provider of the computing device; and a virtual domain for network functions, separate from the external virtual domain, configured with a secure tunnel interface, connected to a customer network and managed by the customer of the provider of the computing device; the external virtual domain, implementing a route-based virtual private network, forwarding encrypted network traffic received from the public network via a secure tunnel to the secure tunnel interface configured in the virtual domain; the virtual domain decrypting the encrypted network traffic to generate network traffic; and the virtual domain forwarding the network traffic to the customer network.

[0013] Details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, the drawings, and the claims. Attached Figure Description

[0014] Figure 1 This is a block diagram illustrating a system including an example device configured and operated according to the technology described herein.

[0015] Figure 2 This is a block diagram illustrating a system including an example device that performs virtualized network functions according to the technology configured and operated as described herein.

[0016] Figure 3 The illustration shows a conceptual diagram of a metropolitan area-based cloud switching network system that provides multiple cloud switching points including devices, according to the technology described herein.

[0017] Figure 4 This is a flowchart illustrating an example operating mode of a device according to the technology of this disclosure.

[0018] Figure 5 This is a block diagram illustrating further details of an example of a computing device operating according to one or more techniques of the present disclosure.

[0019] Figure 6 This is a flowchart illustrating an example operating mode of a device according to the technology described in this disclosure.

[0020] Throughout the accompanying figures and text, similar reference characters indicate similar elements. Detailed Implementation

[0021] Figure 1 This is a block diagram illustrating a system 100 including an example device 104, configured and operated according to the technology described herein. Figure 1In the example, system 100 includes cloud switch 102, which includes a data center switching structure connected to device 104. The data center switching structure, device 104, and other devices (not shown) of cloud switch 102 can be configured by programmable network platform 103.

[0022] In some cases, cloud exchange 102 may refer to the Equinix cloud exchange infrastructure provided by Equinix Inc. of Redwood City, California. Further examples of cloud-based service exchange can be found in the following documents: U.S. Patent Application No. 15 / 099,407, filed April 14, 2016, entitled “CLOUD-BASED SERVICES EXCHANGE”; U.S. Patent Application No. 14 / 927,451, filed October 29, 2015, entitled “INTERCONNECTION PLATFORM FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF A CLOUD-BASED SERVICES EXCHANGE”; and U.S. Patent Application No. 14 / 927,306, filed October 29, 2015, entitled “ORCHESTRATION ENGINE FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF INTERCONNECTIONS WITHIN A CLOUD-BASED SERVICES EXCHANGE”; each of which is incorporated herein by reference in its entirety.

[0023] System 100 also includes a public network 120 connected to customer branch office 118, a customer network 130, and a cloud service provider network 128 providing one or more cloud services 114A-114N (collectively, "Cloud Services 114"). Public network 120 may be a network that is publicly available with little or no restriction. For example, public network 120 may be part of or otherwise connected to the Internet, a network service provider network, an autonomous system, an Internet service provider network, or a combination or one or more of such networks.

[0024] Customer network 130 is a network deployed and / or managed by customers of the provider that deploys and / or manages cloud exchange 102. Cloud exchange 102 may be implemented at least in part using a data center switching fabric located within one or more data centers (not shown), where customers also co-locate networking, computing, and other devices of customer network 130. This data center switching fabric may alternatively be referred to as a data center structure, switching fabric, cloud switching fabric, switching network, data center network, or other network operating as data center infrastructure, and may be deployed and configured to interconnect multiple customer networks of the data center provider, which have access to ports in the data center switching fabric. Customers of customer network 130 may be enterprises, resellers, hosting service providers, network service providers, internet service providers, cloud service providers, or other entities. Customer branch office 118 may be a remote branch office of a customer of customer network 130, connected to public network 120.

[0025] Cloud service provider network 128 is a network deployed and / or managed by a cloud service provider, which is a customer of the provider that deploys and / or manages cloud exchange 102. Cloud service provider network 128 can represent a public cloud, private cloud, hybrid cloud, virtual private cloud within a public cloud, or other network providing cloud services. Cloud service 114 originates and receives cloud service traffic exchanged with other networks such as customer network 130. Cloud provider organization 123 can be a remote branch of a cloud provider entity within cloud service provider network 128, connected to public network 120.

[0026] Device 104 may be a network device, router, firewall, switch, or other physical network device that provides network function 105. Device 104 may be a Physical Network Function (PNF) defined by the European Telecommunications Standards Institute (ETSI). Device 104 may provide forwarding and network address translation services for network traffic to and from VNF 204.

[0027] According to the technology described in this disclosure, device 104 stores configuration data 109 that defines the configuration of device 104. A programmable network platform 103 or an operator can invoke the interface of device 104 to add, delete, or modify the configuration data 109. Configuration data 109 defines an external virtual domain 106 and multiple virtual domains 110A-110K (collectively, "virtual domain 110"). Each of external virtual domain 106 and virtual domain 110 is a virtual instance of device 104, connected to at least one network via a different port (not shown) of device 104 and isolated from other virtual domains, unless configuration data 109 defines virtual connections between the virtual domain and one or more other virtual domains.

[0028] The provider can deploy device 104 that can be shared among multiple different customers of the provider (e.g., a data center provider). The provider uses configuration data 109 to configure device 104 to define virtual domains 110 for the respective customers of the provider or other entities (such as resellers). Thus, each customer has a separate, isolated virtual domain that forwards traffic associated with the network and received at the virtual domain for the customer. For example, virtual domain 110A is associated with a first port of device 104 connected to customer network 130 and forwards traffic associated with customer network 130, while virtual domain 110K is associated with a second port of device 104 connected to cloud service provider network 128 and forwards traffic associated with the cloud service provider for cloud service provider network 128.

[0029] Device 104 can apply network functions 105 to any network traffic traversing the domain, based on policies configured by customers associated with the domain. For example, customers of customer network 130 can configure virtual domain 110A using specific routing policies, firewall rules, NAT rules, or other network function rules, policies, or configurations to implement customer network function preferences regarding network traffic traversing virtual domain 110A through device 104. Configuration data 109 can restrict customers to configuring only their respective domain 110 and prevent customers from configuring or modifying: for example, the existence of virtual domains 106 and 110; virtual domain connections between any of 106 and 110; or connections from virtual domains 106 and 110 to the network. For example, for virtual domain authorization, device 104 can use Terminal Access Controller Access Control System (TACACS), TACACS+, or Remote Authentication Dial-In User Service (RADIUS) or Diameter to restrict the configuration of virtual domains for the authorizing party (e.g., a reseller or customer). In some examples, only the provider of network function 105 for device 104 may be authorized to configure external virtual domain 106 and virtual domain connection 121. Additional details for limiting authorization can be found in U.S. Patent Application No. 16 / 836,77, filed March 31, 2020, entitled “Virtual Network Function Virtual Domain Isolation,” the entire contents of which are incorporated herein by reference.

[0030] In some examples, a virtual domain may include a Virtual Router and Forwarder (VRF) instance with an interface to a corresponding network. For example, external virtual domain 106 has an interface with a public IP address 111 on a public network 120. Virtual domain 110A has an interface with an IP address 112A on a customer network 130. Virtual domain 110K has an interface with an IP address on a cloud service provider network 128. In some examples, the VRFs of virtual domains 106 and 110 are configured with routing information to facilitate inter-VRF forwarding based on service attributes (e.g., route leakage). The provider of device 104 can pre-configure these virtual domain connections by setting configuration data 109 to "stitch" the two virtual domains 110 together to achieve route leakage between virtual domains by configuring import and export route destinations in the corresponding VRFs. Optional virtual domain connections 121A-121C between virtual domains 110 (collectively referred to as "virtual domain connections 121") are as follows: Figure 1 As illustrated in the diagram. In some examples, the configuration of device 104 prevents customers from configuring or otherwise modifying virtual domain connections 121A-121C. Virtual domain connections 121 are configured by the provider of device 104, in some cases based on a customer's subscription to cloud services and / or data center services or a request for connectivity with other customers. In some cases, virtual domain connections 121 are pre-configured before customers have the right to modify the corresponding configuration of their respective virtual domains. For customer networks 130 that access the Internet and / or customer branch offices 118, and vice versa, virtual domain 110 may, in some cases, have virtual domain connections 121 with external virtual domain 106, which operates as a VPN gateway for device 104. The IP addresses 112A-112K of the corresponding virtual domains 110A-110K can be private or public.

[0031] In some examples, a virtual domain can represent a firewall domain. For instance, external virtual domain 106 could be a firewall domain that applies network function 105 (in this example, a firewall) to network traffic received from a public network 120 or from any virtual domain within virtual domain 110. The firewall domain can implement firewall rules to determine whether and how received network traffic passes through external virtual domain 106 or other virtual domains 110. Other virtual domains 110 can also be configured to implement firewall preferences for corresponding clients within virtual domain 110.

[0032] Device 104 can prevent tagged VPN traffic because network traffic traverses virtual domains 106 and 110 within device 104. For example, virtual domain 110A could be a virtual firewall domain or a VRF instance. Resellers or customers / tenants can configure virtual domain 110A using configuration restrictions (e.g., command-line interface). Device 104 has configuration data indicating that a customer's port belongs to virtual domain 110A, and upon receiving traffic from a customer's network coupled to such a port, device 104 applies routing table or firewall rules for that domain and then forwards the traffic normally.

[0033] Each IP address 112 for the corresponding virtual domain 110 can be a public IP for the site-to-site secure tunnel 119, or the virtual domain can share a public IP 111 using virtual domain connection 121. The secure tunnel endpoint resolves to a specific virtual domain 110. If the virtual domain shares the public IP 111, VPN 107 performs demultiplexing based on the destination public IP, the source IP for the external site, or a combination thereof.

[0034] Virtual domain 110 can advertise routes using BGP over secure tunnel 119. Customer branch offices 118 or other sites can advertise their gateway routers. Cloud service provider networks 128 can advertise their gateway routers. External virtual domain 106 can perform forwarding for routes received from external gateway routers. Received routes can be stored in routes 125 for route-based virtual private networks. Received routes can also be stored in one or more virtual domains 110 for forwarding based on such routes (or firewall rules). These routes can be used for inter-virtual domain forwarding via virtual domain connection 121.

[0035] Therefore, virtual domain 110K can forward cloud service traffic received from cloud service 114A via cloud service provider network 128 to external virtual domain 106 via virtual domain connection 121C, and vice versa. In some examples, cloud service traffic received at virtual domain 110K can be processed using network function 105 before being forwarded to external virtual domain 106 for further forwarding to its destination. Depending on the policy for network function 105 for external virtual domain 106, external virtual domain 106 can also apply network function 105. A similar process can be applied in the opposite direction from cloud server 114 to cloud client 118.

[0036] Device 104 uses route 125 to implement a route-based Virtual Private Network (VPN) 107 to determine whether to route network traffic to one of the secure tunnels 119A-119K (collectively referred to as "secure tunnel 119") and to determine which virtual domain 110 to route network traffic received from any secure tunnel in secure tunnel 119. The provider of device 104 sets configuration data 109 to create secure endpoints 115A-115K (collectively referred to as "secure endpoint 115"), which are secure virtual tunnel interfaces used by device 104. Secure tunnel 119 may represent an IPSec tunnel or other encrypted tunnels that can be used to implement VPN 107.

[0037] Secure endpoint 115 sends and receives encrypted, tunneled network traffic within its respective virtual domain 110 to facilitate service isolation between customers within that virtual domain 110. When external virtual domain 106 receives encrypted network traffic via one of the secure tunnels 119, external virtual domain 106 applies route 125 to route the encrypted network traffic to the correct virtual domain 110 based on the source IP / port and / or destination IP / port information of the encrypted network traffic. For example, the provider of device 104 can configure routes in route 125 to forward traffic originating from customer branch office 118 and destined for customer network 130, or both, to secure endpoint 115A in virtual domain 110A for customers associated with customer branch office 118 and customer network 130. The matching prefix for this route can be based on information provided by the customer, and the destination for this route can be the secure tunnel interface represented by secure endpoint 115A. Device 104 decrypts the encrypted network traffic. Then, virtual domain 110 can apply network functions 105 to network services based on the specific preferences of virtual domain 110A for network 105, and virtual domain 110A can forward network services to customer network 130. In some cases, the underlying network services are destined for another network, such as cloud service provider network 128. Virtual domain 110A can then forward network services to virtual domain 110 located on the path to the destination network via one of virtual domain connections 121.

[0038] In this way, device 104 creates a secure VPN that terminates within the customer's virtual domain 110A, with an endpoint within the customer's branch office 118. The customer branch office 118 may have a dedicated VPN gateway (not shown) to operate as another secure endpoint for the secure tunnel 119A. Therefore, the secure VPN extends between virtual domain 110A and the customer branch office 118, and although encrypted network traffic for multiple customers may be mixed at the external virtual domain 106, it is encrypted. Unencrypted network traffic for the customer exists only within device 104 within the virtual domain 110 configured for that customer. Device 104 can similarly operate with respect to the secure tunnel 119K and virtual domain 110K of the VPN for the cloud service provider. In some cases, the VPN further protects internal routing information by encrypting the IP headers of the customer's network traffic. For the secure tunnel 119 to which the customer's network traffic is directed, the customer's network traffic is encapsulated by another set of IP headers.

[0039] In some cases, the customer entry point into device 104 can be considered the A-side of the customer-provider interconnection, while the exit-side connection can be considered the Z-side. The Z-side can also be configured as the center for multiple spokes (A-side customers) to connect to the service. Customers receive Z-side service information through subscription. However, the Z-side receives connection information for such services from all A-side subscribers while maintaining privacy among A-side customers.

[0040] In practice, each customer management device 104 operates on a single "layer," corresponding to a virtual domain within virtual domain 110. The customer is only aware of this layer, its own network, and any networks its layer is already connected to using one of the virtual domain connections 121. This technology avoids L3VPNs, which require additional labels or protocol flags on packets to separate customer traffic. Instead, this technology uses virtual domain 110 and secure tunnel 119, along with a route-based VPN, to facilitate isolation. Once network traffic leaves device 104 for public network 120, it is encrypted with the appropriate headers for reaching its destination. In contrast, L3VPN traffic is labeled and may not be encrypted. External locations, such as customer branch offices 118, terminate the corresponding secure tunnel 119. Once customer branch offices 118 leave the domain and head towards external virtual domain 106 (public IP 111), network traffic originating from customer branch offices 118 is encrypted. In some cases, the remote end, Z-side, or intermediate hop may not be aware of the existence of services for multiple customers; that is, they may all consider them to be single customer services from a single device 104. However, in reality, each flow belongs to a different customer, and the customer only controls their corresponding virtual domain 110, thus allowing the same platform (device 104) to be shared among multiple customers.

[0041] By integrating a VPN and VPN gateway into a single device 104 using a route-based VPN applied at an external virtual domain 106, which effectively acts as a VPN gateway within device 104 for networks connected to device 104, device 104 can enable multiple client VPNs on corresponding virtual domains 110, all sharing the same uplink to the public network 106. Furthermore, because the secure tunnel 119 terminates in the corresponding virtual domain 110, data is encrypted until it reaches the corresponding virtual domain 110 for the client. This reduces security vulnerabilities and promotes privacy. In most cases, even the provider managing the external virtual domain 106 does not have access to the decrypted network services for the client. Therefore, these technologies allow device 104, its network functions 105, licenses, and other services and resources to be securely shared among multiple clients of the provider, facilitating connectivity and accessibility with external branch offices and between client networks connected to cloud exchange 102. This reduces inbound time or latency for new clients, which can be added through simple configuration changes to device 104 and a one-time connection to the port. This can also increase the utilization of equipment 104 by distributors or suppliers.

[0042] Figure 2 This is a block diagram illustrating a system 200 including an example device 204 performing virtualized network functions according to the technology configured and operated according to the description herein. In the example of system 200, VNF 204 and Figure 1 Device 104 is configured similarly, and it can be a PNF for the same network function, namely network function 105.

[0043] Figure 2 The cloud switch 202 is similar to the cloud switch 102 and includes a network function virtualization infrastructure (NFVI) 202, which can be provided in a data center environment that also includes the switching structure of the cloud switch 102 (not shown).

[0044] NFVI 202 can deploy one or more services, such as virtualized network functions. NFVI 202 includes compute hardware, storage hardware, and network hardware for executing VNFs. In some examples, NFVI 202 also includes a virtualization layer on top of the hardware to provide virtual compute, virtual storage, and virtual networking for executing VNFs. NFVI 202 can be executed by one or more compute devices in a centralized or distributed manner. Figure 1In the example, the NFVI 202 platform includes servers running virtualization software (e.g., hypervisors), such as server 234, on which virtualization software implements a virtual execution environment for deploying VNF images (including network infrastructure software). Server 234 can provide one or more virtual machines 236A-236N (collectively referred to as "VM 136"). Each of VM 236 emulates hardware. In other words, each VM 236 provides a virtualized operating system and application suite (e.g., for deploying VNFs) for client access. Alternatively or additionally, each of the servers can provide containers (e.g., those provided by open-source Docker container applications) or other virtual execution environments in which VNFs are implemented. VNF 204 is deployed as one of these virtual execution environments, in this case, VM 236A.

[0045] VNF 204 can provide similar functionality to hardware-based network devices such as dedicated network equipment, but VNFs deliver this functionality in software. VNFs are primarily a software architecture and therefore can be decoupled from the underlying hardware. For example, a VNF 204 can provide the same routing, switching firewall, intrusion detection, or other services traditionally provided by dedicated hardware, but in software form. A VNF 204 can provide forwarding and network address translation services for network traffic going to and from it.

[0046] VNF 204 storage configuration data 109, this configuration data 109 configures with Figure 1 The virtual domains 106 and 110 in device 104 are similar to those in device 104. Therefore, VNF 204 operates similarly to device 104 to implement a route-based VPN, thereby terminating the secure tunnel 119 within virtual domain 110. This allows VNF 204 to be shared among multiple clients (each with a corresponding virtual domain 110), providing secure VPN service forwarding for client services. Regarding the operation in system 100... Figure 1 Device 104 describes the operation and configuration of VNF 204 in detail. Regarding... Figure 1 Users can use the programmable network platform 103 to configure the VNF 204 using the configuration data 109.

[0047] Apart from Figure 2 Outside the virtual domain of the example system 200 illustrated in the figure, or instead Figure 2 The virtual domain of the example system 200 illustrated in the figure may include other virtual domains. For example, VNF204 may include an Internet switching virtual domain that couples VNF204 to an Internet switching network, a cloud switching network, or a switching infrastructure.

[0048] exist Figure 1 The example shown in the diagram illustrates a server 134 and a VNF 204. A traditional NFVI infrastructure can include more than one server, which in turn can include more than one VNF.

[0049] Figure 3 The diagram illustrates a conceptual design of a metropolitan area-based cloud switching network system with multiple cloud switching points, including devices, according to the technology described herein. Multiple cloud switching points can be used to at least partially implement NFVI 202 and / or connect to physical network functions for network service applications. For example, NFVI 202 can be connected to the cloud switching fabric of cloud switch 328A and include VNF 204. However, as illustrated, device 104 is connected to the cloud switching fabric of cloud switch 328A. In some cases, these systems can be deployed within a single data center.

[0050] Each of the cloud-based service exchange points 328A-328C (described hereinafter as “cloud exchange points” and collectively referred to as “cloud exchange points 328”) of cloud-based service exchange point 300 (“cloud exchange point 300”) may represent different data centers located in the same metropolitan area (“metropolitan-based”, e.g., New York City, New York; Silicon Valley, California; Seattle-Tacoma, Washington; Minneapolis-St. Paul, Minnesota; London, United Kingdom; etc.) to provide resilient and independent cloud-based service exchange through which cloud-based service customers (“cloud customers”) and cloud-based service providers (“cloud providers”) connect to receive and provide cloud services respectively. In various examples, cloud exchange 300 may include more or fewer cloud exchange points 328. In some cases, cloud exchange 300 includes only one cloud exchange point 328. As used herein, references to “cloud exchange” or “cloud-based service exchange” may refer to a cloud exchange point. The cloud exchange provider can deploy instances of Cloud Exchange 300 in multiple different metropolitan areas, with each instance of Cloud Exchange 300 having one or more Cloud Exchange Points 328.

[0051] Each cloud exchange point 328 includes network infrastructure and an operating environment through which cloud customers 308A-308C (collectively, "cloud customers 308") receive cloud services from multiple cloud service providers 310A-310N (collectively, "cloud service providers 310"). Cloud service providers 310 may host one of the multiple cloud services 114. As noted above, cloud service providers 310 may be public or private cloud service providers.

[0052] The CloudExchange 300 provides secure, private virtual connections to multiple cloud service providers (CSPs) globally to its customers (e.g., enterprises, network operators, network service providers, and SaaS customers). Multiple CSPs participate in the cloud exchange by having at least one accessible port, through which customers can connect to one or more cloud services provided by each CSP. The CloudExchange 300 allows any customer's private network to directly cross-connect to any other customer at a public point, enabling direct exchange of network services between customer networks.

[0053] Cloud customer 308 may receive cloud-based services directly via a Layer 3 peering and physical connection with one of the cloud exchange points 328, or indirectly via one of the network service providers 306A-306B (collectively, “NSP 306”, or alternatively, “Carrier 306”). Cloud customer 308 may include customers associated with VNF 204 as described above. For example, cloud customer 308 may include systems used by cloud customer 118 to access cloud service 114 via VNF 204. NSP 306 provides “cloud transit” by maintaining a physical presence within one or more cloud exchange points 328 and aggregating Layer 3 access from one or more customers 308. NSP 306 may peer directly with one or more cloud exchange points 328 at Layer 3, and in doing so, provide indirect Layer 3 connections and peering with one or more customers 308 through which customers 308 can obtain cloud services from cloud exchange point 300. Figure 3In the example, each of the cloud exchange points 328 can be assigned a different Autonomous System Number (ASN). For example, cloud exchange point 328A is assigned ASN 1, cloud exchange point 328B is assigned ASN 2, and so on. Therefore, each cloud exchange point 328 is the next hop in the path vector routing protocol (e.g., BGP) path from cloud service provider 310 to customer 308. As a result, although each cloud exchange point 328 is not a transit network with one or more WAN links and accompanying Internet access and transport policies, it can peer with multiple different autonomous systems via external BGP (eBGP) or other external gateway routing protocols to exchange, aggregate, and route service traffic 310 from one or more cloud service providers to customers. In other words, cloud exchange point 328 can internalize the eBGP peering relationship that cloud service provider 310 and customer 308 will maintain on a pairwise basis. Conversely, customer 308 can configure a single eBGP peer with cloud exchange point 328 and receive multiple cloud services from one or more cloud service providers 310 via the cloud exchange. While this document primarily describes eBGP or other Layer 3 routing protocol peering connections between the cloud exchange point and the customer, NSP, or cloud service provider networks, the cloud exchange point can learn routes from these networks in other ways, such as through static configuration or via Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or other routing distribution protocols.

[0054] As an example above, customer 308C is illustrated as having a contract with the cloud exchange provider of cloud exchange 300 to directly access Layer 3 cloud services via cloud exchange point 328C. In this manner, for example, customer 308C receives redundant Layer 3 connections from cloud service provider 310A. In contrast, customer 308C is illustrated as having a contract with the cloud exchange provider of cloud exchange 300 to directly access Layer 3 cloud services via cloud exchange point 328C, and also a contract with NSP 306B to access Layer 3 cloud services via the transit network of NSP 306B. Customer 308B is illustrated as having contracts with multiple NSPs 306A and 306B to provide redundant cloud access to cloud exchange points 328A and 328B via the respective transit networks of NSPs 306A and 306B. Through the L3 peering configuration within the switching equipment of NSP306 and cloud exchange point 328, and the L3 connection (e.g., a Layer 3 virtual circuit) established within cloud exchange point 328, the aforementioned contract is instantiated in the network infrastructure of cloud exchange point 328 to interconnect the cloud service provider 310 network with the NSP 306 network and the customer 308 network, all of which have at least one port providing connectivity within one or more cloud exchange points 328.

[0055] In some examples, the cloud switch 300 allows any Network Service Provider (NSP) or "Operator" 306A-306B (collectively, "Operator 306") customer 308A, 308B, or a corresponding customer of other cloud customers including customer 308C, to directly connect to any other customer network and / or any CSP 310 via a virtual Layer 2 (L2) or Layer 3 (L3) connection, thereby allowing direct exchange of network services between the customer network and the CSP 310. The virtual L2 or L3 connection may be referred to as a "virtual circuit".

[0056] Operators 306 may each represent network service providers associated with the transit network, through which network subscribers of Operator 306 can access cloud services provided by CSP 310 via cloud exchange 300. Generally, customers of CSP 310 may include network operators, large enterprises, managed service providers (MSPs), and customers of Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Virtualization as a Service (VaaS), and Data Storage as a Service (dSaaS) services for such cloud-based services provided by CSP 310 via cloud exchange 300.

[0057] In this way, Cloud Exchange 300 streamlines and simplifies the process of collaboration between CSP 310 and customers (via Operator 306 or directly) in a transparent and neutral manner. An example application of Cloud Exchange 300 is co-location and interconnection of data centers, where CSP 310 and Operator 306 and / or Customer 308 may already have networks, such as representing any cloud exchange point 328 by having one or more accessible ports within the data center available for interconnection. This allows participating operators, customers, and CSPs to have a wide range of interconnectivity options within the same facility. In this way, operators / customers can have the option to create many-to-many interconnections by hooking to one or more cloud exchange points 328 only once. In other words, Cloud Exchange 300 allows customers to interconnect to multiple CSPs and cloud services, rather than having to establish separate connections on a transit network to access different cloud service providers or different cloud services from one or more cloud service providers.

[0058] The cloud exchange 300 includes a programmable network platform 320 for dynamically programming the cloud exchange 300 to responsively and reliably fulfill service requests that encapsulate business requirements for services provided by the cloud exchange 300 and / or cloud service providers 310 coupled to the cloud exchange 300. The programmable network platform 320 may include a network service coordinator 332 that handles tenant (e.g., cloud client) requests for VNF deployments. For example, the network service coordinator 332 can organize, bootstrap, and integrate underlying services via VMs 136 (or containers) and other software and network subsystems to manage various services (e.g., VNF deployments). As a result, the programmable network platform 320 can coordinate business-level services across heterogeneous cloud service providers 310, based on clearly defined service policies, quality of service policies, service level agreements and costs, and further, based on the service topology used for business-level services.

[0059] The programmable network platform 320 enables cloud service providers managing the cloud exchange 300 to dynamically configure and manage the cloud exchange 300, for example, to facilitate virtual connections for cloud service delivery from multiple cloud service providers 310 to one or more cloud customers 308. The cloud exchange 300 can enable cloud customers 308 to bypass the public internet and connect directly to cloud service providers 310, thereby improving performance, reducing costs, increasing connection security and privacy, and leveraging cloud computing for additional applications. In this way, for example, enterprises, network operators, and SaaS customers can integrate cloud services with their internal applications at least in some respects, as if such services were part of their own data center network or as if they were otherwise directly coupled to their own data center network.

[0060] In other examples, the programmable network platform 320 enables cloud service providers to configure cloud exchange 300 using an L3 instance requested by a cloud customer 308, as described herein. For example, customer 308 may request an L3 instance to link multiple cloud service providers (e.g., for transferring customer data between two cloud service providers, or for obtaining services from multiple cloud service providers via a mesh).

[0061] The programmable network platform 320 may represent an application running within one or more data centers of the cloud exchange 300, or alternatively, may represent an application running off-site, for example, at a back office or branch of a cloud provider. The programmable network platform 320 may be distributed, wholly or partially, among data centers, each associated with a different cloud exchange point 328 to form the cloud exchange 300. Although shown as managing a single cloud exchange 300, the programmable network platform 320 may control the provisioning of services for multiple different cloud exchanges. Alternatively or additionally, multiple individual instances of the programmable network platform 320 may control the provisioning of services for corresponding multiple different cloud exchanges.

[0062] In the illustrated example, the programmable network platform 320 includes a service interface (or "service API") 314, which defines how applications 330, such as a customer portal, can invoke methods, fields, and / or other software primitives of the programmable network platform 320. The service interface 314 can allow operators 306, customers 308, cloud service providers 310, and / or cloud exchange providers to programmably access the capabilities and assets of the cloud exchange 300 according to the technologies described herein.

[0063] For example, service interface 314 can facilitate machine-to-machine communication to enable the dynamic provisioning of virtual circuits in the cloud switch for interconnecting customer and / or cloud service provider networks. In this way, programmable network platform 320 automates various aspects of cloud service provisioning. For instance, service interface 314 can provide customers with an automated and seamless way to establish, offload, and manage interconnections between multiple different cloud providers participating in the cloud switch.

[0064] Cloud service provider network 310A can represent Figures 1 to 2 Example instance of cloud service provider network 128, customer 308A can represent Figures 1 to 2An example instance of customer network 130. Programmable network platform 320 can provision one or more virtual circuits in cloud exchange point 328A to interconnect customer network 308A to cloud service provider network 310A and forward traffic via device 104 for processing in virtual domains 110 associated with the respective cloud service provider and customer. For example, a first virtual circuit can connect customer network 308A to virtual domain 110A of device 104, and a second virtual circuit can connect cloud service provider network 310A to virtual domain 110K. Device 104 includes virtual domain connection 121B, which connects the first and second virtual circuits together to enable cloud service traffic to flow between customer network 308A and cloud service provider network 310A via virtual domains 110A and 110K, which apply network function 105 according to the policies of each customer (in this example, customers for virtual domain 110A and customers / cloud service providers for virtual domain 110K) for network function 105.

[0065] Figure 4 This is a flowchart illustrating an example operating mode of a device according to the technology of this disclosure. This operating mode includes a setup phase and an operation phase. Although the operation phase is shown after the setup phase for illustrative purposes, this order is not necessary, as setup can occur in some cases while the device is in operating mode. During the setup phase, a computing device, such as device 104 or VNF 204 (e.g., executed on a server), receives first configuration data 109 defining an external virtual domain 106 (400) for network function 105. The external virtual domain 106 can be managed by the provider of the computing device and can only be configured by it, not by the provider's customers. The computing device can operate as a gateway from virtual domain 110 to a public network 120. The computing device receives second configuration data defining a virtual domain 110A for network function 105 and a secure tunnel interface (402) for virtual domain 110A. The computing device receives third configuration data (404) defining a virtual domain connection 121A between external virtual domain 106 and virtual domain 110A. The computing device obtains and installs a prefix-based route to the route-based virtual private network 107, which corresponds to the client network 130 attached to the first port of the computing device (the port of virtual domain 110A), and this route is mapped to the secure tunnel interface (406) of virtual domain 110A. The secure tunnel interface can be a secure tunnel endpoint.

[0066] The computing device then receives encrypted network traffic at a second port of the computing device (the port of external virtual domain 106). This port may be connected to (or the port reached by the computing device) the public network 120 (408). External virtual domain 106 does not decrypt the encrypted network traffic. Based on route 109, the computing device uses a route-based virtual private network 107 to forward the encrypted network traffic to the secure tunnel interface (410) of virtual domain 110A mapped to the prefix of route 109.

[0067] Virtual domain 110A decrypts encrypted network traffic (412) and forwards the decrypted network traffic to customer network 130 based on route 109 (414). In this way, the virtual domain 110 of a corresponding customer with a secure VPN tunnel terminating within the customer-specific virtual domain 110 can improve the security of customer traffic because unencrypted traffic for multiple customers traversing public network 120 does not traverse public links or public virtual domains, such as external virtual domain 106.

[0068] Figure 5 This is a block diagram illustrating further details of an example of a computing device operating according to one or more techniques of the present disclosure. Figure 5 A specific example of a server or other computing device 500 may be illustrated, which includes one or more processors 502 for executing any system, application, or module described herein. Although regarding servers implementing VNFs... Figure 5 The techniques described herein may include physical devices such as dedicated routers or firewalls, which may include similar components whose operation is similar to that described for computing device 500. However, as described elsewhere herein, such physical devices will typically perform network functions locally and implement virtual domains, rather than implementing VNF 524.

[0069] One or more processors 502 can execute VM 526 and VNF 524. Other examples of computing device 500 can be used in other instances. Although for illustrative purposes, such as Figure 5 The device is shown as a standalone computing device 500, but a computing device can be any component or system that includes one or more processors or other suitable computing environments for executing software instructions, and does not necessarily need to include, for example, a processor such as a processor or other suitable computing environment for executing software instructions. Figure 5 One or more components shown (e.g., communication unit 506; and in some examples, components such as storage devices 508 may not be located in the same location or in the same chassis as other components).

[0070] like Figure 5As shown in a specific example, computing device 500 includes one or more processors 502, one or more input devices 504, one or more communication units 506, one or more output devices 512, one or more storage devices 508, and a user interface (UI) device 510, as well as the communication unit 506. In one example, computing device 500 also includes one or more applications 522, a hypervisor 517, and an operating system 516 executable by computing device 500. Each of components 502, 504, 506, 508, 510, and 512 is coupled (physically, communicatively, and / or operatively) for inter-component communication. In some examples, communication channel 514 may include a system bus, a network connection, an inter-process communication data structure, or any other method for transmitting data. As an example, components 502, 504, 506, 508, 510, and 512 may be coupled via one or more communication channels 514.

[0071] In one example, processor 502 is configured to implement functional and / or processing instructions for execution within computing device 500. For example, processor 502 may be able to process instructions stored in storage device 508. Examples of processor 502 may include any one or more of a microprocessor, controller, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

[0072] One or more storage devices 508 may be configured to store information within computing device 500 during operation. In some examples, storage device 508 is described as a computer-readable storage medium. In some examples, storage device 508 is temporary memory, meaning that the primary purpose of storage device 508 is not long-term storage. In some examples, storage device 508 is described as volatile memory, meaning that storage device 508 does not retain its stored contents when the computer is turned off. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage device 508 is used to store program instructions executed by processor 502. In one example, storage device 508 is used by software or an application running on computing device 500 to temporarily store information during program execution.

[0073] In some examples, storage device 508 also includes one or more computer-readable storage media. Storage device 508 can be configured to store a larger amount of information than volatile memory. Storage device 508 can also be configured for long-term storage of information. In some examples, storage device 508 includes non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM).

[0074] In some examples, computing device 500 also includes one or more communication units 506. In one example, computing device 500 uses communication unit 506 to communicate with external devices via one or more networks, such as one or more wired / wireless / mobile networks. Communication unit 506 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device capable of sending and receiving information. In some examples, computing device 500 uses communication unit 506 to communicate with external devices. Communication unit 506 may include or be connected to one or more ports of computing device 500. Ports may be associated with different virtual domains used as a whole for VNF 524 or for configuration data 109 of computing device 500.

[0075] In one example, computing device 500 also includes one or more user interface devices 510. In some examples, user interface devices 510 are configured to receive input from a user via haptic, audio, or video feedback. Examples of the multiple user interface devices 510 include presence-sensitive displays, mice, keyboards, voice response systems, cameras, microphones, or any other type of device used to detect commands from the user. In some examples, presence-sensitive displays include touch-sensitive screens.

[0076] The computing device 500 may also include one or more output devices 512. In some examples, the output device 512 is configured to provide output to a user using tactile, audio, or video stimuli. In one example, the output device 512 includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting signals into an appropriate form that is understandable to humans or machines. Additional examples of the output device 512 include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate understandable output to a user.

[0077] Computing device 500 may include operating system 516. In some examples, operating system 516 controls the operation of components of computing device 500. For example, in one example, operating system 516 facilitates communication between one or more applications 522, hypervisor 517, VM 526, and VNF 524 and processor 502, communication unit 506, storage device 508, input device 504, user interface device 510, and output device 512. Application 522, hypervisor 517, VM 526, and VNF 524 may also include program instructions and / or data executable by computing device 500. Hypervisor 517 enables process-based or system-based VM 526 to execute as an isolated device instance for executing VNF 524. However, in some cases, computing device 500 may use container virtualization to execute VNF 524 as one or more deployed containers.

[0078] VNF 524 may represent an example instance of VNF 204 and store configuration data 109 and routes 125, which at least partially define the configuration and operation of VNF 204 to establish and implement a virtual domain as described above in detail with respect to VNF 204 and device 104 and in accordance with the techniques described in this disclosure. The virtual domain may be associated with different customers of the provider or reseller of VNF 524.

[0079] Figure 6 This is a flowchart illustrating an example operating mode of a device according to the technology described in this disclosure. This operating mode includes a setup phase and an operating phase. Although the operating phase is shown after the setup phase for illustrative purposes, this order is not necessary, as setup can occur in some cases while the device is in operating mode.

[0080] During the setup phase, a computing device, such as device 104 or VNF 204 (e.g., executed on a server), receives first configuration data 109, which defines a virtual domain 110A (600) for network function 105. The network function to be applied by virtual domain 110A can be managed and configured only by a first customer of the computing device provider, and cannot be configured by the provider. The first configuration data 109 can associate a first port of the computing device with virtual domain 110A. The computing device receives second configuration data 109 (602) defining a virtual domain 110K for network function 105. Virtual domains 110A and 110K are separate from each other. The second configuration data 109 can associate a second port of the computing device with virtual domain 110K.

[0081] The computing device receives third configuration data 109, which defines a virtual domain connection 121C (604) between virtual domain 110A and virtual domain 110K. The virtual domain connection 121C enables network services to be forwarded from virtual domain 110A to virtual domain 110K, and typically vice versa.

[0082] The computing device then receives network traffic at a first port of the computing device (the port of virtual domain 110A). This port may be connected to (or a port reached by the computing device) a first customer network (e.g., customer network 130) (606). Virtual domain 110A applies network function 105 to network traffic based on policies or other configurations set by the first customer for virtual domain 110A (608).

[0083] Virtual domain 110A forwards network traffic to virtual domain 110B (610) via virtual domain connection 112C. Virtual domain 110B applies network function 105 to network traffic based on policies or other configurations set by the second customer for virtual domain 110B (612). Virtual domain 110B can then forward network traffic to the second customer network (e.g., cloud service provider network 128) via a second port.

[0084] The techniques described herein can be implemented in hardware, software, firmware, or any combination thereof. Various features described as modules, units, or components can be implemented together in an integrated logic device, or individually as discrete but interoperable logic devices or other hardware devices. In some cases, various features of an electronic circuit can be implemented as one or more integrated circuit devices, such as integrated circuit chips or chipsets.

[0085] If implemented in hardware, this disclosure may relate to apparatus such as a processor or integrated circuit device (such as an integrated circuit chip or chipset). Alternatively or additionally, if implemented in software or firmware, the technology may be implemented at least in part by a computer-readable data storage medium including instructions that, when executed, cause the processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store these instructions executed by the processor.

[0086] Computer-readable media can form part of a computer program product and may include packaging materials. Computer-readable media may include computer data storage media such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, and so on. In some examples, the article of manufacture may include one or more computer-readable storage media.

[0087] In some examples, computer-readable storage media may include non-transitory media. The term "non-transitory" can indicate that the storage medium is not embodied in a carrier wave or a propagating signal. In some examples, non-transitory storage media may store data that can change over time (e.g., in RAM or cache).

[0088] The code or instructions can be software and / or firmware executed by processing circuitry, which includes one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described in this disclosure can be provided within software or hardware modules.

Claims

1. A computing device, comprising: A processing circuitry system coupled to a memory, the processing circuitry system and the memory being configured to implement: Network functionality; An external virtual domain for the network function is connected to a public network and managed by the provider of the computing device. as well as The virtual domain for the aforementioned network function is separate from the external virtual domain, configured with a secure tunnel interface, connected to the client network, and managed by the client of the provider of the computing device. The external virtual domain implements a route-based virtual private network to forward encrypted network traffic received from the public network via the secure tunnel to the secure tunnel interface configured in the virtual domain. The virtual domain is configured to decrypt the encrypted network service to generate a network service and forward the network service to the customer network.

2. The computing device according to claim 1, The virtual domain includes a first virtual domain, and the client network includes a first client network. The processing circuitry and the memory are further configured to implement: A second virtual domain for the aforementioned network function, which is separate from the first virtual domain and the external virtual domain, and is connected to a second client network. The first virtual domain and the second virtual domain are configured with virtual domain connections and routing information or firewall rules, so that the first virtual domain forwards selected network services received from the customer network to the second virtual domain for forwarding to the second customer network.

3. The computing device according to claim 2, wherein the second client network is a cloud service provider network.

4. The computing device according to claim 2, The secure tunnel interface mentioned above is the first secure tunnel interface. The second virtual domain is configured with a second secure tunnel interface. The external virtual domain implements the route-based virtual private network to forward other encrypted network services received from the public network via different security tunnels to the second secure tunnel interface in the second virtual domain, and The second virtual domain is configured to decrypt the other encrypted network services to generate other network services, and to forward the other network services to the second client network.

5. The computing device according to any one of claims 1-4, The computing device is configured to restrict the authorization granted to the provider for configuring the external virtual domain. The computing device is configured to allow the client to configure the virtual domain.

6. The computing device according to any one of claims 1-4, wherein the network function is a virtualized network function.

7. The computing device according to any one of claims 1-4, The route-based virtual private network includes routes that map prefixes to the secure tunnel interface and apply the routes to forward the encrypted network services to the secure tunnel interface configured in the virtual domain.

8. The computing device according to any one of claims 1-4, wherein the external virtual domain implements a virtual private network gateway.

9. The computing device according to any one of claims 1-4, wherein the virtual domain is configured to apply the network function to the network service before forwarding the network service to the client network.

10. The computing device according to any one of claims 1-4, The virtual domain includes one of a virtual routing and forwarding instance or a firewall domain that stores routing information received from the client network. The virtual domain is configured to apply the routing information to the network service in order to forward the network service to the customer network.

11. The computing device according to any one of claims 1-4, The customer network is connected to the virtual domain via a cloud switching infrastructure, and The public network is connected to the external virtual domain via the cloud exchange structure.

12. A computer networking method, comprising: Configuration data is received by the computing device, and the configuration data is defined as follows: An external virtual domain for network functionality, which is connected to a public network and managed by the provider of the computing device; The virtual domain for the network function is separate from the external virtual domain, is configured with a secure tunnel interface, is connected to the customer network, and is managed by the customer of the provider of the computing device. Encrypted network services received from the public network via a secure tunnel are forwarded from the external virtual domain that implements a route-based virtual private network to the secure tunnel interface configured in the virtual domain. The encrypted network service is decrypted by the virtual domain to generate the network service; as well as The network service is forwarded from the virtual domain to the customer network.

13. The method of claim 12, wherein the route-based virtual private network includes a route that maps a prefix to the secure tunnel interface, and the route is applied to forward the encrypted network service to the secure tunnel interface configured in the virtual domain.

14. A computing device, comprising: A processing circuitry system coupled to a memory, the processing circuitry system and the memory being configured to implement: Network functionality; A first virtual domain for the network function, the first virtual domain is connected to a first client network and is managed by a first client for the provider of the computing device; A second virtual domain for the network function, which is separate from the first virtual domain, is connected to a second client network and is managed by a second client of the provider of the computing device; as well as A virtual domain connection, which enables network services to be forwarded from the first virtual domain to the second virtual domain, is configured by the provider for the computing device. The first virtual domain is configured to apply the network function to the received network service before forwarding the received network service to the second virtual domain.

15. The computing device according to claim 14, The virtual domain connection mentioned above includes a first virtual domain connection, and The processing circuitry and the memory are further configured to implement: An external virtual domain for the network function, connected to a public network, managed by the provider for the computing device, and separate from the first and second virtual domains; and A second virtual domain connection, which enables network services to be forwarded from the external virtual domain to the second virtual domain, is configured by the provider for the computing device.

16. The computing device of claim 14, wherein the second virtual domain is configured to apply the network function to the second received network service before forwarding the second received network service to the second client network.

17. The computing device of claim 14, wherein the network function is a virtualized network function.

18. The computing device according to any one of claims 14-17, The computing device is configured to restrict the authorization used by the provider to configure the virtual domain connection, and The computing device is configured to allow the first client to configure the first virtual domain.

19. The computing device of claim 15, wherein the external virtual domain implements a virtual private network gateway.

20. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to perform the method according to any one of claims 12-13.

Images