idnits 2.17.1 draft-he-teas-gmpls-signaling-smp-00.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 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC4872, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'A' is mentioned on line 177, but not defined == Missing Reference: 'B' is mentioned on line 177, but not defined == Missing Reference: 'C' is mentioned on line 177, but not defined == Missing Reference: 'D' is mentioned on line 177, but not defined == Missing Reference: 'H' is mentioned on line 165, but not defined == Missing Reference: 'I' is mentioned on line 164, but not defined == Missing Reference: 'J' is mentioned on line 164, but not defined == Missing Reference: 'K' is mentioned on line 165, but not defined == Missing Reference: 'E' is mentioned on line 165, but not defined == Missing Reference: 'F' is mentioned on line 165, but not defined == Missing Reference: 'G' is mentioned on line 165, but not defined == Unused Reference: 'RFC7412' is defined on line 364, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group J. He 2 Internet Draft I. Busi 3 Updates (if published): RFC 4872 Huawei 4 Intended status: Standards Track 6 Expires: April 20, 2019 October 22, 2018 8 GMPLS Signaling Extensions for Shared Mesh Protection 9 draft-he-teas-gmpls-signaling-smp-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current 19 Internet-Drafts is at 20 https://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 This Internet-Draft will expire on April 20, 2019. 30 Copyright Notice 32 Copyright (c) 2018 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with 40 respect to this document. Code Components extracted from this 41 document must include Simplified BSD License text as described in 42 Section 4.e of the Trust Legal Provisions and are provided without 43 warranty as described in the Simplified BSD License. 45 Abstract 47 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects 48 of a shared mesh protection (SMP) mechanism, where the difference 49 between SMP and shared mesh restoration (SMR) is also identified. 50 ITU-T Recommendation G.873.3 [G873.3] defines the protection 51 switching operation and associated protocol for shared mesh 52 protection (SMP) at the optical data unit (ODU) layer. RFC 7412 53 provides requirements for any mechanism that would be used to 54 implement SMP in an MPLS-TP network. 56 This document updates RFC 4872 to provide the extensions to the 57 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 58 support the control of the shared mesh protection. 60 Table of Contents 62 1. Introduction ................................................2 63 2. Conventions used in this document............................3 64 3. SMP Definition ..............................................3 65 4. GMPLS Signaling Extension for SMP............................4 66 4.1. Identifiers ............................................5 67 4.2. Signaling Primary LSPs..................................6 68 4.3. Signaling Secondary LSPs................................6 69 5. Updates to PROTECTION Object.................................7 70 5.1. New Protection Type.....................................7 71 5.2. Other Updates ..........................................7 72 6. Security Considerations......................................8 73 7. IANA Considerations .........................................8 74 8. References ..................................................8 75 8.1. Normative References....................................8 76 8.2. Informative References..................................9 78 1. Introduction 80 RFC 4872 [RFC4872] defines extension of RSVP-TE to support shared 81 mesh restoration (SMR) mechanism. Shared mesh restoration can be 82 seen as a particular case of pre-planned LSP rerouting that 83 reduces the recovery resource requirements by allowing multiple 84 protecting LSPs to share common link and node resources. The 85 recovery resources for the protecting LSPs are pre-reserved during 86 the provisioning phase, and an explicit restoration signaling is 87 required to activate (i.e., commit resource allocation at the data 88 plane) a specific protecting LSP instantiated during the 89 provisioning phase. 91 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects 92 of a shared mesh protection (SMP) mechanism. ITU-T Recommendation 93 G.873.3 [G873.3] defines the protection switching operation and 94 associated protocol for shared mesh protection (SMP) at the optical 95 data unit (ODU) layer. RFC 7412 provides requirements for any 96 mechanism that would be used to implement SMP in an MPLS-TP network. 98 SMP differs from SMR in the activation/protection switching 99 operation. The former activates a protecting LSP via the automatic 100 protection switching (APS) protocol in the data plane when the 101 working LSP fails, while the latter via the control plane 102 signaling. It is therefore necessary to distinguish SMP from SMR 103 during provisioning so that each node involved behaves 104 appropriately in the recovery phase when activation of a 105 protecting LSP is done. 107 This document updates RFC 4872 to provide the extensions to the 108 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 109 support the control of the shared mesh protection mechanism. Only 110 the generic aspects for signaling SMP are addressed by this 111 document. The technology-specific aspects are expected to be 112 addressed by other drafts. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 117 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 118 "MAY", and "OPTIONAL" in this document are to be interpreted as 119 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 120 appear in all capitals, as shown here. 122 In addition, the reader is assumed to be familiar with the 123 terminology used in [RFC4872] and [RFC4426]. 125 3. SMP Definition 127 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects 128 of a shared mesh protection (SMP) mechanism. ITU-T Recommendation 129 G.873.3 [G873.3] defines the protection switching operation and 130 associated protocol for shared mesh protection (SMP) at the optical 131 data unit (ODU) layer. RFC 7412 provides requirements for any 132 mechanism that would be used to implement SMP in an MPLS-TP network. 134 The SMP mechanism is based on pre-computed protection transport 135 entities that are pre-configured into the network elements. Pre- 136 configuration here means pre-reserving resources for the 137 protecting LSPs without activating a particular protecting LSP 138 (e.g. in circuit networks, the cross-connects in the intermediate 139 nodes of the protecting LSP are not pre-established). Pre- 140 configuring but not activating the protecting LSP allows the 141 common link and node resources in a protecting LSP to be shared by 142 multiple working LSPs that are physically (i.e., link, node, SRLG, 143 etc.) disjoint. Protecting LSPs are activated in response to 144 failures of working LSPs or operator's commands by means of the 145 APS protocol that operates in the data plane. SMP is always 146 revertive. 148 SMP has a lot of similarity to SMR except that the activation in 149 case of SMR is achieved by control plan signaling during the 150 recovery operation while SMP is done by APS protocol in the data 151 plane. SMP has advantages with regard to the recovery speed 152 compared with SMR. 154 4. GMPLS Signaling Extension for SMP 156 Consider the following network topology: 158 A---B---C---D 159 \ / 160 E---F---G 161 / \ 162 H---I---J---K 164 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 165 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order 166 to achieve resource sharing during the signaling of these 167 protecting LSPs, they must have the same Tunnel Endpoint Address 168 (as part of their SESSION object). However, these addresses are 169 not the same in this example. Similar to SMR, a new LSP Protection 170 Type of the secondary LSP is defined as "Shared Mesh Protection" 171 (see PROTECTION object defined in [RFC4872]) to allow resource 172 sharing along nodes E, F, and G. In this case, the protecting LSPs 173 are not merged (which is useful since the paths diverge at G), but 174 the resources along E, F, G can be shared. 176 When a failure is detected on one of the working LSPs (say working 177 LSP [A,B,C,D]), the switching operation for the egress node (say 178 node A) will be triggered by an Signal Degrade (SD) or Signal Fail 179 (SF) on the working LSP. The egress node A will send a protection 180 switching request APS message (for example SF) to its adjacent 181 (downstream) intermediate node (say node E) to activate setting up 182 the corresponding protecting LSP. If the protection resource is 183 available, Node E will send a confirmation message to the egress node 184 A and forward the switching request APS message to its adjacent 185 (downstream) node (say node F). When the confirmation message is 186 received by node A and the protection resource is available, the 187 cross-connection on node A is established. At this time the traffic 188 is bridged to and selected from the protecting LSP at node A. The 189 node E will wait for the confirmation message from node F, which 190 triggers node E to set up the cross-connection for the protection 191 transport entity being activated. If the protection resource is not 192 available (due to failure or being used by higher priority 193 connections), the switching will not be successful; the intermediate 194 node may send a message to notify the end node, or keep trying until 195 the resource is available or the switching request is cancelled. If 196 the resource is in use by a lower priority protection entity, the 197 lower priority service will be removed and then the intermediate node 198 will follow the procedure as described for the case when the resource 199 is available. 201 The following subsections detail how shared mesh protection can be 202 implemented in an interoperable fashion using GMPLS RSVP-TE 203 extensions (see [RFC3473]). This includes: 205 (1) the ability to identify a "secondary protecting LSP" (hereby 206 called the "secondary LSP") used to recover another primary 207 working LSP (hereby called the "protected LSP") 209 (2) the ability to associate the secondary LSP with the protected 210 LSP 212 (3) the capability to include information about the resources 213 used by the protected LSP while instantiating the secondary LSP. 215 (4) the capability to instantiate during the provisioning phase 216 several secondary LSPs in an efficient manner. 218 (5) the capability to support activation of a secondary LSP after 219 failure occurrence via APS protocol in the data plane. 221 4.1. Identifiers 223 To simplify association operations, both LSPs (i.e., the protected 224 and the secondary LSPs) belong to the same session. Thus, the 225 SESSION object MUST be the same for both LSPs. The LSP ID, 226 however, MUST be different to distinguish between the protected 227 LSP carrying working traffic and the secondary LSP. 229 A new LSP Protection Type "Shared Mesh Protection" is introduced 230 to the LSP Flags of PROTECTION object (see [RFC4872]) to set up 231 the two LSPs. This LSP Protection Type value is applicable to 232 both uni- and bidirectional LSPs. 234 4.2. Signaling Primary LSPs 236 The PROTECTION object (see [RFC4872]) is included in the Path 237 message during signaling of the primary working LSPs, with the LSP 238 Protection Type value set to "Shared Mesh Protection". 240 Primary working LSPs are signaled by setting in the POTECTION 241 object the S bit to 0, the P bit to 0, the N bit to 1 and in the 242 ASSOCIATION object, the Association ID to the associated secondary 243 protecting LSP_ID. 245 Note: N bit is set to indicate that the protection switching 246 signaling is done via data plane. 248 4.3. Signaling Secondary LSPs 250 The PROTECTION object (see [RFC4872]) is included in the Path 251 message during signaling of the secondary protecting LSPs, with 252 the LSP Protection Type value set to "Shared Mesh Protection". 254 Secondary protecting LSPs are signaled by setting in the 255 PROTECTION object the S bit and the P bit to 1, the N bit to 1 and 256 in the ASSOCIATION object, the Association ID to the associated 257 primary working LSP_ID, which MUST be known before signaling of 258 the secondary LSP. Moreover, the Path message used to instantiate 259 the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE 260 object (see [RFC4872]) that further allows for recovery resource 261 sharing at each intermediate node along the secondary path. 263 With this setting, the resources for the secondary LSP SHOULD be 264 pre-reserved, but not committed at the data plane level, meaning 265 that the internals of the switch need not be established until 266 explicit action is taken to activate this LSP. Activation of a 267 secondary LSP and protection switching to the activated protecting 268 LSP is done using APS protocol in the data plane. 270 After protection switching completes the protecting LSP SHOULD be 271 signaled with the S bit set to 0 and O bit set to 1 in the 272 PROTECTION object. At this point, the link and node resources must 273 be allocated for this LSP that becomes a primary LSP (ready to 274 carry normal traffic). The formerly working LSP MAY be signaled 275 with the A bit set in the ADMIN_STATUS object (see [RFC3473]). 277 5. Updates to PROTECTION Object 279 GMPLS extension requirements for SMP introduce several updates to 280 the Protection Object (see [RFC4872]). 282 5.1. New Protection Type 284 A new LSP protection type "Shared Mesh Protection" is added in the 285 protection object. This LSP Protection Type value is applicable to 286 both uni- and bidirectional LSPs. 288 LSP (Protection Type) Flags 290 0x11 Shared Mesh Protection 292 5.2. Other Updates 294 N bit and O bit in the Protection object as defined in [RFC4872] 295 are also updated to include applicability to SMP. 297 Notification (N): 1 bit 299 When set to 1, this bit indicates that the control plane message 300 exchange is only used for notification during protection 301 switching. When set to 0 (default), it indicates that the control 302 plane message exchanges are used for protection-switching 303 purposes. The N bit is only applicable when the LSP Protection 304 Type Flag is set to either 0x04 (1:N Protection with Extra- 305 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 306 Bidirectional Protection), or 0x11 (Shared Mesh Protection). The 307 N bit MUST be set to 0 in any other case. 309 Operational (O): 1 bit 310 When set to 1, this bit indicates that the protecting LSP is 311 carrying the normal traffic after protection switching. The O bit 312 is only applicable when the P bit is set to 1, and the LSP 313 Protection Type Flag is set to either 0x04 (1:N Protection with 314 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 315 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 316 The O bit MUST be set to 0 in any other case. 318 6. Security Considerations 320 No further security considerations than [RFC4872]. 322 7. IANA Considerations 324 There are no IANA actions required. 326 8. References 328 8.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 334 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 335 Tunnels", RFC 3209, December 2001. 337 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 338 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 339 Engineering (RSVP-TE) Extensions", RFC 3473, January 340 2003. 342 [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, 343 "Generalized Multi-Protocol Label Switching (GMPLS) 344 Recovery Functional Specification", RFC 4426, March 345 2006. 347 [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 348 Ed., "RSVP-TE Extensions in support of End-to-End 349 Generalized Multi-Protocol Label Switching (GMPLS) 350 Recovery", RFC 4872, May 2007. 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017. 356 [G808.3] ITU-T, "Generic protection switching - Shared mesh 357 protection", G.808.3, October 2012. 359 8.2. Informative References 361 [G873.3] ITU-T, "Optical transport network - Shared mesh 362 protection", G.873.3, September 2017. 364 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., Mirsky, 365 G., "Requirements for MPLS Transport Profile (MPLS-TP) 366 Shared Mesh Protection", RFC 7412, December 2014. 368 Authors' Addresses 370 Jia He 371 Huawei Technologies Co.,Ltd. 372 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang 373 District, Shenzhen, China 375 Email: hejia@huawei.com 377 Italo Busi 378 Huawei 380 Email: italo.busi@huawei.com