Selecting end-to-end paths with dynamic software-defined cloud interconnection (SDCI) tunnels

Abstract

Techniques for computing end-to-end SLA-aware paths using cloud services that use dynamic software-defined cloud interconnect (SDCI) tunnels between user devices and access point of presence (POP) nodes and inter-POP tunnels of the SDCI. The cloud services can include a performance-aware path instantiation (PAPI) component that includes a POP database for storing performance metrics associated with POPs of the SDCI, an enterprise policy database for storing user-specific policies, and / or a path computation component. The path computation component can compute a path based on the user-specific policies, the performance metrics associated with the POP nodes, and / or real-time context data associated with the user device and / or a destination device. The path can include a first tunnel between the user device and an optimal access POP node of the SDCI and a second tunnel from the access POP node through internal POP nodes to the destination device.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 385,520, filed July 26, 2021, entitled “End-to-End Path Selection with Dynamic Software-Defined Cloud Interconnection (SDCI) Tunneling,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to dynamic software-defined cloud interconnect (SDCI) tunnels between user equipment and optimal edge point of presence (POP) nodes, and to end-to-end service level agreement (SLA) aware paths for inter-POP tunnels of SDCI. Background Technology

[0004] With the evolution of Software as a Service (SaaS), Platform as a Service (PaaS), and Internet as a Service (IAAS), and the increased use of cloud services by enterprises, the nature of traffic flows has shifted from the traditional model of all user traffic (both business and non-business traffic) converging to centralized data centers (DCs). With the introduction of SaaS, multi-cloud, and hybrid cloud models, access to such cloud services is evolving into a Direct Internet Access (DIA) model, in which user traffic directly accesses applications on multiple different cloud-hosted systems. Therefore, direct traffic between remote workers and cloud services is common. However, as more business traffic uses the internet as its underlying layer, Quality of Service (QoS) relies primarily on the quality of the internet connection. Therefore, traffic flows from users to cloud services may be limited to those without Service Level Agreement (SLA) guarantees.

[0005] While Software-Defined Wide Area Networks (SDWAN) are an option, they may not be the most viable choice for all connectivity scenarios. Specifically, SLAs supporting remote workers have many limitations; for example, not all home networks are dual-homed (e.g., Multiprotocol Label Switching (MPLS) or multiple Internet Service Providers (ISPs)); there are no dedicated bandwidth guarantees from ISPs; and any delays or interruptions in the transit path may offer little or no insight into diverting traffic to alternative paths. Using 4G and / or 5G as backup paths is not a cost-effective solution, and end-to-end diversification is not guaranteed. Furthermore, creating tunnels to the nearest data center (DC) to route traffic to a dedicated (SLA-guaranteed) link from the DC to the cloud is ineffective, as users may ultimately route traffic from coast to coast depending on the DC's location. Attached Figure Description

[0006] The following detailed description is given with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals indicate the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to denote similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale relative to each other.

[0007] Figure 1 A system architecture diagram of an example environment for implementing at least some of the various techniques disclosed herein is shown. This environment includes an SDWAN controller for collecting performance metrics associated with multiple Points of Presence (POP) nodes of a Software-Defined Cloud Interconnect (SDCI) service, and a cloud service for calculating dynamic end-to-end performance and SLA-aware paths from user equipment to destination equipment.

[0008] Figure 2 A component diagram of an example cloud service, including the Performance-Aware Path Instantiation (PAPI) component, is shown.

[0009] Figure 3 The system architecture diagram shows an example environment for a cloud service that includes an SDWAN controller and a dynamic SDCI tunnel between user equipment and optimal edge POP nodes, as well as an SDCI inter-POP tunnel for calculating end-to-end SLA-aware paths.

[0010] Figure 4 A system architecture diagram is shown for an example environment including an SDWAN controller and cloud services, as well as an example end-to-end overlay for routing traffic from user equipment to destination equipment using an SDCIPOP tunnel.

[0011] Figure 5 A flowchart is shown as an example method for calculating end-to-end SLA-aware paths using cloud services, which utilizes dynamic SDCI tunnels between user equipment and optimal edge POP nodes, as well as inter-POP tunnels for SDCI.

[0012] Figure 6 A flowchart is shown of an example method for calculating an end-to-end SLA-aware path using cloud services, leveraging dynamic SDCI tunnels between user devices and optimal edge POP nodes, and inter-POP tunnels of SDCI.

[0013] Figure 7 A computer architecture diagram is shown, illustrating an example computer hardware architecture for implementing a network device that can be used to implement various aspects of the various technologies presented herein. Detailed Implementation

[0014] Overview

[0015] The invention is set forth in the independent claims, and preferred features are set forth in the dependent claims. These aspects may be implemented individually or in combination with each other. A feature of one aspect may be applied to each aspect individually or in combination with other aspects.

[0016] This disclosure describes a method for calculating an end-to-end SLA-aware path using a cloud service, employing a dynamic SDCI tunnel between a user device and an optimal edge point of presence (POP) node, as well as inter-POP tunnels of the SDCI. The method includes: receiving a request for an end-to-end path between a client device and a destination device at a cloud service. The end-to-end path can be established at least partially using Software-Defined Cloud Interconnect (SDCI). The method may further include: identifying performance requirements associated with a user account for transmitting traffic on the end-to-end path for a user account associated with the client device. The method may further include: identifying performance data indicating performance metrics for one or more paths between one or more points of presence (POPs) of the SDCI. The method may further include: calculating the path between the user device and the destination device at a cloud service, at least partially based on performance metrics associated with one or more paths that satisfy the performance requirements associated with the user account. The method may further include: enabling data to be transmitted from the client device to the destination device using the path.

[0017] Additionally or alternatively, the method includes: receiving a request for an end-to-end path between a client device and a destination device at a cloud service. The request may indicate performance requirements associated with a user account for delivering traffic over the end-to-end path. The end-to-end path may be established at least partially using Software-Defined Cloud Interconnect (SDCI). The method may further include: identifying performance data indicating performance metrics for one or more paths between one or more points of presence (POPs) of the SDCI. The method may further include: calculating, at least partially, a path between the user device and the destination device at a cloud service based on performance metrics associated with the one or more paths, the one or more paths satisfying performance requirements associated with the user account. The method may further include: using the path to deliver data from the client device to the destination device.

[0018] The techniques described in this disclosure can be performed as a method and / or executed by a system having a non-transitory computer-readable medium storing computer-executable instructions, wherein the non-transitory computer-readable medium performs the above techniques when the computer-executable instructions are executed by one or more processors.

[0019] Example Implementation

[0020] As mentioned above, there are many limitations to supporting SLAs for remote workers. For example, not all home networks are dual-homed (e.g., Multiprotocol Label Switching (MPLS) or multiple Internet Service Providers (ISPs)), there is no dedicated bandwidth guarantee from the ISP, and any delays or interruptions in the transit path may have little or no inspiration for shifting traffic to an alternative path. Using 4G and / or 5G as a backup path is not a cost-effective solution, and there is no guarantee of end-to-end diversified paths. Furthermore, creating a tunnel to the nearest data center to route traffic to a dedicated (SLA) guaranteed link from the data center to the cloud is ineffective because users may end up routing traffic from shore to shore depending on the location of the data center.

[0021] This disclosure describes techniques for cloud services including a Performance-Aware Path Instantiation (PAPI) component that can access real-time performance metrics and user-specific policies associated with a point-of-presence (POP) node of a Software-Defined Cloud Interconnection (SDCI) service (e.g., Megaport) to compute an end-to-end Service Level Agreement (SLA)-aware path that connects the user device to a destination device and / or service using a dynamic SDCI tunnel between the user device and the optimal edge access POP node, as well as inter-POP tunnels of the SDCI. The SDCI service may include multiple edge access POP nodes distributed across the Internet that the user can connect to. As previously described, the cloud service may include PAPI components (e.g., but not limited to Domain Name Service (DNS) layer security components, secure web gateway components, cloud delivery firewall components, and / or cloud access security broker (CASB) components) and may be configured to provide various additional cloud services. The cloud service may be associated with a software-defined wide area network (SD-WAN) controller configured to collect real-time performance metrics between hosting facilities (e.g., data center facilities associated with an enterprise and / or user), SDCIPOP nodes, various additional cloud services (e.g., SaaS, virtual machines, etc.), and various access networks. Additionally or alternatively, the SDCI service may communicate with the cloud service and / or the SD-WAN controller to periodically provide SDCI internal network telemetry data (e.g., performance metrics associated with tunnels between SDCI internal POP nodes). The PAPI component may also include an enterprise policy database, a POP database, and / or a path calculation component. The enterprise policy database stores policies for each user and / or each tenant, the POP database stores real-time performance metrics associated with SDCI edge access POP nodes and / or internal POP nodes, and the path calculation component is configured to use data included in the enterprise policy database and / or POP database to calculate the path from the user device to the destination device and / or service.

[0022] As previously mentioned, cloud services can leverage various components (e.g., PAPI components, DNS layer security components, secure web gateway components, cloud delivery firewall components, and / or CASB components) to provide cloud services. In some examples, the PAPI component can be configured to access real-time performance metrics and user-specific enterprise policies associated with the SDCIPOP node to compute an end-to-end SLA-aware path connecting the user device to the destination device and / or service. In some examples, this path may include a first tunnel (also referred to herein as an external tunnel) from the user device to an edge POP node (also referred to herein as an access POP node), which is determined to be the optimal edge POP node for the user device. For example, the PAPI component can utilize real-time contextual information (e.g., the location of the user device, the location of the destination device and / or service, SLAs associated with the user device, and / or internal path telemetry data (e.g., performance metrics between the various POP nodes of SDCI)) to determine the optimal SDCI access POP node from multiple candidate SDCI edge POP nodes for establishing the first tunnel to the user device. Additionally or alternatively, the path may include a second tunnel (also referred to herein as an internal tunnel) through internal SDCIPOP nodes to the destination device and / or service. For example, the PAPI component may utilize real-time context information to determine which internal SDCIPOP nodes meet the SLA requirements associated with the user equipment, which internal POP nodes have the most favorable current workload (e.g., selecting a POP node that supports fewer communication paths than another POP node), and / or the most favorable performance metric among the internal POP nodes of SDCI. In some examples, the path may be established by stitching together an external tunnel between the user equipment and the best SDCI edge POP node, and an internal tunnel through internal SDCIPOP nodes to the destination device and / or service. In some examples, tunnels may be stitched together using overlay encapsulation (e.g., Segmented Routing over IPv6 (SRv6) encapsulation, Virtual Scalable Local Area Network (VxLAN) encapsulation, etc.).

[0023] As previously mentioned, cloud services may include additional built-in security components, such as DNS layer security components, secure web gateway components, cloud delivery firewall components, and / or CASB components. In some examples, the DNS layer security component may be configured to block network threats at the DNS and IP network layers. Additionally or alternatively, the secure web gateway component may be configured to provide full proxy capabilities to improve performance and reduce network risk by effectively logging, inspecting, and / or controlling web traffic, providing URL and application control, and protection against malware. Additionally or alternatively, the cloud delivery firewall component may be configured to provide cloud delivery firewall access to remote users using a direct-to-the-Internet (DIA) connection to log all activity and block unwanted traffic using IP, port, and / or protocol rules. The CASB component may be configured to provide enterprises with the ability to detect and report cloud applications used on the associated organization.

[0024] For example, the environment includes: a cloud service with PAPI components, an SDCI service with one or more access POP nodes and / or one or more internal POP nodes, an SD-WAN controller associated with SD-WAN, client devices associated with SD-WAN, and / or a Secure Access Service Edge (SASE) DNS provider associated with the SDCI service. As previously described, PAPI components may include a POP database, a path calculation component, and / or an enterprise policy database. In some examples, SD-WAN may be at least partially associated with an enterprise. In some examples, one or more access POP nodes of SDCI may be distributed across the Internet and configured as access points to one or more internal POP nodes of SDCI to user devices. In some examples, the SDCI service and the SASE DNS provider may be tightly coupled so that they can share SLA information to optimize customer processing.

[0025] As previously described, the PAPI component may include a POP database, an enterprise policy database, and / or a path calculation component. In some examples, the POP database of the PAPI component may include various database entries tracking all possible SDCIPOP locations, including, for example, IP data associated with SDCI access POP nodes and / or real-time performance metrics between SDCI data center site SDCIPOP nodes, various cloud services, and / or access networks. In some examples, real-time performance metrics may be collected by the SDCI service and / or SD-WAN controller and transmitted to a cloud service, where the PAPI component may store the metrics in the POP database. Additionally or alternatively, the enterprise policy database may include user-specific policies. For example, an enterprise may register specific SLAs for specific traffic types and / or user categories. In some examples, SLAs may include bandwidth guarantees, latency guarantees, jitter guarantees, etc. Additionally or alternatively, user-specific policies may be SLA- and / or security-specific. In some examples, the path calculation component may access the POP database and / or the enterprise policy database and utilize the data stored therein to calculate the path requested by the user for establishing a connection via the cloud service.

[0026] When a home router and / or enterprise router receives a DNS resolution request query from a user device, the request can be sent to a DNS service, which can then check who is attempting to resolve the DNS query. In some examples, the DNS service can determine that the DNS resolution request is associated with a known client of the SDCI service, and the DNS service can forward the DNS resolution to a PAPI component. In some examples, the DNS service can forward the DNS resolution as a Name Server (NS) record. Additionally or alternatively, the DNS service can determine that the DNS resolution request is not associated with a known client of the SDCI service, and the DNS service can forward the DNS resolution as a regular A-record to a PAPI component. Additionally or alternatively, home routers and / or enterprise routers can be configured to determine whether there are policy and / or SLA requirements associated with the DNS resolution, and can forward the DNS resolution to a PAPI component.

[0027] In such an example where the PAPI component receives DNS resolution, it compares the DNS resolution with policies in the enterprise policy database to identify the user's SLA requirements. In some examples, real-time context information (e.g., the location of the user's device and the location of the destination) may be sent to the PAPI component. In some examples, real-time context information may be sent to the PAPI component as part of the DNS resolution. Additionally or alternatively, real-time context information may be sent to the PAPI component separately from the DNS resolution.

[0028] In this example where the PAPI component receives real-time context information, the PAPI component can use this information to identify the optimal SDCI access POP node. In some examples, a path calculation component can be used to determine the optimal SDCI access POP node. In some examples, the PAPI component and / or the path calculation component can utilize data entries stored in the POP database indicating SDCI intranet telemetry data and / or performance metrics probed between the user equipment and all available SDCI access POP nodes. Using data from the POP database and real-time context information, the PAPI component and / or the path calculation component can determine the optimal SDCI access POP node for the user equipment.

[0029] When the optimal SDCI access POP node for a user device is determined, the PAPI component and / or path calculation component can perform an SLA lookup for the customer and the type of cloud service being accessed. The optimal SDCI access POP node is determined based on the SLA, probes between the user device and all candidate SDCI access POP nodes, and internal path telemetry from the POP database. Using the identified optimal SDCI access POP node, DNS records can be sent to the DNS service, and the DNS service can return responses, such as A-records, to the home router and / or enterprise router associated with the user device.

[0030] Additionally or alternatively, DNS may return extended responses to home routers and / or enterprise routers associated with the user equipment. In some examples, the extended response may include additional information associated with alternative candidate SDCI access POP nodes. In such examples, the home router, enterprise router, and / or user equipment may include logic stored thereon to select the best SDCI access POP node from the candidate SDCI access POP nodes. In some examples, overlay headers and / or additional metadata (e.g., in-situ OAM (iOAM)) may be used to store and / or send the additional information associated with the candidate SDCI access POP node.

[0031] In some examples, the PAPI service can leverage policies stored in an enterprise policy database for each customer and / or each tenant to determine whether an SLA is required for traffic flows from a user device to a destination device and / or service. In such examples where an SLA is not required for flows from a user device to a destination device and / or service, a conventional A-Record DNS response is returned to the home router and / or enterprise router associated with the user device. Additionally or alternatively, in such examples where an SLA is required for flows from a user device to a destination device and / or service, the path calculation component can use location information indicated by real-time context data to determine the optimal SDCI access POP node and establish one or more external tunnels from the user device to one or more candidate SDCI access POP nodes and / or one or more internal tunnels from the candidate SDCI access POP nodes through internal SDCI POP nodes to the destination device and / or service.

[0032] Once one or more external tunnels and one or more internal tunnels are established, the path calculation component can stitch the tunnels together to form one or more end-to-end monitoring paths. In some examples, the tunnels can be stitched together using overlay encapsulation (e.g., Segmented Routing over IPv6 (SRv6) encapsulation, Virtual Extensible LAN (VxLAN) encapsulation, etc.). In some examples, the details required to establish the external tunnel can be passed back to the DNS service from the path calculation component of the PAPI component and can be included in the DNS response. In some examples, the DNS response can be used by home routers, enterprise routers, and / or user equipment to establish an external tunnel to the best candidate SDCI access POP node. In some examples, the DNS response can include various details required to establish the external tunnel, such as one or more IP addresses associated with the corresponding candidate SDCI access POP node, one or more certificates required to establish the external tunnel, one or more credentials required to establish the external tunnel, an indication of the overlay encapsulation type, etc.

[0033] By establishing one or more external tunnels and one or more internal tunnels, the PAPI component can maintain the tunnels in a stateful manner. This allows the PAPI component to be configured to continuously monitor the performance of one or more external tunnels between the user equipment and candidate SDCI access POP nodes and / or one or more internal tunnels between candidate SDCI access POP nodes, one or more SDCI internal POP nodes, and the destination device and / or service. In some examples, the PAPI component and / or the path calculation component can be configured to re-establish one or more internal tunnels and / or one or more external tunnels as needed (e.g., if the performance metric of the first tunnel indicates a performance degradation, a second tunnel with a more favorable performance metric can be established instead of the first tunnel).

[0034] Additionally or alternatively, the PAPI component and / or the path calculation component may configure one or more external tunnels and / or one or more internal tunnels as redundant tunnels (e.g., having the same source and destination when using different paths), wherein the tunnels may be configured as primary or secondary tunnels and / or active or inactive tunnels for load sharing purposes.

[0035] While these technologies are described as being implemented using cloud services (including compute servers, data centers, and / or cloud computing networks), they are generally applicable to any network of devices managed by an entity that can provide virtual resources. In some instances, a variety of components can be used in a system to execute the technologies described herein. The devices and components that execute the technologies described herein are an implementation issue, and the technologies described are not limited to any particular architecture or implementation.

[0036] The techniques described in this paper provide various improvements and efficiencies in using cloud services to compute end-to-end SLA-aware paths that utilize dynamic SDCI tunnels between user equipment and optimal edge POP nodes, as well as inter-POP tunnels within the SDCI. For example, the techniques described in this paper can allow the establishment of one or more external tunnels connecting user equipment to corresponding optimal SDCI access POP nodes. One or more SDCI access POP nodes can be identified as the optimal node among multiple candidate SDCI access POP nodes based on real-time contextual data (e.g., user equipment location, destination location, etc.) and / or user-specific policies (e.g., policies indicating SLA requirements, etc.). Additionally, the techniques described in this paper can allow the probing of internal tunnels between internal POP nodes within the SDCI to determine performance metrics for internal tunnels, thereby selecting the internal tunnel with the most favorable performance metrics for establishing the end-to-end path. Furthermore, multiple external and / or internal tunnels can be established and configured as primary and / or secondary tunnels for load balancing of data along separate paths from a single source to a single destination.

[0037] Certain embodiments and implementations of this disclosure will now be described more fully below with reference to the accompanying drawings, in which aspects are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. As stated herein, this disclosure covers variations of the embodiments. Similar reference numerals always refer to similar elements.

[0038] Figure 1A system architecture diagram of an example environment 100 for implementing at least some of the various techniques disclosed herein is shown. Environment 100 includes an SDWAN controller and a cloud service 106. The SDWAN controller is used to collect performance metrics associated with multiple point-of-presence (POP) nodes of a software-defined cloud interconnect (SDCI) service 104. The cloud service 106 is used to calculate dynamic end-to-end performance and SLA-aware paths from a home router and / or enterprise router 108 associated with a user device (also referred to herein as a client device) 110 to a destination device and / or service (e.g., a cloud-based virtual machine 112).

[0039] Cloud service 106 may include one or more components, subcomponents, and / or configurations. For example, cloud service 106 may include PAPI component 114. In some examples, PAPI component 114 may include POP database 116, path calculation component 118, and / or enterprise policy database 120. In some examples, POP database 116 of PAPI component 114 may include various database entries that track all possible POP locations associated with SDCI service 104, including, for example, IP data associated with access POP nodes 122(1)-(3) of SDCI service 104, and / or data center sites associated with SDCI service 104, internal POP nodes 124(1)-(3) associated with SDCI service 104, real-time performance metrics between various cloud services (e.g., SaaS 126), and / or access networks (e.g., IaaS 128). In some examples, real-time performance metrics may be collected by SDCI service 104 and / or SD-WAN controller 102 and transmitted to cloud service 106, where PAPI component 114 can store the metrics in POP database 116. Additionally or alternatively, enterprise policy database 120 may include user-specific policies. For example, an enterprise may register specific SLAs for specific traffic types and / or user categories. In some examples, SLAs may include bandwidth guarantees, latency guarantees, jitter guarantees, etc. Additionally or alternatively, user-specific policies may be SLAs and / or security-specific. In some examples, path calculation component 118 may access POP database 116 and / or enterprise policy database 120 and use the data stored therein to calculate the path requested by the user for establishing a connection via cloud service 106.

[0040] Client device 110 may include any type of device configured to communicate over one or more networks (e.g., wide area network (WAN) 130) using various communication protocols (e.g., VPN, SSL, TLS, DTLS, and / or any other protocol). For example, client device 110 may include personal client devices (e.g., desktop computers, laptop computers, telephones, tablet computers, wearable devices, entertainment devices (e.g., televisions), etc.), network devices (e.g., servers, routers, switches, access points, etc.), and / or any other type of computing device.

[0041] One or more example service providers (e.g., SDCI service 104, cloud service 106, cloud-based virtual machine 112, SaaS 126, and / or IaaS 128) may provide one or more services to various client devices via network 130. In some examples, the service providers may include application services, websites, or other cloud-based services. In some examples, the service providers may provide client device 110 with basic resources such as processors (CPUs), memory (RAM), storage devices (disks), and networking (bandwidth). Additionally, in some examples, the service provider (e.g., cloud-based virtual machine 112) may provide, accommodate, or otherwise support one or more application services for client device 110 to connect to and use. In some instances, computing resources associated with and / or allocated to the service providers may be stored in various data centers located in different physical locations. For example, a first computing resource of the service providers may be stored in a first data center located in a first geographic location, while a second computing resource of the service providers may be stored in a second data center located in a second geographic location. A data center may be a physical facility or building designated for storing networked devices across a geographical area. For example, a data center may be located at each individual internal POP node 124 and / or individual access POP node 122 of SDCI service 104. The data center may include various networking devices, as well as redundant or backup components and infrastructure for power supply, data communication connectivity, environmental control, and various security devices. In some examples, the data center may include one or more virtual data centers, which are pools or collections of cloud infrastructure resources specifically designed for enterprise needs and / or the needs of cloud-based service providers.

[0042] As previously described, SDCI service 104 may include one or more internal POP nodes 124(1)-(3), which are configured to route traffic through SDCI service 104 to a destination computer or service, such as a cloud-based virtual machine 112 and / or SaaS 126. Additionally or alternatively, SDCI service 104 may include one or more access POP nodes 122(1)-(3), which are configured to route traffic from a home router and / or enterprise router 108 associated with client device 110 to one or more internal POP nodes 124. Furthermore, an external tunnel may be established between client device 110 and access POP nodes 122, and an internal tunnel may be established between external POP nodes 122, internal POP nodes 124, and the final destination to form an end-to-end SLA-aware path. It should be understood that although only 3 access POP nodes 122 and 3 internal POP nodes 124 are shown, the SDCI service 104 may include any number of access POP nodes 122 and / or internal POP nodes 124.

[0043] As previously described, PAPI component 114 and / or path calculation component 118 can be configured to access real-time performance metrics and user-specific enterprise policies associated with SDCIPOP nodes 122, 124 to calculate an end-to-end SLA-aware path connecting user equipment 110 to destination device and / or service 112. In some examples, this path may include a first tunnel (also referred to herein as an external tunnel) from user equipment 110 to access POP node 122 (also referred to herein as an edge POP node), which is determined to be the optimal edge POP node for user equipment 110. For example, PAPI component 114 and / or path calculation component 118 may utilize real-time contextual information (e.g., the location of user equipment 110, the location of destination device and / or service 112, SLA associated with user equipment 110, and / or internal path telemetry data (e.g., performance metrics between the various internal POP nodes 124 of SDCI service 104)) to determine the optimal SDCI access POP node 122 for establishing a first tunnel to the user equipment from a plurality of candidate SDCI access POP nodes 122. Additionally or alternatively, the path may include a second tunnel (also referred to herein as an internal tunnel) traversing the internal POP nodes 124 of SDCI service 104 and to the destination device and / or service 112. For example, PAPI component 114 and / or path calculation component 118 can utilize real-time context information to determine which internal POP nodes 124 meet the SLA requirements associated with user equipment 110, which internal POP nodes 124 have the most favorable current workload (e.g., selecting a POP node that supports fewer communication paths than another POP node), and / or the most favorable performance metric among the internal POP nodes 124 of SDCI service 104. In some examples, a path can be established by stitching together an external tunnel between user equipment 110 and the optimal SDCI edge POP node 122, and an internal tunnel through the internal SDCIPOP node 124 to the destination device and / or service 112. In some examples, tunnels can be stitched together using overlay encapsulation (e.g., Segmented Routing over IPv6 (SRv6) encapsulation, Virtual Scalable Local Area Network (VxLAN) encapsulation, etc.).

[0044] Figure 2 A component diagram of a sample cloud service 106, including a Performance-Aware Path Instantiation (PAPI) component 114, is shown. In some examples, cloud service 106 can be configured as a reference. Figure 1The cloud service 106 is described. Additionally or alternatively, the cloud service 106 may utilize various components (e.g., PAPI component 114, DNS layer security component 202, secure web gateway component 204, cloud delivery firewall component 206, and / or cloud access security broker (CASB) component 208) to provide cloud services.

[0045] PAPI component 114 may include one or more sub-components, such as POP database 116, path calculation component 118, and / or enterprise policy database 120. In some examples, POP database 116 may be configured to store real-time performance metrics associated with access POP nodes and / or internal POP nodes of the SDCI service. In some examples, path calculation component 118 is configured to use data included in enterprise policy database 120 and / or POP database 116 to calculate paths from user devices to destination devices and / or services. In some examples, enterprise policy database 120 may be configured to store policies for each user and / or each tenant.

[0046] In some examples, PAPI component 114 may utilize path calculation component 118 and may be configured to access real-time performance metrics and user-specific enterprise policies associated with the POP node of the SDCI service to calculate an end-to-end SLA-aware path connecting the user device to the destination device and / or service. For example, PAPI component 114 may receive DNS resolution, and in response, PAPI component 114 may compare the DNS resolution with policies in enterprise policy database 120 to identify the user's SLA requirements. In some examples, real-time context information (e.g., the location of the user device and the location of the destination, etc.) may be sent to PAPI component 114. In some examples, real-time context information may be sent to PAPI component 114 as part of DNS resolution. Additionally or alternatively, real-time context information may be sent to PAPI component 114 separately from DNS resolution.

[0047] Additionally or alternatively, PAPI component 114 can be configured to identify the optimal access POP node for SDCI based on the user associated with DNS resolution and utilizing real-time context information. In some examples, path calculation component 118 can be used to determine the optimal access POP node. In some examples, PAPI component 114 and / or path calculation component 118 can utilize data entries stored in POP database 116 indicating SDCI internal network telemetry data and / or performance metrics probed between the user equipment and all available access POP nodes for the SDCI service. Using data from POP database 116 and real-time context information, PAPI component 114 and / or path calculation component 118 can determine the optimal access POP node for the user equipment.

[0048] When the optimal SDCI access POP node for a user device is determined, the PAPI component 114 and / or the path calculation component 118 can perform an SLA lookup for the customer and the type of cloud service being accessed. The path calculation component 118 can determine the optimal SDCI access POP node for the associated user device based on the SLA, probes between the user device and all candidate SDCI access POP nodes, and internal path telemetry from the POP database 116. Using the identified optimal SDCI access POP node, a DNS record can be sent to the DNS service, and the DNS service can return a response, such as an A- record, to the home router and / or enterprise router associated with the user device.

[0049] As previously described, cloud service 106 may include additional built-in security components, such as DNS layer security component 202, secure web gateway component 204, cloud delivery firewall component 206, and / or CASB component 208. In some examples, DNS layer security component 202 may be configured to block network threats at the DNS and IP network layers. Additionally or alternatively, secure web gateway component 204 may be configured to provide full proxy capabilities to improve performance and reduce network risks by effectively logging, inspecting, and / or controlling web traffic, providing URL and application control, and protection against malware. Additionally or alternatively, cloud delivery firewall component 206 may be configured to provide cloud delivery firewall to remote users using a direct-to-internet access (DIA) connection to log all activity and block unwanted traffic using IP, port, and / or protocol rules. CASB component 208 may be configured to provide enterprises with the ability to detect and report cloud applications used on the associated organization.

[0050] Figure 3A system architecture diagram of an example environment 300 is shown, including an SDWAN controller 102 and a cloud service 106 for calculating end-to-end SLA-aware paths for dynamic SDCI tunnels between user equipment 110 and one or more optimal edge POP nodes, as well as inter-POP tunnels for SDCI service 104. In some examples, environment 300 may correspond to a reference... Figure 1 At least a portion of the environment 100 described.

[0051] As previously described, cloud service 106 may include PAPI component 114, and PAPI component 114 may include one or more sub-components, such as POP database 116, path calculation component 118, and / or enterprise policy database 120. In some examples, environment 300 may include software-defined wide area network (SD-WAN) 130. SD-WAN 130 may be at least partially associated with an enterprise. In some examples, one or more access POP nodes 122 of SDCI service 104 may be distributed across the Internet and configured as access points to internal POP nodes(s) 124 for user equipment 110 utilizing SDCI service 104. In some examples, SDCI service 104 may be tightly coupled to a SASEDNS provider, enabling them to share SLA information to optimize customer processing.

[0052] When the home router and / or enterprise router 108 receives a DNS resolution request query from user equipment 110, the request can be sent to a DNS service, which can check who is attempting to resolve the DNS query. In some examples, the DNS service can determine that the DNS resolution request is associated with a known client of SDCI service 104, and the DNS service can forward the DNS resolution to PAPI component 114. In some examples, the DNS service can forward the DNS resolution as a Name Server (NS) record. Additionally or alternatively, the DNS service can determine that the DNS resolution request is not associated with a known client of SDCI service 104, and the DNS service can forward the DNS resolution as a regular A-record to PAPI component 114. Additionally or alternatively, the home router and / or enterprise router 108 can be configured to determine whether there are policy and / or SLA requirements associated with the DNS resolution, and can forward the DNS resolution to PAPI component 114.

[0053] In some examples, PAPI component 114 may utilize real-time contextual information (e.g., the location of user equipment 110 and the location of the destination (e.g., virtual machine 112)) to identify one or more optimal access POP nodes 122 for user equipment 110 to utilize SDCI service 104. Additionally or alternatively, PAPI component 114 and / or path calculation component 118 may utilize data entries stored in POP database 116 to indicate SDCI intranet telemetry data and / or performance metrics probed between user equipment 110 and one or more of all available SDCI access POP nodes 122. Additionally or alternatively, PAPI component 114 and / or path calculation component 118 may perform SLA lookups for the customer and the type of cloud service being accessed (e.g., cloud-based virtual machine 112). Based on real-time context information, SLA, probes between user equipment 110 and all candidate access POP nodes 122, and internal path telemetry from POP database 116, PAPI component 114 and / or path calculation component 118 can determine one or more optimal SDCI access POP nodes 122 for user equipment 110 to access SDCI service 104. For example, path calculation component 118 can determine that a first access POP node 122(1) is the optimal access POP node 122 available to user equipment 110. Additionally or alternatively, path calculation component 118 can determine that a second access POP node 122(2) is the optimal access POP node 122 available to user equipment 110. In some examples, the first access POP node 122(1) can be configured as the primary access POP node 122, while the second access POP node 122(2) can be configured as the secondary access POP node 122.

[0054] By configuring the first access POP node 122(1) as the primary access POP node 122(1), DNS records can be sent to the DNS service, and the DNS service can return responses, such as A-records, to the home router and / or enterprise router 108 associated with the user equipment 110.

[0055] Additionally or alternatively, DNS may return extended responses to the home router and / or enterprise router 108 associated with user equipment 110. In some examples, the extended response may include additional information associated with alternative candidate access POP node 122 (e.g., a second access POP node 122(2) configured as a secondary access POP node 122(2)). In such examples, home router 108, enterprise router 108, and / or user equipment 110 may include logic stored thereon to select the best SDCI access POP node 122 from the candidate access POP nodes 122. In some examples, overlay headers and / or additional metadata (e.g., in-situ OAM (iOAM)) may be used to store and / or send the additional information associated with the secondary access POP node 122(2).

[0056] As previously described, PAPI component 114 can utilize policies for each customer and / or each tenant stored in enterprise policy database 120 to determine whether an SLA is required for a traffic flow from user device 110 to destination device and / or service 112. In an example where an SLA is not required for a flow from user device 110 to destination device and / or service 112, a conventional A-record DNS response is returned to the home router and / or enterprise router 108 associated with user device 110. Additionally or alternatively, in an example where an SLA is required for a flow from user device 110 to destination device and / or service 112, path calculation component 118 can use location information indicated by real-time context data to determine the optimal access POP node 122 and establish one or more external tunnels from user device 110 to one or more candidate access POP nodes 122 and / or one or more internal tunnels from candidate access POP nodes 122 through SDCI internal POP node 124 to destination device and / or service 112.

[0057] For example, tunnel 1.1 302 can be configured as a primary external tunnel bridging the primary path from the home router and / or enterprise router 108 associated with user equipment 110 to the primary access POP node 122(1). Alternatively, tunnel 1.2 304 can be configured as a secondary external tunnel bridging the secondary path from the home router and / or enterprise router 108 associated with user equipment 110 to the secondary access POP node 122(2). Furthermore, tunnel 2.1 306 can be configured as a primary internal tunnel bridging the primary path from the primary access POP node 122(1) through the primary internal POP node 124(1) and the secondary internal POP node 122(2) to the destination device and / or service 112. Additionally or alternatively, tunnel 2.2 308 may be configured as a secondary internal tunnel that bridges the secondary path from secondary access POP node 122(2) through secondary internal POP node 124(2) to destination device and / or service 112.

[0058] Once one or more external tunnels 302, 304 and one or more internal tunnels 306, 308 are established, the path calculation component 118 can stitch the tunnels together to form one or more end-to-end monitoring paths (e.g., the primary and secondary paths described above). By establishing one or more paths, the PAPI component 118 can maintain the tunnels in a stateful manner, allowing it to be configured to continuously monitor the performance of one or more external tunnels 302, 304 and / or one or more candidate access POP nodes 122, one or more internal POP nodes 124, and one or more internal tunnels 306, 308 between the user equipment 110 and the candidate access POP node 122, and / or one or more candidate access POP nodes 122, and between the destination device and / or service 112. In some examples, the PAPI component 114 and / or the path calculation component 118 can be configured to re-establish one or more internal tunnels 306, 308 and / or one or more external tunnels 302, 304 as needed. For example, if the performance metric of one of the tunnels associated with the primary paths 302 and 306 indicates performance degradation, heavy workload, etc., one or more tunnels of the secondary paths 304 and 308 can be determined to have a more favorable performance metric, and the secondary paths can be established and / or given priority in place of the primary paths. Additionally or alternatively, for load balancing purposes, the path calculation component 118 can give one path priority over another.

[0059] Figure 4A system architecture diagram of an example environment 400 is shown, including an SDWAN controller 102, a cloud service 106, and an example end-to-end overlay encapsulation 402. This example end-to-end overlay encapsulation 402 is used to route traffic from user equipment 110 to destination device and / or service 112 using one or more internal and / or external POP tunnels 302-308 of SDCI service 104. In some examples, environment 400 may correspond to [references to other environments]. Figure 1 and Figure 3 The described environment(s) is 100 and / or 300.

[0060] Once one or more external tunnels (e.g., primary external tunnel 302 and / or secondary external tunnel 304) and one or more internal tunnels (e.g., primary internal tunnel 306 and / or secondary external tunnel 308) are established, the path calculation component 118 can stitch the primary external tunnel 302 and primary internal tunnel 306 and / or secondary external tunnel 304 and secondary internal tunnel 308 together to form one or more end-to-end monitoring paths, such as primary paths and secondary paths.

[0061] In some examples, external tunnels 302, 304 and corresponding internal tunnels 306, 308 may be stitched together using overlay encapsulation (e.g., Segmented Routing over IPv6 (SRv6) encapsulation, Virtual Extensible LAN (VxLAN) encapsulation, etc.). In some examples, the details required to establish one or more external tunnels 302, 304 may be passed back to the DNS service from the path calculation component 118 of PAPI component 114 and may be included in the DNS response returned to the home router and / or enterprise router 108. In some examples, the DNS response may be used by the home router 108, enterprise router 108, and / or user equipment 110 to establish one or more external tunnels 302, 304 to one or more corresponding candidate access POP nodes 122(1), 122(2). In some examples, the DNS response may include various details required to establish one or more external tunnels 302, 304, such as one or more IP addresses associated with the corresponding access POP node 122, one or more certificates required to establish one or more external tunnels 302, 304, one or more credentials required to establish one or more external tunnels 302, 304, an indication of the overlay encapsulation type, etc. In some examples, end-to-end encapsulation 402 may be used to route traffic on the desired path.

[0062] In some examples, the end-to-end encapsulation 402(1) may include an edge POP address 404, an internal POP address 406, a destination address 408, and a payload 410. In some examples, the edge POP address 404 may be configured as an external header for routing communication between a home router and / or enterprise router 108 associated with user equipment 110 and an access POP node 122 having an IP address included in the edge POP address 404 header. For example, the edge POP address 404 may include the address (e.g., an IP address) of the first access POP node 122(1), and the home router and / or enterprise router 108 associated with user equipment may utilize the edge POP address 404 included in the external header to send data using the primary external tunnel between user equipment 110 and the first access POP node 122(1). In some examples, the internal POP address 406 can be configured as a secondary header for routing communication between access POP nodes 122 with IP addresses included in the edge POP address header 404 and along the internal path of the internal POP node 124 of the SDCI service. For example, the internal POP address 406 may include an address such as an IP address associated with the first internal POP node 124(1) and / or the main internal tunnel, and the access POP node 122(1) may utilize the internal POP address 406 included in the secondary header to send data between the first access POP node 122(1), the first internal POP node 124(1), the second internal POP node 124(2), and the final destination 112 using the main internal tunnel. In some examples, the destination address 408 can be configured as an internal header for directing traffic from the internal path to the final destination, such as a cloud-based virtual machine 112. For example, destination address 408 may include an address such as an IP address associated with final destination 112, and payload 410 may be routed to final destination 112 via an internal tunnel. In some instances, payload 410 may be configured to store communication data transmitted between user equipment 110 and final destination 112.

[0063] Figure 5 and Figure 6 Flowcharts for example methods 500 and 600 are shown, and at least in part by... Figures 1 to 4 This document refers to various aspects of the functions performed by the cloud service 106, SDCI service 104, and / or SDWAN controller 102 as described herein. Figure 5 and Figure 6 The described logical operations can be implemented as (1) a sequence of computer-implemented actions or program modules running on a computing system and / or (2) interconnected machine logic circuits or circuit modules within a computing system.

[0064] The implementation of the various components described herein is a matter of choice, depending on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to differently as operations, structured devices, actions, or modules. These operations, structured devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more can be performed than Figure 5 and Figure 6 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. While the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0065] Figure 5 A flowchart of an example method 500 for calculating an end-to-end SLA-aware path using cloud service 106 is shown, which uses a dynamic SDCI tunnel between the user equipment and the optimal edge POP node, as well as an inter-POP tunnel of SDCI service 104.

[0066] At 502, method 500 may include: receiving a request for an end-to-end path between a client device and a destination device at a cloud service. In some examples, the cloud service may be configured as cloud service 106 and may include references Figure 1 The description includes PAPI component 114, POP database 116, path computation component 118, and / or enterprise database. In some examples, Software-Defined Cloud Interconnect (SDCI) is used to at least partially establish the end-to-end path. In some examples, SDCI can be configured as a reference. Figure 1 The SDCI service described is 104.

[0067] At 504, method 500 may include: identifying performance requirements associated with a user account for delivering traffic on an end-to-end path. In some examples, performance requirements may be based on an SLA and / or policy associated with the user account. Additionally or alternatively, performance requirements may be determined by a cloud service. Additionally or alternatively, performance requirements may be stored in an enterprise policy database.

[0068] At 506, method 500 may include: identifying performance data that indicates performance metrics between one or more paths between one or more points of presence (POPs) of SDCI. In some examples, the performance data may be identified by a cloud service. Additionally or alternatively, as referenced... Figure 1The description states that one or more POPs of SDCI can be configured as one or more access POP nodes 122 and / or one or more internal POP nodes 124 associated with SDCI service 104. Additionally or alternatively, performance data can be stored in a POP database.

[0069] At 508, method 500 may include: calculating the path between the user device and the destination device. In some examples, the path may be calculated at least in part based on performance metrics associated with one or more paths that meet performance requirements associated with a user account. Additionally or alternatively, the cloud service may be configured to calculate the path between the user device and the destination device. In some examples, the destination device may include a destination service.

[0070] At 510, method 500 may include: causing data to be transmitted from the client device to the destination device using a path. Additionally or alternatively, method 500 may include: causing data to be transmitted from the destination device to the client device using the path. In some examples, such as references... Figure 4 The description states that enabling data to be transmitted using this path may be based on an end-to-end encapsulation 402 that includes an edge POP address 404, an internal POP address 406, a destination address 408, and / or a payload 410.

[0071] Additionally or alternatively, method 500 may include: providing an indication of a path to at least one device associated with the path via a cloud service. In some examples, the at least one device may include any one of a DNS service, an access POP node, an internal POP node, a home router and / or an enterprise router and / or a user device.

[0072] Additionally or alternatively, method 500 may include: sending an indication of a path between a user device and a destination device from a cloud service to a software-defined networking (SDN) controller associated with the cloud service. Additionally or alternatively, method 500 may include: programming the path between the user device and the destination device by the SDN controller, at least in part, based on the indication. In some examples, programming the path may include: providing an indication of the path to at least one of one or more POPs of the SDCI. Additionally or alternatively, as referenced... Figures 1 to 4 The programming path described may include: creating external tunnels, internal tunnels, and / or stitching the tunnels together.

[0073] In some examples, the first path in one or more paths between one or more POPs of SDCI utilizes a first-type network, while the second path in one or more paths between one or more POPs of SDCI utilizes a second-type network. In some examples, the second-type network and the first-type network may be different. In some examples, the first and / or second-type networks may include any of the Internet, fourth-generation (4G) broadband cellular networks, fifth-generation (5G) broadband cellular networks, multi-protocol label switching (MPLS) networks, etc.

[0074] Additionally or alternatively, method 500 may include: sending an indication of a path from the cloud service to the client device. In some examples, enabling data transfer from the client device to the destination device may be based at least in part on sending the indication of a path to the client device. Additionally or alternatively, method 500 may include: sending an indication of a user account associated with the client device from the cloud service to the Domain Name Service (DNS) associated with the cloud service. Additionally or alternatively, method 500 may include: receiving an indication of a policy associated with the user account from the DNS at the cloud service. In some examples, the policy may indicate a Service Level Agreement (SLA) associated with the user account. In some examples, identifying performance requirements associated with the user account may be based at least in part on the SLA associated with the user account.

[0075] In some examples, the request may include an indication of the current location associated with the client device. Additionally or alternatively, method 500 may include: identifying a first POP among one or more POPs of the SDCI by the cloud service based at least in part on the current location associated with the client device. Additionally or alternatively, method 500 may include: calculating a path between the user device and the destination device based at least in part on the first POP among one or more POPs of the SDCI.

[0076] In some examples, the performance data may be first performance data, and the performance metric may be a first performance metric. Additionally or alternatively, method 500 may include: receiving at the cloud service and from a software-defined networking (SDN) controller associated with the cloud service at a first time. In some examples, the first performance data may indicate a first performance metric for one or more paths between one or more POPs of the SDCI. Additionally or alternatively, method 500 may include: storing the first performance metric associated with the first time in a database associated with the cloud service. Additionally or alternatively, method 500 may include: receiving second performance data at the cloud service and from the SDN controller at a second time, the second performance data indicating a second performance metric for one or more paths between one or more POPs of the SDCI. In some examples, the second time may be after the first time. Additionally or alternatively, method 500 may include: storing the second performance metric associated with the second time in a database associated with the cloud service.

[0077] In some examples, the path may be a first path. Additionally or alternatively, method 500 may include: determining, at least in part, that a first performance metric in a second performance metric is more advantageous than a first performance metric in a first performance metric, based on performance requirements by the cloud service. Additionally or alternatively, method 500 may include: calculating a second path between the user device and the destination device at the cloud service, based at least in part on the determination that at least a first performance metric in a second performance metric is more advantageous than a first performance metric in a first performance metric. Additionally or alternatively, method 500 may include: causing data to be transferred from the client device to the destination device using the second path.

[0078] In some examples, performance requirements may include at least one of bandwidth requirements, latency requirements, jitter requirements, and / or security requirements.

[0079] In some examples, the request includes an indication of the current location associated with the client device. Additionally or alternatively, method 500 may include: identifying an edge POP associated with the SDCI at the cloud service based at least in part on the current location associated with the client device and performance requirements associated with a user account. Additionally or alternatively, method 500 may include: providing an indication of the edge POP to a software-defined networking (SDN) controller associated with the cloud service to establish a first secure tunnel between the client device and the edge POP. Additionally or alternatively, method 500 may include: identifying one or more internal POPs of the SDCI from one or more POPs of the SDCI at the cloud service based at least in part on performance requirements and the edge POP. In some examples, one or more internal POPs of the SDCI may include a first internal POP that can be connected to the edge POP. Additionally or alternatively, method 500 may include: providing an indication of one or more internal POPs of the SDCI to an SDN controller to establish a second secure tunnel using one or more paths between the one or more internal POPs of the SDCI. Additionally or alternatively, method 500 may include: providing an indication to the SDN controller of a first internal POP among one or more internal POPs of the SDCI to connect a first secure tunnel to a second secure tunnel. Additionally or alternatively, method 500 may include: enabling data usage paths to be transmitted from the client device to the destination device, at least in part based on connecting the first secure tunnel to the second secure tunnel.

[0080] Additionally or alternatively, method 500 may include: determining a first candidate path at a cloud service, the first candidate path comprising one or more first paths between one or more first POPs of one or more POPs of SDCI. In some examples, the one or more first paths may be associated with a first performance metric in performance metrics. Additionally or alternatively, method 500 may include: determining a second candidate path at a cloud service, the second candidate path comprising one or more second paths between one or more second POPs of one or more POPs of SDCI. In some examples, the one or more second paths may be associated with a second performance metric in performance metrics. Additionally or alternatively, method 500 may include: determining at a cloud service that a first performance metric is more advantageous than a second performance metric, at least in part, based on performance requirements. In some examples, calculating the path between the user device and the destination device includes: calculating a path comprising one or more first paths between one or more first POPs of SDCI, which may be based at least in part on determining that a first performance metric is more advantageous than a second performance metric.

[0081] Figure 6A flowchart of an example method 600 for calculating an end-to-end SLA-aware path using cloud service 106 is shown, which uses a dynamic SDCI tunnel between the user equipment and the optimal edge POP node, as well as an inter-POP tunnel of SDCI service 104.

[0082] At 602, method 600 may include: receiving a request for an end-to-end path between a client device and a destination device at a cloud service. In some examples, the request may indicate performance requirements associated with a user account for delivering traffic over the end-to-end path. In some examples, Software-Defined Cloud Interconnect (SDCI) may be used to at least partially establish the end-to-end path. In some examples, the cloud service may be configured as cloud service 106 and may include references Figure 1 The described components include PAPI component 114, POP database 116, path calculation component 118, and / or enterprise database. Additionally or alternatively, SDCI can be configured for reference. Figure 1 The SDCI service 104 is described. In some examples, performance requirements may be based on SLAs and / or policies associated with user accounts. Additionally or alternatively, performance requirements may be determined by the cloud service. Additionally or alternatively, performance requirements may be stored in an enterprise policy database.

[0083] At 604, method 600 may include: identifying performance data that indicates performance metrics between one or more paths between one or more points of presence (POPs) of SDCI. In some examples, the performance data may be identified by a cloud service. Additionally or alternatively, as referenced... Figure 1 As described, one or more POPs of SDCI can be configured as one or more access POP nodes 122 and / or one or more internal POP nodes 124 associated with SDCI service 104. Additionally or alternatively, performance data can be stored in a POP database.

[0084] At 606, method 600 may include: calculating the path between the user device and the destination device. In some examples, the path may be calculated at least in part based on performance metrics associated with one or more paths that meet performance requirements associated with a user account. Additionally or alternatively, the cloud service may be configured to calculate the path between the user device and the destination device. In some examples, the destination device may include a destination service.

[0085] At 608, method 600 may include: causing data to be transmitted from the client device to the destination device using a path. Additionally or alternatively, method 500 may include: causing data to be transmitted from the destination device to the client device using the path. In some examples, such as references... Figure 4As described, enabling data to be transmitted using this path can be based on an end-to-end encapsulation 402 that includes an edge POP address 404, an internal POP address 406, a destination address 408, and / or a payload 410.

[0086] In some examples, requests may be received from the Domain Name Service (DNS) associated with the cloud service, and / or performance requirements may indicate the Service Level Agreement (SLA) associated with the user account.

[0087] In some examples, the first path in one or more paths between one or more POPs of SDCI utilizes a first-type network, while the second path in one or more paths between one or more POPs of SDCI utilizes a second-type network. In some examples, the second-type network and the first-type network may be different.

[0088] In some examples, performance requirements may include at least one of bandwidth requirements, latency requirements, jitter requirements, and / or security requirements.

[0089] Additionally or alternatively, method 600 may include sending an indication from the cloud service to a software-defined networking (SDN) controller associated with the cloud service regarding the path between the user equipment and the destination device. In some examples, the SDN controller may correspond to a reference... Figure 1 , Figure 3 and / or Figure 4 The described SD-WAN 102. Additionally or alternatively, method 600 may include: programming the path between the user equipment and the destination equipment by an SDN controller, at least in part, based on an indication. In some examples, programming the path may include: providing an indication of the path to at least one of one or more POPs of the SDCI.

[0090] Additionally or alternatively, method 600 may include: determining a first candidate path at a cloud service, the first candidate path comprising one or more first paths between one or more first POPs of one or more POPs of SDCI. In some examples, the one or more first paths may be associated with a first performance metric in performance metrics. Additionally or alternatively, method 600 may include: determining a second candidate path at a cloud service, the second candidate path comprising one or more second paths between one or more second POPs of one or more POPs of SDCI. In some examples, the one or more second paths may be associated with a second performance metric in performance metrics. Additionally or alternatively, method 600 may include: determining at a cloud service that a first performance metric is more advantageous than a second performance metric, at least in part, based on performance requirements. In some examples, calculating the path between the user device and the destination device may include: calculating a path comprising one or more first paths between one or more first POPs of SDCI, at least in part, based on determining that a first performance metric is more advantageous than a second performance metric.

[0091] Figure 7 A computer architecture diagram is shown, illustrating an example computer hardware architecture for implementing a network device that can be used to implement various aspects of the various technologies presented herein. Figure 7 The illustrated computer architecture depicts conventional server computers, workstations, desktop computers, laptops, tablets, web applications, e-readers, smartphones, or other computing devices, and can be used to execute any of the software components presented herein. In some examples, computer 700 may correspond to the cloud service 106 described herein and may include networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, and so on.

[0092] Computer 700 includes a baseboard 702, or "motherboard," which is a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication paths. In an illustrative configuration, one or more central processing units (CPUs) 704 operate in conjunction with a chipset 706. The CPU 704 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 700.

[0093] The CPU 704 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adders / subtractors, arithmetic logic units, floating-point units, and so on.

[0094] Chipset 706 provides an interface between CPU 704 and the remaining components and devices on substrate 702. Chipset 706 may provide an interface with RAM 708, which is used as main memory in computer 700. Chipset 706 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 710 or non-volatile RAM (NVRAM), for storing basic routines that facilitate the startup of computer 700 and the transfer of information between various components and devices. ROM 710 or NVRAM may also store other software components necessary for the operation of computer 700 according to the configuration described herein.

[0095] Computer 700 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network (e.g., network 724). Chipset 706 may include functionality for providing network connectivity via NIC 712 (e.g., a Gigabit Ethernet adapter). NIC 712 enables computer 700 to connect to other computing devices via network 724. It should be understood that multiple NICs 712 may be present in computer 700 to connect the computer to other types of networks and remote computer systems.

[0096] Computer 700 can be connected to storage device 718, which provides non-volatile storage for the computer. Storage device 718 can store operating system 720, programs 722, and data, which have been described in more detail herein. Storage device 718 can be connected to computer 700 via storage controller 714, which is connected to chipset 706. Storage device 718 can consist of one or more physical storage units. Storage controller 714 can be connected to physical storage units via a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0097] Computer 700 can store data on storage device 718 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 718 is characterized as primary or secondary storage, etc.

[0098] For example, computer 700 can store information in storage device 718 by issuing instructions through storage controller 714 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 700 can further read information from storage device 718 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0099] In addition to the aforementioned high-capacity storage device 718, computer 700 can also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that computer-readable storage media are any available medium that provides non-transitory storage of data and can be accessed by computer 700. In some examples, operations performed by various components in environment 100 can be supported by one or more devices similar to computer 700. In other words, some or all of the operations performed by various components in environment 100 can be performed by one or more computer devices 700 operating in a cloud-based configuration.

[0100] By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state storage technologies, compact disc ROM (CD-ROM), digital versatile disc (DVD), high-definition DVD (HD-DVD), Blu-ray or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0101] As briefly mentioned above, storage device 718 may store operating system 720 used to control the operation of computer 700. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a MICROSOFT operating system from Redmond, Washington. The server operating system. According to another embodiment, the operating system may include a UNIX operating system or a variant thereof. It should be understood that other operating systems may also be used. Storage device 718 may store other systems, applications, and data used by computer 700.

[0102] In one embodiment, storage device 718 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 700, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 700 by specifying how CPU 704 transitions between states. According to one embodiment, computer 700 has access to a computer-readable storage medium storing computer-executable instructions that, when executed by computer 700, perform the above-described... Figures 1 to 6 The various processes described herein. The computer 700 may also include a computer-readable storage medium storing instructions for performing any other computer-implemented operations described herein.

[0103] Computer 700 may also include one or more input / output controllers 716 for receiving and processing input from a number of input devices, such as a keyboard, mouse, touchpad, touchscreen, stylus, or other types of input devices. Similarly, input / output controllers 716 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices. It will be understood that computer 700 may not include... Figure 7 All components shown may include Figure 7 Other components not explicitly shown, or those that may utilize [the technology / method] Figure 7 The architecture shown is completely different.

[0104] As described herein, computer 700 may include one or more of cloud service 106 (which includes PAPI component 114), user equipment 110, SDCI service 104, and / or SDWAN controller 102. Computer 700 may include one or more hardware processors 704 (processors) configured to execute one or more stored instructions. The processors 704 may include one or more cores. Furthermore, computer 700 may include one or more network interfaces configured to provide communication between computer 700 and other devices (e.g., the communication performed herein by cloud service 106, SDCI service 104, SDWAN controller 102, and / or user equipment 110). The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), etc. For example, the network interface may include interfaces with Ethernet, Wi-Fi, etc. TM Compatible devices, etc. Program 722 may include any type of program or process for performing the techniques described in this disclosure. Program 722 enables user device 110 to perform various operations.

[0105] In summary, a technique for computing end-to-end SLA-aware paths using cloud services is described. This technique utilizes dynamic software-defined cloud interconnection (SDCI) tunnels between user equipment and access point of presence (POP) nodes, as well as inter-POP tunnels within the SDCI. The cloud service may include a Performance-Aware Path Instantiation (PAPI) component, comprising a POP database for storing performance metrics associated with SDCI POPs, an enterprise policy database for storing user-specific policies, and / or a path computation component. The path computation component may compute paths based on user-specific policies, performance metrics associated with POP nodes, and / or real-time context data associated with user equipment and / or destination devices. The path may include a first tunnel between the user equipment and the optimal access POP node of the SDCI, and a second tunnel from the access POP node through internal POP nodes to the destination device.

[0106] While the invention has been described with respect to specific embodiments, it should be understood that the scope of the invention is not limited to these specific embodiments. Because other modifications and alterations made to suit specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, but rather includes all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0107] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of this application.

Claims

1. A communication method, comprising: The cloud service receives a request for an end-to-end path between a client device and a destination device, wherein the end-to-end path is established at least in part using Software-Defined Cloud Interconnect (SDCI). For the user account associated with the client device, identify the performance requirements associated with the user account for transmitting traffic on the end-to-end path; Identify performance data, which indicates a performance metric for one or more paths including one or more Point of Presence (POP) nodes of the SDCI; The path between the client device and the destination device is calculated at the cloud service based at least in part on the performance metric associated with the one or more paths, which satisfy the performance requirements associated with the user account; and The data is transmitted from the client device to the destination device using the specified path.

2. The communication method according to claim 1 further includes: The cloud service provides an indication of the path to at least one device associated with the path.

3. The communication method according to claim 1 further includes: The cloud service sends an indication of the path between the client device and the destination device to the software-defined networking SDN controller associated with the cloud service. as well as The path between the client device and the destination device is programmed by the SDN controller at least in part based on the indication, wherein programming the path includes providing an indication of the path to at least one of one or more POPs of the SDCI.

4. The communication method according to claim 1, wherein, The first path in one or more paths between one or more POPs of the SDCI utilizes a first type of network, while the second path in one or more paths between one or more POPs of the SDCI utilizes a second type of network, which is different from the first type of network.

5. The communication method according to claim 1, further comprising: The instruction for the path is sent from the cloud service to the client device, and the transmission of the data from the client device to the destination device is at least in part based on the sending of the instruction for the path to the client device.

6. The communication method according to claim 5 further includes: Send an instruction from the cloud service to the DNS service associated with the cloud service regarding the user account associated with the client device; The cloud service receives an indication from the DNS of a policy associated with the user account, wherein the policy indicates a Service Level Agreement (SLA) associated with the user account; and The identification of the performance requirements associated with the user account is based at least in part on the SLA associated with the user account.

7. The communication method according to any one of claims 1 to 6, wherein, The request includes an indication of the current location associated with the client device, and the method further includes: The cloud service identifies a first POP of one or more POPs of the SDCI based at least in part on the current location associated with the client device; and The path between the client device and the destination device is calculated at least in part based on the first POP among one or more POPs that identify the SDCI.

8. A communication system, comprising: One or more processors; as well as One or more computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: The cloud service receives a request for an end-to-end path between a client device and a destination device, wherein the end-to-end path is established at least in part using Software-Defined Cloud Interconnect (SDCI). For the user account associated with the client device, identify the performance requirements associated with the user account for transmitting traffic on the end-to-end path; Identify performance data, which indicates a performance metric for one or more paths including one or more Point of Presence (POP) nodes of the SDCI; The path between the client device and the destination device is calculated at the cloud service based at least in part on the performance metric associated with the one or more paths, which satisfy the performance requirements associated with the user account; and The cloud service provides an indication of the path to at least one device associated with the path.

9. The communication system according to claim 8, wherein, The operation also includes: transmitting data from the client device to the destination device using the path.

10. The communication system according to claim 8, wherein, The performance data is first performance data and the performance metric is first performance metric, and the operation further includes: The first performance data is received at the cloud service and from the software-defined networking SDN controller associated with the cloud service at the first time. The first performance data indicates a first performance metric for the one or more paths between one or more POPs of the SDCI. The first performance metric associated with the first time is stored in the database associated with the cloud service; At the cloud service and at a second time, second performance data is received from the SDN controller, the second performance data indicating a second performance metric for the one or more paths between one or more POPs of the SDCI, wherein the second time is after the first time; and The second performance metric associated with the second time is stored in the database associated with the cloud service.

11. The communication system according to claim 10, wherein, The path is the first path, and the operation further includes: The cloud service determines, at least in part, that the second performance metric is more advantageous than the first performance metric based on the performance requirements. The second path between the client device and the destination device is calculated at the cloud service, at least in part, based on the determination that the second performance metric is more advantageous than the first performance metric; and The second path is used to transmit the data from the client device to the destination device.

12. The communication system according to claim 8, wherein, The performance requirements include at least one of the following: Bandwidth requirements; Latency requirements; jitter requirement; or Security requirements.

13. The communication system according to any one of claims 8 to 12, wherein, The request includes an indication of the current location associated with the client device, and the operation further includes: At the cloud service, the edge POP associated with the SDCI is identified at least in part based on the current location associated with the client device and the performance requirements associated with the user account; Provide an instruction to the edge POP to the software-defined networking SDN controller associated with the cloud service to establish a first secure tunnel between the client device and the edge POP; At the cloud service, based at least in part on the performance requirements and the edge POP, one or more internal POPs of the SDCI are identified from one or more POPs of the SDCI, the one or more internal POPs of the SDCI including a first internal POP that can be connected to the edge POP; Provide the SDN controller with an indication of one or more internal POPs of the SDCI to establish a second secure tunnel using the one or more paths between the one or more internal POPs of the SDCI; Provide the SDN controller with an indication of the first internal POP in one or more internal POPs of the SDCI to connect the first secure tunnel to the second secure tunnel; and At least in part, this is based on connecting the first secure tunnel to the second secure tunnel, enabling data to be transmitted from the client device to the destination device using the path described above.

14. The communication system according to claim 13, further comprising: A first candidate path is determined at the cloud service, the first candidate path including one or more first paths between one or more first POPs in one or more POPs of the SDCI, the one or more first paths being associated with a first performance metric in the performance metric; A second candidate path is determined at the cloud service, the second candidate path including one or more second paths between one or more second POPs in one or more POPs of the SDCI, the one or more second paths being associated with a second performance metric in the performance metric; At the cloud service, the first performance metric is determined to be more advantageous than the second performance metric, at least in part, based on the performance requirements. as well as Calculating the path between the client device and the destination device includes: calculating the path of the one or more first paths between one or more first POPs including the SDCI, based at least in part on determining that the first performance metric is more advantageous than the second performance metric.

15. A communication method, comprising: The cloud service receives a request for an end-to-end path between a client device and a destination device, the request indicating performance requirements associated with a user account for delivering traffic on the end-to-end path, and wherein the end-to-end path is established at least in part using Software-Defined Cloud Interconnect (SDCI). Identify performance data, which indicates a performance metric for one or more paths including one or more Point of Presence (POP) nodes of the SDCI; At the cloud service, the path between the client device and the destination device is calculated, at least in part, based on the performance metric associated with the one or more paths, which satisfy the performance requirements associated with the user account; and The path is used to transmit data from the client device to the destination device.

16. The communication method according to claim 15, wherein, The request is received from the Domain Name Service (DNS) associated with the cloud service, and the performance requirement indicates the Service Level Agreement (SLA) associated with the user account.

17. The communication method according to claim 15, wherein, The first path in one or more paths between one or more POPs of the SDCI utilizes a first type of network, while the second path in one or more paths between one or more POPs of the SDCI utilizes a second type of network, which is different from the first type of network.

18. The communication method according to claim 15, wherein, The performance requirements include at least one of the following: Bandwidth requirements; Latency requirements; jitter requirement; or Security requirements.

19. The communication method according to claim 15, further comprising: The cloud service sends an indication of the path between the client device and the destination device to the software-defined networking SDN controller associated with the cloud service. as well as The path between the client device and the destination device is programmed by the SDN controller at least in part based on the indication, wherein programming the path includes providing an indication of the path to at least one of one or more POPs of the SDCI.

20. The communication method according to any one of claims 15 to 19, further comprising: A first candidate path is determined at the cloud service, the first candidate path including one or more first paths between one or more first POPs in one or more POPs of the SDCI, the one or more first paths being associated with a first performance metric in the performance metric; A second candidate path is determined at the cloud service, the second candidate path including one or more second paths between one or more second POPs in one or more POPs of the SDCI, the one or more second paths being associated with a second performance metric in the performance metric; The cloud service determines that the first performance metric is more advantageous than the second performance metric, at least in part, based on the performance requirements. as well as Calculating the path between the client device and the destination device includes: calculating the path of the one or more first paths between one or more first POPs including the SDCI, based at least in part on determining that the first performance metric is more advantageous than the second performance metric.

21. A communication device, comprising: A module for receiving requests for an end-to-end path between a client device and a destination device at a cloud service, wherein the end-to-end path is established at least in part using Software-Defined Cloud Interconnect (SDCI). A module for identifying, for example, the performance requirements associated with a user account for transmitting traffic on the end-to-end path for a user account associated with the client device. A module for identifying performance data, which indicates a performance metric for one or more paths including one or more Points of Presence (POP) nodes of the SDCI; A module at the cloud service that calculates the path between the client device and the destination device based at least in part on the performance metric associated with the one or more paths, which satisfy the performance requirements associated with the user account; and Module for enabling data to be transmitted from the client device to the destination device using the path.

22. The communication apparatus of claim 21, further comprising a module for implementing the method of any one of claims 2 to 7.

23. A communication device, comprising: A module for receiving, at a cloud service, a request for an end-to-end path between a client device and a destination device, the request indicating performance requirements associated with a user account for delivering traffic on the end-to-end path, and wherein the end-to-end path is established at least in part using Software-Defined Cloud Interconnect (SDCI). A module for identifying performance data that indicates performance metrics for one or more paths including one or more Points of Presence (POP) nodes of the SDCI; A module for calculating, at least in part, the path between the client device and the destination device at the cloud service based on the performance metric associated with the one or more paths, wherein the one or more paths satisfy the performance requirements associated with the user account; and A module for using the path to transmit data from the client device to the destination device.

24. The communication apparatus of claim 23, further comprising a module for implementing the method of any one of claims 16 to 20.

25. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 15 to 20.

26. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 15 to 20.

Images