MPLS Working Group G. Swallow, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track Expires: June 19, 2010 A. Fulignoli, Ed. Ericsson M. Vigoureux, Ed. Alcatel-Lucent December 16, 2009 MPLS Fault Management OAM draft-sfv-mpls-tp-fault-01 Abstract This draft specifies OAM messages to indicate service disruptive conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010. Swallow, et al. Expires June 19, 2010 [Page 1] Internet-Draft MPLS Fault Mangement OAM December 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Swallow, et al. Expires June 19, 2010 [Page 2] Internet-Draft MPLS Fault Mangement OAM December 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 5 2.2. MPLS-TP Link Down Indication . . . . . . . . . . . . . . . 5 2.3. MPLS-TP Locked Report . . . . . . . . . . . . . . . . . . . 6 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . . 6 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 5. Sending and Receiving Fault Management Messages . . . . . . . . 8 5.1. Sending a Fault Management Message . . . . . . . . . . . . 8 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 8 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . . 8 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Swallow, et al. Expires June 19, 2010 [Page 3] Internet-Draft MPLS Fault Mangement OAM December 2009 1. Introduction In traditional transport networks, circuits such as T1 lines are provisioned on multiple switches. When a disruption occurs on any link or node along the path of such a transport circuit, alarms are generated which may in turn suppress alarms and/or activate a backup circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to emulate traditional transport circuits. Therefore a Fault Management (FM) capability must be defined for MPLS. This capability is being defined to meet the MPLS-TP requirements as defined in RFC 5654 [1], and the MPLS-TP Operations, Administration and Maintenance Requirements as defined in draft-ietf-mpls-tp-oam-requirements [2]. However, this mechanism is intended to be applicable to other aspects of MPLS as well. Three broad classes service disruptive conditions are identified. 1. Defect: the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted. 2. Fault: the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (e.g., Administrative Locking). A fault is a persistent defect. 3. Lock: an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the LSP) can be mapped on an LSP. This document specifies an MPLS OAM channel called an "MPLS-OAM Fault Management (FM)" channel. A single message format and a set of procedures are defined to communicate service disruptive conditions from the location where they occur to the endpoints of LSPs which are affected by those conditions. Multiple message types are used to indicate the particular condition. Corresponding to the three classes of service disruptive conditions listed above, three messages are defined to communicate the type of condition. These are known as: Alarm Indication Signal (AIS) Link Down Indication (LDI) Locked Report (LKR) Swallow, et al. Expires June 19, 2010 [Page 4] Internet-Draft MPLS Fault Mangement OAM December 2009 1.1. Terminology ACH: Associated Channel Header AII: Attachment Interface Identifier ASN: Autonomous System Number FEC: Forwarding Equivalence Class FM: Fault Management LSP: Label Switched Path LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS: Multi-Protocol Label Switching MPLS-TP: MPLS Transport Profile OAM: Operations, Administration and Maintenance P2MP: Point to Multi-Point P2P: Point to Point PSC: Protection State Coordination PW: Pseudowire TLV: Type Length Value TTL: Time To Live Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. MPLS Fault Management Messages This document defines messages to indicate three types of service Swallow, et al. Expires June 19, 2010 [Page 5] Internet-Draft MPLS Fault Mangement OAM December 2009 disruptive conditions, Alarm Indication Signal, Link Down Indication, and Locked Report. These semantics of the individual messages are described in subsections below. Although only one of the conditions is named "Fault", we use the term "Fault Management" to generically mean management of all three conditions. Fault Management messages are carried in-band by using the Associated Channel Header (ACH) and Generic Associated Channel Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and delivery of Fault Management messages, the Fault Management Channel is identified by a unique codepoint. When a server MEP detects a service disruptive condition, Fault Management messages are generated by the convergence server-to-client adaptation function. The messages are sent to the client MEPs by inserting them into the affected LSPs in the direction opposite to the detecting MEP's peer server MEP(s). The message is sent periodically until the condition is cleared. 2.1. MPLS-TP Alarm Indication Signal The MPLS-TP Alarm Indication Signal (AIS) message is generated in response to detecting defects in the server layer. The AIS message SHOULD be sent as soon is the condition is detected, that is before any determination has been made as to whether the condition is fatal. For example an AIS message may be sent during a protection switching event and would cease being sent if the protection switch was successful in restoring the link. Its primary purpose is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs. The AIS message MAY be used to trigger recovery mechanisms. It should be noted that such use would be subject to false positives, e.g. unnecessary protection switching events in the client layer. 2.2. MPLS-TP Link Down Indication The LDI message is generated in response to detecting a fatal failure in the server layer. The LDI message MUST NOT be sent until the defect has been determined to be fatal. For example during a protection switching event LDI messages are not sent. However if the protection switch was unsuccessful in restoring the link within the expected repair time, an LDI message MUST be sent. The receipt of an LDI message SHOULD be treated as the equivalent of loss of continuity at the client layer. Like AIS it also is used to suppress alarms. Swallow, et al. Expires June 19, 2010 [Page 6] Internet-Draft MPLS Fault Mangement OAM December 2009 2.3. MPLS-TP Locked Report The MPLS-TP Locked Report (LKR) message is generated when a server layer entity has been administratively locked to communicated that condition to inform the client layer entities of that condition. When an MPLS-TP LSP is administratively locked it is not available to carry client traffic. Its purpose is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs and to allow the clients to differentiate the lock condition from a defect condition. The receipt of an LKR message SHOULD be treated as the equivalent of loss of continuity at the client layer. Like AIS it also is used to suppress alarms. 3. MPLS Fault Management Channel The MPLS Fault Management channel is identified by the ACH as defined in RFC 5586 [4] with the Channel Type set to the MPLS Fault Management (FM) code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] The FM Channel uses ACH TLVs and MUST include the ACH TLV header. The FM ACH Channel and ACH TLVs are shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xHH Fault Management Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ zero or more ACH TLVs ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ MPLS Fault Management Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of the MPLS-TP Fault Management Channel The Fault Management Channel is 0xHH (to be assigned by IANA) The ACH TLVs may include (but are not limited to) IF-ID, Global-ID, and ICC. Swallow, et al. Expires June 19, 2010 [Page 7] Internet-Draft MPLS Fault Mangement OAM December 2009 4. MPLS Fault Management Message Format The format of the Fault Management message is shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers |Flgs |R| Msg Type | Refresh Timer | Total TLV Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS-TP OAM Message Format Version The Version Number is currently 1. Flags One flag, the R-Flag is defined. The other flags in this field MUST be set to zero on transmission and ignored on receipt. R-flag The R-flag is normally set to zero. A setting of one indicates the removal of a previously sent FM condition. Message Type The Message Type indicates the type of condition as listed in the table below. Msg Type Description -------- ----------------------------- 0x0 Reserved 0x1 Alarm Indication Signal (AIS) 0x2 Link Down Indication (LDI) 0x3 Locked Report (LKR) Refresh Timer The maximum time between successive FM messages specified in seconds. The range is 1 to 65535. The value 0 is not permitted. The default value is 60. Swallow, et al. Expires June 19, 2010 [Page 8] Internet-Draft MPLS Fault Mangement OAM December 2009 Total TLV Length The total TLV length is the total of all included TLVs. At this time no TLVs are defined. 5. Sending and Receiving Fault Management Messages 5.1. Sending a Fault Management Message Service disruptive conditions are indicated by sending FM messages. The message type is set to the value corresponding to the condition. The refresh timer is set to the maximum time between successive FM messages. This value SHOULD not be changed on successive FM messages. The message is then prepended with an ACH TLV header. A Global-ID TLV or an ICC TLV MAY be included. The IF-ID TLV SHOULD be included. If the R-Flag clearing procedures are to be used, the IF-ID TLV MUST be included. The message is then sent. The message MUST be refreshed twice at an interval of one second. Further refreshes are sent according to the value of the refresh timer. Refreshing continues until the condition is cleared. 5.2. Clearing a FM Indication Ceasing to send FM messages will clear the indication after 3.5 times the Refresh Timer. To clear an indication more quickly, the following procedure is used. The R-Flag of the FM message is set to one. Other fields of the FM message SHOULD NOT be modified. The message is sent immediately and then refreshed twice at an interval of one second. 5.3. Receiving a FM Indication When a FM message is received, a MEP examines it to ensure that that it is well formed. If the message type is unknown, the message is ignored. If the R-Flag is zero, the condition corresponding to the message type is entered. A timer is set to 3.5 times the refresh timer. If the message is not refreshed within this period, the condition is cleared. A message is considered a refresh if the message type and IF-ID match an existing condition and the R-Flag is set to zero. If the R-Flag is set to one, the MEP checks to see if a condition matching the message type and IF_ID exists. If it does, that Swallow, et al. Expires June 19, 2010 [Page 9] Internet-Draft MPLS Fault Mangement OAM December 2009 condition is cleared. Otherwise the message is ignored. 6. Issues 1. Should we include a TLV like the security TLV in BFD? 7. Security Considerations To be added. 8. IANA Considerations To be added. 9. References 9.1. Normative References [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-03 (work in progress), August 2009. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [5] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D. Ward, "Definition of ACH TLV Structure", draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009. 9.2. Informative References Swallow, et al. Expires June 19, 2010 [Page 10] Internet-Draft MPLS Fault Mangement OAM December 2009 Authors' Addresses George Swallow (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States Email: swallow@cisco.com Annamaria Fulignoli (editor) Ericsson Email: annamaria.fulignoli@ericsson.com Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France Email: martin.vigoureux@alcatel-lucent.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com David Ward Juniper Networks, Inc. Email: dward@juniper.net Swallow, et al. Expires June 19, 2010 [Page 11] Internet-Draft MPLS Fault Mangement OAM December 2009 Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK Email: stbryant@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com Swallow, et al. Expires June 19, 2010 [Page 12]