Data Center Network Virtualisation Standards. Matthew Bocci, Director of Technology & Standards, IP Division IETF NVO3 Co-chair

Transcription

1

2 Data Center Network Virtualisation Standards Matthew Bocci, Director of Technology & Standards, IP Division IETF NVO3 Co-chair May 2013

3 AGENDA 1. Why standardise? 2. Problem Statement and Architecture 3. What is the IETF doing? 4. Potential solutions 3

4 Data Center Services OVERVIEW Internet Cloud Services Enterprise Cloud Services Internal Cloud services IP/MPLS VPN WDM Internet Multi-tenancy has become a core requirement, especially in the context of data centers supporting virtualized hosts (VMs) DCBR CORE TOR Blade servers Rack mount servers Storage 4

5 Data Center Infrastructure Options Profusion of options to meet multi-tenancy requirement VPLS, PBB-VPLS TRILL OTV LISP IP/MPLS VPN WDM Internet E-VPN DCBR PBB E-VPN IP-VPN Need for a standardised set of solutions CORE Meet multi-tenancy at scale requirements Fit in data center environment TOR Blade servers Rack mount servers Storage 5

6 Key Data Center Facts DCs largely based of software networking components (vswitches) in server hypervisors An order of magnitude more than physical network nodes Limited resources available for software networking Service automation is a key component Support of OpenFlow in most hypervisors Network virtualization edge function often co-located with Tenant Systems Hypervisor, vswitches But these cannot be burdened with complex routing protocols 6

7 How is IETF Approaching Problem? The IETF is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. It is the principal body engaged in the development of new Internet standard specifications. *! Network Virtualization Overlays (NVO3) working group Charter: Consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs). NVO3 solution is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. Will define a problem statement, applicability and architectural framework for DC VPNs *From the Tao of the IETF 7

8 Key Requirements from NVO3 Charter 1. Traffic isolation, so that a tenant's traffic is not visible to any other tenant 2. Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. 3. Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. 8

9 Problems with current DC networks draft-ietf-nvo3-problem-statement-03 Need for Dynamic Provisioning Virtual Machine Mobility Limitations Inadequate Forwarding table Sizes Decoupling of logical and physical infrastructure Need for address separation between virtual networks Need for address separation between virtual networks and infrastructure Optimal forwarding between DC VPNs in different sub-nets 9

10 IETF NVO3: Framework draft-ietf-nvo3-framework-02 DC L3 Underlay Network Utilize L3 networking to interconnect NVEs non-nvo3 domains Network Virtualization Edge NVE GW NVE GW NVA (controller) Network Virtualization Edge (NVE) Handle L2/L3 service instances Hide tenant addressing information Map tenant traffic into tunnel Perform NVO3 tunnel encapsulation Network Virtualization Edge DC L3 Underlay NVE NVE NVE Tenant Systems Physical or virtual system that can play the role of a host, or a forwarding element (eg router, switch) Examples: VMs, Bare Metal servers, Networks Appliances (Firewall, DPI) Tenant Systems Network Virtualization Authority (NVA) Centralized controller maintaining global view of network state Assits with orchestration Example: SDN controller 10

11 IETF NVO3: NVE Architecture non-nvo3 domains NVE GW NVE GW Overlay Modules Provide tunneling capabilities Encode context ID in tunnel header Can use any encapsulation option VXLAN, NVGRE, L2TP, IPSec DC L3 Underlay NVE Overlay Module Context ID NVE Overlay Module Context ID VNI VNI VNI VNI VAPs VAPs Virtual Network Instance (VNI) Represents tenant specific configuration Identified by a context ID (e.g. VNID) Per-tenant L2 or L3 FIBs Virtual Access Point (VAP) Attach tenant systems to VNIs Physical or virtual ports Tenant Systems 11

12 IETF NVO3: Solution Discussion NVO3 will not standardize solutions yet Some candidate solutions have been discussed, e.g.: 1. MPLS/BGP Layer 3 and Layer 2 VPNs 2. Pure SDN approaches SDN controller with VXLAN/NVGRE data plane 3. Hybrid approaches: SDN Federation (SDN controller, soft NVEs with data plane only, BGP VPN for inter-controller communications) 12

13 IETF NVO3: Next Steps Demostrate solution applicability to the architecture and requirements via a Gap Analysis Some key questions: Applicability of MPLS control and data plane Distributed vs. centralised control Choice of southbound API: e.g. OpenFlow vs. XMPP 13

14

15

16