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

2. Page 2 © Copyright Old Dog Consulting 2010 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

3. Page 3 © Copyright Old Dog Consulting 2010 The PW Layering Model RFC 3985 defines logical protocol layering For example… Payload Encapsulation PW Demultiplexer PSN Convergence PSN Data-Link Physical May be empty Ethernet Header MPLS Tunnel Label MPLS PW Label Control Word IP HeaderData First byte Last byte

4. Page 4 © Copyright Old Dog Consulting 2010 Multi-Segment Architecture Pseudowire Segments Provider Network Tunnel Switching PEs Native Service AC Terminating PE Provider Network 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) CE

5. Page 5 © 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 Provider Network Tunnel Switching PE Native Service AC Terminating PE CE

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

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

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

9. Page 9 © 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?

10. Page 10 © 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?

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

12. Page 12 © Copyright Old Dog Consulting 2010 P2MP Pseudowires

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

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

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

16. Page 16 © 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!

17. Page 17 © 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)

18. Page 18 © Copyright Old Dog Consulting 2010 PWs Are Transport-Agnostic No surprises here But packet technologies can be different Architecture must allow independence of PW segments Still deliver end-to-end emulated service MPLS-TPIPEthernet T-PE S-PE CE AC Packet Tunnel PW Segment End-to-End PW Emulated Service Stitch Switch

19. Page 19 © 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?

20. Page 20 © 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)

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

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

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