idnits 2.17.1 draft-ietf-ccamp-rsvp-te-li-lb-02.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 is 1 instance of too long lines in the document, the longest one being 4 characters 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 (October 21, 2013) is 3830 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) == Missing Reference: 'RFC5852' is mentioned on line 112, but not defined == Missing Reference: 'RFC4872' is mentioned on line 113, but not defined == Missing Reference: 'RFC4783' is mentioned on line 114, but not defined == Missing Reference: 'RFC4974' is mentioned on line 115, but not defined == Unused Reference: 'RFC3945' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext' is defined on line 284, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-lsp-attribute-ro-02 == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-oam-configuration-fwk-10 ** Downref: Normative reference to an Informational RFC: RFC 6371 == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-12 Summary: 2 errors (**), 0 flaws (~~), 10 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 24, 2014 Z. Li 6 China Mobile 7 D. Ceccarelli 8 Ericsson 9 October 21, 2013 11 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 12 draft-ietf-ccamp-rsvp-te-li-lb-02 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) mechanism for Label Switched Paths (LSPs). The 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 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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. Extensions to RSVP-TE . . . . . . . . . . . . . . . . . . . . 3 64 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 7.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The requirements for Lock Instruct (LI) and Loopback (LB) in 78 Multiprotocol Label Switching Transport Profile (MPLS-TP) are 79 specified in [RFC5860], and the framework of LI and LB is specified 80 in [RFC6371]. 82 In general the LI and LB are useful Operations, Administration and 83 Maintenance (OAM) functions for technologies which use Generalized 84 Multi-Protocol Label Switching (GMPLS) as control plane, e.g. time- 85 division multiplexing, wavelength-division multiplexing, and packet 86 switching. It is natural to use and extend the GMPLS control plane 87 protocol to provide a unified approach for LI and LB provisioning in 88 all these technologies. 90 This document specifies extensions to Resource Reservation Protocol - 91 Traffic Engineering (RSVP-TE) to support lock instruct and loopback 92 mechanism for Label Switched Paths (LSPs). The mechanisms are 93 applicable to technologies which use GMPLS as control plane. For 94 MPLS-TP network, the mechanisms defined in this document are 95 complementary to [RFC6435]. 97 2. Extensions to RSVP-TE 99 The A (Administratively down) bit in ADMIN_STATUS object [RFC3471] 100 [RFC3473] is used to indicate the lock/unlock of the LSP. Format of 101 ADMIN_STATUS Object is as below: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Length | Class-Num(196)| C-Type (1) | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |R| Reserved |H|L|I|C|T|A|D| 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 Reflect (R): 1 bit - see [RFC3471] 112 Handover (H): 1 bit - see [RFC5852] 113 Lockout (L): 1 bit - see [RFC4872] 114 Inhibit Alarm Indication (I): 1 bit - see [RFC4783] 115 Call Control (C): 1 bit - see [RFC4974] 116 Testing (T): 1 bit - see [RFC3471] 117 Administratively down (A): 1 bit - see [RFC3471], reused for Lock 118 Deletion in progress (D): 1 bit - see [RFC3471] 120 A new bit is defined in Attribute Flags TLV [RFC5420] to indicate the 121 loopback mode. The bit number is TBA. 123 Bit Number Name and Usage 124 TBA Loopback mode desired. 125 This flag indicates a particular node on the LSP is required 126 to enter loopback mode. 127 This MAY also be used for specifying the loopback state 128 of the node. 130 3. Operations 132 3.1. Lock Instruct 134 When an ingress LSR wants to put an LSP into lock mode, it MUST send 135 a Path message with the Administratively down (A) bit and the Reflect 136 (R) bit in ADMIN_STATUS Object set. The intermediate nodes SHOULD 137 forward the message with the A bit unchanged to the downstream . 139 On receipt of this Path message, the egress LSR SHOULD try to take 140 the LSP out of service. If the egress Label Switching Router (LSR) 141 locks the LSP successfully, it SHOULD send a Resv message with the A 142 bit in ADMIN_STATUS object set. Otherwise, it SHOULD send a PathErr 143 message with the Error Code "OAM Problem" 144 [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value "Lock 145 Failure", and the following Resv messages SHOULD be sent with the A 146 bit cleared. With this procedure, the intermediate nodes would also 147 be aware of whether the LSP is in Lock mode or not. 149 When an LSP is put in lock mode, the subsequent Path and Resv 150 messages SHOULD keep the A bit in ADMIN_STATUS Object set. 152 When the ingress LSR wants to take the LSP out of the lock mode, it 153 MUST send a Path message with the A bit in ADMIN_STATUS Object 154 cleared. The intermediate nodes SHOULD forward this message with the 155 A bit unchanged to the downstream. 157 On receipt of this Path message, the egress LSR SHOULD try to bring 158 the LSP back to service. If the egress LSR unlocks the LSP 159 successfully, it SHOULD send a Resv message with the A bit in 160 ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr 161 message with the Error Code "OAM Problem" 162 [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value 163 "Unlock Failure", and the following Resv messages SHOULD be sent with 164 the A bit set. 166 When an LSP is taken out of lock mode, the subsequent Path and Resv 167 messages SHOULD keep the A bit in ADMIN_STATUS Object cleared. 169 3.2. Loopback 171 The loopback request can be sent either to the egress LSR or to a 172 particular intermediate node. The mechanism defined in 173 [I-D.ietf-ccamp-lsp-attribute-ro] is used for addressing the loopback 174 request to a particular node on the LSP. The loopback request is 175 acceptable only when the LSP is in lock mode. 177 When a ingress LSR wants to put a particular LSR on the LSP into 178 loopback mode, it MUST send a Path message with the Loopback bit in 179 the Attribute Flags TLV set. The mechanism defined in 180 [I-D.ietf-ccamp-lsp-attribute-ro] is used to address the loopback 181 request to the particular LSR. The Administratively down (A) bit in 182 ADMIN_STATUS object SHOULD be set to keep the LSP in lock mode. 184 On receipt of this Path message, the target LSR of the loopback 185 request SHOULD try to put the LSP into loopback mode. If the node 186 puts the LSP into loopback mode successfully, it SHOULD set the 187 Loopback (B) bit in the Record Route Object (RRO) Attribute subobject 188 [RFC5420] and push this subobject onto the RRO object in the 189 corresponding Resv message. The Administratively down (A) bit in 190 ADMIN_STATUS object SHOULD also be set in the Resv message. If the 191 node cannot put the LSP into loopback mode, it SHOULD send a PathErr 192 message with the Error Code "OAM Problem" 193 [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value 194 "Loopback Failure". 196 When the ingress LSR wants to take the LSP out of loopback mode, it 197 MUST send a Path message with the Loopback (B) bit in the Attribute 198 Flags TLV cleared. The mechanism defined in 199 [I-D.ietf-ccamp-lsp-attribute-ro] is used to indicate that the 200 particular LSR SHOULD exit loopback mode for this LSP. The 201 Administratively down (A) bit in ADMIN_STATUS object SHOULD be set. 203 On receipt of this Path message, the target LSR SHOULD try to take 204 the LSP out of loopback mode. If the node takes the LSP out of 205 loopback mode successfully, it SHOULD clear the Loopback (B) Bit in 206 the RRO Attribute subobject and push this subobject onto the RRO 207 object in the corresponding Resv message. The Administratively down 208 (A) Bit in ADMIN_STATUS Object SHOULD be set. Otherwise, the node 209 SHOULD send a PathErr message with the Error Code "OAM Problem" 210 [I-D.ietf-ccamp-oam-configuration-fwk] and the new Error Value "Exit 211 Loopback Failure". 213 4. IANA Considerations 215 One bit number "Loopback" needs to be assigned in the Attribute Flags 216 registry. 218 Four new Error Values need to be allocated for "OAM Problem" Error 219 Code: 221 Value Error 222 TBA Lock Failure 223 TBA Unlock Failure 224 TBA Loopback Failure 225 TBA Exit Loopback Failure 227 5. Security Considerations 229 This document does not introduce any new security issues above those 230 identified in [RFC3209] and [RFC3473]. 232 6. Acknowledgements 234 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 235 Fondelli for their comments and suggestions. 237 7. References 239 7.1. Normative References 241 [I-D.ietf-ccamp-lsp-attribute-ro] 242 Margaria, C., Martinelli, G., Balls, S., and B. Wright, 243 "LSP Attribute in ERO", draft-ietf-ccamp-lsp-attribute- 244 ro-02 (work in progress), July 2013. 246 [I-D.ietf-ccamp-oam-configuration-fwk] 247 Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE 248 extensions for OAM Configuration", draft-ietf-ccamp-oam- 249 configuration-fwk-10 (work in progress), June 2013. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 255 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 256 Tunnels", RFC 3209, December 2001. 258 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 259 (GMPLS) Signaling Functional Description", RFC 3471, 260 January 2003. 262 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 263 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 264 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 266 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 267 (GMPLS) Architecture", RFC 3945, October 2004. 269 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 270 Ayyangarps, "Encoding of Attributes for MPLS LSP 271 Establishment Using Resource Reservation Protocol Traffic 272 Engineering (RSVP-TE)", RFC 5420, February 2009. 274 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 275 Operations, Administration, and Maintenance (OAM) in MPLS 276 Transport Networks", RFC 5860, May 2010. 278 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 279 Maintenance Framework for MPLS-Based Transport Networks", 280 RFC 6371, September 2011. 282 7.2. Informative References 284 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 285 Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D., 286 and A. Takacs, "Configuration of Pro-Active Operations, 287 Administration, and Maintenance (OAM) Functions for MPLS- 288 based Transport Networks using RSVP-TE", draft-ietf-ccamp- 289 rsvp-te-mpls-tp-oam-ext-12 (work in progress), June 2013. 291 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 292 and X. Dai, "MPLS Transport Profile Lock Instruct and 293 Loopback Functions", RFC 6435, November 2011. 295 Authors' Addresses 297 Jie Dong 298 Huawei Technologies 299 Huawei Building, No.156 Beiqing Rd. 300 Beijing 100095 301 China 303 Email: jie.dong@huawei.com 305 Mach(Guoyi) Chen 306 Huawei Technologies 307 Huawei Building, No.156 Beiqing Rd. 308 Beijing 100095 309 China 311 Email: mach.chen@huawei.com 313 Zhenqiang Li 314 China Mobile 315 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 316 Beijing 100053 317 China 319 Email: lizhenqiang@chinamobile.com 320 Daniele Ceccarelli 321 Ericsson 322 Via A. Negrone 1/A 323 Genova - Sestri Ponente 324 Italy 326 Email: daniele.ceccarelli@ericsson.com