Transcript Slides - IEEE CloudNet 2013

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 WAN
SDN 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
• 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.
• Egress PE strips the added MPLS label and L2 head and change the
FCS field back
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!
谢谢
谢谢