idnits 2.17.1 draft-ietf-teas-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 (March 4, 2015) is 3339 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 (-05) exists of draft-ietf-teas-lsp-attribute-ro-03 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: September 5, 2015 Z. Li 6 China Mobile 7 D. Ceccarelli 8 Ericsson 9 March 4, 2015 11 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 12 draft-ietf-teas-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) for the 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 September 5, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 4 67 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 72 4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 The requirements for Lock Instruct (LI) and Loopback (LB) in the 83 Multiprotocol Label Switching Transport Profile (MPLS-TP) are 84 specified in [RFC5860], and the framework of LI and LB is specified 85 in [RFC6371]. An LSP that is locked, using LI, is prevented from 86 carrying user data traffic. The LB function can only be applied to 87 an LSP that has been previously locked. 89 In general the LI and LB are useful Operations, Administration and 90 Maintenance (OAM) functions for technologies which use Generalized 91 Multi-Protocol Label Switching (GMPLS) for the control plane, e.g., 92 time-division multiplexing, wavelength-division multiplexing and 93 packet switching. It is natural to use and extend the GMPLS control 94 plane protocol to provide a unified approach for LI and LB 95 provisioning in all these technologies. 97 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE 98 extensions for the configuration of pro-active MPLS-TP OAM functions, 99 such as Continuity Check (CC), Connectivity Verification (CV), Delay 100 Measurement (DM) and Loss Measurement (LM). The provisioning of on- 101 demand OAM functions such as LI and LB are not covered in that 102 document. 104 This document specifies extensions to Resource Reservation Protocol- 105 Traffic Engineering (RSVP-TE) to support lock instruct and loopback 106 mechanisms for Label Switched Paths (LSPs). The mechanisms are 107 applicable to technologies which use GMPLS for the control plane. 108 For a network supporting MPLS-TP, the mechanisms defined in this 109 document are complementary to [RFC6435]. 111 2. Flag Definitions for LI and LB 113 2.1. Lock Instruct Indication 115 In order to indicate the lock/unlock status of the LSP, the A 116 (Administratively down) bit in the Administrative Status 117 (ADMIN_STATUS) object [RFC3471] [RFC3473] is used. 119 2.2. Extensions for Loopback 121 In order to indicate the loopback mode of LSP, a new bit flag is 122 defined in the Attribute Flags TLV [RFC5420]. 124 Loopback flag: 126 This flag indicates a particular node on the LSP is required to 127 enter loopback mode. This can also be used for specifying the 128 loopback state of the node. 130 - Bit number: TBA-1 132 - Attribute flag carried in Path message: Yes 134 - Attribute flag carried in Resv message: No 136 - Attribute flag carried in RRO Attributes subobject: Yes 138 3. Operational Procedures 140 3.1. Lock Instruct 142 When an ingress node intends to put an LSP into lock mode, it MUST 143 send a Path message with the Administratively down (A) bit used as 144 specified above and the Reflect (R) bit in the ADMIN_STATUS Object 145 set. 147 On receipt of this Path message, the egress node SHOULD try to take 148 the LSP out of service. If the egress node locks the LSP 149 successfully, it MUST send a Resv message with the A bit in the 150 ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message 151 with the Error Code "OAM Problem" [RFC7260] and the new Error Value 152 "Lock Failure", and the following Resv messages MUST be sent with the 153 A bit cleared. 155 When an LSP is put in lock mode, the subsequent Path and Resv 156 messages MUST keep the A bit in the ADMIN_STATUS Object set. 158 When the ingress node intends to take the LSP out of the lock mode, 159 it MUST send a Path message with the A bit in the ADMIN_STATUS Object 160 cleared. 162 On receipt of this Path message, the egress node SHOULD try to bring 163 the LSP back to service. If the egress node unlocks the LSP 164 successfully, it MUST send a Resv message with the A bit in the 165 ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr 166 message with the Error Code "OAM Problem" [RFC7260] and the new Error 167 Value "Unlock Failure", and the following Resv messages MUST be sent 168 with the A bit set. 170 When an LSP is taken out of lock mode, the subsequent Path and Resv 171 messages MUST keep the A bit in the ADMIN_STATUS Object cleared. 173 3.2. Loopback 175 The loopback request can be sent either to the egress node or to a 176 particular intermediate node. The mechanism defined in 177 [I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback 178 request to a particular node on the LSP. The ingress node MUST 179 ensure that the LSP is in lock mode before it requests setting a 180 particular node on the LSP into loopback mode. 182 When a ingress node intends to put a particular node on the LSP into 183 loopback mode, it MUST send a Path message with the Loopback 184 Attribute Flag defined above in the Attribute Flags TLV set. The 185 mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to 186 address the loopback request to the particular node. The ingress 187 node MUST ensure that the entity (node or interface), at which 188 loopback is intended to occur, is marked as a strict hop in the 189 Explicit Route Object (ERO) subobject. The Administratively down (A) 190 bit in the ADMIN_STATUS object MUST be kept set to indicate that the 191 LSP is still in lock mode. 193 On receipt of this Path message, the target node of the loopback 194 request MUST check if the LSP is in lock mode by verifying that the 195 Administratively down (A) bit is set in the ADMIN_STATUS object. If 196 the bit is not set, the loopback request MUST be ignored. If the bit 197 is set, the node MUST check that the desired loopback entity is 198 explicitly identified by the ERO subobject prior to the ERO Hop 199 Attributes subobject. Currently, the type value MUST be verified to 200 be less than 32 (i.e., able to identify a specific entity where a 201 loopback can occur, see Section 4.3), and for type values 1 (IPv4 202 prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128 203 respectively. If the desired loopback entity is not explicitly 204 identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE 205 object" error SHOULD be generated. Otherwise, the node SHOULD try to 206 put the LSP into loopback mode. If the node puts the LSP into 207 loopback mode successfully, it MUST set the Loopback Attribute Flag 208 if it adds, per [I-D.ietf-teas-lsp-attribute-ro], an RRO Hop 209 Attributes subobject to the RECORD_ROUTE Object (RRO) of a Path or 210 Resv message. The Administratively down (A) bit in the ADMIN_STATUS 211 object MUST be kept set in the message. If the node cannot put the 212 LSP into loopback mode, it MUST send a PathErr message with the Error 213 Code "OAM Problem" [RFC7260] and the new Error Value "Loopback 214 Failure". 216 When the ingress node intends to take the particular node out of 217 loopback mode, it MUST send a Path message with the Loopback 218 Attribute Flag in the Attribute Flags TLV cleared. The mechanism 219 defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that 220 the particular node SHOULD exit loopback mode for this LSP. The 221 Administratively down (A) bit in the ADMIN_STATUS object MUST be kept 222 set to indicate the LSP is still in lock mode. 224 On receipt of this Path message, the target node SHOULD try to take 225 the LSP out of loopback mode. If the node takes the LSP out of 226 loopback mode successfully, it MUST clear the Loopback Attribute Flag 227 in the RRO Hop Attributes subobject and push this subobject onto the 228 RRO object in the corresponding Path or Resv message. The 229 Administratively down (A) Bit in the ADMIN_STATUS Object MUST be kept 230 set in the message. Otherwise, the node MUST send a PathErr message 231 with the Error Code "OAM Problem" [RFC7260] and the new Error Value 232 "Exit Loopback Failure". 234 After the loopback mode is cleared successfully, the ingress node MAY 235 remove the Lock Instruct using the mechanism defined in section 3.1. 236 The ingress node MUST NOT request to exit lock mode if the LSP is 237 still in loopback mode. The egress node MUST ignore such request 238 when the LSP is still in loopback mode. 240 4. IANA Considerations 242 IANA is requested to administer the assignment of new values defined 243 in this document and summarized in this section. 245 4.1. Attribute Flags 247 IANA maintains a registry called "Resource Reservation Protocol- 248 Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called 249 "Attribute Flags". 251 IANA is requested to assign a new bit flag as follows: 253 Bit | | Attribute | Attribute | | | 254 No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference 255 -----+-----------+------------+------------+-----+-----+------------- 256 TBA-1| Loopback | Yes | No | Yes | Yes |this document 258 4.2. RSVP Error Value Sub-codes 260 IANA maintains a registry called "Resource Reservation Protocol 261 (RSVP) Parameters" with a sub-registry called "Error Codes and 262 Globally-Defined Error Value Sub-Codes". 264 IANA is requested to assign four new Error Value sub-codes for the 265 "OAM Problem" Error Code: 267 Value | Description | Reference 268 -----------+-----------------------------+-------------- 269 TBA-2 | Lock Failure | this document 270 TBA-3 | Unlock Failure | this document 271 TBA-4 | Loopback Failure | this document 272 TBA-5 | Exit Loopback Failure | this document 274 4.3. Allocation Rule for ERO Subobjects 276 IANA maintains a registry called "Resource Reservation Protocol 277 (RSVP) Parameters" with a sub-registry called "Class Names, Class 278 Numbers, and Class Types". 280 For Explicit Route Object , the allocation rule for subobject types 281 in the range 5 - 31 (0x05 - 0x1F) needs to be updated as: 283 5-31 Unassigned (For explicit resource identification) 285 5. Security Considerations 287 This document does not introduce any new security issues above those 288 identified in [RFC3209] [RFC3473] and 289 [I-D.ietf-teas-lsp-attribute-ro]. For a more comprehensive 290 discussion of GMPLS security and attack mitigation techniques, please 291 see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 293 In addition, the reporting of the loopback status using the RRO may 294 reveal details about the node that the operator wishes to remain 295 confidential. The privacy considerations as described in section 5, 296 paragraph 3 of [I-D.ietf-teas-lsp-attribute-ro] also apply to this 297 document. 299 6. Acknowledgements 301 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 302 Fondelli for their comments and suggestions. 304 7. References 306 7.1. Normative References 308 [I-D.ietf-teas-lsp-attribute-ro] 309 Margaria, C., Martinelli, G., Balls, S., and B. Wright, 310 "LSP Attribute in ERO", draft-ietf-teas-lsp-attribute- 311 ro-03 (work in progress), March 2015. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 317 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 318 Tunnels", RFC 3209, December 2001. 320 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 321 (GMPLS) Signaling Functional Description", RFC 3471, 322 January 2003. 324 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 325 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 326 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 328 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 329 Ayyangarps, "Encoding of Attributes for MPLS LSP 330 Establishment Using Resource Reservation Protocol Traffic 331 Engineering (RSVP-TE)", RFC 5420, February 2009. 333 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 334 Operations, Administration, and Maintenance (OAM) in MPLS 335 Transport Networks", RFC 5860, May 2010. 337 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 338 Extensions for Operations, Administration, and Maintenance 339 (OAM) Configuration", RFC 7260, June 2014. 341 7.2. Informative References 343 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 344 Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., 345 Skoldstrom, P., and D. Ward, "Configuration of Pro-Active 346 Operations, Administration, and Maintenance (OAM) 347 Functions for MPLS-based Transport Networks using RSVP- 348 TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 (work in 349 progress), January 2015. 351 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 352 Networks", RFC 5920, July 2010. 354 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 355 Maintenance Framework for MPLS-Based Transport Networks", 356 RFC 6371, September 2011. 358 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 359 and X. Dai, "MPLS Transport Profile Lock Instruct and 360 Loopback Functions", RFC 6435, November 2011. 362 Authors' Addresses 364 Jie Dong 365 Huawei Technologies 366 Huawei Campus, No.156 Beiqing Rd. 367 Beijing 100095 368 China 370 Email: jie.dong@huawei.com 371 Mach(Guoyi) Chen 372 Huawei Technologies 373 Huawei Campus, No.156 Beiqing Rd. 374 Beijing 100095 375 China 377 Email: mach.chen@huawei.com 379 Zhenqiang Li 380 China Mobile 381 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 382 Beijing 100053 383 China 385 Email: lizhenqiang@chinamobile.com 387 Daniele Ceccarelli 388 Ericsson 389 Via A. Negrone 1/A 390 Genova - Sestri Ponente 391 Italy 393 Email: daniele.ceccarelli@ericsson.com