idnits 2.17.1 draft-boutros-mpls-tp-fault-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Faults are indicated by sending FM messages. The op code is set to the value corresponding to the fault. A cause may be communicated by setting the corresponding cause code. If no cause is to be communicated this field MUST be set to zero. The R-flag MUST be set to zero. The refresh timer is set to the maximum time between successive FM messages. This value SHOULD not be changed on successive FM messages. -- The document date (July 13, 2009) is 5399 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) == Unused Reference: '4' is defined on line 380, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 384, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-mpls-tp-ach-tlv-00 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Boutros 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track G. Swallow 5 Expires: January 14, 2010 D. Ward 6 S. Bryant 7 Cisco Systems, Inc. 8 July 13, 2009 10 MPLS-TP Fault OAM 11 draft-boutros-mpls-tp-fault-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This draft specifies a fault management indications for MPLS 50 Transport Profile(MPLS-TP) Label Switched Paths (LSPs). The 51 notification mechanism employs a generic method for a Maintenance End 52 Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a 53 fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and 54 Maintenance (OAM) message is defined. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. MPLS-TP Fault Indications . . . . . . . . . . . . . . . . . . . 4 61 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 4 62 2.2. MPLS-TP Reverse Defect Indication . . . . . . . . . . . . . 5 63 2.3. MPLS-TP Locked Indication . . . . . . . . . . . . . . . . . 5 64 3. MPLS-OAM Fault Message . . . . . . . . . . . . . . . . . . . . 5 65 3.1. MPLS Fault Management Channel . . . . . . . . . . . . . . . 5 66 3.2. MPLS-TP Fault Message Format . . . . . . . . . . . . . . . 6 67 4. Sending and Receiving Fault Indications . . . . . . . . . . . . 7 68 4.1. Sending a Fault Indication . . . . . . . . . . . . . . . . 7 69 4.2. Clearing a Fault Indication . . . . . . . . . . . . . . . . 8 70 4.3. Receiving a Fault Indication . . . . . . . . . . . . . . . 8 71 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 In traditional transport networks, circuits such as T1 lines are 82 provisioned on multiple switches. When a fault occurs on any link or 83 node along the path of such a transport circuit, alarms are generated 84 which may in turn activate a backup circuit. MPLS-TP LSP emulating 85 traditional transport circuits needs to provide the same Fault 86 Management (FM) capability. In this document, an MPLS-TP LSP means 87 either an MPLS transport LSP. 89 This document specifies an MPLS-TP Fault Management mechanism based 90 on a new type of MPLS OAM message called an "MPLS-OAM Fault 91 Management (FM)" message. This message is used to convey the 92 following: 94 Alarm Indication Signal (AIS) 96 Reverse Defect Indication (RDI) 98 Locked Indication (LCK) 100 The AIS message is generated in response to detecting defects in the 101 server layer. Its primary purpose is to suppress alarms in the 102 MPLS-TP layer network above the level at which the defect occurs. 103 The AIS message MAY also be used to trigger fault recovery 104 mechanisms. 106 The RDI message is generated by a MEP experiencing a defect to inform 107 its peer MEP(s) of the condition. 109 The LCK message is generated when a server layer entity has been 110 administratively locked to communicated that condition to inform the 111 client layer entities of that condition. When an MPLS-TP LSP is 112 administratively locked it is not available to carry client traffic. 113 Its purpose is to suppress alarms in the MPLS-TP layer network above 114 the level at which the defect occurs and to allow the clients to 115 differentiate the lock condition from a defect condition. 117 1.1. Terminology 119 ACH: Associated Channel Header 121 AII: Attachment Interface Identifier 123 ASN: Autonomous System Number 125 FEC: Forwarding Equivalence Class 126 FM: Fault Management 128 LSP: Label Switched Path 130 LSR: Label Switching Router 132 MEP: Maintenance End Point 134 MIP: Maintenance Intermediate Point 136 MPLS: Multi-Protocol Label Switching 138 MPLS-TP: MPLS Transport Profile 140 OAM: Operations, Administration and Maintenance 142 P2MP: Point to Multi-Point 144 P2P: Point to Point 146 PSC: Protection State Coordination 148 PW: Pseudowire 150 TLV: Type Length Value 152 TTL: Time To Live 154 Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [1]. 160 2. MPLS-TP Fault Indications 162 This document defines messages to indicate three kinds of fault, 163 Alarm Indication Signal, Reverse Defect Indication, and Lock 164 Indication. These are described in below. 166 2.1. MPLS-TP Alarm Indication Signal 168 The AIS message is generated in response to detecting defects in the 169 server layer. Its primary purpose is to suppress alarms in the 170 MPLS-TP layer networks above the level at which the defect occurs. 171 The AIS message MAY also be used to trigger fault recovery 172 mechanisms. 174 When a server MEP detects a fault, AIS messages are generated by the 175 convergence server-to-client adaptation function. The messages are 176 sent to the client MEPs in the direction opposite the peer server 177 MEP(s). This message is sent periodically until the fault is 178 cleared. 180 2.2. MPLS-TP Reverse Defect Indication 182 Reverse Defect Indication is used to communicate defects from the MEP 183 which has detected the fault to its peer MEP(s). 185 The messages are sent in-band to the client MEPs in the direction 186 opposite the peer server MEP(s). This message is sent periodically 187 until the fault is cleared. 189 2.3. MPLS-TP Locked Indication 191 Locked Indication is used to communicate that the facility associated 192 with the MEP has been administratively locked and is not available 193 for client traffic. That is, the facility has been taken out-of- 194 service. This allows a MEP receiving a LCK message to differentiate 195 between a defect condition and an administrative locking action. 197 When a server MEP is locked, LCK messages are generated by the 198 convergence server-to-client adaptation function. The messages are 199 sent to the client MEPs in the direction opposite the peer server 200 MEP(s). This message is sent periodically until the lock is cleared. 202 3. MPLS-OAM Fault Message 204 A single fault message is used to carry fault indications. The 205 particular fault is identified by an op-code. The message is in turn 206 carried in a Fault Management channel identified by the Associated 207 Channel Header. On this channel ACH TLVs are used to carry any 208 necessary identifiers. In particular it is used to carry the sending 209 MEP-ID. 211 3.1. MPLS Fault Management Channel 213 Fault Management messages are carried in the ACH as defined in RFC 214 5586 [2]. MPLS-TP Fault Management (FM) code point = 0xHH. [HH to 215 be assigned by IANA from the PW Associated Channel Type registry.] 217 Messages sent on the MPLS-TP FM Channel MUST be preceded by an ACH 218 TLV Header and MUST include the Sending-MEP TLV as defined in 219 draft-ietf-mpls-ach-tlv. [3] The FM ACH Channel and ACH TLVs are 220 shown below. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |0 0 0 1|Version| Reserved | 0xHH MPLS-TP Fault Management | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ACH TLV Header | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ~ 230 ~ zero or more ACH TLVs ~ 231 ~ | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ~ 234 ~ MPLS-TP Fault Message ~ 235 ~ | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1: ACH Indication of MPLS-TP Fault 240 3.2. MPLS-TP Fault Message Format 242 The format of an MPLS-TP Fault Message is shown below. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Version | OpCode | Cause Code | Flags |R| 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Refresh Timer | Total TLV Length | TLVs | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | TLVs | 252 ~ ~ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2: MPLS-TP OAM Message Format 257 Version 259 The Version Number is currently 1. 261 Flags 263 One flag, the R-Flag is defined. The other flags in this field 264 MUST be set to zero on transmission and ignored on receipt. 266 R-flag 267 The R-flag is normally set to zero. A setting on one inticates 268 the removal of a previously sent FM condition. 270 Op Code 272 The Op Code indicates the type of fault as listed in the table 273 below. 275 Op Code Description 276 ------- ------------- 277 0x0 Reserved 278 0x1 Alarm Indication Signal (AIS) 279 0x2 Remote Defect Indication (RDI) 280 0x3 Locked indication (LCK) 282 Refresh Timer 284 The maximum time between successive FM messages specified in 285 seconds. The range is 1 to 65535. The value 0 is not permitted. 286 The default value is 60. 288 Total TLV Length 290 The total TLV length is the total of all included TLVs. At this 291 time no TLVs are defined. 293 Cause Code 295 The cause of the fault encoded as follows 297 Cause Code Meaning 298 ---------- ------- 299 0x0 No indication 300 0x1 Link failure 301 0x2 Node failure 302 0x3 Low memory 303 0x4 High CPU 304 0x5 Resource unavailable 306 4. Sending and Receiving Fault Indications 308 4.1. Sending a Fault Indication 310 Faults are indicated by sending FM messages. The op code is set to 311 the value corresponding to the fault. A cause may be communicated by 312 setting the corresponding cause code. If no cause is to be 313 communicated this field MUST be set to zero. The R-flag MUST be set 314 to zero. The refresh timer is set to the maximum time between 315 successive FM messages. This value SHOULD not be changed on 316 successive FM messages. 318 The message is then prepended with an ACH TLV header and the Sending- 319 MEP TLV. For AIS messages (which are sent from the convergence 320 server-to-client adaptation function) ID of the server MEP is used. 322 The message is then sent. The message MUST be refreshed twice at an 323 interval of one second. Further refreshes are sent according to the 324 value of the refresh timer. Refreshing continues until the fault is 325 cleared. 327 4.2. Clearing a Fault Indication 329 Ceasing to send FM messages will clear the fault after 3.5 times the 330 Refresh Timer. To clear a fault more quickly, the following 331 procedure is used. The R-FLag of the FM message is set to one. 332 Other fields of the FM message SHOULD NOT be modified. The message 333 is sent immediately and then refreshed twice at at an interval of one 334 second. 336 4.3. Receiving a Fault Indication 338 When a FM Indication is received, a MEP examines it to ensure that 339 that it is well formed. If the op code is unknown, the message is 340 ignored. If the cause code is unknown it is interpreted as "No 341 Indication". If the R-FLag is zero, the Sending-MEP_ID noted and the 342 corresponding defect state is entered. A timer is set to 3.5 times 343 the refresh timer. If the message is not refreshed within this 344 period, the fault is cleared. A message is considered a refresh if 345 the op code and Sending-MEP_ID match an existing fault and the R-Flag 346 is set to zero. 348 If the R-Flag is set to one, the MEP checks to see if a fault 349 matching the op code and Sending-MEP_ID exists. If it does, that 350 fault is cleared. Otherwise the message is ignored. 352 5. Issues 354 1. Are cause codes useful? 356 2. Should we include a TLV like the security TLV in BFD? 358 6. Security Considerations 360 To be added. 362 7. IANA Considerations 364 To be added. 366 8. References 368 8.1. Normative References 370 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 371 Levels", BCP 14, RFC 2119, March 1997. 373 [2] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 374 Associated Channel", RFC 5586, June 2009. 376 [3] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D. 377 Ward, "Definition of ACH TLV Structure", 378 draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009. 380 [4] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. 381 Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-09 382 (work in progress), June 2009. 384 [5] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in 385 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-02 386 (work in progress), June 2009. 388 8.2. Informative References 390 Authors' Addresses 392 Sami Boutros 393 Cisco Systems, Inc. 394 3750 Cisco Way 395 San Jose, California 95134 396 USA 398 Email: sboutros@cisco.com 399 Siva Sivabalan 400 Cisco Systems, Inc. 401 2000 Innovation Drive 402 Kanata, Ontario K2K 3E8 403 Canada 405 Email: msiva@cisco.com 407 George Swallow 408 Cisco Systems, Inc. 409 300 Beaver Brook Road 410 Boxborough, Massachusetts 01719 411 United States 413 Email: swallow@cisco.com 415 David Ward 416 Cisco Systems, Inc. 417 3750 Cisco Way 418 San Jose, California 95134 419 USA 421 Email: wardd@cisco.com 423 Stewart Bryant 424 Cisco Systems, Inc. 425 250, Longwater 426 Green Park, Reading RG2 6GB 427 UK 429 Email: stbryant@cisco.com