MPLS Working Group Dave Allan, Greg Mirsky Internet Draft Ericsson Intended status: Informational Expires: May 2012 November 2011 A framework for the use of SPMEs for shared mesh protection draft-allan-spme-smp-fmwk-00 Abstract Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". Allan et al., Expires May 2012 [Page 1] Internet-Draft draft-allan-spme-smp-fmwk-00 November 2011 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2nd 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Authors......................................................3 2. Conventions used in this document..............................3 2.1. Terminology..................................................3 3. Overview.......................................................4 3.1. Architectural Overview.......................................4 4. Signalling Implications........................................5 5. IANA Considerations............................................5 6. Security Considerations........................................5 7. References.....................................................6 7.1. Normative References.........................................6 7.2. Informative References.......................................6 8. Authors' Addresses.............................................6 Allan et al., Expires May 2012 [Page 2] Internet-Draft draft-allan-spme-smp-fmwk-00 November 2011 1. Introduction Shared mesh protection is described in [2]. A common interpretation of the behavior of shared mesh protection emerges from the circuit switched world whereby subtending path selectors and selector coordination functions support path preemption to ensure that the highest priority path needing the protection resources is granted ownership of the shared segment, all others being preempted, and such functionality can be successfully delegated to dataplane OAM. Ultimately this resolves into a business priority decision vs. an application priority decision in how customer traffic is handled. The packet world is different from the circuit world in that there is no guarantee of convenient alignment of resource requirements between preempting and preempted paths. Nor in a packet environment is there the need to completely preempt all the traffic in a lower priority path simply because a higher priority path lays claim to the resources. Finally it is useful to obviate the requirement for preempting and preemptable traffic to be co-routed. This memo proposes the use of SPMEs with the pipe model of TC copying as an alternative to the use of path pre-emption, path selectors and selector coordination functions for the purposes of implementing business policy. 1.1. Authors David Allan, Greg Mirsky 2. Conventions used in this document 2.1. Terminology MPLS-TP: MPLS Transport Profile MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path representing a circuit SMP: Shared Mesh Protection SPME: Sub-Path Maintenance Entity TC: Traffic Class TTL: Time To Live Allan et al., Expires May 2012 [Page 3] Internet-Draft draft-allan-spme-smp-fmwk-00 November 2011 3. Overview Shared mesh protection is described in [2]. A common interpretation of the behavior of shared mesh protection emerges from the circuit switched world. In that interpretation subtending path selectors and selector coordination support path preemption functionality to ensure that the highest priority path needing the protection resources is the one granted ownership of the shared segment; all others being preempted. It also assumes that all paths sharing the protection resources conveniently all need exactly the same size pipe. In packet transport networks there will frequently not be a convenient 1:1 equivalence of the bandwidth requirements of the set of transport paths sharing protection resources such that a simple pre-emption decision can be made. For example 3 paths: A, B, and C sized "n", "n/2" and "n/2" respectively could have a shared segment size "3n/2" such that simultaneous failures necessitating the activation of any two of the protection paths could be accommodated without path preemption. When one ranks A, B and C with a variety of priorities and considers all failure combinations a rather large matrix of possible required behaviors emerges. If one pursues this line of thinking to its logical conclusion, and envisions a significant set of paths of diverse sizes and diverse priorities, the policy associated with successful path prioritization and preemption becomes quite complex, and ensuring multiple selectors make timely and of necessity common preemption decisions starts to impose network design constraints or require additional coordination protocols that severely impact the utility of SMP. Further in a packet network there can be a difference in the bandwidth reserved and the bandwidth actually used at any given instant in time. One consequence is that there is no need to completely preempt all the traffic in a lower priority path simply because a higher priority path lays a preferential claim to the bandwidth. To obviate these problems, this memo proposes an alternative to how business priority can be implemented for shared mesh protection that obviates the need for path preemption and the limitations such an approach imposes. 3.1. Architectural Overview This memo pre-supposes an operational mode of behavior along the lines of the following: Allan et al., Expires May 2012 [Page 4] Internet-Draft draft-allan-spme-smp-fmwk-00 November 2011 1) As a matter of network design, specific links (or engineered virtual links) are set aside for the purpose of acting as shared protection resources. The key attribute of these links is that the processing of TC markings will be exclusively for shared protection. 2) The arrangement of the shared protection links can be arbitrary such that contiguous domains can be constructed with an arbitrary number of ingress and egress points. A set of contiguous protection links is known as a protection domain. 3) Either an apriori or on-demand mesh of SPMEs that connect all ingress and egress points in a protection domain is required. These are logically forwarding adjacencies for the purposes of routing protection paths 4) The instantiation of protection paths requires the mapping of the incoming path at an ingress node for the protection domain to an SPME that connects the ingress to the required egress node from the domain. 5) The pipe model of TC copying is used such that the SPME gets the TC marking associated with the business priority for the path associated with the incoming label value. As the SPME only transits resources where the TC marking has been overloaded in this fashion business priority does not conflict with application requirements. 6) Admission control for the protection paths transiting the protection domain is performed such that the sum of the bandwidth for a given business priority does not oversubscribe any links in the protected domain, but the sum of the bandwidth for all business priorities can. In this way no traffic of the highest business priority using the shared mesh pool will be contended. 4. Signalling Implications For a future version of this document. 5. IANA Considerations No IETF protocols were harmed in the publishing of this memo. 6. Security Considerations For a future version of this document. Allan et al., Expires May 2012 [Page 5] Internet-Draft draft-allan-spme-smp-fmwk-00 November 2011 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [2] Sprecher, N., et al. "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011 8. Authors' Addresses Dave Allan Ericsson Email: david.i.allan@ericsson.com Greg Mirsky Ericsson Email: Gregory.mirsky@ericsson.com Allan et al., Expires May 2012 [Page 6]