MPLS Working Group S. Boutros Internet-Draft S. Sivabalan Intended status: Standards Track G. Swallow Expires: January 14, 2010 D. Ward S. Bryant Cisco Systems, Inc. July 13, 2009 MPLS-TP Fault OAM draft-boutros-mpls-tp-fault-02 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 January 14, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Boutros, et al. Expires January 14, 2010 [Page 1] Internet-Draft MPLS-TP Fault OAM July 2009 Abstract This draft specifies a fault management indications for MPLS Transport Profile(MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and Maintenance (OAM) message is defined. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MPLS-TP Fault Indications . . . . . . . . . . . . . . . . . . . 4 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . . 4 2.2. MPLS-TP Reverse Defect Indication . . . . . . . . . . . . . 5 2.3. MPLS-TP Locked Indication . . . . . . . . . . . . . . . . . 5 3. MPLS-OAM Fault Message . . . . . . . . . . . . . . . . . . . . 5 3.1. MPLS Fault Management Channel . . . . . . . . . . . . . . . 5 3.2. MPLS-TP Fault Message Format . . . . . . . . . . . . . . . 6 4. Sending and Receiving Fault Indications . . . . . . . . . . . . 7 4.1. Sending a Fault Indication . . . . . . . . . . . . . . . . 7 4.2. Clearing a Fault Indication . . . . . . . . . . . . . . . . 8 4.3. Receiving a Fault Indication . . . . . . . . . . . . . . . 8 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Boutros, et al. Expires January 14, 2010 [Page 2] Internet-Draft MPLS-TP Fault OAM July 2009 1. Introduction In traditional transport networks, circuits such as T1 lines are provisioned on multiple switches. When a fault occurs on any link or node along the path of such a transport circuit, alarms are generated which may in turn activate a backup circuit. MPLS-TP LSP emulating traditional transport circuits needs to provide the same Fault Management (FM) capability. In this document, an MPLS-TP LSP means either an MPLS transport LSP. This document specifies an MPLS-TP Fault Management mechanism based on a new type of MPLS OAM message called an "MPLS-OAM Fault Management (FM)" message. This message is used to convey the following: Alarm Indication Signal (AIS) Reverse Defect Indication (RDI) Locked Indication (LCK) The AIS message is generated in response to detecting defects in the server layer. 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 also be used to trigger fault recovery mechanisms. The RDI message is generated by a MEP experiencing a defect to inform its peer MEP(s) of the condition. The LCK 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. 1.1. Terminology ACH: Associated Channel Header AII: Attachment Interface Identifier ASN: Autonomous System Number FEC: Forwarding Equivalence Class Boutros, et al. Expires January 14, 2010 [Page 3] Internet-Draft MPLS-TP Fault OAM July 2009 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 [1]. 2. MPLS-TP Fault Indications This document defines messages to indicate three kinds of fault, Alarm Indication Signal, Reverse Defect Indication, and Lock Indication. These are described in below. 2.1. MPLS-TP Alarm Indication Signal The AIS message is generated in response to detecting defects in the server layer. Its primary purpose is to suppress alarms in the MPLS-TP layer networks above the level at which the defect occurs. The AIS message MAY also be used to trigger fault recovery mechanisms. Boutros, et al. Expires January 14, 2010 [Page 4] Internet-Draft MPLS-TP Fault OAM July 2009 When a server MEP detects a fault, AIS messages are generated by the convergence server-to-client adaptation function. The messages are sent to the client MEPs in the direction opposite the peer server MEP(s). This message is sent periodically until the fault is cleared. 2.2. MPLS-TP Reverse Defect Indication Reverse Defect Indication is used to communicate defects from the MEP which has detected the fault to its peer MEP(s). The messages are sent in-band to the client MEPs in the direction opposite the peer server MEP(s). This message is sent periodically until the fault is cleared. 2.3. MPLS-TP Locked Indication Locked Indication is used to communicate that the facility associated with the MEP has been administratively locked and is not available for client traffic. That is, the facility has been taken out-of- service. This allows a MEP receiving a LCK message to differentiate between a defect condition and an administrative locking action. When a server MEP is locked, LCK messages are generated by the convergence server-to-client adaptation function. The messages are sent to the client MEPs in the direction opposite the peer server MEP(s). This message is sent periodically until the lock is cleared. 3. MPLS-OAM Fault Message A single fault message is used to carry fault indications. The particular fault is identified by an op-code. The message is in turn carried in a Fault Management channel identified by the Associated Channel Header. On this channel ACH TLVs are used to carry any necessary identifiers. In particular it is used to carry the sending MEP-ID. 3.1. MPLS Fault Management Channel Fault Management messages are carried in the ACH as defined in RFC 5586 [2]. MPLS-TP Fault Management (FM) code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] Messages sent on the MPLS-TP FM Channel MUST be preceded by an ACH TLV Header and MUST include the Sending-MEP TLV as defined in draft-ietf-mpls-ach-tlv. [3] The FM ACH Channel and ACH TLVs are shown below. Boutros, et al. Expires January 14, 2010 [Page 5] Internet-Draft MPLS-TP Fault OAM July 2009 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 MPLS-TP Fault Management | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ zero or more ACH TLVs ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ MPLS-TP Fault Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Fault 3.2. MPLS-TP Fault Message Format The format of an MPLS-TP Fault 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | OpCode | Cause Code | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | Total TLV Length | TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Boutros, et al. Expires January 14, 2010 [Page 6] Internet-Draft MPLS-TP Fault OAM July 2009 The R-flag is normally set to zero. A setting on one inticates the removal of a previously sent FM condition. Op Code The Op Code indicates the type of fault as listed in the table below. Op Code Description ------- ------------- 0x0 Reserved 0x1 Alarm Indication Signal (AIS) 0x2 Remote Defect Indication (RDI) 0x3 Locked indication (LCK) 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. Total TLV Length The total TLV length is the total of all included TLVs. At this time no TLVs are defined. Cause Code The cause of the fault encoded as follows Cause Code Meaning ---------- ------- 0x0 No indication 0x1 Link failure 0x2 Node failure 0x3 Low memory 0x4 High CPU 0x5 Resource unavailable 4. Sending and Receiving Fault Indications 4.1. Sending a Fault Indication 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 Boutros, et al. Expires January 14, 2010 [Page 7] Internet-Draft MPLS-TP Fault OAM July 2009 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 message is then prepended with an ACH TLV header and the Sending- MEP TLV. For AIS messages (which are sent from the convergence server-to-client adaptation function) ID of the server MEP is used. 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 fault is cleared. 4.2. Clearing a Fault Indication Ceasing to send FM messages will clear the fault after 3.5 times the Refresh Timer. To clear a fault 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 at an interval of one second. 4.3. Receiving a Fault Indication When a FM Indication is received, a MEP examines it to ensure that that it is well formed. If the op code is unknown, the message is ignored. If the cause code is unknown it is interpreted as "No Indication". If the R-FLag is zero, the Sending-MEP_ID noted and the corresponding defect state is entered. A timer is set to 3.5 times the refresh timer. If the message is not refreshed within this period, the fault is cleared. A message is considered a refresh if the op code and Sending-MEP_ID match an existing fault and the R-Flag is set to zero. If the R-Flag is set to one, the MEP checks to see if a fault matching the op code and Sending-MEP_ID exists. If it does, that fault is cleared. Otherwise the message is ignored. 5. Issues 1. Are cause codes useful? 2. Should we include a TLV like the security TLV in BFD? Boutros, et al. Expires January 14, 2010 [Page 8] Internet-Draft MPLS-TP Fault OAM July 2009 6. Security Considerations To be added. 7. IANA Considerations To be added. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [3] 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. [4] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-09 (work in progress), June 2009. [5] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-02 (work in progress), June 2009. 8.2. Informative References Authors' Addresses Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Boutros, et al. Expires January 14, 2010 [Page 9] Internet-Draft MPLS-TP Fault OAM July 2009 Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States Email: swallow@cisco.com David Ward Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: wardd@cisco.com Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK Email: stbryant@cisco.com Boutros, et al. Expires January 14, 2010 [Page 10]