Transcript Multi-Segment Pseudowires : Recognising the Layer Network

Multi-Segment Pseudowires:
Recognising the Layer Network
Adrian Farrel
Old Dog Consulting
Old Dog Consulting
Agenda
• Existing building blocks
• Protocol layering in the data plane
• Multi-segment pseudowires
• Architecture and drivers
• Functional requirements
• Picking paths and setting up pseudowires
• Service-level requirements
• The layer model
• Pitfalls and benefits
• Next steps
© Copyright Old Dog Consulting 2010
Page 2
The PW Layering Model
• RFC 3985 defines logical protocol layering
Payload
Encapsulation
May be empty
PW Demultiplexer
PSN Convergence
May be empty
PSN
Data-Link
Physical
• For example…
Ethernet
Header
MPLS
Tunnel Label
MPLS
PW Label
Control
Word
IP Header
Data
Last byte
First byte
© Copyright Old Dog Consulting 2010
Page 3
Multi-Segment Architecture
Pseudowire
Segments
Native Service AC
Provider Network
Terminating PE
Provider Network
CE
Switching PEs
•
•
•
•
Tunnel
Simple extension to the RFC 3985 model
Emulated service is still CE-to-CE
Tunnels are still used to carry the PWs
End-to-end PW is called a multi-segment PW
• Runs between the Terminating PEs (T-PEs)
• Constructed from PW segments
• Carried across provider networks in tunnels
• Tunnels terminated at PEs
• PW segments “switched” (or stitched) at Switching PEs (S-PEs)
© Copyright Old Dog Consulting 2010
Page 4
MS-PW Deployment Motivations
• Initial model shows inter-AS PW service
• A more pressing need
• Reduce the complexity of the tunnel mesh
• Help scaling at PEs and P nodes
• S-PE becomes a network-internal node
• Not the best name!
• Same model applies to inter-area PW service
• Utility extends to P2MP PWs (discussed later)
Pseudowire
Segments
Native Service AC
Terminating PE
Provider Network
CE
Tunnel
Switching PE
© Copyright Old Dog Consulting 2010
Page 5
MS-PW Challenges
• Data plane encapsulation
• Picking a path through the network
• Setting up pseudowire segments and PSN
tunnels
• Service-level requirements
• Capacity
• Diversity
• P2MP
• Operations, Administration and Maintenance
© Copyright Old Dog Consulting 2010
Page 6
Data Plane Challenges
• PW encoding should be independent of PSN technology
• Same techniques/hardware “packetization”
• Regardless of underlying PSN transport
• Resource reservation is needed to guarantee PW
service
• PWs use PSN tunnels
• Reservation must use tunnel resources
• Tunnel must map its resources to network resources
• Tunnel transit nodes are not aware of payload PWs
• PWs must be multiplexed onto data channels to scale
the data plane
• PW flows must not merge
• Have to be able to trace and distinguish individual PWs
• Essential for OAM and fault diagnosis
© Copyright Old Dog Consulting 2010
Page 7
Path Determination
• Choices to be made
• Which tunnels to use?
• Which S-PEs to use?
• For dual-homed CEs: which T-PEs to use?
• Are these choices made in planning or during
LSP set-up? (see next slide)
• What factors affect the choices?
•
•
•
•
Tunnel load and capacity
S-PE load and capacity
Reduce the number of segments on the path?
Path diversity for backup services
© Copyright Old Dog Consulting 2010
Page 8
PW Setup
• Components of MS-PW establishment
• Tunnel set-up
• PW segment set-up
• PW segment stitching
• Choices
• All through the management plane
• Control plane for tunnels and MP for PWs
• Control plane for tunnels and PW segments
• But segment stitching using management plane
• Fully in the control plane
• Some segments MP, some segments CP
• How much operator involvement is needed?
• Where are the administrative boundaries?
• Can the signalling protocols handle the MS-PW path and
constraints?
© Copyright Old Dog Consulting 2010
Page 9
Service Requirements
• Influence path determination and set-up
• PW capacity and quality requirements
• Protection considerations
• End-to-end protection
• Tunnels are diverse
• No re-use of S-PEs
• Segment protection
• Tunnels between S-PEs are diverse
• Protect a PW segment
• Protect an S-PE
• Point-to-multipoint PWs
• Use a single P2MP tunnel?
• Stitch multiple P2P PW segments?
• Combine the techniques?
© Copyright Old Dog Consulting 2010
Page 10
MS-PW Protection
Single segment protection
End-to-end MS-PW protection
PSN tunnel protection
Multi-segment protection
© Copyright Old Dog Consulting 2010
Page 11
P2MP Pseudowires
© Copyright Old Dog Consulting 2010
Page 12
OAM Challenges
• OAM function provides
• Service verification
• Fault detection and reporting
• Fault isolation
• Service verification is end-to-end
• Can run OAM on the PW or on the emulated service
• Faults need to be known where they are to be
handled
• T-PEs for end-to-end protection
• S-PEs for protecting individual segments
• Scaling may be an issue
• How many PWs pass through an S-PE?
• Running OAM on a tunnel can solve this
© Copyright Old Dog Consulting 2010
Page 13
The Layer Model
• There is a natural layering available
• Nothing clever!
• Make a topology of
• Nodes = PEs (T-PEs and S-PEs)
• Links = PSN tunnels
• See that these links have cost and bandwidth
• Plan and set up MS-PWs on this topology
• Each “hop” is a single segment PW
© Copyright Old Dog Consulting 2010
Page 14
Topology Layering
• Tunnels between S-PEs in the PSN become
links in the MS-PW network
© Copyright Old Dog Consulting 2010
Page 15
Multi-Access links
• P2MP tunnels form multi-access links in the MS-PW network
• Care needed about unidirectional P2MP tunnels!
© Copyright Old Dog Consulting 2010
Page 16
The Application Layer is Extra
•
•
•
•
Emulated service is between CEs
• CE is out of scope for the provider network
End-to-end protected service is required
• Protected service is through two “parallel” emulated services
• Individually requested
• Different T-PEs?
• Different ACs?
The protection is the responsibility of the service user
But the emulated services need to have disjoint paths
• Requires the use of Shared Risk Link Groups (SRLGs)
© Copyright Old Dog Consulting 2010
Page 17
PWs Are Transport-Agnostic
AC
Emulated Service
End-to-End PW
Switch
Stitch
PW Segment
Packet Tunnel
CE
MPLS-TP
T-PE
•
•
•
•
Ethernet
IP
S-PE
No surprises here
But packet technologies can be different
Architecture must allow independence of PW segments
Still deliver end-to-end emulated service
© Copyright Old Dog Consulting 2010
Page 18
Pitfalls to Avoid
• “Don’t worry about the control plane”
• Let’s do it all in the management plane for now
• True, but network planning can make good use of layers
• OAM layering will help operations
• “Let’s leverage the IGP”
• We can use our IP/MPLS IGP “discover” S-PEs
• Fine to run an IGP instance in the PW layer
• But don’t overload the normal IGP
• Consider how inter-AS will work
• How about using PCE in the PW layer?
• “Layers add unnecessary complexity”
• We only have a simple network with one S-PE
• Networks will inevitably get more complicated and larger
• How easy will it be to cut over to a layered approach later?
© Copyright Old Dog Consulting 2010
Page 19
More Pitfalls
• “Network layering implies operational separation”
• We want to operate an integrated PSN
• Network layers can be operated and planned independently
• Dynamic integrated multi-layer networks are possible
• Feedback loops between layers with appropriate policy controls and
operator input
• IP/Optical is the latest buzz in this area
• “We can grow LDP to handle MS-PW” in IP/MPLS
networks
• We already use LDP for PW set-up
•
•
•
•
•
It’s true, any protocol can be extended to do anything!
LDP is designed as a neighbour-to-neighbour protocol
T-LDP is currently used only for single segment PWs
Functional creep does not make for good protocol design
Need extensions for all elements of constraint-based path signalling
• Explicit routes, route recording, bandwidth reservation, protection, path
association and path diversity, etc., etc.
• We do already have a PSN signalling suite for this type of function
(RSVP-TE/GMPLS)
© Copyright Old Dog Consulting 2010
Page 20
Potential Benefits?
• Simplified network view
• Aids operation and planning
• Integration of multiple PSN types
• Reduced complexity in network operation
• Separation of application from operation
• Reduced number of control plane protocols
• Increased features and functions
• Leverage experience with existing multi-layer
networks and control planes
•
•
•
•
•
Path computation and control
Resource reservation and management
Protection and restoration
Point-to-multipoint
OAM control and configuration
© Copyright Old Dog Consulting 2010
Page 21
What Should We Do About It?
• Decide whether MS-PWs are for real
• Plan our control plane protocols
• Don’t just evolve them piecemeal
• Look to see if we can leverage existing
protocols we are already running
• Recognise the layered architecture
• Build this into our PW architecture work
• Design PW networks as layers
© Copyright Old Dog Consulting 2010
Page 22
Questions
[email protected]
© Copyright Old Dog Consulting 2010
Page 23