idnits 2.17.1 draft-he-ccamp-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: ---------------------------------------------------------------------------- No issues found here. 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 (July 2, 2018) is 2118 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 170, but not defined == Missing Reference: 'B' is mentioned on line 170, but not defined == Missing Reference: 'C' is mentioned on line 170, but not defined == Missing Reference: 'D' is mentioned on line 170, but not defined == Missing Reference: 'H' is mentioned on line 158, but not defined == Missing Reference: 'I' is mentioned on line 157, but not defined == Missing Reference: 'J' is mentioned on line 157, but not defined == Missing Reference: 'K' is mentioned on line 158, but not defined == Missing Reference: 'E' is mentioned on line 158, but not defined == Missing Reference: 'F' is mentioned on line 158, but not defined == Missing Reference: 'G' is mentioned on line 158, but not defined Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group J. He 2 Internet Draft Huawei 3 Updates (if published): RFC 4872 4 Intended status: Standards Track 6 Expires: December 29, 2018 July 2, 2018 8 GMPLS Signaling Extensions for Shared Mesh Protection 9 draft-he-ccamp-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 December 29, 2018. 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. 54 This document updates RFC 4872 to provide the extensions to the 55 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 56 support the control of the shared mesh protection. 58 Table of Contents 60 1. Introduction ................................................2 61 2. Conventions used in this document............................3 62 3. SMP Definition ..............................................3 63 4. GMPLS Signaling Extension for SMP............................4 64 4.1. Identifiers ............................................5 65 4.2. Signaling Primary LSPs..................................6 66 4.3. Signaling Secondary LSPs................................6 67 5. Updates to PROTECTION Object.................................7 68 5.1. New Protection Type.....................................7 69 5.2. Other Updates ..........................................7 70 6. Security Considerations......................................8 71 7. IANA Considerations .........................................8 72 8. References ..................................................8 73 8.1. Normative References....................................8 74 8.2. Informative References..................................9 76 1. Introduction 78 RFC 4872 [RFC4872] defines extension of RSVP-TE to support shared 79 mesh restoration (SMR) mechanism. Shared mesh restoration can be 80 seen as a particular case of pre-planned LSP rerouting that 81 reduces the recovery resource requirements by allowing multiple 82 protecting LSPs to share common link and node resources. The 83 recovery resources for the protecting LSPs are pre-reserved during 84 the provisioning phase, and an explicit restoration signaling is 85 required to activate (i.e., commit resource allocation at the data 86 plane) a specific protecting LSP instantiated during the 87 provisioning phase. 89 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects 90 of a shared mesh protection (SMP) mechanism. ITU-T Recommendation 91 G.873.3 [G873.3] defines the protection switching operation and 92 associated protocol for shared mesh protection (SMP) at the optical 93 data unit (ODU) layer. 95 SMP differs from SMR in the activation/protection switching 96 operation. The former activates a protecting LSP via the automatic 97 protection switching (APS) protocol in the data plane when the 98 working LSP fails, while the latter via the control plane 99 signaling. It is therefore necessary to distinguish SMP from SMR 100 during provisioning so that each node involved behaves 101 appropriately in the recovery phase when activation of a 102 protecting LSP is done. 104 This document updates RFC 4872 to provide the extensions to the 105 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 106 support the control of the shared mesh protection. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 111 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 112 "MAY", and "OPTIONAL" in this document are to be interpreted as 113 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 114 appear in all capitals, as shown here. 116 In addition, the reader is assumed to be familiar with the 117 terminology used in [RFC4872] and [RFC4426]. 119 3. SMP Definition 121 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects 122 of a shared mesh protection (SMP) mechanism. ITU-T Recommendation 123 G.873.3 [G873.3] defines the protection switching operation and 124 associated protocol for shared mesh protection (SMP) at the optical 125 data unit (ODU) layer. 127 The SMP mechanism is based on pre-computed protection transport 128 entities that are pre-configured into the network elements. Pre- 129 configuration here means pre-reserving resources for the 130 protecting LSPs without activating a particular protecting LSP 131 (e.g. in circuit networks, the cross-connects in the intermediate 132 nodes of the protecting LSP are not pre-established). Pre- 133 configuring but not activating the protecting LSP allows the 134 common link and node resources in a protecting LSP to be shared by 135 multiple working LSPs that are physically (i.e., link, node, SRLG, 136 etc.) disjoint. Protecting LSPs are activated in response to 137 failures of working LSPs or operator's commands by means of the 138 APS protocol that operates in the data plane. SMP is always 139 revertive. 141 SMP has a lot of similarity to SMR except that the activation in 142 case of SMR is achieved by control plan signaling during the 143 recovery operation while SMP is done by APS protocol in the data 144 plane. SMP has advantages with regard to the recovery speed 145 compared with SMR. 147 4. GMPLS Signaling Extension for SMP 149 Consider the following network topology: 151 A---B---C---D 152 \ / 153 E---F---G 154 / \ 155 H---I---J---K 157 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 158 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order 159 to achieve resource sharing during the signaling of these 160 protecting LSPs, they must have the same Tunnel Endpoint Address 161 (as part of their SESSION object). However, these addresses are 162 not the same in this example. Similar to SMR, a new LSP Protection 163 Type of the secondary LSP is defined as "Shared Mesh Protection" 164 (see PROTECTION object defined in [RFC4872]) to allow resource 165 sharing along nodes E, F, and G. In this case, the protecting LSPs 166 are not merged (which is useful since the paths diverge at G), but 167 the resources along E, F, G can be shared. 169 When a failure is detected on one of the working LSPs (say working 170 LSP [A,B,C,D]), the switching operation for the egress node (say 171 node A) will be triggered by an Signal Degrade (SD) or Signal Fail 172 (SF) on the working LSP. The egress node A will send a protection 173 switching request APS message (for example SF) to its adjacent 174 (downstream) intermediate node (say node E) to activate setting up 175 the corresponding protecting LSP. If the protection resource is 176 available, Node E will send a confirmation message to the egress node 177 A and forward the switching request APS message to its adjacent 178 (downstream) node (say node F). When the confirmation message is 179 received by node A and the protection resource is available, the 180 cross-connection on node A is established. At this time the traffic 181 is bridged to and selected from the protecting LSP at node A. The 182 node E will wait for the confirmation message from node F, which 183 triggers node E to set up the cross-connection for the protection 184 transport entity being activated. If the protection resource is not 185 available (due to failure or being used by higher priority 186 connections), the switching will not be successful; the intermediate 187 node may send a message to notify the end node, or keep trying until 188 the resource is available or the switching request is cancelled. If 189 the resource is in use by a lower priority protection entity, the 190 lower priority service will be removed and then the intermediate node 191 will follow the procedure as described for the case when the resource 192 is available. 194 The following subsections detail how shared mesh protection can be 195 implemented in an interoperable fashion using GMPLS RSVP-TE 196 extensions (see [RFC3473]). This includes: 198 (1) the ability to identify a "secondary protecting LSP" (hereby 199 called the "secondary LSP") used to recover another primary 200 working LSP (hereby called the "protected LSP") 202 (2) the ability to associate the secondary LSP with the protected 203 LSP 205 (3) the capability to include information about the resources 206 used by the protected LSP while instantiating the secondary LSP. 208 (4) the capability to instantiate during the provisioning phase 209 several secondary LSPs in an efficient manner. 211 (5) the capability to support activation of a secondary LSP after 212 failure occurrence via APS protocol in the data plane. 214 4.1. Identifiers 216 To simplify association operations, both LSPs (i.e., the protected 217 and the secondary LSPs) belong to the same session. Thus, the 218 SESSION object MUST be the same for both LSPs. The LSP ID, 219 however, MUST be different to distinguish between the protected 220 LSP carrying working traffic and the secondary LSP. 222 A new LSP Protection Type "Shared Mesh Protection" is introduced 223 to the LSP Flags of PROTECTION object (see [RFC4872]) to set up 224 the two LSPs. This LSP Protection Type value is applicable to 225 both uni- and bidirectional LSPs. 227 4.2. Signaling Primary LSPs 229 The PROTECTION object (see [RFC4872]) is included in the Path 230 message during signaling of the primary working LSPs, with the LSP 231 Protection Type value set to "Shared Mesh Protection". 233 Primary working LSPs are signaled by setting in the POTECTION 234 object the S bit to 0, the P bit to 0, the N bit to 1 and in the 235 ASSOCIATION object, the Association ID to the associated secondary 236 protecting LSP_ID. 238 Note: N bit is set to indicate that the protection switching 239 signaling is done via data plane. 241 4.3. Signaling Secondary LSPs 243 The PROTECTION object (see [RFC4872]) is included in the Path 244 message during signaling of the secondary protecting LSPs, with 245 the LSP Protection Type value set to "Shared Mesh Protection". 247 Secondary protecting LSPs are signaled by setting in the 248 PROTECTION object the S bit and the P bit to 1, the N bit to 1 and 249 in the ASSOCIATION object, the Association ID to the associated 250 primary working LSP_ID, which MUST be known before signaling of 251 the secondary LSP. Moreover, the Path message used to instantiate 252 the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE 253 object (see [RFC4872]) that further allows for recovery resource 254 sharing at each intermediate node along the secondary path. 256 With this setting, the resources for the secondary LSP SHOULD be 257 pre-reserved, but not committed at the data plane level, meaning 258 that the internals of the switch need not be established until 259 explicit action is taken to activate this LSP. Activation of a 260 secondary LSP and protection switching to the activated protecting 261 LSP is done using APS protocol in the data plane. 263 After protection switching completes the protecting LSP SHOULD be 264 signaled with the S bit set to 0 and O bit set to 1 in the 265 PROTECTION object. At this point, the link and node resources must 266 be allocated for this LSP that becomes a primary LSP (ready to 267 carry normal traffic). The formerly working LSP MAY be signaled 268 with the A bit set in the ADMIN_STATUS object (see [RFC3473]). 270 5. Updates to PROTECTION Object 272 GMPLS extension requirements for SMP introduce several updates to 273 the Protection Object (see [RFC4872]). 275 5.1. New Protection Type 277 A new LSP protection type "Shared Mesh Protection" is added in the 278 protection object. This LSP Protection Type value is applicable to 279 both uni- and bidirectional LSPs. 281 LSP (Protection Type) Flags 283 0x11 Shared Mesh Protection 285 5.2. Other Updates 287 N bit and O bit in the Protection object as defined in [RFC4872] 288 are also updated to include applicability to SMP. 290 Notification (N): 1 bit 292 When set to 1, this bit indicates that the control plane message 293 exchange is only used for notification during protection 294 switching. When set to 0 (default), it indicates that the control 295 plane message exchanges are used for protection-switching 296 purposes. The N bit is only applicable when the LSP Protection 297 Type Flag is set to either 0x04 (1:N Protection with Extra- 298 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 299 Bidirectional Protection), or 0x11 (Shared Mesh Protection). The 300 N bit MUST be set to 0 in any other case. 302 Operational (O): 1 bit 304 When set to 1, this bit indicates that the protecting LSP is 305 carrying the normal traffic after protection switching. The O bit 306 is only applicable when the P bit is set to 1, and the LSP 307 Protection Type Flag is set to either 0x04 (1:N Protection with 308 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 309 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 310 The O bit MUST be set to 0 in any other case. 312 6. Security Considerations 314 No further security considerations than [RFC4872]. 316 7. IANA Considerations 318 There are no IANA actions required. 320 8. References 322 8.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 328 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 329 Tunnels", RFC 3209, December 2001. 331 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 332 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 333 Engineering (RSVP-TE) Extensions", RFC 3473, January 334 2003. 336 [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, 337 "Generalized Multi-Protocol Label Switching (GMPLS) 338 Recovery Functional Specification", RFC 4426, March 339 2006. 341 [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 342 Ed., "RSVP-TE Extensions in support of End-to-End 343 Generalized Multi-Protocol Label Switching (GMPLS) 344 Recovery", RFC 4872, May 2007. 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017. 350 [G808.3] ITU-T, "Generic protection switching - Shared mesh 351 protection", G.808.3, October 2012. 353 8.2. Informative References 355 [G873.3] ITU-T, "Optical transport network - Shared mesh 356 protection", G.873.3, September 2017. 358 Authors' Addresses 360 Jia He 361 Huawei Technologies Co.,Ltd. 362 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang 363 District, Shenzhen, China 365 Email: hejia@huawei.com