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. What do service providers say? • Service providers give us two fundamental requirements • “We want to deploy MPLS-TP in rings.” • “We want to protect our traffic” • That means we need to provide “ring protection” (i.e., protection in rings) • But what is a ring? 73rd IETF, Minneapolis, November 2008

3. There is a base requirement draft-jenkins-mpls-mpls-tp-requirements-01 req-47: 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 optimized 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. This has caused some confusion. • In order to define optimized mechanisms, we must define what we are trying to optimize, and how we will judge the solution. That means: we need specific requirements written down. 73rd IETF, Minneapolis, November 2008

4. What is a ring?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 • This ring could be operated as a layer (scenario 2) or as if a real ring (scenario 1) 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 clarified a little… 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. Recent Additional Requirements • Know/control where my traffic is in the network • Obviously a bit more simple in a ring 73rd IETF, Minneapolis, November 2008

10. 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 • Even “optimization requirements” might be met by general solutions • We will attempt to meet requirements using existing techniques (this is a JWT requirement) • MPLS data plane techniques (label stacking, etc.) • Must operate without using a control plane • MPLS control plane (fast reroute) • GMPLS control plane • Link level protection • End-to-end protection • Segment protection • New solutions if and only if necessary to meet requirements 73rd IETF, Minneapolis, November 2008

11. 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? • But maybe there are other requirements (e.g., optimization requirements) • It will be valuable to have applicability statements • How to use existing mechanisms to provide protection in ring deployments • Show how all “ring protection requirements” are solved • Include scenarios for optimization cases • This could all be included in the Protection and Survivability Framework I-D • draft-sprecher-mpls-tp-survive-fwk-00.txt 73rd IETF, Minneapolis, November 2008