idnits 2.17.1 draft-ietf-ccamp-rsvp-te-li-lb-05.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 (October 25, 2014) is 3469 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) == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12 Summary: 0 errors (**), 0 flaws (~~), 2 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: April 28, 2015 Z. Li 6 China Mobile 7 D. Ceccarelli 8 Ericsson 9 October 25, 2014 11 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 12 draft-ietf-ccamp-rsvp-te-li-lb-05 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 April 28, 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. Extensions for Lock Instruct . . . . . . . . . . . . . . 3 65 2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3 66 3. Operational Procedures . . . . . . . . . . . . . . . . . . . 4 67 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 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. Extensions for Lock Instruct 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. The format of ADMIN_STATUS Object is as below: 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Length | Class-Num(196)| C-Type (1) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |R| Reserved |H|L|I|C|T|A|D| 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Figure 1. Admin_Status Object 125 Reflect (R): 1 bit - see [RFC3471] 126 Handover (H): 1 bit - see [RFC5852] 127 Lockout (L): 1 bit - see [RFC4872] 128 Inhibit Alarm Indication (I): 1 bit - see [RFC4783] 129 Call Control (C): 1 bit - see [RFC4974] 130 Testing (T): 1 bit - see [RFC3471] 131 Administratively down (A): 1 bit - see [RFC3471], reused for Lock 132 Deletion in progress (D): 1 bit - see [RFC3471] 134 2.2. Extensions for Loopback 136 In order to indicate the loopback mode of LSP, a new bit flag is 137 defined in the Attribute Flags TLV [RFC5420]. 139 Loopback flag: 141 This flag indicates a particular node on the LSP is required to 142 enter loopback mode. This can also be used for specifying the 143 loopback state of the node. 145 - Bit number: TBA 147 - Attribute flag carried in Path message: Yes 149 - Attribute flag carried in Resv message: No 151 - Attribute flag carried in RRO Attributes subobject: Yes 153 3. Operational Procedures 155 3.1. Lock Instruct 157 When an ingress Label Switching Router (LSR) intends to put an LSP 158 into lock mode, it MUST send a Path message with the Administratively 159 down (A) bit defined above and the Reflect (R) bit in ADMIN_STATUS 160 Object set. 162 On receipt of this Path message, the egress LSR SHOULD try to take 163 the LSP out of service. If the egress LSR locks the LSP 164 successfully, it SHOULD send a Resv message with the A bit in 165 ADMIN_STATUS object set. Otherwise, it SHOULD send a PathErr message 166 with the Error Code "OAM Problem" [RFC7260] and the new Error Value 167 "Lock Failure", and the following Resv messages SHOULD be sent with 168 the A bit cleared. 170 When an LSP is put in lock mode, the subsequent Path and Resv 171 messages SHOULD keep the A bit in ADMIN_STATUS Object set. 173 When the ingress LSR intends to take the LSP out of the lock mode, it 174 MUST send a Path message with the A bit in ADMIN_STATUS Object 175 cleared. 177 On receipt of this Path message, the egress LSR SHOULD try to bring 178 the LSP back to service. If the egress LSR unlocks the LSP 179 successfully, it SHOULD send a Resv message with the A bit in 180 ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr 181 message with the Error Code "OAM Problem" [RFC7260] and the new Error 182 Value "Unlock Failure", and the following Resv messages SHOULD be 183 sent with the A bit set. 185 When an LSP is taken out of lock mode, the subsequent Path and Resv 186 messages SHOULD keep the A bit in ADMIN_STATUS Object cleared. 188 3.2. Loopback 190 The loopback request can be sent either to the egress LSR or to a 191 particular intermediate node. The mechanism defined in 192 [I-D.ietf-ccamp-lsp-attribute-ro] is used for addressing the loopback 193 request to a particular node on the LSP. The loopback request is 194 acceptable only when the LSP is already in lock mode. 196 When a ingress LSR intends to put a particular LSR on the LSP into 197 loopback mode, it MUST send a Path message with the Loopback bit 198 defined above in the Attribute Flags TLV set. The mechanism defined 199 in [I-D.ietf-ccamp-lsp-attribute-ro] is used to address the loopback 200 request to the particular LSR. The Administratively down (A) bit in 201 ADMIN_STATUS object SHOULD be kept set to indicate that the LSP is 202 still in lock mode. 204 On receipt of this Path message, the target LSR of the loopback 205 request SHOULD try to put the LSP into loopback mode. If the node 206 puts the LSP into loopback mode successfully, it SHOULD set the 207 Loopback (B) bit in the Record Route Object (RRO) Attribute subobject 208 [RFC5420] and push this subobject onto the RRO object in the 209 corresponding Resv message. The Administratively down (A) bit in 210 ADMIN_STATUS object SHOULD be kept set in the Resv message. If the 211 node cannot put the LSP into loopback mode, it SHOULD send a PathErr 212 message with the Error Code "OAM Problem" [RFC7260] and the new Error 213 Value "Loopback Failure". 215 When the ingress LSR intends to take the LSP out of loopback mode, it 216 MUST send a Path message with the Loopback (B) bit in the Attribute 217 Flags TLV cleared. The mechanism defined in 218 [I-D.ietf-ccamp-lsp-attribute-ro] is used to indicate that the 219 particular LSR SHOULD exit loopback mode for this LSP. The 220 Administratively down (A) bit in ADMIN_STATUS object SHOULD be kept 221 set to indicate the LSP is still in lock mode. 223 On receipt of this Path message, the target LSR SHOULD try to take 224 the LSP out of loopback mode. If the node takes the LSP out of 225 loopback mode successfully, it SHOULD clear the Loopback (B) Bit in 226 the RRO Attribute subobject and push this subobject onto the RRO 227 object in the corresponding Resv message. The Administratively down 228 (A) Bit in ADMIN_STATUS Object SHOULD be kept set in the Resv 229 message. Otherwise, the node SHOULD send a PathErr message with the 230 Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit 231 Loopback Failure". 233 4. IANA Considerations 235 IANA is requested to administer the assignment of new values defined 236 in this document and summarized in this section. 238 4.1. Attribute Flags 240 IANA maintains a registry called "Resource Reservation Protocol- 241 Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called 242 "Attribute Flags". 244 IANA is requested to assign a new bit flag as follows: 246 Bit | | Attribute | Attribute | | 247 No. | Name | Flags Path | Flags Resv | RRO | Reference 248 ----+--------------+------------+------------+-----+-------------- 249 TBA | Loopback | Yes | No | Yes | this document 251 4.2. RSVP Error Value Sub-codes 253 IANA maintains a registry called "Resource Reservation Protocol 254 (RSVP) Parameters" with a sub-registry called "Error Codes and 255 Globally-Defined Error Value Sub-Codes". 257 IANA is requested to assign four new Error Value sub-codes for the 258 "OAM Problem" Error Code: 260 Value | Description | Reference 261 -----------+-----------------------------+-------------- 262 TBA | Lock Failure | this document 263 TBA | Unlock Failure | this document 264 TBA | Loopback Failure | this document 265 TBA | Exit Loopback Failure | this document 267 5. Security Considerations 269 This document does not introduce any new security issues above those 270 identified in [RFC3209] and [RFC3473]. For a more comprehensive 271 discussion of GMPLS security and attack mitigation techniques, please 272 see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 274 6. Acknowledgements 276 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 277 Fondelli for their comments and suggestions. 279 7. References 281 7.1. Normative References 283 [I-D.ietf-ccamp-lsp-attribute-ro] 284 Margaria, C., Martinelli, G., Balls, S., and B. Wright, 285 "LSP Attribute in ERO", draft-ietf-ccamp-lsp-attribute- 286 ro-05 (work in progress), October 2014. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 292 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 293 Tunnels", RFC 3209, December 2001. 295 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 296 (GMPLS) Signaling Functional Description", RFC 3471, 297 January 2003. 299 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 300 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 301 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 303 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 304 Ayyangarps, "Encoding of Attributes for MPLS LSP 305 Establishment Using Resource Reservation Protocol Traffic 306 Engineering (RSVP-TE)", RFC 5420, February 2009. 308 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 309 Operations, Administration, and Maintenance (OAM) in MPLS 310 Transport Networks", RFC 5860, May 2010. 312 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 313 Extensions for Operations, Administration, and Maintenance 314 (OAM) Configuration", RFC 7260, June 2014. 316 7.2. Informative References 318 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 319 Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D., 320 and A. Takacs, "Configuration of Pro-Active Operations, 321 Administration, and Maintenance (OAM) Functions for MPLS- 322 based Transport Networks using RSVP-TE", draft-ietf-ccamp- 323 rsvp-te-mpls-tp-oam-ext-12 (work in progress), June 2013. 325 [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", 326 RFC 4783, December 2006. 328 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 329 Extensions in Support of End-to-End Generalized Multi- 330 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 331 2007. 333 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) 334 RSVP-TE Signaling Extensions in Support of Calls", RFC 335 4974, August 2007. 337 [RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. 338 Bardalai, "RSVP-TE Signaling Extension for LSP Handover 339 from the Management Plane to the Control Plane in a GMPLS- 340 Enabled Transport Network", RFC 5852, April 2010. 342 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 343 Networks", RFC 5920, July 2010. 345 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 346 Maintenance Framework for MPLS-Based Transport Networks", 347 RFC 6371, September 2011. 349 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 350 and X. Dai, "MPLS Transport Profile Lock Instruct and 351 Loopback Functions", RFC 6435, November 2011. 353 Authors' Addresses 355 Jie Dong 356 Huawei Technologies 357 Huawei Campus, No.156 Beiqing Rd. 358 Beijing 100095 359 China 361 Email: jie.dong@huawei.com 363 Mach(Guoyi) Chen 364 Huawei Technologies 365 Huawei Campus, No.156 Beiqing Rd. 366 Beijing 100095 367 China 369 Email: mach.chen@huawei.com 370 Zhenqiang Li 371 China Mobile 372 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 373 Beijing 100053 374 China 376 Email: lizhenqiang@chinamobile.com 378 Daniele Ceccarelli 379 Ericsson 380 Via A. Negrone 1/A 381 Genova - Sestri Ponente 382 Italy 384 Email: daniele.ceccarelli@ericsson.com