--- 1/draft-ietf-mpls-tp-cc-cv-rdi-03.txt 2011-06-29 00:15:44.000000000 +0200 +++ 2/draft-ietf-mpls-tp-cc-cv-rdi-04.txt 2011-06-29 00:15:44.000000000 +0200 @@ -1,41 +1,42 @@ MPLS Working Group Dave Allan, Ed. Internet Draft Ericsson Intended status: Standards Track -Expires: August 2011 George Swallow Ed. +Expires: December 2011 George Swallow Ed. Cisco Systems, Inc John Drake Ed. Juniper - February 2, 2011 + June 2011 Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile - draft-ietf-mpls-tp-cc-cv-rdi-03 + draft-ietf-mpls-tp-cc-cv-rdi-04 Abstract - Continuity Check (CC), Proactive Connectivity Verification (CV) and - Remote Defect Indication (RDI) functionalities are required for MPLS- - TP OAM. + Continuity Check, Proactive Connectivity Verification and Remote + Defect Indication 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 - any connectivity issues. RDI enables an End Point to report, to its + Continuity Check monitors the integrity of the continuity of the + label switched path for any loss of continuity defect. Connectivity + verification monitors the integrity of the routing of the label + switched path between sink and source for any connectivity issues. + Remote defect indication 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. + a pseudo wire, label switched path 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). + This document specifies methods for proactive continuity check, + continuity verification, and remote defect indication for MPLS-TP + label switched paths, pseudo wires and Sections using Bidirectional + Forwarding Detection. 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 @@ -75,459 +76,557 @@ 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 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.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 + 3.1. Existing Capabilities........................................5 + 3.2. CC, CV, and RDI Overview.....................................5 + 3.3. ACH code points for CC and proactive CV......................6 + 3.4. MPLS BFD CC Message format...................................7 + 3.5. MPLS BFD proactive CV Message format.........................7 + 3.5.1. ICC-based MEP-ID...........................................9 + 3.5.2. Section MEP-ID.............................................9 + 3.5.3. LSP MEP-ID.................................................9 + 3.5.4. PW Endpoint MEP-ID........................................10 + 3.6. BFD Session in MPLS-TP terminology..........................11 + 3.7. BFD Profile for MPLS-TP.....................................11 + 3.7.1. Session initiation and Modification.......................13 + 3.7.2. Defect entry criteria.....................................13 + 3.7.3. Defect entry consequent action............................14 + 3.7.4. Defect exit criteria......................................15 + 3.7.5. State machines............................................15 + 3.7.6. Configuration of MPLS-TP BFD sessions.....................18 + 3.7.7. Discriminator values......................................18 + 4. Configuration Considerations..................................18 + 5. Acknowledgments...............................................19 + 6. IANA Considerations...........................................19 + 7. Security Considerations.......................................19 + 8. References....................................................20 + 8.1. Normative References........................................20 + 8.2. Informative References......................................20 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 [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). + connectivity and loss of continuity of transport circuits. Both + pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [10] + emulating traditional transport circuits need to provide the same + continuity check (CC) proactive continuity verification (CV) and + remote defect indication (RDI) 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 sub path maintenance entity (SPME) between + two Maintenance Entity Group End Points (MEPs). - As described in [11], Continuity Check (CC) and Proactive - Connectivity Verification (CV) functions are used to detect loss of + As described in [11], CC and CV functions are used to detect loss of continuity (LOC), and unintended connectivity between two MEPs (e.g. - mismerging or misconnectivity or unexpected MEP). + mis-merging or mis-connectivity 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. + 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 BFD + control 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 - uni-directional LSPs are for further study. + encapsulations include generic alert label (GAL)/G-ACh, virtual + circuit connectivity verification (VCCV) and UDP/IP. Procedures for + uni-directional p2p and p2mp LSPs are for further study. The mechanisms specified in this document are restricted to BFD asynchronous mode. 1.1. Authors David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami -Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. +Boutros, Siva Sivabalan, David Ward, Martin Vigoureux and Robert +Rennison. 2. Conventions used in this document 2.1. Terminology ACH: Associated Channel Header BFD: Bidirectional Forwarding Detection CV: Connectivity Verification GAL: Generalized Alert Label +G-ACh: Generic Associated Channel + LDI: Link Down Indication LKI: Lock Instruct LKR: Lock Report LSR: Label Switching Router +ME: Maintenance Entity + 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. +RDI: Remote Defect Indication SPME: Sub-Path Maintenance Entity + TTL: Time To Live TLV: Type Length Value VCCV: Virtual Circuit Connectivity Verification 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: + This document describes procedures for achieve combined CC, CV and + RDI functionality within a single MPLS-TP MEG using BFD. This + augments the capabilities that can be provided for MPLS-TP LSPs using + existing specified tools and procedures. - o CC mode: defines a new code point in the Associated Channel Header - (ACH) described in RFC 5586[2].In this mode Continuity Check and - RDI functionalities are supported. +3.1. Existing Capabilities - o CV mode: defines a new code point in the Associated Channel Header - (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. + A CC-only mode may be provided via protocols and procedures described + in RFC 5885[7] with ACH channel 7. These procedures may be applied to + bi-directional LSPs as well as PWs. - 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. + Implementations MAY also interoperate with existing equipment by + implementing [2], or [8] in addition to the procedures documented in + this memo. In accordance with RFC 5586[2], when BFD control packets + are encapsulated in an IP header, the fields in the IP header are set + as defined in RFC 5884[8]. When IP encapsulation is used CV mis- + connectivity defect detection can be performed by inferring a + globally unique source on the basis of the combination of the source + IP address and "my discriminator" fields. - 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. +3.2. CC, CV, and RDI Overview - 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. + The combined CC, CV, and RDI functionality for MPLS-TP is achieved by + multiplexing CC and CV PDUs within a single BFD session. The CV PDUs + are augmented with a source MEP ID TLV to permit mis-connectivity + detection to be performed by sink MEPs. -3.1. ACH code points for CC and proactive CV + The interleaving of PDUs is achieved via the use of distinct + encapsulations and code points for generic associated channel (G-ACh) + encapsulated BFD depending on whether the PDU format is CC or CV: + + o CC format: defines a new code point in the Associated Channel + Header (ACH) described in RFC 5586[2].This format supports + Continuity Check and RDI functionalities. + + o CV format: defines a new code point in the Associated Channel + Header (ACH) described in RFC 5586[2]. The ACH with "MPLS + Proactive CV" code point indicates that the message is an MPLS BFD + proactive CV message, and information for CV processing is + appended in the form of the source MEP ID TLV. + + RDI is communicated via the BFD diagnostic field in BFD CC 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 + multiplier have been exceeded, and with "5 - Path Down" as a + consequence of the sink MEP receiving AIS with LDI set. A sink MEP + that has started sending diagnostic code 5 SHOULD NOT change it to 1 + when the detection timer expires. + +3.3. 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 | + |0 0 0 1|Version| Flags | BFD CC/CV Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of MPLS-TP Connectivity 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 + - BFD CC code point = 0xXX. [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.] + - BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA + from the PW Associated Channel Type registry.] - Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and - Sections. + CC and CV PDUs apply to all pertinent MPLS-TP structures, including + 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- - ID and identified as requiring additional processing by the different - ACh channel type. When CC and CV are interleaved, the minimum - insertion interval for CV PDUs is one per second. + CC and CV operation is simultaneously employed on a maintenance + entity (ME) within a single BFD session. The expected usage is + that normal operation is to send CC BFD protocol data units + (PDUs) interleaved with a CV BFD PDU (augmented with a + source MEP-ID and identified as requiring additional + processing by the different ACh channel type). The + insertion interval for CV PDUs is one per second. Detection + of a loss of continuity defect is the detect multiplier (fixed at 3 + for the CC code point) times the session periodicity. Mis- + connectivity defects are detected in a maximum of one second. -3.2. MPLS BFD CC Message format +3.4. 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 | + |0 0 0 1|Version| Flags | 0xXX BFD CC Code point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS CC Message -3.3. MPLS BFD proactive CV Message format + As shown in figure 2, the MPLS CC message consists of the BFD control + packet as defined in [4] pre-pended by the ACh. + +3.5. MPLS BFD proactive CV Message format The format of an MPLS CV 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 CV Code Point | + |0 0 0 1|Version| Flags | 0xXX+1 BFD CV Code Point | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | - ~ Unique MEP-ID of source of the BFD packet ~ + ~ MEP Source ID TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. + As shown in figure 3, the MPLS CV message consists of the BFD control + packet as defined in [4] pre-pended by the ACH, and appended by a MEP + source ID TLV. 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. + length Value field. A BFD session will only use one encoding of the + Source ID TLV. - 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: + The length in the BFD control packet is as per [4], the MEP Source ID + TLV is not included. There are 3 possible Source MEP TLVs + (corresponding to the MEP-IDs defined in [9]) [type fields to be + assigned by IANA]. The type fields are: - X1 - ICC encoded MEP-ID + X1 - Section MEP-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). + When GAL label is used, the time to live (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 +3.5.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. + ICC based MEP-IDs are for further study. -3.3.2. LSP MEP-ID +3.5.2. Section 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. + The IP compatible MEP-IDs for MPLS-TP sections is the interface ID. + The format of the Section MEP-ID TLV is: -3.3.3. PW Endpoint MEP-ID + 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 = | Length = | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Global_ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Node Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Interface Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 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. + Where the type is of value 'xx' (to be assigned by IANA). The length + is the length of the value fields. The MPLS-TP Global ID, Node + Identifier and Interface Numbers are as per [9]. - 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.5.3. LSP MEP-ID -3.4. BFD Session in MPLS-TP terminology + The format for the LSP MEP-ID is as defined in [9]. This consists of + 32-bit MPLS-TP Global ID, the 32-bit Node Identifier, followed by the + 16-bit Tunnel_Num (that MUST be unique within the context of the Node + Identifier), and the 16-bit LSP_NUM (that MUST be unique with the + context of the Tunnel Num). The format of the TLV is: - A BFD session corresponds to a CC or a proactive CV OAM instance in - MPLS-TP terminology. + 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 = | Length = | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Global_ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Node Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tunnel_Num | LSP_Num | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - A BFD session is enabled when the CC or proactive CV functionality is - enabled on a configured Maintenance Entity (ME).. + Where the type is of value 'xx+1' (to be assigned by IANA). The + length is the length of the value fields. The MPLS-TP Global ID, Node + Identifier, Tunnel Num and LSP_Num are as per [9]. - On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as - detailed in [4]. +3.5.4. PW Endpoint MEP-ID - When on a ME the CC or proactive CV functionality is disabled, the + The format the MPLS_TP PW Endpoint MEP-ID is as defined in [9]. The + format of the TLV is: + + 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 = | Length = | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Global_ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MPLS-TP Node Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC_ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AGI Type | AGI Length | AGI Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ AGI Value (contd.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Where the type is value 'xx+2' (to be assigned by IANA). The length + is the length of the following data. The Global ID, Node Identifier + and Attachment Circuit (AC)_ID are as per [9]. The Attachment Group + Identifier (AGI) Type is as per [6], and the AGI length is the length + of the AGI value field. + +3.6. BFD Session in MPLS-TP terminology + + A BFD session corresponds to a CC and proactive CV OAM instance in + MPLS-TP terminology. A BFD session is enabled when the CC and + proactive CV functionality is enabled on a configured Maintenance + Entity (ME). + + When the CC and proactive CV functionality is disabled on an ME, 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. + enables the CC and CV functionality. -3.5. BFD Profile for MPLS-TP + All BFD state changes and P/F exchanges MUST be done using CC + packets. P/F and session state information in CV packets MUST be + ignored. - 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. - Poll/final discipline can only used for VCCV and UDP/IP encapsulated - BFD. +3.7. BFD Profile for MPLS-TP - This document specifies bi-directional BFD for p2p transport LSPs, - hence the M bit MUST be clear. + BFD operates in asynchronous mode utilizing the encapsulation defined + in section 3 for all sessions in a given MEG. For LSPs, SPMEs and + sections this is GAL/G-ACh encapsulated BFD using the code points + specified in section 3.1. For PWs, this is G-ACh encapsulated BFD + using the code points specified in section 3.1. In this mode, the BFD + Control packets are periodically sent at configurable time rate. This + rate is a fixed value common for both directions of MEG for the + lifetime of the MEG. + + This document specifies bi-directional BFD for p2p transport LSPs; + hence all BFD packets MUST be sent with the M bit 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. + directions operate independently but are still part of the same MEG. + A single bi-directional BFD session is used for coordinated + operation. Two independent BFD sessions are used for independent + operation. It should be noted that independent operation treats + session state and defect state as independent entities. For example + an independent session can be in the UP state while receiving RDI + indication. For a coordinated session, the session state will track + the defect state. - Coordinated operation is as described in [4]. Independent operation - requires clarification of two aspects of [4]. Independent operation - 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 LSP. Each source MEP will have a corresponding sink MEP - that has been configured to a Tx interval of zero. + In coordinated mode, an implementation SHOULD NOT reset + bfd.RemoteDiscr until it is exiting the DOWN state. + + In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr + upon transitioning to the DOWN state. + + Overall operation is as specified in [4] and augmented for MPLS in + [8]. Coordinated operation is as described in [4]. Independent + operation requires clarification of two aspects of [4]. Independent + operation is characterized by the setting of bfd.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 LSP. 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 on the reverse component of the bi-directional LSP 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 on the reverse component 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 that include the RDI diagnostic code 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 either control detection period expired or - neighbor signaled session down offering RDI functionality). + bfd.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 that include the RDI diagnostic code 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 either control detection + period expired or neighbor signaled session down 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 [5] and the Lock Instruct/Lock Report transactions; Lock Report interaction being optional. -3.5.1. Session initiation +3.7.1. Session initiation and Modification - 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 of configuration error (to be - assigned by IANA) indicating that the requested Tx rate cannot be - supported. + Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 + second and the detect multiplier = 3. + Once in the UP state, poll/final discipline is used to modify the + periodicity of control message exchange from their default rates to + the desired rates and set the detect multiplier to 3. - 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 and/or - configured rate and the detect interval switches to detect multiplier - times the session peer's Tx Rate. + Once the desired rate has been reached using the poll/final + mechanism, implementations SHOULD NOT attempt further rate + modification. -3.5.2. Defect entry criteria + In the rare circumstance where an operator has a reason to further + change session parameters, beyond the initial migration from default + values; poll/final discipline can be used with the caveat that a peer + implementation may consider a session change unacceptable and/or + bring the BFD session down. + +3.7.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]. + [4] to consider given the possibility of mis-connectivity 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: + PDUs: 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). + 2. Receipt of a link down indication or lock report. 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 - - receiving an IP encoded CC or CV packet on a LSP configured - to use GAL/GaCH, or vice versa + - receiving an IP encoded CC or CV BFD control packet on a + LSP configured to use GAL/G-ACh, 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). + (Mis-connectivity defect). Note that as each encoding of the + Source MEP ID TLV contains unique information (there is no + mechanical translation possible between MEP ID formats), receipt + of an unexpected source MEP ID type is the same as receiving an + unexpected value. + 3. Receipt of a session discriminator that is not in the local BFD + database in the your discriminator field (mis-connectivity + defect). + 4. Receipt of a session discriminator that is in the local database + but does not have the expected 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. + 2. Receiving link down indication. E.g. a local link failure, an + MPLS-TP LDI indication, or Lock Report. 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. + 5. Receiving BFD control packets in all discernable ways correct. -3.5.3. Defect entry consequent action +3.7.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. + peer using CC messages. - 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- + The blocking of traffic as a consequent action MUST be driven only by + a defect's consequent action as specified in draft-ietf-mpls-tp-oam- 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 + When the defect is mis-connectivity, the LSP termination will + silently discard all non-OAM traffic received. The sink MEP will also + send a defect indication back to the source MEP via the use of a + diagnostic code of mis-connectivity defect. -3.5.4.1. Exit from a Loss of continuity defect +3.7.4. Defect exit criteria + +3.7.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 - - Exit from a misconfiguration defect occurs when two consecutive CC or - CV frames have been received with the expected M bit setting. + occurs upon receipt of a well formed BFD control packet from the peer + MEP as described in figures 5 and 6. -3.5.4.3. Exit from a mis-connectivity defect +3.7.4.2. Exit from a mis-connectivity defect 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. + with mis-connectivity defects have been received for a period of 3.5 + seconds. -3.5.5. State machines +3.7.5. State machines The following state machines update [4]. They have been modified to 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. @@ -544,34 +643,34 @@ | | ADMIN DOWN,| | | |ADMIN DOWN, DOWN,| | | |TIMER TIMER,| | V |AIS-LDI,LKR AIS-LDI,LKR | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ - Figure 4: State machine for coordinated session operation + Figure 4: MPLS CC 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). + source MEP (who requested bfd.MinRxInterval=0) and the sink MEP (who + agreed to bfd.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 AIS-with LDI set and optionally LKR do not enter into the state machine transition from the UP state, but do enter into the INIT and DOWN states. +--+ - | | UP, ADMIN DOWN, TIMER + | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | |ADMIN DOWN ADMIN DOWN | | | |TIMER, | | | |AIS-LDI, | | @@ -571,26 +670,27 @@ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | |ADMIN DOWN ADMIN DOWN | | | |TIMER, | | | |AIS-LDI, | | V |LKR | V +------+ +------+ +----| | | |----+ + DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, +--->| | INIT, UP | |<---+ AIS-LDI, LKR +------+ +------+ - Figure 5: State machine for source MEP for independent session - operation + Figure 5: MPLS CC 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. @@ -607,121 +707,146 @@ | |ADMIN DOWN, TIMER, | | | |TIMER, DOWN, | | | |AIS-LDI, AIS-LDI, | V V |LKR LKR | | +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ - Figure 6: State machine for the sink MEP for independent session - operation + Figure 6: MPLS CC State machine for the sink MEP for independent + session operation -3.5.6. Configuration of MPLS-TP BFD sessions +3.7.6. Configuration of MPLS-TP BFD sessions - Configuration of MPLS-TP BFD session paramters and coordination of + Configuration of MPLS-TP BFD session parameters and coordination of same between the source and sink MEPs is out of scope of this memo. -3.5.7. Discriminator values +3.7.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. Per RFC5884 Section 7 [8], a node MUST NOT change the value of the "my discriminator" field for an established BFD session. +4. Configuration Considerations -4. Acknowledgments + The following is an exemplary set of configuration parameters for a + BFD session: - Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit - Sprecher and Yaacov Weingarten also contributed to this - document. + Mode and Encapsulation + RFC 5884 - BFD CC in UDP/IP/LSP + RFC 5885 - BFD CC in G-ACh + RFC 5085 - UDP/IP in G-ACh + MPLS-TP - CC/CV in GAL/G-ACh or G-ACh -5. IANA Considerations + For MPLS-TP, the following additional parameters need to be + configured: + 1) Session mode, coordinated or independent + 2) CC periodicity + 3) The MEG/MEP ID for the MEPs at either end of the LSP + 4) Whether authentication is enabled (and if so, the associated + parameters) - This draft requires the allocation of two channel types from the - the IANA "PW Associated Channel Type" registry in RFC4446 [6]. + And the following parameters can optionally be configured or locally + assigned: + 1) The discriminators used by each MEP. Both bfd.LocalDiscr and + bfd.RemoteDiscr. - Xx MPLS-TP CC message + Finally the following is directly inferred: + 1) Detect multiplier of 3 - Xx+1 MPLS-TP CV message +5. Acknowledgments + + Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit Sprecher + and Yaacov Weingarten also contributed to this document. +6. IANA Considerations + + This draft requires the allocation of two channel types from the IANA + "PW Associated Channel Type" registry in RFC4446 [6]. + XX MPLS-TP CC message + XX+1 MPLS-TP CV message This draft requires the creations of a source MEP-ID TLV registry with initial values of: - Xx - ICC encoded MEP-ID + Xx - Section 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 + Xx - - misconnectivity defect -6. Security Considerations +7. Security Considerations Base BFD foresees an optional authentication section (see [4] section 6.7); that can be applied to this application. -7. References +8. References -7.1. Normative 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 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-03 (work in progress), October 2010 + ietf-mpls-tp-fault-04 (work in progress), April 2011 [6] Martini, L., " IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", RFC 4446, April 2006 [7] Nadeau, T. et al. "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) ", IETF RFC 5885, June 2010 [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010 [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- - ietf-mpls-tp-identifiers-03 (work in progress), October - 2010 + ietf-mpls-tp-identifiers-06 (work in progress), June 2011 -7.2. Informative References +8.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 + ietf-mpls-tp-oam-framework-11 (work in progress), February + 2011 + + [12] Nadeau, T, et al., "Pseudowire Virtual Circuit + Connectivity Verification (VCCV): A Control Channel for + Pseudowires", RFC 5085, December 2007 Authors' Addresses Dave Allan Ericsson Email: david.i.allan@ericsson.com John Drake Juniper Email: jdrake@juniper.net @@ -742,10 +867,14 @@ Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.com Siva Sivabalan Cisco Systems, Inc. Email: msiva@cisco.com David Ward Juniper Email: dward@juniper.net + + Robert Rennison + ECI Telecom + Email: robert.rennison@ecitele.com