Embedded Files
Cisco Project: Recipient of CEO Innovation Fund
Videos:
Main Concept Introduction:
Seamless Cloud Concept Introduction
5 Minute demo video: Running Distributed Media App (Video Streaming) over a Seamless Cloud Instance:
How a Seamless Cloud Instance is mapped over Multi-AS MPLS VPN Network and Multi-site Openstack Clouds:
Detailed description of Seamless Virtual Cloud Engine for Hybrid/Multi-Clouds
Problem
Enterprises with multiple geographically distributed branches or sites face the challenge of extending their intranet sites or DCs or private Cloud sites or DCs to one or more public Clouds, which itself may have multiple geographically distributed Cloud DCs. Enterprises typically connect their intranet sites and DCs using connectivity and VPN services offered by network service providers (NSP). The VPN service can be based on L2/L3 MPLS VPN service or site-to-site IPSEC VPN service. If the NSPs also provide public Cloud services, enterprises may want to use the same VPN service to securely extend their intranet or private Clouds to the NSP offered public Clouds. In addition, they should be able to use the NSP public Clouds and other public Clouds (such as AWS, Azure, Google) simultaneously. The challenge is how an enterprise extends into multiple public Clouds seamlessly, securely and in a simple way without being exposed to the complexities of the underlying networking and Cloud infrastructures.
Solution
To address the problem a programmable Cloud networking and SDN framework called the Seamless Virtual Cloud framework was developed. This framework allowed an enterprise (Cloud tenant) extend its geographically distributed intranet or private Cloud sites into multiple public Clouds with just a few clicks or a few API calls. The framework consisted of following: 1) a Cloud abstraction layer consisting of tenant facing API for multi-Cloud extension and 3D graph abstraction of the API, 2) a programmable Cloud networking and SDN controller or engine located in enterprise sites, 3) a programmable Cloud networking and SDN controller or engine located in public Cloud sites. The latter two can be packaged in a VM or container.
Cloud Abstraction and API
A tenant admin or a developer (user, in short) CRUD (create, read, update, delete) a geographically distributed virtual Cloud that appears to the tenant as one seamless Cloud even though its sites and resources are distributed widely over multiple Clouds and networks. A user can CRUD a seamless Cloud (SCL) elastically by expanding or shrinking it on-demand or based on conditions. The figures below show that the user has created two segments of an SCL, one by extending into the public Cloud of CSP1 (Cloud Service Provider 1) and another into that of CSP2. A user can CRUD as many instances as it wants. For example, each dedicated to a particular function, such as one for finance department and one for engineering, or one for Hadoop distributed application and one for distributed multimedia streaming.
Each instance of an SCL is totally isolated from another instance and from the outside world. In addition, resources within an SCL cannot reach the outside. The isolation is end-to-end, that is, from on-premises resources (such as a VM) to the host server to the TOR switch to the DC network to the MAN/WAN to the off-premises DC to the TOR switch to the server to the resources and vice versa.
The 3D graph visualization of one segment of an SCL instance created by a tenant T1 is shown below. This segment is rooted at an object (shown as yellow sphere) called the SeamlessClouds, which is labelled as SCL_T1_CSP1. The root object labelled as Meta-SCL in the graph can be used to create other segments (see below). T1 has created this segment with public Cloud provider CSP1:
As shown below the tenant T1 created another segment of the SCL with another CSP CSP2 and connected with a simple IsolationWAN API call (corresponding to the cylinder abstraction labelled as Bridge_T1 in the graph). If the user uses the 3D graph UI, the extension is done by a few mouse clicks.
The REST API corresponding to the IsolationWAN abstraction, which extends seamlessly and securely a set of Cloud or DC or branch sites into another set, is shown below.
The objects or API elements in the SCL abstraction are abstract, where some of the objects correspond to real-world objects. For example, a Resource object corresponds to a host or a VM. A Site object corresponds to a physical site and in the network topology to a set of customer edge (CE) and provider edge (PE) routers. The IsolationOnPremises or IsolationOffPremises may correspond to a VLAN or VxLAN and the IsolationWAN to a multipoint to multipoint MPLS VPN or a set of site-to-site IPSEC tunnels. When a Resource or Site object is deleted, the real object still remains there, but it will no longer be reachable from within the SCL instance from which it is deleted. It is also possible to delete an edge with the same effect. Deletion of an edge is performed by updating an existing object. For example, in the above API a user can remove the entry OnPremiseSite, id: b759… to make that site unreachable from within the SCL and vice versa. In general, the Isolation abstraction makes one subgraph or segment of an SCL instance reachable seamlessly and securely from another subgraph.
Seamless Cloud Engine
The functional architecture of the Seamless Cloud Engine or controller is shown below. Each organization offering the Seamless Cloud service deploys the SCL engine on its premises. A tenant CRUD an SCL instance on its engine, which then interacts with the other engines to CRUD the SCL segment in respective Cloud. The Clouds that offer the SCL service are advertised to the tenant via the SCL engine on the tenant premises.
The SCL engine has two major components: 1) SCL graph control module that receives the REST API requests and CRUD the SCL graph or subgraph, 2) Infrastructure Programmer Module that maps the graph or API to the underlying infrastructure by programming the virtual and physical networking infrastructure end-to-end. Each SCL engine manages its segment of the SCL subgraph. For example, if the Cloud controller is Openstack, then respective Neutron API is used to program the Openstack virtual networking for the resources (VM). The physical networking infrastructure is programmed via SDN interfaces, such as OpenFlow or NetConf or CLI.
Mapping of SCL Graph to Infrastructure
A tenant only sees the virtual SCL graph. It does not see the complexities of the underlying infrastructure. As mentioned above, and SCL engine maps an SCL graph or the relevant API to a virtual network end-to-end (E2E). An example of an end-to-end virtual network is shown below. It shows two tenants has CRUD its own SCL instance. There are multiple segments of the E2E virtual network that are stitched together. The E2E virtual network provides full isolation and security to the SCL instance, which as we mentioned above does not allow reachability of SCL resources from within the SCL to the outside network and vice versa.
Mapping of SCL Graph to E2E Virtual Network
We will explain CRUD of the virtual network via following example.
Assume tenant T1 is CRUDing an SCL instance. Assume that Server 1-T1 of T1 Site 1 (CA), Server 2-T1 of CSP1 DC1 (CA) and Server 3-T1 of CSP1 DC2 (NY) is already included in the SCL instance SCL1. A this point the virtual network that allows reachabilities between these resources and sites has already been created. Assume now that the tenant is adding the Clients in T1 Site 4 (NY) to the SCL1. In this case the virtual network segments marked in the figure above as 1 through 7 will be created as follows. As mentioned above that each engine controlling a segment programs the infrastructure to create its portion of the virtual network segment.
If the Cloud controller (in the tenant network segment) is Openstack and the resources are VM, then the virtual network segment inside Openstack controlled compute host is CRUD via the Neutron API. Let us call this virtual network segment VM virtual network or VMVN. The VMVN can be assigned a VLAN or VxLAN or mapped to a GRE tunnel. This segment spans up to the TOR switches. A tenant makes an SCL API call to attach the client VMs to in T1 Site 4 (NY) the SCL1. As a result the SCL engine in the tenant premises will create a VMVN using Neutron API calls, which is shown below.
A virtual network segment then is carried over the DC/campus network to the customer edge router (CE), which we call the DCVN. This segment can be realized in a number of ways, including GRE tunnel and mapping VMVN VLAN or VxLAN to the tunnel or hop-by-hop VLAN and VRF-lite mapping. We will show the latter option via CLI (note that CLI is for explanation purpose only, other methods can be used).
Refer to figure: programming the virtual network segment on SW1-CE1 (for simplicity we assume direct connectivity here): Assume SW1-CE1 is a routed interface and VLAN or sub-interface 101 is used for VMVN VLAN.
interface GigabitEthernet1/1.101
Description Traffic to CE1 SCL1_T1 VRF-lite
encapsulation dot1Q 101
ip vrf forwarding SCL1_T1
ip address <ip address> <mask>
On CE1:
interface GigabitEthernet2/1.101
Description Traffic to SW1 SCL1_T1 VRF-lite
encapsulation dot1Q 101
ip vrf forwarding SCL1_T1
ip address <ip address> <mask>
Virtualization of Routing:
router ospf 1 vrf SCL1_T1
network <net prefix> <mask> area 0
router-id <ip address>
or
address-family ipv4 vrf SCL1_T1
network <net prefix>
no auto-summary
autonomous-system 100
eigrp router-id <ip address>
exit-address-family
The virtual network segment (MWVN) over the MAN or WAN is provided via multipoint to multipoint (M2M) MPLS VPN (CE-PE to CE-PE) or site-to-site (CE to CE) IPSEC tunnels. Following is a simplified outline of how this segment is created with MPLS L3 M2M VPN. We do not show the full configuration or programming of the CE-PE routers that includes routing and MPBGP programming.
In the example above, only the prefix T1-Prfx-1 is allowed into the SCL virtual network. Hence “route map” filtering is used. Otherwise all routing information may be exchanged.
On PE1:
ip vrf SCL1_T1
rd 65000:0
! Only IP address prefix of VN T1-Prfx-1 is exported
export map T1Prfx1Map
! Import the routes of other sites (T1-Prfx-2/3/4)
route-target import 65000:2
route-target import 65000:3
route-target import 65000:4
! Only IP address prefix of VN T1-Prfx-1 is
! permitted into the route exchange
ip prefix-list p1 seq 5 permit <T1-Prfx-1 IP prefix>
! The prefix will be sent by the MP-BGP protocol with
! RT of 65000:1 as indicated by the set extcommunity
! Not shown here: The PE2/3/4 will import RT 65000:1
! The SCL engine Infrea controller keeps track of
! which other sites or resources are part of the SCL1
! already; it then identifies PE of those sites and
! program those PEs to import this RT 65000:1
route-map T1Prfx1Map permit 10
match ip address prefix-list p1
set extcommunity rt 65000:1
interface GigabitEthernet2/1.101
Description Traffic to PE1 SCL1_T1 VRF-lite
encapsulation dot1Q 101
ip vrf forwarding SCL1_T1
ip address <ip address> <mask>
Each segment of the SCL virtual network is controlled by the SCL engine controlling that segment. In the above figure we assumed that a CSP controls its MAN/WAN segment and its public Cloud DCs.
Following figures shows that MPLS L3 VPN routes and BGP updates are elastically growing or shrinking as user CRUD different section of an SCL instance. Note, above CLIs are for illustration only. But following is from real execution of SCL engines.
Mapping to IPSEC Tunnels with IPSEC Gateway VNF and Virtualized Seamless Cloud Engines
Seamless Cloud engines on a physical host in a DC, but can also be packaged in a VM or Container and run in a Cloud. The SCL engine can work with both physical routers and switches and virtualized versions of them. The latter is known as VNF (virtual network function). The engine can dynamically or elastically launch VNF and then program them to create E2E virtual network for an SCL instance.
Following figures show launching of an IPSEC gateway VNF (CSR) when an SCL abstract site is created via the respective SCL API. A crypto-map IPSEC tunnel is created when IsolationWAN API is invoked. The traffic between VMs then flow through this tunnel only.
VNF launched on-demand after SCL API call.
Resource (VM) traffic now flows through IPSEC tunnel only.
Sites and resources of SCL1 in Texas DC and Amsterdam DC (of Cisco Cloud) are now reachable to each other and isolated via site-site IPSEC tunnels.
Examples of Use cases
Distributed Multimedia Streaming over a Seamless Cloud Instance over Multiple Clouds
See the video of demo above.
Distributed Hadoop Application Execution over a Seamless Cloud Instance over Multiple Clouds
An enterprise may have huge amount of data to be processed. But segments of data may be geographically distributed. Moving this data around to a central site and processing them may not be scalable or cost-effective. It may take long time to move the data and huge bandwidth consumption has to be paid. The Hadoop processing model consisting of Map and reduce does not require moving the segments of data around. Rather Map execution can be performed locally and then aggregated and reduced size data can be moved in the Reduce phases. The SCL framework also allows creation of section of an SCL instance on condition based on rules (see the enableOnCondition element in the API example above). For example, an IsolationWAN API can be invoked based on condition, such as when Hadoop Reduce phases starts.
Virtualized Distributed DC Tiers over a Seamless Cloud Instance over Multiple Clouds
A typical physical DC Tier topology looks something like the following:
A tenant can CRUD elastically a virtualized instance of the DC tier over an instance of an SCL over multiple Clouds as shown below.
Google Sites
Report abuse