idnits 2.17.1 draft-ietf-teas-rsvp-te-li-lb-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 (December 30, 2014) is 3405 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: 'RFC4783' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC4974' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5852' is defined on line 324, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 Summary: 0 errors (**), 0 flaws (~~), 6 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 M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 3, 2015 Z. Li 6 China Mobile 7 D. Ceccarelli 8 Ericsson 9 December 30, 2014 11 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 12 draft-ietf-teas-rsvp-te-li-lb-01 14 Abstract 16 This document specifies extensions to Resource Reservation Protocol- 17 Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and 18 Loopback (LB) mechanisms for Label Switched Paths (LSPs). These 19 mechanisms are applicable to technologies which use Generalized 20 Multi-Protocol Label Switching (GMPLS) as control plane. 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 RFC 2119 [RFC2119]. 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 July 3, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3 64 2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3 65 2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3 66 3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3 67 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 5 71 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The requirements for Lock Instruct (LI) and Loopback (LB) in 82 Multiprotocol Label Switching Transport Profile (MPLS-TP) are 83 specified in [RFC5860], and the framework of LI and LB is specified 84 in [RFC6371]. 86 In general the LI and LB are useful Operations, Administration and 87 Maintenance (OAM) functions for technologies which use Generalized 88 Multi-Protocol Label Switching (GMPLS) as control plane, e.g. time- 89 division multiplexing, wavelength-division multiplexing and packet 90 switching. It is natural to use and extend the GMPLS control plane 91 protocol to provide a unified approach for LI and LB provisioning in 92 all these technologies. 94 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE 95 extensions for the configuration of pro-active MPLS-TP OAM functions, 96 such as Continuity Check (CC), Connectivity Verification (CV), Delay 97 Measurement (DM) and Loss Measurement (LM). The provisioning of on- 98 demand OAM functions such as LI and LB are not covered in that 99 document. 101 This document specifies extensions to Resource Reservation Protocol- 102 Traffic Engineering (RSVP-TE) to support lock instruct and loopback 103 mechanisms for Label Switched Paths (LSPs). The mechanisms are 104 applicable to technologies which use GMPLS as control plane. For 105 MPLS-TP network, the mechanisms defined in this document are 106 complementary to [RFC6435]. 108 2. Flag Definitions for LI and LB 110 2.1. Lock Instruct Indication 112 In order to indicate the lock/unlock of the LSP, the A 113 (Administratively down) bit in ADMIN_STATUS object [RFC3471] 114 [RFC3473] is used. 116 2.2. Extensions for Loopback 118 In order to indicate the loopback mode of LSP, a new bit flag is 119 defined in the Attribute Flags TLV [RFC5420]. 121 Loopback flag: 123 This flag indicates a particular node on the LSP is required to 124 enter loopback mode. This can also be used for specifying the 125 loopback state of the node. 127 - Bit number: TBA 129 - Attribute flag carried in Path message: Yes 131 - Attribute flag carried in Resv message: No 133 - Attribute flag carried in RRO Attributes subobject: Yes 135 3. Operational Procedures 137 3.1. Lock Instruct 139 When an ingress Label Switching Router (LSR) intends to put an LSP 140 into lock mode, it MUST send a Path message with the Administratively 141 down (A) bit defined above and the Reflect (R) bit in ADMIN_STATUS 142 Object set. 144 On receipt of this Path message, the egress LSR SHOULD try to take 145 the LSP out of service. If the egress LSR locks the LSP 146 successfully, it MUST send a Resv message with the A bit in 147 ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message 148 with the Error Code "OAM Problem" [RFC7260] and the new Error Value 149 "Lock Failure", and the following Resv messages MUST be sent with the 150 A bit cleared. 152 When an LSP is put in lock mode, the subsequent Path and Resv 153 messages MUST keep the A bit in ADMIN_STATUS Object set. 155 When the ingress LSR intends to take the LSP out of the lock mode, it 156 MUST send a Path message with the A bit in ADMIN_STATUS Object 157 cleared. 159 On receipt of this Path message, the egress LSR SHOULD try to bring 160 the LSP back to service. If the egress LSR unlocks the LSP 161 successfully, it MUST send a Resv message with the A bit in 162 ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr 163 message with the Error Code "OAM Problem" [RFC7260] and the new Error 164 Value "Unlock Failure", and the following Resv messages MUST be sent 165 with the A bit set. 167 When an LSP is taken out of lock mode, the subsequent Path and Resv 168 messages MUST keep the A bit in ADMIN_STATUS Object cleared. 170 3.2. Loopback 172 The loopback request can be sent either to the egress LSR or to a 173 particular intermediate node. The mechanism defined in 174 [I-D.ietf-ccamp-lsp-attribute-ro] is used for addressing the loopback 175 request to a particular node on the LSP. The ingress LSR MUST ensure 176 that the LSP is in lock mode before it requests setting a particular 177 node on the LSP into loopback mode. 179 When a ingress LSR intends to put a particular node on the LSP into 180 loopback mode, it MUST send a Path message with the Loopback 181 Attribute Flag defined above in the Attribute Flags TLV set. The 182 mechanism defined in [I-D.ietf-ccamp-lsp-attribute-ro] is used to 183 address the loopback request to the particular LSR. The 184 Administratively down (A) bit in ADMIN_STATUS object MUST be kept set 185 to indicate that the LSP is still in lock mode. 187 On receipt of this Path message, the target LSR of the loopback 188 request SHOULD try to put the LSP into loopback mode. If the node 189 puts the LSP into loopback mode successfully, it MUST set the 190 Loopback Attribute Flag in the Record Route Object (RRO) Attribute 191 subobject [RFC5420] and push this subobject onto the RRO object in 192 the corresponding Resv message. The Administratively down (A) bit in 193 ADMIN_STATUS object MUST be kept set in the Resv message. If the 194 node cannot put the LSP into loopback mode, it MUST send a PathErr 195 message with the Error Code "OAM Problem" [RFC7260] and the new Error 196 Value "Loopback Failure". 198 When the ingress LSR intends to take the particular node out of 199 loopback mode, it MUST send a Path message with the Loopback 200 Attribute Flag in the Attribute Flags TLV cleared. The mechanism 201 defined in [I-D.ietf-ccamp-lsp-attribute-ro] is used to indicate that 202 the particular LSR SHOULD exit loopback mode for this LSP. The 203 Administratively down (A) bit in ADMIN_STATUS object MUST be kept set 204 to indicate the LSP is still in lock mode. 206 On receipt of this Path message, the target LSR SHOULD try to take 207 the LSP out of loopback mode. If the node takes the LSP out of 208 loopback mode successfully, it MUST clear the Loopback Attribute Flag 209 in the RRO Attribute subobject and push this subobject onto the RRO 210 object in the corresponding Resv message. The Administratively down 211 (A) Bit in ADMIN_STATUS Object MUST be kept set in the Resv message. 212 Otherwise, the node MUST send a PathErr message with the Error Code 213 "OAM Problem" [RFC7260] and the new Error Value "Exit Loopback 214 Failure". 216 After the loopback mode is cleared successfully, the ingress LSR MAY 217 remove the Lock Instruct using the mechanism defined in section 3.1. 219 4. IANA Considerations 221 IANA is requested to administer the assignment of new values defined 222 in this document and summarized in this section. 224 4.1. Attribute Flags 226 IANA maintains a registry called "Resource Reservation Protocol- 227 Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called 228 "Attribute Flags". 230 IANA is requested to assign a new bit flag as follows: 232 Bit | | Attribute | Attribute | | 233 No. | Name | Flags Path | Flags Resv | RRO | Reference 234 ----+--------------+------------+------------+-----+-------------- 235 TBA | Loopback | Yes | No | Yes | this document 237 4.2. RSVP Error Value Sub-codes 239 IANA maintains a registry called "Resource Reservation Protocol 240 (RSVP) Parameters" with a sub-registry called "Error Codes and 241 Globally-Defined Error Value Sub-Codes". 243 IANA is requested to assign four new Error Value sub-codes for the 244 "OAM Problem" Error Code: 246 Value | Description | Reference 247 -----------+-----------------------------+-------------- 248 TBA | Lock Failure | this document 249 TBA | Unlock Failure | this document 250 TBA | Loopback Failure | this document 251 TBA | Exit Loopback Failure | this document 253 5. Security Considerations 255 This document does not introduce any new security issues above those 256 identified in [RFC3209] and [RFC3473]. For a more comprehensive 257 discussion of GMPLS security and attack mitigation techniques, please 258 see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 260 6. Acknowledgements 262 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 263 Fondelli for their comments and suggestions. 265 7. References 267 7.1. Normative References 269 [I-D.ietf-ccamp-lsp-attribute-ro] 270 Margaria, C., Martinelli, G., Balls, S., and B. Wright, 271 "LSP Attribute in ERO", draft-ietf-ccamp-lsp-attribute- 272 ro-05 (work in progress), October 2014. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 278 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 279 Tunnels", RFC 3209, December 2001. 281 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 282 (GMPLS) Signaling Functional Description", RFC 3471, 283 January 2003. 285 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 286 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 287 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 289 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 290 Ayyangarps, "Encoding of Attributes for MPLS LSP 291 Establishment Using Resource Reservation Protocol Traffic 292 Engineering (RSVP-TE)", RFC 5420, February 2009. 294 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 295 Operations, Administration, and Maintenance (OAM) in MPLS 296 Transport Networks", RFC 5860, May 2010. 298 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 299 Extensions for Operations, Administration, and Maintenance 300 (OAM) Configuration", RFC 7260, June 2014. 302 7.2. Informative References 304 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 305 Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P., 306 Ward, D., and A. Takacs, "Configuration of Pro-Active 307 Operations, Administration, and Maintenance (OAM) 308 Functions for MPLS-based Transport Networks using RSVP- 309 TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 (work in 310 progress), December 2014. 312 [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", 313 RFC 4783, December 2006. 315 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 316 Extensions in Support of End-to-End Generalized Multi- 317 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 318 2007. 320 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) 321 RSVP-TE Signaling Extensions in Support of Calls", RFC 322 4974, August 2007. 324 [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. 325 Bardalai, "RSVP-TE Signaling Extension for LSP Handover 326 from the Management Plane to the Control Plane in a GMPLS- 327 Enabled Transport Network", RFC 5852, April 2010. 329 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 330 Networks", RFC 5920, July 2010. 332 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 333 Maintenance Framework for MPLS-Based Transport Networks", 334 RFC 6371, September 2011. 336 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 337 and X. Dai, "MPLS Transport Profile Lock Instruct and 338 Loopback Functions", RFC 6435, November 2011. 340 Authors' Addresses 342 Jie Dong 343 Huawei Technologies 344 Huawei Campus, No.156 Beiqing Rd. 345 Beijing 100095 346 China 348 Email: jie.dong@huawei.com 350 Mach(Guoyi) Chen 351 Huawei Technologies 352 Huawei Campus, No.156 Beiqing Rd. 353 Beijing 100095 354 China 356 Email: mach.chen@huawei.com 358 Zhenqiang Li 359 China Mobile 360 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 361 Beijing 100053 362 China 364 Email: lizhenqiang@chinamobile.com 366 Daniele Ceccarelli 367 Ericsson 368 Via A. Negrone 1/A 369 Genova - Sestri Ponente 370 Italy 372 Email: daniele.ceccarelli@ericsson.com