1 / 23

Multi-Segment Pseudowires: Recognising the Layer Network

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

deion
Download Presentation

Multi-Segment Pseudowires: Recognising the Layer Network

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multi-Segment Pseudowires: Recognising the Layer Network Adrian Farrel Old Dog Consulting Old Dog Consulting

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. MS-PW Protection Single segment protection End-to-end MS-PW protection PSN tunnel protection Multi-segment protection © Copyright Old Dog Consulting 2010

  12. P2MP Pseudowires © Copyright Old Dog Consulting 2010

  13. 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

  14. 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

  15. Topology Layering • Tunnels between S-PEs in the PSN become links in the MS-PW network © Copyright Old Dog Consulting 2010

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. Questions adrian@olddog.co.uk © Copyright Old Dog Consulting 2010

More Related