The Impact of SDN On MPLS Networks
Adrian Farrel
Juniper Networks
afarrel@juniper.net
www.mpls2012.com
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?
• Shiny-thing Desparately Needed
• $ome Dollars Now
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)
LFIB
Prefix Out i/f, label
IP Packet
NHFLE
In i/f, label Out i/f, label
MPLS Packet
NHFLE
In i/f, label Pop
MPLS Packet
• Integration with underlying data plane
• Encapsulation rules
• Data link addresses
6
IP Packet
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
Control plane
SDN
Programming
Language
Data plane
8
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
•
•
•
•
•
IGP enhanced for TE and link quality
BGP-LS reports to PCE
PCE requests LSPs
Normal LSP signaling
LSP status reports
PCE
13
Making New Tools
• Can’t do everything with what have already
• Interface to the Routing System (IRS)
• A programmatic interface to routers
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
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
Traffic demand
Service request
IRS
BGP-LS
TEDB
IGP-TE
PCE
PCEP
IRS
Policy
IRS
Virtual Link
RSVP-TE
VNTM
OpenFlow
& IRS
PCEP
IRS
GMPLS
PCE
TEDB
16
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
DB Replication
Content
Streaming
Data Transfer
17
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?
Or a cornucopia of riches?
19
Questions?
afarrel@juniper.net
20