Download Interface to the Routing System

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Deep packet inspection wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Peering wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Network tap wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Distributed firewall wikipedia , lookup

Internet protocol suite wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Computer network wikipedia , lookup

IEEE 1355 wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Airborne Networking wikipedia , lookup

Routing wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Transcript
Interface to the Routing System
Adrian Farrel
[email protected]
[email protected]
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
2 of 23
The Routing System
• The forwarding plane is just part of a router
• We are interested in larger granularity impact
Router
Topology DB
Config
OAM, Events
Measurement
Config DB
RIB
Policy DB
OpenFlow
RIB Manager
FIB
Routing
and
Signalling
Data Plane
3
3 of 23
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”
4 of 23
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
5 of 23
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
6 of 23
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
7 of 23
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
8 of 23
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
9 of 23
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
10 of 23
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
11 of 23
Additional SDN Function
• Applications need to dynamically:
– Augment routing, based on:
• Policy
• Flow and application awareness
• Time and external changes
Network
Application
IRS
IRS
IRS
IRS
IRS
– With knowledge of:
•
•
•
•
Topology (active & potential)
Network events
Traffic measurement
Etc.
12 of 23
Feedback Loop:
Control & Information
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
13 of 23
The IRS Architecture
Application
Application
Application
Server
IRS Client
IRS Client
IRS Protocol &
Data Encoding
Router
OAM, Events
and
Measurement
Policy DB
Data Plane
IRS Agent
RIBs and RIB Manager
Topology DB
Routing and
Signaling
Protocols
FIB
14
14 of 23
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
15 of 23
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
16 of 23
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
17 of 23
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
18 of 23
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
19 of 23
ABNO Framework
NMS/OSS
Application/Service Requester
ABNO Controller
IRS Agent
IRS/PCEP
Network
Policy
OffBoard
Routing
Protocol
Virtual Network
Topology Manager
PCE
Resource Manager
TED
OpenFlow/Forces
PCEP
BGP-LS
Network
IRS
Config/
Netconf
OpenFlow/
Forces
Routers
20 of 23
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
ABNO Controller
TEDB
PCEP
IGP-TE
PCE
PCEP
IRS
Policy
IRS
Virtual Link
RSVP-TE
VNTM
OpenFlow
& ForCES
PCEP
IRS
GMPLS
PCE
TEDB
IGP-TE
21 of 23
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)
22 of 23
Questions?
[email protected]
[email protected]
23 of 23