idnits 2.17.1 draft-dong-teas-inter-layer-abstract-error-report-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a failure occurs in the server layer network, and the server layer protection/restoration could recover the failure by setting up a new server layer path, the ingress client layer edge node of the end-to-end LSP does not need to trigger client layer protection mechanisms, but it SHOULD be aware of the event happened on the end-to-end path. The server layer node which recovered the failure MUST send a PathErr message which carries the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set. The error node address field MUST be set to zero to indicate this is not to identify an error of a particular node. The error code SHOULD be "Reroute (34)" and the Error Value SHOULD be "reroute accomplished". The upstream server layer nodes SHOULD propagate the received PathErr message to the previous hop, until the PathErr message reaches the client layer edge node. Upon receipt of this PathErr message, the client layer edge node SHOULD not trigger any client layer protection/restoration mechanism, as it is indicated in the message that the reroute is accomplished. In this case, the client layer edge node and the server layer edge node may also exchange the characteristics of the updated server layer path, details of which is outside the scope of this document. -- The document date (July 4, 2015) is 3211 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) == Unused Reference: 'RFC2205' is defined on line 323, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft X. Wei 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 5, 2016 V. Lopez 6 O. Gonzalez de Dios 7 Telefonica I+D 8 July 4, 2015 10 RSVP-TE Extensions for Abstract Error Report in Multi-Layer Traffic 11 Engineered Networks 12 draft-dong-teas-inter-layer-abstract-error-report-01 14 Abstract 16 This document provides extensions to the Resource ReserVation 17 Protocol-Traffic Engineering (RSVP-TE) to support the report of 18 abstract error information across the multi-layer network boundary 19 using Generalized Multiprotocol Label Switching (GMPLS) User Network 20 Interface (UNI). Such abstract error information is useful for 21 efficient protection and restoration coordination of multi-layer 22 Label Switched Paths (LSPs), and is helpful to the fault localization 23 and diagnostics in the multi-layer networks. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 5, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. RSVP-TE Extensions for Abstract Error Report . . . . . . . . 4 67 3. Operation Procedures . . . . . . . . . . . . . . . . . . . . 5 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. IF_ID ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . . 7 70 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 7.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 In multi-layer Traffic Engineered (TE) networks, end-to-end Traffic 81 Engineered (TE) LSPs are established across more than one network 82 layers. If some failure occurs in the network, according to the type 83 and location of the failure, different recovery mechanisms could be 84 used to provide efficient inter-layer protection and restoration for 85 the end-to-end TE LSPs. Such error information is also helpful for 86 fault localization, diagnostics and troubleshooting in the multi- 87 layer networks. However, in multi-layer networks, the exchange of 88 detailed error information across the layer boundary should be 89 avoided due to the concerns about confidentiality, scalability and 90 stability. This document defines RSVP-TE extensions for the abstract 91 error information report for inter-layer TE LSPs, which can meet the 92 requirement of efficient protection and fault localization, and the 93 constraints on information exchange across the multi-layer network 94 boundaries are not violated . 96 In multi-layer TE networks, several protection mechanisms could be 97 deployed to protect the end-to-end inter-layer LSPs, such as local 98 protection in the server layer, end-to-end protection/restoration in 99 the server layer, and end-to-end protection/restoration initiated in 100 the client layer. In order to achieve multi-layer protection with 101 efficient utilization of network resources, appropriate protection 102 mechanism should be invoked according to the type and location of the 103 failure. 105 Client Client 106 Network +----------------------------------+ Network 107 +---------+ | | +---------+ 108 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 109 | | | | | | | | | | | |UNI-1| | | | 110 | -+ EN1+-+-----+--+ CN1 +----+ CN3 +----+ CN4 +---+-----+-+ EN3+- | 111 | | | | +--+--| | | | | |---+-----+-| | | 112 | +----+ | | | +--+--+ +--+--+ +--+--+ |UNI-2| +----+ | 113 | | | | | | | | | | 114 +---------+ | | | | | | +---------+ 115 | | | | | | 116 +---------+ | | | | | | +---------+ 117 | | | | +--+--+ | +--+--+ | | | 118 | +----+ | | | | | +-------+ | | | +----+ | 119 | | +-+--+ | | CN2 +---------------+ CN5 | | | | | | 120 | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | 121 | | | | | +-----+ +-----+ | | | | | 122 | +----+ | | | | +----+ | 123 | | +----------------------------------+ | | 124 +---------+ Core Network +---------+ 125 Client Client 126 Network Network 127 Legend: EN - Edge Node 128 CN - Core Node 130 Figure 1: Multi-layer Network Topology 132 Figure 1 shows a multi-layer network topology which is modified based 133 on the overlay reference model in [RFC4208] to describe the different 134 failure and protection scenarios of an inter-layer LSP. Assume in 135 normal state there is an end-to-end LSP from EN2 to EN3 which 136 traverses the path: EN2-CN1-CN3-CN4-EN3. There are several failure 137 cases in which different protection and report behavior should be 138 performed. 140 o If a failure occurs in the server layer link CN3-CN4, and the 141 server layer protection/restoration could recover this by setting 142 up a new path between CN3 and CN4, then the end-to-end LSP between 143 EN2 and EN3 will traverse a new path: EN2-CN1-CN3-CN5-CN4-EN3. In 144 this case the client layer protection or restoration is not 145 needed, while the client layer still SHOULD be informed of the 146 failure and restoration happened in the server layer for fault 147 localization and diagnostics, and the characteristics of the new 148 server layer path may be changed and need to be updated to the 149 client layer. 151 o If a failure occurs in the server layer link CN3-CN4, and the 152 server layer protection/restoration mechanism cannot recover this 153 failure, then the client layer MUST be informed of this situation 154 to trigger the client layer protection/restoration mechanism. 156 o If the UNI interface UNI-1 between the edge node EN3 and the 157 server layer node CN4 fails, it may be restored efficiently by 158 using a stand-by UNI interface UNI-2 along with the existing 159 resources in the server layer. Such restoration may be initiated 160 either by the ingress edge node of the end-to-end LSP (EN2 in 161 figure 1), or by the nodes adjacent to the failed UNI link (CN4 162 and EN3). In both cases the client layer SHOULD be informed of 163 the failure and recovery happened on the UNI link of the end-to- 164 end LSP. 166 o If a failure occurs on the UNI link between EN3 and CN4, and 167 stand-by UNI interface recovery is not available, the client layer 168 node EN2 SHOULD be informed of this failure and trigger the client 169 layer protection/restoration mechanism. 171 In summary, necessary information about the failure happens in the 172 end-to-end inter-layer LSPs SHOULD be exchanged between different 173 network layers for appropriate protection/restoration, fault 174 localization and diagnostics. The confidentiality concerns in multi- 175 layer networks SHOULD also be considered. 177 2. RSVP-TE Extensions for Abstract Error Report 179 This section specifies the RSVP-TE extensions for abstracted error 180 information report on the end-to-end inter-layer TE LSPs. 182 In the IF_ID ERROR_SPEC Object defined in [RFC3473], one new 183 Interface_ID TLV "ABSTRACT_LOC" is defined to indicate the abstracted 184 failure location: 186 Type Length Format Description 187 ------------------------------------- 188 TBD 4 See below ABSTRACT_LOC 189 The value field of the "ABSTRACT_LOC" TLV is 32 bit flags numbered 190 from the most significant bit as bit zero. Two flags are defined in 191 this document: 193 o Server Layer Internal (I): When set, it indicates the failure 194 happens inside the server layer. 196 o UNI (U): When set, it indicates the failure happens on an UNI 197 interface between the server layer and the client layer. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Reserved |U|I| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Besides, two new Error Values are defined for Error Code 34 "Reroute" 206 in [RFC5710] : 208 o Error Value = TBD1, reroute accomplished 210 o Error Value = TBD2, upper layer reroute required 212 3. Operation Procedures 214 This section describes the procedures of exchanging the abstracted 215 error report between interconnected server and client network layers. 217 When a failure occurs in the server layer network, and the server 218 layer protection/restoration could recover the failure by setting up 219 a new server layer path, the ingress client layer edge node of the 220 end-to-end LSP does not need to trigger client layer protection 221 mechanisms, but it SHOULD be aware of the event happened on the end- 222 to-end path. The server layer node which recovered the failure MUST 223 send a PathErr message which carries the ABSTRACT_LOC TLV in the 224 IF_ID ERROR_SPEC Object, in which the "I" bit is set. The error node 225 address field MUST be set to zero to indicate this is not to identify 226 an error of a particular node. The error code SHOULD be "Reroute 227 (34)" and the Error Value SHOULD be "reroute accomplished". The 228 upstream server layer nodes SHOULD propagate the received PathErr 229 message to the previous hop, until the PathErr message reaches the 230 client layer edge node. Upon receipt of this PathErr message, the 231 client layer edge node SHOULD not trigger any client layer 232 protection/restoration mechanism, as it is indicated in the message 233 that the reroute is accomplished. In this case, the client layer 234 edge node and the server layer edge node may also exchange the 235 characteristics of the updated server layer path, details of which is 236 outside the scope of this document. 238 When a failure occurs in the server layer network, and the server 239 layer protection/restoration mechanism cannot recover the failure, 240 the server layer edge node which connects to the ingress client layer 241 edge node MUST send a PathErr message which carries the ABSTRACT_LOC 242 TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set. The 243 error node address field MUST be set to zero to indicate this is not 244 to identify an error of a particular node. The Error Code SHOULD be 245 "Reroute (34)" and the Error Value SHOULD be "upper layer reroute 246 required". Upon receipt of this PathErr message, the ingress client 247 layer edge node SHOULD trigger the client layer protection/ 248 restoration mechanism to recover the end-to-end LSP. 250 When the UNI interface which connects the remote server layer edge 251 and the remote client layer edge fails, and is recovered by a stand- 252 by UNI interface, the server layer edge node which connects to the 253 recovered UNI interface MUST send a PathErr message which carries the 254 ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" bit 255 is set. The error node address field MUST be set to zero to indicate 256 this is not to identify an error of a particular node. The Error 257 Code SHOULD be "Reroute (34)", the Error Value SHOULD be "reroute 258 accomplished". The upstream server layer nodes SHOULD propagate the 259 received PathErr message to the previous hop, until the PathErr 260 message reaches the client layer edge node. Upon receipt of this 261 PathErr message, the ingress client layer edge node may send a new 262 Path message to refresh the end-to-end inter-layer LSP. 264 When a failure happens on the UNI link between the remote server 265 layer and client layer edge nodes, and the stand-by UNI interface 266 recovery is not available, the server layer edge node which connects 267 to the failed UNI interface MUST send a PathErr message which carries 268 the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" 269 bit is set. The error node address field MUST be set to zero to 270 indicate this is not to identify an error of a particular node. The 271 Error Code SHOULD be "Reroute (34)" and the Error Value SHOULD be 272 "upper layer reroute required". The upstream server layer nodes 273 SHOULD propagate the received PathErr message to the previous hop, 274 until the PathErr message reaches the client layer edge node. The 275 client layer edge node SHOULD trigger the client layer protection/ 276 restoration mechanism based on the received PathErr message. 278 4. IANA Considerations 280 IANA is requested to administer the assignment of new values defined 281 in this document and summarized in this section. 283 4.1. IF_ID ERROR_SPEC TLVs 285 IANA maintains a registry called "GMPLS Signaling Parameters" with a 286 sub-registry called "Interface_ID Types". 288 IANA is requested to assign a new TLV type for the "ABSTRACT_LOC" TLV 289 defined in this document. 291 4.2. RSVP Error Value Sub-codes 293 IANA maintains a registry called "Resource Reservation Protocol 294 (RSVP) Parameters" with a sub-registry called "Error Codes and 295 Globally-Defined Error Value Sub-Codes". 297 IANA is requested to assign two new Error Value sub-codes for the 298 "Reroute" Error Code: 300 Value | Description | Reference 301 -----------+--------------------------------+-------------- 302 TBA | reroute accomplished | this document 303 TBA | upper layer reroute required | this document 305 5. Security Considerations 307 This document does not introduce any new security issues above those 308 identified in [RFC3209] and [RFC3473]. For a more comprehensive 309 discussion of GMPLS security and attack mitigation techniques, please 310 see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 312 6. Acknowledgements 314 TBD 316 7. References 318 7.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 324 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 325 Functional Specification", RFC 2205, September 1997. 327 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 328 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 2003. 335 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 336 "Generalized Multiprotocol Label Switching (GMPLS) User- 337 Network Interface (UNI): Resource ReserVation Protocol- 338 Traffic Engineering (RSVP-TE) Support for the Overlay 339 Model", RFC 4208, October 2005. 341 [RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr 342 Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, 343 January 2010. 345 7.2. Informative References 347 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 348 Networks", RFC 5920, July 2010. 350 Authors' Addresses 352 Jie Dong 353 Huawei Technologies 354 Huawei Campus, No. 156 Beiqing Rd. 355 Beijing 100095 356 China 358 Email: jie.dong@huawei.com 360 Xiugang Wei 361 Huawei Technologies 362 Huawei Campus, No. 156 Beiqing Rd. 363 Beijing 100095 364 China 366 Email: weixiugang@huawei.com 368 Victor Lopez 369 Telefonica I+D 370 Don Ramon de la Cruz 82-84 371 Madrid 28045 372 Spain 374 Email: victor.lopezalvarez@telefonica.com 375 Oscar Gonzalez de Dios 376 Telefonica I+D 377 Don Ramon de la Cruz 82-84 378 Madrid 28045 379 Spain 381 Email: oscar.gonzalezdedios@telefonica.com