SWAN: End-to-End Orchestration

of Cloud Network and WAN

Haiyang Qian*, Xin Huang§, Clark Chen*

*China Mobile USA Research Center, §Cyan Inc.

Network Virtualization

• Network Virtualization or multi-tenancy

– Multiple isolated virtual networks coexist on the same network

infrastructure.

– Each tenant network or virtual network (VN) could dynamically

configure its own security policy, virtual address space, and

bandwidth/QoS.

• SDN is the most popular choice for implementing Network

Virtualization

– Centralized control

– Network programmability

– Cost-effective solution for scale out

– Optimized TE, resource utilization, and energy saving,

– Reducing CAPEX and OPEX

– And more …

Network Virtualization in WAN

• But.. existing publicly available network virtualization solutions are

limited to within a Data Center.

• For cloud service, VNs usually span multiple geographically

distributed DCs

– Cloud services and applications are deployed across DCs

– Hybrid cloud: private DCs + public DCs

– VM Migration across WAN to offer better user experience

– And more …

• SDN based network virtualization in WAN is critical extension to

DC network virtualization

End-to-End Orchestration

• But.. DCs and WAN are usually managed separately, by different

organizations or operation teams

• End-to-end network orchestration

– Dynamic control on initiating, maintaining, tearing down VNs (Virtual Networks)

across multiple DCs and coordinating per-service(application) bandwidth and

QoS.

• End-to-End Orchestration for cloud service is a desirable feature

for both service providers and customers (tenants)

Proposed System

• SWAN

– An End-to-End Orchestration System for cloud service.

– Providing unified management for cloud resources,

including computing, storage, and networking.

– Managing both DCs and WAN

– Setting up VNs across DCs/WAN

– Mapping the right bandwidth and QoS across DCs/WAN.

SWAN: Architecture

DC Controller• OpenStack to orchestrate cloud• Quantum manages VNs via SDN controller• SDN controller controllers either OVS (overlay

model) or switches (underlay model) or both (hybrid model)

WAN Controller• Dynamic bandwidth

allocation• Path computation• TE

WAN and DC Controller together• Cross DC VN• QoS consistency of DC and WANSDN applications includes VME, QME, PCE, TES

The life of a frame in L2 MPLS VPN

• Ingress PE adds MPLS label (Tunnel and VC Label) and a new L2 head and change the FCS field for the DC-to-WAN frame

• Tunnel Label is used to establish tunnels between PE pairs while the VC Label is used to identify which CE router to switch to

• Egress PE strips the added MPLS label and L2 head and change the FCS field back

• For traffic from DC to WAN, the OF switch matches on ingress port, Dst MAC, Dst IPv4/v6, EtherType (0x08000 for IPv4), VLAN Tag and takes following actions: pop VLAN tag, push MPLS label, set MPLS TTL, rewrite dest. MAC and sour. Mac, subtract 2 IP TTL and output packet to output port.

• For the traffic from the WAN to the DC, the OF switch matches on Ingress Port, Dst MAC, Dst IPv4/IPv6, EtherType (0x8847 for MPLS), MPLS label and takes following actions: pop MPLS label, push VLAN tag, subtract 1 from IP TTL, rewrite Dst MAC and Src MAC, output packet to output port.

Virtual Networking across Multiple DC

• VLAN tag must be either globally used or mapped via centralized controller.

• Implemented in Virtual Network Data Based (VNDB) on top of SDN controller

• Global Identifier: whenever the DC SDN controller create a new VN with a VLAN tag, the VLAN tag must be registered in the VNDB and WAN controller distributes this information to all DC controllers and cloud orchestrators in other DCs.

• Local Identifier: let each DC use VLAN tag independently and maintain a VLAN tag mapping information in the system. When the VMs belonging to the same VN while residing in different DC communicate with each other, the PE router needs to rewrite the VLAN tag in source DC to the VLAN tag in destination DC according to the VLAN tag mapping information in VNDB.

Global identifier requires coordination when creating a new VN while local identifier amortizes this overhead to every traffic flow from one DC to another.

Proof of Concept (POC)

Proof of Concept (cont.)

• Three VNs belonging to three different enterprises across

two DCs

• Each enterprise is allocated certain amount of bandwidth

according to the SLA in the MPLS domain

• Each enterprise has up to three types of traffic (priorities)

• We verify that

– The VN can go across multiple DCs and VMs can be migrated across DCs

– The QoS for applications in DC can be mapped to appropriate QoS in

MPLS WAN

– The WAN bandwidth allocation is dynamically recofigurable

Conclusion and Future Work

• Introduce our design to achieve end-to-end orchestration for cloud service

• Present our architecture of providing virtual networking service across

multiple DCs interconnected by MPLS-WAN

• SDN is the core of our design

– DC controller to manage the virtual cloud and steer traffic within DC

– WAN controller and in-hour developed applications provide a global view of virtual networks

across multiple DCs

• Build a PoC to prove the feasibility of the design

• Future work

– Using other identifier technologies, such as VXLAN, GRE Tunneling, etc.

– Implement a network of LSRs between PE routers to mimic a more realistic MPLS WAN

– Add MPLS signaling and routing system

– Design and implement proposed TE

– Benchmark WAN link utilization

谢 谢谢 谢Thank you!