Operations and Management Area Working Group                  T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Informational                               N. Sprecher
Expires: January April 2014                               Nokia Siemens Networks
                                                           E. Bellagamba
                                                                Ericsson
                                                           Y. Weingarten

                                                            July 9,

                                                        October 21, 2013

      An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms
                   draft-ietf-opsawg-oam-overview-09.txt
                             Data Plane Tools
                   draft-ietf-opsawg-oam-overview-10.txt

Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset for fault detection and isolation, and for
   performance measurement. Over the years various OAM mechanisms tools have been
   defined for various layers in the protocol stack, and are used with a variety stack.

   This document summarizes some of the data plane OAM tools defined in
   the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for
   the transport protocols.

   This profile (MPLS-TP), and TRILL.

   The target audience of this document presents includes network equipment
   vendors, network operators and standard development organizations,
   and can be used as an overview index to some of the main data plane OAM tools that
   have been
   defined by in the IETF.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, April 21, 2014.

Copyright Notice

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

Table of Contents

   1. Introduction ................................................. 3
      1.1. Background .............................................. 4
      1.2. Target Audience.......................................... 4 5
      1.3. OAM-related Work in the IETF ............................ 5
      1.4. Focusing on Data Plane OAM Tools ........................ 6
   2. Terminology .................................................. 6 7
      2.1. Abbreviations ........................................... 6 7
      2.2. Terminology used in OAM Standards ....................... 8 9
         2.2.1. General Terms ...................................... 8 9
         2.2.2. Operations, Administration and Maintenance ......... 9
         2.2.3. Functions, Mechanisms, Tools and Protocols ......... 8
         2.2.3. ..................... 9
         2.2.4. Data Plane, Control Plane and Management Plane ..... 9
         2.2.4. .... 10
         2.2.5. The Players ....................................... 10
         2.2.5. 11
         2.2.6. Proactive and On-demand Activation ................ 11
         2.2.6. 12
         2.2.7. Connectivity Verification and Continuity Checks ... 11
         2.2.7. Failures .......................................... 12
         2.2.8. Connection Oriented vs. Connectionless Communication13
         2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14
         2.2.10. Failures ......................................... 14
   3. OAM Functions ............................................... 12 15
   4. OAM Mechanisms Tools in the IETF - a Detailed Description.......... 13 Description .............. 16
      4.1. IP Ping ................................................ 13 16
      4.2. IP Traceroute .......................................... 14 16
      4.3. Bidirectional Forwarding Detection (BFD) ............... 15 17
         4.3.1. Overview .......................................... 15 17
         4.3.2. Terminology ....................................... 15 18
         4.3.3. BFD Control ....................................... 15 18
         4.3.4. BFD Echo .......................................... 16 18
      4.4. MPLS OAM ............................................... 16 19
      4.5. MPLS-TP OAM ............................................ 17 20
         4.5.1. Overview .......................................... 17 20
         4.5.2. Terminology ....................................... 17 20
         4.5.3. Generic Associated Channel ........................ 19 22
         4.5.4. MPLS-TP OAM Toolset ............................... 19 22
            4.5.4.1. Continuity Check and Connectivity Verification 20 23
            4.5.4.2. Route Tracing ................................ 20 23
            4.5.4.3. Lock Instruct ................................ 20 23
            4.5.4.4. Lock Reporting ............................... 21 24
            4.5.4.5. Alarm Reporting .............................. 21 24
            4.5.4.6. Remote Defect Indication ..................... 21 24
            4.5.4.7. Client Failure Indication .................... 21 24
            4.5.4.8. Performance Monitoring ....................... 21 24
               4.5.4.8.1. Packet Loss Measurement (LM) ............ 22 24
               4.5.4.8.2. Packet Delay Measurement (DM) ........... 22 25
      4.6. Pseudowire OAM ......................................... 23 26
         4.6.1. Pseudowire OAM using Virtual Circuit Connectivity
         Verification (VCCV) ...................................... 23 26
         4.6.2. Pseudowire OAM using G-ACh ........................ 24 27
         4.6.3. Attachment Circuit - Pseudowire Mapping ........... 24 27
      4.7. OWAMP and TWAMP......................................... 24 27
         4.7.1. Overview .......................................... 24 27
         4.7.2. Control and Test Protocols ........................ 25 28
         4.7.3. OWAMP ............................................. 25 28
         4.7.4. TWAMP ............................................. 26 29
      4.8. TRILL .................................................. 26 29
      4.9. Summary of OAM Mechanisms .............................. 27 Tools ................................... 30
      4.10. Summary of OAM Functions .............................. 29 32
   5. Security Considerations ..................................... 30 33
   6. IANA Considerations ......................................... 31 34
   7. Acknowledgments ............................................. 31 34
   8. References .................................................. 31 34
      8.1. Informative References ................................. 31 34
   Appendix A. List of OAM Documents .............................. 36 40
      A.1. List of IETF OAM Documents ............................. 36 40
      A.2. List of Selected Non-IETF OAM Documents ................ 41 44

1. Introduction

   OAM is a general term that refers to a toolset for detecting,
   isolating and reporting failures and for monitoring the network
   performance.

   There are several different interpretations to the "OAM" acronym.
   This document refers to Operations, Administration and Maintenance,
   as recommended in [OAM-Def]. Section 3 of [RFC6291].

   This document summarizes some of the data plane OAM tools and mechanisms defined in
   the
   IETF. IETF in the context of IP unicast, MPLS, pseudowires, MPLS for
   the transport profile (MPLS-TP), and TRILL.

   This document focuses on data plane OAM tools. Hence, control and
   management aspects of OAM are outside the scope of this document.
   This document focuses on tools for detecting and isolating failures
   and for performance monitoring. Network repair functions such as Fast
   Reroute (FRR) and protection switching, which are often triggered by
   OAM protocols, are out of the scope of this document.

1.1. Background

   OAM was originally used in traditional transport communication technologies
   such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM
   was probably the first technology to include inherent OAM mechanisms support
   from day one, while in other transport technologies OAM was typically defined
   in an ad hoc manner after the technology was already defined and
   deployed. Packet-based networks were traditionally considered
   unreliable and best-effort, but as packet-based networks evolved,
   they have become the common transport for both data and telephony,
   replacing traditional transport protocols. Consequently, packet-based
   networks were expected to provide a similar "carrier grade"
   experience, and specifically to support OAM.

   As typical networks have a multi-layer architecture, the set of OAM typically has
   protocols similarly take a multi-layer architecture; structure; each transport
   technology layer has its
   own OAM mechanisms. protocols. Moreover, OAM can be used at different levels of
   hierarchy in the network to form a multi-layer OAM solution, as shown
   in the example in Figure 1.

   Figure 1 illustrates a network in which IP traffic between two
   customer edges is transported over an MPLS provider network. MPLS OAM
   is used at the provider-level for monitoring the connection between
   the two provider edges, while IP OAM is used at the customer-level
   for monitoring the end-to-end connection between the two customer
   edges.

           |<-------------- Customer-level OAM -------------->|
                 IP OAM (Ping, Traceroute, OWAMP, TWAMP)

                        |<- Provider-level OAM ->|
                            MPLS OAM (LSP Ping)

     +-----+       +----+                        +----+       +-----+
     |     |       |    |========================|    |       |     |
     |     |-------|    |          MPLS          |    |-------|     |
     |     |  IP   |    |                        |    |  IP   |     |
     +-----+       +----+                        +----+       +-----+
     Customer     Provider                      Provider      Customer
       Edge         Edge                          Edge          Edge

                     Figure 1 Example: Multi-layer OAM

1.2. Target Audience

   The target audience of this document includes:

   o Standard development organizations - both IETF working groups and
      non-IETF organizations can benefit from this document when
      designing new OAM protocols, or when looking to reuse existing OAM
      mechanisms
      tools for new transport technologies.

   o Network equipment vendors and network operators - can use this
      document as an index to existing some of the common IETF OAM mechanisms, and their
      connection to various transport technologies. tools.

   It should be noted that this document is not necessarily suitable for
   beginners without any background in OAM.

1.3. OAM-related Work in the IETF

   This memo provides an overview of the different sets of OAM
   mechanisms tools
   defined by the IETF. The set of OAM mechanisms tools described in this memo are
   applicable to IP unicast, MPLS, pseudowires, MPLS for the transport
   profile (MPLS-TP), and TRILL. While OAM mechanisms tools that are applicable to
   other technologies exist, they are beyond the scope of this memo.

   This document focuses on IETF documents that have been published as
   RFCs, while other ongoing OAM-related work is outside the scope.

   The IETF has defined OAM protocols and mechanisms tools in several different
   contexts. We roughly categorize these efforts into a few sets of OAM-related OAM-
   related RFCs, listed in Table 1. Each category defines a
   logically-coupled logically-
   coupled set of RFCs, although the sets are in some cases intertwined
   by common tools and protocols.

   The discussion in this document is ordered according to these
   categories.

                     +--------------+------------+
                     | Category     | Transport  |
                     |              | Technology |
                     +--------------+------------+
                     |IP Ping       | IPv4/IPv6  |
                     +--------------+------------+
                     |IP Traceroute | IPv4/IPv6  |
                     +--------------+------------+
                     |BFD           | generic    |
                     +--------------+------------+
                     |MPLS OAM      | MPLS       |
                     +--------------+------------+
                     |MPLS-TP OAM   | MPLS-TP    |
                     +--------------+------------+
                     |Pseudowire OAM| Pseudowires|
                     +--------------+------------+
                     |OWAMP and     | IPv4/IPv6  |
                     |TWAMP         |            |
                     +--------------+------------+
                     |TRILL OAM     | TRILL      |
                     +--------------+------------+
              Table 1 Categories of OAM-related IETF Documents

1.4. Focusing on Data Plane OAM Tools

   OAM tools may, and quite often do, work in conjunction with a control
   plane and/or management plane.  At the data plane, OAM provides
   instrumentation tools. OAM tools often use control plane functions,
   e.g., to initialize OAM sessions and to exchange various parameters.
   The OAM tools communicate with the management plane to raise alarms,
   and often OAM tools may be activated by the management (as well as by
   the control plane), e.g. to locate and localize problems.

   The considerations of the control plane maintenance tools and the
   functionality of the management plane are out of scope for this
   document, which concentrates on presenting the data plane tools that
   are used for OAM. Network repair functions such as Fast Reroute (FRR)
   and protection switching, which are often triggered by OAM protocols,
   are also out of the scope of this document.

   Since OAM protocols are used for monitoring the data plane, it is
   imperative for OAM tools to be capable of testing the actual data
   plane in as much accuracy as possible. Thus, it is important to
   enforce fate-sharing between OAM traffic that monitors the data plane
   and the user-traffic data plane traffic it monitors.

2. Terminology

2.1. Abbreviations

   ACH    Associated Channel Header

   AIS    Alarm Indication Signal

   ATM    Asynchronous Transfer Mode

   BFD    Bidirectional Forwarding Detection

   CC     Continuity Check

   CV     Connectivity Verification

   DM     Delay Measurement

   ECMP   Equal Cost Multiple Paths

   FEC    Forwarding Equivalence Class

   FRR    Fast Reroute

   G-ACh   Generic Associated Channel

   GAL    Generic Associated Label

   ICMP   Internet Control Message Protocol

   L2TP   Layer Two Tunneling Protocol

   LCCE   L2TP Control Connection Endpoint

   LDP    Label Distribution Protocol

   LER    Label Edge Router
   LM     Loss Measurement

   LSP    Label Switched Path

   LSR    Label Switched Router

   ME     Maintenance Entity

   MEG    Maintenance Entity Group

   MEP    MEG End Point

   MIP    MEG Intermediate Point

   MP     Maintenance Point

   MPLS   Multiprotocol Label Switching

   MPLS-TP MPLS Transport Profile

   MTU    Maximum Transmission Unit

   OAM    Operations, Administration, and Maintenance

   PDH    Plesiochronous Digital Hierarchy

   PE     Provider Edge

   PW     Pseudowire

   PWE3   Pseudowire Emulation Edge-to-Edge

   RBridge Routing Bridge

   RDI    Remote Defect Indication

   SDH    Synchronous Digital Hierarchy

   SONET   Synchronous Optical Networking

   TRILL   Transparent Interconnection of Lots of Links

   TTL    Time To Live

   VCCV   Virtual Circuit Connectivity Verification

2.2. Terminology used in OAM Standards

2.2.1. General Terms

   A wide variety of terms is used in various OAM standards. This
   section presents a comparison of the terms used in various OAM
   standards, without fully quoting the definition of each term.

   An interesting overview of the term OAM and its derivatives is
   presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms
   is presented in [TP-Term], and provides a good summary of some of the
   OAM related terminology.

2.2.2. Functions, Mechanisms, Tools Operations, Administration and Protocols

OAM Function Maintenance

   The following definition of OAM is a group quoted from [OAM-Def]:

   The components of functions the "OAM" acronym (and provisioning) are defined as
   follows:

   o Operations - Operation activities are undertaken to keep the
      network (and the services that provide the network fault indication,
   performance information, and data provides) up and diagnosis functions (based on
      running.  It includes monitoring the definition network and finding problems.
      Ideally these problems should be found before users are affected.

   o Administration - Administration activities involve keeping track
      of OAM resources in the ATM Forum Glossary).

   This definition implies network and how they are used.  It includes
      all the bookkeeping that is necessary to track networking
      resources and the network under control.

   o Maintenance - Maintenance activities are focused on facilitating
      repairs and upgrades -- for example, when equipment must be
      replaced, when a router needs a patch for an operating system
      image, or when a new switch is added to a network.  Maintenance
      also involves corrective and preventive measures to make the
      managed network run more effectively, e.g., adjusting device
      configuration and parameters.

2.2.3. Functions, Tools and Protocols

OAM Function

   An OAM function is an instrumentation measurement type or diagnostic.

   OAM functions are the atomic building blocks of OAM, where each
   function defines an OAM capability.

   Typical examples of OAM functions are presented in Section 3.

OAM Protocol

   A protocol used for implementing one or more OAM functions.

   The OWAMP-Test [OWAMP] is an example of an OAM protocol.

OAM Mechanism Tool

   An OAM Mechanism, sometimes referred to as an OAM tool, tool is a
   mechanism that implements specific means of applying one or more OAM
   functions.

   In some cases an OAM protocol *is* an OAM mechanism, tool, e.g., OWAMP-
   Test. OWAMP-Test. In
   other cases an OAM mechanism tool uses a set of protocols that are not strictly
   OAM-related; for example, Traceroute (Section 4.2.) can be
   implemented using UDP and ICMP messages, without using an OAM
   protocol per se.

   The terms tool and mechanism are used interchangeably in this
   document.

2.2.3.

2.2.4. Data Plane, Control Plane and Management Plane

Data Plane

   The Data Plane data plane is typically described as the hardware and software
   components responsible for receiving a packet, performing lookups to
   identify the packet's destination and possible actions that need set of functions used to
   be performed on the packet, and forwarding the packet out through transfer data in the
   appropriate outgoing interface (based on [Cont]).
   stratum or layer under consideration [ITU-Terms].

   .

   The Data Plane is also known as the Forwarding Plane or the User
   Plane.

Control Plane

   The Control Plane, as described in [Cont], control plane is generally described as the hardware set of protocols and software components for handling packets destined mechanisms that enable
   routers to
   the device itself as well as building and sending efficiently learn how to forward packets originated
   locally towards their
   final destination (based on the device. [Comp]).

Management Plane

   This

   The term Management Plane, as described in [Mgmt], [Mng], is used to describe
   the exchange of management messages through management protocols
   (often transported by IP and by IP transport protocols) between
   management applications and the managed entities such as network
   nodes.

Data Plane vs. Control Plane vs. Management Plane

   The distinction between the planes is at times a bit vague. For
   example, the definition of "Control Plane" above may imply that OAM
   tools such as ping, BFD and others are in fact in the control plane.

   This document focuses on data plane OAM tools, i.e., tools used for
   monitoring the data plane. While these tools could arguably be
   considered to be in the control plane, these tools monitor the data
   plane, and hence it is imperative to have fate-sharing between OAM
   traffic that monitors the data plane and the data plane traffic it
   monitors.

   Another potentially vague distinction is between the management plane
   and control plane. The management plane should be seen as separate
   from, but possibly overlapping with, the control plane (based on
   [Mgmt]).

2.2.4.
   [Mng]).

2.2.5. The Players

   An OAM mechanism tool is used between two (or more) "players". Various terms
   are used in IETF documents to refer to the players that take part in
   OAM. Table 2 summarizes the terms used in each of the categories
   discussed in this document.

          +--------------------------+--------------------------+
          | Category                 | Terms                    |
          +--------------------------+--------------------------+
          | Ping / Traceroute        |-Host                     |
          | ([ICMPv4], [ICMPv6],     |-Node                     |
          |  [TCPIP-Tools])          |-Interface                |
          |                          |-Gateway                  |
          + ------------------------ + ------------------------ +
          | BFD [BFD]                | System                   |
          + ------------------------ + ------------------------ +
          | MPLS OAM [MPLS-OAM-FW]   | LSR                      |
          + ------------------------ + ------------------------ +
          | MPLS-TP OAM [TP-OAM-FW]  |-End Point - MEP          |
          |                          |-Intermediate Point - MIP |
          + ------------------------ + ------------------------ +
          | Pseudowire OAM [VCCV]    |-PE                       |
          |                          |-LCCE                     |
          + ------------------------ + ------------------------ +
          | OWAMP and TWAMP          |-Host                     |
          | ([OWAMP], [TWAMP])       |-End system               |
          + ------------------------ + ------------------------ +
          | TRILL OAM [TRILL-OAM]    |-RBridge                  |
          +--------------------------+--------------------------+
                   Table 2 Maintenance Point Terminology

2.2.5.

2.2.6. Proactive and On-demand Activation

   The different OAM tools may be used in one of two basic types of
   activation:

Proactive

   Proactive activation - indicates that the tool is activated on a
   continual basis, where messages are sent periodically, and errors are
   detected when a certain number of expected messages are not received.

On-demand

   On-demand activation - indicates that the tool is activated
   "manually" to detect a specific anomaly.

2.2.6.

2.2.7. Connectivity Verification and Continuity Checks

   Two distinct classes of failure management functions are used in OAM
   protocols, connectivity verification and continuity checks. The
   distinction between these terms is defined in [MPLS-TP-OAM], and is
   used similarly in this document.

Continuity Check

   Continuity checks are used to verify that a destination is reachable,
   and are typically sent proactively, though they can be invoked on-
   demand as well.

Connectivity Verification

   A connectivity verification function allows Alice to check whether
   she is connected to Bob or not. This function also allows Alice to
   verify that messages from Bob are received through the correct path,
   thereby verifying not only that the two MPs are connected, but also
   that they are connected through the expected path, allowing detection
   of unexpected topology changes. It is noted that while the CV
   function is performed in the data plane, the "expected path" is
   predetermined either in the control plane or in the management plane.
   A connectivity verification (CV) protocol typically uses a CV
   message, followed by a CV reply that is sent back to the originator.
   A CV function can be applied proactively or on-demand.

   Connectivity verification and continuity checks are considered
   complementary mechanisms, and are often used in conjunction with each
   other.

2.2.7. Failures

   The terms Failure, Fault, and Defect are used interchangeably in the
   standards, referring to

2.2.8. Connection Oriented vs. Connectionless Communication

Connection Oriented

   In Connection Oriented technologies an end-to-end connection is
   established (by a malfunction that can be detected control protocol or provisioned by a
   connectivity or management
   system) prior to the transmission of data.

   Typically a continuity check. connection identifier is used to identify the connection.
   In some standards, such as
   802.1ag [IEEE802.1Q] , there connection oriented technologies it is no distinction often the case (although
   not always) that all packets belonging to a specific connection use
   the same route through the network.

Connectionless

   In Connectionless technologies data is typically sent between these terms,
   while end
   points without prior arrangement. Packets are routed independently
   based on their destination address, and hence different packets may
   be routed in other standards each of these terms refers to a different
   type of malfunction. way across the network.

Discussion

   The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which
   distinguishes between these terms tools described in [ITU-T-G.806];

Fault

   The term Fault refers to an inability to perform a required action,
   e.g., an unsuccessful attempt to deliver a packet.

Defect

   The term Defect refers to an interruption in the normal operation,
   such this document include tools that support
   connection oriented technologies, as well as tools for connectionless
   technologies.

   In connection oriented technologies OAM is used to monitor a consecutive period of time where no
   *specific* connection; OAM packets are delivered
   successfully.

Failure

   The term Failure refers to forwarded through the termination of same
   route as the required function.
   While a Defect typically refers to a limited period of time, data traffic and receive the same treatment. In
   connectionless technologies, OAM is used between a
   failure refers to source and
   destination pair without defining a long period specific connection. Moreover, in
   some cases the route of time.

3. OAM Functions

   This subsection provides a brief summary packets may differ from the one of the common OAM functions
   used in OAM-related standards. These functions are used as building
   blocks in
   data traffic. For example, the OAM standards described in this document.

   o Connectivity Verification (CV) and/or Continuity Checks (CC):
      As defined in Section 2.2.6.

   o Path Discovery / Fault Localization:
      This mechanism can be used to trace connectionless IP Ping (Section 4.1.)
   tests the route reachability from a source to a given destination,
      i.e., to identify the nodes along the route to while
   the destination.
      When more than one route connection oriented LSP Ping (Section 4.4.) is available to used for
   monitoring a specific destination,
      this mechanism traces one of LSP (connection), and provides the available routes. When a failure
      occurs, this mechanism also allows capability
   to detect the location of the
      failure.
      Note that monitor all the term route tracing (or Traceroute) that is available paths used in
      the context of by an LSP.

   It should be noted that in some cases connectionless protocols are
   monitored by connection oriented OAM protocols. For example, while IP and MPLS,
   is sometimes referred a connectionless protocol, it can monitored by BFD (Section 4.3.
   ), which is connection oriented.

2.2.9. Point-to-point vs. Point-to-multipoint Services

Point-to-point (P2P)

   A P2P service delivers data from a single source to a single
   destination.

Point-to-multipoint (P2MP)

   An P2MP service delivers data from a single source to a one or more
   destinations (based on [Signal]).

   [Signal] also defines a MP2MP service as path
      tracing a service that delivers data
   from more than one source to one or more receivers.

Discussion

   The OAM tools described in other transport technologies, such this document include tools for P2P
   services, as TRILL.

   o Performance Monitoring:
      Typically refers to:

        o Loss Measurement (LM) - monitors the packet loss rate.

        o Delay Measurement (DM) - monitors the delay well as tools for P2MP services.

   The distinction between P2P services and delay
          variation.

4. OAM Mechanisms in P2MP services affects the IETF - a Detailed Description

   This section presents a detailed description
   corresponding OAM tools. A P2P service is typically simpler to
   monitor, as it consists of the sets a single pair of OAM-
   related mechanisms end points. P2MP services
   present several challenges. For example, in a P2MP service, the OAM
   mechanism not only verifies that each of the categories in Table 1.

4.1. IP Ping

   Ping destinations is a common network diagnosis application for IP networks
   reachable from the source, but also verifies that
   uses ICMP. 'Ping' the P2MP
   distribution tree is an abbreviation for Packet internet groper
   [NetTerms].  As defined intact and loop-free. Another challenge in [NetTerms], it P2MP
   services is a program used to test
   reachability of destinations performance monitoring; while in P2P packet loss is
   measured by sending them an ICMP echo request maintaining packet counters at the two end-points, in
   P2MP packet loss must be carefully measured by generating synthetic
   traffic to each corresponding end-point and
   waiting for maintaining a reply. separate
   counter for each peer end-point.

2.2.10. Failures

   The ICMP Echo request/reply exchange in Ping is used as a continuity
   check function for the Internet Protocol. The originator transmits an
   ICMP Echo request packet, and the receiver replies with an Echo
   reply. ICMP ping is defined in two variants, [ICMPv4] is used for
   IPv4, terms Failure, Fault, and [ICMPv6] is Defect are used for IPv6.

   Ping implementations typically use ICMP messages. UDP Ping is interchangeably in the
   standards, referring to a
   variant malfunction that uses UDP messages instead of ICMP echo messages.

   Ping is can be detected by a
   connectivity or a single-ended continuity check, i.e., it allows the
   *initiator* of the Echo request to test the reachability. If it is
   desirable for both ends to test the reachability, both ends have to
   invoke Ping independently.

   Note that since ICMP filtering check. In some standards, such as
   802.1ag [IEEE802.1Q] , there is deployed no distinction between these terms,
   while in some routers and
   firewalls, the usefulness other standards each of Ping is sometimes limited these terms refers to a different
   type of malfunction.

   The terminology used in the wider
   internet. This limitation IETF MPLS-TP OAM is equally relevant based on the ITU-T
   terminology, which distinguishes between these three terms in
   [ITU-T-G.806];

Fault

   The term Fault refers to Traceroute.

4.2. IP Traceroute

   Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
   users inability to discover perform a path between an IP source and required action,
   e.g., an IP destination. unsuccessful attempt to deliver a packet.

Defect

   The most common way term Defect refers to implement Traceroute [TCPIP-Tools] is
   described an interruption in the normal operation,
   such as follows. Traceroute sends a sequence consecutive period of UDP time where no packets to
   UDP port 33434 at are delivered
   successfully.

Failure

   The term Failure refers to the destination. By default, Traceroute begins by
   sending three packets (the number termination of packets is configurable in most
   Traceroute implementations), each with an IP Time-To-Live (or Hop
   Limit in IPv6) value the required function.
   While a Defect typically refers to a limited period of one time, a
   failure refers to a long period of time.

3. OAM Functions

   This subsection provides a brief summary of the destination. common OAM functions
   used in OAM-related standards. These packets expire
   as soon functions are used as they reach the first router building
   blocks in the path. Consequently,
   that router sends three ICMP Time Exceeded Messages back OAM standards described in this document.

   o Connectivity Verification (CV) and/or Continuity Checks (CC):
      As defined in Section 2.2.7.

   o Path Discovery / Fault Localization:
      This function can be used to trace the
   Traceroute application. Traceroute now sends another three UDP
   packets, each with the TTL value of 2. These messages cause the
   second router route to return ICMP messages. This process continues, with
   ever increasing values for a destination,
      i.e., to identify the TTL field, until nodes along the packets actually
   reach route to the destination. Because no application listens
      When more than one route is available to port 33434
   at the a specific destination,
      this function traces one of the destination returns ICMP Destination
   Unreachable Messages indicating an unreachable port. This event
   indicates available routes. When a failure
      occurs, this function also allows to detect the Traceroute application that it is finished.  The
   Traceroute program displays the round-trip delay associated with each location of the attempts.

   It is noted
      failure.
      Note that Traceroute is an application, and not a protocol. As
   such, it has various different implementations. One of the most
   common ones uses UDP probe packets, as described above. Other
   implementations exist term route tracing (or Traceroute) that use other types is used in
      the context of probe messages, such as
   ICMP or TCP.

   Note that IP routing may be asymmetric. While Traceroute discovers a
   path between a source and destination, it does not reveal the reverse
   path.

   A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined MPLS, is sometimes referred to as path
      tracing in the context of Traceroute. These documents define several extensions,
   including extensions to other protocols, such as TRILL.

   o Performance Monitoring:
      Typically refers to:

        o Loss Measurement (LM) - monitors the ICMP Destination Unreachable message,
   that can be used by Traceroute applications.

4.3. Bidirectional Forwarding Detection (BFD)

4.3.1. Overview

   While multiple packet loss rate.

        o Delay Measurement (DM) - monitors the delay and delay
          variation.

4. OAM mechanisms have been defined for various protocols Tools in the protocol stack, Bidirectional Forwarding Detection [BFD],
   defined by the IETF BFD working group, is - a generic OAM mechanism
   that can be deployed over various encapsulating protocols, and Detailed Description

   This section presents a detailed description of the sets of OAM-
   related tools in
   various medium types. The IETF has defined variants each of the protocol
   for categories in Table 1.

4.1. IP ([BFD-IP], [BFD-Multi]), Ping

   Ping is a common network diagnosis application for MPLS LSPs [BFD-LSP], and IP networks that
   uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for
   pseudowires [BFD-VCCV]. The usage of BFD
   Packet internet groper, although the term has been so commonly used
   that it stands on its own.  As defined in MPLS-TP [NetTerms], it is defined in
   [TP-CC-CV].

   BFD includes two main OAM functions, using two types a program
   used to test reachability of BFD packets:
   BFD Control packets, destinations by sending them an ICMP
   echo request and BFD Echo packets.

4.3.2. Terminology

   BFD operates between two *systems*. waiting for a reply.

   The BFD protocol ICMP Echo request/reply exchange in Ping is run between
   two systems after establishing a *session*.

4.3.3. BFD Control

   BFD supports used as a bidirectional continuity check, using BFD control
   packets, that are exchanged within a BFD session. BFD sessions
   operate in one of two modes:

   o Asynchronous mode (i.e. proactive): in this mode BFD control
      packets are sent periodically. When
   check function for the Internet Protocol. The originator transmits an
   ICMP Echo request packet, and the receiver detects that no
      BFD control packets have been received during a predetermined
      period of time, a failure replies with an Echo
   reply. ICMP ping is detected.

   o Demand mode: defined in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates two variants, [ICMPv4] is used for
   IPv4, and [ICMPv6] is used for IPv6.

   Ping implementations typically use ICMP messages. UDP Ping is a series
   variant that uses UDP messages instead of BFD control packets to
      check the ICMP echo messages.

   Ping is a single-ended continuity of check, i.e., it allows the session. BFD control packets are sent
      independently in each direction.

   Each
   *initiator* of the end-points (referred Echo request to as systems) of test the monitored path
   maintains its own session identification, called a Discriminator, reachability. If it is
   desirable for both of which are included in ends to test the BFD Control Packets reachability, both ends have to
   invoke Ping independently.

   Note that are
   exchanged between the end-points.  At the time of session
   establishment, the Discriminators are exchanged between the two-end
   points.  In addition, the transmission (and reception) rate since ICMP filtering is
   negotiated between the two end-points, based on information included deployed in some routers and
   firewalls, the control packets.  These transmission rates may be renegotiated
   during the session.

   During normal operation usefulness of the session, i.e. no failures are
   detected, the BFD session Ping is sometimes limited in the Up state.  If no BFD Control
   packets are received during a period of time called the Detection
   Time, the session wider
   internet. This limitation is declared equally relevant to be Down. The detection time Traceroute.

4.2. IP Traceroute

   Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
   users to discover a
   function of the pre-configured or negotiated transmission time, path between an IP source and an IP destination.

   The most common way to implement Traceroute [TCPIP-Tools] is
   described as follows. Traceroute sends a
   parameter called Detect Mult. Detect Mult determines sequence of UDP packets to
   UDP port 33434 at the destination. By default, Traceroute begins by
   sending three packets (the number of
   missing BFD Control packets that cause the session is configurable in most
   Traceroute implementations), each with an IP Time-To-Live (or Hop
   Limit in IPv6) value of one to be declared the destination. These packets expire
   as
   Down. This parameter is included soon as they reach the first router in the BFD Control packet.

4.3.4. BFD Echo

   A BFD echo packet is sent to a peer system, and is looped back path. Consequently,
   that router sends three ICMP Time Exceeded Messages back to the
   originator. The echo function can be used proactively, or on-demand.

   The BFD echo function has been defined in BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for
   MPLS-TP.

4.4. MPLS OAM

   The IETF MPLS working group has defined OAM for MPLS LSPs. The
   requirements and framework of this effort are defined in
   [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM
   mechanism defined, in this context, is LSP Ping [LSP-Ping].

   LSP Ping is modeled after
   Traceroute application. Traceroute now sends another three UDP
   packets, each with the Ping/Traceroute paradigm and thus it
   may be used in one TTL value of two modes:

   o "Ping" mode: In this mode LSP Ping is used for end-to-end
      connectivity verification between two LERs.

   o "Traceroute" mode: This mode is used for hop-by-hop fault
      isolation.

   LSP Ping extends 2. These messages cause the basic
   second router to return ICMP Ping operation (of data-plane
   connectivity verification) messages. This process continues, with functionality to verify data-plane
   vs. control-plane consistency
   ever increasing values for a Forwarding Equivalence Class
   (FEC) and also Maximum Transmission Unit (MTU) problems. The
   Traceroute functionality may be used to isolate and localize the MPLS
   faults, using TTL field, until the Time-to-live (TTL) indicator packets actually
   reach the destination. Because no application listens to incrementally
   identify port 33434
   at the sub-path of destination, the LSP destination returns ICMP Destination
   Unreachable Messages indicating an unreachable port. This event
   indicates to the Traceroute application that it is successfully traversed
   before finished.  The
   Traceroute program displays the faulty link or node.

   It should be noted that LSP Ping supports unique identification round-trip delay associated with each
   of the LSP within an addressing domain. The identification attempts.

   While Traceroute is checked
   using the full FEC identification. LSP Ping a tool that finds *a* path from A to B, it should
   be noted that traffic from A to B is easily extensible often forwarded through Equal
   Cost Multiple Paths (ECMP). Paris Traceroute [Paris] is an extension
   to
   include additional information needed Traceroute that attempts to support new functionality, discovers all the available paths from
   A to B by use of Type-Length-Value (TLV) constructs. The usage scanning different values of TLVs is
   typically not easy to perform header fields (such as UDP
   ports) in hardware, and is thus typically
   handled by the control plane.

   LSP Ping supports both asynchronous, as well as, on-demand
   activation.

4.5. MPLS-TP OAM

4.5.1. Overview

   The MPLS working group probe packets.

   It is noted that Traceroute is an application, and not a protocol. As
   such, it has defined various different implementations. One of the OAM toolset most
   common ones uses UDP probe packets, as described above. Other
   implementations exist that fulfills the
   requirements for MPLS-TP OAM. The full set use other types of requirements for MPLS-
   TP OAM are probe messages, such as
   ICMP or TCP.

   Note that IP routing may be asymmetric. While Traceroute discovers a
   path between a source and destination, it does not reveal the reverse
   path.

   A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in [MPLS-TP-OAM], and include both general
   requirements for
   the behavior context of Traceroute. These documents define several extensions,
   including extensions to the OAM mechanisms and a set of
   operations ICMP Destination Unreachable message,
   that should can be supported used by the OAM toolset.  The set of
   mechanisms required are further elaborated in [TP-OAM-FW], which
   describes the general architecture of the OAM system as well as
   giving overviews of the functionality of the OAM toolset.

   Some of the basic requirements for the Traceroute applications.

4.3. Bidirectional Forwarding Detection (BFD)

4.3.1. Overview

   While multiple OAM toolset tools have been defined for MPLS-TP are:

   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 the MPLS-TP OAM toolset should rely
      on the IP routing and forwarding capabilities. On the other hand, various protocols in environments where IP functionality is not available,
   the OAM
      tools must still be able to operate without dependence on IP
      forwarding and routing.

   o OAM packets and protocol stack, Bidirectional Forwarding Detection [BFD], defined
   by the user traffic are required to be congruent
      (i.e. OAM packets are transmitted in-band) and there IETF BFD working group, is a need to
      differentiate generic OAM packets from data plane ones. Inherent in this
      requirement is the principle tool that MPLS-TP OAM can be independent of
      any existing control-plane, although it should not preclude use
   deployed over various encapsulating protocols, and in various medium
   types. The IETF has defined variants of the control-plane functionality.

4.5.2. Terminology

Maintenance Entity (ME) protocol for IP ([BFD-
   IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD-
   VCCV]. The usage of BFD in MPLS-TP OAM tools are designed to monitor and manage a
   Maintenance Entity (ME).  An ME, as is defined in [TP-OAM-FW], defines a
   relationship between [TP-CC-CV].

   BFD includes two points main OAM functions, using two types of a transport path to which
   maintenance BFD packets:
   BFD Control packets, and monitoring operations apply. BFD Echo packets.

4.3.2. Terminology

   BFD operates between two *systems*. The term Maintenance Entity (ME) BFD protocol is used in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as run between
   two systems after establishing a *session*.

4.3.3. BFD Control

   BFD supports a bidirectional continuity check, using BFD control
   packets, that are exchanged within a BFD session. BFD sessions
   operate in the MPLS-TP terminology
   ([TP-OAM-FW]).

Maintenance Entity Group (MEG)

   The collection of one or more MEs that belongs to of two modes:

   o Asynchronous mode (i.e. proactive): in this mode BFD control
      packets are sent periodically. When the same transport
   path and receiver detects that are maintained and monitored as no
      BFD control packets have been received during a group are known as predetermined
      period of time, a
   Maintenance Entity Group (based on [TP-OAM-FW]).

Maintenance Point (MP)

   A Maintenance Point (MP) failure is detected.

   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a functional entity that is defined at system initiates a
   node in the network, and can initiate and/or react series of BFD control packets to OAM messages.
   This document focuses on
      check the data-plane functionality continuity of MPs, while
   MPs interact with the session. BFD control plane and with packets are sent
      independently in each direction.

   Each of the management plane end-points (referred to as
   well.

   The term MP is used in IEEE 802.1ag, and was similarly adopted in
   MPLS-TP ([TP-OAM-FW]).

Maintenance End Point (MEP)

   A Maintenance End Point (MEP) is one systems) of the end points monitored path
   maintains its own session identification, called a Discriminator,
   both of an ME, and
   can initiate OAM messages and respond to them (based on [TP-OAM-FW]).

Maintenance Intermediate Point (MIP)

   In between MEPs, there which are zero or more intermediate points, called
   Maintenance Entity Group Intermediate Points  (based on [TP-OAM-FW]).

   A Maintenance Intermediate Point (MIP) is an intermediate point that
   does not generally initiate OAM frames (one exception to this is included in the
   use of AIS notifications), but is able to respond to OAM frames BFD Control Packets that are destined to it. A MIP in MPLS-TP identifies OAM packets destined
   to it by
   exchanged between the value end-points.  At the time of session
   establishment, the TTL field in Discriminators are exchanged between the OAM packet. The term
   Maintenance Point two-end
   points.  In addition, the transmission (and reception) rate is a general term for MEPs and MIPs.

Up and Down MEPs

   The IEEE 802.1ag [IEEE802.1Q] defines a distinction
   negotiated between Up MEPs
   and Down MEPs. A MEP is a bridge interface that is monitored by an
   OAM protocol either the two end-points, based on information included
   in the direction facing control packets.  These transmission rates may be renegotiated
   during the network, or in session.

   During normal operation of the
   direction facing session, i.e. no failures are
   detected, the bridge. A Down MEP BFD session is a MEP that receives OAM
   packets from, and transmits them to the direction of in the network. An Up MEP receives OAM state.  If no BFD Control
   packets from, and transmits them to the direction
   of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses are received during a similar
   distinction on the placement period of time called the MEP - either at Detection
   Time, the ingress,
   egress, or forwarding function of the node (Down / Up MEPs).  This
   placement session is important for localization of a failure. declared to be Down. The distinction between Up and Down MEPs was defined in [TP-OAM-FW],
   but has not been used in other MPLS-TP RFCs, as of the writing detection time is a
   function of
   this document.

4.5.3. Generic Associated Channel

   In order to address the requirement for in-band pre-configured or negotiated transmission of MPLS-
   TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
   defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based
   on the same concepts as the PWE3 ACH time, and VCCV mechanisms.  However,
   to address the needs of LSPs as differentiated from PW, the following
   concepts were defined for [G-ACh]:

   o An Associated Channel Header (ACH), that uses a format similar to
   parameter called Detect Mult. Detect Mult determines the PW number of
   missing BFD Control Word, is a 4-byte header packets that is prepended cause the session to OAM
      packets.

   o A Generic Associated Label (GAL). The GAL be declared as
   Down. This parameter is a reserved MPLS label
      value (13) that indicates that included in the BFD Control packet.

4.3.4. BFD Echo

   A BFD echo packet is an ACH packet sent to a peer system, and the
      payload follows immediately after the label stack.

   It should be noted that while the G-ACh was defined as part of the
   MPLS-TP definition effort, the G-ACh is a generic tool that looped back to the
   originator. The echo function can be used proactively, or on-demand.

   The BFD echo function has been defined in MPLS in general, BFD for IPv4 and IPv6
   ([BFD-IP]), but is not only used in MPLS-TP.

4.5.4. MPLS-TP OAM Toolset

   To address the functionality that is required of the OAM toolset, the BFD for MPLS WG conducted an analysis of the existing IETF and ITU-T OAM
   mechanisms and their ability to fulfill the required functionality.
   The conclusions of this analysis are documented LSPs, PWs, or in [OAM-Analys]. BFD for
   MPLS-TP.

4.4. MPLS OAM

   The IETF MPLS working group currently plans to use a mixture of has defined OAM mechanisms
   that are based on various existing standards, and adapt them to the for MPLS LSPs. The
   requirements of [MPLS-TP-OAM]. Some of the main building blocks and framework of this solution effort are based on:

   o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
      proactive continuity check defined in
   [MPLS-OAM-FW] and connectivity verification.

   o [MPLS-OAM], respectively. The corresponding OAM
   tool defined, in this context, is LSP Ping as defined in [LSP-Ping] [LSP-Ping]. OAM for on-demand connectivity
      verification.

   o New protocol packets, using G-ACH, to address different
      functionality.

   o Performance measurement protocols that are based on the
      functionality that P2MP
   services is described in [ITU-T-Y1731].

   The following sub-sections describe the OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

4.5.4.1. Continuity Check and Connectivity Verification

   Continuity Check [MPLS-P2MP].

   LSP Ping is modeled after the Ping/Traceroute paradigm and Connectivity Verification are presented in
   Section 2.2.6. of this document.  As presented there, these tools thus it
   may be used either proactively or on-demand.  When using these tools
   proactively, they are generally used in tandem.

   For MPLS-TP there are one of two distinct tools, the proactive tool is
   defined in [TP-CC-CV] while the on-demand tool is defined in
   [OnDemand-CV]. modes:

   o "Ping" mode: In on-demand mode, this function should support
   monitoring between the MEPs and, in addition, between a MEP and MIP.
   [TP-OAM-FW] highlights,  when performing Connectivity Verification,
   the need mode LSP Ping is used for end-to-end
      connectivity verification between two LERs.

   o "Traceroute" mode: This mode is used for hop-by-hop fault
      isolation.

   LSP Ping extends the CC-V messages basic ICMP Ping operation (of data-plane
   connectivity verification) with functionality to include unique identification of
   the MEG that is being monitored verify data-plane
   vs. control-plane consistency for a Forwarding Equivalence Class
   (FEC) and the MEP that originated the
   message. also Maximum Transmission Unit (MTU) problems.

   The proactive tool [TP-CC-CV] challenge in MPLS networks is based on extensions to BFD (see
   Section 4.3.) with the additional limitation that the transmission
   and receiving rates are based on configuration by the operator.  The
   on-demand tool [OnDemand-CV] is an adaptation traffic of a given LSP may
   be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping (see
   Section 4.4.) for
   monitors all the required behavior available paths of MPLS-TP.

4.5.4.2. Route Tracing

   [MPLS-TP-OAM] defines that there is a need for an LSP by monitoring its
   different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP
   does not use ECMP, and thus does not require OAM over multiple paths.
   The Traceroute functionality that
   would allow a path end-point may be used to isolate and localize the
   MPLS faults, using the Time-to-live (TTL) indicator to incrementally
   identify the intermediate and end-
   points sub-path of the path. 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.  The tool for this LSP that is based on successfully traversed
   before the faulty link or node.

   It should be noted that LSP Ping (see
   Section 4.4.) functionality and is described in [OnDemand-CV].

4.5.4.3. Lock Instruct supports unique identification of
   the LSP within an addressing domain. The Lock Instruct function [Lock-Loop] identification is used checked
   using the full FEC identification. LSP Ping is easily extensible to notify a transport
   path end-point
   include additional information needed to support new functionality,
   by use of an administrative need Type-Length-Value (TLV) constructs. The usage of TLVs is
   typically not easy to disable the transport
   path.  This functionality will generally be used perform in conjunction with
   some intrusive OAM function, e.g. Performance measurement, Diagnostic
   testing, to minimize the side-effect on user data traffic.

4.5.4.4. Lock Reporting

   Lock Reporting hardware, and is a function used thus typically
   handled by an end-point of a path to report
   to its far-end end-point that a lock condition the control plane.

   LSP Ping supports both asynchronous, as well as, on-demand
   activation.

4.5. MPLS-TP OAM

4.5.1. Overview

   The MPLS working group has been affected on defined the path.

4.5.4.5. Alarm Reporting

   Alarm Reporting [TP-Fault] provides OAM toolset that fulfills the means to suppress alarms
   following detection
   requirements for MPLS-TP OAM. The full set of defect conditions at requirements for MPLS-
   TP OAM are defined in [MPLS-TP-OAM], and include both general
   requirements for the server sub-layer.
   Alarm reporting is used by an intermediate point behavior of the OAM tools and a path, that
   becomes aware set of a fault on
   operations that should be supported by the path, to report to OAM toolset.  The set of
   mechanisms required are further elaborated in [TP-OAM-FW], which
   describes the end-points general architecture of the path. [TP-OAM-FW] states that this may occur OAM system as a result well as
   giving overviews of a
   defect condition discovered at a server sub-layer. This generates an
   Alarm Indication Signal (AIS) that continues until the fault is
   cleared. The consequent action functionality of this function the OAM toolset.

   Some of the basic requirements for the OAM toolset for MPLS-TP are:

   o MPLS-TP OAM must be able to support both an IP based and non-IP
      based environment. If the network is detailed IP based, i.e. IP routing and
      forwarding are available, then the MPLS-TP OAM toolset should rely
      on the IP routing and forwarding capabilities. On the other hand,
      in
   [TP-OAM-FW].

4.5.4.6. Remote Defect Indication

   Remote Defect Indication (RDI) environments where IP functionality is used proactively by a path end-
   point to report not available, the OAM
      tools must still be able to its peer end-point that a defect is detected operate without dependence on a
   bidirectional connection between them. [MPLS-TP-OAM] points out that
   this function may be applied IP
      forwarding and routing.

   o OAM packets and the user traffic are required to a unidirectional LSP only if be congruent
      (i.e. OAM packets are transmitted in-band) and there is a
   return path exists.  [TP-OAM-FW] points out that need to
      differentiate OAM packets from data plane ones. Inherent in this function is
   associated with the proactive CC-V function.

4.5.4.7. Client Failure Indication

   Client Failure Indication (CFI)
      requirement is defined in [MPLS-TP-OAM] to allow the propagation information from one edge principle that MPLS-TP OAM be independent of
      any existing control-plane, although it should not preclude use of
      the network to the
   other. control-plane functionality.

4.5.2. Terminology

Maintenance Entity (ME)

   The information concerns a defect MPLS-TP OAM tools are designed to monitor and manage a client, in the case
   that the client does not support alarm notification.

4.5.4.8. Performance Monitoring

   The definition of MPLS performance monitoring was motivated by the
   MPLS-TP requirements [MPLS-TP-OAM], but was
   Maintenance Entity (ME).  An ME, as defined generically for
   MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] [TP-OAM-FW], defines a
   performance
   relationship between two points of a transport path to which
   maintenance and monitoring profile for MPLS-TP.

4.5.4.8.1. Packet Loss Measurement (LM)

   Packet Loss Measurement operations apply.

   The term Maintenance Entity (ME) is a function used to verify the quality of
   the service. Packet loss, in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as defined in [IPPM-1LM] and [MPLS-TP-OAM],
   indicates the ratio of the number MPLS-TP terminology
   ([TP-OAM-FW]).

Maintenance Entity Group (MEG)
   The collection of user packets lost one or more MEs that belongs to the total
   number of user packets sent during same transport
   path and that are maintained and monitored as a defined time interval.

   There group are two possible ways of determining this measurement:

   o Using OAM packets, it is possible to compute the statistics based known as a
   Maintenance Entity Group (based on [TP-OAM-FW]).

Maintenance Point (MP)

   A Maintenance Point (MP) is a series of OAM packets. This, however, has functional entity that is defined at a
   node in the disadvantage of
      being artificial, network, and may not be representative since part can initiate and/or react to OAM messages.
   This document focuses on the data-plane functionality of MPs, while
   MPs interact with the
      packet loss may be dependent upon packet sizes control plane and upon the
      implementation of with the MEPs that take part management plane as
   well.

   The term MP is used in the protocol.

   o Sending delimiting messages for the start IEEE 802.1ag, and end was similarly adopted in
   MPLS-TP ([TP-OAM-FW]).

Maintenance End Point (MEP)

   A Maintenance End Point (MEP) is one of a measurement
      period during which the source and sink end points of an ME, and
   can initiate OAM messages and respond to them (based on [TP-OAM-FW]).

Maintenance Intermediate Point (MIP)

   In between MEPs, there are zero or more intermediate points, called
   Maintenance Entity Group Intermediate Points  (based on [TP-OAM-FW]).

   A Maintenance Intermediate Point (MIP) is an intermediate point that
   does not generally initiate OAM frames (one exception to this is the path count the
   use of AIS notifications), but is able to respond to OAM frames that
   are destined to it. A MIP in MPLS-TP identifies OAM packets transmitted and received. After destined
   to it by the end delimiter, value of the
      ratio would be calculated by TTL field in the path OAM entity.

4.5.4.8.2. Packet Delay Measurement (DM)

   Packet Delay Measurement packet. The term
   Maintenance Point is a function that is used to measure one-
   way or two-way delay of general term for MEPs and MIPs.

Up and Down MEPs

   The IEEE 802.1ag [IEEE802.1Q] defines a packet transmission distinction between Up MEPs
   and Down MEPs. A MEP is a pair of bridge interface that is monitored by an
   OAM protocol either in the
   end-points of a path (PW, LSP, direction facing the network, or Section). Where:

   o One-way packet delay, as defined in [IPPM-1DM], is the time
      elapsed from
   direction facing the start of transmission of bridge. A Down MEP is a MEP that receives OAM
   packets from, and transmits them to the first bit direction of the
      packet by a source node until network. An
   Up MEP receives OAM packets from, and transmits them to the reception direction
   of the last bit of
      that packet by bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar
   distinction on the destination node.

   o Two-way packet delay, as defined in [IPPM-2DM], is placement of the time
      elapsed from MEP - either at the start of transmission ingress,
   egress, or forwarding function of the first bit node (Down / Up MEPs).  This
   placement is important for localization of the
      packet by a source node until the reception failure.

   The distinction between Up and Down MEPs was defined in [TP-OAM-FW],
   but has not been used in other MPLS-TP RFCs, as of the last bit writing of
   this document.

4.5.3. Generic Associated Channel

   In order to address the
      loop-backed packet by the same source node, when the loopback is
      performed at the packet's destination node.

   For each requirement for in-band transmission of these two metrics, MPLS-
   TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
   defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based
   on the DM function allows same concepts as the MEP PWE3 ACH and VCCV mechanisms.  However,
   to
   measure address the delay, as well needs of LSPs as differentiated from PW, the delay variation. Delay measurement
   is performed by exchanging timestamped OAM packets between the
   participating MEPs.

4.6. Pseudowire OAM

4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification
   (VCCV)

   VCCV, as following
   concepts were defined in [VCCV], provides a means for end-to-end fault
   detection and diagnostics tools [G-ACh]:

   o An Associated Channel Header (ACH), that uses a format similar to be extended for PWs (regardless of
      the underlying tunneling technology). The VCCV switching function
   provides a control channel associated with each PW. [VCCV] defines
   three PW Control Channel (CC) types, i.e., three possible methods for
   transmitting and identifying OAM messages:

   o CC Type 1: In-band VCCV, as described in [VCCV], Word, is also referred
      to as "PWE3 Control Word with 0001b as first nibble".  It uses the
      PW Associated Channel Header [PW-ACH].

   o CC Type 2: Out-of-band VCCV [VCCV], a 4-byte header that is also referred prepended to as "MPLS
      Router Alert Label". In this case the control channel OAM
      packets.

   o A Generic Associated Label (GAL). The GAL is created
      by using the a reserved MPLS router alert label [RFC3032] immediately above
      value (13) that indicates that the PW label.

   o CC Type 3: TTL expiry VCCV [VCCV], packet is also referred to as "MPLS PW
      Label with TTL == 1", i.e., an ACH packet and the control channel is identified when
      payload follows immediately after the value label stack.

   It should be noted that while the G-ACh was defined as part of the TTL field
   MPLS-TP definition effort, the G-ACh is a generic tool that can be
   used in MPLS in general, and not only in MPLS-TP.

4.5.4. MPLS-TP OAM Toolset

   To address the PW label functionality that is set to 1.

   VCCV currently supports required of the following OAM mechanisms: ICMP Ping, LSP
   Ping, toolset, the
   MPLS WG conducted an analysis of the existing IETF and BFD. ICMP ITU-T OAM
   tools and LSP Ping are IP encapsulated before being
   sent over their ability to fulfill the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes required functionality.  The
   conclusions of
   encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP header) and provides support to
   signal the AC status. this analysis are documented in [OAM-Analys]. The MPLS
   working group currently plans to use a mixture of the VCCV control channel provides
   the context, OAM tools that are
   based on the MPLS-PW label, required to bind various existing standards, and
   bootstrap the BFD session adapt them to a particular pseudo wire (FEC),
   eliminating the need to exchange Discriminator values.

   VCCV consists
   requirements of two components: (1) signaled component to
   communicate VCCV capabilities as part [MPLS-TP-OAM]. Some of VC label, the main building blocks of
   this solution are based on:

   o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
      proactive continuity check and (2) switching
   component connectivity verification.

   o LSP Ping as defined in [LSP-Ping] for on-demand connectivity
      verification.

   o New protocol packets, using G-ACH, to cause address different
      functionality.

   o Performance measurement protocols that are based on the PW payload to be treated as a control packet.

   VCCV
      functionality that is not directly dependent upon described in [ITU-T-Y1731].

   The following sub-sections describe the presence OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

4.5.4.1. Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification are presented in
   Section 2.2.7. of a control plane.
   The VCCV capability negotiation this document.  As presented there, these tools may
   be performed as part of used either proactively or on-demand.  When using these tools
   proactively, they are generally used in tandem.

   For MPLS-TP there are two distinct tools, the PW
   signaling when LDP proactive tool is used. In case of manual configuration of
   defined in [TP-CC-CV] while the
   PW, it on-demand tool is the responsibility of the operator to set consistent
   options at both ends. The manual option was created specifically to
   handle MPLS-TP use cases where no control plane was a requirement.
   However, new use cases such as pure mobile backhaul find this
   functionality useful too.

4.6.2. Pseudowire OAM using G-ACh

   As mentioned above, VCCV enables OAM for PWs by using a control
   channel for OAM packets. When PWs are used in MPLS-TP networks,
   rather than the control channels defined in VCCV, the G-ACh can be
   used as an alternative control channel. The usage of
   [OnDemand-CV]. In on-demand mode, this function should support
   monitoring between the G-ACh for
   PWs is defined MEPs and, in [PW-G-ACh].

4.6.3. Attachment Circuit - Pseudowire Mapping

   The PWE3 working group has defined a mapping and notification of
   defect states addition, between a pseudowire (PW) MEP and MIP.
   [TP-OAM-FW] highlights,  when performing Connectivity Verification,
   the Attachment Circuits
   (ACs) need for the CC-V messages to include unique identification of
   the end-to-end emulated service. This mapping MEG that is of key
   importance to being monitored and the end-to-end functionality. Specifically, MEP that originated the mapping
   message.

   The proactive tool [TP-CC-CV] is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and based on extensions to BFD (see
   Section 5.3 of [ATM-L2] for ATM.

4.7. OWAMP 4.3.) with the additional limitation that the transmission
   and TWAMP

4.7.1. Overview receiving rates are based on configuration by the operator.  The IPPM working group in
   on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see
   Section 4.4.) for the IETF required behavior of MPLS-TP.

4.5.4.2. Route Tracing

   [MPLS-TP-OAM] defines common criteria and
   metrics that there is a need for measuring performance of IP traffic ([IPPM-FW]). Some of
   the key RFCs published by this working group have defined metrics for
   measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   and packet loss [IPPM-1LM]. It should be noted functionality that
   would allow a path end-point to identify the work intermediate and end-
   points of the
   IETF path. This function would be used in the context of performance metrics is not limited to IP
   networks; [PM-CONS] presents general guidelines on-demand mode.
   Normally, this path will be used for considering new
   performance metrics.

   The IPPM working group has defined not bidirectional PW, LSP, and
   sections, however, unidirectional paths may be supported only metrics if a
   return path exists.  The tool for performance
   measurement, but also protocols that define how the measurement this is
   carried out. The One-way Active Measurement Protocol [OWAMP] and based on the
   Two-Way Active Measurement Protocol [TWAMP] define a method LSP Ping (see
   Section 4.4.) functionality and
   protocol for measuring performance metrics is described in IP networks.

   OWAMP [OWAMP] enables measurement of one-way characteristics of IP
   networks, such as one-way packet loss and one-way delay.  For its
   proper operation OWAMP requires accurate time of day setting at its
   end points.

   TWAMP [TWAMP] [OnDemand-CV].

4.5.4.3. Lock Instruct

   The Lock Instruct function [Lock-Loop] is a similar protocol that enables measurement of both
   one-way and two-way (round trip) characteristics.

   OWAMP and TWAMP are both comprised of two separate protocols:

   o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop
      test sessions and notify a transport
   path end-point of an administrative need to fetch their results. Continuity Check and
      Connectivity Verification are tested and confirmed by establishing disable the OWAMP/TWAMP Control Protocol TCP connection.

   o OWAMP-Test/TWAMP-Test: transport
   path.  This functionality will generally be used to exchange test packets between two
      measurement nodes. Enables the loss and delay measurement
      functions, as well as detection of other anomalies, such as packet
      duplication and packet reordering.

   It should be noted that while [OWAMP] and [TWAMP] define tools for
   performance measurement, they do not define the accuracy of these
   tools. The accuracy depends on scale, implementation and network
   configurations.

   Alternative protocols for performance monitoring are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet conjunction with
   some intrusive OAM [ITU-T-Y1731].

4.7.2. Control and Test Protocols

   OWAMP and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of function, e.g. Performance measurement, Diagnostic
   testing, to minimize the control protocols side-effect on user data traffic.

4.5.4.4. Lock Reporting

   Lock Reporting is a function used by an end-point of a path to
   initiate, start, and stop test sessions, and for OWAMP report
   to fetch
   results.  The test protocols introduce test packets (which contain
   sequence numbers and timestamps) along its far-end end-point that a lock condition has been affected on
   the IP path under test
   according path.

4.5.4.5. Alarm Reporting

   Alarm Reporting [TP-Fault] provides the means to suppress alarms
   following detection of defect conditions at the server sub-layer.
   Alarm reporting is used by an intermediate point of a schedule, and record statistics path, that
   becomes aware of packet arrival.
   Multiple sessions may be simultaneously defined, each with a session
   identifier, and defining fault on the number of packets path, to be sent, the amount
   of padding report to be added (and thus the packet size), the start time,
   and end-points of
   the send schedule (which can be either path. [TP-OAM-FW] states that this may occur as a constant time between
   test packets or exponentially distributed pseudo-random). Statistics
   recorded conform to result of a
   defect condition discovered at a server sub-layer. This generates an
   Alarm Indication Signal (AIS) that continues until the relevant IPPM RFCs.

   OWAMP and TWAMP test traffic fault is designed with security
   cleared. The consequent action of this function is detailed in mind. Test
   packets are hard
   [TP-OAM-FW].

4.5.4.6. Remote Defect Indication

   Remote Defect Indication (RDI) is used proactively by a path end-
   point to detect because they are simply UDP streams report to its peer end-point that a defect is detected on a
   bidirectional connection between negotiated port numbers, them. [MPLS-TP-OAM] points out that
   this function may be applied to a unidirectional LSP only if there a
   return path exists.  [TP-OAM-FW] points out that this function is
   associated with potentially nothing static in
   the packets.  OWAMP and TWAMP also include optional authentication
   and encryption for both control and test packets.

4.7.3. OWAMP

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and Fetch-Client.  The Session-
   Sender originates test traffic that proactive CC-V function.

4.5.4.7. Client Failure Indication

   Client Failure Indication (CFI) is received by defined in [MPLS-TP-OAM] to allow
   the Session-
   Receiver.  The Server configures and manages propagation information from one edge of the session, as well as
   returning network to the results.  The Control-Client initiates requests for
   test sessions, triggers their start, and may trigger their
   termination.
   other. The Fetch-Client requests the results of information concerns a completed
   session.  Multiple roles may be combined in defect to a single host - for
   example, one host may play client, in the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing case
   that the roles client does not support alarm notification.

4.5.4.8. Performance Monitoring

   The definition of Server and
   Session-Receiver.

   In a typical OWAMP session MPLS performance monitoring was motivated by the Control-Client establishes
   MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for
   MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a TCP
   connection
   performance monitoring profile for MPLS-TP.

4.5.4.8.1. Packet Loss Measurement (LM)

   Packet Loss Measurement is a function used to port 861 of verify the Server, which responds with a server
   greeting message indicating supported security/integrity modes. The
   Control-Client responds with quality of
   the chosen communications mode service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM],
   indicates the
   Server accepts ratio of the modes.  The Control-Client then requests and fully
   describes number of user packets lost to the total
   number of user packets sent during a test session defined time interval.

   There are two possible ways of determining this measurement:

   o Using OAM packets, it is possible to which compute the Server responds with its
   acceptance statistics based
      on a series of OAM packets. This, however, has the disadvantage of
      being artificial, and supporting information.  More than one test session may not be requested with additional messages.  The Control-Client then
   starts a test session and representative since part of the Server acknowledges.  The Session-
   Sender then sends test packets with pseudorandom padding to
      packet loss may be dependent upon packet sizes and upon the
   Session-Receiver until
      implementation of the session is complete or until MEPs that take part in the Control-
   client stops protocol.

   o Sending delimiting messages for the session.  Once finished, the Fetch-Client sends start and end of a
   fetch request to the server, measurement
      period during which responds with an acknowledgement the source and immediately thereafter sink of the result data.

4.7.4. TWAMP

   TWAMP defines path count the following logical roles: session-sender, session-
   reflector, server,
      packets transmitted and control-client.  These are similar to received. After the
   OWAMP roles, except that end delimiter, the Session-Reflector does not collect any
   packet information, and there
      ratio would be calculated by the path OAM entity.

4.5.4.8.2. Packet Delay Measurement (DM)

   Packet Delay Measurement is no need for a Fetch-Client.

   In function that is used to measure one-
   way or two-way delay of a typical TWAMP session the Control-Client establishes packet transmission between a TCP
   connection to port 862 pair of the Server, and mode is negotiated as in
   OWAMP.  The Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them with insertion of
   timestamps.

4.8. TRILL

   The requirements
   end-points of OAM in TRILL are a path (PW, LSP, or Section). Where:

   o One-way packet delay, as defined in [TRILL-OAM]. The main
   challenge in TRILL OAM [IPPM-1DM], is that traffic between RBridges RB1 and RB2
   may be forwarded through more than one path. Thus, an OAM protocol
   between RBridges RB1 and RB2 must be able to monitor all the
   available paths between the two RBridge.

   During time
      elapsed from the writing start of transmission of this document the detailed definition first bit of the
   TRILL OAM tools are still work in progress. This subsection presents
      packet by a source node until the main requirements reception of the last bit of
      that packet by the destination node. Note that one-way delay
      measurement requires the clocks of TRILL OAM.

   The main requirements defined in [TRILL-OAM] are:

   o Continuity Checking (CC) - the TRILL OAM protocol must support a
      function for CC between any two RBridges RB1 and RB2.

   o Connectivity Verification (CV) - connectivity between two RBridges
      RB1 and RB2 can end-points to be verified on a per-flow basis.
      synchronized.

   o Path Tracing - allows an RBridge to trace all Two-way packet delay, as defined in [IPPM-2DM], is the available paths
      to time
      elapsed from the start of transmission of the first bit of the
      packet by a peer RBridge.

   o Performance monitoring - allows an RBridge to monitor source node until the reception of the last bit of the
      loop-backed packet
      loss and by the same source node, when the loopback is
      performed at the packet's destination node. Note that due to
      possible path asymmetry, the one-way packet delay from one end-
      point to a peer RBridge.

4.9. Summary of OAM Mechanisms

   This subsection provides a short summary another is not necessarily equal to half of the two-way
      packet delay.
      As opposed to one-way delay measurement, two-way delay measurement
      does not require the two end-points to be synchronized.

   For each of these two metrics, the OAM mechanism
   categories described in this document.

   A detailed list of DM function allows the RFCs related MEP to each category
   measure the delay, as well as the delay variation. Delay measurement
   is given performed by exchanging timestamped OAM packets between the
   participating MEPs.

4.6. Pseudowire OAM

4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification
   (VCCV)

   VCCV, as defined in
   Appendix A.1.

   +-----------+------------------------------------------+------------+
   | Category  | Description                              | Transport  |
   |           |                                          | Technology |
   +-----------+------------------------------------------+------------+
   |IP Ping    | Ping ([IntHost], [NetTerms]) is [VCCV], provides a simple | IPv4/IPv6  |
   |           | application means for testing reachability that|            |
   |           | uses ICMP Echo messages ([ICMPv4],       |            |
   |           | [ICMPv6]).                               |            |
   +-----------+------------------------------------------+------------+
   |IP         | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6  |
   |Traceroute | an application that allows users to trace|            |
   |           | the path between an IP source end-to-end fault
   detection and an IP  |            |
   |           | destination, i.e., diagnostics tools to identify the nodes |            |
   |           | along the path. If more than one path    |            |
   |           | exists between be extended for PWs (regardless of
   the source and destination|            |
   |           | Traceroute traces *a* path. underlying tunneling technology). The most     |            |
   |           | common implementation of Traceroute      |            |
   |           | uses UDP probe messages, although there  |            |
   |           | are other implementations that use       |            |
   |           | different probes, such as ICMP or TCP.   |            |
   +-----------+------------------------------------------+------------+
   |BFD        | Bidirectional Forwarding Detection (BFD) | generic    |
   |           | is defined in [BFD] as VCCV switching function
   provides a framework control channel associated with each PW. [VCCV] defines
   three Control Channel (CC) types, i.e., three possible methods for a |            |
   |           | lightweight generic
   transmitting and identifying OAM mechanism.  The  |            |
   |           | intention messages:

   o CC Type 1: In-band VCCV, as described in [VCCV], is also referred
      to define a base mechanism  |            |
   |           | that can be used as "PWE3 Control Word with various            |            |
   |           | encapsulation types, network             |            |
   |           | environments, and in various medium      |            |
   |           | types.                                   |            |
   +-----------+------------------------------------------+------------+
   |MPLS OAM   | MPLS LSP Ping, 0001b as defined in [MPLS-OAM], | MPLS       |
   |           | [MPLS-OAM-FW] and [LSP-Ping], is an OAM  |            |
   |           | mechanism for point-to-point and         |            |
   |           | point-to-multipoint MLPS LSPs.           |            |
   |           | It includes two main functions: Ping and |            |
   |           | Traceroute.                              |            |
   |           | first nibble".  It uses the
      PW Associated Channel Header [PW-ACH].

   o CC Type 2: Out-of-band VCCV [VCCV], is noted that while also referred to as "MPLS
      Router Alert Label". In this category     |            |
   |           | focuses on LSP Ping, other OAM mechanisms|            |
   |           | can be used in MPLS networks, e.g., BFD. |            |
   +-----------+------------------------------------------+------------+
   |MPLS-TP OAM| MPLS-TP OAM case the control channel is defined in a set of RFCs. | MPLS-TP    |
   |           | The OAM requirements for created
      by using the MPLS Transport  |            |
   |           | Profile (MPLS-TP) are defined in         |            |
   |           | [MPLS-TP-OAM]. Each of router alert label [RFC3032] immediately above
      the tools in PW label.

   o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW
      Label with TTL == 1", i.e., the  |            |
   |           | OAM toolset control channel is defined in its own RFC, as|            |
   |           | specified in Section A.1.                |            |
   +-----------+------------------------------------------+------------+
   |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire |
   |OAM        | channels that support identified when
      the use value of existing|            |
   |           | IETF OAM tools the TTL field in the PW label is set to be used for a pseudo-  |            |
   |           | wire (PW).  The control channels that are|            |
   |           | defined in [VCCV] and [PW-G-ACh] may be  |            |
   |           | used in conjunction with 1.

   VCCV currently supports the following OAM tools: ICMP Ping, LSP  |            |
   |           | Ping,
   and BFD to perform CC BFD. ICMP and CV       |            |
   |           | functionality.  In addition LSP Ping are IP encapsulated before being sent over
   the channels |            |
   |           | PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of
   encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP header) and provides support to
   signal the AC status. The use of any of the MPLS-TP VCCV control channel provides
   the context, based  |            |
   |           | OAM tools for completing their respective|            |
   |           | OAM functionality for a PW.              |            |
   +-----------+------------------------------------------+------------+
   |OWAMP and  | The One Way Active Measurement Protocol  | IPv4/IPv6  |
   |TWAMP      | (OWAMP) on the MPLS-PW label, required to bind and
   bootstrap the Two Way Active Measure-  |            |
   |           | ment Protocols (TWAMP) are two protocols |            |
   |           | defined in BFD session to a particular pseudo wire (FEC),
   eliminating the IP Performance Metrics    |            |
   |           | (IPPM) working group in need to exchange Discriminator values.

   VCCV consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC label, and (2) switching
   component to cause the IETF. These  |            |
   |           | protocols allow various performance      |            |
   |           | metrics PW payload to be measured, such treated as packet   |            |
   |           | loss, delay and delay variation,         |            |
   |           | duplication and reordering.              |            |
   +-----------+------------------------------------------+------------+
   |TRILL OAM  | a control packet.

   VCCV is not directly dependent upon the presence of a control plane.
   The requirements VCCV capability negotiation may be performed as part of OAM in TRILL are     | TRILL      |
   |           | defined in [TRILL-OAM]. These            |            |
   |           | requirements include continuity checking,|            |
   |           | connectivity verification, path tracing  |            |
   |           | and performance monitoring. During the   |            |
   |           | writing PW
   signaling when LDP is used. In case of this document the detailed    |            |
   |           | definition manual configuration of the TRILL OAM tools        |            |
   |           |
   PW, it is work in progress.                     |            |
   +-----------+------------------------------------------+------------+
              Table 3 Summary the responsibility of OAM-related IETF Mechanisms

4.10. Summary the operator to set consistent
   options at both ends. The manual option was created specifically to
   handle MPLS-TP use cases where no control plane was a requirement.
   However, new use cases such as pure mobile backhaul find this
   functionality useful too.

   The PWE3 working group has conducted an implementation survey of VCCV
   [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in
   practice.

4.6.2. Pseudowire OAM Functions

   Table 4 summarizes the using G-ACh

   As mentioned above, VCCV enables OAM functions that for PWs by using a control
   channel for OAM packets. When PWs are supported used in each of MPLS-TP networks,
   rather than the categories that were analyzed control channels defined in this section. VCCV, the G-ACh can be
   used as an alternative control channel. The columns usage of
   this tables are the typical OAM functions described G-ACh for
   PWs is defined in Section 1.3.

       +-----------+-------+--------+--------+-------+----------+
       |           |Continu|Connecti|Path    |Perform|Other     | [PW-G-ACh].

4.6.3. Attachment Circuit - Pseudowire Mapping

   The PWE3 working group has defined a mapping and notification of
   defect states between a pseudowire (PW) and the Attachment Circuits
   (ACs) of the end-to-end emulated service. This mapping is of key
   importance to the end-to-end functionality. Specifically, the mapping
   is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and
   Section 5.3 of [ATM-L2] for ATM.

4.7. OWAMP and TWAMP

4.7.1. Overview

   The IPPM working group in the IETF defines common criteria and
   metrics for measuring performance of IP traffic ([IPPM-FW]). Some of
   the key RFCs published by this working group have defined metrics for
   measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   and packet loss [IPPM-1LM]. It should be noted that the work of the
   IETF in the context of performance metrics is not limited to IP
   networks; [PM-CONS] presents general guidelines for considering new
   performance metrics.

   The IPPM working group has defined not only metrics for performance
   measurement, but also protocols that define how the measurement is
   carried out. The One-way Active Measurement Protocol [OWAMP] and the
   Two-Way Active Measurement Protocol [TWAMP] define a method and
   protocol for measuring performance metrics in IP networks.

   OWAMP [OWAMP] enables measurement of one-way characteristics of IP
   networks, such as one-way packet loss and one-way delay.  For its
   proper operation OWAMP requires accurate time of day setting at its
   end points.

   TWAMP [TWAMP] is a similar protocol that enables measurement of both
   one-way and two-way (round trip) characteristics.

   OWAMP and TWAMP are both comprised of two separate protocols:

   o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop
      test sessions and to fetch their results. Continuity Check and
      Connectivity Verification are tested and confirmed by establishing
      the OWAMP/TWAMP Control Protocol TCP connection.

   o OWAMP-Test/TWAMP-Test: used to exchange test packets between two
      measurement nodes. Enables the loss and delay measurement
      functions, as well as detection of other anomalies, such as packet
      duplication and packet reordering.

   It should be noted that while [OWAMP] and [TWAMP] define tools for
   performance measurement, they do not define the accuracy of these
   tools. The accuracy depends on scale, implementation and network
   configurations.

   Alternative protocols for performance monitoring are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].

4.7.2. Control and Test Protocols

   OWAMP and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of the control protocols is to
   initiate, start, and stop test sessions, and for OWAMP to fetch
   results.  The test protocols introduce test packets (which contain
   sequence numbers and timestamps) along the IP path under test
   according to a schedule, and record statistics of packet arrival.
   Multiple sessions may be simultaneously defined, each with a session
   identifier, and defining the number of packets to be sent, the amount
   of padding to be added (and thus the packet size), the start time,
   and the send schedule (which can be either a constant time between
   test packets or exponentially distributed pseudo-random). Statistics
   recorded conform to the relevant IPPM RFCs.

   OWAMP and TWAMP test traffic is designed with security in mind. Test
   packets are hard to detect because they are simply UDP streams
   between negotiated port numbers, with potentially nothing static in
   the packets.  OWAMP and TWAMP also include optional authentication
   and encryption for both control and test packets.

4.7.3. OWAMP

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and Fetch-Client.  The Session-
   Sender originates test traffic that is received by the Session-
   Receiver.  The Server configures and manages the session, as well as
   returning the results.  The Control-Client initiates requests for
   test sessions, triggers their start, and may trigger their
   termination.  The Fetch-Client requests the results of a completed
   session.  Multiple roles may be combined in a single host - for
   example, one host may play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing the roles of Server and
   Session-Receiver.

   In a typical OWAMP session the Control-Client establishes a TCP
   connection to port 861 of the Server, which responds with a server
   greeting message indicating supported security/integrity modes. The
   Control-Client responds with the chosen communications mode and the
   Server accepts the modes.  The Control-Client then requests and fully
   describes a test session to which the Server responds with its
   acceptance and supporting information.  More than one test session
   may be requested with additional messages.  The Control-Client then
   starts a test session and the Server acknowledges.  The Session-
   Sender then sends test packets with pseudorandom padding to the
   Session-Receiver until the session is complete or until the Control-
   client stops the session.  Once finished, the Fetch-Client sends a
   fetch request to the server, which responds with an acknowledgement
   and immediately thereafter the result data.

4.7.4. TWAMP

   TWAMP defines the following logical roles: session-sender, session-
   reflector, server, and control-client.  These are similar to the
   OWAMP roles, except that the Session-Reflector does not collect any
   packet information, and there is no need for a Fetch-Client.

   In a typical TWAMP session the Control-Client establishes a TCP
   connection to port 862 of the Server, and mode is negotiated as in
   OWAMP.  The Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them with insertion of
   timestamps.

4.8. TRILL

   The requirements of OAM in TRILL are defined in [TRILL-OAM]. The
   challenge in TRILL OAM, much like in MPLS networks, is that traffic
   between RBridges RB1 and RB2 may be forwarded through more than one
   path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able
   to monitor all the available paths between the two RBridge.

   During the writing of this document the detailed definition of the
   TRILL OAM tools are still work in progress. This subsection presents
   the main requirements of TRILL OAM.

   The main requirements defined in [TRILL-OAM] are:

   o Continuity Checking (CC) - the TRILL OAM protocol must support a
      function for CC between any two RBridges RB1 and RB2.

   o Connectivity Verification (CV) - connectivity between two RBridges
      RB1 and RB2 can be verified on a per-flow basis.

   o Path Tracing - allows an RBridge to trace all the available paths
      to a peer RBridge.

   o Performance monitoring - allows an RBridge to monitor the packet
      loss and packet delay to a peer RBridge.

4.9. Summary of OAM Tools

   This subsection provides a short summary of each of the OAM tool
   categories described in this document.

   A detailed list of the RFCs related to each category is given in
   Appendix A.1.

   +-----------+------------------------------------------+------------+
   | Category  | Description                              | Transport  |
   |           |                                          | Technology |
   +-----------+------------------------------------------+------------+
   |IP Ping    | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6  |
   |           | application for testing reachability that|            |
   |           | uses ICMP Echo messages ([ICMPv4],       |            |
   |           | [ICMPv6]).                               |            |
   +-----------+------------------------------------------+------------+
   |IP         | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6  |
   |Traceroute | an application that allows users to trace|            |
   |           | the path between an IP source and an IP  |            |
   |           | destination, i.e., to identify the nodes |            |
   |           | along the path. If more than one path    |            |
   |           | exists between the source and destination|            |
   |           | Traceroute traces *a* path. The most     |            |
   |           | common implementation of Traceroute      |            |
   |           | uses UDP probe messages, although there  |            |
   |           | are other implementations that use       |            |
   |           | different probes, such as ICMP or TCP.   |            |
   +-----------+------------------------------------------+------------+
   |BFD        | Bidirectional Forwarding Detection (BFD) | generic    |
   |           | is defined in [BFD] as a framework for a |            |
   |           | lightweight generic OAM tool.  The       |            |
   |           | intention is to define a base tool       |            |
   |           | that can be used with various            |            |
   |           | encapsulation types, network             |            |
   |           | environments, and in various medium      |            |
   |           | types.                                   |            |
   +-----------+------------------------------------------+------------+
   |MPLS OAM   | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS       |
   |           | [MPLS-OAM-FW] and [LSP-Ping], is an OAM  |            |
   |           | tool for point-to-point and              |            |
   |           | point-to-multipoint MLPS LSPs.           |            |
   |           | It includes two main functions: Ping and |            |
   |           | Traceroute.                              |            |
   |           | It is noted that while this category     |            |
   |           | focuses on LSP Ping, other OAM tools     |            |
   |           | can be used in MPLS networks, e.g., BFD. |            |
   +-----------+------------------------------------------+------------+
   |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP    |
   |           | The OAM requirements for MPLS Transport  |            |
   |           | Profile (MPLS-TP) are defined in         |            |
   |           | [MPLS-TP-OAM]. Each of the tools in the  |            |
   |           | OAM toolset is defined in its own RFC, as|            |
   |           | specified in Section A.1.                |            |
   +-----------+------------------------------------------+------------+
   |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire |
   |OAM        | channels that support the use of existing|            |
   |           | IETF OAM tools to be used for a pseudo-  |            |
   |           | wire (PW).  The control channels that are|            |
   |           | defined in [VCCV] and [PW-G-ACh] may be  |            |
   |           | used in conjunction with ICMP Ping, LSP  |            |
   |           | Ping, and BFD to perform CC and CV       |            |
   |           | functionality.  In addition the channels |            |
   |           | support use of any of the MPLS-TP based  |            |
   |           | OAM tools for completing their respective|            |
   |           | OAM functionality for a PW.              |            |
   +-----------+------------------------------------------+------------+
   |OWAMP and  | The One Way Active Measurement Protocol  | IPv4/IPv6  |
   |TWAMP      | (OWAMP) and the Two Way Active Measure-  |            |
   |           | ment Protocols (TWAMP) are two protocols |            |
   |           | defined in the IP Performance Metrics    |            |
   |           | (IPPM) working group in the IETF. These  |            |
   |           | protocols allow various performance      |            |
   |           | metrics to be measured, such as packet   |            |
   |           | loss, delay and delay variation,         |            |
   |           | duplication and reordering.              |            |
   +-----------+------------------------------------------+------------+
   |TRILL OAM  | The requirements of OAM in TRILL are     | TRILL      |
   |           | defined in [TRILL-OAM]. These            |            |
   |           | requirements include continuity checking,|            |
   |           | connectivity verification, path tracing  |            |
   |           | and performance monitoring. During the   |            |
   |           | writing of this document the detailed    |            |
   |           | definition of the TRILL OAM tools        |            |
   |           | is work in progress.                     |            |
   +-----------+------------------------------------------+------------+
                 Table 3 Summary of OAM-related IETF Tools

4.10. Summary of OAM Functions

   Table 4 summarizes the OAM functions that are supported in each of
   the categories that were analyzed in this section. The columns of
   this tables are the typical OAM functions described in Section 1.3.

       +-----------+-------+--------+--------+-------+----------+
       |           |Continu|Connecti|Path    |Perform|Other     |
       |           |ity    |vity    |Discover|ance   |Function  |
       |           |Check  |Verifica|y       |Monitor|s         |
       | Category  |       |tion    |        |ing    |          |
       +-----------+-------+--------+--------+-------+----------+
       |IP Ping    |Echo   |        |        |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |IP         |       |        |Tracerou|       |          |
       |Traceroute |       |        |te      |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |BFD        |BFD    |BFD     |        |       |RDI usi-  |
       |           |Control|Control |        |       |ng BFD    |
       |           |/ Echo |        |        |       |Control   |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |MPLS OAM   |       |"Ping"  |"Tracero|       |          |
       |(LSP Ping) |       |mode    |ute"    |       |          |
       |           |       |        |mode    |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |MPLS-TP    |CC     |CV/pro- |Route   |-LM    |-Diagnos- |
       |OAM        |       |active  |Tracing |-DM    | tic Test |
       |           |       |or on-  |        |       |-Lock     |
       |           |       |demand  |        |       |-Alarm    |
       |           |       |        |        |       |Reporting |
       |           |       |        |        |       |-Client   |
       |           |       |        |        |       |Failure   |
       |           |       |        |        |       |Indication|
       |           |       |        |        |       |-RDI      |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |Pseudowire |BFD    |-BFD    |LSP-Ping|       |          |
       |OAM        |       |-ICMP   |        |       |          |
       |           |       | Ping   |        |       |          |
       |           |       |-LSP-   |        |       |          |
       |           |       | Ping   |        |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |OWAMP and  | - control      |        |-Delay |          |
       |TWAMP      |   protocol     |        | measur|          |
       |           |                |        | ement |          |
       |           |                |        |-Packet|          |
       |           |                |        | loss  |          |
       |           |                |        | measur|          |
       |           |                |        | ement |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |TRILL OAM  |CC     |CV      |Path    |-Delay |          |
       |           |       |        |tracing | measur|          |
       |           |       |        |        | ement |          |
       |           |       |        |        |-Packet|          |
       |           |       |        |        | loss  |          |
       |           |       |        |        | measur|          |
       |           |       |        |        | ement |          |
       +-----------+-------+--------+--------+-------+----------+
         Table 4 Summary of the OAM Functionality in IETF OAM Mechanisms

5. Security Considerations OAM Functionality in IETF OAM Tools

5. Security Considerations

   This memo presents an overview of existing OAM tools, and proposes
   no new OAM tools. Therefore, this document introduces no security
   considerations. However, the OAM tools reviewed in this document can
   and do present security issues. The reader is encouraged to review
   the Security Considerations section of each document referenced by
   this memo.

6. IANA Considerations

   There are no new IANA considerations implied by this document.

7. Acknowledgments

   The authors gratefully acknowledge Sasha Vainshtein, Carlos
   Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other
   members of the OPSAWG mailing list for their helpful comments.

   This memo presents an overview document was prepared using 2-Word-v2.0.template.dot.

8. References

8.1. Informative References

   [ATM-L2]      Singh, S., Townsley, M., and C. Pignataro,
                 "Asynchronous Transfer Mode (ATM) over Layer 2
                 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May
                 2006.

   [BFD]         Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD)", RFC 5880, June 2010.

   [BFD-Gen]     Katz, D., Ward, D., "Generic Application of existing OAM mechanisms,
                 Bidirectional Forwarding Detection (BFD)", RFC 5882,
                 June 2010.

   [BFD-IP]      Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for IPv4 and
   proposes no new OAM mechanisms. Therefore, this document introduces
   no security considerations. However, IPv6 (Single Hop)", RFC 5881, June
                 2010.

   [BFD-LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,
                 G., "Bidirectional Forwarding Detection (BFD) for MPLS
                 Label Switched Paths (LSPs)", RFC 5884, June 2010.

   [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for Multihop Paths", RFC 5883, June 2010.

   [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional Forwarding
                 Detection (BFD) for the OAM mechanism reviewed in
   this document can Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV)", RFC 5885, June
                 2010.

   [Comp]        Bonaventure, O., "Computer Networking: Principles,
                 Protocols and Practice", 2008.

   [Cont]        Dugal, D., Pignataro, C., Dunn, R., "Protecting the
                 Router Control Plane", RFC 6192, March 2011.

   [Dup]         Uijterwaal, H., "A One-Way Packet Duplication Metric",
                 RFC 5560, May 2009.

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

   [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP
                 Extensions for Multiprotocol Label Switching", RFC
                 4950, August 2007.

   [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,
                 JR., "Extending ICMP for Interface and do present security issues. The reader is
   encouraged to review the Security Considerations section of each
   document referenced by this memo.

6. IANA Considerations

   There are no new IANA considerations implied by this document.

7. Acknowledgments

   The authors gratefully acknowledge Sasha Vainshtein, Carlos Next-Hop
                 Identification", RFC 5837, April 2010.

   [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., Pignataro, David Harrington, Dan Romascanu, Ron Bonica C.,
                 "Extended ICMP to Support Multi-Part Messages", RFC
                 4884, April 2007.

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

   [ICMPv6]      Conta, A., Deering, S., and other
   members of M. Gupta, "Internet Control
                 Message Protocol (ICMPv6) for the OPSAWG mailing list Internet Protocol
                 Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [IEEE802.1Q]  IEEE 802.1Q, "IEEE Standard for their helpful comments.

   This document was prepared using 2-Word-v2.0.template.dot.

8. References

8.1. Informative References

   [LSP-Ping]    Kompella, K., Swallow, Local and metropolitan
                 area networks - Media Access Control (MAC) Bridges and
                 Virtual Bridged Local Area Networks", October 2012.

   [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology -
                 Local and metropolitan area networks - Carrier sense
                 multiple access with collision detection (CSMA/CD)
                 access method and physical layer specifications",
                 clause 57, December 2008.

   [IntHost]     Braden, R., "Requirements for Internet Hosts --
                 Communication Layers", RFC 1122, October 1989.

   [IPPM-1DM]    Almes, G., "Detecting Multi-Protocol
                 Label Switched (MPLS) Data Plane Failures", Kalidindi, S., Zekauskas, M., "A One-way
                 Delay Metric for IPPM", RFC 4379,
                 February 2006.

   [MPLS-OAM]    Nadeau, T., Morrow, 2679, September 1999.

   [IPPM-1LM]    Almes, G., Kalidindi, S., Zekauskas, M., Swallow, "A One-way
                 Packet Loss Metric for IPPM", RFC 2680, September
                 1999.

   [IPPM-2DM]    Almes, G., Allan, D.,
                 Matsushima, Kalidindi, S., "Operations and Management (OAM)
                 Requirements Zekauskas, M., "A Round-trip
                 Delay Metric for Multi-Protocol Label Switched (MPLS)
                 Networks", IPPM", RFC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework 2681, September 1999.

   [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics for Multi-Protocol
                 Label Switching (MPLS) Operations and Management
                 (OAM)", Measuring
                 Connectivity", RFC 4378, February 2006.

   [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' 2678, September 1999.

   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                 "Framework for
                 Multiprotocol Label Switching Architecture (MPLS)
                 Operation IP Performance Metrics", RFC 2330, May
                 1998.

   [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
                 Administration and Maintenance (OAM) Functions", RFC 3429,
                 November 2002.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements mechanism for
                 OAM MPLS-TP
                 in MPLS Packet Transport Networks", RFC 5860, May 2010.

   [G-ACh]       Bocci, M., Vigoureux, Network (PTN)", November 2012.

   [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
                 administration and maintenance mechanisms for MPLS-TP
                 networks using the tools defined for MPLS", November
                 2012.

   [ITU-T-CT]    Betts, M., Bryant, S., "MPLS "Allocation of a Generic Associated Channel", RFC 5586, June 2009.

   [VCCV]        Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV): A Control Channel
                 Type for Pseudowires", ITU-T MPLS Transport Profile Operation,
                 Maintenance, and Administration (MPLS-TP OAM)", RFC 5085, December 2007.

   [PW-ACH]      Bryant, S., Swallow, G., Martini, L., McPherson, D.,
                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                 6671, November 2012.

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
                 transport equipment - Description methodology and
                 generic functionality", January 2009.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance
                 mechanism for Use over an MPLS PSN", RFC 4385, networks", February 2006.

   [ATM-L2]      Singh, S., Townsley, M., 2004.

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and C. Pignataro,
                 "Asynchronous Transfer Mode (ATM) over Layer 2
                 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May
                 2006.
                 Mechanisms for Ethernet-based Networks", July 2011.

   [ITU-Terms]   ITU-R/ITU-T Terms and Definitions, online, 2013.

   [L2TP-EC]     McGill, N. and C. Pignataro, "Layer 2 Tunneling
                 Protocol Version 3 (L2TPv3) Extended Circuit Status
                 Values", RFC 5641, August 2009.

   [PW-MAP]      Aissaoui, M., Busschbach, P., Martini, L., Morrow,

   [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux,
                 M.,
                 Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
                 Operations, Administration, Dai, X., "MPLS Transport Profile Lock Instruct and Maintenance (OAM)
                 Message Mapping",
                 Loopback Functions", RFC 6310, July 6435, November 2011.

   [ICMPv4]      Postel, J., "Internet Control Message Protocol", STD 5,

   [LSP-Ping]    Kompella, K., Swallow, G., "Detecting Multi-Protocol
                 Label Switched (MPLS) Data Plane Failures", RFC 792, September 1981.

   [ICMPv6]      Conta, 4379,
                 February 2006.

   [Mng]         Farrel, A., Deering, "Inclusion of Manageability Sections in
                 Path Computation Element (PCE) Working Group Drafts",
                 RFC 6123, February 2011.

   [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and M. Gupta, "Internet Control
                 Message Protocol (ICMPv6) for the Internet Protocol
                 Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [IntHost]     Braden, R., "Requirements Delay
                 Measurement for Internet Hosts --
                 Communication Layers", RFC 1122, October 1989.

   [NetTerms]    Jacobsen, O., Lynch, D., "A Glossary of Networking
                 Terms", MPLS Networks", RFC 1208, March 1991.

   [MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., 6374, September
                 2011.

   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
                 Matsushima, S., "Operations and Management (OAM)
                 Requirements for
                 Point-to-Multipoint MPLS Multi-Protocol Label Switched (MPLS)
                 Networks", RFC 4687,
                 September 4377, February 2006.

   [ICMP-Ext]    Bonica, R., Gan, D., Tappan,

   [MPLS-OAM-FW] Allan, D., Pignataro, C., "ICMP
                 Extensions Nadeau, T., "A Framework for Multiprotocol Multi-Protocol
                 Label Switching", RFC
                 4950, August 2007.

   [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., Pignataro, C.,
                 "Extended ICMP to Support Multi-Part Messages", Switching (MPLS) Operations and Management
                 (OAM)", RFC
                 4884, April 2007.

   [ICMP-Int]    Atlas, 4378, February 2006.

   [MPLS-P2MP]   Yasukawa, S., Farrel, A., Bonica, R., Pignataro, C., Shen, N., Rivers,
                 JR., "Extending ICMP for Interface King, D., Nadeau, T.,
                 "Operations and Next-Hop
                 Identification", Management (OAM) Requirements for
                 Point-to-Multipoint MPLS Networks", RFC 5837, April 4687,
                 September 2006.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for
                 OAM in MPLS Transport Networks", RFC 5860, May 2010.

   [TCPIP-Tools] Kessler, G., Shepard, S.,

   [NetTerms]    Jacobsen, O., Lynch, D., "A Primer On Internet and
                 TCP/IP Tools and Utilities", Glossary of Networking
                 Terms", RFC 2151, June 1997. 1208, March 1991.

   [NetTools]    Enger, R., Reynolds, J., "FYI on a Network Management
                 Tool Catalog: Tools for Monitoring and Debugging
                 TCP/IP Internets and Interconnected Devices", RFC
                 1470, June 1993.

   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                 "Framework

   [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of the OAM Tool
                 Set for IP Performance Metrics",  MPLS based Transport Networks", RFC 2330, May
                 1998.

   [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics 6669,
                 July 2012.

   [OAM-Def]     Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                 D., Mansfield, S., "Guidelines for Measuring
                 Connectivity", the use of the OAM
                 acronym in the IETF ", RFC 2678, September 1999.

   [IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
                 Delay Metric 6291, June 2011.

   [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' for IPPM",
                 Multiprotocol Label Switching Architecture (MPLS)
                 Operation and Maintenance (OAM) Functions", RFC 2679, September 1999.

   [IPPM-1LM]    Almes, G., Kalidindi, 3429,
                 November 2002.

   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Zekauskas, M., "A One-way
                 Packet Loss Metric for IPPM", Aggarwal, R. "MPLS
                 On-Demand Connectivity Verification and Route
                 Tracing", RFC 2680, September
                 1999.

   [IPPM-2DM]    Almes, G., Kalidindi, 6426, November 2011.

   [OWAMP]       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
                 Zekauskas, M., "A Round-trip
                 Delay Metric for IPPM", One-way Active Measurement Protocol
                 (OWAMP)", RFC 2681, 4656, September 1999. 2006.

   [PARIS]       Brice Augustin, Timur Friedman and Renata Teixeira,
                 "Measuring Load-balanced Paths in the Internet", IMC,
                 2007.

   [PM-CONS]     Clark, A. and B. Claise, "Guidelines for Considering
                 New Performance Metric Development", BCP 170, RFC
                 6390, October 2011.

   [OWAMP]       Shalunov,

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

   [PW-G-ACh]    Li, H., Martini, L., He, J., and
                 Zekauskas, Huang, F., "Using the
                 Generic Associated Channel Label for Pseudowire in the
                 MPLS Transport Profile (MPLS-TP)", RFC 6423, November
                 2011.

   [PW-MAP]      Aissaoui, M., "A One-way Active Measurement Protocol
                 (OWAMP)", Busschbach, P., Martini, L., Morrow, M.,
                 Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
                 Operations, Administration, and Maintenance (OAM)
                 Message Mapping", RFC 4656, September 2006.

   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., 6310, July 2011.

   [PW-Map]      M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.
                 Nadeau, "Pseudowire (PW) Operations, Administration,
                 and
                 Babiarz, J., "A Two-Way Active Measurement Protocol
                 (TWAMP)", Maintenance (OAM) Message Mapping", RFC 5357, October 2008. 6310, July
                 2011.

   [Reorder]     Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
                 S., and J. Perser, "Packet Reordering Metrics", RFC
                 4737, November 2006.

   [Dup]         Uijterwaal, H., "A One-Way Packet Duplication Metric",
                 RFC 5560, May 2009.

   [BFD]         Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD)", RFC 5880, June 2010.

   [BFD-IP]      Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
                 2010.

   [BFD-Gen]     Katz, D., Ward, D., "Generic Application of
                 Bidirectional Forwarding Detection (BFD)", RFC 5882,
                 June 2010.

   [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for Multihop Paths", RFC 5883, June 2010.

   [BFD-LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,
                 G., "Bidirectional Forwarding Detection (BFD) for MPLS
                 Label Switched Paths (LSPs)", RFC 5884, June 2010.

   [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional Forwarding
                 Detection (BFD) for the Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV)",

   [Signal]      Yasukawa, S., "Signaling Requirements for Point-to-
                 Multipoint Traffic-Engineered MPLS Label Switched
                 Paths (LSPs)", RFC 5885, June
                 2010.

   [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Administration 4461, April 2006.

   [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and
                 Maintenance Framework for MPLS-based Transport
                 Networks ",
                 TCP/IP Tools and Utilities", RFC 6371, September 2011. 2151, June 1997.

   [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., "Proactive
                 Connectivity Verification, Continuity Check and Remote
                 Defect indication for MPLS Transport Profile", RFC
                 6428, November 2011.

   [OnDemand-CV] Gray, E., Bahadur, N.,

   [TP-Fault]    Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., Aggarwal, R.
                 "MPLS
                 On-Demand Connectivity Verification Fault Management Operations, Administration, and Route
                 Tracing",
                 Maintenance (OAM)", RFC 6426, 6427, November 2011.

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

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

   [TP-Fault]    Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
                 "MPLS Fault Management Operations, Administration, and
                 Maintenance (OAM)", RFC 6427, November 2011.

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

   [ITU-T-CT]    Betts, M., "Allocation of a Generic Associated Channel
                 Type for ITU-T MPLS Transport Profile Operation,
                 Maintenance, and

   [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Administration (MPLS-TP OAM)", RFC
                 6671, November 2012.

   [PW-Map]      M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.
                 Nadeau, "Pseudowire (PW) Operations, Administration, and
                 Maintenance (OAM) Message Mapping", RFC 6310, July
                 2011.

   [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F., "Using the
                 Generic Associated Channel Label Framework for Pseudowire in the
                 MPLS MPLS-based Transport Profile (MPLS-TP)", RFC 6423, November
                 2011.

   [OAM-Def]     Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                 D., Mansfield, S., "Guidelines for the use of the OAM
                 acronym in the IETF
                 Networks ", RFC 6291, June 2011.

   [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of the OAM Tool
                 Set for  MPLS based Transport Networks", RFC 6669,
                 July 2012. 6371, September 2011.

   [TP-Term]     Van Helvoort, H., Andersson, L., Sprecher, N., "A
                 Thesaurus for the Terminology used in Multiprotocol
                 Label Switching Transport Profile (MPLS-TP)
                 drafts/RFCs and ITU-T's Transport Network
                 Recommendations", work-in-progress, draft-ietf-mpls-
                 tp-rosetta-stone, July 2012.

   [Cont]        Dugal, D., Pignataro, C., Dunn, R., "Protecting the
                 Router Control Plane", RFC 6192, March 2011.

   [Mng]         Farrel, A., "Inclusion of Manageability Sections in
                 Path Computation Element (PCE) Working Group Drafts",
                 RFC 6123, February 2011.

   [TRILL-OAM]   Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve,
                 R., "Requirements for Operations, Administration, and
                 Maintenance (OAM) in Transparent Interconnection of
                 Lots of Links (TRILL)", RFC 6905, March 2013.

   [IEEE802.1Q]  IEEE 802.1Q, "IEEE Standard for Local and metropolitan
                 area networks - Media Access Control (MAC) Bridges

   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
                 Virtual Bridged Local Area Networks",
                 Babiarz, J., "A Two-Way Active Measurement Protocol
                 (TWAMP)", RFC 5357, October 2012.

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
                 Mechanisms for Ethernet-based Networks", July 2011.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance
                 mechanism for MPLS networks", February 2004.

   [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology -
                 Local and metropolitan area networks - Carrier sense
                 multiple access with collision detection (CSMA/CD)
                 access method and physical layer specifications",
                 clause 57, December 2008.

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
                 transport equipment - Description methodology and
                 generic functionality", January 2009.

   [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
                 administration and maintenance mechanisms for MPLS-TP
                 networks using the tools defined for MPLS", November
                 2012.

   [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
                 Administration and Maintenance mechanism

   [VCCV]        Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV): A Control Channel
                 for MPLS-TP
                 in Packet Transport Network (PTN)", November 2012. Pseudowires", RFC 5085, December 2007.

   [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) &
                 Virtual Circuit Connectivity Verification (VCCV)
                 Implementation Survey Results", work-in-progress,
                 draft-ietf-pwe3-vccv-impl-survey-results, August 2013.

Appendix A.                 List of OAM Documents

A.1. List of IETF OAM Documents

   Table 5 summarizes the OAM related RFCs published by the IETF.

   It is important to note that the table lists various RFCs that are
   different by nature. For example, some of these documents define OAM
   tools or OAM protocols (or both), while others define protocols that
   are not strictly OAM-related, but are used by OAM tools. The table
   also includes memos RFCs that define the requirements or the framework of
   OAM in the context of a specific transport technology, or describe
   how to use existing OAM tools in a new transport technology. context (e.g., MPLS-TP).

   The RFCs in the table are categorized in a few sets as defined in
   Section 1.3.

   +-----------+--------------------------------------+----------+
   | Category  | Title                                | RFC      |
   +-----------+--------------------------------------+----------+
   |IP Ping    | Requirements for Internet Hosts --   | RFC 1122 |
   |           | Communication Layers [IntHost]       |          |
   |           +--------------------------------------+----------+
   |           | A Glossary of Networking Terms       | RFC 1208 |
   |           | [NetTerms]                           |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 792  |
   |           | [ICMPv4]                             |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) for the Internet Protocol   |          |
   |           | Version 6 (IPv6) Specification       |          |
   |           | [ICMPv6]                             |          |
   +-----------+--------------------------------------+----------+
   |IP         | A Primer On Internet and TCP/IP      | RFC 2151 |
   |Traceroute | Tools and Utilities [TCPIP-Tools]    |          |
   |           +--------------------------------------+----------+
   |           | FYI on a Network Management Tool     | RFC 1470 |
   |           | Catalog: Tools for Monitoring and    |          |
   |           | Debugging TCP/IP Internets and       |          |
   |           | Interconnected Devices [NetTools]    |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 792  |
   |           | [ICMPv4]                             |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) for the Internet Protocol   |          |
   |           | Version 6 (IPv6) Specification       |          |
   |           | [ICMPv6]                             |          |
   |           +--------------------------------------+----------+
   |           | Extended ICMP to Support Multi-Part  | RFC 4884 |
   |           | Messages [ICMP-MP]                   |          |
   |           +--------------------------------------+----------+
   |           | Extending ICMP for Interface and     | RFC 5837 |
   |           | Next-Hop Identification [ICMP-Int]   |          |
   +-----------+--------------------------------------+----------+
   |BFD        | Bidirectional Forwarding Detection   | RFC 5880 |
   |           | [BFD]                                |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5881 |
   |           | (BFD) for IPv4 and IPv6 (Single Hop) |          |
   |           | [BFD-IP]                             |          |
   |           +--------------------------------------+----------+
   |           | Generic Application of Bidirectional | RFC 5882 |
   |           | Forwarding Detection [BFD-Gen]       |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5883 |
   |           | (BFD) for Multihop Paths [BFD-Multi] |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5884 |
   |           | for MPLS Label Switched Paths (LSPs) |          |
   |           | [BFD-LSP]                            |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |          |
   |           | Connectivity Verification (VCCV)     |          |
   |           | [BFD-VCCV]                           |          |
   +-----------+--------------------------------------+----------+
   |MPLS OAM   | Operations and Management (OAM)      | RFC 4377 |
   |           | Requirements for Multi-Protocol Label|          |
   |           | Switched (MPLS) Networks [MPLS-OAM]  |          |
   |           +--------------------------------------+----------+
   |           | A Framework for Multi-Protocol       | RFC 4378 |
   |           | Label Switching (MPLS) Operations    |          |
   |           | and Management (OAM) [MPLS-OAM-FW]   |          |
   |           +--------------------------------------+----------+
   |           | Detecting Multi-Protocol Label       | RFC 4379 |
   |           | Switched (MPLS) Data Plane Failures  |          |
   |           | [LSP-Ping]                           |          |
   |           +--------------------------------------+----------+
   |           | Operations and Management (OAM)      | RFC 4687 |
   |           | Requirements for Point-to-Multipoint |          |
   |           | MPLS Networks [MPLS-P2MP]            |          |
   |           +--------------------------------------+----------+
   |           | ICMP Extensions for Multiprotocol    | RFC 4950 |
   |           | Label Switching [ICMP-Ext]           |          |
   +-----------+--------------------------------------+----------+
   |MPLS-TP    | Requirements for OAM in MPLS-TP      | RFC 5860 |
   |OAM        | [MPLS-TP-OAM]                        |          |
   |           +--------------------------------------+----------+
   |           | MPLS Generic Associated Channel      | RFC 5586 |
   |           | [G-ACh]                              |          |
   |           +--------------------------------------+----------+
   |           | MPLS-TP OAM Framework                | RFC 6371 |
   |           | [TP-OAM-FW]                          |          |
   |           +--------------------------------------+----------+
   |           | Proactive Connectivity Verification, | RFC 6428 |
   |           | Continuity Check, and Remote Defect  |          |
   |           | Indication for the MPLS Transport    |          |
   |           | Profile [TP-CC-CV]                   |          |
   |           +--------------------------------------+----------+
   |           | MPLS On-Demand Connectivity          | RFC 6426 |
   |           | Verification and Route Tracing       |          |
   |           | [OnDemand-CV]                        |          |
   |           +--------------------------------------+----------+
   |           | MPLS Fault Management Operations,    | RFC 6427 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | [TP-Fault]                           |          |
   |           +--------------------------------------+----------+
   |           | MPLS Transport Profile Lock Instruct | RFC 6435 |
   |           | and Loopback Functions [Lock-Loop]   |          |
   |           +--------------------------------------+----------+
   |           | Packet Loss and Delay Measurement for| RFC 6374 |
   |           | MPLS Networks [MPLS-LM-DM]           |          |
   |           +--------------------------------------+----------+
   |           | A Packet Loss and Delay Measurement  | RFC 6375 |
   |           | Profile for MPLS-Based Transport     |          |
   |           | Networks [TP-LM-DM]                  |          |
   +-----------+--------------------------------------+----------+
   |Pseudowire | Pseudowire Virtual Circuit           | RFC 5085 |
   |OAM        | Connectivity Verification (VCCV):    |          |
   |           | A Control Channel for Pseudowires    |          |
   |           | [VCCV]                               |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |          |
   |           | Connectivity Verification (VCCV)     |          |
   |           | [BFD-VCCV]                           |          |
   |           +--------------------------------------+----------+
   |           | Using the Generic Associated Channel | RFC 6423 |
   |           | Label for Pseudowire in the MPLS     |          |
   |           | Transport Profile (MPLS-TP)          |          |
   |           | [PW-G-ACh]                           |          |
   |           +--------------------------------------+----------+
   |           | Pseudowire (PW) Operations,          | RFC 6310 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | Message Mapping [PW-Map]             |          |
   +-----------+--------------------------------------+----------+
   |OWAMP and  | A One-way Active Measurement Protocol| RFC 4656 |
   |TWAMP      | [OWAMP]                              |          |
   |           +--------------------------------------+----------+
   |           | A Two-Way Active Measurement Protocol| RFC 5357 |
   |           | [TWAMP]                              |          |
   |           +--------------------------------------+----------+
   |           | Framework for IP Performance Metrics | RFC 2330 |
   |           | [IPPM-FW]                            |          |
   |           +--------------------------------------+----------+
   |           | IPPM Metrics for Measuring           | RFC 2678 |
   |           | Connectivity [IPPM-Con]              |          |
   |           +--------------------------------------+----------+
   |           | A One-way Delay Metric for IPPM      | RFC 2679 |
   |           | [IPPM-1DM]                           |          |
   |           +--------------------------------------+----------+
   |           | A One-way Packet Loss Metric for IPPM| RFC 2680 |
   |           | [IPPM-1LM]                           |          |
   |           +--------------------------------------+----------+
   |           | A Round-trip Delay Metric for IPPM   | RFC 2681 |
   |           | [IPPM-2DM]                           |          |
   |           +--------------------------------------+----------+
   |           | Packet Reordering Metrics            | RFC 4737 |
   |           | [Reorder]                            |          |
   |           +--------------------------------------+----------+
   |           | A One-Way Packet Duplication Metric  | RFC 5560 |
   |           | [Dup]                                |          |
   +-----------+--------------------------------------+----------+
   |TRILL OAM  | Requirements for Operations,         | RFC 6905 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | in Transparent Interconnection of    |          |
   |           | Lots of Links (TRILL)                |          |
   +-----------+--------------------------------------+----------+
                 Table 5 Summary of IETF OAM Related RFCs

A.2. List of Selected Non-IETF OAM Documents

   In addition to the OAM mechanisms tools defined by the IETF, the IEEE and ITU-T
   have also defined various OAM mechanisms tools that focus on Ethernet, and
   various other transport network environments. These various mechanisms, tools,
   defined by the three standard organizations, are often tightly
   coupled, and have had a mutual effect on each other. The ITU-T and
   IETF have both defined OAM mechanisms tools for MPLS LSPs, [ITU-T-Y1711] and
   [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to
   some extent linked to IETF OAM mechanisms tools listed above and are mentioned
   here only as reference material:

   o OAM mechanisms tools for Layer 2 have been defined by the ITU-T in
      [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE
      802.3 standard defines OAM for one-hop Ethernet links
      [IEEE802.3ah].

   o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and
      MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].

   It should be noted that these non-IETF documents deal in many cases
   with OAM functions below the IP layer (Layer 2, Layer 2.5) and in
   some cases operators use a multi-layered OAM approach, which is a
   function of the way their networks are designed.

   Table 6 summarizes some of the main OAM standards published by non-
   IETF standard organizations. This document focuses on IETF OAM
   standards, but these non-IETF standards are referenced in this
   document where relevant.

   +-----------+--------------------------------------+---------------+
   |           | Title                                |Standard/Draft |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operation & Maintenance mechanism    | ITU-T Y.1711  |
   |MPLS OAM   | for MPLS networks [ITU-T-Y1711]      |               |
   |           +--------------------------------------+---------------+
   |           | Assignment of the 'OAM Alert Label'  | RFC 3429      |
   |           | for Multiprotocol Label Switching    |               |
   |           | Architecture (MPLS) Operation and    |               |
   |           | Maintenance (OAM) Functions          |               |
   |           | [OAM-Label]                          |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T Y.1711.                    |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operations, administration and       |ITU-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP   |               |
   |           | networks using the tools defined for |               |
   |           | MPLS [ITU-G8113.2]                   |               |
   |           |                                      |               |
   |           |  Note: this document describes the   |               |
   |           |  OAM toolset defined by the IETF for |               |
   |           |  MPLS-TP, whereas ITU-T G.8113.1     |               |
   |           |  describes the OAM toolset defined   |               |
   |           |  by the ITU-T.                       |               |
   |           +--------------------------------------+---------------+
   |           | Operations, Administration and       |ITU-T G.8113.1 |
   |           | Maintenance mechanism for MPLS-TP in |               |
   |           | Packet Transport Network (PTN)       |               |
   |           +--------------------------------------+---------------+
   |           | Allocation of a Generic Associated   | RFC 6671      |
   |           | Channel Type for ITU-T MPLS Transport|               |
   |           | Profile Operation, Maintenance, and  |               |
   |           | Administration (MPLS-TP OAM)         |               |
   |           | [ITU-T-CT]                           |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T G.8113.1.                  |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | OAM Functions and Mechanisms for     | ITU-T Y.1731  |
   |Ethernet   | Ethernet-based Networks              |               |
   |OAM        | [ITU-T-Y1731]                        |               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Connectivity Fault Management        | IEEE 802.1ag  |
   |CFM        | [IEEE802.1Q]                         |               |
   |           |                                      |               |
   |           |  Note: CFM was originally published  |               |
   |           |  as IEEE 802.1ag, but is now         |               |
   |           |  incorporated in the 802.1Q standard.|               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Management of Data Driven and Data   | IEEE 802.1ag  |
   |DDCFM      | Dependent Connectivity Faults        |               |
   |           | [IEEE802.1Q]                         |               |
   |           |                                      |               |
   |           |  Note: DDCFM was originally published|               |
   |           |  as IEEE 802.1Qaw, but is now        |               |
   |           |  incorporated in the 802.1Q standard.|               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Media Access Control Parameters,     | IEEE 802.3ah  |
   |802.3      | Physical Layers, and Management      |               |
   |link level | Parameters for Subscriber Access     |               |
   |OAM        | Networks [IEEE802.3ah]               |               |
   |           |                                      |               |
   |           |  Note: link level OAM was originally |               |
   |           |  defined in IEEE 802.3ah, and is now |               |
   |           |  incorporated in the 802.3 standard. |               |
   +-----------+--------------------------------------+---------------+
         Table 6 Non-IETF OAM Standards Mentioned in this Document

Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692
   Israel

   Email: talmi@marvell.com

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

   Email: nurit.sprecher@nsn.com

   Elisa Bellagamba
   Ericsson
   6 Farogatan St.
   Stockholm,   164 40
   Sweden

   Phone: +46 761440785
   Email: elisa.bellagamba@ericsson.com

   Yaacov Weingarten
   34 Hagefen St.
   Karnei Shomron,   4485500
   Israel

   Email: wyaacov@gmail.com