idnits 2.17.1 draft-gandhi-ccamp-gmpls-restoration-lsp-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: ---------------------------------------------------------------------------- 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 (July 15, 2013) is 3931 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2205' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 213, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6689 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Rakesh Gandhi 3 Internet-Draft Zafar Ali 4 Intended status: BCP Gabriele Maria Galimberti 5 Expires: January 16, 2014 Cisco Systems, Inc. 6 July 15, 2013 8 RSVP-TE Extensions For Signaling GMPLS Restoration LSP 9 draft-gandhi-ccamp-gmpls-restoration-lsp-01 11 Abstract 13 In transport networks, there are requirements where Generalized 14 Multi-Protocol Label Switching (GMPLS) recovery scheme need to employ 15 restoration LSP while keeping resources for the working and/ or 16 protecting LSPs reserved in the network. Existing GMPLS recovery 17 procedures do not address these requirements. This document describes 18 best common practice for using RSVP-TE for GMPLS recovery with 19 restoration LSP. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 31, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions used in this document . . . . . . . . . . . . . . 4 57 3. Restoration LSP Signaling Extensions . . . . . . . . . . . . . 5 58 3.1. Signaling Procedure . . . . . . . . . . . . . . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative references . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to 70 include support for different switching technologies [RFC3471] 71 [RFC3473]. These switching technologies provide several protection 72 schemes [RFC4426][RFC4427] (e.g. 1+1, 1:N and M:N). GMPLS RSVP-TE 73 signaling has been extended to support various recovery schemes to 74 establish Label Switched Paths (LSPs) [RFC4872][RFC4873], typically 75 working LSP and protecting LSP. [RFC4427] Section 7 specifies various 76 schemes for GMPLS restoration. 78 In GMPLS recovery schemes currently considered, restoration LSP is 79 signaled after the failure has been detected and notified on the 80 working LSP. These schemes assume that working LSP is removed from 81 the network before restoration LSP is signaled. In transport 82 networks, as working LSPs are typically signaled over a nominal path, 83 there are many scenarios where service providers would like to keep 84 resources associated with the working LSPs reserved. This is to make 85 sure that the service (working LSP) can use the nominal path when the 86 failure is repaired. Consequently, in transport networks one can 87 employ a recovery scheme where a new restoration LSP is signaled 88 while working LSP and/ or protecting LSP are not torn down in control 89 plane due to a failure. Restoration LSP differs from a secondary LSP 90 in the way that secondary LSP does not reserve resources in the data 91 plane and is not able to carry any traffic until it is refreshed 92 whereas restoration LSP does reserve resources and is able to carry 93 traffic. 95 One example of the recovery scheme considered in this draft is 1+R 96 recovery. The 1+R recovery is exemplified in Figure 1. In this 97 example, working LSP on path A-B-C-Z is pre-established. Typically 98 after a failure detection and notification on the working LSP, a 99 second LSP on path A-H-I-J-Z is established as a restoration LSP. 100 Unlike protection LSP, restoration LSP is signaled on as needed 101 basis. 103 A --- B --- C --- Z 104 \ / 105 H --- I --- J 107 Figure 1: An example of 1+R recovery scheme 109 During failure with 1+R recovery scheme, in general, working LSP 110 resources are not released and working and restoration LSPs coexist 111 in the network. Nonetheless, working and restoration LSPs can share 112 network resources. Typically when failure is recovered on the working 113 LSP, restoration LSP is no longer required and torn down (e.g. 114 revertive mode). 116 Another example of the recovery scheme considered in this draft is 117 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP 118 and/ or the protecting LSP after the failure has been detected and 119 notified on the working LSP or the protecting LSP. The 1+1+R recovery 120 is exemplified in Figure 2. In this example, working LSP on path A-B- 121 C-Z and protecting LSP on path A-D-E-F-Z are pre-established. After a 122 failure detection and notification on a working LSP or protecting 123 LSP, a third LSP on path A-H-I-J-Z is established as a restoration 124 LSP. The restoration LSP in this case provides protection against a 125 second order failure. Restoration LSP is torn down when the failure 126 on the working or protecting LSP is repaired. 128 D --- E --- F 129 / \ 130 A --- B --- C --- Z 131 \ / 132 H --- I --- J 134 Figure 2: An example of 1+1+R recovery scheme 136 [RFC4872] Section 14 defines PROTECTION object for GMPLS recovery 137 signaling. The PROTECTION object is used to identify primary and 138 secondary LSPs using S bit and protecting and working LSPs using P 139 bit. However, the PROTECTION object does not have a way to identify 140 restoration LSP. [RFC4872] and [RFC6689] define the usage of 141 ASSOCIATION object for further associating GMPLS working and 142 protecting LSPs for the case where restoration LSP is signaled for 143 GMPLS recovery after the working or protecting LSPs are removed. 145 This draft outlines the best common practice for identifying the 146 restoration LSP for GMPLS recovery where working and protecting LSP 147 resources are kept reserved. 149 2. Conventions used in this document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Restoration LSP Signaling Extensions 157 3.1. Signaling Procedure 159 Where GMPLS recovery scheme need to employ restoration LSP while 160 keeping resources for the working and/ or protecting LSPs reserved in 161 the network, restoration LSP is signaled with ASSOCIATION object with 162 the association ID set to the LSP ID of the LSP it is restoring. For 163 example, when a restoration LSP is signaled for a working LSP, the 164 ASSOCIATION object in the restoration LSP contains the association ID 165 set to the LSP ID of the working LSP. Similarly, when a restoration 166 LSP is signaled for a protecting LSP, the ASSOCIATION object in the 167 restoration LSP contains the association ID set to the LSP ID of the 168 protecting LSP. 170 The procedure for signaling the PROTECTION object is specified in 171 [RFC4872][RFC4873] and does not change. Restoration LSP for the 172 working LSP is signaled with P bit cleared and restoration LSP for the 173 protecting LSP is signaled with P bit set. 175 When using a GMPLS recovery mode, where working LSP is destroyed, and 176 the restoration LSP is promoted to be the new working LSP, restoration 177 LSP RSVP Path message MUST be refreshed by using the 178 ASSOCIATION_OBJECT.LSP_ID from the destroyed working LSP 179 ASSOCIATION_OBJECT.LSP_ID. 181 When using a GMPLS recovery mode, where a protecting LSP is destroyed, 182 and the restoration LSP is promoted to be the new protecting LSP, 183 restoration LSP RSVP Path message MUST be refreshed by using the 184 ASSOCIATIN_OBJECT.LSP_ID from the destroyed protecting LSP 185 ASSOCIATION_OBJECT.LSP_ID. 187 4. IANA Considerations 189 This document makes no request for IANA action. 191 5. Security Considerations 193 This document introduces no additional security considerations. For a 194 general discussion on MPLS and GMPLS related security issues, see the 195 MPLS/GMPLS security framework [RFC5920]. In addition, the 196 considerations specified in [RFC4872] and [RFC4873] will apply. 198 6. Acknowledgement 199 The authors would like to thank George Swallow for the discussion on 200 the GMPLS restoration. 202 7. References 204 7.1. Normative references 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, March 1997. 209 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 210 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 211 Functional Specification", RFC 2205, September 1997. 213 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 214 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 215 Tunnels", RFC 3209, December 2001. 217 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 218 Switching (GMPLS) Signaling Functional Description", RFC 219 3471, January 2003. 221 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 222 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 223 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 225 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 226 Extensions in Support of End-to-End Generalized Multi- 227 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 228 2007. 230 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 231 "GMPLS Segment Recovery", RFC 4873, May 2007. 233 [RFC6689] Berger, L, "Usage of the RSVP ASSOCIATION Object", RFC 234 6689, July 2012. 236 7.2. Informative References 238 [RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors, 239 "Generalized Multiprotocol Label Switching (GMPLS) 240 Recovery Functional Specification", RFC 4426, March 2006. 242 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 243 (Protection and Restoration) Terminology for Generalized 244 Multi-Protocol Label Switching, RFC 4427, March 2006. 246 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 247 Networks", RFC 5920, July 2010. 249 Authors' Addresses 251 Rakesh Gandhi 252 Cisco Systems, Inc. 254 Email: rgandhi@cisco.com 256 Zafar Ali 257 Cisco Systems, Inc. 259 Email: zali@cisco.com 261 Gabriele Maria Galimberti 262 Cisco Systems, Inc. 264 Email: ggalimbe@cisco.com