idnits 2.17.1 draft-gandhi-ccamp-gmpls-restoration-lsp-04.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 : ---------------------------------------------------------------------------- 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 date (April 23, 2014) is 3649 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Rakesh Gandhi, Ed. 3 Internet-Draft Zafar Ali 4 Intended status: Informational Gabriele Maria Galimberti 5 Expires: October 25, 2014 Cisco Systems, Inc. 6 Xian Zhang 7 Huawei 8 April 23, 2014 10 RSVP-TE Signaling For GMPLS Restoration LSP 11 draft-gandhi-ccamp-gmpls-restoration-lsp-04 13 Abstract 15 In transport networks, there are requirements where Generalized 16 Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme 17 needs to employ restoration Label Switched Path (LSP) while keeping 18 resources for the working and/or protecting LSPs reserved in the 19 network after the failure. 21 This document reviews how the LSP association is to be provided using 22 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 23 signaling in the context of GMPLS end-to-end recovery when using 24 restoration LSP where failed LSP is not torn down. No new procedures 25 or mechanisms are defined by this document, and it is strictly 26 informative in nature. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Signaling Restoration LSP Association . . . . . . . . . . . . 5 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3473] extends 73 Multi-Protocol Label Switching (MPLS) to include support for 74 different switching technologies. These switching technologies 75 provide several protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N 76 and M:N). Resource Reservation Protocol - Traffic Engineering (RSVP- 77 TE) signaling has been extended to support various GMPLS recovery 78 schemes [RFC4872][RFC4873], to establish Label Switched Paths (LSPs), 79 typically for working LSP and protecting LSP. [RFC4427] Section 7 80 specifies various schemes for GMPLS recovery. 82 In GMPLS recovery schemes generally considered, restoration LSP is 83 signaled after the failure has been detected and notified on the 84 working LSP. In non-revertive recovery mode, working LSP is assumed 85 to be removed from the network before restoration LSP is signaled. 86 For revertive recovery mode, a restoration LSP is signaled while 87 working LSP and/or protecting LSP are not torn down in control plane 88 due to a failure. In transport networks, as working LSPs are 89 typically signaled over a nominal path, service providers would like 90 to keep resources associated with the working LSPs reserved. This is 91 to make sure that the service (working LSP) can use the nominal path 92 when the failure is repaired to provide deterministic behaviour and 93 guaranteed Service Level Agreement (SLA). Consequently, revertive 94 recovery mode is usually preferred by recovery schemes used in 95 transport networks. 97 As defined in [RFC4872] and being considered in this document, "fully 98 dynamic rerouting switches normal traffic to an alternate LSP that is 99 not even partially established only after the working LSP failure 100 occurs. The new alternate route is selected at the LSP head-end 101 node, it may reuse resources of the failed LSP at intermediate nodes 102 and may include additional intermediate nodes and/or links." 104 One example of the recovery scheme considered in this document is 1+R 105 recovery. The 1+R recovery is exemplified in Figure 1. In this 106 example, working LSP on path A-B-C-Z is pre-established. Typically 107 after a failure detection and notification on the working LSP, a 108 second LSP on path A-H-I-J-Z is established as a restoration LSP. 109 Unlike protection LSP, restoration LSP is signaled per need basis. 111 A --- B --- C --- Z 112 \ / 113 H --- I --- J 115 Figure 1: An example of 1+R recovery scheme 117 During failure switchover with 1+R recovery scheme, in general, 118 working LSP resources are not released and working and restoration 119 LSPs coexist in the network. Nonetheless, working and restoration 120 LSPs can share network resources. Typically when failure is 121 recovered on the working LSP, restoration LSP is no longer required 122 and torn down (e.g., revertive mode). 124 Another example of the recovery scheme considered in this document is 125 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 126 and/or the protecting LSP after the failure has been detected and 127 notified on the working LSP or the protecting LSP. The 1+1+R 128 recovery is exemplified in Figure 2. In this example, working LSP on 129 path A-B-C-Z and protecting LSP on path A-D-E-F-Z are 130 pre-established. After a failure detection and notification on a 131 working LSP or protecting LSP, a third LSP on path A-H-I-J-Z is 132 established as a restoration LSP. The restoration LSP in this case 133 provides protection against a second order failure. Restoration LSP 134 is torn down when the failure on the working or protecting LSP is 135 repaired. 137 D --- E --- F 138 / \ 139 A --- B --- C --- Z 140 \ / 141 H --- I --- J 143 Figure 2: An example of 1+1+R recovery scheme 145 [RFC4872] Section 14 defines PROTECTION object for GMPLS recovery 146 signaling. As defined, the PROTECTION object is used to identify 147 primary and secondary LSPs using S bit and protecting and working 148 LSPs using P bit. Furthermore, [RFC4872] defines the usage of 149 ASSOCIATION object for associating GMPLS working and protecting LSPs. 151 [RFC6689] Section 2.2 reviews the procedure for providing LSP 152 associations for GMPLS end-to-end recovery and covers the schemes 153 where the failed working LSP and/or protecting LSP are torn down. 155 This document reviews how the LSP association is to be provided for 156 GMPLS end-to-end recovery when using restoration LSP where working 157 and protecting LSP resources are kept reserved in the network after 158 the failure. 160 2. Signaling Restoration LSP Association 162 Where GMPLS end-to-end recovery scheme needs to employ restoration 163 LSP while keeping resources for the working and/or protecting LSPs 164 reserved in the network after the failure, restoration LSP is 165 signaled with ASSOCIATION object with the association ID set to the 166 LSP ID of the LSP it is restoring. For example, when a restoration 167 LSP is signaled for a working LSP, the ASSOCIATION object in the 168 restoration LSP contains the association ID set to the LSP ID of the 169 working LSP. Similarly, when a restoration LSP is signaled for a 170 protecting LSP, the ASSOCIATION object in the restoration LSP 171 contains the association ID set to the LSP ID of the protecting LSP. 173 The procedure for signaling the PROTECTION object is specified in 174 [RFC4872]. Specifically, restoration LSP being used as a working LSP 175 is signaled with P bit cleared and being used as a protecting LSP is 176 signaled with P bit set. 178 As discussed in Section 1 of this document, [RFC6689] Section 2.2 179 reviews the procedure for providing LSP associations for the GMPLS 180 end-to-end recovery scheme using restoration LSP where the failed 181 working LSP and/or protecting LSP are torn down. 183 3. IANA Considerations 185 This document makes no request for IANA action. 187 4. Security Considerations 189 This document reviews procedures defined in [RFC4872] and [RFC6689] 190 and does not define any new procedure. As such, no new security 191 considerations are introduced in this document. 193 5. Acknowledgement 195 The authors would like to thank George Swallow for the discussions on 196 the GMPLS restoration. 198 6. References 200 6.1. Normative References 202 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 203 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 204 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 206 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 207 Extensions in Support of End-to-End Generalized Multi- 208 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 209 2007. 211 [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 212 6689, July 2012. 214 6.2. Informative References 216 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., 217 "Generalized Multiprotocol Label Switching (GMPLS) 218 Recovery Functional Specification", RFC 4426, March 2006. 220 [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection 221 and Restoration) Terminology for Generalized 222 Multi-Protocol Label Switching, RFC 4427, March 2006. 224 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and Farrel, 225 A., "GMPLS Segment Recovery", RFC 4873, May 2007. 227 Authors' Addresses 229 Rakesh Gandhi (editor) 230 Cisco Systems, Inc. 232 Email: rgandhi@cisco.com 234 Zafar Ali 235 Cisco Systems, Inc. 237 Email: zali@cisco.com 239 Gabriele Maria Galimberti 240 Cisco Systems, Inc. 242 Email: ggalimbe@cisco.com 244 Xian Zhang 245 Huawei Technologies 246 Research Area F3-1B, 247 Huawei Industrial Base, 248 Shenzhen, 518129, China 250 Email: zhang.xian@huawei.com