The Impact of SDN On MPLS Networks Adrian Farrel Juniper Networks

Agenda Some Definitions Needed (SDN) Why consider SDN? SDN as a toolkit Fine-grain programming An interface to routing and policy Enabling services A programmable MPLS network 2

What do we mean by SDN? Software It’s all software! We are looking for automation Tools or applications Driven or Defined Does it matter? Networks Micro-management of forwarding decisions Control of end-to-end paths Whole-sale operation of network Is it all about the buzz? S hiny-thing D esparately N eeded $ ome D ollars N ow 3

What will we do with SDN? Make our networks better Provide cool services at lower prices Reduce OPEX and simplify network operations Enable better monitoring and diagnostics Make better use of deployed resources Converged services are the future Converged infrastructure is the future 4

The SDN Toolbox To a network, all configuration tools look like hammers One size does not fit all SDN is about engineering the routers to allow better tools to be designed and applied 5

MPLS Data Plane Programmability Label stacking, popping, and swapping MPLS as a cross-connect technology (NHFLE) Prefix-to-label mapping (LFIB) Integration with underlying data plane Encapsulation rules Data link addresses 6 IP Packet Prefix LFIB Out i/f, label MPLS Packet In i/f, label NHFLE Out i/f, label In i/f, label NHFLE Pop

Applications and Protocols for MPLS Data Plane Programmability An application is software that runs remotely That demands a protocol and a data encoding Element Management IETF : SNMP/MIBs, Netconf/YANG Proprietary : CLI, GUI, XML Legacy : TL1 … Network Management Coordinated connection set-up is just coordinated element management Control plane / data plane separation Use an existing configuration protocol IETF : GSMP (RFC 3292), ForCES (RFC 5810) ONF : OpenFlow 7

Control Plane / Data Plane Separation Support legacy / cheap devices Experiment with new routing protocols Integrate dynamic routing with static control Avoid “complexities” of routing protocols 8 Data plane Control plane SDN Programming Language

Functional Control at a Higher Level Operators want to build and deploy services “Make a pseudowire for me” “Optimize my traffic loading” “Provision a layer 3 VPN” “Show me how my network is being used” “Configure my data center” “Manage security and policy” “Provide service callendaring” Needs a higher-level interaction with the network Demands more sophisticated control of routers Must integrate with standard routing features 9

Leveraging Existing Tools New services and features for rapid deployment There are plenty of existing tools Leverage implemented and deployed protocols We can put them together to enable high function SDN in MPLS networks May need some extensions Avoid long development cycles 10

BGP-LS to Extract Topology Information Information about the network Nodes and links Link state Up-to-date TE capabilities Delay and other quality information Status of existing LSPs / tunnels Used for network monitoring, analysis, and planning Critical input to path computation (e.g., via PCE) Fundamental component unspecified in the PCE architecture BGP-LS is a set of simple extensions to BGP Client is any node listening to the IGP For example an ASBR or a Route Reflector Server can not be a very light-weight BGP implementation Reduces dependency on IGP sniffing 11

Stateful PCE for Control of Services Early work on PCE was stateless PCE knows state of network PCE does not recall anything about previous computations PCE does not know about existing provisioned services Except as described on new computation requests Stateful PCE was always in the architecture Retain information about provisioned LSPs New extensions to PCEP Allow explicit activation of LSPs from the PCE Receive information from network about LSPs Provides key components for bandwidth callendaring 12

Integrating the Components 13 IGP enhanced for TE and link quality BGP-LS reports to PCE PCE requests LSPs Normal LSP signaling LSP status reports PCE

Making New Tools Can’t do everything with what have already Interface to the Routing System (IRS) A programmatic interface to routers 14 Data Plane FIB RIBs and RIB Manager Policy DB Routing and Signaling Protocols Topology DB OAM, Events and Measurement IRS Agent IRS Client Router Server Application IRS Protocol & Data Encoding

Enabling Services Service enablement and turn-up is complex Existing tools help with planning Commissioning through scripts or work-plans SDN can be a set of tools to enable services L3VPN delivery Data center interconnect Bandwidth callendaring Mult-layer connectivity and virtual links 15

Service Example : Multi-layer SDN can coordinate multiple network layers May both be MPLS networks Involves many SDN components 16 PCE Traffic demand Service request VNTM TEDB PCE BGP-LS IRS PCEP RSVP-TE GMPLS IGP-TE IRS OpenFlow & IRS Virtual Link PCEP TEDB IRS Policy IGP-TE

Service Example : L3VPN with Callendaring Which PEs to use? How to connect PEs? What load? When? What redundancy? QoS? Security? How to connect to the Internet? Planned support for high bandwidth services 17 DB Replication Content Streaming Data Transfer

Putting the Tools into the Box SDN will possibly remain buzz and hype Or maybe it will evolve into bickering between proponents of different solutions Or it could become a comprehensive set of tools Configuration tools RIB and policy control Topology and LSP management Service enablement Potential to enable a rich set of functions in future MPLS networks 18

SDN - Pandora’s Toolbox? A mess of overlapping tools and protocols with too many features and functions? 19 Or a cornucopia of riches?

Questions? 20