idnits 2.17.1 draft-ietf-teas-rsvp-te-li-lb-03.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2015) is 3352 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-01 == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 Summary: 1 error (**), 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 M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 27, 2015 Z. Li 6 China Mobile 7 D. Ceccarelli 8 Ericsson 9 January 23, 2015 11 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 12 draft-ietf-teas-rsvp-te-li-lb-03 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 27, 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 . . . . . . . . . . . . . . . . . . . 3 67 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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. 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 node intends to put an LSP into lock mode, it MUST 140 send a Path message with the Administratively down (A) bit defined 141 above and the Reflect (R) bit in ADMIN_STATUS Object set. 143 On receipt of this Path message, the egress node SHOULD try to take 144 the LSP out of service. If the egress node locks the LSP 145 successfully, it MUST send a Resv message with the A bit in 146 ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message 147 with the Error Code "OAM Problem" [RFC7260] and the new Error Value 148 "Lock Failure", and the following Resv messages MUST be sent with the 149 A bit cleared. 151 When an LSP is put in lock mode, the subsequent Path and Resv 152 messages MUST keep the A bit in ADMIN_STATUS Object set. 154 When the ingress node intends to take the LSP out of the lock mode, 155 it MUST send a Path message with the A bit in ADMIN_STATUS Object 156 cleared. 158 On receipt of this Path message, the egress node SHOULD try to bring 159 the LSP back to service. If the egress node unlocks the LSP 160 successfully, it MUST send a Resv message with the A bit in 161 ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr 162 message with the Error Code "OAM Problem" [RFC7260] and the new Error 163 Value "Unlock Failure", and the following Resv messages MUST be sent 164 with the A bit set. 166 When an LSP is taken out of lock mode, the subsequent Path and Resv 167 messages MUST keep the A bit in ADMIN_STATUS Object cleared. 169 3.2. Loopback 171 The loopback request can be sent either to the egress node or to a 172 particular intermediate node. The mechanism defined in 173 [I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback 174 request to a particular node on the LSP. The ingress node MUST 175 ensure that the LSP is in lock mode before it requests setting a 176 particular node on the LSP into loopback mode. 178 When a ingress node intends to put a particular node on the LSP into 179 loopback mode, it MUST send a Path message with the Loopback 180 Attribute Flag defined above in the Attribute Flags TLV set. The 181 mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to 182 address the loopback request to the particular node. The ingress 183 MUST ensure that the desired loopback mode is strictly identified in 184 the ERO. The Administratively down (A) bit in ADMIN_STATUS object 185 MUST be kept set to indicate that the LSP is still in lock mode. 187 On receipt of this Path message, the target node of the loopback 188 request MUST check if the LSP is in lock mode by verifying that the 189 Administratively down (A) bit is set in the ADMIN_STATUS object. If 190 the bit is not set, the loopback request MUST be ignored. If the bit 191 is set, the node MUST check that the desired loopback is strictly 192 identified by verifying that the L bit is set to 0 in both the ERO 193 Hop Attributes subobject and the prior subobject. The prior 194 subobject MUST also be checked to ensure that it provides strict 195 identification. Currently, the type value MUST be verified to be 196 less than 32, and for type values 1 and 2 the prefix length MUST be 197 32 and 128 respectively. If the desired loopback is not strictly 198 identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE 199 object" error SHOULD be generated. Otherwise, the node SHOULD try to 200 put the LSP into loopback mode. If the node puts the LSP into 201 loopback mode successfully, it MUST set the Loopback Attribute Flag 202 if it adds, per [RFC5420], an Attributes subobject to the 203 RECORD_ROUTE Object (RRO) of a Path or Resv message. The 204 Administratively down (A) bit in ADMIN_STATUS object MUST be kept set 205 in the message. If the node cannot put the LSP into loopback mode, 206 it MUST send a PathErr message with the Error Code "OAM Problem" 207 [RFC7260] and the new Error Value "Loopback Failure". 209 When the ingress node intends to take the particular node out of 210 loopback mode, it MUST send a Path message with the Loopback 211 Attribute Flag in the Attribute Flags TLV cleared. The mechanism 212 defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that 213 the particular node SHOULD exit loopback mode for this LSP. The 214 Administratively down (A) bit in ADMIN_STATUS object MUST be kept set 215 to indicate the LSP is still in lock mode. 217 On receipt of this Path message, the target node SHOULD try to take 218 the LSP out of loopback mode. If the node takes the LSP out of 219 loopback mode successfully, it MUST clear the Loopback Attribute Flag 220 in the RRO Attributes subobject and push this subobject onto the RRO 221 object in the corresponding Path or Resv message. The 222 Administratively down (A) Bit in ADMIN_STATUS Object MUST be kept set 223 in the message. Otherwise, the node MUST send a PathErr message with 224 the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit 225 Loopback Failure". 227 After the loopback mode is cleared successfully, the ingress node MAY 228 remove the Lock Instruct using the mechanism defined in section 3.1. 229 The ingress node MUST NOT request to exit lock mode if the LSP is 230 still in loopback mode. The egress node MUST ignore such request 231 when the LSP is still in loopback mode. 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 | ERO | Reference 248 ----+--------------+------------+------------+-----+-----+------------- 249 TBA | Loopback | Yes | No | Yes | 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] [RFC3473] and 271 [I-D.ietf-teas-lsp-attribute-ro]. For a more comprehensive 272 discussion of GMPLS security and attack mitigation techniques, please 273 see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 275 6. Acknowledgements 277 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 278 Fondelli for their comments and suggestions. 280 7. References 281 7.1. Normative References 283 [I-D.ietf-teas-lsp-attribute-ro] 284 Margaria, C., Martinelli, G., Balls, S., and B. Wright, 285 "LSP Attribute in ERO", draft-ietf-teas-lsp-attribute- 286 ro-01 (work in progress), December 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., Takacs, A., Mirsky, G., Andersson, L., 320 Skoldstrom, P., and D. Ward, "Configuration of Pro-Active 321 Operations, Administration, and Maintenance (OAM) 322 Functions for MPLS-based Transport Networks using RSVP- 323 TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 (work in 324 progress), January 2015. 326 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 327 Networks", RFC 5920, July 2010. 329 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 330 Maintenance Framework for MPLS-Based Transport Networks", 331 RFC 6371, September 2011. 333 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 334 and X. Dai, "MPLS Transport Profile Lock Instruct and 335 Loopback Functions", RFC 6435, November 2011. 337 Authors' Addresses 339 Jie Dong 340 Huawei Technologies 341 Huawei Campus, No.156 Beiqing Rd. 342 Beijing 100095 343 China 345 Email: jie.dong@huawei.com 347 Mach(Guoyi) Chen 348 Huawei Technologies 349 Huawei Campus, No.156 Beiqing Rd. 350 Beijing 100095 351 China 353 Email: mach.chen@huawei.com 355 Zhenqiang Li 356 China Mobile 357 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 358 Beijing 100053 359 China 361 Email: lizhenqiang@chinamobile.com 363 Daniele Ceccarelli 364 Ericsson 365 Via A. Negrone 1/A 366 Genova - Sestri Ponente 367 Italy 369 Email: daniele.ceccarelli@ericsson.com