A framework for the use of SPMEs for shared mesh protection draft-allan-mpls-spme-smp-frmwk-00 Dave Allan, Greg Mirsky

Problem Numerous proposals exist to support the concept of shared mesh restoration with a concept of path preemption –So business priority can be applied to path protection when network resources are contended This is rather draconian on several fronts –The preempted service is 100% preempted, it simply stops working even if the preempting service is not consuming all of the protection resources at a given time –It requires the addition of path selectors and the coordination of same at arbitrary points in the network –Selector placement is constrained Limitations of “Preemption heuristics” explicitly limit the LSPs to being of “equal size” –Variable size pipes of different business priorities becomes an intractable logic problem

A simple example of selector based Shared mesh Two paths with a shared backup segment The selectors need to work in such a way that if both working paths fail, the service with the higher business priority gets use of the bandwidth in the shared protection segment Protected service Working Path Shared Protection Segment Protected service Working Path Head end AND all shared segment selectors ALL need reliable coordination to successfully protection switch

The issue If one can live with degradation of a service instead of preemption and notification, offering shared mesh protection can be significantly simplified –It is simply a planning exercise with no protocol changes This can be done by encoding business priority on a packet by packet basis across the shared segment –Packets with the highest business priority always get through –Packets with lower priority can scavenge unused bandwidth If we do this then: 1. no selector coordination is required, 2.no additional protocol elements are required, 3.no artificial constraints are placed on the locations of ingress to and egress from shared segments ›Shared protection resources have no topological constraints 4.No artificial constrains are placed on fixed pipe sizes

How to do this 1.Links are uniquely set aside as shared segment links ›This could be virtual links in the form of LLSPs that traffic is policed/shaped into 2.SPMEs at the ingress to a shared segment link use the pipe model of DSCP handling to impose encoding of business priority in the TC field of the SPME label – actual application encodings are simply tunneled 3.Network planning does not oversubscribe a business priority in a shared space but the sum of traffic across all business priorities does

Example Working Path High Priority Protection Path High Priority Shared mesh SPME High Priority Working Path Low Priority Protection Path Low Priority Shared mesh SPME Low priority Working paths traverse links that can carry  of all traffic Protection paths are only uncontended at a given business priority  of all traffic for all business priorities can oversubscribe link

Signalling Implications If signalling carried an indication of business priority, at the ingress to a shared protection domain, the SPME could be inferred from the combination of priority and the ERO permitting the SPME with the correct priority and domain egress to be selected

Next Steps We’ll pose the questions: “Do we see more than one model of shared mesh going forward?” “If only one, what are the actual business requirements?” Collect comments and seek validation