MPLS Working Group A. Fulignoli, Ed. Internet Draft Ericsson Intended status: Standards Track Expires: April 2010 S. Boutros, Ed. Cisco Systems, Inc M. Vigoureux, Ed. Alcatel-Lucent October 16, 2009 Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile draft-asm-mpls-tp-bfd-cc-cv-00 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 April 17, 2010. 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. Fulignoli et al., Expires April 16, 2010 [Page 1] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 Abstract Continuity Check (CC), Proactive Connectivity Verification (CV) and Remote Defect Indication (RDI) functionalities are MPLS-TP OAM requirements listed in [3]. Continuity Check monitors the integrity of the continuity of the path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the path between sink and source for any connectivity issues. RDI enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP or Section. It is RECOMMENDED that a protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs and Sections as per [3]. This document specifies methods for proactive CV, CC, and RDI for MPLS-TP Label Switched Path (LSP), PWs and Sections using Bidirectional Forwarding Detection (BFD). Table of Contents 1. Introduction................................................3 1.1. Contributing Authors.......................................3 2. Conventions used in this document............................3 2.1. Terminology...............................................3 3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD..........4 3.1. MPLS-TP BFD CC Message format..............................5 3.2. MPLS-TP BFD proactive CV/CC Message format.................5 3.3. BFD Profile for MPLS-TP....................................6 3.3.1. Timer negotiation........................................7 3.3.2. Discriminator values.....................................7 3.4. Remote Detection Indication (RDI)..........................7 4. Operation...................................................7 4.1. Unidirectional p2p or p2mp transport path..................8 5. Acknowledgments.............................................9 6. IANA Considerations.........................................9 7. Security Considerations......................................9 8. References..................................................9 8.1. Normative References.......................................9 8.2. Informative References....................................10 Fulignoli et al., Expires April 16, 2010 [Page 2] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 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 [11] emulating traditional transport circuits need to provide the same CC and proactive CV capabilities as mentioned in [3]. This document describes the use of BFD [7] for CC, proactive CV, and RDI of an MPLS-TP LSP between two 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 [7] for bidirectional p2p connections and uses the p2mp BFD state machine defined in [8] for p2p unidirectional and p2mp unidirectional transport path. As described in [4], Continuity Check (CC) and Proactive Connectivity Verification (CV) functions are used to detect loss of continuity (LOC), unintended connectivity between two MEPs (e.g. mismerging or misconnection or unexpected MEP). The Remote Defect Indication (RDI) is an indicator that is transmitted by a MEP to communicate to its peer MEPs that a signal fail condition exists.RDI is only used for bidirectional connections and is associated with proactive CC & CV packet generation. The main goal here is to specify the BFD extension and behaviour to satisfy the CC, proactive CV monitoring and the RDI functionality. 1.1. Contributing Authors Siva Sivabalan, George Swallow, David Ward. 2. Conventions used in this document 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.1. Terminology ACH: Associated Channel Header BFD: Bidirectional Forwarding Detection CV: Connection Verification Fulignoli et al., Expires April 16, 2010 [Page 3] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 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 RDI: Remote defect indication. TTL: Time To Live TLV: Type Length Value 3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD This document proposes two modes of BFD operation o CC mode: uses the existing ACH code point (0x0007) and BFD ACH packet encapsulation (BFD without IP/UDP headers ) as defined in [6]. In this mode Continuity Check and RDI functionalities are supported. o CV/CC mode: defines a new code point in the Associated Channel Header (ACH) described in [2]. Under MPLS label stack of the MPLS- TP LSP, the ACH with "MPLS-TP Proactive CV/CC" code point indicates that the message is an MPLS-TP BFD proactive CV and CC message. Fulignoli et al., Expires April 16, 2010 [Page 4] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 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| 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 [2]. MPLS-TP proactive CV/CC code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] In this mode Continuity Check, Connectivity Verifications and RDI functionalities are supported. Both CC and CV/CC modes apply to PWs, MPLS LSPs (including tandem connection monitoring), and Sections It's possible to run the BFD in CC mode on some transport paths and the BFD in CV/CC mode on other transport paths. In any case, only one tool for OAM instance at time, configurable by operator, can run. 3.1. MPLS-TP BFD CC Message format The format of an MPLS-TP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Flags |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. MPLS-TP BFD proactive CV/CC Message format The format of an MPLS-TP CV/CC Message format is shown below, ACH TLVs MUST precede the BFD control packet. Fulignoli et al., Expires April 16, 2010 [Page 5] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 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| Flags |0xHH MPLS-TP CV/CC Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unique MEP-ID of source of the BFD packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS-TP CV/CC Message As shown in Figure 2, BFD Control packet as defined in [7] is transmitted as MPLS labeled packets along with ACH, ACH TLV Header defined in Section 3 of RFC 5586 and one ACH TLV object carrying the unique MEP Identifier of the source of the BFD packet defined in [12] When GAL label is used, the TTL field of the GAL MUST be set to at least 1, and the GAL will be the end of stack label. 3.3. BFD Profile for MPLS-TP BFD MUST run in asynchronous mode as described in [7]. No changes to the BFD state machine defined in [7] for p2p bidirectional transport path and in [8] for unidirectional p2p and p2mp transport path. BFD Control Packets are sent at regular configured time rate. BFD session is declared Down: If an unexpected MEP identifier is received (mis-connectivity defect) If timer and detect multiplier re-negotiation is disabled and an unexpected desired min Tx interval field value or unexpected detect multiplier field are received (Unexpected period defect). If BFD session times out (Loss of Connectivity) Fulignoli et al., Expires April 16, 2010 [Page 6] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 3.3.1. Timer negotiation BFD timer values negotiation is optional and disabled by default on the MPLS-TP transport paths. Active Role is default, passive is optional. The configured BFD packet transmission is carried in the "Desired Min TX Interval field". For a bidirectional p2p transport path the "Required Min RX Interval field" MUST be the same as "Desired Min TX Interval field". The source MEP of an unidirectional p2p and p2mp session MUST set the "Required Min RX Interval field " to 0. The default timer values to be used based on what's recommended in [4]. 3.3.2. Discriminator values In the BFD control packet the discriminator values have either local or no significance. My discriminator field MUST be set to a nonzero value (it can be a fixed value), the transmitted your discriminator value MUST reflect back the received value of My discriminator field or be set to 0 if that value is not known yet. 3.4. Remote Detection Indication (RDI) The BFD Diagnostic (Diag) field defined in [8] can be used for this functionality. On MEP mismatch, loss of connectivity or unexpected timer and unexpected detect multiplier a MEP sends to its peer MEP a BFD packet with the Diagnostic (Diag) field value set to 1 (corresponding to the "Control Detection Time Expired"). The value 0 indicates RDI condition has been cleared. 4. Operation For p2p bidirectional LSPs, both endpoints of the bidirectional MPLS- TP LSP MUST send BFD messages in-band in the MPLS-TP LSP using the defined code point. When on a configured bidirectional transport path the proactive CV/CC or CC monitoring is enabled, each MEP sends the BFD Control Packets at the rate of the configured transmission period and each MEP Fulignoli et al., Expires April 16, 2010 [Page 7] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 expects to receive the BFD packets from its peer MEP at the same rate as per [4]. MPLS labels at both MEPs are used to provide context for the received BFD packets. Active role is the default behavior, passive role is optional. In Active role both MEPs start sending initial BFD Control Packets with the State field set to "Down" value and with "Your discriminator" field set to zero. +-----+ +-----+ | | ------- X -------->| | | A | <----------------- | B | +-----+ +-----+ Figure 3 o If a MEP-B in Figure 3 detects one of the following faults (miss- connectivity, Unexpected Period or loss of continuity) from its peer MEP, it declares that the transport path in its receive direction is down (in other words, MEP-B enters the "receive defect" state for this transport path) and signals it to its peer MEP (MEP-A) sending the BFD packets with State (Sta) field set to "Down" and Diagnostic code 1 (RDI) o In turn, the peer MEP (MEP-A) declares the transport path is down in its transmit direction, (in other words, MEP-A enters the "transmit defect" state for this transport path) setting the State (Sta field ) to Down with Diagnostic code 3 (Neighbor signaled session down) in its BFD packets towards MEP-B. Please note that if the failure is unidirectional, i.e. only from A to B direction as in Figure 1. MEP-A, transits first to Down State but then to Init state as it still receives BFD packets from its peer MEP B. 4.1. Unidirectional p2p or p2mp transport path. o In a unidirectional (point-to-point or point-to-multipoint) transport path, where the proactive CV/CC or CC monitoring is enabled, only the Source MEP is enabled to generate BFD packets with frequency of the configured transmission period and always with UP State information. This MEP does not expect to receive any BFD packets from its peer MEP(s), as such all state transitions are administratively driven. Fulignoli et al., Expires April 16, 2010 [Page 8] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 o A MEP Sink, configured on a unidirectional transport path where the proactive CV and CC monitoring is enabled, expects to receive the BFD packets from its peer MEP at the configured frequency; the defects detection procedure is the same as the bidirectional MEP. Traffic MUST not be affected, when proactive CV/CC or CC monitoring is enabled/disabled by an operator on a configured MEP or when a BFD session transits from one state to another as per [4]. 5. Acknowledgments To be added in a later version of this document 6. IANA Considerations To be added in a later version of this document 7. Security Considerations The security considerations for the authentication TLV need further study. Base BFD foresees an optional authentication section (see [7] section 6.7); that can be extended even to the tool proposed in this document. Authentication methods that require checksum calculation on the outgoing packet must extend the checksum even on the ME Identifier Section. This is possible but seems uncorrelated with the solution proposed in this document: it could be better to use the simple password authentication method. 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. et al., " MPLS Generic Associated Channel ", RFC 5586 , June 2009 [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam- requirements-03 (work in progress), August 2009 Fulignoli et al., Expires April 16, 2010 [Page 9] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 [4] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and Overview", draft-ietf-mpls-tp-oam-framework-01 (work in progress), July 2009 [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007 [6] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv- bfd-07 (work in progress), July 2009 [7] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", draft-ietf-bfd-base-09 (work in progress), February 2009 [8] Katz, D. and D. Ward, "BFD for Multipoint Networks", draft-katz-ward-bfd-multipoint-02 (work in progress), February 2009 [9] Boutros, S. et al., "Definition of ACH TLV Structure", draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June 2009 [10] Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow, "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), June 2008 [11] Bocci, M., et al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-05, (work in progress), September 2009 [12] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- swallow-mpls-tp-identifiers-01 (work in progress), July 2009 8.2. Informative References To be added in a later version of this document Fulignoli et al., Expires April 16, 2010 [Page 10] Internet-Draft draft-asm-mpls-tp-bfd-cc-cv-00 October 2009 Authors' Addresses Annamaria Fulignoli (Editor) Ericsson Email: annamaria.fulignoli@ericsson.com Sami Boutros (Editor) Cisco Systems, Inc. Email: sboutros@cisco.com Martin Vigoureux (Editor) Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Contributing Authors' Addresses 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 Fulignoli et al., Expires April 16, 2010 [Page 11]