[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-mpls-tp-bfd-cc-cv) 00 01 02 03 04 05 06 RFC 6428

MPLS Working Group                                       Dave Allan, Ed.
Internet Draft                                                 Ericsson
Intended status: Standards Track
Expires: December 2011                                George Swallow Ed.
                                                      Cisco Systems, Inc

                                                          John Drake Ed.

                                                               June 2011

     Proactive Connectivity Verification, Continuity Check and Remote
               Defect indication for MPLS Transport Profile


   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
   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 pseudo wire, label switched path or Section.

   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",
   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 December 2011                  [Page 1]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 2nd 2011.

Copyright Notice

   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
   3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5
   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

Allan et al.,           Expires December, 2011                 [Page 2]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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
   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], CC and CV functions are used to detect loss of
   continuity (LOC), and unintended connectivity between two MEPs (e.g.
   mis-merging or mis-connectivity or unexpected MEP).

   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 generic alert label (GAL)/G-ACh, virtual

Allan et al.,           Expires December, 2011                 [Page 3]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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 and Robert

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

Allan et al.,           Expires December, 2011                 [Page 4]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

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

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 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.

3.1. Existing Capabilities

   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.

   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.

3.2. CC, CV, and RDI Overview

   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.

Allan et al.,           Expires December, 2011                 [Page 5]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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     |      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 = 0xXX. [HH to be assigned by IANA from the PW
   Associated Channel Type registry.] or,

   - BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA
   from the PW Associated Channel Type registry.]

   CC and CV PDUs apply to all pertinent MPLS-TP structures, including
   PWs, MPLS LSPs (including SPMEs), and Sections.

Allan et al.,           Expires December, 2011                 [Page 6]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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.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     |    0xXX BFD CC Code point     |
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
                     Figure 2: MPLS CC Message

   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.

Allan et al.,           Expires December, 2011                 [Page 7]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

    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     |    0xXX+1 BFD CV Code Point   |
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
   |                                                               |
   ~                      MEP Source ID TLV                        ~
   |                                                               |

                     Figure 3: MPLS CV Message

   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. A BFD session will only use one encoding of the
   Source ID TLV.

   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 - Section MEP-ID

      X2 - LSP MEP-ID

      X3 - PW MEP-ID

   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

   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

Allan et al.,           Expires December, 2011                 [Page 8]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

3.5.1. ICC-based MEP-ID

   ICC based MEP-IDs are for further study.

3.5.2. Section MEP-ID

   The IP compatible MEP-IDs for MPLS-TP sections is the interface ID.
   The format of the Section MEP-ID 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                    |
   |                    MPLS-TP Interface Number                   |

   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].

3.5.3. LSP MEP-ID

   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:

   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 =                     |

Allan et al.,           Expires December, 2011                 [Page 9]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   |                       MPLS-TP Global_ID                       |
   |                    MPLS-TP Node Identifier                    |
   |           Tunnel_Num          |            LSP_Num            |

   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].

3.5.4. PW Endpoint MEP-ID

   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.)                        ~
   |                                                               |

Allan et al.,           Expires December, 2011                [Page 10]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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

   A new BFD session is initiated when the operator enables or re-
   enables the CC and CV functionality.

   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

3.7. BFD Profile for MPLS-TP

   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 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

Allan et al.,           Expires December, 2011                [Page 11]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   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.

   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

   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
   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

   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

Allan et al.,           Expires December, 2011                [Page 12]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

3.7.1. Session initiation and Modification

   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.

   Once the desired rate has been reached using the poll/final
   mechanism, implementations SHOULD NOT attempt further rate

   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 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
     1. BFD session times out (Loss of Continuity 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
     1. BFD control packets are received with an unexpected
        encapsulation (mis-connectivity defect), these include:
          - 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)

Allan et al.,           Expires December, 2011                [Page 13]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

     2. Receipt of an unexpected globally unique Source MEP identifier
        (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
     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. E.g. a local link failure, an
        MPLS-TP LDI indication, or Lock Report.

     3. Receiving from an incorrect source (determined by whatever

     4. Receiving from a correct source (as near as can be determined),
        but with incorrect session information).

     5. Receiving BFD control packets in all discernable ways correct.

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 using CC messages.

   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

   When the defect is mis-connectivity, the LSP termination will
   silently discard all non-OAM traffic received. The sink MEP will also

Allan et al.,           Expires December, 2011                [Page 14]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   send a defect indication back to the source MEP via the use of a
   diagnostic code of mis-connectivity defect.

3.7.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 BFD control packet from the peer
   MEP as described in figures 5 and 6. Exit from a mis-connectivity defect

   Exit from a mis-connectivity defect state occurs when no CV messages
   with mis-connectivity defects have been received for a period of 3.5

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.

                             |  | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
                             |  V
               DOWN        +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               ADMIN DOWN,|  |
              |  |ADMIN DOWN,          DOWN,|  |

Allan et al.,           Expires December, 2011                [Page 15]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

              |  |TIMER               TIMER,|  |
              V  |AIS-LDI,LKR   AIS-LDI,LKR |  V
            +------+                      +------+
       +----|      |                      |      |----+
   DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
       +--->|      | INIT, UP             |      |<---+
            +------+                      +------+

   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 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

                             |  | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
                             |  V
               DOWN        +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |ADMIN DOWN     ADMIN DOWN |  |
              |  |TIMER,                    |  |
              |  |AIS-LDI,                  |  |
              V  |LKR                       |  V
            +------+                      +------+
       +----|      |                      |      |----+

Allan et al.,           Expires December, 2011                [Page 16]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   DOWN|    | INIT |--------------------->|  UP  |    | INIT, UP, DOWN,
       +--->|      | INIT, UP             |      |<---+ AIS-LDI, LKR
            +------+                      +------+

   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

                             |  | ADMIN DOWN, TIMER, AIS-LDI, LKR
                             |  V
               DOWN        +------+  INIT, UP
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               ADMIN DOWN,|  |
              |  |ADMIN DOWN,    TIMER,     |  |
              |  |TIMER,         DOWN,      |  |
              |  |AIS-LDI,       AIS-LDI,   |  V
             V  |LKR            LKR        |  |
            +------+                      +------+
       +----|      |                      |      |----+
   DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
       +--->|      | INIT, UP             |      |<---+
            +------+                      +------+

     Figure 6: MPLS CC State machine for the sink MEP for independent
                             session operation

Allan et al.,           Expires December, 2011                [Page 17]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

3.7.6. Configuration of MPLS-TP BFD sessions

   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.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

   The following is an exemplary set of configuration parameters for a
   BFD session:

   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

   For MPLS-TP, the following additional parameters need to be
   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

Allan et al.,           Expires December, 2011                [Page 18]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   And the following parameters can optionally be configured or locally
   1) The discriminators used by each MEP. Both bfd.LocalDiscr and

   Finally the following is directly inferred:
   1) Detect multiplier of 3

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   - 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 -
              - misconnectivity defect

7. Security Considerations

   Base BFD foresees an optional authentication section (see [4]
   section 6.7); that can be applied to this application.

Allan et al.,           Expires December, 2011                [Page 19]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

8. References

8.1. Normative References

  [1]   Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

  [2]   Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
        5586 , June 2009

  [3]   Vigoureux, M., Betts, M. and D. Ward, "Requirements for
        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-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-06 (work in progress), June 2011

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-11 (work in progress), February

  [12]  Nadeau, T, et al., "Pseudowire Virtual Circuit
        Connectivity Verification (VCCV): A Control Channel for
        Pseudowires", RFC 5085, December 2007

Allan et al.,           Expires December, 2011                [Page 20]

Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-04            June 2011

   Authors' Addresses

   Dave Allan
   Email: david.i.allan@ericsson.com

   John Drake
   Email: jdrake@juniper.net

   George Swallow
   Cisco Systems, Inc.
   Email: swallow@cisco.com

   Annamaria Fulignoli
   Email: annamaria.fulignoli@ericsson.com

   Sami Boutros
   Cisco Systems, Inc.
   Email: sboutros@cisco.com

   Martin Vigoureux
   Email: martin.vigoureux@alcatel-lucent.com

   Siva Sivabalan
   Cisco Systems, Inc.
   Email: msiva@cisco.com

   David Ward
   Email: dward@juniper.net

   Robert Rennison
   ECI Telecom
   Email: robert.rennison@ecitele.com

Allan et al.,           Expires December, 2011                [Page 21]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/