MPLS Working Group                                    A. Fulignoli, Ed.
Internet Draft                                                 Ericsson
Intended status: Standards Track
Expires: April 2010                                     S. Boutros, Ed.
                                                     Cisco Systems, Inc

                                                      M. Vigoureux, Ed.

                                                       October 16, 2009

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

   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
   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 April 17, 2010.

   Copyright Statement

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (
   info). Please review these documents carefully, as they describe
   your rights and restrictions with respect to this document.

Fulignoli et al.,      Expires April 16, 2010                 [Page 1]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009


   Continuity Check (CC), Proactive Connectivity Verification (CV) and
   Remote Defect Indication (RDI) functionalities are MPLS-TP OAM
   requirements listed in [3].

   Continuity Check monitors the integrity of the continuity of the path
   for any loss of continuity defect. Connectivity verification monitors
   the integrity of the routing of the path between sink and source for
   any connectivity issues. RDI enables an End Point to report, to its
   associated End Point, a fault or defect condition that it detects on
   a PW, LSP or Section.

   It is RECOMMENDED that a protocol solution, meeting one or more
   functional requirement(s), be the same for PWs, LSPs and Sections as
   per [3].

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

   Table of Contents

   1. Introduction................................................3
   1.1. Contributing Authors.......................................3
   2. Conventions used in this document............................3
   2.1. Terminology...............................................3
   3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD..........4
   3.1. MPLS-TP BFD CC Message format..............................5
   3.2. MPLS-TP BFD proactive CV/CC Message format.................5
   3.3. BFD Profile for MPLS-TP....................................6
   3.3.1. Timer negotiation........................................7
   3.3.2. Discriminator values.....................................7
   3.4. Remote Detection Indication (RDI)..........................7
   4. Operation...................................................7
   4.1. Unidirectional p2p or p2mp transport path..................8
   5. Acknowledgments.............................................9
   6. IANA Considerations.........................................9
   7. Security Considerations......................................9
   8. References..................................................9
   8.1. Normative References.......................................9
   8.2. Informative References....................................10

Fulignoli et al.,      Expires April 16, 2010                 [Page 2]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

1. Introduction

   In traditional transport networks, circuits are provisioned on
   multiple switches. Service Providers (SP) need OAM tools to detect
   mis-connectivity and loss of continuity of transport circuits. MPLS-
   TP LSPs [11] emulating traditional transport circuits need to provide
   the same CC and proactive CV capabilities as mentioned in [3]. This
   document describes the use of BFD [7] for CC, proactive CV, and RDI
   of an MPLS-TP LSP between two Maintenance End Points (MEPs).

   The mechanism specified in this document is restricted only to BFD
   asynchronous mode.

   The proposed method uses BFD state machine defined in Section 6.2 of
   [7] for bidirectional p2p connections and uses the p2mp BFD state
   machine defined in [8] for p2p unidirectional and p2mp unidirectional
   transport path.

   As described in [4], Continuity Check (CC) and Proactive Connectivity
   Verification (CV) functions are used to detect loss of continuity
   (LOC), unintended connectivity between two MEPs (e.g. mismerging or
   misconnection or unexpected MEP).

   The Remote Defect Indication (RDI) is an indicator that is
   transmitted by a MEP to communicate to its peer MEPs that a signal
   fail condition exists.RDI is only used for bidirectional connections
   and is associated with proactive CC & CV packet generation.

   The main goal here is to specify the BFD extension and behaviour to
   satisfy the CC, proactive CV monitoring and the RDI functionality.

1.1. Contributing Authors

Siva Sivabalan, George Swallow, David Ward.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
this document are to be interpreted as described in RFC-2119 [1].

2.1. Terminology

ACH: Associated Channel Header

BFD: Bidirectional Forwarding Detection

CV: Connection Verification

Fulignoli et al.,      Expires April 16, 2010                 [Page 3]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

EOS: End of Stack

GAL: Generalized Alert Label

LSR: Label Switching Router

MEP: Maintenance End Point

MIP: Maintenance Intermediate Point

MPLS-OAM: MPLS Operations, Administration and Maintenance

MPLS-TP: MPLS Transport Profile

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

MS-PW: Mult-Segment PseudoWire

NMS: Network Management System

PW: PseudoWire

RDI: Remote defect indication.

TTL: Time To Live

TLV: Type Length Value

3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD

   This document proposes two modes of BFD operation

   o CC mode: uses the existing ACH code point (0x0007) and BFD ACH
      packet encapsulation (BFD without IP/UDP headers ) as defined in
      [6]. In this mode Continuity Check and RDI functionalities are

   o CV/CC mode: defines a new code point in the Associated Channel
      Header (ACH) described in [2]. Under MPLS label stack of the MPLS-
      TP LSP, the ACH with "MPLS-TP Proactive CV/CC" code point
      indicates that the message is an MPLS-TP BFD proactive CV and CC

Fulignoli et al.,      Expires April 16, 2010                 [Page 4]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

    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  MPLS-TP CV/CC Code Point |

       Figure 1: ACH Indication of MPLS-TP Connection Verification

   The first nibble (0001b) indicates the ACH.

   The version and the reserved values are both set to 0 as specified in

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

   In this mode Continuity Check, Connectivity Verifications and RDI
   functionalities are supported.

   Both CC and CV/CC modes apply to PWs, MPLS LSPs (including tandem
   connection monitoring), and Sections

   It's possible to run the BFD in CC mode on some transport paths
   and the BFD in CV/CC mode on other transport paths. In any case,
   only one tool for OAM instance at time, configurable by
   operator, can run.

3.1. MPLS-TP BFD CC Message format

   The format of an MPLS-TP CC Message format is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |0 0 0 1|Version|     Flags     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |

3.2. MPLS-TP BFD proactive CV/CC Message format

   The format of an MPLS-TP CV/CC Message format is shown below, ACH
   TLVs MUST precede the BFD control packet.

Fulignoli et al.,      Expires April 16, 2010                 [Page 5]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

    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  MPLS-TP CV/CC Code Point |
   |                    ACH TLV Header                             |
   |                                                               |
   ~          Unique MEP-ID of source of the BFD packet            ~
   |                                                               |
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |

                     Figure 2: MPLS-TP CV/CC Message

   As shown in Figure 2, BFD Control packet as defined in [7] is
   transmitted as MPLS labeled packets along with ACH, ACH TLV Header
   defined in Section 3 of RFC 5586 and one ACH TLV object carrying the
   unique MEP Identifier of the source of the BFD packet defined in [12]

   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.

3.3. BFD Profile for MPLS-TP

   BFD MUST run in asynchronous mode as described in [7].

   No changes to the BFD state machine defined in [7] for p2p
   bidirectional transport path and in [8] for unidirectional p2p and
   p2mp transport path.

   BFD Control Packets are sent at regular configured time rate.

   BFD session is declared Down:

      If an unexpected MEP identifier is received (mis-connectivity

      If timer and detect multiplier re-negotiation is disabled and an
      unexpected desired min Tx interval field value or unexpected
      detect multiplier field are received (Unexpected period defect).

      If BFD session times out (Loss of Connectivity)

Fulignoli et al.,      Expires April 16, 2010                 [Page 6]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

3.3.1. Timer negotiation

   BFD timer values negotiation is optional and disabled by default on
   the MPLS-TP transport paths.

   Active Role is default, passive is optional.

   The configured BFD packet transmission is carried in the "Desired Min
   TX Interval field". For a bidirectional p2p transport path the
   "Required Min RX Interval field" MUST be the same as "Desired Min TX
   Interval field". The source MEP of an unidirectional p2p and p2mp
   session MUST set the "Required Min RX Interval field " to 0.

   The default timer values to be used based on what's recommended in

3.3.2. Discriminator values

   In the BFD control packet the discriminator values have either local
   or no significance.

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

3.4. Remote Detection Indication (RDI)

   The BFD Diagnostic (Diag) field defined in [8] can be used for this

   On MEP mismatch, loss of connectivity or unexpected timer and
   unexpected detect multiplier a MEP sends to its peer MEP a BFD packet
   with the Diagnostic (Diag) field value set to 1 (corresponding to the
   "Control Detection Time Expired").

   The value 0 indicates RDI condition has been cleared.

4. Operation

   For p2p bidirectional LSPs, both endpoints of the bidirectional MPLS-
   TP LSP MUST send BFD messages in-band in the MPLS-TP LSP using the
   defined code point.

   When on a configured bidirectional transport path the proactive CV/CC
   or CC monitoring is enabled, each MEP sends the BFD Control Packets
   at the rate of the configured transmission period and each MEP

Fulignoli et al.,      Expires April 16, 2010                 [Page 7]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

   expects to receive the BFD packets from its peer MEP at the same rate
   as per [4].

   MPLS labels at both MEPs are used to provide context for the received
   BFD packets.

   Active role is the default behavior, passive role is optional.

   In Active role both MEPs start sending initial BFD Control Packets
   with the State field set to "Down" value and with "Your
   discriminator" field set to zero.

                +-----+                    +-----+
                |     | ------- X -------->|     |
                |  A  | <----------------- |  B  |
                +-----+                    +-----+
                             Figure 3

   o If a MEP-B in Figure 3 detects one of the following faults (miss-
      connectivity, Unexpected Period or loss of continuity) from its
      peer MEP, it declares that the transport path in its receive
      direction is down (in other words, MEP-B enters the "receive
      defect" state for this transport path) and signals it to its peer
      MEP (MEP-A) sending  the BFD packets with State (Sta) field set to
      "Down" and Diagnostic code 1 (RDI)

   o In turn, the peer MEP (MEP-A) declares the transport path is down
      in its transmit direction, (in other words, MEP-A enters the
      "transmit defect" state for this transport path) setting the State
      (Sta field ) to Down with Diagnostic code 3 (Neighbor signaled
      session down) in its BFD packets towards MEP-B. Please note that
      if the failure is unidirectional, i.e. only from A to B direction
      as in Figure 1. MEP-A, transits first to Down State but then to
      Init state as it still receives BFD packets from its peer MEP B.

4.1. Unidirectional p2p or p2mp transport path.

   o In a unidirectional (point-to-point or point-to-multipoint)
      transport path, where the proactive CV/CC or CC monitoring is
      enabled, only the Source MEP is enabled to generate BFD packets
      with frequency of the configured transmission period and always
      with UP State information. This MEP does not expect to receive any
      BFD packets from its peer MEP(s), as such all state transitions
      are administratively driven.

Fulignoli et al.,      Expires April 16, 2010                 [Page 8]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

   o A MEP Sink, configured on a unidirectional transport path where
      the proactive CV and CC monitoring is enabled, expects to receive
      the BFD packets from its peer MEP at the configured frequency; the
      defects detection procedure is the same as the bidirectional MEP.

   Traffic MUST not be affected, when proactive CV/CC or CC monitoring
   is enabled/disabled by an operator on a configured MEP or when a BFD
   session transits from one state to another as per [4].

5. Acknowledgments

   To be added in a later version of this document

6. IANA Considerations

   To be added in a later version of this document

7. Security Considerations

   The security considerations for the authentication TLV need further

   Base BFD foresees an optional authentication section (see [7]
   section 6.7); that can be extended even to the tool proposed in
   this document.

   Authentication methods that require checksum calculation on the
   outgoing packet must extend the checksum even on the ME
   Identifier Section. This is possible but seems uncorrelated with
   the solution proposed in this document: it could be better to
   use the simple password authentication method.

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
         OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-
         requirements-03 (work in progress), August 2009

Fulignoli et al.,      Expires April 16, 2010                 [Page 9]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

   [4]   Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
         Overview", draft-ietf-mpls-tp-oam-framework-01 (work in
         progress), July 2009

   [5]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007

   [6]   Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
         Detection (BFD) for the Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-
         bfd-07 (work in progress), July 2009

   [7]   Katz, D. and D. Ward, "Bidirectional Forwarding
         Detection", draft-ietf-bfd-base-09 (work in progress),
         February 2009

   [8]   Katz, D. and D. Ward, "BFD for Multipoint Networks",
         draft-katz-ward-bfd-multipoint-02 (work in progress),
         February 2009

   [9]   Boutros, S. et al., "Definition of ACH TLV Structure",
         draft-ietf-mpls-tp-ach-tlv-00 (work in progress), June

   [10]  Aggarwal, R., Kompella, K., Nadeau, T. and G. Swallow,
         "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in
         progress), June 2008

   [11]  Bocci, M., et al., "A Framework for MPLS in Transport
         Networks", draft-ietf-mpls-tp-framework-05, (work in
         progress), September 2009

   [12]  Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
         swallow-mpls-tp-identifiers-01 (work in progress), July

8.2. Informative References

   To be added in a later version of this document

Fulignoli et al.,      Expires April 16, 2010                [Page 10]

Internet-Draft     draft-asm-mpls-tp-bfd-cc-cv-00         October 2009

   Authors' Addresses

   Annamaria Fulignoli (Editor)

   Sami Boutros (Editor)
   Cisco Systems, Inc.

   Martin Vigoureux (Editor)

   Contributing Authors' Addresses

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8

   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MASSACHUSETTS 01719
   United States

   David Ward
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California 95134

Fulignoli et al.,      Expires April 16, 2010                [Page 11]