Method, system, and computer-readable medium for providing a multi-tenant software-defined wide area network (SD-WAN) node

Abstract

A method occurs in a first network node in a service provider network for providing at least one service to multiple tenants, the method including: generating user configuration information for a first tenant using input from an administrator of the service provider network, transmitting at least a portion of the user configuration information to the first tenant, receiving first configuration information from the first tenant for configuring a first conduit for tunneling communications between the service provider network and a first site associated with the first tenant's SD-WAN, and configuring the first conduit using the first configuration information, wherein the first network node is associated with the multiple conduits, and a second conduit of the multiple conduits is at least partially configured by the second tenant but not the first tenant, and the method further includes tunneling communications between the service provider network and the first site via the first conduit.

Description

[Technical field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application Serial No. 16 / 586,300, filed September 27, 2019, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to communication networks. More particularly, the subject matter described herein relates to a method, system, and computer-readable medium for providing a multi-tenant software-defined wide area network (SD-WAN) node. [Background technology]

[0003] background A wide area network (WAN) may be used to connect multiple sites, offices, and / or local area networks (LANs) for networking. For example, an enterprise (e.g., a company or a university) may have several branches or offices in multiple locations that need to connect to a data center and to each other. In this example, the enterprise may use WAN links (e.g., dedicated telecommunications circuits and / or other technologies for physical and / or virtual connections, such as packet-switched or circuit-switched connections) to connect the various locations in the WAN and to maintain or achieve a desired service level (e.g., security requirements, bandwidth requirements, and / or latency requirements). Because the WAN may use encryption protocols and various network protocols in transmitting traffic over the WAN links, various network nodes may be required to route, process, and / or facilitate WAN-related communications.

[0004] A software-defined WAN (SD-WAN) involves using software-defined networking (SDN) concepts to create and manage a WAN. For example, an SD-WAN may include multiple physical and / or virtual nodes or devices that are programmable by a network controller to handle or facilitate WAN-related communications. An SD-WAN may also utilize lower-cost, commercially available Internet access and related network equipment instead of more expensive WAN connection technologies and specialized equipment. Although an SD-WAN may help connect multiple sites in an effective and cost-effective manner, problems may arise when trying to connect WAN users to networks or services, such as cloud services, controlled by others. For example, many cloud service providers serve multiple customers, making it impractical for a service provider to allow each enterprise to deploy SD-WAN equipment on its own network. It is also unlikely that a service provider will by default provide its cloud services (e.g., via an Internet connection) to all WAN-based users at the desired service level. Furthermore, because service providers do not have an effective and cost-effective way to provide reliable access to cloud services to an SD-WAN, SD-WAN users may not receive cloud services at the service level to which they are accustomed. Summary of the Invention

[0005] summary A method, system, and computer-readable medium for providing a multi-tenant software-defined wide area network (SD-WAN) node is disclosed. A method occurs in a first network node in a service provider network for providing at least one service to multiple tenants. The method includes generating user configuration information for a first tenant using input from an administrator of the service provider network, the user configuration information including a security key for enabling the first tenant to configure aspects of the first network node and an aggregate bandwidth limit associated with the first tenant, the method further includes transmitting at least a portion of the user configuration information to the first tenant, receiving first configuration information from the first tenant for configuring a first conduit for tunneling communications between the service provider network and a first site associated with the first tenant's SD-WAN, and configuring the first conduit using the first configuration information for tunneling communications between the service provider network and the first site, the first network node being associated with a plurality of conduits, a second conduit of the plurality of conduits being at least partially configured by the second tenant rather than the first tenant, the method further includes tunneling communications between the service provider network and the first site via the first conduit.

[0006] A system includes a first network node in a service provider network for providing at least one service to a plurality of tenants, the first network node including at least one processor and a memory. The first network node is configured to generate user configuration information for a first tenant using input from an administrator of the service provider network, the user configuration information including a security key for enabling the first tenant to configure aspects of the first network node and an aggregate bandwidth limit associated with the first tenant, the first network node is further configured to send at least a portion of the user configuration information to the first tenant, receive first configuration information from the first tenant for configuring a first conduit for tunneling communications between the service provider network and a first site associated with the first tenant's SD-WAN, and configure the first conduit using the first configuration information for tunneling communications between the service provider network and the first site, the first network node is associated with a plurality of conduits, a second conduit of the plurality of conduits is at least partially configured by the second tenant rather than the first tenant, and the first network node is further configured for tunneling communications between the service provider network and the first site via the first conduit.

[0007] The subject matter described herein may be implemented in software combined with hardware and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory devices such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms.

[0008] The term "node," as used herein, refers to at least one physical computing platform that includes one or more processors and memory.

[0009] The term "function" or "module" as used herein refers to software that combines with hardware and / or firmware to achieve the features described herein.

[0010] BRIEF DESCRIPTION OF THE DRAWINGS The subject matter described herein will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 illustrates an exemplary communications environment utilizing multi-tenant software-defined wide area network (SD-WAN) nodes. [Diagram 2]FIG. 1 illustrates an example SD-WAN node for providing cloud services to an adaptive private network (APN). [Diagram 3] FIG. 1 illustrates example APN configuration information that can be used to configure aspects of an SD-WAN node. [Figure 4A] FIG. 1 illustrates a graphical user interface (GUI) for configuring aspects of an SD-WAN node. [Figure 4B] FIG. 1 illustrates a graphical user interface (GUI) for configuring aspects of an SD-WAN node. [Figure 4C] FIG. 1 illustrates a graphical user interface (GUI) for configuring aspects of an SD-WAN node. [Diagram 5] FIG. 1 illustrates an example action for providing APN configuration information to an SD-WAN node. [Figure 6A] FIG. 2 illustrates an example message traversing a cloud conduit connecting an adaptive private network and a service provider network. [Figure 6B] FIG. 2 illustrates an example message traversing a cloud conduit connecting an adaptive private network and a service provider network. [Figure 7] FIG. 1 illustrates an example process for providing a multi-tenant SD-WAN node. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for providing a multi-tenant software-defined wide area network (SD-WAN) node. In general, an SD-WAN may be managed as a single administrative domain. For example, the nodes of an SD-WAN may be managed by a network administrator, who may have full control of the configuration parameters of the SD-WAN. However, many SD-WAN users want access to cloud services provided by third parties, and problems may arise when trying to provide such cloud services to SD-WAN users with service levels consistent with the SD-WAN.

[0013] One possible solution for connecting SD-WAN users and cloud services may involve placing an SD-WAN node within a service provider network. This local SD-WAN node may then be used to provide improved (e.g., more reliable) network paths to Internet-based applications or services hosted by the service provider. However, a service provider may not want to manage hundreds or thousands of SD-WAN nodes for its customers. Also, the service provider may not want to allow external network administrators unfettered access to the service provider network that would allow them to configure their own SD-WAN nodes. Thus, the service provider would prefer to control at least some aspects of any local SD-WAN nodes in its network.

[0014] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms for providing a multi-tenant SD-WAN node are disclosed. For example, a network node (e.g., an SD-WAN node) or a service gateway according to at least some aspects described herein may be in a service provider network and provide at least one service to one or more tenants (e.g., management domains, enterprises, or associated SD-WANs). In this example, the network node or service gateway, or aspects therein, may be securely managed from different management domains without the possibility of the different management domains interfering with each other. Continuing with this example, the different management domains may be prevented from interfering with each other by security measures (e.g., unique pre-shared keys) and / or access designs (e.g., tenant-specific bandwidth limits, tenant-specific and / or site-specific conduits, etc.).

[0015] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms are disclosed for receiving configuration information from multiple tenants and from a service provider and merging or shaping the configuration information into a single runtime configuration for an SD-WAN node that meets the requirements of the tenants and the service provider. For example, a network node or service gateway according to at least some aspects described herein may be configured to allow each tenant to configure aspects (e.g., encryption settings and protocol settings) of one or more conduits (e.g., communication tunnels that use multiple WAN links to connect a service provider network to an SD-WAN site) while allowing the service provider to configure various other aspects (e.g., the number of sites each tenant connects to the service provider network and the total bandwidth for each tenant). In this example, the configuration for each tenant may be performed independently and may occur at different times (e.g., the configuration is performed without requiring coordination between any of the tenants).

[0016] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms are disclosed for enabling an SD-WAN node to utilize a high-precision time synchronization mechanism to monitor conduits or their WAN links for latency and other issues, e.g., so that packets can be transmitted over the WAN links with the lowest latency. For example, an SD-WAN node may send and receive traffic over multiple WAN links associated with different tenants, each of which maintains its own time synchronization mechanism to monitor the status of their WAN links. Because each of the time synchronization mechanisms may be slightly different from one another, a network node or service gateway according to at least some aspects described herein may maintain and / or utilize a separate time synchronization mechanism (e.g., a master clock) for the conduits associated with the network node or service gateway. In another example, where an existing time synchronization mechanism is used by different tenants, for example, a network node or service gateway according to at least some aspects described herein may maintain and / or utilize a separate time synchronization mechanism for each conduit associated with the network node or service gateway.

[0017] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms are disclosed for identifying and / or distinguishing between SD-WANs and associated WAN links (which may use the same identifiers) associated with different tenants. For example, a network node or service gateway according to at least some aspects described herein may maintain or store WAN link identifiers associated with each tenant along with unique tenant and / or site identifiers. In this example, during configuration, when a network node or service gateway receives WAN link identifiers "1" and "2" associated with site "X" of tenant "A", the network node or service gateway may store the information using a data structure (e.g., a hash table using tenant and / or site identifiers as inputs and corresponding WAN link identifiers as outputs) such that the tenant and / or site identifiers can identify the corresponding WAN link identifiers, especially if the WAN link identifiers are not unique on their own.

[0018] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms for establishing and removing dynamic cloud conduits are disclosed. For example, upon detection of user traffic directed to or from the service provider, a cloud conduit may be established between an SDN-WAN node in the service provider network and a client device in a tenant's (e.g., enterprise network) SDN-WAN site. Once the cloud conduit is established, a heartbeat process may be used to determine when the cloud conduit is no longer needed. For example, the client device may periodically poll the SD-WAN node in the service provider network using a connection status request. In this example, the SD-WAN node may reply to the connection status request and may track any unsuccessful connection status requests from the client device. Continuing with this example, if a predetermined number of consecutive connection status requests are unsuccessful, the SD-WAN node may assume that the client device has stopped operating or no longer has a cloud conduit connection active. In response to determining that the cloud conduit is no longer needed, the SD-WAN node may automatically clean up the resources used for the connection to the client device such that the resources are available for use by other client devices.

[0019] Advantageously, by providing a multi-tenant SD-WAN node that can interact with or be part of a separate and independent SD-WAN, service providers can provide cloud services (e.g., Internet-based applications, cloud-based storage, etc.) to SD-WAN users in a more reliable, efficient, and cost-effective manner. For example, a multi-tenant SD-WAN node (e.g., an SD-WAN service gateway in a service provider network) can provide a solution to service providers that they can deploy and sell a reliable way to access business-critical Internet-hosted services as a service to their enterprise customers, with each tenant being able to configure aspects of the SD-WAN node while preventing each tenant from interfering with the service provider's or other tenants' configurations. The use of dynamic cloud conduits also allows service providers to use resources efficiently because the SD-WAN node can detect inactivity of a dynamic cloud conduit and release the associated resources associated with any inactive cloud conduit, thereby allowing the resources to be reallocated to another cloud conduit and / or tenant.

[0020] Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0021] FIG. 1 illustrates an example communication environment 100 utilizing SD-WAN nodes. With reference to FIG. 1, the communication environment 100 may include an adaptive private network (APN) 101 and a service provider network 102. The APN 101 may represent various network nodes, equipment, and user devices associated with an administrative domain. In this example, the APN 101 may also be referred to as an SD-WAN and may use SD-WAN technologies, WAN links, and related equipment to connect the sites together. For example, the APN 101 may represent an enterprise network that includes multiple sites (e.g., site 110 and site 112) communicatively connected via an SD-WAN node or equipment. In this example, the SD-WAN node or equipment may be configured to use the WAN links and related equipment to tunnel communications between the sites using encryption and encapsulation techniques.

[0022] Each of the sites 110 and 112 may represent a LAN, sub-network, or physical location (e.g., an office building) associated with the APN 101, and each site may include various devices, facilities, and / or equipment. As shown in FIG. 1, the site 110 may include a network controller (NC) 113 and data storage 118, and the site 112 may include a client appliance (CA) 116 and data storage 120. In some embodiments, a site including the NC 114 (e.g., the site 110) may not include or utilize a separate CA. Instead, in such embodiments, the NC 114 may include functionality similar to the CA 116 and may facilitate cloud conduit connections between the site 110 and other sites of the APN 101 and / or between the site 110 and the service provider network 102.

[0023] In some embodiments, APN 101 may have an active network controller (e.g., NC 114) and a standby network controller that may become active if a failover occurs. In such embodiments, the active network controller may be at the same site as the standby network controller or at a different site.

[0024] The NC 114 may represent any suitable entity (e.g., software running on a processor, an FPGA, an ASIC, or a combination of software, FPGA, and / or ASIC) for performing one or more aspects associated with controlling or managing the SD-WAN (e.g., the APN 101) and associated network nodes (e.g., the CA 116). In some embodiments, the NC 114 may be implemented using one or more processors and / or memory. For example, the NC 114 may utilize one or more processors (e.g., executing software stored in a memory) to configure the CA 116. In this example, the NC 114 may also utilize one or more processors to transmit instructions or network information to various modules or entities in the APN 101 or the service provider network 102. In some embodiments, the NC 114 may include or interact with a master clock controller, a time synchronization module, or related functionality. For example, the time synchronization module may be responsible for time synchronization with the APNs and may periodically transmit a synchronization signal (e.g., time synchronization information) to keep a common clock or slave clocks synchronized.

[0025] CA 116 may be any suitable entity (e.g., software running on a processor, an FPGA, an ASIC, or a combination of software, FPGA, and / or ASIC) for connecting sites in APN 101. In some embodiments, CA 116 may be configured to use one or more WAN conduits (e.g., logical entities) to tunnel communications between locations. In some embodiments, each conduit may use a WAN link (e.g., a group of IP addresses connected using commercially available Internet access, cellular networks, leased lines, and / or other connection technologies), and communications traversing the conduit may use one or more network protocols (e.g., encapsulation protocols) and / or encryption techniques.

[0026] In some embodiments, CA 116 may use network management protocols, link aggregation techniques, and / or congestion avoidance mechanisms to reduce latency, increase bandwidth, and otherwise maintain one or more reliable connections between sites 110 and 112. For example, CA 116 and / or SN 104 may monitor paths (e.g., WAN links) associated with conduits to track the status and latency of those paths and then transmit packets over viable (e.g., low-latency) paths. In this example, if a packet is lost, the packet may be retransmitted over a different path.

[0027] In some embodiments, monitoring a path (e.g., a WAN link) associated with a conduit may involve periodically (e.g., every 50 milliseconds) sending status update messages or other messages to the SN 104 and using information obtained from these messages to select an appropriate link for transmitting packets from one location to another.

[0028] Each of data storages 118 and 120 may represent any suitable entity (e.g., a computer-readable medium or memory) for storing APN configuration information, CA configuration information, and / or other data. For example, each of data storages 118 and 120 may store network information transmitted from NC 114 and may store state information associated with communications traversing WAN conduits.

[0029] The service provider network 102 may represent various network nodes, facilities, and / or devices associated with providing the cloud services 108. The service provider network 102 may include a service provider site 103 for interfacing with the cloud services 108 (e.g., internet-based applications, cloud-based storage, internet-based collaboration tools, etc.). For example, the service provider site 103 may include internet-facing hosts and servers for receiving and responding to user requests for the cloud services 108. In this example, the service provider site 103 may communicate with the cloud services 108 via various connection technologies and / or network facilities. For example, the cloud services 108 may include separate enterprise networks, data centers, and network facilities controlled by the service provider and may be connected to the service provider site 103 and / or the internet via multiple redundant connection technologies.

[0030] Cloud service 108 may represent any suitable entity (e.g., a network, node, device, facility, etc.) associated with providing or hosting an Internet-based or third-party hosted application or service. For example, cloud service 108 may include voice over Internet protocol (VoIP) services, software as a service (SAAS), or Internet backhaul services. In this example, communications (e.g., user responses) may be generated by one or more nodes associated with cloud service 108 and communicated to service provider site 103 via an internal network, an external network, a direct link, or other connection technology.

[0031] The service provider site 103 may include an SD-WAN node (SN) 104 and a data storage 106. The SN 104 may be any suitable entity (e.g., software and / or VMs running on one or more processors in a computing platform) for connecting the APN 101 and the service provider network 102. The data storage 106 may represent any suitable entity (e.g., a computer-readable medium or memory) for storing APN configuration information, SN configuration information, and / or other data. For example, the data storage 106 may store configuration information provided by tenants and by the service provider, and may also store state information associated with communications traversing cloud conduits, for example, between the service provider site 103 and sites 110 or 112.

[0032] In some embodiments, the SN 104 may represent a multi-tenant SD-WAN node and may be configurable to provide cloud services 108 to APNs or their sites controlled by different tenants (e.g., administrative domains) by utilizing configurable cloud conduits. For example, the SN 104 may be configured to use one or more cloud conduits (e.g., IP addresses of nodes in different networks or sites connected via the Internet) to tunnel communications between the APN 101 and the service provider network 102 using encryption and / or packet encapsulation. In another example, as shown in FIG. 2, the SN 104 may connect the service provider network 102 to multiple APNs via cloud conduits.

[0033] In some embodiments, each cloud conduit may use or include physical and / or virtual links (e.g., a group of IP addresses connected using commercially available Internet access, cellular networks, leased lines, and / or other connection technologies) and may be associated with various network protocols and / or encryption settings. For example, the cloud conduit's endpoints (e.g., CA 116 and SN 104) may transform or modify packets for conduit traversal, for example, by encapsulation, encryption, and / or packet header manipulation. In this example, the packet transformation and / or modification can obfuscate the identity of the conduit end users, thereby making it difficult for external entities (e.g., Internet-based nodes along the cloud conduit path) to identify the tenant's identity.

[0034] In some embodiments, the SN 104 may use network management protocols, link aggregation techniques, and / or congestion avoidance mechanisms to reduce latency, increase bandwidth, and otherwise maintain one or more reliable connections between the service provider network 102 and the APN 101 or sites therein. For example, the SN 104 may send status update messages over a conduit or its links every 50 milliseconds and may use information obtained from these messages to select an appropriate link for tunneling communications between the service provider network 102 and the APN 101 or sites therein.

[0035] In some embodiments, the SN 104 may be configured to provide at least one of the cloud services 108 to one or more tenants. For example, the APN 101 may represent a network associated with a tenant (e.g., the APN 101 or its administrator) authorized by the service provider to configure aspects of the SN 104 to establish one or more cloud conduits between the service provider network 102 and the APN 101 or sites therein. In this example, the SN 104 may be configured to allow other tenants (e.g., administrators of various other APNs) to manage aspects of the SN 104 without interfering with the APN 101. In this example, the SN 104 prevents such interference by using security measures (e.g., each tenant or associated APN has a unique security key for authentication) and access, authorization, and usage features that keep tenants and their workloads separate (e.g., tenant bandwidth limits set by the service provider, tenant-specific and / or site-specific conduits, etc.).

[0036] In some embodiments, the SN 104 may be configured to receive APN configuration information from tenants and other configuration information from a service provider, e.g., using an API, web-based interface, or user interface associated with the SN 104. For example, the SN 104 may facilitate tenant-related configuration of the SN 104 by allowing each tenant to configure one or more aspects of a cloud conduit (e.g., encryption settings and protocol settings) and to determine bandwidth allocation from one or more bandwidth capacities configured by the service provider. In this example, the SN 104 may also facilitate service provider-related configuration of the SN 104 by allowing the service provider to configure other aspects (e.g., security keys for each tenant, the number of sites each tenant can connect to the service provider network 102, and the total bandwidth for each tenant, APN, and / or site).

[0037] In some embodiments, configuration information from various sources may be merged or otherwise shaped into a run-time configuration for the SN 104 that meets tenant and service provider requirements. For example, when an APN administrator applies changes to his or her APN configuration, configuration parameters related to the SN 104 may be automatically detected and / or provided to the SN 104 via an API (e.g., a REST API). In this example, an API exposed by the service provider's SD-WAN node may allow updated configuration information to be received and merged into the configuration of the SN 104, e.g., at run-time.

[0038] In some embodiments, the SN 104 or associated entities may utilize one or more network protocols for detailed measurement and monitoring of the network to ensure that conduit traffic is transmitted and / or received. For example, managing cloud conduits may require high-resolution time synchronization and periodic exchange of messages regarding the status of routes and WAN links to identify and / or mitigate communication issues (e.g., latency, or perceived latency). Such conduit management may present challenges because each APN may use a separate time synchronization mechanism (e.g., a master clock) and therefore the notion of time may differ for each APN (e.g., SD-WAN).

[0039] In some embodiments, the SN 104 may be configured to utilize a local time synchronization mechanism (e.g., a master clock within the service provider network 102) to determine whether communications traversing a cloud conduit are stale or up-to-date. In one example, the SN 104 or associated entities may maintain and / or utilize separate time synchronization mechanisms for multiple cloud conduits, e.g., even though existing time synchronization mechanisms are used by different tenants. In another example, the SN 104 or associated entities may maintain and / or utilize separate time synchronization mechanisms for each conduit, e.g., even though existing time synchronization mechanisms are used by different tenants.

[0040] It will be understood that FIG. 1 is for illustrative purposes, and that various nodes and / or modules, locations and / or functionality described above in connection with FIG. 1 may be changed, modified, added, or removed.

[0041] 2 is a diagram illustrating an example SN 104 for providing cloud services to an APN. With reference to FIG. 2, the SN 104 may be in a service provider network 102 and may provide trusted access to cloud services 108 to the APN 200 via a cloud conduit.

[0042] APN 200 may include APN “A”, APN “B”, and APN “C”. Each of APN 200 may represent an SD-WAN network managed by a different tenant (e.g., enterprise domain or administrative domain). APN “A” may include CA 212, APN “B” may include CA 214, and APN “C” may include CA 216. Each of CAs 212-216 may have functionality similar to CA 116 as described above. For example, each of CAs 212-216 may communicate APN configuration information to SN 104 and may act as an endpoint for one or more cloud conduits between its respective APN (or its site) and service provider network 102.

[0043] The SN 104 may include an administration portal 208 and an SD-WAN gateway (SDWG) 210. The administration portal 208 may represent any suitable entity for providing a GUI or other means for configuring aspects of the SN 104 or an associated entity (e.g., SDWG 210). For example, the administration portal 208 may be a virtual appliance (e.g., a virtual machine (VM) or virtual container) running on the SN 104 (e.g., a computing platform) and may provide a web-based administration portal. In some embodiments, the administration portal 208 may be associated with a private IP address and port assigned by the service provider or associated administrator.

[0044] The SDWG 210 may represent any suitable entity for communicating user traffic through a cloud conduit. For example, the SDWG 210 may be a virtual appliance (e.g., a VM or virtual container) running on the SN 104 (e.g., a computing platform) and may set up and maintain cloud conduits for one or more APNs of the APNs 200 using configuration information provided by the management portal 208 or associated data storage (e.g., data storage 106). In this example, for each cloud conduit, at least some of the configuration information comes from an administrator of the service provider network 102 and at least some other configuration comes from an associated tenant (e.g., an entity that manages or controls the APNs and / or sites that connect to the service provider network 102 through the cloud conduit).

[0045] In some embodiments, prior to a cloud conduit being created or established, certain configuration information may be provided to the SN 104 from a tenant or associated node (e.g., NC 114 or CA 116). Exemplary configuration information provided to the SN 104 may include network or site configuration information and settings and may be usable to set up a correctly configured conduit to reliably route traffic between the service provider network 102 and the APN or its site. In some embodiments, the process of providing configuration information to the SN 104 may be referred to as a "mini" configuration, and the information provided in this process may be referred to as "mini" configuration information.

[0046] In some embodiments, cloud conduits may be dynamic with respect to creation and removal. For example, assuming a "mini" configuration process has been performed, the CA 116 may detect when user traffic is due to be directed to the service network provider 102 and may send a trigger message to the SDWG 210 to establish a dynamic cloud conduit. In this example, once the dynamic cloud conduit is established, user traffic may be sent through the cloud conduit. In this example, after determining that the cloud conduit is no longer needed or used (e.g., no user traffic is detected traversing the conduit or no status request is received from the CA 116 within a predetermined amount of time), the SDWG 210 may automatically clean up or deallocate resources used for the connection to the CA 116 so that the resources are available for (re)use.

[0047] In some embodiments, the administration portal 208 and the SDWG 210 may each be associated with a unique private IP address and port assigned by the service provider or associated administrator. In such embodiments, the NAT / router 204 may represent a device or equipment that uses a public IP address for receiving SN-related traffic and one or more ports for identifying whether the received SN-related traffic should be routed to the administration portal 208 and the SDWG 210. For example, traffic from APN "A" or an associated administrator may include either the administration port value or the gateway port value as the destination port in the encapsulation packet header. In this example, if the NAT / router 204 determines that the encapsulation packet header includes the administration port value as the destination port, the NAT / router 204 may route the packet to the private IP address and port associated with the administration portal 208, and if the NAT / router 204 determines that the encapsulation packet header includes the gateway port value as the destination port, the NAT / router 204 may route the packet to the private IP address and port associated with the SDWG 210.

[0048] In some embodiments, the SDWG 210 may be associated with multiple interfaces and / or IP addresses and ports. For example, the SDWG 210 may use at least one private IP address and at least one port for a southbound (SB) interface toward the APN 200 and at least one public IP address and at least one port for a northbound (NB) interface toward the cloud service 108. Example message flows traversing the SN 104 and elements therein are described below with respect to Figures 6A-6B.

[0049] It will be understood that FIG. 2 and its associated description are for illustration purposes, and that SN 104 and / or various other entities in FIG. 2 may include additional and / or different modules, components, or functionality.

[0050] FIG. 3 illustrates example APN configuration information 300 that can be used to configure aspects of an SD-WAN node (e.g., SN 104 or SDWG 210). In some embodiments, the APN configuration information 300 may include data from a “mini” configuration process that involves sending some initial configuration information from a site node (e.g., NC 114 or CA 116) to the SN 104. For example, the APN configuration information 300 may be provided to the SN 104 and may be used to set up a correctly configured conduit to reliably route traffic between the service provider network 102 and the APN or its site. In this example, the APN configuration information 300 may include a subset of network or site configuration information and may be communicated to the SN 104 before a conduit is created or used for a given APN or site.

[0051] In some embodiments, the APN configuration information 300 may be transmitted to the SN 104 in a data format readable by the SN 104 or a module therein. For example, as shown in FIG. 3, the APN configuration information 300 may be provided in an XML data format. In some embodiments, the APN configuration information 300 may include cloud global properties, cloud service default information, IPSec properties, advanced properties, cloud service properties, one or more rules, class information, cloud server (e.g., SN) properties, virtual WAN link information associated with the cloud server, auto-route group properties, site equipment (e.g., CA) properties, route information, additional cloud service properties, dynamic cloud conduit routing domain information associated with the cloud service, and / or additional virtual WAN link information associated with the cloud service.

[0052] In some embodiments, the APN configuration information 300 provided to the SN 104 may include only information that has recently been changed or added. For example, if an APN adjusts the network protocol used by its WAN links or adds additional encryption measures, the APN configuration information 300 provided to the SN 104 may include this changed or new information, while not providing configuration information that has not been changed.

[0053] A portion of an exemplary XML configuration file is illustrated with reference to Figure 3. The first line of the exemplary XML configuration file may include a "miniconfig" XML data element that indicates a name, revision number, and timestamp for the XML configuration file.

[0054] Lines 2-9 of the exemplary XML configuration file show a “cloud_global_properties” XML data element that indicates an encryption mode parameter (line 3), an extended message authentication parameter (line 4), an extended message authentication type (line 5), an extended packet uniqueness parameter (line 6), an extended re-enterable parameter (line 7), and a subscriber APN name parameter (line 8).

[0055] Lines 10-21 of the exemplary XML configuration file show a "virtual_wan_link_access" XML data element that indicates the WAN link name (line 11), property definition parameters (line 12), WAN link identifier parameters (line 13), access type parameters (line 14), WAN ingress physical rate limit parameters (line 15), WAN egress physical rate limit parameters (line 16), WAN ingress permitted rate limit parameters (line 17), WAN egress permitted rate limit parameters (line 18), maximum transmission units in bytes parameter (line 19), public IP address parameters (line 20), and enable public IP learning feature parameters (line 21).

[0056] It will be understood that Figure 3 and its associated description are for illustrative purposes, and that different and / or additional information may be available to configure an SD-WAN node or aspects thereof than that shown in Figure 3. For example, for all conduits and conduit-related services, the APN configuration information 300 may include parameters and settings to appropriately configure the SN 104 or SDWG 210 to handle various services via the conduits.

[0057] 4A-4C illustrate GUIs 400-404 for configuring aspects of an SD-WAN node (e.g., SN 104). In some embodiments, GUIs 400-404 may represent various pages provided by management portal 208 that can be used by a service provider or associated administrator to configure SN 104 or aspects thereof (e.g., SDWG 210). In some embodiments, GUIs 400-404 may also enable a service provider to enter various tenant-specific (e.g., subscriber-specific) information (e.g., bandwidth limits associated with a tenant, and maximum number of tenant sites allowed).

[0058] In some embodiments, an administrator of the service provider network 102 may need to configure the SN 104, add authorized subscribers (e.g., tenants), and add one or more authorized APNs that can utilize the SN 104. In some embodiments, the configuration related to the service provider may be performed prior to a tenant or subscriber providing the APN configuration information 300.

[0059] 4A, GUI 400 represents a page for receiving input for configuring a service gateway (e.g., SN 104 or SDWG 210). In some embodiments, GUI 400 may include groups of input fields associated with different configuration aspects and action buttons (e.g., an "Add" button for adding or storing the entered information and a "Cancel" button for closing or clearing the page (e.g., ignoring the entered information)).

[0060] As shown in GUI 400, the "General" group may include a service name input field for naming or identifying a particular SD-WAN node within the service provider network 102, and a bandwidth capacity input field for indicating an aggregate bandwidth limit associated with the SD-WAN node. For example, the aggregate bandwidth limit may be a value based on the service provider's hardware or other considerations, and this bandwidth limit may be enforced such that when bandwidth for all tenants of the SN 104 is taken into account, e.g., when combined, it does not exceed the aggregate bandwidth limit associated with the SD-WAN node.

[0061] The "Management / REST API Interface" group may include a public management IP address input field for entering a public IP address for connecting to SDWG 210, a management port input field for entering a port for connecting to SDWG 210, and a private management IP address input field for entering a private IP address for connecting to SDWG 210 (e.g., available through a NAT / router in service provider network 102).

[0062] The “Southbound Conduit Interface” group may include a public conduit IP address input field for entering a public IP address for connecting from the APN to an SD-WAN node in the service provider network 102, a first conduit port input field for entering a first port for connecting to an SD-WAN node in the service provider network 102, a second conduit port input field for entering a second port for connecting to an SD-WAN node in the service provider network 102, a southbound private VIP address input field for entering a private virtual IP (VIP) address for connecting to an APN-facing interface of the SDWG 210 (e.g., usable by a NAT / router in the service provider network 102), a southbound private gateway address input field for entering a gateway address for reaching a router that can be used to resolve the southbound private VIP address or an associated address range as indicated by the entered mask value, and a mask input field for entering a value to indicate an address range that may be assigned for the southbound conduit interface.

[0063] The "Northbound Service Interface" group may include a Northbound VIP Address input field for entering a private VIP address for connecting to an Internet-facing interface of SDWG 210 (e.g., usable by a NAT / router in service provider network 102), a Northbound Private Gateway Address input field for entering a gateway address for reaching a router that can be used to resolve the Northbound Private VIP address or an associated address range as indicated by the entered mask value, and a Mask input field for entering a value to indicate an address range that may be assigned for the Northbound Service Interface.

[0064] 4B, GUI 402 represents a page for receiving input for configuring a subscriber (e.g., a tenant). In some embodiments, GUI 402 may include multiple input fields associated with different configuration aspects and action buttons (e.g., a "Create Subscriber" button for adding or storing the entered information and a "Close" button for closing or clearing the page (e.g., ignoring the entered information).

[0065] As shown, the GUI 402 may include a subscriber name input field for entering a name or identifier to represent a particular subscriber, an email input field for entering an email address associated with the particular subscriber, a password input field for entering a password associated with the particular subscriber, a password confirmation input field for re-entering the password to confirm that the password entered in the password input field is correct, and a bandwidth capacity input field for entering a total bandwidth limit associated with the subscriber (e.g., the subscriber can manage bandwidth allocation among various sites and / or networks in the administration portal 208, but cannot exceed this subscriber bandwidth limit set by the service provider).

[0066] 4C, GUI 404 represents a page for receiving input for configuring a network (e.g., APN 101). In some embodiments, GUI 404 may include multiple input fields associated with different configuration aspects and action buttons (e.g., a "Create Network" button for adding or storing the entered information and a "Close" button for closing or clearing the page (e.g., ignoring the entered information)).

[0067] As shown, the GUI 404 may include a network name entry field for entering a name or identifier to represent a particular network, and a pre-shared key entry field for entering a pre-shared key (PSK) that can be used for authentication (e.g., so that only authorized subscribers can interact with and / or modify this network's configuration settings for the SN 104). The GUI 404 may also include a "New PSK" button for triggering the generation of a unique pre-shared key, for example, by a web server, a security device, or another entity.

[0068] The GUI 404 may also include a bandwidth limit per site for entering a bandwidth limit associated with each site (e.g., LAN, sub-network, or associated location) associated with the APN, and a bandwidth limit per network for entering a bandwidth limit associated with the APN. The bandwidth limit per network cannot exceed the total subscriber capacity (e.g., entered via the GUI 402). The GUI 404 may also provide feedback of remaining subscriber capacity based on the number of sites used and their associated entered bandwidth limits.

[0069] The GUI 404 may also include user interface elements for associating the APN with one or more service gateways (e.g., SD-WAN nodes in the service provider network 102). For example, the GUI 404 may include action buttons such as an "Add Service" button for selecting a service gateway to associate with the APN and a "Remove Service" button for disassociating the service gateway from the APN. In this example, the GUI 404 may provide a table or visual element to show the maximum bandwidth and maximum connections allowed for each associated service gateway.

[0070] It will be understood that FIGS. 4A-4C and their associated description are for illustrative purposes, and that additional and / or different user interface elements may be available for inputting various information to facilitate configuring aspects of the SD-WAN node by a service provider or associated administrator.

[0071] 5 is a diagram illustrating example actions for providing APN configuration information to the SN 104. In some embodiments, the APN configuration information may be stored in a data file in one or more formats or may be transmitted to the SN 104 via a web GUI, API, or other communication interface. In such embodiments, the SN 104 may use the received APN configuration information to create or establish one or more cloud conduits between the SN 104 and an associated APN.

[0072] 5, in step 501, the NC 114 may transmit the APN configuration information 300 to the CA 116. For example, the NC 114 may have access to most, if not all, of the relevant APN configuration information 300 and may provide this information to the CA 116 periodically (e.g., every 10 minutes), dynamically (e.g., upon detection of an SD-WAN change), or on request.

[0073] In step 502, the CA 116 may receive the APN configuration information 300 and, if necessary, may modify the APN configuration information 300 or generate additional configuration information. For example, the CA 116 may generate or modify site-specific configuration information and add this information to the APN configuration information 300 obtained from the NC 114.

[0074] In step 503, the CA 116 may send the APN configuration information 300 to the SN 104. For example, the CA 116 may utilize a REST API or another mechanism to upload the APN configuration file to the SN 104.

[0075] At step 504, the SN 104 may receive the APN configuration information 300 and may parse and store the APN configuration information 300 for future use. For example, the SN 104 may store various APN configuration settings in a data structure such that the associated APN configuration settings are recoverable when creating a conduit that connects to an APN or an associated site.

[0076] 5 is for illustrative purposes and that different and / or additional messages, steps, and / or actions may be used. For example, instead of the CA 116 communicating the APN configuration information 300, another entity (e.g., a network controller or administrator using a web-based interface) may provide the APN configuration information 300. It will also be understood that the various messages, steps, and / or actions described herein may occur in a different order or sequence.

[0077] 6A-6B are diagrams illustrating example messages traversing a cloud conduit connecting an APN and a service provider network. In particular, FIG. 6A illustrates egress message flow from host 600 in APN "A" to SDWG 210, and FIG. 6B illustrates ingress message flow from SDWG 210 to host 600.

[0078] In some embodiments, a cloud conduit may utilize one or more WAN links (e.g., connections between public IP addresses) that allow traffic to be tunneled between an APN (or associated site) and a service provider network. For example, the conduit may send packets between a public IP address of CA 212 (or associated device) in APN "A" and NAT / router 204 in service provider network 102. By utilizing multiple WAN links in this example, the cloud conduit has inherent reliability even if some of the WAN links go down or have communication problems.

[0079] In some embodiments, a cloud conduit may be configured to transmit communications using a set of encryption and / or protocol settings configured by the APN or an associated administrator. In some embodiments, a cloud conduit may be dynamic in nature. For example, a cloud conduit may be set up after a message destined for a service provider network is detected, for example, by CA 212. In such an embodiment, the message may need to be queued until establishment of the cloud conduit is complete.

[0080] In some embodiments, the SDWG 210 of the SN 104 or another entity may learn or derive the public IP addresses of the WAN links associated with various APNs or their sites. For example, the SDWG 210 may receive encrypted packets via a cloud conduit connecting the SDWG 210 and the CA 212, but the SDWG 210 may be unaware of the public IP address associated with the CA 212. In this example, to determine or learn the public IP address associated with the CA 212, the SDWG 210 may attempt to decrypt the packet using different site keys (e.g., previously generated by the service provider and stored in the data storage 106) until the packet decryption is successful and after successful decryption, the SDWG 210 sees the source IP address and source port in the packet header. Once the source IP address and source port are learned, the SDWG 210 of the SN 104 or another entity may associate the learned source IP address and source port with various tenant-related identifiers. For example, the SDWG 210 may maintain routing table information using a hash-based data structure. In this example, the hash key may be based on a source IP address (public or external) and a source port, and the corresponding hash entry is based on an APN identifier, a WAN link identifier, and a site identifier. In this example, because the combination of a WAN link identifier, an associated APN identifier, and an associated site identifier is unique, SDWG 210 can identify the associated WAN link associated with a site or conduit even when multiple tenants use the same WAN link identifier.

[0081] 6A, in step 601, a request packet (e.g., an Internet Control Management Protocol Echo Request packet) may be sent from host 600 in APN "A". The request packet may include a header indicating an IP address associated with host 600 as the source address and an IP address associated with an Internet-based service as the destination address. The request message may be destined for an Internet service provider, e.g., an Office 365 web-based application.

[0082] At step 602, CA 212 may receive the request packet and may process the request packet for transmission via the cloud conduit. In some embodiments, CA 212 may process the request packet by changing the source address in the request packet header to a WAN link IP address and port associated with CA 212, and may encapsulate the request packet by adding an encapsulation header and / or by encrypting the request packet, for example as a payload in the encapsulated packet.

[0083] In some embodiments, the source IP address and / or other parameters in the request packet header (e.g., step 601) may be altered or hidden from the service provider and other tenants for privacy purposes. For example, such obfuscation may be utilized to make it difficult for a service provider or another entity to identify the identity of an endpoint sending a packet traversing a cloud conduit.

[0084] In some embodiments, the encapsulated packet may include an encapsulation header (e.g., a Talari reliable protocol (TRP) header) indicating the WAN link IP address as the source address, an IP address associated with the NAT / router 204 as the destination address, and / or a conduit port as the source and destination ports.

[0085] At step 603 , the encapsulated packet may be sent to the NAT / router 204 associated with the SN 104 .

[0086] In step 604, the NAT / router 204 may receive the encapsulated packet and inspect its header to determine whether to route the packet to the SN 104. For example, if the encapsulated packet header indicates a conduit port as the destination port, the NAT / router 204 may modify the destination address and / or destination port in the encapsulated packet header to direct the encapsulated packet to the SDWG 210.

[0087] In some embodiments, the NAT / router 204 may store state information about the encapsulated packet and / or the inner request packet to identify the appropriate conduit and / or destination within APN "A" when sending back a corresponding response packet. For example, the NAT / router 204 may use a data structure (e.g., a hash table or dictionary) that maps a data tuple (e.g., a source IP address and a source port).

[0088] In step 605 , the encapsulated packet may be sent to the SDWG 210 .

[0089] In step 606, the SDWG 210 may receive the encapsulated packet and may decapsulate the encapsulated packet, for example, by stripping off the encapsulation header. The SDWG 210 may also modify the source address associated with the request packet from a WAN link IP address associated with the CA 212 to a “northbound” IP address associated with the NAT / router 202 for routing traffic destined for the cloud service 108.

[0090] In some embodiments, the NAT / router 202 may store state information about the request packet in order to identify the appropriate conduit and / or destination within APN "A" when a corresponding response packet is sent back. For example, the NAT / router 204 may use a data structure that maps a data tuple (e.g., source IP address and source port).

[0091] In some embodiments, the NAT / router 202 may forward or send the request packet to its destination (e.g., IP address "8.8.8.8"). For example, a service node in the service provider network 102 may process the request packet and a corresponding response may be generated and sent back to the NAT / router 202 associated with the SN 104. In this example, the NAT / router 202 may receive the response packet and send or forward the response packet to the SDWG 210.

[0092] 6B, in step 607, SDWG 210 may receive a response packet corresponding to the request packet and may process the response packet for transmission through the cloud conduit. In some embodiments, SDWG 210 may process the response packet by changing the destination address in the response packet header to an IP address associated with NAT / router 204, and may encapsulate the response packet by adding an encapsulation header and / or by encrypting the response packet, for example, as a payload in the encapsulated packet. In some embodiments, the encapsulated packet may include an encapsulation header (e.g., a TRP header) indicating a private IP address associated with SDWG 210 as the source address, a "southbound" IP address associated with NAT / router 204 as the destination address, and the conduit ports as the source and destination ports.

[0093] At step 608 , the encapsulated packet may be sent to the NAT / router 204 associated with the SN 104 .

[0094] In step 609, NAT / router 204 may receive the encapsulated packet and inspect its header to determine which conduit to use to route the encapsulated packet. For example, if the encapsulated packet header indicates a conduit to CA 212 (e.g., based on one or more identifiers, or a hash of various values), NAT / router 204 may change the destination address to a WAN link IP address and / or destination port associated with CA 212 in the encapsulated packet header to direct the encapsulated packet to CA 212. In some embodiments, NAT / router 204 may change the source address in the encapsulated packet header to a public IP address associated with NAT / router 204.

[0095] At step 610 , the encapsulated packet may be sent to the CA 212 . In step 611, CA 212 may receive the encapsulated packet and may decapsulate the encapsulated packet, for example, by stripping off the encapsulation header. CA 212 may also modify the destination address associated with the response packet from the WAN link IP address associated with CA 212 to an IP address associated with host 600.

[0096] In step 612 , the CA 212 may send a response packet to the host 600 . It will be understood that Figure 6 is for illustrative purposes and that different and / or additional messages, steps, and / or actions may be used. It will also be understood that the various messages, steps, and / or actions described herein may occur in a different order or sequence.

[0097] 7 illustrates an example process 700 for providing a multi-tenant SD-WAN node. In some embodiments, the example process 700 described herein, or portions thereof, may be performed in or by a network node (e.g., the SN 104), the SDWG 210, and / or another module or node.

[0098] With reference to example process 700, user configuration information for a first tenant may be generated using input from an administrator of the service provider network at step 702. In some embodiments, the user configuration information may include a security key to enable the first tenant to configure aspects of the first network node and an aggregate bandwidth limit associated with the first tenant.

[0099] At least a portion of the user configuration information may be sent to the first tenant in step 704. For example, the user configuration information may include a pre-shared key, a service bandwidth limit, a per-conduit bandwidth limit, a per-site bandwidth limit, and / or a per-network bandwidth limit. In this example, the user configuration information may be configured by the service provider or an associated administrator, or the user configuration information may be provided via an API or user interface.

[0100] In step 706, first configuration information may be received from the first tenant for configuring a first conduit for tunneling communications between the service provider network and a first site associated with the first tenant's SD-WAN.

[0101] For example, the CA 116 or NC 114 may send a message containing a "mini" configuration file to the SN 104 via the REST API and / or the web-based management portal 208. In this example, the message may be directed to an IP address associated with the SN 104 and may include a pre-shared key provided by the SN 104 to the CA 116 or NC 114.

[0102] In step 708, a first conduit for tunneling communications between the service provider network and the first site may be configured using first configuration information (e.g., “mini” configuration information), the first network node being associated with a plurality of conduits, and a second conduit of the plurality of conduits being at least partially configured by the second tenant rather than the first tenant.

[0103] In some embodiments, the first conduit may be configured after receiving the first configuration information. In such embodiments, the first conduit may be established in response to a trigger message. For example, the trigger message may be a message for requesting at least one service or a message destined for the service provider network. In this example, the trigger message may include any message destined for the service provider network 102 or any message for requesting one or more of the cloud services 108 and / or any message destined for the service provider network 102. Continuing with this example, the first conduit may be removed (e.g., associated allocated resources in the SN 104 may be released) upon detection of inactivity for a predetermined amount of time.

[0104] At step 710, communications between the service provider network and the first site may be tunneled through a first conduit. In some embodiments, communications traversing the first conduit may be encapsulated using a first set of protocol settings and / or encryption settings, and communications traversing the second conduit may be encapsulated using the first set of protocol settings and / or encryption settings, the first set of protocol settings and / or encryption settings being different from the second set of protocol settings and / or encryption settings.

[0105] In some embodiments, conduit status information and time synchronization information associated with the first site may be communicated over the first conduit using a representational state transfer application programming interface (REST API) and / or an encapsulation protocol. For example, the first conduit may use an advanced encryption standard (AES) encrypted tunneling protocol (e.g., a proprietary conduit protocol) that uses an encapsulating security payload (ESP) tunnel type and a 32-bit secure hash algorithm (SHA)-based hash value, and the second conduit may use a different tunneling protocol that uses an authentication header (AH) tunnel type and a 64-bit SHA-based hash value.

[0106] In some embodiments, a tenant may represent or include an entity (e.g., a business or company), a network (e.g., APN 101) or a site (e.g., site 110) associated with the entity, or a device, node, or equipment associated with the entity. For example, a first tenant may include a CA 116, an NC 114, or a network administrator associated with APN 101.

[0107] In some embodiments, the first network node may include a gateway and a controller implemented using one or more virtual machines or virtual containers. For example, the SN 104 may include the SDWG 210 and the administration portal 208, which are Linux-based virtual machines.

[0108] In some embodiments, the first conduit may be associated with a first time manager implemented in a first network node or node within the service provider network, the first time manager being separate from a second time manager implemented in a network controller or node within the first tenant's SD-WAN. For example, the SN 104 may utilize a master clock or other time synchronization mechanism for communications over one or more cloud conduits associated with the service provider network 102 (e.g., service provider site 103). In this example, the NC 114 may provide or utilize a separate master clock or other time synchronization mechanism for communications within site 110 and / or site 112.

[0109] In some embodiments, process 700 may further include receiving second configuration information (e.g., “mini” configuration information) from the first tenant for configuring a third conduit for tunneling communications between the service provider network and a second site associated with the first tenant's SD-WAN; and configuring the third conduit using the second configuration information for tunneling communications between the service provider network and the second site associated with the first tenant's SD-WAN, wherein a combined bandwidth of the first conduit and the third conduit does not exceed an aggregate bandwidth limit associated with the first tenant, and the process may further include tunneling communications between the service provider network and the second site associated with the first tenant's SD-WAN via the third conduit.

[0110] In some embodiments, the process 700 may further include learning a public IP address associated with a first site (e.g., site 112), where learning the public IP address includes receiving the encrypted packet via the first conduit, decrypting the encrypted packet using stored pre-shared keys associated with different sites until the encrypted packet is successfully decrypted, and identifying the public IP address from the decrypted packet header. For example, the SN 104 or SDGW 210 may learn the IP address associated with the CA 116 by attempting to decrypt the packet using different pre-shared keys associated with various APNs or tenants. In this example, after the pre-shared keys successfully decrypt the packet, the SN 104 or SDGW 210 may associate the IP source address and source port located in the packet header of the packet with the associated APN identifier, WAN link identifier, and site identifier.

[0111] In some embodiments, the process 700 may further include maintaining statistics and / or traffic monitoring information associated with each conduit, site, and / or tenant.

[0112] 7 is for illustrative purposes and that different and / or additional steps and / or actions may be used. It will also be understood that the various steps and / or actions described herein may occur in differing orders or sequences.

[0113] It should be noted that the network nodes, SN 104, SDWG 210, and / or functionality described herein may constitute special purpose computing devices. Also, the network nodes, SN 104, SDWG 210, and / or functionality described herein may improve the technical field of communication networks and SD-WAN connectivity. For example, by providing a SN 104 in a service provider network that can facilitate conduits configured by multiple tenants, SD-WAN users can receive cloud services in a reliable manner and / or with reliable service levels. Also, by using multi-tenant SD-WAN nodes, service providers can provide cloud services to SD-WAN users associated with multiple tenants more reliably and in an efficient and cost-effective manner.

[0114] It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Moreover, the foregoing description is for purposes of illustration only, and not for purposes of limitation.

Claims

1. 1. A method for providing a multi-tenant software-defined wide area network (SD-WAN) node, the method comprising: A first network node in a service provider network for providing at least one service to a plurality of tenants, generating user configuration information for a first tenant using input from an administrator of the service provider network, the user configuration information including a security key for authentication of the first tenant and an aggregate bandwidth limit associated with the first tenant, the method further comprising: transmitting at least a portion of the user configuration information to the first tenant; receiving first configuration information from the first tenant for configuring a first conduit for tunneling communications between the service provider network and a first site associated with the first tenant's SD-WAN; and configuring the first conduit for tunneling communications between the service provider network and the first site using the first configuration information, the first network node being associated with a plurality of conduits, a second conduit of the plurality of conduits being at least partially configured by a second tenant rather than the first tenant, the method further comprising: The method includes tunneling communications between the service provider network and the first site through the first conduit.

2. 2. The method of claim 1, wherein the communications traversing the first conduit are encapsulated using a first set of protocol and / or encryption settings and the communications traversing the second conduit are encapsulated using a second set of protocol and / or encryption settings, the first set of protocol and / or encryption settings being different from the second set of protocol and / or encryption settings.

3. 3. The method of claim 1 or 2, wherein the step of configuring the first conduit is in response to a trigger message, the trigger message being a message for requesting the at least one service or a message destined for the service provider network, and the first conduit is removed when inactivity for a predetermined amount of time is detected.

4. 4. The method of claim 1, further comprising: at the first network node, learning a public Internet Protocol (IP) address associated with the first site, the learning of the public IP address comprising: receiving an encrypted packet via the first conduit; decrypting the encrypted packet using a stored pre-shared key associated with a different site until the encrypted packet is successfully decrypted; and identifying the public IP address from the decrypted packet header.

5. The method of any one of claims 1 to 4, wherein conduit status information and time synchronization information associated with the first site are communicated via the first conduit using a Representational State Transfer Application Programming Interface (REST API) and / or an encapsulation protocol.

6. 6. The method of claim 1, wherein the first network node includes a gateway and a controller implemented using one or more virtual machines or virtual containers, and the first conduit utilizes multiple WAN links for reliability.

7. The method of any one of claims 1 to 6, wherein the first conduit is associated with a first time manager implemented in the first network node or a node in the service provider network, the first time manager being separate from a second time manager implemented in a network controller or a node in the SD-WAN of the first tenant.

8. receiving second configuration information from the first tenant for configuring a third conduit for tunneling communications between the service provider network and a second site associated with the SD-WAN of the first tenant; and configuring the third conduit for tunneling communications between the service provider network and the second site using the second configuration information, wherein a combined bandwidth of the first conduit and the third conduit does not exceed the aggregate bandwidth limit; and A method according to any preceding claim, comprising the step of tunnelling communications between the service provider network and the second site through the third conduit.

9. A method according to any preceding claim, comprising maintaining statistical and / or traffic monitoring information associated with each conduit, site and / or tenant.

10. 1. A system for providing a multi-tenant software-defined wide area network (SD-WAN) node, the system comprising: A first network node in a service provider network for providing at least one service to a plurality of tenants, the first network node comprising: At least one processor; [0023] a memory; A system, wherein the first network node is configured to perform the method according to any one of claims 1 to 9.

11. A program which, when executed by at least one processor of the first network node, causes the first network node to perform the steps of any one of claims 1 to 9.

Images