Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan (Ed.) Intended status: Standards Track George Swallow Expires: September 2009 David Ward Stewart Bryant Cisco Systems, Inc. March 9, 2009 Fault Management for the MPLS Transport Profile draft-boutros-mpls-tp-fault-01.txt 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 September 9, 2009. Abstract This draft specifies a fault management mechanism for MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP). The proposed mechanism is based on a generic way of notifying a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) of a fault on an MPLS-TP LSP using new type of MPLS Operation, Administration, and Maintenance (OAM) messages. Boutros Expires September 9, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. MPLS-TP Fault Mechanism........................................3 4. MPLS-OAM Fault Message.........................................4 4.1. In-band Message Identification............................4 4.2. Out-of-band Message Identification........................4 4.3. MPLS-TP Fault Message Format..............................5 5. Operation......................................................7 6. Security Considerations.......................................10 7. IANA Considerations...........................................10 8. References....................................................10 8.1. Normative References.....................................10 8.2. Informative References...................................10 Author's Addresses...............................................11 Full Copyright Statement.........................................11 Intellectual Property Statement..................................12 1. Introduction In traditional transport networks, circuits such as T1 lines are provisioned on multiple switches. When a fault happens on any link or node on 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 need to provide the same Fault Management (FM) capability. In this document, an MPLS-TP LSP means either an MPLS transport LSP or an MPLS Pseudowire (PW). This document specifies an MPLS-TP Fault Management mechanism based on a new type of MPLS-OAM packets called "MPLS-OAM Fault Management (FM)" packets. Upon receiving an MPLS OAM FM message: 1. A MIP/MEP activates the backup MPLS-TP LSP (if available) rather than waiting for notification from other fault detection mechanism such as Bidirectional Forwarding Detection (BFD). 2. A MEP sends MPLS-OAM Connection Verification (CV) Message described in [2] to verify the new end-to-end path of the MPLS- TP LSP. The proposed mechanism is based on a set of new TLVs which can be transported using one of the following two methods: 1. Using in-band MPLS OAM messages which are forwarded as MPLS packets (non-IP based). Boutros Expires September 9, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP packets are used (IP-based). The LSP-Ping messages are sent using the codepoint defined in [4]. Method (1) and (2) are referred to as "Non-IP option" and "LSP-Ping option" respectively in the rest of the document. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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. Terminology ACH: Associated Channel Header CV: Connection Verification FM: Fault Management LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP: MPLS Transport Profile NMS: Network Management System PM: Performance Monitoring TTL: Time To Live TLV: Type Length Value 3. MPLS-TP Fault Mechanism For the Non-IP option, the proposed mechanism uses a new code points in the Associated Channel Header (ACH) described in [5]. Boutros Expires September 9, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 The LSP-Ping option will be in compliance to specifications [3],[4], and [8]. Also, the proposed mechanism requires a new message type as described below, and uses the LSPI and address TLVs defined in [6]. 4. MPLS-OAM Fault Message 4.1. In-band Message Identification In the in-band option, under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP Fault" code point indicates that the message is an MPLS OAM Fault message. 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|Flags | 0xHH MPLS-TP Fault Management | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Fault The first nibble (0001b) indicates the ACH. The version and the reserved values are both set to 0 as specified in [1]. MPLS-TP Fault code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] 4.2. Out-of-band Message Identification [To be added] Boutros Expires September 9, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 4.3. 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 | Message Type | Operation | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Cause Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV's | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS-TP OAM Message Format Version The Version Number is currently 1. Message Type Three message types are defined as shown below. Message Type Description ------------ ------------- 0x0 Downstream Fault 0x1 Upstream Fault 0x2 Fault Response Operation Three operations are defined as shown below. The three operations can appear in a Downstream or an Upstream fault message. Detailed descriptions of the operations appear in the next section. Boutros Expires September 9, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 Operation Description --------- ------------- 0x01 Fault added and local repair activated. 0x02 Fault added with no local repair. 0x03 Fault removed. Sender's Handle The Sender's Handle is filled in by the sender. There are no semantics associated with this handle. Message Length The total length of any included TLVs. Message ID The Message ID is set by the sender and is incremented everytime the sender sends a new message. The receiver MUST include the Message ID in it needs to send a Fault response message back to the sender. Return code Value Meaning ----- ------- 0 Fault Code 1 Success 2 Failure Cause code for return code = Fault Code Value Meaning ----- ------- 0x0 no fault 0x1 Link failure 0x2 Node failure 0x3 Low memory 0x4 High CPU 0x5 Resource unavailable Boutros Expires September 9, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 Cause code for return code = Success or Failure Value Meaning ----- ------- 1 Fail to match MPLS-TP LSP ID 2 Malformed Fault message received 3 One or more of the TLVs is/are unknown 4 Authentication failed The fault return code is used in both Downstream fault and upstream fault message types. The other return codes are used in the Fault response messages. Downstream and Upstream fault messages MUST contain a source and a destination address TLVs defined in [6] filled with Source and destination addresses of the two LSRs associated with the fault segment, and LSPI TLV defined in [6] filled with the ID of the MPLS- TP LSP. A fault message can optionally include an Authentication TLV specified in [7]. The receiver MEP or MIP may send a Fault response to the sender MEP or MIP using an MPLS Fault response message, the fault response MUST contain a source address TLV defined in [6] filled with the sender address, and LSPI TLV defined in [6] filled with the ID of the MPLS- TP LSP. 5. Operation Scenario-1 Link Failure detected by only one node: LSR-1 <-> LSR-2 <- X -> LSR-3 <-> LSR-4 | | --- LSR-5 --- There is an MPLS-TP LSP spanning LSR-1, LSR-2, LSR-3, and LSR-4. LSR- 1 and LSR-4 act as MEPs and LSR-2 and LSR-3 act as a MIP. Furthermore, the segment between LSR-2 and LSR-3 is protected by another MPLS-TP LSP as shown above. Boutros Expires September 9, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 Assume that there is a fault on segment between LSR-2 and LSR-3, it was detected only by LSR-2. The proposed scheme operates as follows: 1. Upon detecting failure, LSR-2 activates the backup MPLS-TP LSP that protects the failure, and sends MPLS-OAM FM messages to LSR-1 (upstream) and LSR-5 (downstream via backup MPLS-TP LSP). The MPLS- OAM FM message has an indication that local repair is active on LSR-2. 2. MPLS-OAM FM message arrives at LSR-5 which simply forwards it to downstream over the backup MPLS-TP LSP. 3. MPLS-OAM FM message arrives at LSR-3, and since backup MPLS-TP LSP exists on LSR-3, the backup is activated. The MPLS-OAM FM message is forwarded downstream. 4. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM CV message to verify the new end-to-end path. Scenario-2 Link Failure detected by both nodes adjacent to the failure: LSR-1 <-> LSR-2 <- X -> LSR-3 <-> LSR-4 | | ---- LSR-5 --- This example is similar to the first one except that both LSR-2 and LSR-3 detect the failure. The proposed scheme operates as follows: 1. Upon detecting failure, LSR-2 activates the backup MPLS-TP LSP that protects the failure, and sends MPLS-OAM FM messages to LSR-1 (upstream) and LSR-5 (downstream via backup MPLS-TP LSP). The MPLS- OAM FM message has an indication that local repair is active on LSR-2. Also, since LSR-3 also detects the failure, it also activates the backup MPLS-TP LSP and sends an MPLS-OAM FM message upstream and downstream. The MPLS-OAM FM message has an indication that local repair is active on LSR-3 as well. Boutros Expires September 9, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 2. MPLS-OAM FM messages arrive at LSR-5 which simply forwards it to upstream and downstream over the backup MPLS-TP LSP. 3. MPLS-OAM FM message arrives at LSR-3 and LSR-2. Since the failure is already known to LSR-3 and LSR-2, the MPLS-OAM FM message is discarded. 4. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM CV message to verify the new end-to-end path. Proposed Solution: Fault Removal LSR-1 <-> LSR-2 <-> LSR-3 <-> LSR-4 | | -- LSR-5 -- Assuming LSR-2 detects fault removal proposed solution operates as follows: 1. LSR-2 activates the primary MPLS-TP LSP back and sends MPLS-OAM FM messages to LSR-1 (upstream) and LSR-3 (downstream via primary MPLS-TP LSP). The MPLS-OAM FM message has an indication that the specified fault is removed on LSR-2. 2. MPLS-OAM FM message arrives at LSR-3. LSR-3 activates the primary MPLS-TP LSP back, and forwards the MPLS-OAM FM message downstream to LSR-4. 3. Upon receiving MPLS-OAM FM messages, LSR-1 and LSR-4 send MPLS-OAM CV message to verify the new end-to-end path. A MEP or MIP in response to the MPLS-OAM Fault Management message may send a Fault response message with return code = (1) success and cause code = 0 or return code = (2) failure and a cause code as follow: 1. if LSP ID cannot be matched, it sends a response with cause code 1 back to the sender MEP or MIP. 2. if the message is malformed, it sends a response with the cause code 2 back to to the sender MEP or MIP. 3. if any of the TLV is not known, it sends a response with cause code 3 back to to the sender MEP or MIP. It may also include the unknown TLVs. Boutros Expires September 9, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 4. if message authentication fails, it sends a response with the cause code 4 back to to the sender MEP or MIP. Note that MPLS TTL value is set to 255 in the response message. 6. Security Considerations The security considerations for the authentication TLV need further study. 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", RFC 2119, March, 1997. [2] S. Boutros, et. al., "Connection verification for MPLS Transport Profile LSP", draft-boutros-mpls-tp-cv-00.txt, Work in Progress, November, 2008. [3] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [4] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, December 2007. [5] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- ietf-mpls-tp-gach-gal-02.txt, work in progress, January 6, 2009. [6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. [7] S. Boutros, et. al., "MPLS-TP Loopback", draft-boutros-mpls-tp- loopback-01.txt, Work in Progress, November, 2008. 8.2. Informative References [8] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008. Boutros Expires September 9, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 Author's Addresses Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com 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 UK Email: stbryant@cisco.com Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Boutros Expires September 9, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 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. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including Boutros Expires September 9, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-fault-01.txt March 2009 those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the UETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Boutros Expires September 9, 2009 [Page 13]