--- 1/draft-ietf-mpls-tp-cc-cv-rdi-02.txt 2011-02-03 15:14:02.000000000 +0100 +++ 2/draft-ietf-mpls-tp-cc-cv-rdi-03.txt 2011-02-03 15:14:02.000000000 +0100 @@ -1,24 +1,24 @@ MPLS Working Group Dave Allan, Ed. Internet Draft Ericsson Intended status: Standards Track -Expires: April 2011 George Swallow Ed. +Expires: August 2011 George Swallow Ed. Cisco Systems, Inc John Drake Ed. Juniper - October 22, 2010 + February 2, 2011 Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile - draft-ietf-mpls-tp-cc-cv-rdi-02 + draft-ietf-mpls-tp-cc-cv-rdi-03 Abstract Continuity Check (CC), Proactive Connectivity Verification (CV) and Remote Defect Indication (RDI) functionalities are required for MPLS- TP OAM. Continuity Check monitors the integrity of the continuity of the LSP for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the LSP between sink and source for @@ -51,79 +51,81 @@ 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. + This Internet-Draft will expire on August 2nd 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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........................................5 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 3.1. ACH code points for CC and proactive CV......................6 3.2. MPLS BFD CC Message format...................................6 3.3. MPLS BFD proactive CV Message format.........................7 - 3.4. BFD Session in MPLS-TP terminology...........................7 - 3.5. BFD Profile for MPLS-TP......................................8 - 3.5.1. Session initiation.........................................9 - 3.5.2. Defect entry criteria......................................9 - 3.5.3. Defect entry consequent action............................10 - 3.5.4. Defect exit criteria......................................11 - 3.5.5. State machines............................................11 - 3.5.6. Configuration of MPLS-TP BFD sessions.....................14 - 3.5.7. Discriminator values......................................14 - 4. Acknowledgments...............................................15 - 5. IANA Considerations...........................................15 - 6. Security Considerations.......................................15 - 7. References....................................................15 - 7.1. Normative References........................................15 - 7.2. Informative References......................................16 + 3.3.1. ICC-based MEP-ID...........................................8 + 3.3.2. LSP MEP-ID.................................................8 + 3.3.3. PW Endpoint MEP-ID.........................................8 + 3.4. BFD Session in MPLS-TP terminology...........................8 + 3.5. BFD Profile for MPLS-TP......................................9 + 3.5.1. Session initiation........................................10 + 3.5.2. Defect entry criteria.....................................10 + 3.5.3. Defect entry consequent action............................11 + 3.5.4. Defect exit criteria......................................12 + 3.5.5. State machines............................................12 + 3.5.6. Configuration of MPLS-TP BFD sessions.....................15 + 3.5.7. Discriminator values......................................15 + 4. Acknowledgments...............................................16 + 5. IANA Considerations...........................................16 + 6. Security Considerations.......................................16 + 7. References....................................................16 + 7.1. Normative References........................................16 + 7.2. Informative References......................................17 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 SPME between - two Maintenance Entity Group End Points (MEPs). + and MPLS-TP LSPs [10] emulating traditional transport circuits need + to provide the same CC and proactive CV capabilities as required in + RFC 5860[3]. This document describes the use of BFD for CC, proactive + CV, and RDI of a PW, LSP or SPME 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 misconnectivity or unexpected MEP). + As described in [11], 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 misconnectivity 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 LSPs 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 both co-routed and associated bi-directional LSPs. Supported encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for @@ -178,55 +180,56 @@ RDI: Remote Defect Indication. SPME: Sub-Path Maintenance Entity TTL: Time To Live TLV: Type Length Value VCCV: Virtual Circuit Connectivity Verification -2.2. Issues for discussion - - 1) Requirement for additional BFD diagnostic codes? - - 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 ACh encapsulated 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. + (ACH) described in RFC 5586[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]. The ACH with "MPLS Proactive CV" code - point indicates that the message is an MPLS BFD proactive CV and - CC message and CC, CV and RDI functionalities are supported. + (ACH) described in RFC 5586[2]. The ACH with "MPLS Proactive CV" + code point indicates that the message is an MPLS BFD proactive CV + and CC message and CC, CV and RDI functionalities are supported. RDI: is communicated via the BFD diagnostic field in BFD CC and CV messages. It is not a distinct PDU. A sink MEP will encode a diagnostic code of "1- Control detection time expired" when the interval times detect multipler have been exceeded, and with "3 - neighbor signaled session down" as a consequence of the sink MEP receiving AIS with LDI set. A sink MEP that has started sending diag code 3 will NOT change it to 1 when the detection timer expires. - In accordance with RFC 5586, when these packets are encapsulated in - an IP header the fields in the IP header are set as defined in RFC - 5884. It should also be noted that existing ACh code points and - mechanisms for negotiating the control channel and connectivity - verification (i.e. OAM functions) between PEs are specified for - VCCV[6]. + In accordance with RFC 5586[2], when these packets are encapsulated + in an IP header, the fields in the IP header are set as defined in + RFC 5884[8]. Further existing ACh code points and mechanisms for BFD + VCCV are specified in RFC5885[7]. These MAY be applied to + Pseudowires by configuration. Also by configuration, the BFD PW-ACH- + encapsulated for PW fault detection only encapsulation can be applied + to bi-directional LSPs by employing the GAL to indicate the presence + of the ACh. + + A further artifact of IP encapsulation is that CV mis-connectivity + defect detection can be performed by inferring MEP_ID on the basis of + the combination of the source IP address and "my discriminator" + fields. 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 Connectivity Verification @@ -236,28 +239,29 @@ 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. + Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and + Sections. CC and CV operation can be simultaneously employed on an ME within a single BFD session. The expected usage is that normal operation is to - send CC BFD PDUs with every nth BFD PDU augmented with a source MEP + send CC BFD PDUs with every nth BFD PDU augmented with a source MEP- ID and identified as requiring additional processing by the different - ACh channel type. + ACh channel type. When CC and CV are interleaved, the minimum + insertion interval for CV PDUs is one per second. 3.2. MPLS BFD CC Message format The format of an MPLS CC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Flags | 0xHH BFD CC Code point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -282,36 +286,75 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unique MEP-ID of source of the BFD 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 the ACH. Appended to - the BFD control packet is a MEP Source ID TLV. The length in the BFD - control packet is as per [4]. There are 4 possible Source MEP TLVs - (corresponding to the MEP IDs defined in [8] [type fields to be - assigned by IANA]. The type fields are: + the BFD control packet is a MEP Source ID TLV. - X1 - ICC encoded MEP ID + A MEP Source ID TLV is encoded as a 2 octet field that specifies a + Type, followed by a 2 octet Length Field, followed by a variable + length Value field. - X2 - LSP-MEP_ID + The length in the BFD control packet is as per [4]. There are 3 + Source MEP TLVs (corresponding to the MEP-IDs defined in Error! + Reference source not found. [type fields to be assigned by IANA]. The + type fields are: - X3 - PW MEP ID + X1 - ICC encoded MEP-ID - X4 - PW Segment endpoint ID + X2 - LSP MEP-ID + + X3 - PW MEP-ID 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). + A node MUST NOT change the value in the MEP Source ID TLV. + + When digest based authentication is used, the Source ID TLV MUST NOT + be included in the digest + +3.3.1. ICC-based MEP-ID + + As defined in [9], the ICC-based MEP_ID consists of the MEG_ID, a + string of up to 13 characters (A-Z and 0-9), followed by the MEP + Index, an unsigned 16 bit integer that MUST be unique within the + context of the MEG_ID. + +3.3.2. LSP MEP-ID + + As defined in [9], the MPLS_TP LSP MEP-ID consists of the Node + Identifier, a thirty two bit identifier that MUST be unique within + the context of an operator's network, followed by the Tunnel_Num, an + unsigned sixteen bit integer that MUST be unique within the context + of the Node Identifier, and the LSP_NUM, an unsigned sixteen bit + integer that MUST be unique with the context of the Tunnel Num. + +3.3.3. PW Endpoint MEP-ID + + As defined in [9], the PW Endpoint MEP-ID consists of the Node + Identifier, a thirty two bit identifier that MUST be unique within + the context of an operator's network, followed by the AC_ID, a thirty + two bit identifier that MUST be unique within the context of the Node + Identifier. + + In situations where global uniqueness is required, the Node + Identifier is preceded by the Global ID, a thirty two bit identifier + that contains the two-octet (right hand justified and preceded by + sixteen bits of zero) or four-octet value of the operator's + Autonomous System Number (ASN). + 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).. On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as detailed in [4]. @@ -322,27 +365,24 @@ 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, the session must be moved to the ADMIN DOWN state. + parameters, the session MUST be moved to the ADMIN DOWN state. Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD. - 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 LSPs, hence the M bit MUST be clear. There are two modes of operation for bi-directional LSPs. One in which the session state of both directions of the LSP 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. @@ -380,30 +420,31 @@ machine; these are the Link Down Indication [5] and the Lock Instruct/Lock Report transactions; Lock Report interaction being optional. 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. + state and sends a diagnostic code of configuration error (to be + assigned by IANA) 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]. In both the DOWN and INIT states messages are transmitted at a rate of one per second and the defect detection interval is fixed at 3.5 seconds. On transition to the UP - state message periodicity changes to the negotiated rate and the - detect interval switches to detect multiplier times the session - peer's Tx Rate. + state, message periodicity changes to the negotiated and/or + configured rate and the detect interval switches to detect multiplier + times the session peer's Tx Rate. 3.5.2. Defect entry criteria There are further defect criteria beyond those that are defined in [4] to consider given the possibility of mis-connectivity and mis- configuration defects. The result is the criteria for a LSP 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 or CV: @@ -401,39 +442,42 @@ 3.5.2. Defect entry criteria There are further defect criteria beyond those that are defined in [4] to consider given the possibility of mis-connectivity and mis- configuration defects. The result is the criteria for a LSP 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 or 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 + - receiving an IP encoded CC or CV packet on a LSP configured + to use GAL/GaCH, or vice versa (note there are other possibilities that can also alias as an OAM packet) 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). + 5. IF BFD authentication is used, receipt of a message with + incorrect authentication information (password, MD5 digest, or + SHA1 hash). 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). @@ -443,59 +487,52 @@ 5. Receiving control packets in all discernable ways correct. 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. - + framework [11] section 5.1.1.2. When the defect is mis-branching, the LSP termination will silently discard all non-oam traffic received. 3.5.4. Defect exit criteria 3.5.4.1. 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. 3.5.4.2. Exit from a session mis-configuration defect - [editors: for a future version of the document] + Exit from a misconfiguration defect occurs when two consecutive CC or + CV frames have been received with the expected M bit setting. 3.5.4.3. Exit from a mis-connectivity defect - [Editors node: The shift to CC with interleaved CV suggests the CV - periodicity may not be known by a sink MEP, hence exit criteria from - a mis-connectivity defect may not be able to be established. We - suggest two possible resolutions for this: - - 1. Exit criteria is manual intervention. - - 2. A minimum CV insertion rate (say 1/sec) be specified such that - the exit criteria be specified as no mis-connected CV PDUs be - received for a minimum of 3 times the minimum insertion rate] + Exit from a mis-connectivity defect state occurs when no CV messages + have been received with an incorrect source MEP-ID for a period of + 3.5 seconds. 3.5.5. State machines The following state machines update [4]. They have been modified to - include AIS with LDI set and LKI as inputs to the state machine and - to clarify the behavior for independent mode. LKR is an optional - input. + include AIS with LDI set and LKI as specified in [5] as inputs to the + state machine and to clarify the behavior for independent mode. LKR + is an optional input. The coordinated session state machine has been augmented to indicate AIS with LDI set and optionally LKR as inputs to the state machine. For a session that is in the UP state, receipt of AIS with LDI set or optionally LKR will transition the session into the DOWN state. +--+ | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | V DOWN +------+ INIT @@ -575,95 +612,115 @@ +----| | | |----+ 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] + Configuration of MPLS-TP BFD session paramters and coordination of + same between the source and sink MEPs is out of scope of this memo. 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. + Per RFC5884 Section 7 [8], a node MUST NOT change the value of the + "my discriminator" field for an established BFD session. 4. Acknowledgments - To be added in a later version of this document + Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit + Sprecher and Yaacov Weingarten also contributed to this + document. 5. IANA Considerations - To be added in a later version of this document + This draft requires the allocation of two channel types from the + the IANA "PW Associated Channel Type" registry in RFC4446 [6]. -6. Security Considerations + Xx MPLS-TP CC message - The security considerations for the authentication TLV need further - study. + Xx+1 MPLS-TP CV message - Base BFD foresees an optional authentication section (see [4] - section 6.7); that can be extended also to the tool proposed in - this document. + This draft requires the creations of a source MEP-ID TLV + registry with initial values of: - 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. + Xx - ICC encoded MEP-ID + + Xx+1 - LSP MEP-ID + + Xx+2 - PW MEP-ID + + The source MEP-ID TLV will require standards action registration + procedures for additional values. + + This memo requests a code point from the registry for BFD + diagnostic codes [4]: + + Xx - configuration error + +6. Security Considerations + + Base BFD foresees an optional authentication section (see [4] + section 6.7); that can be applied to this application. 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] Swallow, G. et al., "MPLS Fault Management OAM", draft- - ietf-mpls-tp-fault-02 (work in progress), July 2010 + ietf-mpls-tp-fault-03 (work in progress), October 2010 - [6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit - Connectivity Verification (VCCV): A Control Channel for - Pseudowires", RFC 5085, December 2007 + [6] Martini, L., " IANA Allocations for Pseudowire Edge to + Edge Emulation (PWE3)", RFC 4446, April 2006 -7.2. Informative References + [7] Nadeau, T. et al. "Bidirectional Forwarding Detection + (BFD) for the Pseudowire Virtual Circuit Connectivity + Verification (VCCV) ", IETF RFC 5885, June 2010 - [7] Bocci, M., et al., "A Framework for MPLS in Transport - Networks", RFC5921, July 2010 + [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection + (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, + June 2010 - [8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- - swallow-mpls-tp-identifiers-02 (work in progress), July + [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- + ietf-mpls-tp-identifiers-03 (work in progress), October 2010 - [9] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- - ietf-mpls-tp-oam-framework-09 (work in progress), October +7.2. Informative References + + [10] Bocci, M., et al., "A Framework for MPLS in Transport + Networks", RFC5921, July 2010 + + [11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- + ietf-mpls-tp-oam-framework-10 (work in progress), December 2010 Authors' Addresses Dave Allan Ericsson Email: david.i.allan@ericsson.com John Drake Juniper