240 likes | 450 Views
Multi-Segment Pseudowires: Recognising the Layer Network. Adrian Farrel 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
E N D
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
Payload Encapsulation May be empty PW Demultiplexer May be empty PSN Convergence PSN Data-Link Physical Ethernet Header MPLS Tunnel Label MPLS PW Label Control Word IP Header Data Last byte First byte The PW Layering Model • RFC 3985 defines logical protocol layering • For example… © Copyright Old Dog Consulting 2010
Multi-Segment Architecture • 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) Pseudowire Segments Native Service AC Terminating PE Provider Network Provider Network CE Tunnel Switching PEs © Copyright Old Dog Consulting 2010
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
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
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
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
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
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
MS-PW Protection Single segment protection End-to-end MS-PW protection PSN tunnel protection Multi-segment protection © Copyright Old Dog Consulting 2010
P2MP Pseudowires © Copyright Old Dog Consulting 2010
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
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
Topology Layering • Tunnels between S-PEs in the PSN become links in the MS-PW network © Copyright Old Dog Consulting 2010
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
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
PWs Are Transport-Agnostic Emulated Service AC • No surprises here • But packet technologies can be different • Architecture must allow independence of PW segments • Still deliver end-to-end emulated service End-to-End PW Switch Stitch PW Segment Packet Tunnel CE MPLS-TP Ethernet IP T-PE S-PE © Copyright Old Dog Consulting 2010
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
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
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
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
Questions adrian@olddog.co.uk © Copyright Old Dog Consulting 2010