Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan Intended status: Standards Track George Swallow Expires: July 2009 David Ward Stewart Bryant Cisco Systems, Inc. January 9, 2009 Fault Management for the MPLS Transport Profile draft-boutros-mpls-tp-fault-00.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 July 12, 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 July 12, 2009 [Page 1] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. MPLS-TP Performance Monitor Mechanism..........................3 4. MPLS-OAM Fault Message.........................................4 4.1. Downstream/Upstream Fault TLV.............................5 4.2. Fault Removal TLV.........................................6 5. Operation......................................................7 6. Security Considerations........................................9 7. IANA Considerations............................................9 TBD...............................................................9 8. References.....................................................9 8.1. Normative References......................................9 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 FM 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 June 12, 2009 [Page 2] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 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 Performance Monitor 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 June 12, 2009 [Page 3] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 The LSP-Ping option will be in compliance to specifications [3],[4], and [8]. Also, the proposed mechanism requires a set of new TLVs called Fault Addition TLV, Fault Removal TLV. The new TLVs are described below. 4. MPLS-OAM Fault Message To support the Non-IP option, a new ACH code-point called "MPLS-OAM Fault Management" is introduced as part of this specification. In addition, a 32-bit field is added to carry the message ID and the message length as 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|0 0 0 0|Flags | MPLS-TP Fault Management | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MPLS-TP OAM Message Header First nibble = 0001b. The value of the MPLS-TP FM code point is TBD. The Message ID is set by the sender. The receiver MUST include the Message ID in the response. This way, the sender can correlate a reply with the corresponding request. The Message Length is the total length of the message in bytes excluding the length of the MPLS-TP OAM message header. Flags in the ACH 0x01 local repair happened. 0x02 Fault added. 0x04 Fault removed. Boutros Expires June 12, 2009 [Page 4] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 4.1. Downstream/Upstream Fault TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Address block TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Connection-ID TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fault Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | +-+-+-+-+-+-+-+-+ Type = 0xHH DownStream Fault. Type = 0xhh UpStream Fault. Address block TLV defined in [6] includes Source and destination addresses of the two LSRs associated with the fault segment. Connection ID TLV defined in [6] includes Connection ID of the MPLS- TP LSP. Fault Code Description ---------- ------------- 0x0 no fault 0x1 Link failure 0x2 Node failure 0x3 Low memory 0x4 High CPU 0x5 Resource unavailable Boutros Expires June 12, 2009 [Page 5] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 Flag Value Meaning ---------- ------- 0x0 no Local repair done 0x1 Local repair done The receiver MEP or MIP can send a NAK response to the sender MEP using an MPLS OAM message with a Response TLV described in [7] if it does not support the Fault TLV. 4.2. Fault Removal TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = TBD | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Address block TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Connection-ID TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fault Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | +-+-+-+-+-+-+-+-+ The fault removal TLV has a Fault Code of 0. Fault Code Description ---------- ------------- 0x0 no fault Flag Value FM Mode ---------- ------------- 0x0 no Local repair done 0x1 Local repair done The receiver MEP or MIP MUST send a NAK response to the sender MEP using an MPLS OAM message with a Response TLV described in [loop] if it does not support the Fault Removal TLV. Boutros Expires June 12, 2009 [Page 6] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 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. 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 --- Boutros Expires June 12, 2009 [Page 7] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 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. 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. Since LSR-3 activates the primary MPLS-TP LSP back, and which 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. Boutros Expires June 12, 2009 [Page 8] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 A MEP or MIP in response to the MPLS-OAM Fault Management message Must send a response TLV with an error code: 1. if the message is malformed, it sends a response with the error code 2 back to LSR-1. 2. if any of the TLV is not known, it sends a response with error code 3 back to LSR-1. It may also include the unknown TLVs. 3. if message authentication fails, it sends a response with the error code 4 back to LSR-1. 4. if the MPLS-TP is already locked, it sends a response with error code 5 back to A. 5. if connection-ID cannot be matched, it sends a response with error code 14. 6. if PM packet rate cannot be handled, it sends a response with error code 15. 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 TBD 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. Boutros Expires June 12, 2009 [Page 9] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 [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-01.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 June 12, 2009 [Page 10] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 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. 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 Boutros Expires June 12, 2009 [Page 11] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 publication of this document. 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 those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. Boutros Expires June 12, 2009 [Page 12] Internet-Draft draft-boutros-mpls-tp-fault-00.txt January 2009 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 June 12, 2009 [Page 13]