Network Working Group                                   N. Sprecher, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                            T. Nadeau, Ed.
Expires: March 7, 2009                                                BT
                                                    H. van Helvoort, Ed.
                                                                  Huawei
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                       September 3, 2008


                          MPLS-TP OAM Analysis
               draft-sprecher-mpls-tp-oam-analysis-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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
   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 March 7, 2009.

Abstract

   The intention of this document is to analyze the set of requirements
   for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to
   verify whether the existing MPLS OAM tools can be applied to these
   requirements, identify which of the existing tools need to be
   extended, and which new tools should be defined.  Eventually, the
   purpose of the document is to recommend which of the existing tools
   should be extended and what new tools should be defined to support



Sprecher, et al.          Expires March 7, 2009                 [Page 1]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   the set of OAM requirements for MPLS-TP.

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












































Sprecher, et al.          Expires March 7, 2009                 [Page 2]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  PW VCCV  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.4.  Organization of the document . . . . . . . . . . . . . . .  6
   2.  Architectural requirements and general principles of
       operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Architectural and Principles of Operation -
           Recommendations and Guidelines . . . . . . . . . . . . . .  8
   3.  MPLS-TP OAM Functions  . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Continuity Check and Connectivity Verification . . . . . . 10
       3.1.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 10
       3.1.2.  Gaps analysis  . . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  Recommendations and Guidelines . . . . . . . . . . . . 11
     3.2.  Alarm Suppression  . . . . . . . . . . . . . . . . . . . . 11
       3.2.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 11
       3.2.2.  Recommendations and Guidelines . . . . . . . . . . . . 11
     3.3.  Lock Indication  . . . . . . . . . . . . . . . . . . . . . 11
       3.3.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 11
       3.3.2.  Recommendations and Guidelines . . . . . . . . . . . . 12
     3.4.  Packet Loss Measurement  . . . . . . . . . . . . . . . . . 12
       3.4.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 12
       3.4.2.  Recommendations and Guidelines . . . . . . . . . . . . 12
     3.5.  Diagnostic Test  . . . . . . . . . . . . . . . . . . . . . 12
       3.5.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 12
       3.5.2.  Recommendations and Guidelines . . . . . . . . . . . . 12
     3.6.  Trace Route  . . . . . . . . . . . . . . . . . . . . . . . 12
       3.6.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 12
       3.6.2.  Recommendations and Guidelines . . . . . . . . . . . . 12
     3.7.  Delay Measurement  . . . . . . . . . . . . . . . . . . . . 13
       3.7.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 13
       3.7.2.  Recommendations and Guidelines . . . . . . . . . . . . 13
     3.8.  Remote Defect Indication . . . . . . . . . . . . . . . . . 13
       3.8.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 13
       3.8.2.  Recommendations and Guidelines . . . . . . . . . . . . 13
     3.9.  Client Signal Fail . . . . . . . . . . . . . . . . . . . . 14
       3.9.1.  Existing tools . . . . . . . . . . . . . . . . . . . . 14
       3.9.2.  Recommendations and Guidelines . . . . . . . . . . . . 14
   4.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18




Sprecher, et al.          Expires March 7, 2009                 [Page 3]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


1.  Introduction

   OAM (Operations, Administration, and Maintenance) plays a significant
   and fundamental role in carrier networks, providing methods for fault
   management and performance monitoring in both the transport and the
   service layers on order to improve their ability to support services
   with guaranteed and strict SLAs while reducing their operational
   costs.

   [MPLS-TP Requirements] in general and [MPLS-TP OAM Requirements] in
   particular define a set of requirements on OAM functionality in
   MPLS-TP for MPLS-TP LSPs (network infrastructure) and PWs (services).

   The purpose of this document is to analyze the OAM requirements and
   verify whether the existing OAM tools defined for MPLS can be used to
   fulfill the requirements, identify which tools need to be extended to
   comply with the requirements, and which new tools need to be defined.
   The existing tools that are evaluated include LSP Ping (defined in
   [LSP Ping]), MPLS BFD (defined in [ MPLS BFD ]) and Virtual Circuit
   Connectivity Verification (defined in [PW VCCV] and [VCCV BFD]).

1.1.  LSP Ping

   LSP Ping is a variation of ICMP Ping and Traceroute [ICMP] that is
   adapted to MPLS LSP.  Addressing is based upon the LSP Label and
   label stack in order to guarantee that the echo messages are switched
   in-band of the LSP.  The messages are transmitted using IP/UDP
   encapsulation and IP addresses in the 127/8 (loopback) range.  The
   use of the loopback range guarantees that the LSP Ping messages will
   not be transmitted outside the LSP.

   LSP Ping extends the basic ICMP Ping operation (of data-plane
   connectivity and continuity check) with functionality to verify data-
   plane vs. control-plane consistency for a FEC and also MTU problems.
   The traceroute functionality is used to isolate and localize the MPLS
   faults, using the TTL to incrementally verify the path.  While LSP
   Ping is dependent upon the label propogation that may be performed
   over the control-plane via LDP, there is no direct dependence of LSP
   Ping on the control-plane.

   LSP Ping can be activated both in on-demand and pro-active
   (asynchronous) modes.

   [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP
   LSPs, and extends the techniques and mechanisms of LSP Ping to the
   MPLS P2MP environment.

   [LSP Ping over MPLS Tunnels] extends LSP Ping to operate over MPLS



Sprecher, et al.          Expires March 7, 2009                 [Page 4]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   tunnels or for a stitched LSP.

   TTL exhaust is the method for terminating flows at intermediate LSRs.

   LSP Ping is considered to be computational intensive.  In cases of
   LSP bundling, there is no guarantee that the LSP Ping packets will
   follow the same physical path used by the data traffic.

1.2.  MPLS BFD

   BFD (Bidirectional Forwarding Detection) is a mechanism that is
   defined for fast fault detection.  BFD defines a simple packet that
   may be transmitted over any protocol, dependent on the application
   that is employing the mechanism.  BFD is dependent upon creation of a
   session that is agreed upon by both ends of the link (which may be a
   single link, LSP, etc.) that is being checked.  In addition to the
   control packets that BFD defines, BFD supports an echo function to
   check the continuity, and verify the reachability of the desired
   destination.  BFD does not support a discovery mechanism nor support
   a traceroute capability for fault localization, these must be
   provided by use of other mechanisms.  The BFD packets support
   authentication between the routers being checked.

   BFD can be used in pro-active (asynchronous) and on-demand modes of
   operation.

   [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used
   to verify data-plane continuity.  It uses a simple hello protocol
   which can be easily implemented in hardware.  The end-points of the
   LSP exchange hello packets at negotiated regular intervals and an
   end-point is declared down when expected hello packets do not show
   up.  Failures in each direction can be monitored independently using
   the same BFD session.  The use of the BFD echo function and on-demand
   activation are outside the scope of the MPLS BFD specification.

   There is a need for a mechanism to bootstrap a BFD session and bind
   the session to a particular LSP or FEC.  LSP Ping is designated by
   [MPLS BFD] to bootstrap the BFD session in an MPLS environment.  The
   session BFD messages for MPLS are transmitted using a IP/UDP
   encapsulation.

   The Discriminator values, as currently used, provide only a locally
   unique context, since they are defined by the end-points of the ME.
   This limitation of the uniqueness of the session discriminator limits
   the used of BFD for connectivity verification, since (in extreme
   cases) it may be possible for crossing paths to use identical
   discriminators at their end-points. .




Sprecher, et al.          Expires March 7, 2009                 [Page 5]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


1.3.  PW VCCV

   PW VCCV provides end-to-end fault detection and diagnostics for PWs
   (regardless of the underlying tunneling technology).  The VCCV
   switching function provides a control channel associated with each PW
   (based on the PW Associated Channel Header which is defined in [PW-
   ACH], and allows sending OAM packets in-band with PW data (using CC
   Type 1: In-band VCCV)

   VCCV supports the following OAM mechanisms: ICMP Ping, LSP Ping and
   BFD.  ICMP and LSP Ping are IP encapsulated before being sent over
   the PW ACH.  BFD for VCCV supports two modes of encapsulation -
   either IP/UDP encapsulated (with IP/UDP header) or PW-ACH
   encapsulated (with no IP/UDP header) and provides support to signal
   the AC status..  The use of the VCCV control channel provides the
   context, based on the MPLS-PW label, required to bind and bootstrap
   the BFD session to a particular pseudo wire (FEC), eliminating the
   need to exchange Discriminator values.

   VCCV consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC label, and (2) switching
   component to cause the PW payload to be treated as a control packet.

   VCCV is not directly dependent upon the presence of a control plane.
   The VCCV capability negotiation may be performed as part of the PW
   signaling when LDP is used.  In case of manual configuration of the
   PW, it is the responsibility of the operator to set consistent
   options at both ends.

   Note: There is a need to prevent confusion between the Connectivity
   Verification function defined in [MPLS-TP OAM Requirements], and the
   ACH's CV type defined in [PW VCCV], that identifies the protocol that
   is being used over the control channel.

1.4.  Organization of the document

   The analysis of the architectural requirements and the general
   principles of operations are discussed first and then the
   requirements on the set of OAM functions.

   Eventually, the purpose of the document is to recommend which of the
   existing tools should be extended and what new tools should be
   defined to support the set of OAM requirements in MPLS-TP.


2.  Architectural requirements and general principles of operation

   [MPLS-TP OAM Requirements] defines a set of requirements on OAM



Sprecher, et al.          Expires March 7, 2009                 [Page 6]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   architecture and general principles of operations which are evaluated
   below:

   o  [MPLS-TP OAM Requirements] requires that OAM mechanisms in MPLS-TP
      are independent of the transmission media and of the client
      service being emulated by the PW.  The existing tools comply with
      this requirement.

   o  [MPLS-TP OAM Requirements] requires that MPLS-TP OAM MUST be able
      to operate without IP functionality and without relying on control
      and/or management planes.  It is required that OAM functionality
      MUST NOT be dependent on IP routing and forwarding capabilities.
      The existing tools do not rely on control and/or management plane,
      however the following should be observed regarding the reliance on
      IP functionality:

      *  LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header
         (UDP/IP) and do not comply with the requirement.  In the on-
         demand mode, LSP Ping also uses IP forwarding to reply back to
         the source router.  This dependence on IP, has further
         implications concerning the use of LSP Ping as the bootstrap
         mechanism for BFD for MPLS.

      *  VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
         for PWs and can comply with the requirement.

   o  [MPLS-TP OAM Requirements] requires that OAM tools for fault
      management do not rely on user traffic, and the existing MPLS OAM
      tools already comply with this requirement.  It is also required
      that OAM packets and the user traffic are congruent (i.e.  OAM
      packets are transmitted in-band) ad there is a need to
      differentiate OAM packets from user-plane ones.

      *  For PWs, VCCV provides a control channel associated with each
         PW which allows sending OAM packets in band of PWs and allow
         the receiving end-point to intercept, interpret, and process
         them locally as OAM messages.  VCCV defines different VCCV
         Connectivity Verification Types for MPLS (like ICMP Ping, LSP
         Ping and IP/UD encapsulated BFD and PW-ACH encapsulated BFD).

      *  Currently there is no distinct OAM payload identifier in MPLS
         shim.  BFD and LSP Ping packets for LSPs are carried over
         UDP/IP and are addressed to the loopback address range.  The
         router at the end-point intercepts, interprets, and processes
         the packets.






Sprecher, et al.          Expires March 7, 2009                 [Page 7]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   o  [MPLS-TP OAM Requirements] requires that the MPLS-TP OAM mechanism
      allows the propagation of AC (Attachment Circuit) failures and
      their clearance across a MPLS-TP domain

      *  BFD for VCCV supports a mechanism for "Fault detection and
         AC/PW Fault status signaling."  This can be used for both IP/
         UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by
         setting the appropriate VCCV Connectivity Verification
         Type.This mechanism could support this requirement.

   o  [MPLS-TP OAM Requirements] defines Maintenance Domain, Maintenance
      End Points (MEPs) and Maintenance Intermediate Points (MIPs).
      Means should be defined to provision these entities, both by
      static configuration (as it is required to operate OAM in the
      absence of any control plane or dynamic protocols) and by a
      control plane.

   o  [MPLS-TP OAM Requirements] requires a single OAM technology and
      consistent OAM capabilities for LSPs, PWs, MPLS-TP Links, and
      Tandem Connections.  There is currently no mechanism in the IETF
      to support OAM for Tandem Connections.  Also, the existing set of
      tools defines a different way of operating the OAM functions (e.g.
      LSP Ping to bootstrap MPLS BFD vs. VCCV).

   o  [MPLS-TP OAM Requirements] requires allowing OAM packets to be
      directed to an intermediate node (MIP) of a LSP/PW.  Technically,
      this could be supported by the proper setting of the TTL value.
      However, the applicability of such a solution needs to be examined
      per OAM function.  For details, see below.

   o  [MPLS-TP OAM Requirements] suggests that OAM messages MAY be
      authenticated.  BFD has a support for authentication.  Other tools
      should support this capability as well.

2.1.  Architectural and Principles of Operation - Recommendations and
      Guidelines

   Based on the requirements analysis above, the following guidelines
   should be followed to create an OAM environment that could more fully
   comply with the requirements cited:

   o  Extend the PW Associate Channel Header (ACH) to provide a control
      channel at the path and section levels.  This could then be
      associated with a MPLS-TP Link, LSP, or a Tandem Connection (TC).
      The ACH should then become a common mechanism for PW, LSP, MPLS-TP
      Link, and Tandem Connection.





Sprecher, et al.          Expires March 7, 2009                 [Page 8]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   o  Create a VPCV (Virtual Path Connectivity Verification) definition
      that would apply the definitions and functionality of VCCV to the
      MPLS-TP environment for LSP or Tandem Connection.  Need to support
      distinct identifier or label for all types of paths.

   o  Create or extend the VCCV definition to define a mechanism that
      would apply the definitions and functionality of VCCV to PW Tandem
      Connections

   o  Apply BFD to these new mechanisms using the control channel
      encapsulation, as defined above - allowing use of BFD for MPLS-TP
      independent of IP functionality.

   o  Define a mechanism to create TCME and allow transmission of the
      traffic via the Tandem Connection using label stacking.

   Creating these extensions/mechanisms would fulfil the following
   architectural requirements, mentioned above:

   o  Independence of IP forwarding and routing.

   o  OAM packets should be transmitted in-band.

   o  Support a single OAM technology for LSP, PW, MPLS-TP Link, and TC.

   In addition, the following additional requirements can be satisfied:

   o  Provide the ability to carry other types of communications (e.g.,
      APS, Management Control Channel (MCC), Signalling Control Channel
      (SCC)), by defining new types of communication channels for PWs,
      MPLS-TP Links, and LSPs.

   o  The design of the OAM mechanisms for MPLS-TP MUST allow the
      ability to support vendor specific and experimental OAM functions.


3.  MPLS-TP OAM Functions

   The following sections discuss the required OAM functions that were
   identified in [MPLS-TP OAM Requirements].

   LSP Ping is not considered a candidate to fulfill the required
   functionality, due its failure to comply with the basic architectural
   requirement for independence from IP routing and forwarding, as
   documented in Section 2 of this document.  However, usage of LSP
   Ping, in addition to the MPLS-TP OAM tools, or in MPLS-TP deployments
   with IP functionality is not precluded.




Sprecher, et al.          Expires March 7, 2009                 [Page 9]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


3.1.  Continuity Check and Connectivity Verification

   Continuity Check (CC) and Connectivity Verification (CV) are OAM
   operations generally used in tandem, and compliment each other.
   Together they are used to detect loss of traffic continuity and
   misconnections between MEPs and are useful for applications like
   Fault Management, Performance Monitoring and Protection Switching,
   etc.  To guarantee that CV can identify misconnections from cross-
   connections it is necessary that the CV tool use network-wide unique
   identifiers for the path checked in the session.

3.1.1.  Existing tools

   BFD can be used to support the pro-active OAM CC function when
   operated in the asynchronous mode.  However, the current definition
   of basic BFD is dependent on use of LSP Ping to bootstrap the BFD
   session.  Regarding the CV functional aspects, basic BFD has the
   limitation that it uses only locally unique session identifiers.

   VCCV can be used to carry BFD packets that are not IP/UDP
   encapsulated for CC on a PW and use the PW label to identify the
   path.

3.1.2.  Gaps analysis

   There is currently no tool that gives coverage for both CC and CV
   functionality.

   One possible option, is to extend BFD to fill the gaps indicated
   above.  The extension would include:

   o  A mechanism should be defined to carry BFD packets over LSP
      without reliance on IP functionality.

   o  A mechanism should be defined to bootstrap BFD sessions for MPLS
      that is not dependent on UDP.

   o  BFD needs to be used in conjunction with "globally" unique
      identifiers for the path or ME being checked to allow connectivity
      verfication support.  There are two possibilities, to allow BFD to
      support this new type of identifier -

      *  Change the semantics of the two Discriminator fields that exist
         in BFD and have each node select the ME unique identifier.
         This may have backward compatibility implications.

      *  Create a new optional field in the BFD packet that would
         identify the path being checked, in addition to the existing



Sprecher, et al.          Expires March 7, 2009                [Page 10]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


         session identifiers.

   o  Extensions to BFD would be needed to cover P2MP connections.

   An additional option would be to create a new tool that would give
   coverage for both CC and CV according to the requirements and the
   principles of operation (see section 2.1).  This option is less
   preferable.

3.1.3.  Recommendations and Guidelines

   Extend BFD to resolve the gaps, using a new optional field for the
   unique path identifier.

   Note that [MP BFD] defines a method for using BFD to provide
   verification of multipoint or multicast connectivity.

3.2.  Alarm Suppression

   Alarm Suppression is a function that is used by a server layer MEP to
   notify a failure condition to its client layer MEP(s) in order to
   suppress alarms that may be generated by maintenance domains of the
   client layer as a result of the failure condition in the server
   layer.

3.2.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.

3.2.2.  Recommendations and Guidelines

   Define a tool to support Alarm Suppression.

3.3.  Lock Indication

   Lock Indication is a function that is used by a server layer MEP to
   indicate an administrative locking of a server layer which may result
   in consequential interruption of data traffic forwarding towards the
   client layer MEP(s) expecting this traffic.  The reception of a Lock
   Indication allows a MEP to suppress alarms and to differentiate
   between a defect condition and an administrative locking action at
   the server layer MEP.

3.3.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.





Sprecher, et al.          Expires March 7, 2009                [Page 11]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


3.3.2.  Recommendations and Guidelines

   Define a tool to support Lock Indication.

3.4.  Packet Loss Measurement

   Packet Loss Measurement is a function that is used to verify the
   quality of the service.

3.4.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.

3.4.2.  Recommendations and Guidelines

   Define a tool to support Packet Loss Measurement.

3.5.  Diagnostic Test

   A diagnostic test is a function that is used between MEPs to verify
   bandwidth throughput, packet loss, bit errors, etc.

3.5.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.

3.5.2.  Recommendations and Guidelines

   Define a tool to support Diagnostic Test.

3.6.  Trace Route

   Trace route is a function that is used to determine the route of a
   connection across the MPLS transport network.

3.6.1.  Existing tools

   LSP Ping supports trace route but as it does not comply with the
   requirement for OAM functions to be independent on IP routing and
   forwarding capabilities, it can not be utilized for MPLS-TP

3.6.2.  Recommendations and Guidelines

   Define a new tool to support Trace Route.







Sprecher, et al.          Expires March 7, 2009                [Page 12]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


3.7.  Delay Measurement

   Delay Measurement is a function that is used to measure one-way or
   two-way delay of a packet transmission between a pair of MEPs.
   Where:

   o  One-way packet delay is the time elapsed from the start of
      transmission of the first bit of the packet by a source node until
      the reception of the first bit of that packet by the destination
      node.

   o  Two-way packet delay is the time elapsed from the start of
      transmission of the first bit of the packet by a source node until
      the reception of the last bit of the loop-backed packet by the
      same source node, when the loopback is performed at the packet's
      destination node.

3.7.1.  Existing tools

   There is no mechanism defined in the IETF that fulfills all of the
   MPLS-TP OAM requirements.

3.7.2.  Recommendations and Guidelines

   Define a tool to support Delay Measurement.

3.8.  Remote Defect Indication

   Remote Defect Indication (RDI) is used by a MEP to notify its peer
   MEP that a defect is detected on a bi-directional connection between
   them.

   This function should be supported in pro-active mode.

3.8.1.  Existing tools

   There is no mechanism defined in the IETF to fully support this
   functionality, however BFD supports a mechanism of informing the far-
   end that the session has gone down, and the Diagnostic field
   indicates the reason.

3.8.2.  Recommendations and Guidelines

   Either create a dedicated mechanism for this functionality or extend
   the BFD session functionality to support the functionality without
   disrupting the CC or CV functionality.





Sprecher, et al.          Expires March 7, 2009                [Page 13]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


3.9.  Client Signal Fail

   Client Signal Fail function (CSF) is used to propagate a Client
   Failure indication to the far-end sink when alarm suppression in the
   client layer is not supported.

3.9.1.  Existing tools

   There is a possibility of using the BFD over VCCV mechanism for
   "Fault detection and AC/PW Fault status signalling".  However, there
   is a need to differentiate between faults on the AC and the PW.

3.9.2.  Recommendations and Guidelines

   Either extend the BFD tool or define a tool to support Client Signal
   Fail propagation.


4.  Recommendation

   o  Define a Tandem Connection entity for both LSPs and PWs and allow
      the transmission of traffic by means of label stacking and proper
      TTL setting.

   o  Extend the ACH to provide a control channel for MPLS-TP Links,
      LSPs, and Tandem Connections.

   o  Define a VPCV mechanism for LSP and Tandem Connection.  This
      mechanism should reuse, as much as possible, the same principles
      of operation as VCCV.  The ACH should be extended to support CV
      types for each of the tools that are defined below, in a way that
      is consistent for PW, LSP and Tandem Connection.

   o  Extend the control and the management planes to support the
      configuration of the OAM maintenance entities and the set of
      functions to be supported by these entities.

   o  The appropriate assignment of network-wide unique identifiers
      needed to support connectivity verification should be considered.

   o  Tools should be defined to support the following functions:

      *  Connectivity verification

      *  Alarm suppression

      *  Lock indication




Sprecher, et al.          Expires March 7, 2009                [Page 14]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


      *  Packet loss measurement

      *  Diagnostic test

      *  Trace-route

      *  Delay measurement

      *  Remote defect indication

      *  Client signal fail

   o  The tools may have the capability to authenticate the messages.

   Notes:

   1.  We may consider having a document to define common CC and CV
       types of ACH for the use of VCCV and VPCV.

   2.  We may consider changing the name of the ACH "CV Type" to
       "Protocol Type" in order to avoid confusion with the CV function
       that is defined in [MPLS-TP OAM Requirements]


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   This document does not by itself raise any particular security
   considerations.


7.  Acknowledgements

   The authors wish to thank xxxxxxx for his review and proposed
   enhancements to the text.


8.  Informative References

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



Sprecher, et al.          Expires March 7, 2009                [Page 15]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


   [LSP Ping]
              Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [PW ACH]   Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

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

   [MP BFD]   Katz, D. and D. Ward, "BFD for Multipoint Networks",
              ID draft-katz-ward-bfd-multipoint-01.txt, December 2007.

   [VCCV BFD]
              Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
              Detection (BFD) for the Pseudowire Virtual Circuit
              Connectivity Verification (VCCV)",
              ID draft-ietf-pwe3-vccv-bfd-01.txt, February 2008.

   [P2MP LSP Ping]
              Nadeau, T. and A. Farrel, "Detecting Data Plane Failures
              in Point-to-Multipoint Multiprotocol Label Switching
              (MPLS) - Extensions to LSP Ping",
              ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.

   [MPLS LSP Ping]
              Bahadur, N. and K. Kompella, "Mechanism for performing
              LSP-Ping over MPLS tunnels",
              ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008.

   [MPLS-TP OAM Requirements]
              Vigoreux, M., Betts, M., and D. Ward, "Requirements for
              OAM in MPLS Transport Networks",
              ID draft-vigoreux-mpls-tp-oam-requirements-00, July 2008.

   [MPLS-TP Requirments]
              Nadeau, T. and C. Pignataro, "Requirements for the
              Trasport Profile of MPLS",
              ID draft-jenkins-mpls-mplstp-requirements-00, July 2008.









Sprecher, et al.          Expires March 7, 2009                [Page 16]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


Authors' Addresses

   Nurit Sprecher (editor)
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com


   Tom Nadeau (editor)
   BT
   United States

   Email: tom.nadeau@bt.com


   Huub van Helvoort (editor)
   Huawei
   Kolkgriend 38, 1356 BC Almere
   Netherlands

   Phone: +31 36 5316076
   Email: hhelvoort@huawei.com


   Yaacov Weingarten
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Phone: +972-9-775 1827
   Email: yaacov.weingarten@nsn.com
















Sprecher, et al.          Expires March 7, 2009                [Page 17]


Internet-Draft            MPLS-TP OAM Analysis            September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Sprecher, et al.          Expires March 7, 2009                [Page 18]