FIELD OF THE INVENTION

The invention relates to computer networking, particularly the provisioning of network ports and virtual links for a computer based network.

BACKGROUND OF THE INVENTION

Consumers and enterprises have increasingly shifted toward cloud-based networking for communication and data services. This shift has created challenges due to an increasing variety of network configurations available from a growing number of cloud service providers.

For example, when implementing a cloud-based networking solution, it can be extremely difficult to understand the various network configurations and options available from the different cloud service providers. Each cloud service provider can have its own set of options for implementing its respective solutions, and each solution may differ in costs and accompanying services.

Exchange of data between two cloud providers is typically controlled by a customer. The customer is required to maintain a router and bring data from the respective cloud providers back to a customer device that controls routing. This requires the customer to install and maintain a router, provide space and power, and maintain knowledge of how to configure the customer router for each cloud service provider with which

communication is required.

There is also the potential to be wasteful of network resources, particularly in a case where two or more cloud service providers are physically located nearby to each other, yet both are located some distance from a customer.

It is an object of at least preferred embodiments of the present invention to address some of the aforementioned disadvantages. An additional or alternative object is to at least provide the public with a useful choice. SUMMARY OF THE INVENTION

In accordance with an aspect of the invention, a method of provisioning a virtual link between endpoints in a data network comprises: receiving a first request to establish a network port comprising an interface for a dedicated network connection between a first endpoint and a remote network, the first endpoint remote from a client premises;

receiving a second request to attach to the network port a virtual link between the first endpoint and at least one second endpoint, the at least one second endpoint remote from the client premises; generating configuration data for the network port and the virtual link; and based at least partly on the configuration data, configuring one or more physical network resources for provisioning the virtual link between the first endpoint and the at least one second endpoint, the virtual link having a data path that does not include the client premises.

The term 'comprising' as used in this specification means 'consisting at least in part of'. When interpreting each statement in this specification that includes the term

'comprising', features other than that or those prefaced by the term may also be present. Related terms such as 'comprise' and 'comprises' are to be interpreted in the same manner.

In an embodiment the at least one second endpoint is/are associated with at least one of a cloud service provider, a public network.

In an embodiment the method further comprises establishing the virtual link between the first endpoint and the at least one second endpoint, the virtual link including a point- to-point virtual link.

In accordance with a further aspect of the invention a system comprises: a processor; and a computer-readable storage medium having stored thereon instructions which, when executed by the processor, cause the processor to: receive a first request to establish a network port comprising an interface for a dedicated network connection between a first endpoint and a remote network, the first endpoint remote from a client premises; receive a second request to attach to the network port a virtual link between the first endpoint and at least one second endpoint, the at least one second endpoint remote from the client premises; generate configuration data for the network port and the virtual link; and based at least partly on the configuration data, configure one or more physical network resources for provisioning the virtual link between the first endpoint and the at least one second endpoint, the virtual link having a data path that does not include the client premises. In an embodiment the at least one second endpoint is/are associated with at least one of a cloud service provider, a public network.

In an embodiment the method further comprises establishing the virtual link between the first endpoint and the at least one second endpoint, the virtual link including a point- to-point virtual link.

In accordance with a further aspect of the invention a computer-readable storage device has stored therein instructions that, upon being executed by a processor, cause the processor to: receive a first request to establish a network port comprising an interface for a dedicated network connection between a first endpoint and a remote network, the first endpoint remote from a client premises; receive a second request to attach to the network port a virtual link between the first endpoint and at least one second endpoint, the at least one second endpoint remote from the client premises; generate

configuration data for the network port and the virtual link; and based at least partly on the configuration data, configure one or more physical network resources for

provisioning the virtual link between the first endpoint and the at least one second endpoint, the virtual link having a data path that does not include the client premises.

In an embodiment the at least one second endpoint is/are associated with at least one of a cloud service provider, a public network.

In an embodiment the method further comprises establishing the virtual link between the first endpoint and the at least one second endpoint, the virtual link including a point- to-point virtual link.

The invention in one aspect comprises several steps. The relation of one or more of such steps with respect to each of the others, the apparatus embodying features of construction, and combinations of elements and arrangement of parts that are adapted to affect such steps, are all exemplified in the following detailed disclosure.

To those skilled in the art to which the invention relates, many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting. Where specific integers are mentioned herein which have known equivalents in the art to which this invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

In addition, where features or aspects of the invention are described in terms of Markush groups, those persons skilled in the art will appreciate that the invention is also thereby described in terms of any individual member or subgroup of members of the Markush group.

As used herein, '(s)' following a noun means the plural and/or singular forms of the noun.

As used herein, the term 'and/or' means 'and' or 'or' or both.

The terms 'component', 'module', 'system', 'interface', and/or the like as used in this specification in relation to a processor are generally intended to refer to a computer- related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The term 'connected to' as used in this specification in relation to data or signal transfer includes all direct or indirect types of communication, including wired and wireless, via a cellular network, via a data bus, or any other computer structure. It is envisaged that they may be intervening elements between the connected integers. Variants such as’in communication with’,’joined to’, and’attached to’ are to be interpreted in a similar manner. Related terms such as’connecting’ and’in connection with’ are to be

interpreted in the same manner.

It is intended that reference to a range of numbers disclosed herein (for example, 1 to 10) also incorporates reference to all rational numbers within that range (for example, 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9, and 10) and also any range of rational numbers within that range (for example, 2 to 8, 1.5 to 5.5, and 3.1 to 4.7) and, therefore, all sub-ranges of all ranges expressly disclosed herein are hereby expressly disclosed.

These are only examples of what is specifically intended and all possible combinations of numerical values between the lowest value and the highest value enumerated are to be considered to be expressly stated in this application in a similar manner.

In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents or such sources of information is not to be construed as an admission that such documents or such sources of information, in any jurisdiction, are prior art or form part of the common general knowledge in the art.

In the description in this specification reference may be made to subject matter which is not within the scope of the appended claims. That subject matter should be readily identifiable by a person skilled in the art and may assist in putting into practice the invention as defined in the presently appended claims.

Although the present invention is broadly as defined above, those persons skilled in the art will appreciate that the invention is not limited thereto and that the invention also includes embodiments of which the following description gives examples.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred forms of the computer networking techniques will now be described by way of example only with reference to the accompanying figures in which :

Figure 1 shows a prior art system for interconnecting networks;

Figure 2 shows a system for interconnecting networks;

Figure 3 shows an example cloud architecture that can be utilized in accordance with some embodiments;

Figure 4 illustrates a schematic block diagram of an example controller from figure 3;

Figure 5 shows an example method for provisioning a virtual link between endpoints in a data network;

Figure 6 illustrates a diagram of an example interconnection model between clouds or networks;

Figure 7 illustrates an example configuration of a fabric from figure 6; and Figure 8 illustrates a second example configuration of a fabric from figure 6.

DETAILED DESCRIPTION

The approaches set forth below can allow users to provision network services through a control interface for creating network ports interconnecting devices and networks, such as network carriers, service providers, cloud providers, and so forth. The network ports can be configured through the control interface, which can provide an interactive display for establishing the network ports interconnecting the devices and networks.

The control interface can allow users to add and purchase network services, edit the network services, remove the network services, or monitor the network services. The purchased network services can be automatically configured by interconnecting various networks or clouds based on the settings specified via the control interface.

Figure 1 illustrates a schematic diagram of a prior art system 100 for interconnecting networks. A client 105 within a client premises connects to a network fabric 110. One example of a link to connect the client 105 to the network fabric 110 includes a data cable 115 within a data centre. In an embodiment the data cable is positioned within the client premises, for example within a single building or campus of buildings.

Examples of client 105 include one or more of: endpoint, enterprise, network, campus, or data centre.

The client 105 connects to the network fabric 110 to establish one or more links to one or more endpoints. Examples of endpoints are shown by way of example at 130, 132,

134 and 136. In an embodiment, network fabric 110 includes physical resources for establishing, monitoring, configuring, managing, and/or troubleshooting the one or more links.

Figure 1 shows client 105 connected to endpoint 130 via a combination of data cable 115, network fabric 110 and link 140. The client 105 is shown connected to endpoint 132 via a combination of data cable 115, network fabric 110 and link 142. Endpoint 130 and endpoint 132 are shown connected by a virtual link 144 shown in dashed lines.

Endpoint 134 is shown connected to client 105 via data cable 115, fabric 110 and link 146, as well as being shown connected to endpoint 132 via virtual link 148. Endpoint 136 is shown connected to client 105 via data cable 115, fabric 110, and link 150, as well as being shown connected to endpoint 134 via virtual link 152.

The links 140-152 include virtual links or circuits to the endpoints 130-136. For example, in an embodiment the links 140-152 comprise dedicated or point-to-point links or tunnels to the endpoints 130-136. For example, link 140 in an embodiment comprises an MPLS pseudowire connecting client 105 with endpoint 130.

One drawback with system 100 is that data in each case must be controlled by the client. For example in order to exchange data between endpoint 130 and endpoint 132 via virtual link 144, the data is required to be transmitted to client 105 via link 140, network fabric 110, and data cable 115. The client 105 then causes the data to be routed to endpoint 132 via data cable 115, network fabric 110 and link 142.

This arrangement requires the client 105 to install and maintain a router, provide space and power, and have knowledge of how to configure the client router for each endpoint for which communication is required.

System 100 has the potential to be wasteful of network resources, particularly in a case where endpoints 130 and 132 are nearby to each other, yet are positioned some distance from client 105.

Figure 2 shows an embodiment of a system 200 for interconnecting networks. The system includes fabric 210 that is configured to operate differently to the network fabric 110 of figure 1. A client 205 connects to the fabric 210 via a link such as link 215. Client 205 and link 215 shown in figure 2 are similar to client 105 and link 115 shown in figure 1.

In an embodiment the fabric 210 includes one or more private and/or public networks. Examples of fabrics are described in more detail below. In an embodiment, fabric 210 includes one or more of: a datacenter, a cloud, at least one public network, at least one private network, a cluster of public and/or private networks, or any other suitable network or combination of networks.

As shown in figure 2, data is routed via the fabric 210 between endpoints 230-236. The endpoints 230-236 include one or more of: clouds, carriers, service providers, public networks, private networks, or datacenters. Examples of clouds include public clouds, private clouds, hybrid clouds. Examples of cloud architectures are further described below.

By way of example, endpoint 230 is shown as a network provider, endpoint 232 is shown as a storage provider, endpoint 234 is shown as a cloud services provider, and endpoint 236 is shown as an IP voice and data services provider.

In an embodiment, endpoints 230-236 provide services to, or extend current services from, client 205. For example, endpoints 230-236 can be configured to provide additional bandwidth services, cloud bursting services, or media services to client 205 and/or consumers of services from client 205.

In an embodiment the endpoints are physically separated and/or remote from the client 205 or customer premises. There is no requirement that data be routed between endpoints 230-236 via data cable 215 and client 205. This means that data can be exchanged directly between endpoints 230-236 without having to be sent via the client 205.

Endpoint 230 for example is connected to network fabric 210 via link 240. Endpoint 232 is connected to network fabric 210 via link 242. Endpoints 230 and 232 are connected to each other via virtual link 244. Data exchanged between endpoint 230 and endpoint 232 is transmitted via link 240, network fabric 210 and link 242. There is no requirement that the data be transmitted to client 205 via data cable 215.

Endpoints 234 and 236 are similarly connected to the network fabric 210 via links 246 and 250 respectively. Endpoints 232 and 234 are connected to each other via virtual link 248. Endpoints 234 and 236 are connected to each other via virtual link 252.

The present technology can be utilized in one or more cloud computing environments.

Figure 3 illustrates an example cloud architecture 300 that can be utilized in accordance with some embodiments. This architecture 300 is further described in our International PCT patent specification WO 2018/020446 which is hereby incorporated by reference.

Cloud 302 can be a public, private, and/or hybrid cloud system which may include one or more public and private cloud networks in communication with each other. In an embodiment the cloud architecture 300 is used to implement the network fabric 210 of figure 2.

Cloud 302 can include resources, such as one or more Firewalls 304; Load Balancers 306; WAN optimization platforms 308; devices 310, such as switches, routers, intrusion detection systems, etc.; servers 312, such as a primary use network server, a data backup server, dynamic host configuration protocol (DHCP) server, a domain naming system (DNS) server, a storage server, an authentication server, etc.; virtual machines (VMs) 314; and controllers 316, such as a communications controller or management device.

Cloud resources can be physical, software, virtual, or any combination thereof. For example, a cloud resource can include a server running one or more VMs or hosting one or more databases. Moreover, cloud resources can be provisioned based on one or more of: requests (e.g., client or tenant requests), schedules, triggers, events, signals, messages, alerts, agreements, necessity, subscriptions, purchases, or any other factor.

Cloud 302 can provision various types of resources or services, such as network recovery services, application services, software development services, database services, storage services, management services, monitoring services, configuration services, administration services, backup services, disaster recovery services, bandwidth or performance services, intrusion detection services, VPN services, or any type of services to any device, server, network, client, or tenant.

Other example service models include software as a service, infrastructure as a service, platform as a service, backend as a service, desktop as a service, or information technology management as a service.

In addition, cloud 302 can handle traffic and manage resources and configurations. For example, cloud 302 can provide network routing/re-routing services, network data backup services, configuration services, such as automated deployments, automated wireless configurations, automated policy implementations, and the like.

In some embodiments, the cloud 302 can collect data about a client or network and generate configuration settings for specific service, device, or networking deployments. For example, the cloud 302 can generate one or more of: security policies, subnetting and routing schemes, forwarding schemes, NAT settings, VPN settings, or any other type of configurations. The cloud 302 can then push or transmit the necessary data and settings to specific devices or components to manage a specific implementation or deployment.

For example, the cloud 302 can generate VPN settings, such as IP mappings, port number, and security information, and send the VPN settings to specific, relevant device(s) or component(s) identified by the cloud 302 or otherwise designated.

The relevant device(s) or component(s) can then use the VPN settings to establish a VPN tunnel according to the settings. As another example, the cloud 302 can generate and manage network diagnostic tools or graphical user interfaces, or automate the interconnection between multiple networks and resources.

Furthermore, cloud 302 can provide specific services for clients - namely, client A 205A, client B 205B, and client C 205C. For example, cloud 302 can deploy a network or specific network component, configure links or devices, automate services or functions, or provide any other services for the clients.

Other non-limiting example services performable by cloud 302 can include network administration services, network monitoring services, content filtering services, application control, WAN optimization, firewall services, gateway services, storage services, protocol configuration services, wireless deployment services, interconnection services, network services, and so forth. To this end, the clients 205A, 205B and 205C can connect with cloud 302 through networks 330, 332, and 334, respectively. More specifically, client A 205A, client B 205B, and client C 205C can each connect with cloud 302 through networks 330, 332, and 334, respectively, in order to access resources from cloud 302, communicate with cloud 302, or receive any services from cloud 302.

Networks 330, 332, and 334 can each refer to a public network, such as the Internet; a private network, such as a LAN; a combination of networks; or any other network, such as a VPN.

Moreover, the clients can each include one or more networks. For example, client A 105, client B 320, and client C 322 can each include one or more LANs and VLANs. A client can represent a branch network, such as a LAN, or multiple branch networks, such as multiple remote networks.

For example, client A 205A can represent a single LAN network or branch, or multiple branches or networks, such as a branch building, office, or campus network in Los Angeles and another branch building, office, or campus network in New York. Client A 205A, client B 205B, and client C 205C can thus include campus networks, enterprise networks, provider networks, datacenters, etc.

If a client includes multiple branches or networks, the multiple branches or networks can each have a designated connection to the cloud 302. For example, each branch or network can maintain a tunnel to the cloud 302. Alternatively, all branches or networks for a specific client can connect to the cloud 302 via one or more specific branches or networks.

For example, traffic for the different branches or networks of a client can be routed through one or more specific branches or networks. Further, client A 205A, client B 205B, and client C 205C can each include one or more routers, switches, appliances, client devices, VMs, or any other devices.

Each client can also maintain links between branches. For example, client A 205A can have two branches, and the branches can maintain a link between each other. Thus, in some cases, branches can maintain a tunnel between each other, such as a VPN tunnel.

Moreover, the link or tunnel between branches can be generated and/or maintained by the cloud 302. For example, the cloud 302 can collect network and address settings for each branch and use those settings to establish a tunnel between branches. Cloud 302 can maintain information about each client network, in order to provide or support specific services for each client, such as network traffic monitoring, network traffic routing/re-routing, security, or network services. Cloud 302 can also maintain one or more links or tunnels to the clients. For example, cloud 302 can maintain a virtual circuit to one or more devices in client A's network.

The cloud 302 can also monitor device and network health and status information for client A 205A, client B 205B, and client C 205C. To this end, client A 205A, client B 205B, and client C 205C can synchronize information with cloud 302.

Cloud 302 can also manage and deploy services for the clients. For example, cloud 302 can collect network information about client A 205A and generate network and device settings to automatically deploy a service for client A 205A.

In addition, cloud 302 can update device, network, and service settings for the clients. Cloud 302 can also interconnect a client with another network or cloud either directly or indirectly through the cloud 302, for example.

Those skilled in the art will understand that the cloud architecture 302 can include any number of nodes, devices, links, networks, or components. In fact, embodiments with different numbers and/or types of clients, networks, nodes, cloud components, servers, software components, devices, virtual or physical resources, configurations, topologies, services, appliances, deployments, or network devices are also contemplated herein. Further, cloud 302 can include any number of types of resources, which can be accessed and utilized by clients or tenants. The illustration and examples provided herein are intended for clarification of some embodiments of the present technology.

Moreover, as far as communications, packets (e.g., traffic and/or messages) can be exchanged among the various nodes and networks in the cloud architecture 300 using specific network protocols. In particular, packets can be exchanged using wired protocols, wireless protocols, security protocols, OSI-Layer specific protocols, labels, or any other protocols. Some non-limiting examples of protocols can include Session Initiation Protocol (SIP), protocols from the Internet Protocol Suite, such as TCP/IP; OSI (Open Systems Interconnection) protocols, such as L1-L7 protocols; routing protocols, such as RIP, IGP, BGP, STP, ARP, OSPF, EIGRP, NAT; or any other protocols or standards, such as HTTP, SSH, SSL, RTP, FTP, SMTP, POP, PPP, NNTP, IMAP, Telnet,

SSL, SFTP, WIFI, Bluetooth, VTP, ISL, IEEE 802 standards, L2TP, IPSec, etc.

In an embodiment, at least some packets exchanged among nodes and networks in the cloud architecture 300 include Quality of Service (QoS) markings. In addition, various hardware and software components or devices can be implemented to facilitate communications both within a network and between networks. The various hardware and software components or devices can also be referred to as nodes and some examples are switches, hubs, routers, access points (APs), antennas, network interface cards (NICs), modules, cables, firewalls, servers, repeaters, sensors, and the like.

Figure 4 illustrates a schematic block diagram of an example controller 316 from figure 3. Controller 316 can serve as a cloud service management system for cloud 302. In particular, controller 316 can manage cloud operations, client communications, service provisioning, network configuration and monitoring, and the like.

For example, controller 316 can manage cloud service provisioning or deployment, such as cloud storage, media, streaming, security, or administration services. Controller 316 can also manage VMs; networks, such as client networks; service provisioning; virtual circuits between networks or clouds; interfaces; network ports; and so forth.

In an embodiment the controller 316 is configured to read, honour, re-write and/or apply Quality of Service (QoS) markings on at least one packet. QoS markings on packets may be used, stored and/or analysed within the controller 316. Such QoS markings function as labels within the system.

Controller 316 can include several subcomponents, including hardware and software components such as a scheduling function 400, a processor 402, a dashboard process 404, data storage 406, a networking function 408, a management layer 410, and a communication interface 412.

The various subcomponents can be implemented as hardware and/or software components. Examples of components include one or more of a processor, a memory, modules, logic, virtual workload, data structures.

Moreover, although figure 4 illustrates one example configuration of the various components of controller 316, those of skill in the art will understand that the

components can be configured in a plurality of different ways and can include any other type and number of components.

For example, networking function 408 and management layer 410 can belong to one software module or multiple separate modules. Other modules can be combined or further divided up into more subcomponents. Scheduling function 400 can manage scheduling of procedures, events, services, or communications. For example, scheduling function 400 can schedule when resources should be allocated from cloud 302.

As another example, scheduling function 400 can schedule when specific instructions or commands should be transmitted to a network, for example one or more client devices.

Scheduling function 400 can provide scheduling for operations performed or executed by the various subcomponents of controller 316. Scheduling function 400 can also schedule resource slots, virtual machines, bandwidth, device activity, status changes, nodes, updates, policies, circuits, services, and the like.

Dashboard process 404 can provide an interface or front end where clients can access, consume, purchase, configure, remove, manage, and generally monitor cloud and network services.

For example, dashboard process 404 can provide a web-based frontend where clients can configure client devices or networks that are cloud-managed, provide client preferences, configure policies, enter data, upload statistics, configure interactions or operations, etc.

As another example, dashboard process 404 can provide an interactive display where users can interconnect their network or device with one or more networks or clouds, such as cloud 302 and a separate cloud or datacenter, for example.

Dashboard process 404 can provide visibility information, such as views of client networks or devices, and even provide diagnostic information. For example, dashboard process 404 in an embodiment provides one or more of a view of the status or conditions of the client's network, the operations taking place, services, performance, a topology or layout, specific network devices, protocols implemented, running processes, errors, notifications, alerts, network structure, ongoing communications, data analysis.

Dashboard process 404 can provide a graphical user interface (GUI) for the client to monitor the client's network(s), devices, statistics, services, connections, account(s), configurations, errors, notifications, etc., and even make modifications or setting changes through the GUI.

The GUI can depict charts, lists, tables, tiles, network trees, maps, topologies, symbols, structures, or any graphical object or element. In addition, the GUI can use color, font, shapes, or any other characteristics to depict scores, alerts, or conditions. Dashboard process 404 can also handle user or client requests. For example, the client can enter a request through a corresponding GUI to establish or configure a virtual circuit or service, modify configurations, add resources to a current service, purchase or cancel a service, etc.

Data storage 406 can include any data or information, such as management data, statistics, settings, preferences, profile data, account data, transactions, logs, notifications, attributes, configuration parameters, client information, network information, and the like.

For example, controller 316 can collect network statistics from a client (e.g., client A 105) and store the statistics in data storage 406. Data storage 406 can also include performance and/or configuration information.

This way, controller 316 can use such data to perform management or service operations for the client. Data storage 406 in an embodiment includes one or more of: a physical storage or memory device, a database, a folder, a disk, any storage medium on controller 316, or any storage medium directly/indirectly accessible to controller 316.

Networking function 408 in an embodiment includes one or more of a module, application, appliance, logic, processor, function capable of performing network operations.

Networking function 408 can thus perform networking calculations, such as network addressing, or networking service or operations, such as auto virtual circuit configuration or traffic routing/re-routing.

For example, networking function 408 in an embodiment is configured to perform one or more of: filtering functions, switching functions, failover functions, high availability functions, network or device deployment functions, resource allocation functions, messaging functions, traffic analysis functions, port configuration functions, mapping functions, packet manipulation functions, path calculation functions, loop detection, cost calculation, error detection, or otherwise manipulate data or networking devices.

Networking function 408 can handle networking requests from other networks or devices and establish links between devices. Networking function 408 can also perform queueing, messaging, or protocol operations.

Management layer 410 can include logic to perform management operations. For example, management layer 410 can include the logic to allow the various components of controller 316 to interface and work together. Management layer 410 in an embodiment includes one or more of the logic, functions, software, or procedures to allow controller 316 to perform monitoring, management, control, deployment, configuration, and administration operations of other devices, networks, clouds, providers, clients (e.g., clients 105, 320, 322); or cloud 302 operations and/or applications, services provided to clients, or any other component or procedure. Management layer 410 can include the logic to operate controller 316 and perform particular services configured on controller 316.

Moreover, management layer 410 can initiate, enable, or launch other instances in controller 316 and/or cloud 302. In some embodiments, management layer 410 can also provide authentication and security services for cloud 302, clients 105, 320, 322, controller 316, and/or any other device or component.

Further, management layer 410 can manage nodes, resources, VMs, settings, policies, protocols, communications, services, clouds, datacenters, networks, and the like. In some embodiments, management layer 410 and networking function 408 can be part of the same module. However, in some embodiments, management layer 410 and networking function 408 can be separate layers and/or modules.

Communication interface 412 allows controller 316 to communicate with other devices or networks, such as clients 105, 320, 322 or other clouds or providers. Communications interface 412 can be a network interface card (NIC), and can include wired and/or wireless capabilities.

Communication interface 412 allows controller 316 to send and receive data from other devices and networks. In some embodiments, controller 316 can include multiple communications interfaces for redundancy or failover. For example, controller 316 can include dual NICs for connection redundancy or for multiple lines or channels.

Figure 5 shows an example method 500 for provisioning a virtual link between endpoints in a data network. Examples of endpoints include endpoints 140, 142, 144 and 146 shown in figure 2. In an embodiment a client 105 uses the dashboard process 404 from figure 4 to establish a virtual link between endpoints in the data network.

The client 105 enters a first request to establish a network port comprising an interface for a dedicated network connection between a first endpoint and a remote network. An example of a first endpoint is endpoint 140. An example of a remote network is fabric 210. The first request is received 502 by the controller 316.

The client uses the same dashboard process 404, or a different dashboard process, to enter a second request to attach to the network port a virtual link between the first endpoint 140 and one or more second endpoints of the remote network. An example of a second endpoint is endpoint 142. An example of a virtual link is shown at 128. The second request is received 504 by the controller 316. In an embodiment the controller 316 generates 506 configuration data for the network port and the virtual link 128. The configuration data facilitates the building of a data path (Layer 2) and/or the logical connectivity between the endpoints (Layer 3).

The data paths comprise virtual links directly between endpoints from the user viewpoint. The data paths are in fact routed via network fabric 210 but not client 205.

In an embodiment the configuration data includes at least one variable.

One example of a group of variables is associated to the endpoint in question. For example different endpoints have the potential to require different configurations.

Another example of a group of variables is associated to any intricacies associated to the endpoint. For example some cloud providers require double tagged VLANs while others do not. These considerations are associated to the layer 2 component of the build. In an embodiment the configuration data includes one or more of:

• Assuming physical infrastructure is in place, the setup of the VLAN between the endpoints.

• Any intricacies associated with VLAN build (number of VLAN Tags used on the service)

• Bandwidth associated to the service

• Confirmation that the build is successful.

A further example of a group of variables relates to the Layer 3 configuration. This configuration comprises a unique combination of a cloud and a customer. It includes IP connectivity as well as routing exchange. One example of a routing exchange is BGP. Assuming the routing exchange is BGP, the configuration data in an embodiment includes one or more of:

• The IP addresses at both the local and remote endpoint (Layer 3 connectivity)

• The BGP configuration at both ends, including AS number, networks advertised (Routing information and exchange). In an embodiment the information retrieval and configuration steps are combined to achieve configuration in fewer steps.

The controller 316 configures 508 one or more physical network resources for provisioning for example link 240 between endpoint 230 and network fabric 210, link 242 between endpoint 232 and network fabric 210, and virtual link between endpoint 230 and endpoint 232. The configuring is based at least partly on the configuration data generated in step 506.

The first endpoint 230 and the second endpoint 232 are physically separated from client 205, remote from client 205 and/or not associated to a customer premises associated to client 205. In an embodiment the endpoint 230 and the second endpoint 232 are both remote from the customer premises. Virtual link 244 facilitates data exchange between first endpoint 230 and second endpoint 232 without requiring to be routed through the customer premises.

Figure 6 illustrates a diagram of an example interconnection model 600 between clouds or networks, in accordance with some embodiments.

In an embodiment the interconnection model 600 includes a first cloud 610 and a second cloud 660. Examples of first cloud 610 include private and/or public cloud, enterprise datacenter, network, endpoint, campus. In an embodiment the second cloud 660 is directly connected or separated by one or more networks, such as the Internet.

In some embodiments, the first cloud 610 is connected to the second cloud 660 via portions of the Internet and dedicated paths associated with the first cloud and/or the second cloud.

In an embodiment the first cloud 610 and second cloud 660 are connected via a communication link 650 between cloud gateway 612 and cloud gateway 662. Data packets and traffic can be exchanged among the devices of the clouds 610, 660 using predefined network communication protocols.

In an embodiment the communication link 670 includes one of more of: a dedicated virtual or physical line, a virtual circuit, a pseudowire, a virtual private network, or a point-to-point network. Moreover, the communication link 670 can be established using a remote network 672.

The remote network 672 can be a datacenter, a private network, a distributed network, or cloud. The communication link 670 can also be established using other, intermediary networks, such as a public network (i.e., the Internet), which can interconnect the clouds 610, 660 with or without the remote network 672.

First cloud 610 can include a virtual supervisor module 614, a hypervisor 616 (also called a virtual machine manager or monitor), and one or more VMs 618. Virtual supervisor module 614 can be used to create VMs in the cloud. Each of the VMs can host an application or service, and can operate as if each resides in the cloud.

Hypervisor 616 can be configured by the virtual supervisor module 614, and can provide an operating system for one or more VMs. Hypervisor 616 can include computer software, firmware, and/or hardware to create and/or run one or more VMs. Moreover, hypervisor 616 can run one or more VMs on one or more computers called host machines. Each of the VMs can be referred to as a guest machine, and can run a guest operating system.

First cloud 610 can also include a hybrid cloud manager 620, which can be a

management plane VM for auto-provisioning resources in a hybrid cloud solution. The hybrid cloud manager 620 can be a management platform (which can include physical or virtual components, such as a VM) running in the first cloud 610, and can be generally responsible for providing hybrid cloud operations, translating between cloud interfaces, management of cloud resources, dynamic instantiating of cloud gateways and cloud VM components (e.g., VM 618, 664) through virtualization platform and cloud provider APIs, for example.

The hybrid cloud manager 620 may also monitor components (e.g., the cloud gateways 612, 662, one or more private application VMs, communication link 672, etc.) and/or manage those components.

Each cloud or network can include switch and/or network infrastructure for providing features and network services such as switching network traffic locally at the cloud, providing consistent enterprise network polices, allowing insertion or provisioning of various network services (e.g., load balancers, firewalls, content servers, web services, voice and data services, etc.).

For example, first cloud 610 can include enterprise router 622 and second cloud 660 can include router 666 for routing traffic between cloud components or devices and/or within the network fabric. Moreover, the switch and/or network infrastructure can form a network topology, such as a spine-leaf or folded CLOS topology, which can include one or more switches, routers, segments, servers, domains, tenants, etc. Communication link 670 can take several forms. For example, communication link 670 can include, or can be established via, remote network 672 and/or any other network, such as a public network (e.g., the Internet), a private network (e.g., a LAN), or a combination thereof.

Communication link 670 can also include a virtual private network (VPN) or tunnel, a point-to-point link, a pseudowire, a virtual circuit, etc., as previously noted.

The communication link 670 can offer secure transport connections between the clouds. Moreover, the communication link 670 can be based on tunneling or point-to-point technologies which can provide customers inter or intra-datacenter network connectivity and various network topologies. Such technologies can also extend the network (e.g., cloud or enterprise datacenter) at the network layer (Layer 3 or "L3" of the OSI model).

Networks created at a cloud or datacenter (e.g., second cloud 660) can include new subnets, segments, overlays, and VMs to extend a different cloud or datacenter. Specific services or applications (e.g., access control lists, firewall policies, domain name services, etc.) can be accordingly configured or modified in order for attached VM systems to communicate through the underlay and/or between clouds.

Some cloud embodiments can utilize a secure transport layer (e.g., Layer 4 or "L4") tunnel as the communication link 670 between the first cloud gateway 612 in the first cloud 610 and a second cloud gateway 662 in the second cloud 660.

The secure transport layer tunnel can be configured to provide a link layer (e.g., Layer 2 or "L2") network extension between the first cloud 610 and the second cloud 660.

The secure transport layer (L4) tunnel (e.g., transport layer security (TLS), datagram TLS (DTLS), secure socket layer (SSL), etc.) can provide a secure L2 switch overlay that interconnects cloud resources (e.g., second cloud 660) with other clouds, networks or datacenters (e.g., first cloud 610, enterprise networks or datacenters, etc.). In other words, the secure transport layer tunnel can provide a link layer network extension between the first cloud 610 and the second cloud 660.

Cloud gateway 612 at the first cloud 610 can use the communication link 670 to connect to cloud resources allocated at the second cloud 660, and vice versa. The link 670 can be used with corporate or private firewalls and NAT devices due to the nature of the transport level protocols (e.g., UDP/TCP) and the transport layer ports opened for HTTP/HTTPS in the firewall, for example. Underlying L2 networks can be further extended and connected to each of the cloud VMs through the cloud gateways 612 and 662. Cloud service providers can offer a number of network attachments for each of the cloud VMs and resources, such as networking or data processing capabilities. Cloud service providers can provide one or more types of services, such as software as a service, infrastructure as a service, platform as a service, backend as a service, desktop as a service, or information technology management as a service.

As described above, the techniques herein can allow customers to deploy network architectures and interconnections between clouds or networks. As one of ordinary skill in the art will readily recognize, the interconnection model 600 can include other architectures, networks, carriers, providers, components, resources, links, devices, or clouds. Indeed, interconnection model 600 is provided as a non-limiting example for simplicity and explanation purposes.

Figure 7 illustrates an example configuration of a remote network or fabric 672 for provisioning services and interconnecting networks. Fabric 672 can include switches 700 and 702 configured according to a specific topology, such as spine-leaf or folded CLOS, for communicating within the fabric 672.

In an embodiment, switches 700 and 702 serve as the underlay of the network.

Moreover, switches 700 and 702 can interface with one or more devices 704, such as servers, VMs, controllers, and so forth.

Fabric 672 can also include a gateway 706, which can serve as an ingress/egress router for connecting the fabric 672 with other networks, devices, or clouds. Fabric 672 can also include capabilities for establishing virtual circuits, links, or tunnels to other networks, and managing or routing traffic to and from other networks.

Figure 8 illustrates a second example configuration of a fabric 672 for provisioning services and interconnecting networks. Fabric 672 can include multiple networks or datacenters 800, 802, 804. The networks or datacenters 800, 802, 804 can be interconnected within the fabric 672 via respective routers 810, 812, 814.

One or more of the respective routers 810, 812, 814 can also connect the networks or datacenters 800, 802, 804 to other networks or devices outside of the fabric 672. This way, the networks or datacenters 800, 802, 804 can communicate with other networks and devices outside of the fabric 672. Embodiments disclosed above have application to one or more of the following use cases:

1. Customer does not have the equipment/ experience to run BGP. The virtual router will perform the BGP function and customer can use static routes to reach cloud providers. Customer would order 1 Megaport, 1 virtual router, 2 VXCs (one between the port and virtual router, and one to their cloud provider).

2. Customer has many cloud connections. They can aggregate them on a virtual router and need only configure one VXC and BGP session on their equipment.

3. Customer doesn't have access to a public ASN or public IP addresses but wishes to have a VXC to public cloud. The customer is provided with IP addresses. A virtual router will perform NAT.

4. Customer is distant from the Cloud onramp location but wishes to have local routing. They could create a virtual router in the same metro as the cloud onramps, and have just one VXC back to their remote location.

5. Customer has infrastucture in multiple clouds or cloud regions, and wishes to directly route between them. Virtual router can be located in many different locations and route between cloud regions or providers. No physical port is required.

6. Customer or service provider accepts inbound VXCs, but doesn't wish to manually configure their equipment for every new connection.

Some embodiments disclosed above provide a gateway or interconnection to multiple private or public networks, cloud service providers, internet service providers, among other networks or services.

Examples of cloud service providers and cloud networks include AWS® from

Amazon.com®, Inc. of Seattle, WA., Azure® from Microsoft® Corp. of Redmond, WA., and Google Cloud Platform® from Google® Inc. of Mountain View, CA.

The gateway or interconnection may allow a user to access or interconnect one or more cloud providers through a web site, a command-line interface, a computing application (for example, a mobile computing device application), an API, or other control interface. The setup can be automated through the control interface with minimal manual configuration. Embodiments disclosed above have the potential to remove the need for a user to purchase his/her own hardware, software, and other resources for implementing a network, such as servers, routers, switches, firewalls, deep packet inspectors, traffic monitors, load balancers, wide area network (WAN) optimizers, security appliances, domain name system (DNS), and other network resources.

Embodiments disclosed above have the potential to eliminate manual configuration of the user's network to connect to other networks, clouds, or providers. For instance, a user may wish to utilize services of multiple cloud service providers based on

considerations such as cost, geographic proximity, high availability, load balancing, and data replication, among other factors.

The foregoing description of the invention includes preferred forms thereof. Modifications may be made thereto without departing from the scope of the invention, as defined by the accompanying claims.