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

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

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

73rd IETF, Minneapolis, November 2008 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

73rd IETF, Minneapolis, November 2008 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

73rd IETF, Minneapolis, November 2008 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

73rd IETF, Minneapolis, November 2008 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

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

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

73rd IETF, Minneapolis, November 2008 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