idnits 2.17.1 draft-dong-ccamp-rsvp-te-mpls-tp-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 : ---------------------------------------------------------------------------- ** There is 1 instance 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 (December 4, 2012) is 4161 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 105, but not defined == Missing Reference: 'RFC4872' is mentioned on line 106, but not defined == Missing Reference: 'RFC4783' is mentioned on line 107, but not defined == Missing Reference: 'RFC4974' is mentioned on line 108, but not defined == Unused Reference: 'I-D.ietf-ccamp-oam-configuration-fwk' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 252, 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 270, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-oam-configuration-fwk-08 == Outdated reference: A later version (-03) exists of draft-margaria-ccamp-lsp-attribute-ero-02 ** 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-10 Summary: 2 errors (**), 0 flaws (~~), 11 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: June 7, 2013 Z. Li 6 China Mobile 7 December 4, 2012 9 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 10 draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05 12 Abstract 14 This document specifies extensions to RSVP-TE to support lock 15 instruct and loopback mechanism for LSPs. The mechanisms are 16 applicable to technologies which use GMPLS as control plane. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 7, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Extensions to RSVP-TE . . . . . . . . . . . . . . . . . . . . . 3 60 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The requirements for Lock Instruct (LI) and Loopback (LB) in MPLS-TP 74 are specified in [RFC5860], and the framework of LI and LB is 75 specified in [RFC6371]. 77 In general the LI and LB are useful OAM functions for technologies 78 which use GMPLS as control plane, e.g. time-division multiplexing, 79 wavelength-division multiplexing, and packet switching. It is 80 natural to use and extend the GMPLS control plane protocol to provide 81 a unified approach for LI and LB provisioning in all these 82 technologies. 84 This document specifies extensions to RSVP-TE to support lock 85 instruct and loopback mechanism for LSPs. The mechanisms are 86 applicable to technologies which use GMPLS as control plane. For 87 MPLS-TP network, the mechanisms defined in this document are 88 complementary to [RFC6435]. 90 2. Extensions to RSVP-TE 92 The A (Administratively down) bit in ADMIN_STATUS object [RFC3471] 93 [RFC3473] is used to indicate the lock/unlock of the LSP. Format of 94 ADMIN_STATUS Object is as below: 96 0 1 2 3 97 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 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Length | Class-Num(196)| C-Type (1) | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 |R| Reserved |H|L|I|C|T|A|D| 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Reflect (R): 1 bit - see [RFC3471] 105 Handover (H): 1 bit - see [RFC5852] 106 Lockout (L): 1 bit - see [RFC4872] 107 Inhibit Alarm Indication (I): 1 bit - see [RFC4783] 108 Call Control (C): 1 bit - see [RFC4974] 109 Testing (T): 1 bit - see [RFC3471] 110 Administratively down (A): 1 bit - see [RFC3471], reused for Lock 111 Deletion in progress (D): 1 bit - see [RFC3471] 113 A new bit is defined in Attribute Flags TLV [RFC5420] to indicate the 114 loopback mode. The bit number is TBA. 116 Bit Number Name and Usage 117 TBA Loopback mode desired. 118 This flag indicates a particular node on the LSP is required 119 to enter loopback mode. 120 This MAY also be used for specifying the loopback state 121 of the node. 123 3. Operations 125 3.1. Lock Instruct 127 When an ingress LSR wants to put an LSP into lock mode, it MUST send 128 a Path message with the Administratively down (A) bit and the Reflect 129 (R) bit in ADMIN_STATUS Object set. The intermediate nodes SHOULD 130 forward the message with the A bit unchanged to the downstream . 132 On receipt of this Path message, the egress LSR SHOULD try to take 133 the LSP out of service. If the egress LSR locks the LSP 134 successfully, it SHOULD send a Resv message with the A bit in 135 ADMIN_STATUS object set. Otherwise, it SHOULD send a PathErr message 136 with the Error Code "OAM Problem" and the new Error Value "Lock 137 Failure", and the following Resv messages SHOULD be sent with the A 138 bit cleared. With this procedure, the intermediate nodes would also 139 be aware of whether the LSP is in Lock mode or not. 141 When an LSP is put in lock mode, the subsequent Path and Resv 142 messages SHOULD keep the A bit in ADMIN_STATUS Object set. 144 When the ingress LSR wants to take the LSP out of the lock mode, it 145 MUST send a Path message with the A bit in ADMIN_STATUS Object 146 cleared. The intermediate nodes SHOULD forward this message with the 147 A bit unchanged to the downstream. 149 On receipt of this Path message, the egress LSR SHOULD try to bring 150 the LSP back to service. If the egress LSR unlocks the LSP 151 successfully, it SHOULD send a Resv message with the A bit in 152 ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr 153 message with the Error Code "OAM Problem" and the new Error Value 154 "Unlock Failure", and the following Resv messages SHOULD be sent with 155 the A bit set. 157 When an LSP is taken out of lock mode, the subsequent Path and Resv 158 messages SHOULD keep the A bit in ADMIN_STATUS Object cleared. 160 3.2. Loopback 162 The loopback request can be sent either to the egress LSR or to a 163 particular intermediate node. The mechanism defined in 164 [I-D.margaria-ccamp-lsp-attribute-ero] is used for addressing the 165 loopback request to a particular node on the LSP. The loopback 166 request is acceptable only when the LSP is in lock mode. 168 When a ingress LSR wants to put a particular LSR on the LSP into 169 loopback mode, it MUST send a Path message with the Loopback bit in 170 the Attribute Flags TLV set. The mechanism defined in 171 [I-D.margaria-ccamp-lsp-attribute-ero] is used to address the 172 loopback request to the particular LSR. The Administratively down 173 (A) bit in ADMIN_STATUS object SHOULD be set to keep the LSP in lock 174 mode. 176 On receipt of this Path message, the target LSR of the loopback 177 request SHOULD try to put the LSP into loopback mode. If the node 178 puts the LSP into loopback mode successfully, it SHOULD set the 179 Loopback (B) bit in the RRO Attribute subobject [RFC5420] and push 180 this subobject onto the RRO object in the corresponding Resv message. 181 The Administratively down (A) bit in ADMIN_STATUS object SHOULD also 182 be set in the Resv message. If the node cannot put the LSP into 183 loopback mode, it SHOULD send a PathErr message with the Error Code 184 "OAM Problem" and the new Error Value "Loopback Failure". 186 When the ingress LSR wants to take the LSP out of loopback mode, it 187 MUST send a Path message with the Loopback (B) bit in the Attribute 188 Flags TLV cleared. The mechanism defined in 189 [I-D.margaria-ccamp-lsp-attribute-ero] is used to indicate that the 190 particular LSR SHOULD exit loopback mode for this LSP. The 191 Administratively down (A) bit in ADMIN_STATUS object SHOULD be set. 193 On receipt of this Path message, the target LSR SHOULD try to take 194 the LSP out of loopback mode. If the node takes the LSP out of 195 loopback mode successfully, it SHOULD clear the Loopback (B) Bit in 196 the RRO Attribute subobject and push this subobject onto the RRO 197 object in the corresponding Resv message. The Administratively down 198 (A) Bit in ADMIN_STATUS Object SHOULD be set. Otherwise, the node 199 SHOULD send a PathErr message with the Error Code "OAM Problem" and 200 the new Error Value "Exit Loopback Failure". 202 4. IANA Considerations 204 One bit number Loopback needs to be assigned in the Attribute Flags 205 registry. 207 Four new Error Values need to be allocated for Error Code "OAM 208 Problem": "Lock Failure", "Unlock Failure", "Loopback Failure", "Exit 209 Loopback Failure". 211 5. Security Considerations 213 This document does not introduce any new security issues above those 214 identified in [RFC3209] and [RFC3473]. 216 6. Acknowledgements 218 The authors would like to thank Greg Mirsky, Lou Berger and Francesco 219 Fondelli for their comments and suggestions. 221 7. References 223 7.1. Normative References 225 [I-D.ietf-ccamp-oam-configuration-fwk] 226 Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE 227 extensions for OAM Configuration", 228 draft-ietf-ccamp-oam-configuration-fwk-08 (work in 229 progress), July 2012. 231 [I-D.margaria-ccamp-lsp-attribute-ero] 232 Margaria, C., Schroetter, D., Martinelli, G., Balls, S., 233 and B. Wright, "LSP Attribute in ERO", 234 draft-margaria-ccamp-lsp-attribute-ero-02 (work in 235 progress), October 2012. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 241 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 242 Tunnels", RFC 3209, December 2001. 244 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 245 (GMPLS) Signaling Functional Description", RFC 3471, 246 January 2003. 248 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 249 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 250 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 252 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 253 (GMPLS) Architecture", RFC 3945, October 2004. 255 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 256 Ayyangarps, "Encoding of Attributes for MPLS LSP 257 Establishment Using Resource Reservation Protocol Traffic 258 Engineering (RSVP-TE)", RFC 5420, February 2009. 260 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 261 Operations, Administration, and Maintenance (OAM) in MPLS 262 Transport Networks", RFC 5860, May 2010. 264 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 265 Maintenance Framework for MPLS-Based Transport Networks", 266 RFC 6371, September 2011. 268 7.2. Informative References 270 [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 271 Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D., 272 and A. Takacs, "Configuration of Pro-Active Operations, 273 Administration, and Maintenance (OAM) Functions for MPLS- 274 based Transport Networks using RSVP-TE", 275 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10 (work in 276 progress), October 2012. 278 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 279 and X. Dai, "MPLS Transport Profile Lock Instruct and 280 Loopback Functions", RFC 6435, November 2011. 282 Authors' Addresses 284 Jie Dong 285 Huawei Technologies 286 Huawei Building, No.156 Beiqing Rd. 287 Beijing 100095 288 China 290 Email: jie.dong@huawei.com 291 Mach Chen 292 Huawei Technologies 293 Huawei Building, No.156 Beiqing Rd. 294 Beijing 100095 295 China 297 Email: mach.chen@huawei.com 299 Zhenqiang Li 300 China Mobile 301 Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. 302 Beijing 100053 303 China 305 Email: lizhenqiang@chinamobile.com