idnits 2.17.1 draft-takacs-ccamp-revertive-ps-10.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 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4872], [RFC4873]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3723 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: 'RFC3209' is mentioned on line 200, but not defined == Unused Reference: 'IEEE-PBBTE' is defined on line 223, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.808.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-PBBTE' ** Downref: Normative reference to an Informational RFC: RFC 4427 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Takacs 2 Internet-Draft F. Fondelli 3 Intended status: Standards Track B. Tremblay 4 Expires: August 13, 2014 Ericsson 5 Z. Ali 6 Cisco Systems 7 February 14, 2014 9 RSVP-TE Recovery Extension for data plane initiated reversion, 10 and protection timer signaling 11 draft-takacs-ccamp-revertive-ps-10 13 Abstract 15 RSVP-TE recovery extensions are specified in [RFC4872] and 16 [RFC4873]. Currently recovery signaling does not support the 17 request for revertive protection and recovery timers values. This 18 document extends the PROTECTION Object format allowing sub-TLVs, and 19 defines two sub-TLVs to carry wait-to-restore and hold-off 20 intervals. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in 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 This Internet-Draft will expire on August 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Updated PROTECTION Object format and sub-TLVs . . . . . . . . 6 64 3. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 Generalized MPLS (GMPLS) extends MPLS to include support for 73 different switching technologies [RFC3471]. These switching 74 technologies provide several protection schemes [RFC4426][RFC4427] 75 (e.g. 1+1, 1:N, M:N). Many characteristics of those protection 76 schemes are common regardless of the switching technology (e.g. TDM, 77 LSC, etc). GMPLS RSVP-TE signaling has been extended to support the 78 various protection schemes and establish Label Switched 79 Paths (LSPs) configuring its specific protection characteristics 80 [RFC4426][RFC4872]. 82 Currently RSVP-TE extensions do not address the configuration of 83 protection switching timers. It also does not provide information on 84 the protection switching operation mode (i.e., revertive or non- 85 revertive). 87 The Hold-off time (HOFF) is defined as the time between the reporting 88 of signal fail or degrade, and the initialization of the recovery 89 switching operation [RFC4427]. This timer is useful to limit the 90 number of switch actions when multiple layers of recovery are being 91 used, or in case of 1+1 unidirectional protection scheme [G.808.1] to 92 prevent too early switching due to the differential delay 93 between the short and long path. 95 The Wait-to-Restore time (WTR) is defined as a period of time that 96 must elapse after a recovered fault before an LSP can be used again 97 to transport the normal traffic and/or to select the normal traffic 98 from the LSP [RFC4427]. The WTR time is fundamental in revertive 99 mode of operation, to prevent frequent operation of the protection 100 switch due to an intermittent defect [G.808.1]. 102 Reversion refers to the process of moving normal traffic back to the 103 original working LSP after the failure is cleared and the path is 104 repaired [RFC4426][RFC4427][RFC4872]. In transport networks 105 reversion is desirable since the protection path may not be optimal 106 from a routing and resource consumption point of view, additionally, 107 moving traffic back to the working LSP allows the protection 108 resources to be used to protect other LSPs. 110 WTR and HOFF timers must be accurately 111 configured at both ends of the LSP. Operators may need to tune WTR 112 and HOFF timers on a per LSP basis to ensure best protection 113 switching performance (e.g., account for differential delays between 114 worker and protection paths). Currently these values are either pre- 115 configured to a default value (and so may be suboptimal for some of 116 the LSPs) or need to be manually set/tuned after the connections have 117 been established. Since these parameters are important for recovery 118 in transport networks, it is desirable that GMPLS RSVP-TE protection 119 signaling carries the necessary information. 121 This document extends the PROTECTION Object format allowing sub-TLVs, 122 and defines three sub-TLVs to carry WTR and HOFF timer values. 124 2. Updated PROTECTION Object format and sub-TLVs 126 In [RFC4872] and [RFC4873] the PROTECTION object is specified to 127 support end-to-end and segment recovery. In order to ease addition 128 of protection attributes the PROTECTION Object is extended to carry 129 sub-TLVs. The new format updates the PROTECTION Object format of 130 C-Type TBD (suggested value 3). The updated format is depicted below. 131 IANA is requested to maintain the TLV space for the PROTECTION Object. 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Length | Class-Num(37) | C-Type(TBD) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |I|R| Reserved | Seg.Flags | Reserved | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 ~ sub-TLVs ~ 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 This document specifies three new sub-TLVs. 149 WTR - Wait-to-Restore time sub-TLV specifies the WTR time. If the 150 WTR field is 0 the protection switching operation mode is non- 151 revertive, otherwise revertive operation with the signalled timer (in 152 milliseconds) is requested. The value 0xffffffff is reserved, and 153 refers to a locally pre-configured WTR value. 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type (1) (IANA) | Length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | WTR | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 HOFF - Hold-off time sub-TLV specifies the HOFF time. The values are 163 in milliseconds. The value 0xffffffff is reserved, and refers to a 164 locally pre-configured HOFF value. 166 0 1 2 3 167 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type (2) (IANA) | Length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | HOFF | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 In the case of end-to-end protection the PROTECTION Object is 175 inserted at the top level in the Path message, the WTR and HOFF 176 options sub-TLVs correspond to the end-to-end protection. In the 177 case when a segment of the LSP is to be protected and the WTR and 178 HOFF timers for the protection segment are 179 to be set by signaling, explicit segment recovery control has to be 180 used, i.e., the PROTECTION Object with the desired timers set must be 181 inserted in the appropriate Secondary Explicit Route Object (SERO). 183 3. Error handling 185 In the case a specific configuration of the timers is 186 not supported the corresponding error should be generated and sent 187 in the PathErr message: "Routing Problem/Unsupported WTR value" or 188 "Routing Problem/Unsupported HOFF value". 190 4. IANA Considerations 192 4.1. New TLV space for the PROTECTION object 194 A new TLV space needs to be opened and maintained for the PROTECTION 195 Object in the "Class Names, Class Numbers, and Class Types " 196 Registry. 198 4.3. New RSVP error sub-code 200 For Error Code = 24 "Routing Problem" (see [RFC3209]) the following 201 sub-codes are defined. 203 Sub-code Value 204 -------- ----- 206 Unsupported WTR value To be assigned by IANA 207 (suggest value: 80) 209 Unsupported HOFF value To be assigned by IANA 210 (suggest value: 81) 212 5. Security Considerations 214 This document introduces no new security issues. The considerations 215 in [RFC4872] and [RFC4873] apply. 217 6. References 219 [G.808.1] "Generic protection switching -- Linear trail and 220 subnetwork protection", ITU-T Recommendation G.808.1, 221 March 2006. 223 [IEEE-PBBTE] 224 "IEEE 802.1Qay Draft Standard for Provider Backbone 225 Bridging Traffic Engineering", work in progress. 227 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 228 Signaling Functional Description", RFC 3471, January 2003. 230 [RFC4426] "Generalized Multi-Protocol Label Switching (GMPLS) 231 Recovery Functional Specification", RFC 4426, March 2006. 233 [RFC4427] "Recovery (Protection and Restoration) Terminology for 234 Generalized Multi-Protocol Label Switching (GMPLS)", 235 RFC 4427, March 2006. 237 [RFC4872] "RSVP-TE Extensions in Support of End-to-End Generalized 238 Multi-Protocol Label Switching (GMPLS) Recovery", 239 RFC 4872, May 2007. 241 [RFC4873] "GMPLS Segment Recovery", RFC 4873, May 2007. 243 Authors' Addresses 245 Attila Takacs 246 Ericsson 247 Laborc u. 1. 248 Budapest, 1037 249 Hungary 251 Email: attila.takacs@ericsson.com 253 Francesco Fondelli 254 Ericsson 255 Via Negrone 256 Genova, 16153 257 Italy 259 Email: francesco.fondelli.ericsson.com 261 Benoit Tremblay 262 Ericsson 263 8400 Decarie. 264 Montreal, Quebec H4P 2N2 265 Canada 267 Email: benoit.c.tremblay@ericsson.com 269 Zafar Ali 270 Cisco Systems 271 Email: zali@cisco.com