MPLS Working Group Dave Allan, Ed. Internet Draft Ericsson Intended status: Standards Track Expires: January 2011 George Swallow Ed. Cisco Systems, Inc John Drake Ed. Juniper July 12, 2010 Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile draft-ietf-mpls-tp-cc-cv-rdi-01 Abstract Continuity Check (CC), Proactive Connectivity Verification (CV) and Remote Defect Indication (RDI) functionalities required for are MPLS- TP OAM. 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. 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). 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 RFC2119 [1]. 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 Allan et al., Expires January 12, 2011 [Page 1] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 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 November 28, 2010. Copyright Notice Copyright (c) 2010 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Authors......................................................4 2. Conventions used in this document..............................4 2.1. Terminology..................................................4 2.2. Issues for discussion........................................4 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 3.1. ACH code points for CC and proactive CV......................5 3.2. MPLS BFD CC Message format...................................6 3.3. MPLS BFD proactive CV Message format.........................6 3.4. BFD Session in MPLS-TP terminology...........................7 3.5. BFD Profile for MPLS-TP......................................7 3.5.1. Session initiation.........................................8 3.5.2. Defect entry criteria......................................8 Allan et al., Expires January 12, 2011 [Page 2] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 3.5.3. Defect entry consequent action............................10 3.5.4. Defect exit criteria......................................10 3.5.5. State machines............................................10 3.5.6. Configuration of MPLS-TP BFD sessions.....................13 3.5.7. Discriminator values......................................13 4. Acknowledgments...............................................13 5. IANA Considerations...........................................14 6. Security Considerations.......................................14 7. References....................................................14 7.1. Normative References........................................14 7.2. Informative References......................................15 1. Introduction In traditional transport networks, circuits are provisioned on two or more switches. Service Providers (SP) need OAM tools to detect mis- connectivity and loss of continuity of transport circuits. Both PWs and MPLS-TP LSPs [7] emulating traditional transport circuits need to provide the same CC and proactive CV capabilities as required in draft-ietf-mpls-tp-oam-requirements[3]. This document describes the use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between two Maintenance Entity Group End Points (MEPs). As described in [9], Continuity Check (CC) and Proactive Connectivity Verification (CV) functions are used to detect loss of continuity (LOC), and 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 MEP that a signal fail condition exists. RDI is only used for bidirectional connections and is associated with proactive CC & CV packet generation. This document specifies the BFD extension and behavior to satisfy the CC, proactive CV monitoring and the RDI functional requirements for bi-directional paths. Procedures for uni-directional paths are for further study. The mechanisms specified in this document are restricted to BFD asynchronous mode. Allan et al., Expires January 12, 2011 [Page 3] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 1.1. Authors David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. 2. Conventions used in this document 2.1. Terminology ACH: Associated Channel Header BFD: Bidirectional Forwarding Detection CV: Connection Verification GAL: Generalized Alert Label LSR: Label Switching Router MEG: Maintenance Entity Group MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-TP: MPLS Transport Profile MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path representing a circuit MS-PW: Multi-Segment PseudoWire NMS: Network Management System PW: Pseudo Wire RDI: Remote Defect Indication. TTL: Time To Live TLV: Type Length Value 2.2. Issues for discussion 1) Requirement for additional BFD diagnostic codes? Allan et al., Expires January 12, 2011 [Page 4] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 1. When periodicity of CV cannot be supported 3. MPLS CC, proactive CV and RDI Mechanism using BFD This document proposes distinct encapsulations and code points for BFD depending on whether the mode of operation is CC or CV: o CC mode: defines a new code point in the Associated Channel Header (ACH) described in [2].In this mode Continuity Check and RDI functionalities are supported. o CV mode: defines a new code point in the Associated Channel Header (ACH) described in [2]. Under MPLS label stack, the ACH with "MPLS Proactive CV" code point indicates that the message is an MPLS BFD proactive CV and CC message. o RDI: is communicated via the BFD state field in BFD CC and CV messages. It is not a distinct PDU. 3.1. ACH code points for CC and proactive CV 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 BFD CC/CV Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Connection Verification The first nibble (0001b) indicates the ACH. The version and the flags are set to 0 as specified in [2]. The code point is either - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] or, - BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry.] Both CC and CV modes apply to PWs, MPLS LSPs (including tandem connection monitoring), and Sections. It's possible to run BFD in CC mode on some transport paths and BFD in CV mode on other transport paths. For a given Maintenance Entity Group (MEG) only one mode can be used. A MEP that is configured to Allan et al., Expires January 12, 2011 [Page 5] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 support CC mode and receives CV BFD packets, or vice versa, MUST consider them as an unexpected packet, i.e. detect a mis-connectivity defect. 3.2. MPLS BFD CC Message format The format of an MPLS 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 | 0xHH BFD CC Code point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS CC Message 3.3. MPLS BFD proactive CV Message format The format of an MPLS CV Message format is shown below, ACH TLVs [5] MUST precede the BFD control packet. 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 BFD CV Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unique MEP-ID of source of the BFD packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: MPLS CV Message As shown in Figure 3, BFD Control packet as defined in [4] is transmitted as MPLS labeled packets along with ACH, ACH TLV Header Allan et al., Expires January 12, 2011 [Page 6] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 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 [8]. 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 (S=1). 3.4. BFD Session in MPLS-TP terminology A BFD session corresponds to a CC or a proactive CV OAM instance in MPLS-TP terminology. A BFD session is enabled when the CC or proactive CV functionality is enabled on a configured Maintenance Entity (ME) or in the case of an associated bi-directional path, pair of Maintenance Entities. On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as detailed in [4]. When on a ME the CC or proactive CV functionality is disabled, the BFD session transitions to the ADMIN DOWN State and the BFD session ends. A new BFD session is initiated when the operator enables or re- enables the CC or CV functionality on the same ME. 3.5. BFD Profile for MPLS-TP BFD MUST operate in asynchronous mode. In this mode, the BFD Control packets are periodically sent at configurable time rate. This rate is typically a fixed value for the lifetime of the session. In the rare circumstance where an operator has a reason to change session parameters, poll/final discipline is used. The transport profile is designed to operate independent of the control plane; hence the C bit SHOULD be set. This document specifies bi-directional BFD for p2p transport paths, hence the M bit MUST be clear. There are two modes of operation for bi-directional paths. One in which the session state of both directions of the path is coordinated and one constructed from BFD sessions in such a way that the two directions operate independently. A single bi-directional BFD session is used for coordinated operation. Two independent BFD sessions are used for independent operation. Coordinated operation is as described in [4]. Independent operation requires clarification of two aspects of [4]. Independent operation Allan et al., Expires January 12, 2011 [Page 7] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 is characterized by the setting of MinRxInterval to zero by the MEP that is typically the session originator (referred to as the source MEP), and there will be a session originator at either end of the bi- directional path. Each source MEP will have a corresponding sink MEP that has been configured to a Tx interval of zero. The base spec is unclear on aspects of how a MEP with a BFD transmit rate set to zero behaves. One interpretation is that no periodic messages originate with that MEP, it will only originate messages on a state change. The first clarification is that when a state change occurs a MEP set to a transmit rate of zero sends BFD control messages with a one second period until such time that the state change is confirmed by the session peer. At this point the MEP set to a transmit rate of zero can resume quiescent behavior. This adds robustness to all state transitions in the RxInterval=0 case. The second is that the originating MEP (the one with a non-zero TxInterval) will ignore a DOWN state received from a zero interval peer. This means that the zero interval peer will continue to send DOWN state messages as the state change is never confirmed. This adds robustness to the exchange of RDI indication on a uni-directional failure (for both session types DOWN with a diagnostic of control detection period expired offering RDI functionality). A further extension to the base specification is that there are additional OAM protocol exchanges that act as inputs to the BFD state machine; these are the Link Down Indication [6] and the Lock Instruct/Lock Report transactions. 3.5.1. Session initiation In all scenarios a BFD session starts with both ends in the DOWN state. DOWN state messages exchanged include the desired Tx and Rx rates for the session. If a node cannot support the Min Tx rate desired by a peer MEP it does not transition from down to the INIT state and sends a diagnostic code (TBD) indicating that the requested Tx rate cannot be supported. Otherwise once a transition from DOWN to INIT has occurred, the session progresses as per [4]. 3.5.2. Defect entry criteria There are further defect criteria beyond that defined in [4] to consider given the possibility of mis-connectivity and mis- configuration defects. The result is the criteria for a path Allan et al., Expires January 12, 2011 [Page 8] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 direction to transition from the defect free state to a defect state is a superset of that in the BFD base specification [4]. The following conditions cause a MEP to enter the defect state for CC of CV: 1. BFD session times out (Loss of Continuity defect), 2. Receipt of a link down indication. 3. Receipt of an unexpected M bit (Session Mis-configuration defect), And the following will cause the MEP to enter the defect state for CV operation 1. BFD control packets are received with an unexpected encapsulation (Mis-connectivity defect), these include - a PW receiving a packet with a GAL - an LSP receiving an IP header instead of a GAL (note there are other possibilities but these can also alias 2. Receipt of an unexpected globally unique Source MEP identifier (Mis-connectivity defect), 3. Receipt of an unexpected session discriminator in the your discriminator field (Mis-connectivity defect), 4. Receipt of an expected session discriminator with an unexpected label (mis-connectivity defect), The effective defect hierarchy (order of checking) is 1. Receiving nothing 2. Receiving link down indication 3. Receiving from an incorrect source (determined by whatever means) 4. Receiving from a correct source (as near as can be determined), but with incorrect session information) 5. Receiving control packets in all discernable ways correct. Allan et al., Expires January 12, 2011 [Page 9] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 3.5.3. Defect entry consequent action Upon defect entry a sink MEP will assert signal fail into any client (sub-)layers. It will also communicate session DOWN to its session peer. The blocking of traffic as consequent action MUST be driven only by a defect's consequent action as specified in draft-ietf-mpls-tp-oam- framework [9] section 5.1.1.2. When the defect is mis-branching, the transport path termination will silently discard all non-oam traffic received. 3.5.4. Defect exit criteria Exit from a Loss of continuity defect For a coordinated session, exit from a loss of connectivity defect is as described in figure 4 which updates [4]. For an independent session, exit from a loss of connectivity defect occurs upon receipt of a well formed control packet from the peer MEP as described in figures 5 and 6. Exit from a session mis-configuration defect [editors: for a future version of the document] Exit from a mis-connectivity defect The exit criteria for a mis-connectivity defect is determined by the maximum of the set of min Rx session time times the multiplier that have been received. A session can transition from DOWN to UP (independent mode) or DOWN to INIT (coordinated mode) when both correctly formed control packets are being exchanged, and no mis- connected control packets have been received in the specified interval. 3.5.5. State machines The following state machines update [4]. They have been modified to include LDI and LKI as inputs to the state machine and to clarify the behavior for independent mode. The coordinated session state machine has been augmented to indicate LDI and LKR as inputs to the state machine. For a session that is in the UP state, receipt of LDI or LKR will transition the session into the DOWN state. Allan et al., Expires January 12, 2011 [Page 10] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 [Dave: I have to think that we do not need to consider LDI/LKR for transition from DOWN to INIT, I have to receive a BFD control packet to do that which means the condition is cleared, only funky case is when I'm getting both UP messages and LDI/LKR] +--+ | | UP, ADMIN DOWN, TIMER, LDI/LKR | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | ADMIN DOWN,| | | |ADMIN DOWN, DOWN,| | | |TIMER TIMER,| | V |LDI/LKR LDI/LKR | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ Figure 4: State machine for coordinated session operation For independent mode, there are two state machines. One for the source MEP (who requested MinRxInterval=0) and the sink MEP (who agreed to MinRxInterval=0). The source MEP will not transition out of the UP state once initialized except in the case of a forced ADMIN DOWN. Hence LDI/LKR do not enter into the state machine transition from the UP state, but do enter into the INIT and DOWN states. Allan et al., Expires January 12, 2011 [Page 11] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 +--+ | | UP, ADMIN DOWN, TIMER | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | ADMIN DOWN | | | |ADMIN DOWN, | | | |TIMER, | | V |LDI/LKR | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, +--->| | INIT, UP | |<---+ LDI/LKR +------+ +------+ Figure 5: State machine for source MEP for independent session operation The sink MEP state machine (for which the transmit interval has been set to zero) is modified to: 1) Permit direct transition from DOWN to UP once the session has been initialized. With the exception of via the ADMIN DOWN state, the source MEP will never transition from the UP state, hence in normal unidirectional fault scenarios will never transition to the INIT state. Allan et al., Expires January 12, 2011 [Page 12] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 +--+ | | ADMIN DOWN, TIMER, LDI/LKR | V DOWN +------+ INIT, UP +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | ADMIN DOWN,| | | |ADMIN DOWN, TIMER, | | | |TIMER, DOWN, | | V |LDI/LKR LDI/LKR | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ Figure 6: State machine for the sink MEP for independent session operation 3.5.6. Configuration of MPLS-TP BFD sessions [Editors note, for a future revision of the document] 3.5.7. Discriminator values In the BFD control packet the discriminator values have either local to the sink MEP or no significance (when not known). 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. Although the BFD base specification permits an implementation to change the my discriminator field at arbitrary times, this is not permitted for CV mode in order to avoid race conditions in mis- connectivity defects. 4. Acknowledgments To be added in a later version of this document Allan et al., Expires January 12, 2011 [Page 13] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 5. IANA Considerations To be added in a later version of this document 6. Security Considerations The security considerations for the authentication TLV need further study. Base BFD foresees an optional authentication section (see [4] section 6.7); that can be extended also to the tool proposed in this document. Authentication methods that require checksum calculation on the outgoing packet must extend the checksum also 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. 7. References 7.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 Operations Administration and Maintenance in MPLS Transport Networks", RFC5860, May 2010 [4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010 [5] Boutros, S. et al., "Definition of ACH TLV Structure", draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March 2010 [6] Swallow, G. et al., "MPLS Fault Management OAM", draft- ietf-mpls-tp-fault-02 (work in progress), July 2010 Allan et al., Expires January 12, 2011 [Page 14] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 7.2. Informative References [7] Bocci, M., et al., "A Framework for MPLS in Transport Networks", RFC5921, July 2010 [8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- swallow-mpls-tp-identifiers-02 (work in progress), July 2010 [9] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework-06 (work in progress), April 2010 Allan et al., Expires January 12, 2011 [Page 15] Internet-Draft draft-ietf-mpls-tp-cc-cv-rdi-01 July 2010 Authors' Addresses Dave Allan Ericsson Email: david.i.allan@ericsson.com John Drake Juniper Email: jdrake@juniper.net George Swallow Cisco Systems, Inc. Email: swallow@cisco.com Annamaria Fulignoli Ericsson Email: annamaria.fulignoli@ericsson.com Sami Boutros Cisco Systems, Inc. Email: sboutros@cisco.com Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com David Ward Juniper Email: dward@juniper.net Allan et al., Expires January 12, 2011 [Page 16]