Internet DRAFT - draft-ietf-mpls-tp-oam-analysis

draft-ietf-mpls-tp-oam-analysis





Network Working Group                                        N. Sprecher
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                                   L. Fang
Expires: October 18, 2012                                          Cisco
                                                          April 17, 2012


   An Overview of the OAM Tool Set for  MPLS based Transport Networks
                 draft-ietf-mpls-tp-oam-analysis-09.txt

Abstract

   This document provides an overview of the OAM toolset for MPLS based
   Transport Networks (MPLS-TP).  The toolset consists of a comprehensive 
   set of fault management and performance monitoring capabilities 
   (operating in the data-plane) which are appropriate for transport 
   networks as required in RFC 5860 and support the network and services 
   at different nested levels.  This overview includes a brief recap of
   MPLS-TP OAM requirements and functions, and of generic mechanisms
   created in the MPLS data plane to allow the OAM packets run in-band
   and share their fate with data packets.  The protocol definitions for
   each of the MPLS-TP OAM tools are defined in separate documents (RFCs
   or Working Group drafts) which are referenced by this document.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on October 18, 2012.

Copyright Notice

   Copyright (c) 2012 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



Sprecher & Fang         Expires October 18, 2012               [Page 1]

Internet-Draft                OAM Tool Set                    April 2012


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.































Sprecher & Fang         Expires October 18, 2012               [Page 2]

Internet-Draft                OAM Tool Set                    April 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
     1.3.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Basic OAM Infrastructure Functionality . . . . . . . . . . . .  6
   3.  MPLS-TP OAM Functions  . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Continuity Check and Connectivity Verification . . . . . .  8
       3.1.1.  Documents for CC-CV tools  . . . . . . . . . . . . . .  9
     3.2.  Remote Defect Indication . . . . . . . . . . . . . . . . .  9
       3.2.1.  Documents for RDI  . . . . . . . . . . . . . . . . . .  9
     3.3.  Route Tracing  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1.  Documents for Route Tracing  . . . . . . . . . . . . . 10
     3.4.  Alarm Reporting  . . . . . . . . . . . . . . . . . . . . . 10
       3.4.1.  Documents for Alarm Reporting  . . . . . . . . . . . . 10
     3.5.  Lock Instruct  . . . . . . . . . . . . . . . . . . . . . . 10
       3.5.1.  Documents for Lock Instruct  . . . . . . . . . . . . . 10
     3.6.  Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10
       3.6.1.  Documents for Lock Reporting . . . . . . . . . . . . . 10
     3.7.  Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.7.1.  Documents for Diagnostic Testing . . . . . . . . . . . 11
     3.8.  Packet Loss Measurement  . . . . . . . . . . . . . . . . . 11
       3.8.1.  Documents for Packet Loss Measurement  . . . . . . . . 11
     3.9.  Packet Delay Measurement . . . . . . . . . . . . . . . . . 12
       3.9.1.  Documents for Delay Measurement  . . . . . . . . . . . 12
   4.  MPLS-TP OAM documents guide  . . . . . . . . . . . . . . . . . 12
   5.  OAM Toolset Applicability and Utilization  . . . . . . . . . . 14
     5.1.  Connectivity Check and Connectivity Verification . . . . . 14
     5.2.  Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15
     5.3.  Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 16
     5.4.  Alarm Reporting and Link Down Indication . . . . . . . . . 16
     5.5.  Remote Defect Indication . . . . . . . . . . . . . . . . . 17
     5.6.  Packet Loss and Delay Measurement  . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21










Sprecher & Fang         Expires October 18, 2012               [Page 3]

Internet-Draft                OAM Tool Set                    April 2012


1.  Introduction

1.1.  Scope

   The MPLS Transport Profile (MPLS-TP) architectural framework is
   defined in [RFC 5921], and it describes common set of protocol
   functions that supports the operational models and capabilities
   typical of such networks.

   OAM (Operations, Administration, and Maintenance) plays a significant
   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.

   [RFC 5654], in general, and [RFC 5860], in particular, define a set
   of requirements for OAM functionality for MPLS-Transport Profile
   (MPLS-TP)Label Switched Paths (LSPs) ), Pseudowires (PWs) and
   sections.

   The OAM solution, developed by the joint IETF and ITU-T MPLS-TP
   project, has three objectives:

   o  The OAM toolset should be developed based on existing MPLS
      architecture, technology, and toolsets.

   o  The OAM operational experience should be similar to that in other
      transport networks.

   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].

   The MPLS-TP OAM toolset is based on the following existing tools:

   o  LSP-Ping as defined in [RFC 4379].

   o  Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880]
      and refined in [RFC 5884].

   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
      been used for functionality guidelines for the performance
      measurement tools that were not previously supported in MPLS.

   It should be noted that certain extensions and adjustments have been
   specified relative to the existing MPLS tools, in order to conform to
   the transport environment and the requirements of MPLS-TP.  However,



Sprecher & Fang         Expires October 18, 2012               [Page 4]

Internet-Draft                OAM Tool Set                    April 2012


   compatibility with the existing tools has been maintained.

   This document provides an overview of the MPLS-TP OAM toolset, which
   consists of tools for MPLS-TP fault management and performance
   monitoring.  This overview includes a brief recap of MPLS-TP OAM
   requirements and functions, and of the generic mechanisms used to
   support the MPLS-TP OAM operation.

   The protocol definitions for each individual MPLS-TP OAM tool are
   specified in separate RFCs (or Working Group documents while this
   document is work in progress), which are referenced by this document.

   In addition, the document includes a table that cross-references the
   solution documents to the OAM functionality supported.  Finally, the
   document presents the applicability and utilization of each tool in
   the MPLS-TP OAM toolset.

1.2.  Contributing Authors

   Elisa Bellagamba   Ericsson
   Yaacov Weingarten  Nokia Siemens Networks
   Dan Frost          Cisco
   Nabil Bitar        Verizon
   Raymond Zhang      Alcatel Lucent
   Lei Wang           Telenor
   Kam Lee Yap        XO Communications
   John Drake         Juniper
   Yaakov Stein       RAD
   Anamaria Fulignoli Ericsson
   Italo Busi         Alcatel Lucent
   Huub van Helvoort  Huawei
   Thomas Nadeau      Computer Associate
   Henry Yu           TW Telecom
   Mach Chen          Huawei
   Manuel Paul        Deutsche Telekom
















Sprecher & Fang         Expires October 18, 2012               [Page 5]

Internet-Draft                OAM Tool Set                    April 2012


1.3.  Acronyms

   This document uses the following acronyms:

   ACH     Associated Channel Header
   AIS     Alarm Indication Signal
   BFD     Bidirectional Forwarding Detection
   CC-CV   Continuity Check and Connectivity Verification
   DM      Delay Measurement
   FM      Fault Management
   G-ACh   Generic Associated Channel
   GAL     G-ACh Label
   GMPLS   Generalized Multi-Protocol Label Switching
   IANA    Internet Assigned Names Authority
   LDI     Link Down Indication
   LKR     Lock Report
   LM      Loss Measurement
   LOC     Loss of Continuity
   LSP     Label Switched Path
   MEP     Maintenance Entity Group End Point
   MEG     Maintenance Entity Group
   MIP     Maintenance Entity Group Intermediate Point
   MPLS    MultiProtocol Label Switching
   MPLS-TP Transport Profile for MPLS
   OAM     Operations, Administration, and Maintenance
   PM      Performance Monitoring
   PW      Pseudowire
   RDI     Remote Defect Indication
   SLA     Service Level Agreement
   TLV     Type, Length, Value
   VCCV    Virtual Circuit Connectivity Verification


2.  Basic OAM Infrastructure Functionality

   [RFC 5860] defines a set of requirements on OAM architecture and
   general principles of operations, which are evaluated below:

   [RFC 5860] requires that --

   o  OAM mechanisms in MPLS-TP are independent of the transmission
      media and of the client service being emulated by the PW ([RFC
      5860], section 2.1.2).

   o  MPLS-TP OAM must be able to support both an IP based and non-IP
      based environment.  If the network is IP based, i.e.  IP routing
      and forwarding are available, then it must be possible to choose
      to make use of IP capabilities.  On the other hand, in



Sprecher & Fang         Expires October 18, 2012               [Page 6]

Internet-Draft                OAM Tool Set                    April 2012


      environments where IP functionality is not available, the OAM
      tools must still be able to operate independent of IP forwarding
      and routing ([RFC 5860], section 2.1.4).  It is required to have
      OAM interoperability between distinct domains materializing the
      environments ([RFC 5860], section 2.1.5).

   o  all OAM protocols support identification information, at least in
      the form of IP addressing structure and be extensible to support
      additional identification schemes ([RFC 5860], section 2.1.4).

   o  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 packets ([RFC 5860], section 2.1.3).
      Inherent in this requirement is the principle that full operation
      of the MPLS-TP OAM must be possible independently of the control
      or management plane used to operate the network ([RFC 5860],
      section 2.1.3).

   o  MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
      point co-routed bidirectional LSPs, point-to-point bidirectional
      Sections ([RFC 5860], section 2.1.1).  The applicability of
      particular MPLS-TP OAM functions to point-to-point associated
      bidirectional LSPs, point-to-point unidirectional LSPs, and point-
      to-multipoint LSPs, is described in ([RFC 5860], section 2.2)).
      In addition, MPLS-TP OAM supports these LSPs and PWs when they
      span either a single or multiple domains ([RFC 5860], section
      2.1.1).

   o  OAM packets may be directed to an intermediate point of a LSP/PW
      ([RFC 5860], sections 2.2.3, 2.2.4 and 2.2.5).

   [RFC 5860] recommends that any protocol solution, meeting one or more 
   functional requirement(s), be the same for PWs, LSPs, and Sections 
   (section 2.2).

   The following document-set addresses the basic requirements listed
   above:

   o  The [RFC 6371] document describes the architectural framework for
      conformance to the basic requirements listed above.  It also
      defines the basic relationships between the MPLS structures, e.g.
      LSP, PW, and the structures necessary for OAM functionality, i.e.
      the Managed Entity Group, its End-points, and Intermediate Points.

   o  The [RFC 5586] document specifies the use of the MPLS-TP in-band
      control channels.  It generalizes the applicability of the
      Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and
      Sections, by defining a Generic Associated Channel (G-ACh).  The



Sprecher & Fang         Expires October 18, 2012               [Page 7]

Internet-Draft                OAM Tool Set                    April 2012


      G-ACh allows control packets to be multiplexed transparently over
      LSPs and sections, similar to that of PW VCCV [RFC 5085].  The
      Generic Association Label (GAL) is defined by assigning a reserved
      MPLS label value and is used to identify the OAM control packets.
      The value of the ACH Channel Type field indicates the specific
      protocol carried on the associated control channel.  Each MPLS-TP
      OAM protocol has an IANA assigned channel type allocated to it.

      [RFC 5085] defines an Associated Channel Header (ACH) which
      provides a PW associated control channel between a PW's endpoints,
      over which OAM and other control messages can be exchanged.  [RFC
      5586] generalizes MPLS-TP generalized the PW Associated Channel
      Header (ACH) to provide common in-band control channels also at
      the LSP and MPLS-TP link levels.  The G-ACh allows control packets
      to be multiplexed transparently over the same LSP or MPLS-TP link
      as in PW VCCV.  Multiple control channels can exist between end
      points.

      [RFC 5085] also defines a label-based exception mechanism that
      helps an LSR to identify the control packets and direct them to
      the appropriate entity for processing.  The use of G-ACh and GAL
      provides the necessary mechanisms to allow OAM packets run in-band
      and share their fate with data packets.  It is expected that all
      of the OAM protocols will be used in conjunction with this Generic
      Associated Channel.

   o  The [RFC 6370] document provides an IP-based identifier set for
      MPLS-TP that can be used to identify the transport entities in the
      network and referenced by the different OAM protocols. 
	  [MPLS TP ITU Idents] augments that set of identifiers to include 
	  identifier information in a format used by the ITU-T.  Other 
	  identifier sets may be defined as well.


3.  MPLS-TP OAM Functions

   The following sections discuss the OAM functions that are required in
   [RFC 5860] and expanded upon in [RFC 6371].

3.1.  Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification (CC-CV) are OAM
   operations generally used in tandem, and complement each other.
   These functions are generally run proactively, but may also be used
   on-demand for diagnoses of a specific condition.  Proactively [RFC
   5860] states that the function should allow the MEPs to monitor the
   liveliness and connectivity of a transport path (LSP, PW or a
   section) between them.  In on-demand mode, this function should



Sprecher & Fang         Expires October 18, 2012               [Page 8]

Internet-Draft                OAM Tool Set                    April 2012


   support monitoring between the MEPs and, in addition, between a MEP
   and MIP.  Note that as specified in sections 3.3 and 3.4 of [RFC
   6371], a MEP and a MIP can reside in an unspecified location within a
   node, or in a particular interface on a specific side of the
   forwarding engine.

   The [RFC 6371] highlights the need for the CC-CV messages to include
   unique identification of the MEG that is being monitored and the MEP
   that originated the message.  The function, both proactively and in
   on-demand mode, needs to be transmitted at regular transmission rates
   pre-configured by the operator.

3.1.1.  Documents for CC-CV tools

   [RFC 6428] defines BFD extensions to support proactive CC-CV
   applications.

   [RFC 6426] provides LSP-Ping extensions that are used to implement
   on-demand Connectivity Verification.

   Both of these tools will be used within the framework of the basic
   tools described above, in section 2.

3.2.  Remote Defect Indication

   Remote Defect Indication (RDI) is used by a path end-point to report
   that a defect is detected on a bi-directional connection to its peer
   end-point.  [RFC 5860] points out that this function may be applied
   to a unidirectional LSP only if a return path exists.  [RFC 6371]
   points out that this function is associated with the proactive CC-CV
   function.

3.2.1.  Documents for RDI

   The [RFC 6428] document includes an extension for BFD that would
   include the RDI indication in the BFD format, and a specification of
   how this indication is to be used.

3.3.  Route Tracing

   [RFC 5860] defines that there is a need for functionality that would
   allow a path end-point to identify the intermediate (if any) and end-
   points of the path (LSP, PW or a section).  This function would be
   used in on-demand mode.  Normally, this path will be used for
   bidirectional PW, LSP, and sections, however, unidirectional paths
   may be supported only if a return path exists.





Sprecher & Fang         Expires October 18, 2012               [Page 9]

Internet-Draft                OAM Tool Set                    April 2012


3.3.1.  Documents for Route Tracing

   The [RFC 6426] document that specifies the LSP-Ping enhancements for
   MPLS-TP on-demand Connectivity Verification includes information on
   the use of LSP-Ping for route tracing of a MPLS-TP transport path.

3.4.  Alarm Reporting

   Alarm Reporting is a function used by an intermediate point of a path
   (LSP or PW), that becomes aware of a fault on the path, to report to
   the end-points of the path.  [RFC 6371] states that this may occur as
   a result of a defect condition discovered at a server layer.  The
   intermediate point generates an Alarm Indication Signal (AIS) that
   continues until the fault is cleared.  The consequent action of this
   function is detailed in [RFC 6371].

3.4.1.  Documents for Alarm Reporting

   MPLS-TP defines a new protocol to address this functionality that is
   documented in [RFC 6427].  This protocol uses all of the basic
   mechanisms detailed in Section 2.

3.5.  Lock Instruct

   The Lock Instruct function is an administrative control tool that
   allows a path end-point to instruct its peer end-point to lock the
   path (LSP, PW or section).  The tool is necessary to support single-
   side provisioning for administrative locking, according to [RFC
   6371].  This function is used on-demand.

3.5.1.  Documents for Lock Instruct

   The [RFC 6435] document describes the details of a new ACH based
   protocol format for this functionality.

3.6.  Lock Reporting

   Lock reporting, defined in [RFC 5860], is similar to the Alarm
   Reporting function described above.  It is used by an intermediate
   point to notify the end points of a transport path (LSP or PW) that
   an administrative lock condition exists for this transport path.

3.6.1.  Documents for Lock Reporting

   MPLS-TP defines a new protocol to address this functionality that is
   documented in [RFC 6427].  This protocol uses all of the basic
   mechanisms detailed in Section 2.




Sprecher & Fang         Expires October 18, 2012              [Page 10]

Internet-Draft                OAM Tool Set                    April 2012


3.7.  Diagnostic

   The [RFC 5860] indicates that there is need to provide a OAM function
   that would enable conducting different diagnostic tests on a PW, LSP,
   or Section.  The [RFC 6371] provides two types of specific tests to
   be used through this functionality:

   o  Throughput Estimation - allowing the provider to verify the
      bandwidth/throughput of a transport path.  This is an out-of-
      service tool, that uses special packets of varying sizes to test
      the actual bandwidth and/or throughput of the path.

   o  Data-plane loopback - this out-of-service tool causes all traffic
      that reaches the target node, either a MEP or MIP, to be looped
      back to the originating MEP.  For targeting MIPs, a co-routed bi-
      directional path is required.

3.7.1.  Documents for Diagnostic Testing

   The [RFC 6435] document describes the details of a new ACH based
   protocol format for the Data-plane loopback functionality.

   The tool for Throughput Estimation tool is under study.

3.8.  Packet Loss Measurement

   Packet Loss Measurement is required by [RFC 5860] to provide a
   quantification of the packet loss ratio on a transport path.  This is
   the ratio of the number of user packets lost to the total number of
   user packets during a defined time interval.  To employ this
   function, [RFC 6371] defines that the two end-points of the transport
   path should exchange counters of messages transmitted and received
   within a time period bounded by loss-measurement messages.  The
   framework warns that there may be small errors in the computation
   that result from various issues.

3.8.1.  Documents for Packet Loss Measurement

   The [RFC 6374] document describes the protocol formats and procedures
   for using the tool and enable efficient and accurate measurement of
   packet loss, delay, and throughput in MPLS networks.  [RFC 6375]
   describes a profile of the general MPLS loss, delay, and throughput
   measurement techniques that suffices to meet the specific
   requirements of MPLS-TP.  Note that the tool logic is based on the
   behavior of the parallel function described in [Y.1731].






Sprecher & Fang         Expires October 18, 2012              [Page 11]

Internet-Draft                OAM Tool Set                    April 2012


3.9.  Packet Delay Measurement

   Packet Delay Measurement is a function that is used to measure one-
   way or two-way delay of a packet transmission between a pair of the
   end-points of a path (PW, LSP, or Section), as described in [RFC
   5860].  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 last 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.

   [RFC 6371] describes how the tool could be performed (both in
   proactive and on-demand modes) for either one-way or two-way
   measurement.  However, it warns that the one-way delay option
   requires precise time synchronization between the end-points.

3.9.1.  Documents for Delay Measurement

   The [RFC 6374] document describes the protocol formats and procedures
   for using the tool and enable efficient and accurate measurement of
   packet loss, delay, and throughput in MPLS networks.  [RFC 6375]
   describes a profile of the general MPLS loss, delay, and throughput
   measurement techniques that suffices to meet the specific
   requirements of MPLS-TP.  Note that the tool logic is based on the
   behavior of the parallel function described in [Y.1731].


4.  MPLS-TP OAM documents guide

   The complete MPLS-TP OAM protocol suite is covered by a small set of
   existing IETF documents.  This set of documents may be expanded in
   the future to cover additional OAM functionality.  In order to allow
   the reader to understand this set of documents, a cross-reference of
   the existing documents (IETF RFCs or Internet drafts while this
   document is work in progress) for the initial phase of the
   specification of MPLS based transport networks is provided below.

   [RFC 5586] provides a specification of the basic structure of
   protocol messages for in-band data plane OAM in an MPLS environment.

   [RFC 6370] provides definitions of different formats that may be used



Sprecher & Fang         Expires October 18, 2012              [Page 12]

Internet-Draft                OAM Tool Set                    April 2012


   within OAM protocol messages to identify the network elements of a
   MPLS based transport network.

   The following table (Table 1) provides the summary of proactive
   MPLS-TP OAM Fault Management toolset functions, associated tool/
   protocol, and the corresponding IETF RFCs where they are defined.

   +--------------------------+-------------------------------+--------+
   | OAM Functions            | OAM Tools/Protocols           | RFCs   |
   +--------------------------+-------------------------------+--------+
   | Continuity Check and     | Bidirectional Forwarding      | [RFC   |
   | Connectivity             | Detection (BFD)               | 6428]  |
   | Verification             |                               |        |
   +--------------------------+-------------------------------+--------+
   | Remote Defect Indication | Flag in Bidirectional         | [RFC   |
   | (RDI)                    | Forwarding Detection (BFD)    | 6428]  |
   |                          | message                       |        |
   +--------------------------+-------------------------------+--------+
   | Alarm Indication Signal  | G-ACh bases AIS message       | [RFC   |
   | (AIS)                    |                               | 6427]  |
   +--------------------------+-------------------------------+--------+
   | Link Down Indication     | Flag in AIS message           | [RFC   |
   | (LDI)                    |                               | 6427]  |
   +--------------------------+-------------------------------+--------+
   | Lock Reporting (LKR)     | G-ACh bases LKR message       | [RFC   |
   |                          |                               | 6427]  |
   +--------------------------+-------------------------------+--------+

                  Proactive Fault Management OAM Toolset

                                  Table 1

   The following table (Table 2) provides an overview of the on-demand
   MPLS-TP OAM Fault Management toolset functions, associated tool/
   protocol, and the corresponding IETF RFCs they are defined.

   +------------------------+---------------------------------+--------+
   | OAM Functions          | OAM Tools/Protocols             | RFCs   |
   +------------------------+---------------------------------+--------+
   | Connectivity           | LSP Ping                        | [RFC   |
   | Verification           |                                 | 6426]  |
   +------------------------+---------------------------------+--------+
   | Diagnostic: Loopback   | (1) G-ACh based Loopback and    | [RFC   |
   | and Lock Instruct      | Lock Instruct, (2) LSP Ping     | 6435]  |
   +------------------------+---------------------------------+--------+





Sprecher & Fang         Expires October 18, 2012              [Page 13]

Internet-Draft                OAM Tool Set                    April 2012


   +------------------------+---------------------------------+--------+
   | Lock Instruct(LI)      | Flag in AIS message             | [RFC   |
   |                        |                                 | 6427]  |
   +------------------------+---------------------------------+--------+

                  On Demand Fault Management OAM Toolset

                                  Table 2

   The following table (Table 3) provides the Performance Monitoring
   Fuctions, asscociated tool/protocol definitions, and corresponding
   RFCs.

   +----------------------+--------------------------+-----------------+
   | OAM Functions        | OAM Tools/Protocols      | RFCs            |
   +----------------------+--------------------------+-----------------+
   | Packet Loss          | G-ACh based LM & DM      | [RFC 6374] [RFC |
   | Measurement (LM)     | query messages           | 6375]           |
   +----------------------+--------------------------+-----------------+
   | Packet Delay         | G-ACh based LM & DM      | [RFC 6374] [RFC |
   | Measurement (DM)     | query messages           | 6375]           |
   +----------------------+--------------------------+-----------------+
   | Throughput           | derived from Loss        | [RFC 6374] [RFC |
   | Measurement          | Measurement              | 6375]           |
   +----------------------+--------------------------+-----------------+
   | Delay Variation      | derived from Delay       | [RFC 6374] [RFC |
   | Measurement          | Measurement              | 6375]           |
   +----------------------+--------------------------+-----------------+

                    Performance Monitoring OAM Toolset

                                  Table 3


5.  OAM Toolset Applicability and Utilization

   The following subsections present the MPLS-TP OAM toolset from the
   perspective of the specified protocols and identifies which of the
   required functionality is supported by the particular protocol.

5.1.  Connectivity Check and Connectivity Verification

   Proactive Continuity Check and Connectivity Verification (CC-CV)
   functions are used to detect loss of continuity (LOC), and unintended
   connectivity between two MEPs.  Loss of connectivity, mis-merging,
   mis-connectivity, or unexpected Maintenance Entity Group End Points
   (MEPs) can be detected using the CC-CV tools.  See Section 3.1, 3.2,
   3.3 in this document for CC-CV protocol references.



Sprecher & Fang         Expires October 18, 2012              [Page 14]

Internet-Draft                OAM Tool Set                    April 2012


   The CC-CV tools are used to support MPLS-TP fault management,
   performance management, and protection switching.  Proactive CC-CV
   control packets are sent by the source MEP to sink MEP.  The sink MEP
   monitors the arrival of the CC-CV control packets and detects the
   defect.  For bidirectional transport paths, the CC-CV protocol is,
   usually, transmitted simultaneously in both directions.

   The transmission interval of CC-CV control packet can be configured.
   For example:

   o  3.3ms is the default interval for protection switching.

   o  100ms is the default interval for performance monitoring.

   o  1s is the default interval for fault management.

5.2.  Diagnostic Tests and Lock Instruct

   [RFC 6435] describes a protocol that provides a mechanism is provided
   to Lock and unlock traffic (e.g. data and control traffic) or
   specific OAM traffic at a specific LSR on the path of the MPLS-TP LSP
   to allow loop back of the traffic to the source.

   These diagnostic functions apply to associated bidirectional MPLS-TP
   LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which
   is relevant for MPLS-TP dynamic control plane option with GMPLS), and
   single segment and multi-segment pseudowires.  [RFC 6435] provides
   the protocol definition for diagnostic tests functions.

   The Lock operation instruction is carried in an MPLS Loopback request
   message sent from a MEP to a trail-end MEP of the LSP to request that
   the LSP be taken out of service.  In response, the Lock operation
   reply is carried in a Loopback response message sent from the trail-
   end MEP back to the originating MEP to report the result.

   The loopback operations include:

   o  Lock: take an LSP out of service for maintenance.

   o  Unlock: Restore a previously locked LSP to service.

   o  Set_Full_Loopback and Set_OAM_Loopback

   o  Unset_Full_Loopback and Set_OAM_Loopback

   Operators can use the loopback mode to test the connectivity or
   performance (loss, delay, delay variation, and throughput) of given
   LSP up to a specific node on the path of the LSP.



Sprecher & Fang         Expires October 18, 2012              [Page 15]

Internet-Draft                OAM Tool Set                    April 2012


5.3.  Lock Reporting

   The Lock Report (LKR) function is used to communicate to the client
   (sub-) layer MEPs the administrative locking of a server (sub-) layer
   MEP, and consequential interruption of data traffic forwarding in the
   client (sub-) layer.  See Section 3.6 in this document for Lock
   Reporting protocol references.

   When operator is taking the LSP out of service for maintenance or
   other operational reason, using the LKR function can help to
   distinguish the condition as administrative locking from defect
   condition.

   The Lock Report function would also serve the purpose of alarm
   suppression in the MPLS-TP network above the level at which the Lock
   has occurred.  The receipt of an LKR message may be treated as the
   equivalent of loss of continuity at the client layer.

5.4.  Alarm Reporting and Link Down Indication

   Alarm Indication Signal (AIS) message serves the purpose of alarm
   suppression upon the failure detection in the server (-sub) layer.
   When the Link Down Indication (RDI) is set, the AIS message may be
   used to trigger recovery mechanisms.

   When a server MEP detects the failure, it asserts Loss of Continuity
   (LOC) or signal fail which sets the flag up to generate OAM packet
   with AIS message.  The AIS message is forwarded to downstream sink
   MEP in the client layer.  This would enable the client layer to
   suppress the generation of secondary alarms.

   A Link Down Indication (LDI) flag is defined in the AIS message.  The
   LDI flag is set in the AIS message in response to detecting a fatal
   failure in the server layer.  Receipt of an AIS message with this
   flag set may be interpreted by a MEP as an indication of signal fail
   at the client layer.

   The protocols for Alarm Indication Signal (AIS) and Link Down
   Indication (LDI) are defined in [RFC 6427].

   Fault OAM messages are generated by intermediate nodes where an LSP
   is switched, and propagated to the end points (MEPs).

   From a practical point of view, when both proactive Continuity Check
   functions and LDI are used, one may consider running the proactive
   Continuity Check functions at a slower rate (e.g. longer BFD hello
   intervals), and reply on LDI to trigger fast protection switch over
   upon failure detection in a given LSP.



Sprecher & Fang         Expires October 18, 2012              [Page 16]

Internet-Draft                OAM Tool Set                    April 2012


5.5.  Remote Defect Indication

   Remote Defect Indication (RDI) function enables an End Point to
   report to the other End Point that a fault or defect condition is
   detected on the PW, LSP, or Section for which they are the End
   Points.

   The RDI OAM function is supported by the use of Bidirectional
   Forwarding Detection (BFD) Control Packets [RFC 6428].  RDI is only
   used for bidirectional connections and is associated with proactive
   CC-CV activation.

   When an end point (MEP) detects a signal failure condition, it sets
   the flag up by setting the diagnostic field of the BFD control packet
   to a particular value to indicate the failure condition on the
   associated PW, LSP, or Section, and transmitting the BFD control
   packet with the failure flag up to the other end point (its peer
   MEP).

   The RDI function can be used to facilitate protection switching by
   synchronizing the two end points when unidirectional failure occurs
   and is detected by one end.

5.6.  Packet Loss and Delay Measurement

   The packet loss and delay measurement toolset enables operators to
   measure the quality of the packet transmission over a PW, LSP, or
   Section.  Section 3.8 in this document defined the protocols for
   packet loss measurement and 3.9 in defined the protocols for packet
   delay measurement.

   The loss and delay protocols have the following characteristics and
   capabilities:

   o  They support measurement of packet loss, delay and throughput over
      Label Switched Paths (LSPs), pseudowires, and MPLS sections.

   o  The same LM and DM protocols can be used for both continuous/
      proactive and selective/on-demand measurement.

   o  The LM and DM protocols use a simple query/response model for
      bidirectional measurement that allows a single node - the querier
      - to measure the loss or delay in both directions.

   o  The LM and DM protocols use query messages for unidirectional loss
      and delay measurement.  The measurement can either be carried out
      at the downstream node(s) or at the querier if an out-of-band
      return path is available.



Sprecher & Fang         Expires October 18, 2012              [Page 17]

Internet-Draft                OAM Tool Set                    April 2012


   o  The LM and DM protocols do not require that the transmit and
      receive interfaces be the same when performing bidirectional
      measurement.

   o  The LM supports test-message-based measurement (i.e. inferred
      mode) as well as measurement based on data-plane counters (i.e.
      direct mode).

   o  The LM protocol supports both 32-bit and 64-bit counters.

   o  The LM protocol supports measurement in terms of both packet
      counts and octet counts although for simplicity only packet
      counters are currently included in the MPLS-TP profile.

   o  The LM protocol can be used to measure channel throughput as well
      as packet loss.

   o  The DM protocol supports varying the measurement message size in
      order to measure delays associated with different packet sizes.

   o  The DM protocol uses IEEE 1588 timestamps by default but also
      supports other timestamp formats such as NTP.


6.  IANA Considerations

   This document makes no request of IANA.

   The OAM tools and functions defined under G-ACh use IANA assigned
   code points. the codes are defined in the corresponding IETF RFCs

Note to RFC Editor:

   this section may be removed on publication as an RFC.


7.  Security Considerations

   This document as an overview of MPLS OAM tools does not by itself
   raise any particular security considerations.

   The general security considerations are provided in [RFC 6920] and
   [MPLS-TP Security Frwk].  Security considerations for each function
   in the OAM toolset have been documented in each document that
   specifies the particular functionality.

   OAM in general is always an area where the security risk is high,
   e.g. confidential information may be intercepted for attackers to



Sprecher & Fang         Expires October 18, 2012              [Page 18]

Internet-Draft                OAM Tool Set                    April 2012


   again access to the networks, therefore authentication,
   authorization, and encryption need to be enforced for prevent
   security breach.

   In addition to implement security protocol, tools, and mechanisms,
   following strict operation security procedures is very important,
   especially MPSL-TP static provisioning processes involve operator
   direct interactions with NMS and devices, its critical to prevent
   human errors and malicious attacks.

   Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
   described in [RFC 5085] apply here.  In short, the G-ACh could be
   intercepted, or false G-ACh packets could be inserted.  DoS attack
   could happen by flooding G-ACh messages to peer devices.  To mitigate
   this type of attacks, throttling mechanisms can be used.  For more
   details, please see [RFC 5085].


8.  Acknowledgements

   The authors would like to thank the MPLS-TP experts from both the
   IETF and ITU-T for their helpful comments. In particular, we would
   like to thank Loa Andersson, and the Area Directors for their 
   suggestions and enhancements to the text.

   Thanks to Tom Petch for useful comments and discussions.
   
   Thanks to Rui Costa for his review and comments which helped improve
   this doecument. 


9.  References

9.1.  Normative References

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

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




Sprecher & Fang         Expires October 18, 2012              [Page 19]

Internet-Draft                OAM Tool Set                    April 2012


   [RFC 5586]
              Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [RFC 5654]
              Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
              "Requirements for the Transport Profile of MPLS",
              RFC 5654, April 2009.

   [RFC 5860]
              Vigoureux, M., Betts, M., and D. Ward, "Requirements for
              OAM in MPLS Transport Networks", RFC 5860, April 2009.

   [RFC 5880]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", RFC 5880, February 2009.

   [RFC 5884]
              Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "BFD For MPLS LSPs", RFC 5884, June 2008.

   [RFC 5921]
              Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
              Berger, "A Framework for MPLS in Transport Networks",
              RFC 5921, July 2010.

   [RFC 6370]
              Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
              Identifiers", RFC 6370, September 2011.

   [RFC 6371]
              Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM
              Framework and Overview", RFC 6371, September 2011.

   [RFC 6374]
              Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

   [RFC 6375]
              Frost, D. and S. Bryant, "A Packet Loss and Delay
              Measurement Profile for MPLS-based  Transport Networks",
              RFC 6375, September 2011.

   [RFC 6426]
              Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS
              on-demand Connectivity Verification, Route Tracing and
              Adjacency Verification", RFC 6426, August 2011.




Sprecher & Fang         Expires October 18, 2012              [Page 20]

Internet-Draft                OAM Tool Set                    April 2012


   [RFC 6427]
              Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault
              Management OAM", RFC 6427, September 2011.

   [RFC 6428]
              Allan, D. and G. Swallow, "Proactive Connectivity
              Verification, Continuity Check and Remote Defect
              indication for MPLS Transport Profile", RFC 6428,
              August 2011.

   [RFC 6435]
              Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
              and X. Dai, "MPLS Transport Profile Lock Instruct and
              Loopback Functions", RFC 6435, September 2011.

9.2.  Informative References

   [MPLS-TP Security Frwk]
              Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
              Security Framework",
              ID draft-ietf-mpls-tp-security-framework-02, May 2011.

   [RFC 6920]
              Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

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

   [MPLS TP ITU Idents]
              Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
              Identifiers Following ITU-T Conventions",
              ID draft-ietf-mpls-tp-itu-t-identifiers-02, July 2011.


Authors' Addresses

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

   Email: nurit.sprecher@nsn.com






Sprecher & Fang         Expires October 18, 2012              [Page 21]

Internet-Draft                OAM Tool Set                    April 2012


   Luyuan Fang
   Cisco
   111 Wood Avenue South
   Iselin, NJ  08830
   USA

   Email: lufang@cisco.com












































Sprecher & Fang         Expires October 18, 2012              [Page 22]