Extending MPLS/BGP VPNs to End-Systems

1. Extending MPLS/BGP VPNs to End-Systems Maria Napierala AT&T Labs DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

2. Motivation for Virtualization and SDN • Service Providers want to deploy network and service appliances on server COTS hardware • Reduce CAPEX, OPEX, introduce vendor neutrality, and innovation. • Service Providers want to share network, storage, and compute resources across different services and applications, and across different customers • Treat application, service, customer as a “tenant” of a common infrastructure. • Enable access-control, isolation, multi-tenancy, IP mobility. • Realized by “virtual networks”. • Standard operational practice: simple core, services at the edge. Core should not have virtual network state. DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

3. MPLS/BGP VPNs • MPLS/BGP IP VPNs [RFC4364] is the industry de-facto standard for IP-based virtual networks • Provides constructs for: • Policy-based concept of a VPN. • A virtual interface may communicate with multiple VPNs (extra-net). • Proven scale: 1M+ route deployments are common. • Deployed Inter-AS support. • Optimal route distribution (BGP rt-constraint). • Support for multicast. • Support for traffic filtering (BGP flow-spec). • MPLS/BGP VPN control plane is encapsulation agnostic. DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

4. End-System MPLS/BGP VPNs • There is a need to extend MPLS/BGP VPNs to end-systems and associate virtual resources (Virtual Machines, applications, service appliances) with VPNs. • There is a requirement to decouple “provider edge” (PE) control function from PE forwarding function • Software complexity of PE control function can run on a generic computing machine. • PE forwarding function can be implemented in software and run on multiple industry standard devices, such as operating systems of application servers or network appliances. • Allows the PE control plane function to run on a generic computing machine to be itself virtualized and run as an application in end-system. • Standards based protocol (XMPP) for delegating PE forwarding functionality. End-System is a computer or a server that sits at the edge of a network. DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

5. End-System CE and PE Functions “Controller” is a network of routers Router-based PE • Highest level of abstraction is desired, not to constrain implementations. • Extensibility (XML documents). End-System PE PE PE Control Plane PE Control Plane BGP Open = XMPP proprietary CE Line Card control Hypervisor/ Host OS agent CE App/VM forwarding forwarding • CE is a non-routing host that resides in a Virtual Machine or Server. • PE forwarding function is on a hypervisor switch or network appliance. • PE control plane function on generic computing machine delegates PE forwarding via a standard protocol (XMPP). • Scale: End-system PE can control 1000’s of CE interfaces. • CE is a physical device external to PE. • CE and PE are routing peers. • PE device implements both L3VPN control and forwarding functions. DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

6. Summary • Standards based L3VPN technology is the right building block for network virtualization services • draft-ietf-l3vpn-end-system-00 • draft-marques-sdnp-flow-spec-00 DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

7. Backup DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University

8. XMPP • Extensibility: XML documents. • Publish-subscribe • Route updates can be initiated from Control Plane software. • Events/Stats can be published from the Hypervisor Switch (aka line-card). • Protocol commonly deployed in end-systems. DIMACS - SDN Workshop, Dec 3-4 2012, Rutgers University