Interface to the Routing System

1. Interface to the Routing System Adrian Farrel adrian@olddog.co.uk afarrel@juniper.net

2. Agenda • What is the Routing System? • What do we want to do with the Routing System? • What tools already exist? • An architecture for IRS • Requirements for IRS • IRS Work to be done • Integratingthe toolkit

3. The Routing System • The forwarding plane is just part of a router • We are interested in larger granularity impact Router Topology DB OAM, Events Measurement Config Config DB RIB Routing and Signalling RIB Manager Policy DB Data Plane FIB OpenFlow 3

4. Advanced SDN Use Cases • Programming the Routing Information Base • For example, adding static routes • Setting routing policy • Control how the FIB is built • Other router policies • Modify BGP import/export policies • Topology extraction • Pull routing information (including SRLGs) from network • Topology management • Create virtual links by making connections in lower layers • Service management • Request LSPs, connections, pseudowires • Bandwidth scheduling • “Set up a VPN”

5. Existing SDN Tools - OpenFlow • Useful, programmatic remote API • Initially targeted at data / forwarding plane • Separation of control plane from data plane • RAPI nature introduces extensibility issues • New revisions not backward compatible • Hard to add new data models • Current version has some concerns • Synchronous completion is assumed • No support for bidirectional flow • Security model is not complete • Use needs coordination • A routing protocol • An orchestrator

6. Existing Tools - ForCES • IETF protocol and encoding language • An open standard • Separation of control and forwarding planes • Originally developed to support COTS • Standard, but in-box protocol • Use rapidly extended to out-of-box • Has been used to model OpenFlow • Provides the same level of function • Use needs coordination • A routing protocol • An orchestrator

7. Existing Tools - Config • All routers have configuration interfaces • Command Line Interface • Non-standard • Varies from one product release to the next • Easy to script • Hard to parse output ("screen scraping") • All config approaches tend to be batched • Enter many config commands • Verify the config • Commit • So config is slow and complicated

8. Existing Tools - Netconf / YANG • IETF standardisedprotocol andencoding language • Netconf • Next generation configuration protocol • Lessons learnt from SNMP • Reduced "chattines" of protocol • Multiple objects set at once • Security is far simpler • YANG • XML-like encoding language • Easy to define new data models • Not yet widely adopted • Usage currently has many of the disadvantages of config

9. Existing Tools - PCE • Initially conceived as a path computation server • Solving the problem of inter-AS MPLS-TE • Stateless computation • Uses Traffic Engineering Database • Extended for stateful computation • Recalls information about previous computations • Learns state of provisioning from network • New extensions for "Active PCE" • PCE can issue provisioning commands • Enables new services • Topology creation • Scheduled services • Dynamic re-optimisation and grooming

10. Existing Tools - BGP-LS • How does a PCE obtain the TED? • Unspecified in the architecture • Early implementations participate in IGP • Updates may be too frequent • Implementations must support IS-IS and OSPF • Most TE networks have a BGP-capable router • BGP nodes are designed to process routing policies • BGP-LS is set of simple extensions to advertise topology info • Speaker • Possibly a Route Reflector • Uses policy to determine what to advertise and when • Consumer (i.e. PCE) • Very lightweight BGP implementation • Not drowned by network updates

11. Existing Tools - VNTM • Virtual link is tunnel provided by link in lower layer (e.g., virtual MPLS-TE link made by optical circuit) • Virtual topology is nodes, links, and virtual links • Virtual Network Topology Manager • An architectural component • Responsible for coordinating between layers • Integrates between PCEs at different layers • Applies policies to create “on-demand” topology

12. Additional SDN Function Network Application • Applications need to dynamically: • Augment routing, based on: • Policy • Flow and application awareness • Time and external changes • With knowledge of: • Topology (active & potential) • Network events • Traffic measurement • Etc. Feedback Loop: Control & Information

13. New Tools – Interface to the Routing System • Data models for routing and signaling state • RIB Layer: unicast RIBs, multicast RIBs, MPLS LFIB, etc. • Protocols: ISIS, OSPF, BGP, RSVP-TE, LDP, PIM, mLDP, etc. • Related Function: policy-based routing, QoS, OAM, security, etc. • Framework for integrating external data into routing • Indirection, policy, loop-detection • Filtered events for triggers, verification, and learning about changes to router state • Data models for state • Topology model, interface, measurements, etc. • Device-level and network-level interfaces and protocols

14. The IRS Architecture Application Application Application Server IRS Client IRS Protocol & Data Encoding IRS Client Router OAM, Events and Measurement Topology DB IRS Agent Routing and Signaling Protocols RIBs and RIB Manager Policy DB Data Plane FIB

15. IRS Requirements • Programmability • Easy to write an API • Stateless communications (RESTful) • Reduced session state • No state retention between messages • High throughput and highly responsive • Does not require configuration to be reprocessed • Multiple simultaneous asynchronous operations • Multi-channel (readers/writers) • Duplex communication • Asynchronous, filtered events • Topology information (IGP, BGP, VPN, active/potential) • Easy encoding of data • Parsable • Extensible • Standardised

16. IRS Work in Progress in the IETF • Nine Internet-Drafts for IRS • IETF-85 Atlanta, Georgia, 3-9 November 2012 • IRS Birds of a Feather (BoF) • Establish architectural view • Investigate use cases and requirements • Determine level of support to do real work • Form an IETF Working Group • Need to select the key use cases • Agree a charter • Appoint chairs • Target date early 2013 • Rename to stop frightening the Cousins • I2RS

17. IRS Working Group - Scope and Work • Architecture • Requirements • Details of selected use cases • Information models for use cases • Analysis of existing tools and protocols • Re-Charter required before further work • Work on protocols (extensions or new protocols) • Select or invent encoding language • Develop data models • Join the discussions and contribute to the work • http://www.ietf.org/mailman/irs-discuss

18. Integrating the Toolkit • Re-use of tools is efficient and timely • Leverage existing developments • SDN problem space demands many functions • Make use of all the tools in the toolkit • Build new tools to fill the gaps • Application-Based Network Operation (ABNO) • An SDN Toolbox Architecture • Facilitate high-function network operation • Integrate all of the existing features • Create a framework for IRS

19. Application-Based Network Operation • SDN tools provide high-function, but low granularity • There is a need to coordinate SDN operation to provide service-level features • Some components already exist or are proposed • Orchestrators • OpenFlow Controllers • Routing protocols • Config daemons • IRS Client • Virtual Network Topology Manager • Need a wider architecture to pull the tools together • A framework in which the SDN components operate

20. ABNO Framework NMS/OSS Application/Service Requester ABNO Controller IRS Agent Virtual Network Topology Manager IRS/PCEP Network Policy Off-Board Routing Protocol PCE Resource Manager TED PCEP OpenFlow/Forces BGP-LS Network IRS Config/Netconf Routers OpenFlow/Forces

21. Toolbox Example : Virtual Topology • Cannot address a service request in IP/MPLS network • Create a connection in an under-lying optical network • Make a virtual link to enable the service Traffic demand Service request BGP-LS TEDB TEDB PCEP IGP-TE PCE PCE ABNO Controller VNTM PCEP IRS Virtual Link RSVP-TE Policy OpenFlow & ForCES IRS PCEP IRS GMPLS IGP-TE

22. Summary • Basic SDN function available today • OpenFlow, ForCES • Existing tools for advanced SDN function • PCE, BGP-LS, VNTM, Netconf • Advanced SDN function • Programmable access to core router function • Available as the Interface to the Routing System (IRS) • Integration of the toolkit • Chiefly and architectural task • Application-Based Network Operation (ABNO)

23. Questions? adrian@olddog.co.uk afarrel@juniper.net