[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: August 2011                                  George Swallow Ed.
                                                      Cisco Systems, Inc

                                                          John Drake Ed.
                                                                 Juniper

                                                        February 2, 2011


     Proactive Connectivity Verification, Continuity Check and Remote
               Defect indication for MPLS Transport Profile
                      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
   any connectivity issues. RDI enables an End Point to report, to its
   associated End Point, a fault or defect condition that it detects on
   a PW, LSP or Section.

   This document specifies methods for proactive CV, CC, and RDI for
   MPLS-TP Label Switched Path (LSP), PWs and Sections using
   Bidirectional Forwarding Detection (BFD).


Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [1].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance
   with the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working


Allan et al.,             Expires July 2011                    [Page 1]


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 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
   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 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. 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

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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


   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 [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 [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
   uni-directional LSPs are for further study.

   The mechanisms specified in this document are restricted to BFD
   asynchronous mode.




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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


1.1. Authors

David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami
Boutros, Siva Sivabalan, David Ward, Martin Vigoureux.

2. Conventions used in this document

2.1. Terminology

ACH: Associated Channel Header

BFD: Bidirectional Forwarding Detection

CV: Connectivity Verification

GAL: Generalized Alert Label

LDI: Link Down Indication

LKI: Lock Instruct

LKR: Lock Report

LSR: Label Switching Router

MEG: Maintenance Entity Group

MEP: Maintenance Entity Group End Point

MIP: Maintenance Entity Group Intermediate Point

MPLS-OAM: MPLS Operations, Administration and Maintenance

MPLS-TP: MPLS Transport Profile

MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path
representing a circuit

MS-PW: Multi-Segment PseudoWire

NMS: Network Management System

PW: Pseudo Wire

RDI: Remote Defect Indication.

SPME: Sub-Path Maintenance Entity


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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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:

  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.

  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.

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







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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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


   The first nibble (0001b) indicates the ACH.

   The version and the flags are set to 0 as specified in [2].

   The code point is either

   - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW
   Associated Channel Type registry.] or,

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

   Both CC and CV modes apply to PWs, MPLS LSPs (including 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.

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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 2: MPLS CC Message


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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


3.3. 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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~          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.

   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.

   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:

      X1 - ICC encoded 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).

   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 August, 2011                  [Page 7]


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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

   When on a ME the CC or proactive CV functionality is disabled, the
   BFD session transitions to the ADMIN DOWN State and the BFD session
   ends.

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


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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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.
   Poll/final discipline can only used for VCCV and UDP/IP encapsulated
   BFD.

   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.

   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.

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

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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


   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

   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.

   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.

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


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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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

     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.

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 [11] section 5.1.1.2.
   When the defect is mis-branching, the LSP termination will silently
   discard all non-oam traffic received.





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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


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

   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

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
















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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011



                             +--+
                             |  | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR
                             |  V
               DOWN        +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               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


   For independent mode, there are two state machines. One for the
   source MEP (who requested MinRxInterval=0) and the sink MEP (who
   agreed to MinRxInterval=0).

   The source MEP will not transition out of the UP state once
   initialized except in the case of a forced ADMIN DOWN. Hence 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.













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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011




                             +--+
                             |  | UP, ADMIN DOWN, TIMER
                             |  V
               DOWN        +------+  INIT
              +------------|      |------------+
              |            | 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

   The sink MEP state machine (for which the transmit interval has been
   set to zero) is modified to:

   1) Permit direct transition from DOWN to UP once the session has been
   initialized. With the exception of via the ADMIN DOWN state, the
   source MEP will never transition from the UP state, hence in normal
   unidirectional fault scenarios will never transition to the INIT
   state.











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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011



                             +--+
                             |  | 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: State machine for the sink MEP for independent session
                                 operation

3.5.6. Configuration of MPLS-TP BFD sessions

   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.

   Per RFC5884 Section 7 [8], a node MUST NOT change the value of the
   "my discriminator" field for an established  BFD session.




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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


4. Acknowledgments

   Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit
   Sprecher and Yaacov Weingarten also contributed to this
   document.

5. IANA Considerations

   This draft requires the allocation of two channel types from the
   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+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

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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


  [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

  [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



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














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


Internet-Draft     draft-ietf-mpls-tp-cc-cv-rdi-03        February 2011


   Authors' Addresses

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

   John Drake
   Juniper
   Email: jdrake@juniper.net

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

   Annamaria Fulignoli
   Ericsson
   Email: annamaria.fulignoli@ericsson.com

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

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

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

   David Ward
   Juniper
   Email: dward@juniper.net
















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


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