Requirements for Ring Protection in MPLS-TP

1. Requirements for Ring Protectionin MPLS-TP John Drake (John.E.Drake2@boeing.com) Adrian Farrel (adrian@olddog.co.uk) 73rd IETF, Minneapolis, November 2008

2. There is a base requirement • draft-jenkins-mpls-mpls-tp-requirements-01 • If protection is supported then • MPLS-TP MAY support mechanisms that are optimized for specific network topologies (e.g. ring). These mechanisms MUST be interoperable with the mechanisms defined for arbitrary topology (mesh) networks. • If optimised mechanisms for ring topologies are supported then they MUST support switching times within 50 ms (depending on CV rate configuration) assuming a reference network of a 16 node ring with less than 1200 Km of fiber, as defined by ITU SG15, Question 9. 73rd IETF, Minneapolis, November 2008

3. What do service providers say? • “We want to deploy MPLS-TP in rings.” • “We want to protect our traffic” • That means we need to provide “ring protection” • But what is a ring? 73rd IETF, Minneapolis, November 2008

4. Deployment Scenarios • The network *is* the ring • Deploy routers to replace TDM equipment • Ring as a layer network • The virtual rings imposed on a mesh network to provide connectivity 73rd IETF, Minneapolis, November 2008

5. Physical rings • Physical topology is easy… • An arrangement of two or more nodes each with exactly two line-side interfaces • Each node may have multiple “customer-facing interfaces” • That means that the full extent of the MPLS-TP network is the ring • The ring can be used to support connectivity as a layer network • We can extend this idea to allow ring- interconnect to make larger networks 73rd IETF, Minneapolis, November 2008

6. Layered Network • A ring in the server layer can provide a set of TE links in the client layer • The TE links are protected by the protection within the ring 73rd IETF, Minneapolis, November 2008

7. Virtual Rings • We can super-impose a ring onto a mesh • This creates a virtual or logical ring • We can apply ring properties (whatever they are) to this ring 73rd IETF, Minneapolis, November 2008

8. Detailed Requirements • Supplied by ITU based on draft version of G.8132 • “T-MPLS Shared Protection Ring” • Summarised and translated into English… • A packet transport ring protection scheme shall: • Be applicable at a packet transport layer, for both logical and physical ring topologies • Operate in the data plane, i.e., be independent of a control plane or a management plane • Have the capability to coordinate protection switching actions with resiliency mechanisms possibly operating at the server layer • Support switching time within 50 ms • Protect pt-to-pt and pt-to-mp connections • Have the capability to disable ring protection on selected links (depending on operator’s need) • Maximize the recovery of all possible traffic, both in case of single and multiple failures (including link and/or node failure) • Allow “administrative” protection switching • Support priority logic to negotiate and accommodate simultaneous requests • Support bidirectional switching (unidirectional protection switching is not required) • Support revertive switching (non-revertive is not required) • Prevent protection switch thrashing • Support the sharing of ring protection bandwidth for best-effort traffic and prioritised protection • Support inter-ring connectivity with single and dual node connectivity • Support vendor interoperability in a single ring or at the shared node/link of interconnected rings • Simplify configuration, maintenance operations, ring upgrade, reliable protection status and alarms reporting 73rd IETF, Minneapolis, November 2008

9. Requirements are not solutions • Important not to drive requirements by statements of existing solutions in other technologies • Requirements should be stated clearly in abstract terms • Requirements should not be unnecessarily limited to rings • Where-ever possible applicable to general mesh networks • We will attempt to meet requirements using existing techniques • MPLS data plane techniques (label stacking, etc.) • MPLS control plane (fast reroute) • GMPLS control plane • Link level protection • End-to-end protection • Segment protection 73rd IETF, Minneapolis, November 2008

10. What next? • Do we really need an I-D to describe ring protection requirements? • Which of the requirements listed would not be applicable in generic mesh networks? • It might be valuable to have an applicability statement • How to use existing mechanisms to provide optimized protection in ring deployments • Show how all “ring protection requirements” are solved 73rd IETF, Minneapolis, November 2008