1. Interface to the Routing System
Adrian Farrel

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
Integrating the 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
OpenFlow
FIB 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 standardised protocol and encoding 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.
IRS
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 Client
IRS Protocol & Data Encoding
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 Stateless communications (RESTful)
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

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
IRS/PCEP
Virtual Network Topology Manager
Off-Board
Routing Protocol
Network Policy
PCE
Resource Manager
TED
OpenFlow/Forces
PCEP
BGP-LS
Network
IRS
Config/Netconf
OpenFlow/Forces
Routers

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
ABNO Controller
BGP-LS
TEDB
PCEP
IGP-TE
PCE
PCEP
IRS
Virtual Link
RSVP-TE
Policy
VNTM
OpenFlow & ForCES
IRS
PCEP
IRS
GMPLS
PCE
TEDB
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?