idnits 2.17.1 draft-allan-mpls-spme-smp-fmwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 2012) is 4243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Dave Allan, Greg Mirsky 2 Internet Draft Ericsson 3 Intended status: Informational 4 Expires: February 2013 5 August 2012 7 A framework for the use of SPMEs for shared mesh protection 8 draft-allan-mpls-spme-smp-fmwk-01 10 Abstract 12 Shared mesh protection allows a set of diversely routed paths with 13 diverse endpoints to collectively oversubcribe protection resources. 14 Under normal conditions no single failure will result in the capacity 15 of the associated protection resources to be exhausted. 17 When multiple failures occur such that more than one path in the set 18 of paths utilizing shared protection resources is affected, the 19 necessity arises of pre-empting traffic on the basis of business 20 priority rather than application priority. 22 This memo describes the use of SPMEs and TC marking as a means of 23 indicating business priority for shared mesh protection. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC2119 [1]. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance 34 with the provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet 37 Engineering Task Force (IETF), its areas, and its working 38 groups. Note that other groups may also distribute working 39 documents as Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other 43 documents at any time. It is inappropriate to use Internet- 44 Drafts as reference material or to cite them other than as "work 45 in progress". 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on August 2nd 2011. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described 67 in Section 4.e of the Trust Legal Provisions and are provided 68 without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction...................................................3 73 1.1. Authors......................................................3 74 2. Conventions used in this document..............................3 75 2.1. Terminology..................................................3 76 3. Overview.......................................................4 77 3.1. Architectural Overview.......................................4 78 4. Signalling Implications........................................5 79 5. IANA Considerations............................................5 80 6. Security Considerations........................................5 81 7. References.....................................................6 82 7.1. Normative References.........................................6 83 7.2. Informative References.......................................6 84 8. Authors' Addresses.............................................6 86 1. Introduction 88 Shared mesh protection is described in [2]. A common interpretation 89 of the behavior of shared mesh protection emerges from the circuit 90 switched world whereby subtending path selectors and selector 91 coordination functions support path preemption to ensure that the 92 highest priority path needing the protection resources is granted 93 ownership of the shared segment, all others being preempted, and such 94 functionality can be successfully delegated to dataplane OAM. 96 Ultimately this resolves into a business priority decision vs. an 97 application priority decision in how customer traffic is handled. The 98 packet world is different from the circuit world in that there is no 99 guarantee of convenient alignment of resource requirements between 100 preempting and preempted paths. Nor in a packet environment is there 101 the need to completely preempt all the traffic in a lower priority 102 path simply because a higher priority path lays claim to the 103 resources. Finally it is useful to obviate the requirement for 104 preempting and preemptable traffic to be co-routed. 106 This memo proposes the use of SPMEs with the pipe model of TC copying 107 as an alternative to the use of path pre-emption, path selectors and 108 selector coordination functions for the purposes of implementing 109 business policy. 111 1.1. Authors 113 David Allan, Greg Mirsky 115 2. Conventions used in this document 117 2.1. Terminology 119 MPLS-TP: MPLS Transport Profile 121 MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path 122 representing a circuit 124 SMP: Shared Mesh Protection 126 SPME: Sub-Path Maintenance Entity 128 TC: Traffic Class 130 TTL: Time To Live 131 3. Overview 133 Shared mesh protection is described in [2]. A common interpretation 134 of the behavior of shared mesh protection emerges from the circuit 135 switched world. In that interpretation subtending path selectors and 136 selector coordination support path preemption functionality to ensure 137 that the highest priority path needing the protection resources is 138 the one granted ownership of the shared segment; all others being 139 preempted. It also assumes that all paths sharing the protection 140 resources conveniently all need exactly the same size pipe. 142 In packet transport networks there will frequently not be a 143 convenient 1:1 equivalence of the bandwidth requirements of the set 144 of transport paths sharing protection resources such that a simple 145 pre-emption decision can be made. For example 3 paths: A, B, and C 146 sized "n", "n/2" and "n/2" respectively could have a shared segment 147 size "3n/2" such that simultaneous failures necessitating the 148 activation of any two of the protection paths could be accommodated 149 without path preemption. When one ranks A, B and C with a variety of 150 priorities and considers all failure combinations a rather large 151 matrix of possible required behaviors emerges. 153 If one pursues this line of thinking to its logical conclusion, and 154 envisions a significant set of paths of diverse sizes and diverse 155 priorities, the policy associated with successful path prioritization 156 and preemption becomes quite complex, and ensuring multiple selectors 157 make timely and of necessity common preemption decisions starts to 158 impose network design constraints or require additional coordination 159 protocols that severely impact the utility of SMP. 161 Further in a packet network there can be a difference in the 162 bandwidth reserved and the bandwidth actually used at any given 163 instant in time. One consequence is that there is no need to 164 completely preempt all the traffic in a lower priority path simply 165 because a higher priority path lays a preferential claim to the 166 bandwidth. 168 To obviate these problems, this memo proposes an alternative to how 169 business priority can be implemented for shared mesh protection that 170 obviates the need for path preemption and the limitations such an 171 approach imposes. 173 3.1. Architectural Overview 175 This memo pre-supposes an operational mode of behavior along the 176 lines of the following: 178 1) As a matter of network design, specific links (or engineered 179 virtual links) are set aside for the purpose of acting as shared 180 protection resources. The key attribute of these links is that 181 the processing of TC markings will be exclusively for shared 182 protection. 184 2) The arrangement of the shared protection links can be arbitrary 185 such that contiguous domains can be constructed with an arbitrary 186 number of ingress and egress points. A set of contiguous 187 protection links is known as a protection domain. 189 3) Either an apriori or on-demand mesh of SPMEs that connect all 190 ingress and egress points in a protection domain is required. 191 These are logically forwarding adjacencies for the purposes of 192 routing protection paths 194 4) The instantiation of protection paths requires the mapping of the 195 incoming path at an ingress node for the protection domain to an 196 SPME that connects the ingress to the required egress node from 197 the domain. 199 5) The pipe model of TC copying is used such that the SPME gets the 200 TC marking associated with the business priority for the path 201 associated with the incoming label value. As the SPME only 202 transits resources where the TC marking has been overloaded in 203 this fashion business priority does not conflict with application 204 requirements. 206 6) Admission control for the protection paths transiting the 207 protection domain is performed such that the sum of the bandwidth 208 for a given business priority does not oversubscribe any links in 209 the protected domain, but the sum of the bandwidth for all 210 business priorities can. In this way no traffic of the highest 211 business priority using the shared mesh pool will be contended. 213 4. Signalling Implications 215 For a future version of this document. 217 5. IANA Considerations 219 No IETF protocols were harmed in the publishing of this memo. 221 6. Security Considerations 223 For a future version of this document. 225 7. References 227 7.1. Normative References 229 [1] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 7.2. Informative References 234 [2] Sprecher, N., et al. "MPLS Transport Profile (MPLS-TP) 235 Survivability Framework", RFC 6372, September 2011 237 8. Authors' Addresses 239 Dave Allan 240 Ericsson 241 Email: david.i.allan@ericsson.com 243 Greg Mirsky 244 Ericsson 245 Email: Gregory.mirsky@ericsson.com