idnits 2.17.1 draft-takacs-ccamp-revertive-ps-11.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 3 instances of too long lines in the document, the longest one being 3 characters 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 209: '... MUST be set to 0 when sent and MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (July 6, 2015) is 3216 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 237, but not defined == Unused Reference: 'IEEE-PBBTE' is defined on line 258, 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: 5 errors (**), 0 flaws (~~), 4 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: January 5, 2016 Ericsson 5 Z. Ali 6 Cisco Systems 7 July 6, 2015 9 RSVP-TE Recovery Extension for data plane initiated reversion, 10 and protection timer signaling 11 draft-takacs-ccamp-revertive-ps-11 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 January 2016. 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 values 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) and sub-network connection (SNC) protection options. 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, HOFF timers and SNC protection options 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, HOFF timer values and SNC 123 protection options. 125 2. Updated PROTECTION Object format and sub-TLVs 127 In [RFC4872] and [RFC4873] the PROTECTION object is specified to 128 support end-to-end and segment recovery. In order to ease addition 129 of protection attributes the PROTECTION Object is extended to carry 130 sub-TLVs. The new format updates the PROTECTION Object format of 131 C-Type TBD (suggested value 3). The updated format is depicted below. 132 IANA is requested to maintain the TLV space for the PROTECTION Object. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Length | Class-Num(37) | C-Type(TBD) | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |I|R| Reserved | Seg.Flags | Reserved | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | | 144 ~ sub-TLVs ~ 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 This document specifies three new sub-TLVs. 150 WTR - Wait-to-Restore time sub-TLV specifies the WTR time. If the 151 WTR field is 0 the protection switching operation mode is non- 152 revertive, otherwise revertive operation with the signalled timer (in 153 milliseconds) is requested. The value 0xffffffff is reserved, and 154 refers to a locally pre-configured WTR value. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type (1) (IANA) | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | WTR | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 HOFF - Hold-off time sub-TLV specifies the HOFF time. The values are 164 in milliseconds. The value 0xffffffff is reserved, and refers to a 165 locally pre-configured HOFF value. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type (2) (IANA) | Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | HOFF | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 SNC protection options sub-TLV specifies attributes of the SNC 176 protection. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type (3) (IANA) | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |mode | TCM-ID | Reserved | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Mode field (3 bits): The mode values are defined as follows: 188 SNC Protection Mode Value 189 ------------------- ----- 191 Reserved 0x0 193 SNC/N 0x1 194 (Sub Network Connection protection 195 with Non-intrusive monitoring) 197 SNC/I 0x2 198 (Sub Network Connection protection 199 with Inherent monitoring) 201 SNC/S 0x3 202 (Sub Network Connection protection 203 with Sub-layer monitoring) 205 TCM-ID: Tandem Connection Monitoring Identifier used. This is applicable 206 when SNC mode is set to SNC/S. 208 Reserved field (29 bits): This field is reserved for future use. It 209 MUST be set to 0 when sent and MUST be ignored when received. 211 In the case of end-to-end protection the PROTECTION Object is 212 inserted at the top level in the Path message, the WTR and HOFF 213 options sub-TLVs correspond to the end-to-end protection. In the 214 case when a segment of the LSP is to be protected and the WTR and 215 HOFF timers for the protection segment are 216 to be set by signaling, explicit segment recovery control has to be 217 used, i.e., the PROTECTION Object with the desired timers set must be 218 inserted in the appropriate Secondary Explicit Route Object (SERO). 220 3. Error handling 222 In the case a specific configuration of the timers is 223 not supported the corresponding error should be generated and sent 224 in the PathErr message: "Routing Problem/Unsupported WTR value" or 225 "Routing Problem/Unsupported HOFF value". 227 4. IANA Considerations 229 4.1. New TLV space for the PROTECTION object 231 A new TLV space needs to be opened and maintained for the PROTECTION 232 Object in the "Class Names, Class Numbers, and Class Types " 233 Registry. 235 4.3. New RSVP error sub-code 237 For Error Code = 24 "Routing Problem" (see [RFC3209]) the following 238 sub-codes are defined. 240 Sub-code Value 241 -------- ----- 243 Unsupported WTR value To be assigned by IANA 245 Unsupported HOFF value To be assigned by IANA 247 5. Security Considerations 249 This document introduces no new security issues. The considerations 250 in [RFC4872] and [RFC4873] apply. 252 6. References 254 [G.808.1] "Generic protection switching -- Linear trail and 255 subnetwork protection", ITU-T Recommendation G.808.1, 256 March 2006. 258 [IEEE-PBBTE] 259 "IEEE 802.1Qay Draft Standard for Provider Backbone 260 Bridging Traffic Engineering", work in progress. 262 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 263 Signaling Functional Description", RFC 3471, January 2003. 265 [RFC4426] "Generalized Multi-Protocol Label Switching (GMPLS) 266 Recovery Functional Specification", RFC 4426, March 2006. 268 [RFC4427] "Recovery (Protection and Restoration) Terminology for 269 Generalized Multi-Protocol Label Switching (GMPLS)", 270 RFC 4427, March 2006. 272 [RFC4872] "RSVP-TE Extensions in Support of End-to-End Generalized 273 Multi-Protocol Label Switching (GMPLS) Recovery", 274 RFC 4872, May 2007. 276 [RFC4873] "GMPLS Segment Recovery", RFC 4873, May 2007. 278 Authors' Addresses 280 Attila Takacs 281 Ericsson 282 Laborc u. 1. 283 Budapest, 1037 284 Hungary 286 Email: attila.takacs@ericsson.com 288 Francesco Fondelli 289 Ericsson 290 Via Negrone 291 Genova, 16153 292 Italy 294 Email: francesco.fondelli.ericsson.com 296 Benoit Tremblay 297 Ericsson 298 8400 Decarie. 299 Montreal, Quebec H4P 2N2 300 Canada 302 Email: benoit.c.tremblay@ericsson.com 304 Zafar Ali 305 Cisco Systems 306 Email: zali@cisco.com