From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc7276.txt | 2971 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2971 insertions(+)
 create mode 100644 doc/rfc/rfc7276.txt

(limited to 'doc/rfc/rfc7276.txt')

diff --git a/doc/rfc/rfc7276.txt b/doc/rfc/rfc7276.txt
new file mode 100644
index 0000000..279a9f7
--- /dev/null
+++ b/doc/rfc/rfc7276.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Mizrahi
+Request for Comments: 7276                                       Marvell
+Category: Informational                                      N. Sprecher
+ISSN: 2070-1721                             Nokia Solutions and Networks
+                                                           E. Bellagamba
+                                                                Ericsson
+                                                           Y. Weingarten
+                                                               June 2014
+
+
+                             An Overview of
+        Operations, Administration, and Maintenance (OAM) Tools
+
+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 tools have been
+   defined for various layers in the protocol stack.
+
+   This document summarizes some of the OAM tools defined in the IETF in
+   the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP),
+   pseudowires, and Transparent Interconnection of Lots of Links
+   (TRILL).  This document focuses on tools for detecting and isolating
+   failures in networks and for performance monitoring.  Control and
+   management aspects of OAM are outside the scope of this document.
+   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.
+
+   The target audience of this document includes network equipment
+   vendors, network operators, and standards development organizations.
+   This document can be used as an index to some of the main OAM tools
+   defined in the IETF.  At the end of the document, a list of the OAM
+   toolsets and a list of the OAM functions are presented as a summary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 1]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7276.
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 2]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Background .................................................5
+      1.2. Target Audience ............................................6
+      1.3. OAM-Related Work in the IETF ...............................6
+      1.4. Focusing on the Data Plane .................................7
+   2. Terminology .....................................................8
+      2.1. Abbreviations ..............................................8
+      2.2. Terminology Used in OAM Standards .........................10
+           2.2.1. General Terms ......................................10
+           2.2.2. Operations, Administration, and Maintenance ........10
+           2.2.3. Functions, Tools, and Protocols ....................11
+           2.2.4. Data Plane, Control Plane, and Management Plane ....11
+           2.2.5. The Players ........................................12
+           2.2.6. Proactive and On-Demand Activation .................13
+           2.2.7. Connectivity Verification and Continuity Checks ....14
+           2.2.8. Connection-Oriented vs. Connectionless
+                  Communication ......................................15
+           2.2.9. Point-to-Point vs. Point-to-Multipoint Services ....16
+           2.2.10. Failures ..........................................16
+   3. OAM Functions ..................................................17
+   4. OAM Tools in the IETF - A Detailed Description .................18
+      4.1. IP Ping ...................................................18
+      4.2. IP Traceroute .............................................19
+      4.3. Bidirectional Forwarding Detection (BFD) ..................20
+           4.3.1. Overview ...........................................20
+           4.3.2. Terminology ........................................20
+           4.3.3. BFD Control ........................................20
+           4.3.4. BFD Echo ...........................................21
+      4.4. MPLS OAM ..................................................21
+           4.4.1. LSP Ping ...........................................21
+           4.4.2. BFD for MPLS .......................................22
+           4.4.3. OAM for Virtual Private Networks (VPNs) over MPLS ..23
+      4.5. MPLS-TP OAM ...............................................23
+           4.5.1. Overview ...........................................23
+           4.5.2. Terminology ........................................24
+           4.5.3. Generic Associated Channel .........................25
+           4.5.4. MPLS-TP OAM Toolset ................................25
+                  4.5.4.1. Continuity Check and Connectivity
+                           Verification ..............................26
+                  4.5.4.2. Route Tracing .............................26
+                  4.5.4.3. Lock Instruct .............................27
+                  4.5.4.4. Lock Reporting ............................27
+                  4.5.4.5. Alarm Reporting ...........................27
+                  4.5.4.6. Remote Defect Indication ..................27
+                  4.5.4.7. Client Failure Indication .................27
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 3]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+                  4.5.4.8. Performance Monitoring ....................28
+                           4.5.4.8.1. Packet Loss Measurement (LM) ...28
+                           4.5.4.8.2. Packet Delay Measurement (DM) ..28
+      4.6. Pseudowire OAM ............................................29
+           4.6.1. Pseudowire OAM Using Virtual Circuit
+                  Connectivity Verification (VCCV) ...................29
+           4.6.2. Pseudowire OAM Using G-ACh .........................30
+           4.6.3. Attachment Circuit - Pseudowire Mapping ............30
+      4.7. OWAMP and TWAMP ...........................................31
+           4.7.1. Overview ...........................................31
+           4.7.2. Control and Test Protocols .........................32
+           4.7.3. OWAMP ..............................................32
+           4.7.4. TWAMP ..............................................33
+      4.8. TRILL .....................................................33
+   5. Summary ........................................................34
+      5.1. Summary of OAM Tools ......................................34
+      5.2. Summary of OAM Functions ..................................37
+      5.3. Guidance to Network Equipment Vendors .....................38
+   6. Security Considerations ........................................38
+   7. Acknowledgments ................................................39
+   8. References .....................................................39
+      8.1. Normative References ......................................39
+      8.2. Informative References ....................................39
+   Appendix A. List of OAM Documents ................................ 46
+      A.1. List of IETF OAM Documents ............................... 46
+      A.2. List of Selected Non-IETF OAM Documents .................. 50
+
+1.  Introduction
+
+   "OAM" is a general term that refers to a toolset for detecting,
+   isolating, and reporting failures, and for monitoring network
+   performance.
+
+   There are several different interpretations of the "OAM" acronym.
+   This document refers to Operations, Administration, and Maintenance,
+   as recommended in Section 3 of [OAM-Def].
+
+   This document summarizes some of the OAM tools defined in the IETF in
+   the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP),
+   pseudowires, and TRILL.
+
+   This document focuses on tools for detecting and isolating failures
+   and for performance monitoring.  Hence, this document focuses on the
+   tools used for monitoring and measuring the data plane; control and
+   management aspects of OAM are outside the scope of this document.
+   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.
+
+
+
+Mizrahi, et al.               Informational                     [Page 4]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+1.1.  Background
+
+   OAM was originally used in traditional communication technologies
+   such as E1 and T1, evolving into Plesiochronous Digital Hierarchy
+   (PDH) and then later into Synchronous Optical Network / Synchronous
+   Digital Hierarchy (SONET/SDH).  ATM was probably the first technology
+   to include inherent OAM support from day one, while in other
+   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.  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 more
+   advanced OAM functions, beyond ICMP and router hellos, that were
+   traditionally used for fault detection.
+
+   As typical networks have a multi-layer architecture, the set of OAM
+   protocols similarly take a multi-layer structure; each layer has its
+   own OAM 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 of Multi-layer OAM
+
+
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 5]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+1.2.  Target Audience
+
+   The target audience of this document includes:
+
+   o  Standards 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
+      tools for new technologies.
+
+   o  Network equipment vendors and network operators can use this
+      document as an index to some of the common IETF OAM tools.
+
+   It should be noted that some background in OAM is necessary in order
+   to understand and benefit from this document.  Specifically, the
+   reader is assumed to be familiar with the term "OAM" [OAM-Def], the
+   motivation for using OAM, and the distinction between OAM and network
+   management [OAM-Mng].
+
+1.3.  OAM-Related Work in the IETF
+
+   This memo provides an overview of the different sets of OAM tools
+   defined by the IETF.  The set of OAM tools described in this memo are
+   applicable to IP unicast, MPLS, pseudowires, MPLS Transport Profile
+   (MPLS-TP), and TRILL.  While OAM 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 tools in several different
+   contexts.  We roughly categorize these efforts into a few sets of
+   OAM-related RFCs, listed in Table 1.  Each set defines a 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 sets
+   (the acronyms and abbreviations are listed in Section 2.1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 6]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+                        +--------------+------------+
+                        | Toolset      | 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: OAM Toolset Packages in the IETF Documents
+
+   This document focuses on OAM tools that have been developed in the
+   IETF.  A short summary of some of the significant OAM standards that
+   have been developed in other standard organizations is presented in
+   Appendix A.2.
+
+1.4.  Focusing on the Data Plane
+
+   OAM tools may, and quite often do, work in conjunction with a control
+   plane and/or management plane.  OAM provides instrumentation tools
+   for measuring and monitoring the data plane.  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 plane (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.
+
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 7]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   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 with as much accuracy as possible.  Thus, it is important to
+   enforce fate-sharing between OAM traffic that monitors the data plane
+   and the 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
+
+   CC-V     Continuity Check and Connectivity Verification
+
+   CV       Connectivity Verification
+
+   DM       Delay Measurement
+
+   ECMP     Equal-Cost Multipath
+
+   FEC      Forwarding Equivalence Class
+
+   FRR      Fast Reroute
+
+   G-ACh    Generic Associated Channel
+
+   GAL      Generic Associated Channel Label
+
+   ICMP     Internet Control Message Protocol
+
+   L2TP     Layer 2 Tunneling Protocol
+
+   L2VPN    Layer 2 Virtual Private Network
+
+   L3VPN    Layer 3 Virtual Private Network
+
+   LCCE     L2TP Control Connection Endpoint
+
+   LDP      Label Distribution Protocol
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 8]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   LER      Label Edge Router
+
+   LM       Loss Measurement
+
+   LSP      Label Switched Path
+
+   LSR      Label Switching 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
+
+   OWAMP    One-Way Active Measurement Protocol
+
+   PDH      Plesiochronous Digital Hierarchy
+
+   PE       Provider Edge
+
+   PSN      Public Switched Network
+
+   PW       Pseudowire
+
+   PWE3     Pseudowire Emulation Edge-to-Edge
+
+   RBridge  Routing Bridge
+
+   RDI      Remote Defect Indication
+
+   SDH      Synchronous Digital Hierarchy
+
+   SONET    Synchronous Optical Network
+
+   TRILL    Transparent Interconnection of Lots of Links
+
+
+
+
+Mizrahi, et al.               Informational                     [Page 9]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   TTL      Time To Live
+
+   TWAMP    Two-Way Active Measurement Protocol
+
+   VCCV     Virtual Circuit Connectivity Verification
+
+   VPN      Virtual Private Network
+
+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], which provides a good summary of some of
+   the OAM-related terminology.
+
+2.2.2.  Operations, Administration, and Maintenance
+
+   The following definition of OAM is quoted from [OAM-Def]:
+
+   The components of the "OAM" acronym (and provisioning) are defined as
+   follows:
+
+   o  Operations - Operation activities are undertaken to keep the
+      network (and the services that the network provides) up and
+      running.  It includes monitoring the network and finding problems.
+      Ideally these problems should be found before users are affected.
+
+   o  Administration - Administration activities involve keeping track
+      of resources in the 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.
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 10]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+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
+
+      An OAM protocol is a protocol used for implementing one or more
+      OAM functions.
+
+      The OWAMP-Test [OWAMP] is an example of an OAM protocol.
+
+   OAM Tool
+
+      An OAM tool is a specific means of applying one or more OAM
+      functions.
+
+      In some cases, an OAM protocol *is* an OAM tool, e.g., OWAMP-Test.
+      In other cases, an OAM 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.
+
+2.2.4.  Data Plane, Control Plane, and Management Plane
+
+   Data Plane
+
+      The data plane is the set of functions used to transfer data in
+      the 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 is the set of protocols and mechanisms that
+      enable routers to efficiently learn how to forward packets towards
+      their final destination (based on [Comp]).
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 11]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   Management Plane
+
+      The term "Management Plane", as described in [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 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 [Mng]).
+
+2.2.5.  The Players
+
+   An OAM tool is used between two (or more) peers.  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 toolsets discussed
+   in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 12]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+        +--------------------------+---------------------------+
+        | Toolset                  | 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.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.
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 13]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+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.  It is noted that while the CV
+      function is performed in the data plane, the "expected path" is
+      predetermined in either the control plane or 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 tools often perform path verification as
+      well, allowing 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.
+
+      Connectivity Verification functions can also be used for checking
+      the MTU of the path between the two peers.
+
+      Connectivity Verification and Continuity Checks are considered
+      complementary mechanisms and are often used in conjunction with
+      each other.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 14]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+2.2.8.  Connection-Oriented vs. Connectionless Communication
+
+   Connection-Oriented
+
+      In connection-oriented technologies, an end-to-end connection is
+      established (by a control protocol or provisioned by a management
+      system) prior to the transmission of data.
+
+      Typically a connection identifier is used to identify the
+      connection.  In connection-oriented technologies, it is 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 end
+      points without prior arrangement.  Packets are routed
+      independently based on their destination address, and hence
+      different packets may be routed in a different way across the
+      network.
+
+   Discussion
+
+      The OAM tools described in 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
+      *specific* connection; OAM packets are forwarded through the same
+      route as the data traffic and receive the same treatment.  In
+      connectionless technologies, OAM is used between a source and
+      destination pair without defining a specific connection.
+      Moreover, in some cases, the route of OAM packets may differ from
+      the one of the data traffic.  For example, the connectionless IP
+      Ping (Section 4.1) tests the reachability from a source to a given
+      destination, while the connection-oriented LSP Ping (Section
+      4.4.1) is used for monitoring a specific LSP (connection) and
+      provides the capability to monitor all the available paths used by
+      an LSP.
+
+      It should be noted that in some cases connectionless protocols are
+      monitored by connection-oriented OAM protocols.  For example,
+      while IP is a connectionless protocol, it can be monitored by BFD
+      (Section 4.3), which is connection oriented.
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 15]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+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)
+
+      A P2MP service delivers data from a single source to a one or more
+      destinations (based on [Signal]).
+
+      An MP2MP service is a service that delivers data from more than
+      one source to one or more receivers (based on [Signal]).
+
+      Note: the two definitions for P2MP and MP2MP are quoted from
+      [Signal].  Although [Signal] describes a specific case of P2MP and
+      MP2MP that is MPLS-specific, these two definitions also apply to
+      non-MPLS cases.
+
+   Discussion
+
+      The OAM tools described in this document include tools for P2P
+      services, as well as tools for P2MP services.
+
+      The distinction between P2P services and P2MP services affects the
+      corresponding OAM tools.  A P2P service is typically simpler to
+      monitor, as it consists of a single pair of endpoints.  P2MP and
+      MP2MP services present several challenges.  For example, in a P2MP
+      service, the OAM mechanism not only verifies that each of the
+      destinations is reachable from the source but also verifies that
+      the P2MP distribution tree is intact and loop-free.
+
+2.2.10.  Failures
+
+   The terms "Failure", "Fault", and "Defect" are used interchangeably
+   in the standards, referring to a malfunction that can be detected by
+   a Connectivity Verification or a Continuity Check.  In some
+   standards, such as 802.1ag [IEEE802.1Q], there is no distinction
+   between these terms, while in other standards each of these terms
+   refers to a different type of malfunction.
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 16]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   The terminology used in IETF MPLS-TP OAM is based on the ITU-T
+   terminology, which distinguishes between these three terms in
+   [ITU-T-G.806] as follows:
+
+   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 as a consecutive period of time where no packets are delivered
+   successfully.
+
+   Failure
+
+   The term "Failure" refers to the termination of the required
+   function.  While a Defect typically refers to a limited period of
+   time, a failure refers to a long period of time.
+
+3.  OAM Functions
+
+   This subsection provides a brief summary of the common OAM functions
+   used in OAM-related standards.  These functions are used as building
+   blocks in the OAM standards described in this document.
+
+   o  Connectivity Verification (CV), Path Verification, and Continuity
+      Check (CC):
+      As defined in Section 2.2.7.
+
+   o  Path Discovery / Fault Localization:
+      This function can be used to trace the route to a destination,
+      i.e., to identify the nodes along the route to the destination.
+      When more than one route is available to a specific destination,
+      this function traces one of the available routes.  When a failure
+      occurs, this function attempts to detect the location of the
+      failure.
+      Note that the term "route tracing" (or "Traceroute"), which is
+      used in the context of IP and MPLS, is sometimes referred to as
+      "path tracing" in the context of other protocols, such as TRILL.
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 17]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   o  Performance Monitoring:
+      Typically refers to:
+
+      *  Loss Measurement (LM) - monitors the packet loss rate.
+
+      *  Delay Measurement (DM) - monitors the delay and delay variation
+         (jitter).
+
+4.  OAM Tools in the IETF - A Detailed Description
+
+   This section presents a detailed description of the sets of OAM-
+   related tools in each of the toolsets in Table 1.
+
+4.1.  IP Ping
+
+   Ping is a common network diagnostic application for IP networks that
+   use ICMP.  According to [NetTerms], 'Ping' is an abbreviation for
+   Packet internet groper, although the term has been so commonly used
+   that it stands on its own.  As defined in [NetTerms], it is a program
+   used to test reachability of destinations by sending them an ICMP
+   Echo request and waiting for a reply.
+
+   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, and [ICMPv6] is used for IPv6.
+
+   Ping can be invoked to either a unicast destination or a multicast
+   destination.  In the latter case, all members of the multicast group
+   send an Echo reply back to the originator.
+
+   Ping implementations typically use ICMP messages.  UDP Ping is a
+   variant that uses UDP messages instead of ICMP Echo messages.
+
+   Ping is 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 is deployed in some routers and
+   firewalls, the usefulness of Ping is sometimes limited in the wider
+   Internet.  This limitation is equally relevant to Traceroute.
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 18]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+4.2.  IP Traceroute
+
+   Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
+   users to discover a 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 sequence of UDP packets to
+   UDP port 33434 at the destination.  By default, Traceroute begins by
+   sending three packets (the number of packets is configurable in most
+   Traceroute implementations), each with an IP Time-To-Live (or Hop
+   Limit in IPv6) value of one, to the destination.  These packets
+   expire as soon as they reach the first router in the path.
+   Consequently, that router sends three ICMP Time Exceeded Messages
+   back to the Traceroute application.  Traceroute now sends another
+   three UDP packets, each with the TTL value of 2.  These messages
+   cause the second router to return ICMP messages.  This process
+   continues, with ever-increasing values for the TTL field, until the
+   packets actually reach the destination.  Because no application
+   listens to port 33434 at the destination, the destination returns
+   ICMP Destination Unreachable Messages indicating an unreachable port.
+   This event indicates to the Traceroute application that it is
+   finished.  The Traceroute program displays the round-trip delay
+   associated with each of the attempts.
+
+   While Traceroute is a tool that finds *a* path from A to B, it should
+   be noted that traffic from A to B is often forwarded through Equal-
+   Cost Multipaths (ECMPs).  Paris Traceroute [PARIS] is an extension to
+   Traceroute that attempts to discovers all the available paths from A
+   to B by scanning different values of header fields (such as UDP
+   ports) in the probe packets.
+
+   It is noted 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 that use other types 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 in
+   the context of Traceroute.  These documents define several
+   extensions, including extensions to the ICMP Destination Unreachable
+   message, that can be used by Traceroute applications.
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 19]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   Traceroute allows path discovery to *unicast* destination addresses.
+   A similar tool [mtrace] was defined for multicast destination
+   addresses; it allows tracing the route that a multicast IP packet
+   takes from a source to a particular receiver.
+
+4.3.  Bidirectional Forwarding Detection (BFD)
+
+4.3.1.  Overview
+
+   While multiple OAM tools have been defined for various protocols in
+   the protocol stack, Bidirectional Forwarding Detection [BFD], defined
+   by the IETF BFD working group, is a generic OAM tool that can be
+   deployed over various encapsulating protocols, and in various medium
+   types.  The IETF has defined variants of the protocol for IP
+   ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires
+   [BFD-VCCV].  The usage of BFD in MPLS-TP is defined in [TP-CC-CV].
+
+   BFD includes two main OAM functions, using two types of BFD packets:
+   BFD Control packets and BFD Echo packets.
+
+4.3.2.  Terminology
+
+   BFD operates between *systems*.  The BFD protocol is run between two
+   or more 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 one of two modes:
+
+   o  Asynchronous mode (i.e., proactive): in this mode, BFD Control
+      packets are sent periodically.  When the receiver detects that no
+      BFD Control packets have been received during a predetermined
+      period of time, a failure is reported.
+
+   o  Demand mode: in this mode, BFD Control packets are sent on demand.
+      Upon need, a system initiates a series of BFD Control packets to
+      check the continuity of the session.  BFD Control packets are sent
+      independently in each direction.
+
+   Each of the endpoints (referred to as systems) of the monitored path
+   maintains its own session identification, called a Discriminator;
+   both Discriminators are included in the BFD Control Packets that are
+   exchanged between the endpoints.  At the time of session
+   establishment, the Discriminators are exchanged between the two
+   endpoints.  In addition, the transmission (and reception) rate is
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 20]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   negotiated between the two endpoints, based on information included
+   in the control packets.  These transmission rates may be renegotiated
+   during the session.
+
+   During normal operation of the session, i.e., when no failures have
+   been detected, the BFD session is in the Up state.  If no BFD Control
+   packets are received during a period of time called the Detection
+   Time, the session is declared to be Down.  The detection time is a
+   function of the pre-configured or negotiated transmission rate and a
+   parameter called Detect Mult.  Detect Mult determines the number of
+   missing BFD Control packets that cause the session to be declared as
+   Down.  This parameter is included in the BFD Control packet.
+
+4.3.4.  BFD Echo
+
+   A BFD Echo packet is sent to a peer system and is looped 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 it is not used in BFD for MPLS LSPs or 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
+   tool defined, in this context, is LSP Ping [LSP-Ping].  OAM for P2MP
+   services is defined in [MPLS-P2MP].
+
+   BFD for MPLS [BFD-LSP] is an alternative means for detecting data-
+   plane failures, as described below.
+
+4.4.1.  LSP Ping
+
+   LSP Ping is modeled after the Ping/Traceroute paradigm, and thus it
+   may be used in one 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.
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 21]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   LSP Ping is based on the ICMP Ping operation (of data-plane
+   Connectivity Verification) with additional functionality to verify
+   data-plane vs. control-plane consistency for a Forwarding Equivalence
+   Class (FEC) and also to identify Maximum Transmission Unit (MTU)
+   problems.
+
+   The Traceroute functionality may be used to isolate and localize MPLS
+   faults, using the Time-To-Live (TTL) indicator to incrementally
+   identify the sub-path of the LSP that is successfully traversed
+   before the faulty link or node.
+
+   The challenge in MPLS networks is that the traffic of a given LSP may
+   be load-balanced across Equal-Cost Multipaths (ECMPs).  LSP Ping
+   monitors all the available paths of an LSP by monitoring its
+   different FECs.  Note that MPLS-TP does not use ECMP, and thus does
+   not require OAM over multiple paths.
+
+   Another challenge is that an MPLS LSP does not necessarily have a
+   return path; traffic that is sent back from the egress LSR to the
+   ingress LSR is not necessarily sent over an MPLS LSP, but it can be
+   sent through a different route, such as an IP route.  Thus,
+   responding to an LSP Ping message is not necessarily as trivial as in
+   IP Ping, where the responder just swaps the source and destination IP
+   addresses.  Note that this challenge is not applicable to MPLS-TP,
+   where a return path is always available.
+
+   It should be noted that LSP Ping supports unique identification of
+   the LSP within an addressing domain.  The identification is checked
+   using the full FEC identification.  LSP Ping is extensible to include
+   additional information needed to support new functionality, by use of
+   Type-Length-Value (TLV) constructs.  The usage of TLVs is typically
+   handled by the control plane, as it is not easy to implement in
+   hardware.
+
+   LSP Ping supports both asynchronous and on-demand activation.
+
+4.4.2.  BFD for MPLS
+
+   BFD [BFD-LSP] can be used to detect MPLS LSP data-plane failures.
+
+   A BFD session is established for each MPLS LSP that is being
+   monitored.  BFD Control packets must be sent along the same path as
+   the monitored LSP.  If the LSP is associated with multiple FECs, a
+   BFD session is established for each FEC.
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 22]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   While LSP Ping can be used for detecting MPLS data-plane failures and
+   for verifying the MPLS LSP data plane against the control plane, BFD
+   can only be used for the former.  BFD can be used in conjunction with
+   LSP Ping, as is the case in MPLS-TP (see Section 4.5.4).
+
+4.4.3.  OAM for Virtual Private Networks (VPNs) over MPLS
+
+   The IETF has defined two classes of VPNs: Layer 2 VPNs (L2VPNs) and
+   Layer 3 VPNs (L3VPNs).  [L2VPN-OAM] provides the requirements and
+   framework for OAM in the context of L2VPNs, and specifically it also
+   defines the OAM layering of L2VPNs over MPLS.  [L3VPN-OAM] provides a
+   framework for the operation and management of L3VPNs.
+
+4.5.  MPLS-TP OAM
+
+4.5.1.  Overview
+
+   The MPLS working group has defined the OAM toolset that fulfills the
+   requirements for MPLS-TP OAM.  The full set of requirements for
+   MPLS-TP OAM are defined in [MPLS-TP-OAM] and include both general
+   requirements for the behavior of the OAM tools and a set of
+   operations that should be supported 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 and also gives
+   overviews of the functionality of 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 environment
+      and a 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, 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 the user traffic are required to be congruent
+      (i.e., OAM packets are transmitted in-band), and there is a need
+      to differentiate OAM packets from ordinary user packets in the
+      data plane.  Inherent in this requirement is the principle that
+      MPLS-TP OAM be independent of any existing control plane, although
+      it should not preclude use of the control-plane functionality.
+      OAM packets are identified by the Generic Associated Channel Label
+      (GAL), which is a reserved MPLS label value (13).
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 23]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+4.5.2.  Terminology
+
+   Maintenance Entity (ME)
+
+      The MPLS-TP OAM tools are designed to monitor and manage a
+      Maintenance Entity (ME).  An ME, as defined in [TP-OAM-FW],
+      defines a relationship between two points of a transport path to
+      which maintenance and monitoring operations apply.
+
+      The term "Maintenance Entity (ME)" is used in ITU-T
+      Recommendations (e.g., [ITU-T-Y1731]), as well as in the MPLS-TP
+      terminology ([TP-OAM-FW]).
+
+   Maintenance Entity Group (MEG)
+
+      The collection of one or more MEs that belong to the same
+      transport path and that are maintained and monitored as a group
+      are known as a Maintenance Entity Group (based on [TP-OAM-FW]).
+
+   Maintenance Point (MP)
+
+      A Maintenance Point (MP) is a functional entity that is defined at
+      a node in the network and can initiate and/or react to OAM
+      messages.  This document focuses on the data-plane functionality
+      of MPs, while MPs interact with the control plane and with the
+      management plane as well.
+
+      The term "MP" is used in IEEE 802.1ag and was similarly adopted in
+      MPLS-TP ([TP-OAM-FW]).
+
+   MEG End Point (MEP)
+
+      A MEG End Point (MEP) is one of the endpoints of an ME, and can
+      initiate OAM messages and respond to them (based on [TP-OAM-FW]).
+
+   MEG Intermediate Point (MIP)
+
+      In between MEPs, there are zero or more intermediate points,
+      called MEG Intermediate Points  (based on [TP-OAM-FW]).
+
+      A MEG Intermediate Point (MIP) is an intermediate point that does
+      not generally initiate OAM frames (one exception to this is 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
+      destined to it by the expiration of the TTL field in the OAM
+      packet.  The term "Maintenance Point" is a general term for MEPs
+      and MIPs.
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 24]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   Up and Down MEPs
+
+      IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs
+      and Down MEPs.  A MEP monitors traffic in either the direction
+      facing the network or the direction facing the bridge.  A Down MEP
+      is a MEP that receives OAM packets from and transmits them to the
+      direction of the network.  An Up MEP receives OAM packets from and
+      transmits them to the direction of the bridging entity.  MPLS-TP
+      ([TP-OAM-FW]) uses a similar distinction on the placement of the
+      MEP -- at either the ingress, egress, or forwarding function of
+      the node (Down / Up MEPs).  This placement is important for
+      localization of a failure.
+
+      Note that the terms "Up MEP" and "Down MEP" are entirely unrelated
+      to the conventional "Up"/"Down" terminology, where "Down" means
+      faulty and "Up" means not faulty.
+
+      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 of this document.
+
+4.5.3.  Generic Associated Channel
+
+   In order to address the requirement for in-band 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 [PW-ACH] and
+   VCCV [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), which uses a format similar to
+      the PW Control Word [PW-ACH], is a 4-byte header that is prepended
+      to OAM packets.
+
+   o  A Generic Associated Channel Label (GAL).  The GAL is a reserved
+      MPLS label value (13) that indicates that the packet is an ACH
+      packet 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 can be
+   used in MPLS in general, and not only in MPLS-TP.
+
+4.5.4.  MPLS-TP OAM Toolset
+
+   To address the functionality that is required of the OAM toolset, the
+   MPLS WG conducted an analysis of the existing IETF and ITU-T OAM
+   tools and their ability to fulfill the required functionality.  The
+
+
+
+Mizrahi, et al.               Informational                    [Page 25]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   conclusions of this analysis are documented in [OAM-Analys].  MPLS-TP
+   uses a mixture of OAM tools that are based on previous standards and
+   adapted to the requirements of [MPLS-TP-OAM].  Some of the main
+   building blocks of this solution are based on:
+
+   o  Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
+      proactive Continuity Check and Connectivity Verification.
+
+   o  LSP Ping as defined in [LSP-Ping] for on-demand Connectivity
+      Verification.
+
+   o  New protocol packets, using G-ACH, to address different
+      functionality.
+
+   o  Performance measurement protocols.
+
+   The following subsections describe the OAM tools defined for MPLS-TP
+   as described in [TP-OAM-FW].
+
+4.5.4.1.  Continuity Check and Connectivity Verification
+
+   Continuity Checks and Connectivity Verification are presented in
+   Section 2.2.7 of this document.  As presented there, these tools may
+   be 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 proactive tool is
+   defined in [TP-CC-CV], while the on-demand tool is defined in
+   [OnDemand-CV].  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 for the CC-V messages to include unique identification of
+   the MEG that is being monitored and the MEP that originated the
+   message.
+
+   The proactive tool [TP-CC-CV] 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 of LSP Ping (see
+   Section 4.4.1) for the required behavior of MPLS-TP.
+
+4.5.4.2.  Route Tracing
+
+   [MPLS-TP-OAM] defines that there is a need for functionality that
+   would allow a path endpoint to identify the intermediate and
+   endpoints of the path.  This function would be used in on-demand
+   mode.  Normally, this path will be used for bidirectional PW, LSP,
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 26]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   and Sections; however, unidirectional paths may be supported only if
+   a return path exists.  The tool for this is based on the LSP Ping
+   (see Section 4.4.1) functionality and is described in [OnDemand-CV].
+
+4.5.4.3.  Lock Instruct
+
+   The Lock Instruct function [Lock-Loop] is used to notify a transport-
+   path endpoint of an administrative need to disable the transport
+   path.  This functionality will generally be used in conjunction with
+   some intrusive OAM function, e.g., performance measurement or
+   diagnostic testing, to minimize the side-effect on user data traffic.
+
+4.5.4.4.  Lock Reporting
+
+   Lock Reporting is a function used by an endpoint of a path to report
+   to its far-end endpoint that a lock condition has been affected on
+   the 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 path, that
+   becomes aware of a fault on the path, to report to the endpoints of
+   the path.  [TP-OAM-FW] states that this may occur as a result 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 of this function is detailed in
+   [TP-OAM-FW].
+
+4.5.4.6.  Remote Defect Indication
+
+   Remote Defect Indication (RDI) is used proactively by a path endpoint
+   to report to its peer endpoint that a defect is detected on a
+   bidirectional connection between them.  [MPLS-TP-OAM] points out that
+   this function may be applied to a unidirectional LSP only if a return
+   path exists.  [TP-OAM-FW] points out that this function is associated
+   with the proactive CC-V function.
+
+4.5.4.7.  Client Failure Indication
+
+   Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow
+   the propagation information from one edge of the network to the
+   other.  The information concerns a defect to a client, in the case
+   that the client does not support alarm notification.
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 27]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+4.5.4.8.  Performance Monitoring
+
+   The definition of MPLS performance monitoring was motivated by the
+   MPLS-TP requirements [MPLS-TP-OAM] but was defined generically for
+   MPLS in [MPLS-LM-DM].  An additional document [TP-LM-DM] defines a
+   performance monitoring profile for MPLS-TP.
+
+4.5.4.8.1.  Packet Loss Measurement (LM)
+
+   Packet Loss Measurement is a function used to verify the quality of
+   the service.  Packet loss, as defined in [IPPM-1LM] and
+   [MPLS-TP-OAM], indicates the ratio of the number of user packets lost
+   to the total number of user packets sent during a defined time
+   interval.
+
+   There are two possible ways of determining this measurement:
+
+   o  Using OAM packets, it is possible to compute the statistics based
+      on a series of OAM packets.  This, however, has the disadvantage
+      of being artificial and may not be representative since part of
+      the packet loss may be dependent upon packet sizes and upon the
+      implementation of the MEPs that take part in the protocol.
+
+   o  Delimiting messages can be sent at the start and end of a
+      measurement period during which the source and sink of the path
+      count the packets transmitted and received.  After the end
+      delimiter, the ratio would be calculated by the path OAM entity.
+
+4.5.4.8.2.  Packet Delay Measurement (DM)
+
+   Packet Delay Measurement is a function that is used to measure one-
+   way or two-way delay of a packet transmission between a pair of the
+   endpoints of a path (PW, LSP, or Section).  Where:
+
+   o  One-way packet delay, as defined in [IPPM-1DM], is the time
+      elapsed from the start of transmission of the first bit of the
+      packet by a source node until the reception of the last bit of
+      that packet by the destination node.  Note that one-way delay
+      measurement requires the clocks of the two endpoints to be
+      synchronized.
+
+   o  Two-way packet delay, as defined in [IPPM-2DM], is the time
+      elapsed from the start of transmission of the first bit of the
+      packet by a source node until the reception of the last bit of the
+      looped-back packet 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
+      endpoint to another is not necessarily equal to half of the
+
+
+
+Mizrahi, et al.               Informational                    [Page 28]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+      two-way packet delay.  As opposed to one-way delay measurement,
+      two-way delay measurement does not require the two endpoints to be
+      synchronized.
+
+      For each of these two metrics, the DM function allows the MEP to
+      measure the delay, as well as 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 defined in [VCCV], provides a means for end-to-end fault
+   detection and diagnostic tools to be used for PWs (regardless of the
+   underlying tunneling technology).  The VCCV switching function
+   provides a Control Channel associated with each PW.  [VCCV] defines
+   three Control Channel (CC) types, i.e., three possible methods for
+   transmitting and identifying OAM messages:
+
+   o  Control Channel Type 1: In-band VCCV, as described in [VCCV], is
+      also referred to as "PWE3 Control Word with 0001b as first
+      nibble".  It uses the PW Associated Channel Header [PW-ACH].
+
+   o  Control Channel Type 2: Out-of-band VCCV, as described in [VCCV],
+      is also referred to as "MPLS Router Alert Label".  In this case,
+      the Control Channel is created by using the MPLS router alert
+      label [MPLS-ENCAPS] immediately above the PW label.
+
+   o  Control Channel Type 3: TTL expiry VCCV, as described in [VCCV],
+      is also referred to as "MPLS PW Label with TTL == 1", i.e., the
+      Control Channel is identified when the value of the TTL field in
+      the PW label is set to 1.
+
+   VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping,
+   and BFD.  ICMP and LSP Ping are IP encapsulated before being sent
+   over the 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 the VCCV Control Channel
+   provides the context, based on the MPLS-PW label, required to bind
+   and bootstrap the BFD session to a particular pseudowire (FEC),
+   eliminating the need to exchange Discriminator values.
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 29]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   VCCV consists of two components: (1) the signaled component to
+   communicate VCCV capabilities as part of the VC label, and (2) the
+   switching component to cause the PW payload to be treated as a
+   control packet.
+
+   VCCV is not directly dependent upon the presence of a control plane.
+   The VCCV capability advertisement may be performed as part of the PW
+   signaling when LDP is used.  In case of manual configuration of the
+   PW, it is the responsibility of the operator to set consistent
+   options at both ends.  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] that analyzes which VCCV mechanisms are used in
+   practice.
+
+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 the G-ACh for
+   PWs is defined in [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 by Section 5.3 of [ATM-L2] for ATM.
+
+   [L2VPN-OAM] provides the requirements and framework for OAM in the
+   context of Layer 2 Virtual Private Networks (L2VPNs), and
+   specifically it also defines the OAM layering of L2VPNs over
+   pseudowires.
+
+   The mapping defined in [Eth-Int] allows an end-to-end emulated
+   Ethernet service over pseudowires.
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 30]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+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] each 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
+   endpoints.
+
+   TWAMP [TWAMP] is a similar protocol that enables measurement of both
+   one-way and two-way (round-trip) characteristics.
+
+   OWAMP and TWAMP are each 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].
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 31]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+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 they 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
+   pseudorandomly).  Statistics recorded conform to the relevant IPPM
+   RFCs.
+
+   From a security perspective, OWAMP and TWAMP 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 may play 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 mode.  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; the Server acknowledges and then instructs the
+   Session-Sender to start the test.  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.
+
+
+
+Mizrahi, et al.               Informational                    [Page 32]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   Once finished, the Session-Sender reports to the Server, which
+   recovers data from the Session-Receiver.  The Fetch-Client can then
+   send 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 the 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 timestamps inserted.
+
+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 RBridges.
+
+   During the writing of this document, the detailed definition of the
+   TRILL OAM tools is 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.
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 33]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+5.  Summary
+
+   This section summarizes the OAM tools and functions presented in this
+   document.  This summary is an index to some of the main OAM tools
+   defined in the IETF.  This compact index can be useful to all readers
+   from network operators to standards development organizations.  The
+   summary includes a short subsection that presents some guidance to
+   network equipment vendors.
+
+5.1.  Summary of OAM Tools
+
+   This subsection provides a short summary of each of the OAM toolsets
+   described in this document.
+
+   A detailed list of the RFCs related to each toolset is given in
+   Appendix A.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 34]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
++-----------+------------------------------------------+------------+
+| Toolset   | 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.  Paris Traceroute [PARIS] is an  |            |
+|           | extension that attempts to discover all  |            |
+|           | the available paths from A to B by       |            |
+|           | scanning different values of header      |            |
+|           | fields.                                  |            |
++-----------+------------------------------------------+------------+
+|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 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 MPLS LSPs.           |            |
+|           | It includes two main functions: Ping and |            |
+|           | Traceroute.                              |            |
+|           | BFD [BFD-LSP] is an alternative means for|            |
+|           | detecting MPLS LSP data-plane failures.  |            |
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 35]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
++-----------+------------------------------------------+------------+
+|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 Appendix 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 Protocol [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, 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
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 36]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+5.2.  Summary of OAM Functions
+
+   Table 4 summarizes the OAM functions that are supported in each of
+   the toolsets that were analyzed in this section.  The columns of this
+   table are the typical OAM functions described in Section 1.3.
+
++-----------+----------+-------------+----------+----------+-----------+
+|           |Continuity|Connectivity |Path      |Perf.     |Other      |
+| Toolset   |Check     |Verification |Discovery |Monitoring|Functions  |
+|           |          |             |          |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|IP Ping    |Echo      |             |          |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|IP         |          |             |Traceroute|          |           |
+|Traceroute |          |             |          |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|BFD        |BFD       |BFD Control  |          |          |RDI using  |
+|           |Control/  |             |          |          |BFD Control|
+|           |Echo      |             |          |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|MPLS OAM   |          |"Ping" mode  |"Trace-   |          |           |
+|(LSP Ping) |          |             |route"    |          |           |
+|           |          |             |mode      |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|MPLS-TP    |CC        |CV/proactive |Route     |-LM       |-Diagnostic|
+|OAM        |          |or on demand |Tracing   |-DM       | Test      |
+|           |          |             |          |          |-Lock      |
+|           |          |             |          |          |-Alarm     |
+|           |          |             |          |          | Reporting |
+|           |          |             |          |          |-Client    |
+|           |          |             |          |          | Failure   |
+|           |          |             |          |          | Indication|
+|           |          |             |          |          |-RDI       |
++-----------+----------+-------------+----------+----------+-----------+
+|Pseudowire |BFD       |-BFD         |LSP Ping  |          |           |
+|OAM        |          |-ICMP Ping   |          |          |           |
+|           |          |-LSP Ping    |          |          |           |
++-----------+----------+-------------+----------+----------+-----------+
+|OWAMP and  |     - control          |          |-DM       |           |
+|TWAMP      |      protocol          |          |-LM       |           |
++-----------+----------+-------------+----------+----------+-----------+
+|TRILL OAM  |CC        |CV           |Path      |-DM       |           |
+|           |          |             |tracing   |-LM       |           |
++-----------+----------+-------------+----------+----------+-----------+
+
+       Table 4: Summary of the OAM Functionality in IETF OAM Tools
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 37]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+5.3.  Guidance to Network Equipment Vendors
+
+   As mentioned in Section 1.4, it is imperative for OAM tools to be
+   capable of testing the actual data plane with as much accuracy as
+   possible.  While this guideline may appear obvious, it is worthwhile
+   to emphasize the key importance of enforcing fate-sharing between OAM
+   traffic that monitors the data plane and the data-plane traffic it
+   monitors.
+
+6.  Security Considerations
+
+   OAM is tightly coupled with the stability of the network.  A
+   successful attack on an OAM protocol can create a false illusion of
+   nonexistent failures or prevent the detection of actual ones.  In
+   both cases, the attack may result in denial of service.
+
+   Some of the OAM tools presented in this document include security
+   mechanisms that provide integrity protection, thereby preventing
+   attackers from forging or tampering with OAM packets.  For example,
+   [BFD] includes an optional authentication mechanism for BFD Control
+   packets, using either SHA1, MD5, or a simple password.  [OWAMP] and
+   [TWAMP] have three modes of security: unauthenticated, authenticated,
+   and encrypted.  The authentication uses SHA1 as the HMAC algorithm,
+   and the encrypted mode uses AES encryption.
+
+   Confidentiality is typically not considered a requirement for OAM
+   protocols.  However, the use of encryption (e.g., [OWAMP] and
+   [TWAMP]) can make it difficult for attackers to identify OAM packets,
+   thus making it more difficult to attack the OAM protocol.
+
+   OAM can also be used as a means for network reconnaissance;
+   information about addresses, port numbers, and the network topology
+   and performance can be gathered by either passively eavesdropping on
+   OAM packets or actively sending OAM packets and gathering information
+   from the respective responses.  This information can then be used
+   maliciously to attack the network.  Note that some of this
+   information, e.g., addresses and port numbers, can be gathered even
+   when encryption is used ([OWAMP], [TWAMP]).
+
+   For further details about the security considerations of each OAM
+   protocol, the reader is encouraged to review the Security
+   Considerations section of each document referenced by this memo.
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 38]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+7.  Acknowledgments
+
+   The authors gratefully acknowledge Sasha Vainshtein, Carlos
+   Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit
+   Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam
+   Aldrin, Thomas Narten, and other members of the OPSA WG for their
+   helpful comments on the mailing list.
+
+   This document was originally prepared using 2-Word-v2.0.template.dot.
+
+8.  References
+
+8.1.  Normative References
+
+   [OAM-Def]     Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
+                 D., and S. Mansfield, "Guidelines for the Use of the
+                 "OAM" Acronym in the IETF", BCP 161, RFC 6291, June
+                 2011.
+
+8.2.  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. and D. Ward, "Bidirectional Forwarding
+                 Detection (BFD)", RFC 5880, June 2010.
+
+   [BFD-Gen]     Katz, D. and D. Ward, "Generic Application of
+                 Bidirectional Forwarding Detection (BFD)", RFC 5882,
+                 June 2010.
+
+   [BFD-IP]      Katz, D. and D. Ward, "Bidirectional Forwarding
+                 Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC
+                 5881, June 2010.
+
+   [BFD-LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+                 "Bidirectional Forwarding Detection (BFD) for MPLS
+                 Label Switched Paths (LSPs)", RFC 5884, June 2010.
+
+   [BFD-Multi]   Katz, D. and D. Ward, "Bidirectional Forwarding
+                 Detection (BFD) for Multihop Paths", RFC 5883, June
+                 2010.
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 39]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [BFD-VCCV]    Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
+                 Forwarding Detection (BFD) for the Pseudowire Virtual
+                 Circuit Connectivity Verification (VCCV)", RFC 5885,
+                 June 2010.
+
+   [Comp]        Bonaventure, O., "Computer Networking: Principles,
+                 Protocols and Practice", 2008.
+
+   [Dup]         Uijterwaal, H., "A One-Way Packet Duplication Metric",
+                 RFC 5560, May 2009.
+
+   [Eth-Int]     Mohan, D., Ed., Bitar, N., Ed., Sajassi, A., Ed.,
+                 DeLord, S., Niger, P., and R. Qiu, "MPLS and Ethernet
+                 Operations, Administration, and Maintenance (OAM)
+                 Interworking", RFC 7023, October 2013.
+
+   [G-ACh]       Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+                 "MPLS Generic Associated Channel", RFC 5586, June 2009.
+
+   [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
+                 "ICMP Extensions for Multiprotocol Label Switching",
+                 RFC 4950, August 2007.
+
+   [ICMP-Int]    Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed.,
+                 Shen, N., and JR. Rivers, "Extending ICMP for Interface
+                 and Next-Hop Identification", RFC 5837, April 2010.
+
+   [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
+                 "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 M. Gupta, Ed., "Internet
+                 Control Message Protocol (ICMPv6) for the Internet
+                 Protocol Version 6 (IPv6) Specification", RFC 4443,
+                 March 2006.
+
+   [IEEE802.1Q]  IEEE, "IEEE Standard for Local and metropolitan area
+                 networks - Media Access Control (MAC) Bridges and
+                 Virtual Bridged Local Area Networks", IEEE 802.1Q,
+                 October 2012.
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 40]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [IEEE802.3ah] IEEE, "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", IEEE 802.3ah,
+                 clause 57, December 2008.
+
+   [IntHost]     Braden, R., Ed., "Requirements for Internet Hosts -
+                 Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [IPPM-1DM]    Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                 Delay Metric for IPPM", RFC 2679, September 1999.
+
+   [IPPM-1LM]    Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                 Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [IPPM-2DM]    Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
+                 trip Delay Metric for IPPM", RFC 2681, September 1999.
+
+   [IPPM-Con]    Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
+                 Connectivity", RFC 2678, September 1999.
+
+   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+                 "Framework for IP Performance Metrics", RFC 2330, May
+                 1998.
+
+   [ITU-G8113.1] ITU-T, "Operations, Administration and Maintenance
+                 mechanism for MPLS-TP in Packet Transport Network
+                 (PTN)",  ITU-T Recommendation G.8113.1/Y.1372.1,
+                 November 2012.
+
+   [ITU-G8113.2] ITU-T, "Operations, administration and maintenance
+                 mechanisms for MPLS-TP networks using the tools defined
+                 for MPLS", ITU-T Recommendation G.8113.2/Y.1372.2,
+                 November 2012.
+
+   [ITU-T-CT]    Betts, M., "Allocation of a Generic Associated Channel
+                 Type for ITU-T MPLS Transport Profile Operation,
+                 Maintenance, and Administration (MPLS-TP OAM)", RFC
+                 6671, November 2012.
+
+   [ITU-T-G.806] ITU-T, "Characteristics of transport equipment -
+                 Description methodology and generic functionality",
+                 ITU-T Recommendation G.806, January 2009.
+
+   [ITU-T-Y1711] ITU-T, "Operation & Maintenance mechanism for MPLS
+                 networks", ITU-T Recommendation Y.1711, February 2004.
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 41]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [ITU-T-Y1731] ITU-T, "OAM Functions and Mechanisms for Ethernet-based
+                 Networks", ITU-T Recommendation G.8013/Y.1731, July
+                 2011.
+
+   [ITU-Terms]   ITU-R/ITU-T, "ITU-R/ITU-T Terms and Definitions", 2013,
+                 <http://www.itu.int/pub/R-TER-DB>.
+
+   [L2TP-EC]     McGill, N. and C. Pignataro, "Layer 2 Tunneling
+                 Protocol Version 3 (L2TPv3) Extended Circuit Status
+                 Values", RFC 5641, August 2009.
+
+   [L2VPN-OAM]   Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual
+                 Private Network (L2VPN) Operations, Administration, and
+                 Maintenance (OAM) Requirements and Framework", RFC
+                 6136, March 2011.
+
+   [L3VPN-OAM]   El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan,
+                 K., and A. Gonguet, "Framework for Layer 3 Virtual
+                 Private Networks (L3VPN) Operations and Management",
+                 RFC 4176, October 2005.
+
+   [Lock-Loop]   Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R.,
+                 Ed., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS
+                 Transport Profile Lock Instruct and Loopback
+                 Functions", RFC 6435, November 2011.
+
+   [LSP-Ping]    Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+                 Label Switched (MPLS) Data Plane Failures", RFC 4379,
+                 February 2006.
+
+   [Mng]         Farrel, A., "Inclusion of Manageability Sections in
+                 Path Computation Element (PCE) Working Group Drafts",
+                 RFC 6123, February 2011.
+
+   [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+                 Encoding", RFC 3032, January 2001.
+
+   [MPLS-LM-DM]  Frost, D. and S. Bryant, "Packet Loss and Delay
+                 Measurement for MPLS Networks", RFC 6374, September
+                 2011.
+
+   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
+                 Matsushima, "Operations and Management (OAM)
+                 Requirements for Multi-Protocol Label Switched (MPLS)
+                 Networks", RFC 4377, February 2006.
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 42]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [MPLS-OAM-FW] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for
+                 Multi-Protocol Label Switching (MPLS) Operations and
+                 Management (OAM)", RFC 4378, February 2006.
+
+   [MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
+                 "Operations and Management (OAM) Requirements for
+                 Point-to-Multipoint MPLS Networks", RFC 4687, September
+                 2006.
+
+   [MPLS-TP-OAM] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+                 "Requirements for Operations, Administration, and
+                 Maintenance (OAM) in MPLS Transport Networks", RFC
+                 5860, May 2010.
+
+   [mtrace]      Fenner, W. and S. Casner, "A "traceroute" facility for
+                 IP Multicast", Work in Progress, July 2000.
+
+   [NetTerms]    Jacobsen, O. and D. Lynch, "A Glossary of Networking
+                 Terms", RFC 1208, March 1991.
+
+   [NetTools]    Enger, R. and J. Reynolds, "FYI on a Network Management
+                 Tool Catalog: Tools for Monitoring and Debugging TCP/IP
+                 Internets and Interconnected Devices", FYI 2, RFC 1470,
+                 June 1993.
+
+   [OAM-Analys]  Sprecher, N. and L. Fang, "An Overview of the
+                 Operations, Administration, and Maintenance (OAM)
+                 Toolset for MPLS-Based Transport Networks", RFC 6669,
+                 July 2012.
+
+   [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' for
+                 Multiprotocol Label Switching Architecture (MPLS)
+                 Operation and Maintenance (OAM) Functions", RFC 3429,
+                 November 2002.
+
+   [OAM-Mng]     Ersue, M., Ed., and B. Claise, "An Overview of the IETF
+                 Network Management Standards", RFC 6632, June 2012.
+
+   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal,
+                 "MPLS On-Demand Connectivity Verification and Route
+                 Tracing", RFC 6426, November 2011.
+
+   [OWAMP]       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
+                 M. Zekauskas, "A One-way Active Measurement Protocol
+                 (OWAMP)", RFC 4656, September 2006.
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 43]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [PARIS]       Augustin, B., Friedman, T., and R. Teixeira, "Measuring
+                 Load-balanced Paths in the Internet", IMC '07
+                 Proceedings of the 7th ACM SIGCOMM conference on
+                 Internet measurement, 2007.
+
+   [PM-CONS]     Clark, A. and B. Claise, "Guidelines for Considering
+                 New Performance Metric Development", BCP 170, RFC 6390,
+                 October 2011.
+
+   [PW-ACH]      Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
+                 for Use over an MPLS PSN", RFC 4385, February 2006.
+
+   [PW-G-ACh]    Li, H., Martini, L., He, J., and F. Huang, "Using the
+                 Generic Associated Channel Label for Pseudowire in the
+                 MPLS Transport Profile (MPLS-TP)", RFC 6423, November
+                 2011.
+
+   [PW-MAP]      Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
+                 Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
+                 Operations, Administration, and Maintenance (OAM)
+                 Message Mapping", RFC 6310, July 2011.
+
+   [Reorder]     Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
+                 S., and J. Perser, "Packet Reordering Metrics", RFC
+                 4737, November 2006.
+
+   [Signal]      Yasukawa, S., Ed., "Signaling Requirements for Point-
+                 to-Multipoint Traffic-Engineered MPLS Label Switched
+                 Paths (LSPs)", RFC 4461, April 2006.
+
+   [TCPIP-Tools] Kessler, G. and S. Shepard, "A Primer On Internet and
+                 TCP/IP Tools and Utilities", FYI 30, RFC 2151, June
+                 1997.
+
+   [TP-CC-CV]    Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
+                 "Proactive Connectivity Verification, Continuity Check,
+                 and Remote Defect Indication for the MPLS Transport
+                 Profile", RFC 6428, November 2011.
+
+   [TP-Fault]    Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M.,
+                 Ed., Boutros, S., and D. Ward, "MPLS Fault Management
+                 Operations, Administration, and Maintenance (OAM)", RFC
+                 6427, November 2011.
+
+   [TP-LM-DM]    Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
+                 Delay Measurement Profile for MPLS-Based Transport
+                 Networks", RFC 6375, September 2011.
+
+
+
+Mizrahi, et al.               Informational                    [Page 44]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   [TP-OAM-FW]   Busi, I., Ed., and D. Allan, Ed., "Operations,
+                 Administration, and Maintenance Framework for MPLS-
+                 Based Transport Networks", RFC 6371, September 2011.
+
+   [TP-Term]     van Helvoort, H., Ed., Andersson, L., Ed., and N.
+                 Sprecher, Ed., "A Thesaurus for the Interpretation of
+                 Terminology Used in MPLS Transport Profile (MPLS-TP)
+                 Internet-Drafts and RFCs in the Context of the ITU-T's
+                 Transport Network Recommendations", RFC 7087, December
+                 2013.
+
+   [TRILL-OAM]   Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R.
+                 Watve, "Requirements for Operations, Administration,
+                 and Maintenance (OAM) in Transparent Interconnection of
+                 Lots of Links (TRILL)", RFC 6905, March 2013.
+
+   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
+                 J. Babiarz, "A Two-Way Active Measurement Protocol
+                 (TWAMP)", RFC 5357, October 2008.
+
+   [VCCV]        Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
+                 Virtual Circuit Connectivity Verification (VCCV): A
+                 Control Channel for Pseudowires", RFC 5085, December
+                 2007.
+
+   [VCCV-SURVEY] Del Regno, N., Ed., and A. Malis, Ed., "The Pseudowire
+                 (PW) and Virtual Circuit Connectivity Verification
+                 (VCCV) Implementation Survey Results", RFC 7079,
+                 November 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 45]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+Appendix A.  List of OAM Documents
+
+A.1.  List of IETF OAM Documents
+
+   Table 5 summarizes the OAM-related RFCs produced 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 RFCs that define the requirements or the framework of
+   OAM in a specific context (e.g., MPLS-TP).
+
+   The RFCs in the table are categorized in a few sets as defined in
+   Section 1.3.
+
+   +-----------+--------------------------------------+----------+
+   | Toolset   | 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]                             |          |
+
+
+
+Mizrahi, et al.               Informational                    [Page 46]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   |           +--------------------------------------+----------+
+   |           | 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) [BFD]                          |          |
+   |           +--------------------------------------+----------+
+   |           | Bidirectional Forwarding Detection   | RFC 5881 |
+   |           | (BFD) for IPv4 and IPv6 (Single Hop) |          |
+   |           | [BFD-IP]                             |          |
+   |           +--------------------------------------+----------+
+   |           | Generic Application of Bidirectional | RFC 5882 |
+   |           | Forwarding Detection (BFD)[BFD-Gen]  |          |
+   |           +--------------------------------------+----------+
+   |           | Bidirectional Forwarding Detection   | RFC 5883 |
+   |           | (BFD) for Multihop Paths [BFD-Multi] |          |
+   |           +--------------------------------------+----------+
+   |           | Bidirectional Forwarding Detection   | RFC 5884 |
+   |           | (BFD) 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]           |          |
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 47]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   |           +--------------------------------------+----------+
+   |           | Bidirectional Forwarding Detection   | RFC 5884 |
+   |           | for MPLS Label Switched Paths (LSPs) |          |
+   |           | [BFD-LSP]                            |          |
+   +-----------+--------------------------------------+----------+
+   |MPLS-TP    | Requirements for Operations,         | RFC 5860 |
+   |OAM        | Administration, and Maintenance (OAM)|          |
+   |           | in MPLS Transport Networks           |          |
+   |           | [MPLS-TP-OAM]                        |          |
+   |           +--------------------------------------+----------+
+   |           | MPLS Generic Associated Channel      | RFC 5586 |
+   |           | [G-ACh]                              |          |
+   |           +--------------------------------------+----------+
+   |           | Operations, Administration, and      | RFC 6371 |
+   |           | Maintenance Framework for MPLS-Based |          |
+   |           | Transport Networks [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]                               |          |
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 48]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   |           +--------------------------------------+----------+
+   |           | 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]             |          |
+   |           +--------------------------------------+----------+
+   |           | MPLS and Ethernet Operations,        | RFC 7023 |
+   |           | Administration, and Maintenance (OAM)|          |
+   |           | Interworking [Eth-Int]               |          |
+   +-----------+--------------------------------------+----------+
+   |OWAMP and  | A One-way Active Measurement Protocol| RFC 4656 |
+   |TWAMP      | (OWAMP) [OWAMP]                      |          |
+   |           +--------------------------------------+----------+
+   |           | A Two-Way Active Measurement Protocol| RFC 5357 |
+   |           | (TWAMP) [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]                                |          |
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 49]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   +-----------+--------------------------------------+----------+
+   |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 tools defined by the IETF, the IEEE and ITU-T
+   have also defined various OAM tools that focus on Ethernet and
+   various other transport-network environments.  These various 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 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 the IETF OAM tools listed above and are
+   mentioned here only as reference material.
+
+   o  OAM 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 for
+      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 that
+   in some cases operators use a multi-layered OAM approach, which is a
+   function of the way their networks are designed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 50]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   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                                | Document      |
+   +-----------+--------------------------------------+---------------+
+   |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)       |               |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 51]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+   |           +--------------------------------------+---------------+
+   |           | 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
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 52]
+
+RFC 7276                  Overview of OAM Tools                June 2014
+
+
+Authors' Addresses
+
+   Tal Mizrahi
+   Marvell
+   6 Hamada St.
+   Yokneam  20692
+   Israel
+
+   EMail: talmi@marvell.com
+
+
+   Nurit Sprecher
+   Nokia Solutions and 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mizrahi, et al.               Informational                    [Page 53]
+
-- 
cgit v1.2.3