Internet DRAFT - draft-allan-mpls-spme-smp-fmwk

draft-allan-mpls-spme-smp-fmwk



MPLS Working Group                              Dave Allan, Greg Mirsky 
Internet Draft                                                 Ericsson 
Intended status: Informational                                        
Expires: February 2013                                   
                                                            August 2012 
                                    

        A framework for the use of SPMEs for shared mesh protection 
                       draft-allan-mpls-spme-smp-fmwk-01 


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 February 2013                 [Page 1] 
 

Internet-Draft    draft-allan-mpls-spme-smp-fmwk-01         August 2012 
 

   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) 2012 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 February 2013                 [Page 2] 
 

Internet-Draft    draft-allan-mpls-spme-smp-fmwk-01         August 2012 
 

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 February 2013                 [Page 3] 
 

Internet-Draft    draft-allan-mpls-spme-smp-fmwk-01         August 2012 
 

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 February 2013                 [Page 4] 
 

Internet-Draft    draft-allan-mpls-spme-smp-fmwk-01         August 2012 
 

   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 February 2013                 [Page 5] 
 

Internet-Draft    draft-allan-mpls-spme-smp-fmwk-01         August 2012 
 

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 February 2013                 [Page 6]