[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sprecher-opsawg-mplstp-oam-analysis) 00 01 02 03 04 05 06 07 draft-ietf-mpls-tp-oam-analysis

Network Working Group                                   N. Sprecher, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                            T. Nadeau, Ed.
Expires: November 11, 2009                                            BT
                                                    H. van Helvoort, Ed.
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                            May 10, 2009

                          MPLS-TP OAM Analysis

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-

   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 November 11, 2009.

Copyright Notice

   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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Sprecher, et al.        Expires November 11, 2009               [Page 1]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009


   The intention of this document is to analyze the set of requirements
   for Operations, Administration, and Maintenance (OAM) for the
   Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs],
   to evaluate whether existing OAM tools (either from the current MPLS
   toolset or from the ITU-T documents) can be applied to these
   requirements.  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 for

Sprecher, et al.        Expires November 11, 2009               [Page 2]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

Table of Contents

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

Sprecher, et al.        Expires November 11, 2009               [Page 3]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

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 in order to improve their ability to support services
   with guaranteed and strict Service Level Agreements (SLAs) while
   reducing their operational costs.

   [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular
   define a set of requirements for OAM functionality in MPLS-Transport
   Profile (MPLS-TP) for MPLS-TP Label Switched Paths (LSPs) (network
   infrastructure) and Pseudowires (PWs) (services).

   The purpose of this document is to analyze the OAM requirements and
   evaluate whether existing OAM tools defined for MPLS can be used to
   meet the requirements, identify which tools need to be extended to
   comply with the requirements, and which new tools need to be defined.
   We also take the ITU-T OAM toolset, as defined in [Y.1731], as a
   candidate to base these new tools upon.  The existing tools that are
   evaluated include LSP Ping (defined in [LSP Ping]), MPLS Bi-
   directional Forwarding Detection (BFD) (defined in [MPLS BFD]) and
   Virtual Circuit Connectivity Verification (VCCV) (defined in [PW
   VCCV] and [VCCV BFD]), and the ITU-T OAM toolset defined in [Y.1731].

1.1.  LSP Ping

   LSP Ping is a variation of ICMP Ping and traceroute [ICMP]] adapted
   to the different needs of MPLS LSP.  Forwarding, of the LSP Ping
   packets, is based upon the LSP Label and label stack, in order to
   guarantee that the echo messages are switched in-band (i.e. over the
   same data route) of the LSP.  However, it should be noted that 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 be terminated, by a loss
   of connectivity or inability to continue on the path, without being
   transmitted beyond the LSP.  The return message of the LSP Ping could
   be sent either on the return LSP of a corouted bidirectional LSP, or
   for associated bidirectional LSPs or unidirectional LSPs may be sent
   using IP forwarding to the IP address of the LSP ingress node.

   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 Forwarding Equivalence
   Class (FEC) and also Maximum Transmission Unit (MTU) problems.  The
   traceroute functionality may be used to isolate and localize the MPLS
   faults, using the Time-to-live (TTL) indicator to incrementally
   identify the sub-path of the LSP that is succesfully traversed before

Sprecher, et al.        Expires November 11, 2009               [Page 4]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   the faulty link or node.  LSP Ping is not dependent on the MPLS
   control-plane for its operation, i.e. even though the propagation of
   the LSP label may be performed over the control-plane via the Label
   Distribution Protocol (LDP).

   LSP Ping can be activated both in on-demand and pro-active
   (asynchronous) modes, as defined in [MPLS-TP OAM Reqs].

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

   [MPLS LSP Ping] extends LSP Ping to operate over MPLS tunnels or for
   a stitched LSP.

   As pointed out above, TTL exhaust is the method used to terminate
   flows at intermediate LSRs, usually to locate a problem that was
   discovered previously.

   Some of the drawbacks identified with LSP Ping include - LSP Ping is
   considered to be computational intensive as pointed out in [MPLS
   BFD].  Use of the loopback address range (to protect against leakage
   outside the LSP) assumes that all of the intermediate nodes support
   some IP functionality.  When LSP bundling is employed in the network,
   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 for point-to-point connections.  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.  The session is assigned a separate identifier by each end
   of the path being monitored.  This session identifier is by nature
   only unique within the context of node that assigned it.  As part of
   the session creation, the end-points negotiate an agreed transmission
   rate for the BFD packets.  BFD supports an echo function to check the
   continuity, and verify the reachability of the desired destination.
   BFD does not support neither a discovery mechanism nor 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, as
   defined in [MPLS-TP OAM Reqs], of operation.

Sprecher, et al.        Expires November 11, 2009               [Page 5]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

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

   The BFD session mechanism requires an additional (external) mechanism
   to bootstrap and bind the session to a particular LSP or FEC.  LSP
   Ping is designated by [MPLS BFD] as the bootstrap mechanism for the
   BFD session in an MPLS environment.  The implication is that the
   session establishment BFD messages for MPLS are transmitted using a
   IP/UDP encapsulation.

   In order to be able to identify certain extreme cases of mis-
   connectivity, it is necessary that each managed connection have its
   own unique identifiers.  BFD uses Discriminator values to identify
   the connection being verified, at both ends of the path.  These
   discriminator values are set by each end-node to be unique only in
   the context of that node.  This limited scope of uniqueness would not
   identify a misconnection of crossing paths that could assign the same
   discriminators to the different sessions.

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 (ACH) which is defined in
   [PW ACH]), and allows sending OAM packets in-band with PW data (using
   CC Type 1: In-band VCCV)

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

Sprecher, et al.        Expires November 11, 2009               [Page 6]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   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.

1.4.  ITU Recommendation Y.1731

   [Y.1731] specifies a set of OAM procedures and related packet data
   unit (PDU) formats that meet the transport network requirements for
   OAM.  These PDU and procedures address similar requirements to those
   outlined in [MPLS-TP OAM Reqs].

   The PDU and procedures are described relative to an Ethernet
   environment, with the appropriate encapsulation for that environment.
   However, the actual PDU formats are technology agnostic and could be
   carried over different encapsulations, e.g.  VCCV control channel.
   The OAM procedures, likewise, could be supported by MPLS-TP nodes
   just as they are supported by Ethernet nodes.

   [Y.1731] describes procedures to support the following OAM functions:

   o  Connectivity and Continuity Monitoring - for end-to-end checking

   o  Loopback functionality - to verify connectivity to intermediate

   o  Link trace - provides information on the intermediate nodes of the
      path being monitored, may be used for fault localization.

   o  Alarm indication signaling - for alarm suppression in case of
      faults that are detected at the server layer.

   o  Remote defect indication &ndash as part of the Connectivity and
      Continuity Monitoring packets

   o  Performance monitoring - including measurement of packet delays
      both uni and bi-directional, measurement of the ratio of lost
      packets, and the effective bandwidth that is supported without
      packet loss.

   It should be noted that the PDU defined in [Y.1731] includes various
   information elements (fields) that may not be defined in [MPLS-TP OAM
   Framework].  These fields include information on the MEG-Level,
   OpCode, and version.  Addressing of the PDU as defined in [Y.1731] is
   based on the MAC Address of the nodes, which would need to be
   adjusted to support other addressing schemes, length of additional
   information.  The addressing information is carried in <Type, Length,

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

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   Value> (TLV) fields that follow the actual PDU.

1.5.  Acronyms

                  This draft uses the following acronyms:

       | AC      | Attachment Circuit                             |
       | ACH     | Associated Channel Header                      |
       | BFD     | Bidirectional Forwarding Detection             |
       | CC-V    | Continuity Check and Connectivity Verification |
       | FEC     | Forwarding Equivalence Class                   |
       | LDP     | Label Distribution Protocol                    |
       | LSP     | Label Switched Path                            |
       | ME      | Maintenance Entitity                           |
       | MEP     | Maintenance End Point                          |
       | MIP     | Maintenance Intermediate Point                 |
       | MPLS-TP | Transport Profile for MPLS                     |
       | OAM     | Operations, Administration, and Maintenance    |
       | PDU     | Packet Data Unit                               |
       | PW      | Pseudowire                                     |
       | RDI     | Remote Defect Indication                       |
       | SLA     | Service Level Agreement                        |
       | TC      | Tandem Connection                              |
       | TCME    | Tandem Connection Maintenance Entity           |
       | TTL     | Time-to-live                                   |
       | VCCV    | Virtual Circuit Connectivity Verification      |
       | VPCV    | Virtual Path Connectivity Verification         |

1.6.  Organization of the document

   Section 2 of the document analyzes the requirements that are
   documented in [MPLS-TP OAM Reqs] and provides basic principles of
   operation for the OAM functionality that is required.

   Section 3 evaluates which existing tools can provide coverage for the
   different OAM functions that are required to support MPLS-TP.

   Section 4 provides recommendations on what functionality could be
   covered by the existing toolset and what extensions or new tools
   would be needed in order to provide full coverage of the OAM
   functionality for MPLS-TP.

2.  Architectural requirements and general principles of operation

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

Sprecher, et al.        Expires November 11, 2009               [Page 8]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   and general principles of operations which are evaluated below:

   o  [MPLS-TP OAM Reqs] 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

   o  [MPLS-TP OAM Reqs] 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.

      *  Y.1731 PDU are technology agnostic and thereby not dependent on
         IP functionality.  These PDU could be carried by a VCCV control

   o  [MPLS-TP OAM Reqs] requires that OAM tools for fault management do
      not rely on user traffic, and the existing MPLS OAM tools and
      Y.1731 already comply with this requirement.

   o  It is also required that OAM packets and the user traffic are
      congruent (i.e.  OAM packets are transmitted in-band) and there is
      a need to differentiate OAM packets from user-plane ones.

      *  For PWs, VCCV provides a control channel that can be 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/UDP encapsulated BFD and PW-ACH encapsulated

      *  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

Sprecher, et al.        Expires November 11, 2009               [Page 9]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

         router at the end-point intercepts, interprets, and processes
         the packets.

      *  The Y.1731 PDU could be carried over a control channel defined
         along the data path and the processing of the PDU would occur
         at the destination indicated in the PDU.

   o  [MPLS-TP OAM Reqs] 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 Reqs] 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.
      Note that the Y.1731 functionality currently supports these

   o  [MPLS-TP OAM Reqs] 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).  Currently, the Y.1731
      functionality is defined for Ethernet paths, and the procedures
      would need to be redefined for the various MPLS-TP path concepts.

   o  [MPLS-TP OAM Reqs] 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 Reqs] suggests that OAM messages MAY be
      authenticated.  BFD has a support for authentication.  Other tools
      should support this capability as well.  Y.1731 functionality uses
      the identification of the path for authentication.

Sprecher, et al.        Expires November 11, 2009              [Page 10]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

2.1.  Architectural and Principles of Operation - Recommendations and

   Based on the requirements analysis above, the following guidelines
   should be followed to create an OAM environment that could more fully
   support 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.

   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 a
      generalized addressing scheme that can also support unique
      identification of the monitored paths (or connections).

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

   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.  This could be used to address
      the CC-V functionality

   o  The Y.1731 PDU set could be used as a basis for defining the
      information units to be transmitted over the VPCV.  The actual
      procedures and addressing schemes would need to be adjusted for
      the MPLS-TP environment.

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

   o  Define a mechanism that could be used to address a MIP of a path
      in a unique way, to support the maintenance functions.  This
      addressing should be flexible to allow support for different
      addressing schemes, and would supplement the TTL addressing of
      intermediate points.

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

   o  Independence of IP forwarding and routing.

Sprecher, et al.        Expires November 11, 2009              [Page 11]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

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

   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.

3.1.  Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification (CC-V) 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 CC-V can identify misconnections from cross-
   connections it is necessary that the tool use network-wide unique
   identifiers for the path that is being checked in the session.

3.1.1.  Existing tools

   LSP Ping provides much of the functionality required for corouted
   bidirectional LSPs.  As observed above, LSP Ping may be operated in
   both asynchronous and on-demand mode.  Addressing is based on the LSP
   label and the basic functionality only requires support for the
   loopback address range in each node on the LSP path.

   BFD defines functionality that can be used to support the pro-active
   OAM CC-V function when operated in the asynchronous mode.  However,

Sprecher, et al.        Expires November 11, 2009              [Page 12]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   the current definition of basic BFD is dependent on use of LSP Ping
   to bootstrap the BFD session.  Regarding the connectivity functional
   aspects, basic BFD has a limitation that it uses only locally unique
   (to each node) session identifiers.

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

   Y.1731 provides functionality for all aspects of CC-V for an Ethernet
   environment, this could be translated for the MPLS-TP environment.
   The CCM PDU defined in [Y.1731] includes the ability to set the
   frequency of the messages that are transmitted, and provides for
   attaching the address of the path (in the Ethernet case - the MEG
   Level) and a sequencing number to verify that CCM messages were not

3.1.2.  Gap analysis

   There is currently no single MPLS tool that gives coverage for all
   aspects of CC-V functionality.

   LSP Ping could be used to cover the cases of corouted bidirectional
   LSPs.  However, there is a certain amount of computational overhead
   involved with use of LSP Ping (as was observed in sec 1.1), the
   verification of the control-plane, and the need to support the
   loopback functionality at each intermediate node.

   BFD could be extended 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 packet carrying the BFD that
         would identify the path being checked, in addition to the

Sprecher, et al.        Expires November 11, 2009              [Page 13]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

         existing session identifiers.

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

   Use of the Y.1731 functionality is another option that should be
   considered.  The basic PDU for CCM includes (in the flags field) an
   indication of the frequency of the packets [eliminating the need to
   "negotiate" the frequency between the end-points], and also a flag
   used for RDI.  The procedure itself would need adaptation to comply
   with the MPLS environment.

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

3.1.3.  Recommendations and Guidelines

   Extend BFD to resolve the gaps, using a new optional field for the
   unique path identifier.  And optionally support the PDU format
   defined in [Y.1731] with appropriate adjustments to support the
   MPLS-TP architecture.

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

3.2.  Alarm Notification

   Alarm Notification 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.  This function should also have the capability to
   differentiate an administrative lock from a failure condition at a
   different execution level.

3.2.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   Y.1731 does define a PDU and procedure for this functionality.

3.2.2.  Recommendations and Guidelines

   Define a tool to support Alarm Notification.  This tool could be
   designed around the PDU proposed by [Y.1731] that includes support
   for an indication of the frequency at which these messages are
   transmitted after the alarm is raised until it is cleared.

Sprecher, et al.        Expires November 11, 2009              [Page 14]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

3.3.  Diagnostic

   A diagnostic test is a function that is used between MEPs to verify
   bandwidth throughput, packet loss, bit errors, etc.  This is usually
   performed by sending packets of varying sizes at increasing rates
   (until the limits of the service level) to measure the actual

3.3.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   [Y.1731] describes a function that is dependent on sending a series
   of TST packets (this is a PDU whose size can be varied) at differing

3.3.2.  Recommendations and Guidelines

   Define a tool to support Diagnostic that could be based on the Y.1731

3.4.  Adjacency and Route Tracing

   Functinality of route determination is used to determine the route of
   a connection across the MPLS transport network.  [MPLS-TP OAM Reqs]
   defines two closely related operations - one, Adjacency, for
   discovery of neighboring nodes and the other, Route Tracing, for
   determination of the path that is being traversed and location of a
   fault identified by e.g. the CC-V tool.

3.4.1.  Existing tools

   LSP Ping supports a trace route function that could be used for co-
   routed bidirectional paths.  This could support the second type of

   However, the discovery aspect that is described by the Adjacency
   function does not have any available tools, neither in the IETF
   toolset nor in the ITU recommendations.

3.4.2.  Recommendations and Guidelines

   Define a new tool to support the Adjacency functionality.

   For the Route Trace functionality, either extend the LSP Ping
   functionality to support other options, i.e.  PW, associated
   bidirectional LSP, or define a new tool.

Sprecher, et al.        Expires November 11, 2009              [Page 15]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

3.5.  Lock

   The Lock function allows the system to block off transmission of data
   along a LSP.  When a path end-point receives a command, e.g. from the
   management system, that the path is blocked, the end-point informs
   the far-end that the path has been locked and that no data should be
   transmitted.  This function is used on-demand.

3.5.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   Y.1731 does define a PDU and procedure for this functionality.

3.5.2.  Recommendations and Guidelines

   Define a tool to support Lock.  This tool could be designed around
   the procedure proposed by [Y.1731] that includes support for an
   indication of the frequency at which these messages are transmitted
   until the lock situation is cleared.

3.6.  Remote Defect Indication

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

   This function should be supported in pro-active mode.

3.6.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.  Similarly, when LSP Ping is used for a
   corouted bidirectional LSP the far-end LER could notify that there
   was a misconnectivity.

   In [Y.1731] this functionality is defined as part of the CC-V
   function as a flag in the PDU.

3.6.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.  Such an extension could be
   similar to that suggested by the ITU recommendation

Sprecher, et al.        Expires November 11, 2009              [Page 16]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

3.7.  Client Fail Indication

   Client Fail Indication (CFI) function is used to propagate an
   indication of a failure to the far-end sink when alarm suppression in
   the client layer is not supported.

3.7.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.7.2.  Recommendations and Guidelines

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

3.8.  Packet Loss

   Packet Loss is a function that is used to verify the quality of the
   service.  This function indicates the ratio of packets that are not
   delivered out of all packets that are transmitted by the path source.

   There are two possible ways of determining this measurement -

   o  Using OAM packets, it is possible to compute the statistics based
      on a series of OAM packets.  This, however, has the disadvantage
      of being artificial, and may not be representative since part of
      the packet loss may be dependent upon packet sizes.

   o  Sending delimiting messages for the start and end of a measurement
      period during which the source and sink of the path count the
      packets transmitted and received.  After the end delimiter, the
      ratio would be calculated by the path OAM entity.

3.8.1.  Existing tools

   There is no mechanism defined in the IETF to support this function.
   [Y.1731] describes a function that is based on sending the CCM
   packets [used for CC-V support (see sec 3.1)] for proactive support
   and specialized loss-measurement packets for on-demand measurement.
   These packets include information (in the additional TLV fields) of
   packet counters that are maintained by each of the end-points of a
   path.  These counters maintain a count of packets transmitted by the
   ingress end-point and the count of packets received from the far-end
   of the path by the egress end-point.

Sprecher, et al.        Expires November 11, 2009              [Page 17]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

3.8.2.  Recommendations and Guidelines

   One possibility is to define a mechanism to support Packet Loss
   Measurement, based on the delimiting messages.  This would include a
   way for delimiting the periods for monitoring the packet
   transmissions to measure the loss ratios, and computation of the
   ratio between received and transmitted packets.

   A second possibility would be to define a functionality based on the
   description of the loss-measurement function defined in [Y.1731] that
   is dependent on the counters maintained, by the MPLS LSR (as
   described in [RFC3813], of received and transmitted octets.

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

   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

   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.

   Similarly to the packet loss measurement this could be performed in
   one of two ways -

   o  Using OAM packets - checking delay (either one-way or two-way) in
      transmission of OAM packets.  May not fully reflect delay of
      larger packets, however, gives feedback on general service level.

   o  Using delimited periods of transmission - may be too intrusive on
      the client traffic.

3.9.1.  Existing tools

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

   [Y.1731] describes a function in which specific OAM packets are sent
   with a transmission time-stamp from one end of the managed path to
   the other end (these are transparent to the intermediate nodes).  The

Sprecher, et al.        Expires November 11, 2009              [Page 18]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   delay measurement is supported for both unidirectional and
   bidirectional measurement of the delay.

3.9.2.  Recommendations and Guidelines

   Define a mechanism that would allow to support Delay Measurement.
   The mechanism should be based on measurement of the delay in
   transmission and reception of OAM packets, transmitted in-band with
   normal traffic.  This tool could be based on the tool defined in

4.  Recommendations

   o  Define a maintenance entity that could be applied both to LSPs and
      PWs that would support management of a sub-path.  This entity
      should allow for transmission of traffic by means of label
      stacking and proper TTL setting.

   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  Extend the ACH to provide a control channel for MPLS-TP Links,
      LSPs, and Tandem Connections.

   o  Define a mechanism that would allow the unique addressing of the
      elements that need to be monitored, e.g., the connections, MEPs,
      and MIPs of a path.  This mechanism needs to be flexible enough to
      support different addressing schemes, e.g.  IP addresses, NSAP,
      connection names.

   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  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.  The
      tools could be based on the procedures and PDU format defined by
      [Y.1731] or extensions to existing MPLS tools:

      *  On-demand connectivity verification

Sprecher, et al.        Expires November 11, 2009              [Page 19]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

      *  Alarm suppression

      *  Packet loss measurement

      *  Diagnostic test

      *  Route determination

      *  Delay measurement

      *  Remote defect indication

      *  Client fail indication

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

5.  IANA Considerations

   This document makes no request of IANA.

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

6.  Security Considerations

   This document does not by itself raise any particular security

7.  Acknowledgements

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

8.  Informative References

   [ICMP]     Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, Sept 1981.

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

Sprecher, et al.        Expires November 11, 2009              [Page 20]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

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

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

              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 Reqs]
              Vigoureux, M., Betts, M., and D. Ward, "Requirements for
              OAM in MPLS Transport Networks",
              ID draft-ietf-mpls-tp-oam-requirements-01, April 2009.

   [MPLS-TP OAM Frwk]
              Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and
              Overview", ID draft-ietf-mpls-tp-oam-requirements-01,
              March 2009.

   [MPLS-TP Reqs]
              Nadeau, T. and C. Pignataro, "Requirements for the
              Trasport Profile of MPLS",
              ID draft-ietf-mpls-tp-requirements-06, April 2009.

   [RFC3813]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
              "Multiprotocol Label Switching (MPLS) Label Switching
              Router (LSR) Management  Information Base (MIB)",
              RFC 3813, June 2004.

Sprecher, et al.        Expires November 11, 2009              [Page 21]

Internet-Draft            MPLS-TP OAM Analysis                  May 2009

   [Y.1731]   International Telecommunications Union - Standardization,
              "OAM functions and mechanisms for Ethernet based
              networks", ITU Y.1731, May 2006.

Authors' Addresses

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

   Email: nurit.sprecher@nsn.com

   Tom Nadeau (editor)
   United States

   Email: tom.nadeau@bt.com

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

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

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

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

Sprecher, et al.        Expires November 11, 2009              [Page 22]

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