doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc6669.txt b/doc/rfc/rfc6669.txt
new file mode 100644
index 0000000..e00816b
--- /dev/null
+++ b/doc/rfc/rfc6669.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       N. Sprecher
+Request for Comments: 6669                        Nokia Siemens Networks
+Category: Informational                                          L. Fang
+ISSN: 2070-1721                                            Cisco Systems
+                                                               July 2012
+
+
+  An Overview of the Operations, Administration, and Maintenance (OAM)
+               Toolset for MPLS-Based Transport Networks
+
+Abstract
+
+   This document provides an overview of the Operations, Administration,
+   and Maintenance (OAM) toolset for MPLS-based transport networks.  The
+   toolset consists of a comprehensive set of fault management and
+   performance monitoring capabilities (operating in the data plane)
+   that 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 the MPLS Transport Profile
+   (MPLS-TP) OAM requirements and functions and the generic mechanisms
+   created in the MPLS data plane that allow the OAM packets to 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 documents), which are referenced by
+   this document.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any
+   errata, and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6669.
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 1]
+
+RFC 6669                       OAM Toolset                     July 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
+   (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               Informational                     [Page 2]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Scope ......................................................4
+      1.2. Acronyms ...................................................5
+   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 ...........................8
+      3.2. Remote Defect Indication ...................................8
+           3.2.1. Documents for RDI ...................................9
+      3.3. Route Tracing ..............................................9
+           3.3.1. Documents for Route Tracing .........................9
+      3.4. Alarm Reporting ............................................9
+           3.4.1. Documents for Alarm Reporting .......................9
+      3.5. Lock Instruct ..............................................9
+           3.5.1. Documents for Lock Instruct ........................10
+      3.6. Lock Reporting ............................................10
+           3.6.1. Documents for Lock Reporting .......................10
+      3.7. Diagnostic ................................................10
+           3.7.1. Documents for Diagnostic Testing ...................10
+      3.8. Packet Loss Measurement ...................................10
+           3.8.1. Documents for Packet Loss Measurement ..............11
+      3.9. Packet Delay Measurement ..................................11
+           3.9.1. Documents for Delay Measurement ....................11
+   4. MPLS-TP OAM Documents Guide ....................................12
+   5. OAM Toolset Applicability and Utilization ......................13
+      5.1. Connectivity Check and Connectivity Verification ..........14
+      5.2. Diagnostic Tests and Lock Instruct ........................14
+      5.3. Lock Reporting ............................................15
+      5.4. Alarm Reporting and Link Down Indication ..................15
+      5.5. Remote Defect Indication ..................................16
+      5.6. Packet Loss and Delay Measurement .........................17
+   6. Security Considerations ........................................18
+   7. Acknowledgements ...............................................18
+   8. References .....................................................19
+      8.1. Normative References ......................................19
+      8.2. Informative References ....................................20
+   Contributors ......................................................21
+
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 3]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+1.  Introduction
+
+1.1.  Scope
+
+   The MPLS Transport Profile (MPLS-TP) architectural framework is
+   defined in [RFC5921], and it describes a common set of protocol
+   functions that supports the operational models and capabilities
+   typical of such transport networks.
+
+   Operations, Administration, and Maintenance (OAM) plays a significant
+   role in carrier networks.  It provides methods for fault management
+   and performance monitoring in both the transport and service layers,
+   in order to improve their ability to support services with guaranteed
+   and strict Service Level Agreements (SLAs) while reducing their
+   operational costs.
+
+   [RFC5654], in general, and [RFC5860], in particular, define a set of
+   requirements for the OAM functionality for 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 interoperable with existing MPLS OAM tools as
+      documented in Section 2.1.5. of [RFC5860].
+
+   The MPLS-TP OAM toolset is based on the following existing tools:
+
+   o  LSP ping, as defined in [RFC4379].
+
+   o  Bidirectional Forwarding Detection (BFD), as defined in [RFC5880]
+      and refined in [RFC5884].
+
+   o  ITU-T OAM for the Ethernet toolset, as defined in [Y.1731].  This
+      has been used as functionality guidelines for the performance
+      measurement tools that were not previously supported in MPLS.
+
+   Note 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,
+   compatibility with the existing MPLS tools has been maintained.
+
+
+
+Sprecher & Fang               Informational                     [Page 4]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   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, their functions, and the generic mechanisms used to
+   support the MPLS-TP OAM operation.
+
+   The protocol definitions for individual MPLS-TP OAM tools are
+   specified in separate RFCs (or Working Group documents), which are
+   referenced by this document.
+
+   In addition, this document includes a table that cross-references the
+   solution documents of the OAM functionality supported.  Finally, the
+   document presents the applicability and utilization of each tool in
+   the MPLS-TP OAM toolset.
+
+1.2.  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 Multiprotocol Label Switching
+   IANA    Internet Assigned Numbers 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
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 5]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+2.  Basic OAM Infrastructure Functionality
+
+   [RFC5860] defines a set of requirements for OAM architecture and
+   general principles of operations, which are evaluated below:
+
+   [RFC5860] requires that --
+
+   o  OAM mechanisms in MPLS-TP are independent of the transmission
+      media and the client service being emulated by the PW ([RFC5860],
+      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
+      environments where IP functionality is not available, the OAM
+      tools must still be able to operate independent of IP forwarding
+      and routing ([RFC5860], Section 2.1.4).  It is required to have
+      OAM interoperability between distinct domains materializing the
+      environments ([RFC5860], Section 2.1.5).
+
+   o  All OAM protocols support identification information, at least in
+      the form of IP addressing structure, and are extensible to support
+      additional identification schemes ([RFC5860], 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 [RFC5860], 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 [RFC5860], Section
+      2.1.3.
+
+   o  MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
+      point co-routed bidirectional LSPs, and point-to-point
+      bidirectional Sections ([RFC5860], 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 [RFC5860],
+      Section 2.2.  In addition, MPLS-TP OAM supports these LSPs and PWs
+      when they span either single or multiple domains ([RFC5860],
+      Section 2.1.1).
+
+   o  OAM packets may be directed to an intermediate point of an LSP/PW
+      ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5).
+
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 6]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   [RFC5860], Section 2.2 recommends that any protocol solution meeting
+   one or more functional requirement(s) be the same for PWs, LSPs, and
+   Sections.
+
+   The following document set addresses the basic requirements listed
+   above:
+
+   o  [RFC6371] 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 Maintenance
+      Entity Group (MEG), its end points, and intermediate points.
+
+   o  [RFC5586] specifies the use of the MPLS-TP in-band control
+      channels.  It generalizes the applicability of the PW ACH to MPLS
+      LSPs and Sections by defining a Generic Associated Channel
+      (G-ACh).  The G-ACh allows control packets to be multiplexed
+      transparently over LSPs and Sections similar to that of PW VCCV
+      [RFC5085].  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.
+
+   [RFC5085] defines an Associated Channel Header (ACH) that provides a
+   PW associated control channel between a PW's end points, over which
+   OAM and other control messages can be exchanged.  [RFC5586]
+   generalizes 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.
+
+   [RFC5085] also defines a label-based exception mechanism that helps a
+   Label Switching Router (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
+   to 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  [RFC6370] 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.
+
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 7]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+         Note: [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
+   [RFC5860] and expanded upon in [RFC6371].
+
+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.  [RFC5860] states
+   that the function should allow the MEPs to proactively monitor the
+   liveliness and connectivity of a transport path (LSP, PW, or a
+   Section) between them.  In on-demand mode, this function should
+   support monitoring between the MEPs and between a MEP and MIP.  Note
+   that as specified in [RFC6371], Sections 3.3 and 3.4, 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.
+
+   [RFC6371] 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
+
+   [RFC6428] defines BFD extensions to support proactive CC-CV
+   applications.
+
+   [RFC6426] provides LSP ping extensions that are used to implement
+   on-demand connectivity verification.
+
+   Both of these tools will be used within the basic functionality
+   framework described 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 bidirectional connection to its peer
+   end point.  [RFC5860] points out that this function may be applied to
+   a unidirectional LSP only if a return path exists.  [RFC6371] points
+   out that this function is associated with the proactive CC-CV
+   function.
+
+
+
+Sprecher & Fang               Informational                     [Page 8]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+3.2.1.  Documents for RDI
+
+   [RFC6428] provides an extension for BFD that includes the RDI
+   indication in the BFD format and a specification of how this
+   indication is to be used.
+
+3.3.  Route Tracing
+
+   [RFC5860] defines the need for functionality that would allow a path
+   end point to identify the intermediate points (if any) and end
+   point(s) along 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.
+
+3.3.1.  Documents for Route Tracing
+
+   [RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-
+   demand connectivity verification include information on the use of
+   LSP ping for route tracing of an MPLS-TP path.
+
+3.4.  Alarm Reporting
+
+   Alarm Reporting is a function used by an intermediate point of a path
+   (LSP or PW) to report to the end points of the path that a fault
+   exists on the path.  [RFC6371] 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 [RFC6371].
+
+3.4.1.  Documents for Alarm Reporting
+
+   MPLS-TP defines a new protocol to address this functionality that is
+   documented in [RFC6427].  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 [RFC6371].
+   This function is used on-demand.
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                     [Page 9]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+3.5.1.  Documents for Lock Instruct
+
+   [RFC6435] describes the details of a new ACH-based protocol format
+   for this functionality.
+
+3.6.  Lock Reporting
+
+   Lock Reporting, defined in [RFC5860], 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 the transport path.
+
+3.6.1.  Documents for Lock Reporting
+
+   MPLS-TP defines a new protocol to address this functionality that is
+   documented in [RFC6427].  This protocol uses all the basic mechanisms
+   detailed in Section 2.
+
+3.7.  Diagnostic
+
+   [RFC5860] indicates a need to provide an OAM function that would
+   enable conducting different diagnostic tests on a PW, LSP, or
+   Section.  [RFC6371] 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
+      bidirectional path is required.
+
+3.7.1.  Documents for Diagnostic Testing
+
+   [RFC6435] describes the details of a new ACH-based protocol format
+   for the data-plane loopback functionality.
+
+   The tool for throughput estimation is under study.
+
+3.8.  Packet Loss Measurement
+
+   Packet Loss Measurement is required by [RFC5860] 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
+
+
+
+Sprecher & Fang               Informational                    [Page 10]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   function, [RFC6371] 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,
+   which result from various issues.
+
+3.8.1.  Documents for Packet Loss Measurement
+
+   [RFC6374] describes the protocol formats and procedures for using the
+   tool and enabling efficient and accurate measurement of packet loss,
+   delay, and throughput in MPLS networks.  [RFC6375] describes a
+   profile of the general MPLS loss, delay, and throughput measurement
+   techniques that suffice 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].
+
+3.9.  Packet Delay Measurement
+
+   Packet Delay Measurement is a function that is used to measure the
+   one-way or two-way delay of packet transmission between a pair of the
+   end points of a path (PW, LSP, or Section), as described in
+   [RFC5860], 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.
+
+   [RFC6371] describes how the tool could be used (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
+
+   [RFC6374] describes the protocol formats and procedures for using the
+   tool and enabling efficient and accurate measurement of packet loss,
+   delay, and throughput in MPLS networks.  [RFC6375] 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               Informational                    [Page 11]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+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 (RFCs or Working Group documents) for the
+   initial phase of the specification of MPLS-based transport networks
+   is provided below.
+
+   [RFC5586] provides a specification of the basic structure of protocol
+   messages for in-band data-plane OAM in an MPLS environment.
+
+   [RFC6370] provides definitions of different formats that may be used
+   within OAM protocol messages to identify the network elements of an
+   MPLS-based transport network.
+
+   The following table (Table 1) provides the summary of proactive MPLS-
+   TP OAM Fault Management toolset functions, the associated
+   tool/protocol, and the corresponding RFCs in which they are defined.
+
+  +--------------------------+-------------------------------+---------+
+  | OAM Functions            | OAM Tools/Protocols           | RFCs    |
+  +--------------------------+-------------------------------+---------+
+  | Continuity Check and     | Bidirectional Forwarding      |[RFC6428]|
+  | Connectivity             | Detection (BFD)               |         |
+  | Verification             |                               |         |
+  +--------------------------+-------------------------------+---------+
+  | Remote Defect Indication | Flag in Bidirectional         |[RFC6428]|
+  | (RDI)                    | Forwarding Detection (BFD)    |         |
+  |                          | message                       |         |
+  +--------------------------+-------------------------------+---------+
+  | Alarm Indication Signal  | G-ACh-based AIS message       |[RFC6427]|
+  | (AIS)                    |                               |         |
+  +--------------------------+-------------------------------+---------+
+  | Link Down Indication     | Flag in AIS message           |[RFC6427]|
+  | (LDI)                    |                               |         |
+  +--------------------------+-------------------------------+---------+
+  | Lock Reporting (LKR)     | G-ACh-based LKR message       |[RFC6427]|
+  |                          |                               |         |
+  +--------------------------+-------------------------------+---------+
+
+             Table 1.  Proactive Fault Management OAM Toolset
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 12]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   The following table (Table 2) provides an overview of the on-demand
+   MPLS-TP OAM Fault Management toolset functions, the associated
+   tool/protocol, and the corresponding RFCs in which they are defined.
+
+  +------------------------+---------------------------------+---------+
+  | OAM Functions          | OAM Tools/Protocols             |  RFCs   |
+  +------------------------+---------------------------------+---------+
+  | Connectivity           | LSP Ping                        |[RFC6426]|
+  | Verification           |                                 |         |
+  +------------------------+---------------------------------+---------+
+  | Lock Instruct (LI)     | (1) G-ACh-based Loopback,       |[RFC6426]|
+  |                        | (2) Lock Instruct (LI)          |         |
+  +------------------------+---------------------------------+---------+
+  | Lock Report (LKR)      | Flag in AIS message             |[RFC6426]|
+  |                        |                                 |         |
+  +------------------------+---------------------------------+---------+
+
+             Table 2.  On Demand Fault Management OAM Toolset
+
+   The following table (Table 3) provides the Performance Monitoring
+   Functions, the associated tool/protocol definitions, and the
+   corresponding RFCs in which they are defined.
+
+   +----------------------+--------------------------+-----------------+
+   | OAM Functions        | OAM Tools/Protocols      | RFCs            |
+   +----------------------+--------------------------+-----------------+
+   | Packet Loss          | G-ACh-based LM & DM      | [RFC6374]       |
+   | Measurement (LM)     | query messages           | [RFC6375]       |
+   +----------------------+--------------------------+-----------------+
+   | Packet Delay         | G-ACh-based LM & DM      | [RFC6374]       |
+   | Measurement (DM)     | query messages           | [RFC6375]       |
+   +----------------------+--------------------------+-----------------+
+   | Throughput           | derived from Loss        | [RFC6374]       |
+   | Measurement          | Measurement              | [RFC6375]       |
+   +----------------------+--------------------------+-----------------+
+   | Delay Variation      | derived from Delay       | [RFC6374]       |
+   | Measurement          | Measurement              | [RFC6375]       |
+   +----------------------+--------------------------+-----------------+
+
+               Table 3.  Performance Monitoring OAM Toolset
+
+5.  OAM Toolset Applicability and Utilization
+
+   The following subsections present the MPLS-TP OAM toolset from the
+   perspective of the specified protocols and identifies the required
+   functionality that is supported by the particular protocol.
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 13]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+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 Sections 3.1, 3.2,
+   3.3 in this document for CC-CV protocol references.
+
+   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 the 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 the CC-CV control packets can be
+   configured.  For example:
+
+   o  3.3 ms is the default interval for protection switching.
+
+   o  100 ms is the default interval for performance monitoring.
+
+   o  1 s is the default interval for fault management.
+
+5.2.  Diagnostic Tests and Lock Instruct
+
+   [RFC6435] describes a protocol that provides a mechanism 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
+   loopback of the traffic to the source.
+
+   These diagnostic functions apply to associated bidirectional MPLS-TP
+   LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering
+   (RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-
+   plane option with GMPLS), and single-segment and multi-segment
+   Pseudowires.  [RFC6435] provides the protocol definition for
+   diagnostic tests functions.
+
+   [RFC6435] defines a mechanism where a lock instruction is sent by a
+   management application to both ends of a point-to-point LSP,
+   requesting them to take the LSP out-of-service.  When an end point
+   gets the management request, it locks the LSP and sends a Lock
+   Instruct message to the other end of the LSP.  The Lock Instruct
+   message is carried in a Generic ACH message and is sent periodically.
+   The time between successive messages is no longer than the value set
+   in the Refresh Timer field of the Lock Instruct message.  An LSP end
+   point keeps the LSP locked while it is either receiving the periodic
+
+
+
+Sprecher & Fang               Informational                    [Page 14]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   Lock Instruct messages or has an in-force lock instruction from the
+   management application.
+
+   Note that since the management application will receive a management
+   plane response from both ends of the LSP confirming that the LSP has
+   been locked, there is no requirement for the Lock Instruct message to
+   have a response.  Therefore, [RFC6435] does not define a Lock
+   Instruct response message.
+
+   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 a given
+   LSP up to a specific node on the path of the LSP.
+
+5.3.  Lock Reporting
+
+   The Lock Report (LKR) function is used to communicate to the MEPS of
+   the client (sub-)layer MEPs the administrative locking of a server
+   (sub-)layer MEP, and consequential interruption of data traffic
+   forwarding in the client layer.  See Section 3.6 in this document for
+   Lock Reporting protocol references.
+
+   When an operator is taking the LSP out of service for maintenance or
+   another operational reason, using the LKR function can help to
+   distinguish the condition as administrative locking from a defect
+   condition.
+
+   The Lock Report function may 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 the loss of continuity at the client layer.
+
+5.4.  Alarm Reporting and Link Down Indication
+
+   Alarm Indication Signal (AIS) message is used to suppress alarms
+   following detection of defect conditions at the server (sub-)layer.
+   When the Link Down Indication (LDI) is set, the AIS message may be
+   used to trigger recovery mechanisms.
+
+
+
+
+Sprecher & Fang               Informational                    [Page 15]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   When a server MEP detects the failure, it asserts LOC or signal fail,
+   which sets the flag up to generate an OAM packet with the AIS
+   message.  The AIS message is forwarded to the downstream sink MEP in
+   the client layer.  This enables the client layer to suppress the
+   generation of secondary alarms.
+
+   An 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 AIS and LDI are defined in [RFC6427].
+
+   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.
+
+5.5.  Remote Defect Indication
+
+   The Remote Defect Indication (RDI) function enables an end point to
+   report to its peer end point that a fault or defect condition is
+   detected on the PW, LSP, or Section.
+
+   The RDI OAM function is supported by the use of BFD control packets
+   [RFC6428].  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.  Additionally, the BFD control packet
+   is transmitted 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.
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 16]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+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 defines the protocols for
+   packet loss measurement, and Section 3.9 defines the protocols for
+   packet delay measurement.
+
+   The loss and delay protocols have the following characteristics and
+   capabilities:
+
+   o  They support the 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 measurements.
+
+   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.
+
+   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 [IEEE1588] by default
+      but also supports other timestamp formats, such as NTP.
+
+
+
+Sprecher & Fang               Informational                    [Page 17]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+6.  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 [RFC5920] and
+   [MPLS-TP-SEC].  Security considerations for each function within the
+   OAM toolset have been recorded in each document that specifies a
+   particular functionality.
+
+   In general, OAM is always an area where the security risk is high.
+   For example, confidential information may be intercepted by attackers
+   to gain access to networks; therefore, authentication, authorization,
+   and encryption must be enforced to prevent security breaches.
+
+   It is also important to strictly follow operational security
+   procedures.  For example, in the case of MPLS-TP static provisioning,
+   the operator interacts directly with the Network Management System
+   (NMS) and devices, and it is critical in order to prevent human
+   errors and malicious attacks.
+
+   Since MPLS-TP OAM uses G-ACh, the security risks and mitigations
+   described in [RFC5085] also apply here.  In short, messages on the
+   G-ACh could be intercepted, or false G-ACh packets could be inserted.
+
+   Additionally, DoS attacks can be mounted by flooding G-ACh messages
+   to peer devices.  To mitigate this type of attack, throttling
+   mechanisms or rate limits can be used.  For more details, please see
+   [RFC5085].
+
+7.  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 document.
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 18]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              February 2006.
+
+   [RFC5085]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
+              Virtual Circuit Connectivity Verification (VCCV): A
+              Control Channel for Pseudowires", RFC 5085, December 2007.
+
+   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+              "MPLS Generic Associated Channel", RFC 5586, June 2009.
+
+   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+              Sprecher, N., and S. Ueno, "Requirements of an MPLS
+              Transport Profile", RFC 5654, September 2009.
+
+   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+              "Requirements for Operations, Administration, and
+              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+              May 2010.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, June 2010.
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, June 2010.
+
+   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
+              L., and L. Berger, "A Framework for MPLS in Transport
+              Networks", RFC 5921, July 2010.
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
+
+   [RFC6371]  Busi, I., Ed., and D. Allan, Ed., "Operations,
+              Administration, and Maintenance Framework for MPLS-Based
+              Transport Networks", RFC 6371, September 2011.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374, September 2011.
+
+   [RFC6375]  Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
+              Delay Measurement Profile for MPLS-Based Transport
+              Networks", RFC 6375, September 2011.
+
+
+
+Sprecher & Fang               Informational                    [Page 19]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
+              On-Demand Connectivity Verification and Route Tracing",
+              RFC 6426, November 2011.
+
+   [RFC6427]  Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
+              Boutros, S., and D. Ward, "MPLS Fault Management
+              Operations, Administration, and Maintenance (OAM)", RFC
+              6427, November 2011.
+
+   [RFC6428]  Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
+              "Proactive Connectivity Verification, Continuity Check,
+              and Remote Defect Indication for the MPLS Transport
+              Profile", RFC 6428, November 2011.
+
+   [RFC6435]  Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
+              Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
+              Profile Lock Instruct and Loopback Functions", RFC 6435,
+              November 2011.
+
+8.2.  Informative References
+
+   [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
+              Synchronization Protocol for Networked Measurement and
+              Control Systems", March 2008.
+
+   [MPLS-TP-ITU-Idents]
+              Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
+              Identifiers Following ITU-T Conventions", Work in
+              Progress, March 2012.
+
+   [MPLS-TP-SEC]
+              Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
+              Security Framework", Work in Progress, March 2012.
+
+   [RFC5920]  Fang, L., Ed., "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.
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 20]
+
+RFC 6669                       OAM Toolset                     July 2012
+
+
+Contributors
+
+   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
+
+Authors' Addresses
+
+   Nurit Sprecher
+   Nokia Siemens Networks
+   3 Hanagar St. Neve Ne'eman B
+   Hod Hasharon, 45241
+   Israel
+
+   EMail: nurit.sprecher@nsn.com
+
+
+   Luyuan Fang
+   Cisco Systems
+   111 Wood Avenue South
+   Iselin, NJ 08830
+   USA
+
+   EMail: lufang@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sprecher & Fang               Informational                    [Page 21]
+