Network Working Group Sami Boutros (Ed.) Internet Draft Siva Sivabalan (Ed.) Intended status: Standards Track George Swallow (Ed.) Expires: February 2010 Cisco Systems, Inc. Martin Vigoureux (Ed.) Alcatel-Lucent A. Fulignoli (Ed.) Ericsson July 6, 2009 Connection Verification and Continuity Check for MPLS Transport Profile Label Switched Path draft-boutros-mpls-tp-cv-cc-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 February 6, 2010. Boutros Expires February 6, 2010 [Page 1] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 Abstract Connection Verification (CV) and Continuity Check (CC) are important Operations, Administration, and Management (OAM)functions of MPLS Transport Profile (MPLS-TP). This document specifies methods for CV and CC for MPLS-TP Label Switched Path (LSP) using Bidirectional Forwarding Detection (BFD). Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. MPLS-TP Connection Verification and Continuity Check Mechanism.3 3.1. MPLS-TP CV/CC Message format..............................4 3.2. BFD Profile for MPLS-TP...................................5 4. Operation......................................................6 5. Security Considerations........................................7 6. IANA Considerations............................................7 7. References.....................................................7 7.1. Normative References......................................7 7.2. Informative References....................................7 Author's Addresses................................................8 Full Copyright Statement..........................................9 Intellectual Property Statement...................................9 1. Introduction In traditional transport networks, circuits are provisioned on multiple switches. Service Providers (SP) need OAM tools to detect mis-connectivity and loss of continuity of transport circuits. MPLS- TP LSPs [6] emulating traditional transport circuits need to provide the same CC and CV capabilities as mentioned in [2]. This document describes the use of BFD [3] for CV and CC of an MPLS-TP LSP between 2 Maintenance End Points (MEPs). The mechanism specified in this document is restricted only to BFD asynchronous mode. The proposed method uses BFD state machine defined in Section 6.2 of [3]. Moreover, this document recommends the use of BFD for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)as defined in [5]. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Boutros Expires February 6, 2010 [Page 2] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 document are to be interpreted as described in RFC-2119 [1]. 2. Terminology ACH: Associated Channel Header BFD: Bidirectional Forwarding Detection CV: Connection Verification EOS: End of Stack GAL: Generalized Alert Label LSR: Label Switching Router MEP: Maintenance End Point MIP: Maintenance Intermediate Point MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP: MPLS Transport Profile MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit MS-PW: Mult-Segment PseudoWire NMS: Network Management System PW: PseudoWire RR: Record Route TLV: Type Length Value TTL: Time To Live RDI: Remote defect indication. 3. MPLS-TP Connection Verification and Continuity Check Mechanism The proposed mechanism is based on a new code point in the Generic Associated Channel Header (G-ACH) described in [8]. Under MPLS label stack of the MPLS-TP LSP, the ACH with "MPLS-TP Connection Boutros Expires February 6, 2010 [Page 3] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 Verification/Continuity Check (CV/CC)" code point indicates that the message is an MPLS-TP CV/CC 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 CV/CC Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Connection Verification The first nibble (0001b) indicates the ACH. The version and the reserved values are both set to 0 as specified in [8]. MPLS-TP CV/CC code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] 3.1. MPLS-TP CV/CC Message format The format of an MPLS-TP CV/CC Message format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label (EOS) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | | ~ Destination and Source Node-IDs of the MPLS-TP LSP ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS-TP CV/CC Message Boutros Expires February 6, 2010 [Page 4] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 As shown in Figure 2, BFD Control packet as defined in [3] is transmitted as MPLS labeled packets along with GAL, G-ACH, and TLVs carrying the Destination and Source Node-IDs of the MPLS-TP LSP as defined in a new IETF draft to be published soon. The TTL field of the GAL MUST be set to at least 1, and the GAL will be the end of stack label. The discriminator values in the BFD control packet will be set to the LIH (Logical Interface Handle) at each side of the MPLS-TP LSP. Combination of the Source/Destination Node-IDs and discriminator value (from the BFD packet) represents MEP-ID, i.e., the combination of the source node address and my discriminator is the Source MEP-ID, and the combination of the destination node address and your discriminator is the peer MEP-ID. Note that the format of Node ID is defined in [7]. In this mode of operation, the IP/UDP headers for the BFD control packets are omitted from the BFD encapsulation. Furthermore, BFD is used not only for fault detection but also for mis-insertion and for Remote Defect Indication (RDI). Reception of a BFD control packet having an unexpected source Node-ID, destination Node-ID or discriminator(s) is considered a BFD mis-insertion fault. Reception of BFD control packet with a diagnostic code of 1 (Control Detection Time Expired) or 5 (Path down) is considered an RDI fault. 3.2. BFD Profile for MPLS-TP BFD MUST run in asynchronous mode as described in [3]. In all BFD control packets sent, both "Desired Min TX Interval" and "Required Min RX Interval" MUST be set to the operator configured values for BFD transmission period for the MPLS-TP LSP. If the received BFD packets have different "Desired Min TX Interval field" than the one used for the transmitted packets, the BFD session MUST NOT come up by default, except if the behavior is overridden by an operator using explicit configuration. By default the transmission rates MUST be the same at both end of the MPLS-TP LSP (both working and protecting). The "my discriminator" field in the BFD control packets is set to the MPLS-TP LSP's local LIH (Logical Interface Handle) and the "your discriminator" field is initially set to zero. During BFD session Boutros Expires February 6, 2010 [Page 5] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 negotiation, the "my discriminator" field in the received BFD packets MUST match the remote discriminator. 4. Operation Single-hop BFD initialization procedures described in [4] are followed. As mentioned before, only asynchronous mode is supported. The operation of BFD over MPLS-TP LSP is symmetrical. Both endpoints of the bidirectional MPLS-TP LSP MUST send BFD messages inband in the MPLS-TP LSP using the defined code point. Both MEPs at the end of an MPLS-TP LSP need to bootstrap the BFD session and start sending BFD control packets encapsulated within MPLS-TP CV/CC message described in this document. MPLS-TP LSP labels at both ends of the MPLS-TP LSP will be used as the de-multiplexer for the received BFD packets, and no discriminator values will be used. A single BFD session per MPLS-TP LSP will exist between the MEP's of the MPLS-TP LSP. Both MEP's will be sending initial BFD Control packets with a "Your Discriminator" field of zero, and BFD Control packets received with a "Your Discriminator" field of zero are associated to the BFD session bound to the MPLS-TP LSP. Both "Desired Min TX Interval" and "Required Min RX Interval" MUST be set to the configured BFD transmission period for the MPLS-TP LSP. Assume an MPLS-TP LSP that spans across LSR-A, LSR-B and LSR-C. LSR-A LSR-C act as the MEPs whereas LSR-B act as a MIP for the MPLS-TP LSP. Furthermore, assume that on both LSR-A and LSR-C the operator provision the BFD detection time multiplier as per [3]. If LSR-A receives a BFD control message that has a destination node identifier different from it's identifier, or has an unexpected source node identifier, or non-zero your discriminator value or has a my discriminator value different from what LSR-A is expecting, LSR-A declares that the MPLS-TP LSP is down in its receive direction. In this case, LSR-A signals LSR-C that the BFD session is down using the State (Sta) with diagnostic code 5 (Path down). Boutros Expires February 6, 2010 [Page 6] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 If LSR-A stops receiving BFD control messages from LSR-C for a period of detection time multiplier (calculation of Detection Time is defined in[3]), LSR-A declares that the MPLS-TP LSP is down in its receive direction, and signals this to the remote end via the State (Sta) with Diagnostic code 1(Control Detection Time Expired). In turn, LSR-C declares the MPLS-TP LSP is down in its transmit direction setting the State to Down with Diagnostic code 3 (Neighbor signaled session down) in its control messages to LSR-A. 5. Security Considerations The security considerations for the authentication TLV need further study. 6. IANA Considerations To be added. 7. References 7.1. Normative References [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 02 (work in progress), June 2009. [3] Katz, D., and D. Ward, "Bidirectional Forwarding Detection", draft-ietf-bfd-base-09 (work in progress), August 2009. [4] Katz, D., and D. Ward, "Generic Application of BFD", draft- ietf-bfd-generic-05 (work in progress), February 2009. [5] T. Nadeau, et. Al, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV), draft-ietf-pwe3-vccv-bfd-05, June 2009. 7.2. Informative References [6] M. Bocci, et. al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-01.txt, Work in Progress, June 2009. [7] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- bryant-mpls-tp-ach-tlv-01.txt, Work in Progress, May 2009. Boutros Expires February 6, 2010 [Page 7] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 [8] M. Bocci, et. al., "MPLS Generic Associated Channel", RFC 5586, June, 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 Martin Vigoureux Boutros Expires February 6, 2010 [Page 8] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Annamaria Fulignoli (Editor) Ericsson Email: annamaria.fulignoli@ericsson.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 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 Boutros Expires February 6, 2010 [Page 9] Internet-Draft draft-boutros-mpls-tp-cv-cc-00.txt July 2009 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. 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 February 6, 2010 [Page 10]