Operations and Management Area Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational N. Sprecher Expires:JanuaryApril 2014 Nokia Siemens Networks E. Bellagamba Ericsson Y. WeingartenJuly 9,October 21, 2013 An Overview of Operations, Administration, and Maintenance (OAM)Mechanisms draft-ietf-opsawg-oam-overview-09.txtData Plane Tools draft-ietf-opsawg-oam-overview-10.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAMmechanismstools have been defined for various layers in the protocolstack, and are used with a varietystack. This document summarizes some of the data plane OAM tools defined in the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for the transportprotocols. Thisprofile (MPLS-TP), and TRILL. The target audience of this documentpresentsincludes network equipment vendors, network operators and standard development organizations, and can be used as anoverviewindex to some of the main data plane OAM toolsthat have beendefinedbyin the IETF. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onJanuary 9,April 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 1.1. Background .............................................. 4 1.2. Target Audience..........................................45 1.3. OAM-related Work in the IETF ............................ 5 1.4. Focusing on Data Plane OAM Tools ........................ 6 2. Terminology ..................................................67 2.1. Abbreviations ...........................................67 2.2. Terminology used in OAM Standards .......................89 2.2.1. General Terms ......................................89 2.2.2. Operations, Administration and Maintenance ......... 9 2.2.3. Functions,Mechanisms,Tools and Protocols......... 8 2.2.3...................... 9 2.2.4. Data Plane, Control Plane and Management Plane..... 9 2.2.4..... 10 2.2.5. The Players .......................................10 2.2.5.11 2.2.6. Proactive and On-demand Activation ................11 2.2.6.12 2.2.7. Connectivity Verification and Continuity Checks ...11 2.2.7. Failures ..........................................12 2.2.8. Connection Oriented vs. Connectionless Communication13 2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14 2.2.10. Failures ......................................... 14 3. OAM Functions ...............................................1215 4. OAMMechanismsTools in the IETF - a DetailedDescription.......... 13Description .............. 16 4.1. IP Ping ................................................1316 4.2. IP Traceroute ..........................................1416 4.3. Bidirectional Forwarding Detection (BFD) ...............1517 4.3.1. Overview ..........................................1517 4.3.2. Terminology .......................................1518 4.3.3. BFD Control .......................................1518 4.3.4. BFD Echo ..........................................1618 4.4. MPLS OAM ...............................................1619 4.5. MPLS-TP OAM ............................................1720 4.5.1. Overview ..........................................1720 4.5.2. Terminology .......................................1720 4.5.3. Generic Associated Channel ........................1922 4.5.4. MPLS-TP OAM Toolset ...............................1922 4.5.4.1. Continuity Check and Connectivity Verification2023 4.5.4.2. Route Tracing ................................2023 4.5.4.3. Lock Instruct ................................2023 4.5.4.4. Lock Reporting ...............................2124 4.5.4.5. Alarm Reporting ..............................2124 4.5.4.6. Remote Defect Indication .....................2124 4.5.4.7. Client Failure Indication ....................2124 4.5.4.8. Performance Monitoring .......................2124 4.5.4.8.1. Packet Loss Measurement (LM) ............2224 4.5.4.8.2. Packet Delay Measurement (DM) ...........2225 4.6. Pseudowire OAM .........................................2326 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) ......................................2326 4.6.2. Pseudowire OAM using G-ACh ........................2427 4.6.3. Attachment Circuit - Pseudowire Mapping ...........2427 4.7. OWAMP and TWAMP.........................................2427 4.7.1. Overview ..........................................2427 4.7.2. Control and Test Protocols ........................2528 4.7.3. OWAMP .............................................2528 4.7.4. TWAMP .............................................2629 4.8. TRILL ..................................................2629 4.9. Summary of OAMMechanisms .............................. 27Tools ................................... 30 4.10. Summary of OAM Functions ..............................2932 5. Security Considerations .....................................3033 6. IANA Considerations .........................................3134 7. Acknowledgments .............................................3134 8. References ..................................................3134 8.1. Informative References .................................3134 Appendix A. List of OAM Documents ..............................3640 A.1. List of IETF OAM Documents .............................3640 A.2. List of Selected Non-IETF OAM Documents ................4144 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting failures and for monitoring the network performance. There are several different interpretations to the "OAM" acronym. This document refers to Operations, Administration and Maintenance, as recommended in[OAM-Def].Section 3 of [RFC6291]. This document summarizes some of the data plane OAM toolsand mechanismsdefined in theIETF.IETF in the context of IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. This document focuses on data plane OAM tools. Hence, control and management aspects of OAM are outside the scope of this document. This document focuses on tools for detecting and isolating failures and for performance monitoring. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are out of the scope of this document. 1.1. Background OAM was originally used in traditionaltransportcommunication technologies such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM was probably the first technology to include inherent OAMmechanismssupport from day one, while in othertransporttechnologies OAM was typically defined in an ad hoc manner after the technology was already defined and deployed. Packet-based networks were traditionally considered unreliable and best-effort, but as packet-based networks evolved, they have become the common transport for both data and telephony, replacing traditional transport protocols. Consequently, packet-based networks were expected to provide a similar "carrier grade" experience, and specifically to support OAM. As typical networks have a multi-layer architecture, the set of OAMtypically hasprotocols similarly take a multi-layerarchitecture;structure; eachtransport technologylayer has its own OAMmechanisms.protocols. Moreover, OAM can be used at different levels of hierarchy in the network to form a multi-layer OAM solution, as shown in the example in Figure 1. Figure 1 illustrates a network in which IP traffic between two customer edges is transported over an MPLS provider network. MPLS OAM is used at the provider-level for monitoring the connection between the two provider edges, while IP OAM is used at the customer-level for monitoring the end-to-end connection between the two customer edges. |<-------------- Customer-level OAM -------------->| IP OAM (Ping, Traceroute, OWAMP, TWAMP) |<- Provider-level OAM ->| MPLS OAM (LSP Ping) +-----+ +----+ +----+ +-----+ | | | |========================| | | | | |-------| | MPLS | |-------| | | | IP | | | | IP | | +-----+ +----+ +----+ +-----+ Customer Provider Provider Customer Edge Edge Edge Edge Figure 1 Example: Multi-layer OAM 1.2. Target Audience The target audience of this document includes: o Standard development organizations - both IETF working groups and non-IETF organizations can benefit from this document when designing new OAM protocols, or when looking to reuse existing OAMmechanismstools for newtransporttechnologies. o Network equipment vendors and network operators - can use this document as an index toexistingsome of the common IETF OAMmechanisms, and their connection to various transport technologies.tools. It should be noted that this document is not necessarily suitable for beginners without any background in OAM. 1.3. OAM-related Work in the IETF This memo provides an overview of the different sets of OAMmechanismstools defined by the IETF. The set of OAMmechanismstools described in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. While OAMmechanismstools 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 andmechanismstools in several different contexts. We roughly categorize these efforts into a few sets ofOAM-relatedOAM- related RFCs, listed in Table 1. Each category defines alogically-coupledlogically- coupled set of RFCs, although the sets are in some cases intertwined by common tools and protocols. The discussion in this document is ordered according to these categories. +--------------+------------+ | Category | Transport | | | Technology | +--------------+------------+ |IP Ping | IPv4/IPv6 | +--------------+------------+ |IP Traceroute | IPv4/IPv6 | +--------------+------------+ |BFD | generic | +--------------+------------+ |MPLS OAM | MPLS | +--------------+------------+ |MPLS-TP OAM | MPLS-TP | +--------------+------------+ |Pseudowire OAM| Pseudowires| +--------------+------------+ |OWAMP and | IPv4/IPv6 | |TWAMP | | +--------------+------------+ |TRILL OAM | TRILL | +--------------+------------+ Table 1 Categories of OAM-related IETF Documents 1.4. Focusing on Data Plane OAM Tools OAM tools may, and quite often do, work in conjunction with a control plane and/or management plane. At the data plane, OAM provides instrumentation tools. OAM tools often use control plane functions, e.g., to initialize OAM sessions and to exchange various parameters. The OAM tools communicate with the management plane to raise alarms, and often OAM tools may be activated by the management (as well as by the control plane), e.g. to locate and localize problems. The considerations of the control plane maintenance tools and the functionality of the management plane are out of scope for this document, which concentrates on presenting the data plane tools that are used for OAM. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. Since OAM protocols are used for monitoring the data plane, it is imperative for OAM tools to be capable of testing the actual data plane in as much accuracy as possible. Thus, it is important to enforce fate-sharing between OAM traffic that monitors the data plane and theuser-trafficdata plane traffic it monitors. 2. Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal ATM Asynchronous Transfer Mode BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement ECMP Equal Cost Multiple Paths FEC Forwarding Equivalence Class FRR Fast Reroute G-ACh Generic Associated Channel GAL Generic Associated Label ICMP Internet Control Message Protocol L2TP Layer Two Tunneling Protocol LCCE L2TP Control Connection Endpoint LDP Label Distribution Protocol LER Label Edge Router LM Loss Measurement LSP Label Switched Path LSR Label Switched Router ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance PDH Plesiochronous Digital Hierarchy PE Provider Edge PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RBridge Routing Bridge RDI Remote Defect Indication SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networking TRILL Transparent Interconnection of Lots of Links TTL Time To Live VCCV Virtual Circuit Connectivity Verification 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. An interesting overview of the term OAM and its derivatives is presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. 2.2.2.Functions, Mechanisms, ToolsOperations, Administration andProtocols OAM FunctionMaintenance The following definition of OAM isa groupquoted from [OAM-Def]: The components offunctionsthe "OAM" acronym (and provisioning) are defined as follows: o Operations - Operation activities are undertaken to keep the network (and the services thatprovidethe networkfault indication, performance information, and dataprovides) up anddiagnosis functions (based onrunning. It includes monitoring thedefinitionnetwork and finding problems. Ideally these problems should be found before users are affected. o Administration - Administration activities involve keeping track ofOAMresources in theATM Forum Glossary). This definition impliesnetwork and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control. o Maintenance - Maintenance activities are focused on facilitating repairs and upgrades -- for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more effectively, e.g., adjusting device configuration and parameters. 2.2.3. Functions, Tools and Protocols OAM Function An OAM function is an instrumentation measurement type or diagnostic. OAM functions are the atomic building blocks of OAM, where each function defines an OAM capability. Typical examples of OAM functions are presented in Section 3. OAM Protocol A protocol used for implementing one or more OAM functions. The OWAMP-Test [OWAMP] is an example of an OAM protocol. OAMMechanismTool An OAMMechanism, sometimes referred to as an OAM tool,tool is amechanism that implementsspecific means of applying one or more OAM functions. In some cases an OAM protocol *is* an OAMmechanism,tool, e.g.,OWAMP- Test.OWAMP-Test. In other cases an OAMmechanismtool uses a set of protocols that are not strictly OAM-related; for example, Traceroute (Section 4.2.) can be implemented using UDP and ICMP messages, without using an OAM protocol per se.The terms tool and mechanism are used interchangeably in this document. 2.2.3.2.2.4. Data Plane, Control Plane and Management Plane Data Plane TheData Planedata plane istypically described as the hardware and software components responsible for receiving a packet, performing lookups to identifythepacket's destination and possible actions that needset of functions used tobe performed on the packet, and forwarding the packet out throughtransfer data in theappropriate outgoing interface (based on [Cont]).stratum or layer under consideration [ITU-Terms]. . The Data Plane is also known as the Forwarding Plane or the User Plane. Control Plane TheControl Plane, as described in [Cont],control plane isgenerally described asthehardwareset of protocols andsoftware components for handling packets destinedmechanisms that enable routers tothe device itself as well as building and sendingefficiently learn how to forward packetsoriginated locallytowards their final destination (based onthe device.[Comp]). Management PlaneThisThe term Management Plane, as described in[Mgmt],[Mng], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. Data Plane vs. Control Plane vs. Management Plane The distinction between the planes is at times a bit vague. For example, the definition of "Control Plane" above may imply that OAM tools such as ping, BFD and others are in fact in the control plane. This document focuses on data plane OAM tools, i.e., tools used for monitoring the data plane. While these tools could arguably be considered to be in the control plane, these tools monitor the data plane, and hence it is imperative to have fate-sharing between OAM traffic that monitors the data plane and the data plane traffic it monitors. Another potentially vague distinction is between the management plane and control plane. The management plane should be seen as separate from, but possibly overlapping with, the control plane (based on[Mgmt]). 2.2.4.[Mng]). 2.2.5. The Players An OAMmechanismtool is used between two (or more) "players". Various terms are used in IETF documents to refer to the players that take part in OAM. Table 2 summarizes the terms used in each of the categories discussed in this document. +--------------------------+--------------------------+ | Category | Terms | +--------------------------+--------------------------+ | Ping / Traceroute |-Host | | ([ICMPv4], [ICMPv6], |-Node | | [TCPIP-Tools]) |-Interface | | |-Gateway | + ------------------------ + ------------------------ + | BFD [BFD] | System | + ------------------------ + ------------------------ + | MPLS OAM [MPLS-OAM-FW] | LSR | + ------------------------ + ------------------------ + | MPLS-TP OAM [TP-OAM-FW] |-End Point - MEP | | |-Intermediate Point - MIP | + ------------------------ + ------------------------ + | Pseudowire OAM [VCCV] |-PE | | |-LCCE | + ------------------------ + ------------------------ + | OWAMP and TWAMP |-Host | | ([OWAMP], [TWAMP]) |-End system | + ------------------------ + ------------------------ + | TRILL OAM [TRILL-OAM] |-RBridge | +--------------------------+--------------------------+ Table 2 Maintenance Point Terminology2.2.5.2.2.6. Proactive and On-demand Activation The different OAM tools may be used in one of two basic types of activation: Proactive Proactive activation - indicates that the tool is activated on a continual basis, where messages are sent periodically, and errors are detected when a certain number of expected messages are not received. On-demand On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly.2.2.6.2.2.7. Connectivity Verification and Continuity Checks Two distinct classes of failure management functions are used in OAM protocols, connectivity verification and continuity checks. The distinction between these terms is defined in [MPLS-TP-OAM], and is used similarly in this document. Continuity Check Continuity checks are used to verify that a destination is reachable, and are typically sent proactively, though they can be invoked on- demand as well. Connectivity Verification A connectivity verification function allows Alice to check whether she is connected to Bob or not. This function also allows Alice to verify that messages from Bob are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes. It is noted that while the CV function is performed in the data plane, the "expected path" is predetermined either in the control plane or in the management plane. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other.2.2.7. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to2.2.8. Connection Oriented vs. Connectionless Communication Connection Oriented In Connection Oriented technologies an end-to-end connection is established (by amalfunction that can be detectedcontrol protocol or provisioned by aconnectivity ormanagement system) prior to the transmission of data. Typically acontinuity check.connection identifier is used to identify the connection. Insome standards, such as 802.1ag [IEEE802.1Q] , thereconnection oriented technologies it isno distinctionoften 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 betweenthese terms, whileend points without prior arrangement. Packets are routed independently based on their destination address, and hence different packets may be routed inother standards each of these terms refers toa differenttype of malfunction.way across the network. Discussion Theterminology used in IETF MPLS-TPOAMtakes after the ITU-T, which distinguishes between these termstools described in[ITU-T-G.806]; Fault The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect The term Defect refers to an interruption in the normal operation, suchthis document include tools that support connection oriented technologies, as well as tools for connectionless technologies. In connection oriented technologies OAM is used to monitor aconsecutive period of time where no*specific* connection; OAM packets aredelivered successfully. Failure The term Failure refers toforwarded through thetermination ofsame route as therequired function. While a Defect typically refers to a limited period of time,data traffic and receive the same treatment. In connectionless technologies, OAM is used between afailure refers tosource and destination pair without defining along periodspecific connection. Moreover, in some cases the route oftime. 3.OAMFunctions This subsection provides a brief summarypackets may differ from the one of thecommon OAM functions used in OAM-related standards. These functions are used as building blocks indata traffic. For example, theOAM standards described in this document. o Connectivity Verification (CV) and/or Continuity Checks (CC): As defined in Section 2.2.6. o Path Discovery / Fault Localization: This mechanism can be used to traceconnectionless IP Ping (Section 4.1.) tests theroutereachability from a source to a given destination,i.e., to identify the nodes along the route towhile thedestination. When more than one routeconnection oriented LSP Ping (Section 4.4.) isavailable toused for monitoring a specificdestination, this mechanism traces one ofLSP (connection), and provides theavailable routes. When a failure occurs, this mechanism also allowscapability todetect the location of the failure. Note thatmonitor all theterm route tracing (or Traceroute) that isavailable paths usedin the context ofby an LSP. It should be noted that in some cases connectionless protocols are monitored by connection oriented OAM protocols. For example, while IPand MPLS,issometimes referreda connectionless protocol, it can monitored by BFD (Section 4.3. ), which is connection oriented. 2.2.9. Point-to-point vs. Point-to-multipoint Services Point-to-point (P2P) A P2P service delivers data from a single source to a single destination. Point-to-multipoint (P2MP) An P2MP service delivers data from a single source to a one or more destinations (based on [Signal]). [Signal] also defines a MP2MP service aspath tracinga service that delivers data from more than one source to one or more receivers. Discussion The OAM tools described inother transport technologies, suchthis document include tools for P2P services, asTRILL. o Performance Monitoring: Typically refers to: o Loss Measurement (LM) - monitors the packet loss rate. o Delay Measurement (DM) - monitors the delaywell as tools for P2MP services. The distinction between P2P services anddelay variation. 4. OAM Mechanisms inP2MP services affects theIETF - a Detailed Description This section presents a detailed descriptioncorresponding OAM tools. A P2P service is typically simpler to monitor, as it consists ofthe setsa single pair ofOAM- related mechanismsend points. P2MP services present several challenges. For example, in a P2MP service, the OAM mechanism not only verifies that each of thecategories in Table 1. 4.1. IP Ping Pingdestinations isa common network diagnosis application for IP networksreachable from the source, but also verifies thatuses ICMP. 'Ping'the P2MP distribution tree isan abbreviation for Packet internet groper [NetTerms]. As definedintact and loop-free. Another challenge in[NetTerms], itP2MP services isa program used to test reachability of destinationsperformance monitoring; while in P2P packet loss is measured bysending them an ICMP echo requestmaintaining packet counters at the two end-points, in P2MP packet loss must be carefully measured by generating synthetic traffic to each corresponding end-point andwaiting formaintaining areply.separate counter for each peer end-point. 2.2.10. Failures TheICMP Echo request/reply exchange in Ping is used as a continuity check function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4,terms Failure, Fault, and[ICMPv6] isDefect are usedfor IPv6. Ping implementations typically use ICMP messages. UDP Ping isinterchangeably in the standards, referring to avariantmalfunction thatuses UDP messages instead of ICMP echo messages. Ping iscan be detected by a connectivity or asingle-endedcontinuitycheck, 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 filteringcheck. In some standards, such as 802.1ag [IEEE802.1Q] , there isdeployedno distinction between these terms, while insome routers and firewalls, the usefulnessother standards each ofPing is sometimes limitedthese terms refers to a different type of malfunction. The terminology used inthe wider internet. This limitationIETF MPLS-TP OAM isequally relevantbased on the ITU-T terminology, which distinguishes between these three terms in [ITU-T-G.806]; Fault The term Fault refers toTraceroute. 4.2. IP Traceroute Traceroute ([TCPIP-Tools], [NetTools]) isanapplication that allows usersinability todiscoverperform apath between an IP source andrequired action, e.g., anIP destination.unsuccessful attempt to deliver a packet. Defect Themost common wayterm Defect refers toimplement Traceroute [TCPIP-Tools] is describedan interruption in the normal operation, such asfollows. Traceroute sendsasequenceconsecutive period ofUDPtime where no packetsto UDP port 33434 atare delivered successfully. Failure The term Failure refers to thedestination. By default, Traceroute begins by sending three packets (the numbertermination ofpackets is configurable in most Traceroute implementations), each with an IP Time-To-Live (or Hop Limit in IPv6) valuethe required function. While a Defect typically refers to a limited period ofonetime, a failure refers to a long period of time. 3. OAM Functions This subsection provides a brief summary of thedestination.common OAM functions used in OAM-related standards. Thesepackets expire as soonfunctions are used asthey reach the first routerbuilding blocks in thepath. Consequently, that router sends three ICMP Time Exceeded Messages backOAM standards described in this document. o Connectivity Verification (CV) and/or Continuity Checks (CC): As defined in Section 2.2.7. o Path Discovery / Fault Localization: This function can be used to trace theTraceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second routerroute toreturn ICMP messages. This process continues, with ever increasing values fora destination, i.e., to identify theTTL field, untilnodes along thepackets actually reachroute to the destination.Because no application listensWhen more than one route is available toport 33434 at thea specific destination, this function traces one of thedestination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicatesavailable routes. When a failure occurs, this function also allows to detect theTraceroute application that it is finished. The Traceroute program displays the round-trip delay associated with eachlocation of theattempts. It is notedfailure. Note thatTraceroute is an application, and not a protocol. As such, it has various different implementations. One ofthemost common ones uses UDP probe packets, as described above. Other implementations existterm route tracing (or Traceroute) thatuse other typesis used in the context ofprobe messages, such as ICMP or TCP. Note thatIProuting may be asymmetric. While Traceroute discovers a path between a sourceanddestination, it does not reveal the reverse path. A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been definedMPLS, is sometimes referred to as path tracing in the context ofTraceroute. These documents define several extensions, including extensions toother protocols, such as TRILL. o Performance Monitoring: Typically refers to: o Loss Measurement (LM) - monitors theICMP Destination Unreachable message, that can be used by Traceroute applications. 4.3. Bidirectional Forwarding Detection (BFD) 4.3.1. Overview While multiplepacket loss rate. o Delay Measurement (DM) - monitors the delay and delay variation. 4. OAMmechanisms have been defined for various protocolsTools in theprotocol stack, Bidirectional Forwarding Detection [BFD], defined by theIETFBFD working group, is- ageneric OAM mechanism that can be deployed over various encapsulating protocols, andDetailed Description This section presents a detailed description of the sets of OAM- related tools invarious medium types. The IETF has defined variantseach of theprotocol forcategories in Table 1. 4.1. IP([BFD-IP], [BFD-Multi]),Ping Ping is a common network diagnosis application forMPLS LSPs [BFD-LSP], andIP networks that uses ICMP. According to [NetTerms], 'Ping' is an abbreviation forpseudowires [BFD-VCCV]. The usage of BFDPacket internet groper, although the term has been so commonly used that it stands on its own. As defined inMPLS-TP[NetTerms], it isdefined in [TP-CC-CV]. BFD includes two main OAM functions, using two typesa program used to test reachability ofBFD packets: BFD Control packets,destinations by sending them an ICMP echo request andBFD Echo packets. 4.3.2. Terminology BFD operates between two *systems*.waiting for a reply. TheBFD protocolICMP Echo request/reply exchange in Ping isrun between two systems after establishing a *session*. 4.3.3. BFD Control BFD supportsused as abidirectionalcontinuitycheck, 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. Whencheck function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiverdetects that no BFD control packets have been received during a predetermined period of time, a failurereplies with an Echo reply. ICMP ping isdetected. o Demand mode:defined inthis mode, BFD control packets are sent on-demand. Upon need, a system initiatestwo variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. Ping implementations typically use ICMP messages. UDP Ping is aseriesvariant that uses UDP messages instead ofBFD control packets to check theICMP echo messages. Ping is a single-ended continuityofcheck, i.e., it allows thesession. BFD control packets are sent independently in each direction. Each*initiator* of theend-points (referredEcho request toas systems) oftest themonitored path maintains its own session identification, called a Discriminator,reachability. If it is desirable for bothof which are included inends to test theBFD Control Packetsreachability, both ends have to invoke Ping independently. Note thatare exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) ratesince ICMP filtering isnegotiated between the two end-points, based on information includeddeployed in some routers and firewalls, thecontrol packets. These transmission rates may be renegotiated during the session. During normal operationusefulness ofthe session, i.e. no failures are detected, the BFD sessionPing is sometimes limited in theUp state. If no BFD Control packets are received during a period of time called the Detection Time, the sessionwider internet. This limitation isdeclaredequally relevant tobe Down. The detection timeTraceroute. 4.2. IP Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover afunction of the pre-configured or negotiated transmission time,path between an IP source and an IP destination. The most common way to implement Traceroute [TCPIP-Tools] is described as follows. Traceroute sends aparameter called Detect Mult. Detect Mult determinessequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number ofmissing BFD Controlpacketsthat cause the sessionis configurable in most Traceroute implementations), each with an IP Time-To-Live (or Hop Limit in IPv6) value of one tobe declaredthe destination. These packets expire asDown. This parameter is includedsoon as they reach the first router in theBFD Control packet. 4.3.4. BFD Echo A BFD echo packet is sent to a peer system, and is looped backpath. Consequently, that router sends three ICMP Time Exceeded Messages back to theoriginator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 4.4. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism defined, in this context, is LSP Ping [LSP-Ping]. LSP Ping is modeled afterTraceroute application. Traceroute now sends another three UDP packets, each with thePing/Traceroute paradigm and thus it may be used in oneTTL value oftwo modes: o "Ping" mode: In this mode LSP Ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends2. These messages cause thebasicsecond router to return ICMPPing operation (of data-plane connectivity verification)messages. This process continues, withfunctionality to verify data-plane vs. control-plane consistencyever increasing values fora Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. The Traceroute functionality may be used to isolate and localizetheMPLS faults, usingTTL field, until theTime-to-live (TTL) indicatorpackets actually reach the destination. Because no application listens toincrementally identifyport 33434 at thesub-path ofdestination, theLSPdestination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it issuccessfully traversed beforefinished. The Traceroute program displays thefaulty link or node. It should be noted that LSP Ping supports unique identificationround-trip delay associated with each of theLSP within an addressing domain. The identificationattempts. While Traceroute ischecked using the full FEC identification. LSP Pinga tool that finds *a* path from A to B, it should be noted that traffic from A to B iseasily extensibleoften forwarded through Equal Cost Multiple Paths (ECMP). Paris Traceroute [Paris] is an extension toinclude additional information neededTraceroute that attempts tosupport new functionality,discovers all the available paths from A to B byuse of Type-Length-Value (TLV) constructs. The usagescanning different values ofTLVs is typically not easy to performheader fields (such as UDP ports) inhardware, and is thus typically handled bythecontrol plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 4.5. MPLS-TP OAM 4.5.1. Overview The MPLS working groupprobe packets. It is noted that Traceroute is an application, and not a protocol. As such, it hasdefinedvarious different implementations. One of theOAM toolsetmost common ones uses UDP probe packets, as described above. Other implementations exist thatfulfills the requirements for MPLS-TP OAM. The full setuse other types ofrequirements for MPLS- TP OAM areprobe messages, such as ICMP or TCP. Note that IP routing may be asymmetric. While Traceroute discovers a path between a source and destination, it does not reveal the reverse path. A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in[MPLS-TP-OAM], and include both general requirements forthebehaviorcontext of Traceroute. These documents define several extensions, including extensions to theOAM mechanisms and a set of operationsICMP Destination Unreachable message, thatshouldcan besupportedused bythe OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for theTraceroute applications. 4.3. Bidirectional Forwarding Detection (BFD) 4.3.1. Overview While multiple OAMtoolsettools have been defined forMPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand,various protocols inenvironments where IP functionality is not available,theOAM tools must still be able to operate without dependence on IP forwarding and routing. o OAM packets andprotocol stack, Bidirectional Forwarding Detection [BFD], defined by theuser traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and thereIETF BFD working group, is aneed to differentiategeneric OAMpackets from data plane ones. Inherent in this requirement is the principletool thatMPLS-TP OAMcan beindependent of any existing control-plane, although it should not preclude usedeployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of thecontrol-plane functionality. 4.5.2. Terminology Maintenance Entity (ME)protocol for IP ([BFD- IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- VCCV]. The usage of BFD in MPLS-TPOAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, asis defined in[TP-OAM-FW], defines a relationship between[TP-CC-CV]. BFD includes twopointsmain OAM functions, using two types ofa transport path to which maintenanceBFD packets: BFD Control packets, andmonitoring operations apply.BFD Echo packets. 4.3.2. Terminology BFD operates between two *systems*. Theterm Maintenance Entity (ME)BFD protocol isused in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well asrun between two systems after establishing a *session*. 4.3.3. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate inthe MPLS-TP terminology ([TP-OAM-FW]). Maintenance Entity Group (MEG) The collection ofoneor more MEs that belongs toof two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When thesame transport path andreceiver detects thatare maintained and monitored asno BFD control packets have been received during agroup are known aspredetermined period of time, aMaintenance Entity Group (based on [TP-OAM-FW]). Maintenance Point (MP) A Maintenance Point (MP)failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, afunctional entity that is defined atsystem initiates anode in the network, and can initiate and/or reactseries of BFD control packets toOAM messages. This document focuses oncheck thedata-plane functionalitycontinuity ofMPs, while MPs interact withthe session. BFD controlplane and withpackets are sent independently in each direction. Each of themanagement planeend-points (referred to aswell. The term MP is used in IEEE 802.1ag, and was similarly adopted in MPLS-TP ([TP-OAM-FW]). Maintenance End Point (MEP) A Maintenance End Point (MEP) is onesystems) of theend pointsmonitored path maintains its own session identification, called a Discriminator, both ofan ME, and can initiate OAM messages and respond to them (based on [TP-OAM-FW]). Maintenance Intermediate Point (MIP) In between MEPs, therewhich arezero or more intermediate points, called Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). A Maintenance Intermediate Point (MIP) is an intermediate point that does not generally initiate OAM frames (one exception to this isincluded in theuse of AIS notifications), but is able to respond to OAM framesBFD Control Packets that aredestined to it. A MIP in MPLS-TP identifies OAM packets destined to it byexchanged between thevalueend-points. At the time of session establishment, theTTL field inDiscriminators are exchanged between theOAM packet. The term Maintenance Pointtwo-end points. In addition, the transmission (and reception) rate isa general term for MEPs and MIPs. Up and Down MEPs The IEEE 802.1ag [IEEE802.1Q] defines a distinctionnegotiated betweenUp MEPs and Down MEPs. A MEP is a bridge interface that is monitored by an OAM protocol eitherthe two end-points, based on information included in thedirection facingcontrol packets. These transmission rates may be renegotiated during thenetwork, or insession. During normal operation of thedirection facingsession, i.e. no failures are detected, thebridge. A Down MEPBFD session isa MEP that receives OAM packets from, and transmits them to the direction ofin thenetwork. AnUpMEP receives OAMstate. If no BFD Control packetsfrom, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) usesare received during asimilar distinction on the placementperiod of time called theMEP - either atDetection Time, theingress, egress, or forwarding function of the node (Down / Up MEPs). This placementsession isimportant for localization of a failure.declared to be Down. Thedistinction between Up and Down MEPs was defined in [TP-OAM-FW], but has not been used in other MPLS-TP RFCs, as of the writingdetection time is a function ofthis document. 4.5.3. Generic Associated Channel In order to addresstherequirement for in-bandpre-configured or negotiated transmissionof 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 ACHtime, andVCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that usesaformat similar toparameter called Detect Mult. Detect Mult determines thePWnumber of missing BFD ControlWord, is a 4-byte headerpackets thatis prependedcause the session toOAM packets. o A Generic Associated Label (GAL). The GALbe declared as Down. This parameter isa reserved MPLS label value (13) that indicates thatincluded in the BFD Control packet. 4.3.4. BFD Echo A BFD echo packet isan ACH packetsent to a peer system, andthe 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-AChisa generic tool thatlooped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined inMPLS in general,BFD for IPv4 and IPv6 ([BFD-IP]), but is notonlyused inMPLS-TP. 4.5.4. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, theBFD for MPLSWG conducted an analysis of the existing IETF and ITU-T OAM mechanisms and their ability to fulfill the required functionality. The conclusions of this analysis are documentedLSPs, PWs, or in[OAM-Analys].BFD for MPLS-TP. 4.4. MPLS OAM The IETF MPLS working groupcurrently plans to use a mixture ofhas defined OAMmechanisms that are based on various existing standards, and adapt them to thefor MPLS LSPs. The requirementsof [MPLS-TP-OAM]. Some of the main building blocksand framework of thissolutioneffort arebased on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity checkdefined in [MPLS-OAM-FW] andconnectivity verification. o[MPLS-OAM], respectively. The corresponding OAM tool defined, in this context, is LSP Pingas defined in [LSP-Ping][LSP-Ping]. OAM foron-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality thatP2MP services isdescribed in [ITU-T-Y1731]. The following sub-sections describe the OAM toolsdefinedfor MPLS-TP as describedin[TP-OAM-FW]. 4.5.4.1. Continuity Check and Connectivity Verification Continuity Check[MPLS-P2MP]. LSP Ping is modeled after the Ping/Traceroute paradigm andConnectivity Verification are presented in Section 2.2.6. of this document. As presented there, these toolsthus it may be usedeither proactively or on-demand. When using these tools proactively, they are generally usedintandem. For MPLS-TP there areone of twodistinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in [OnDemand-CV].modes: o "Ping" mode: Inon-demand mode,thisfunction should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the needmode LSP Ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends theCC-V messagesbasic ICMP Ping operation (of data-plane connectivity verification) with functionality toinclude unique identification of the MEG that is being monitoredverify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) andthe MEP that originated the message.also Maximum Transmission Unit (MTU) problems. Theproactive tool [TP-CC-CV]challenge in MPLS networks isbased on extensions to BFD (see Section 4.3.) with the additional limitationthat thetransmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptationtraffic of a given LSP may be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping(see Section 4.4.) formonitors all therequired behavioravailable paths ofMPLS-TP. 4.5.4.2. Route Tracing [MPLS-TP-OAM] defines that there is a need foran LSP by monitoring its different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths. The Traceroute functionalitythat would allow a path end-pointmay be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify theintermediate and end- pointssub-path of thepath. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for thisLSP that isbased onsuccessfully traversed before the faulty link or node. It should be noted that LSP Ping(see Section 4.4.) functionality and is described in [OnDemand-CV]. 4.5.4.3. Lock Instructsupports unique identification of the LSP within an addressing domain. TheLock Instruct function [Lock-Loop]identification isusedchecked using the full FEC identification. LSP Ping is easily extensible tonotify a transport path end-pointinclude additional information needed to support new functionality, by use ofan administrative needType-Length-Value (TLV) constructs. The usage of TLVs is typically not easy todisable the transport path. This functionality will generally be usedperform inconjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 4.5.4.4. Lock Reporting Lock Reportinghardware, and isa function usedthus typically handled byan end-point of a path to report to its far-end end-point that a lock conditionthe control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 4.5. MPLS-TP OAM 4.5.1. Overview The MPLS working group hasbeen affected ondefined thepath. 4.5.4.5. Alarm Reporting Alarm Reporting [TP-Fault] providesOAM toolset that fulfills themeans to suppress alarms following detectionrequirements for MPLS-TP OAM. The full set ofdefect conditions atrequirements for MPLS- TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for theserver sub-layer. Alarm reporting is used by an intermediate pointbehavior of the OAM tools and apath, that becomes awareset ofa fault onoperations that should be supported by thepath, to report toOAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes theend-pointsgeneral architecture of thepath. [TP-OAM-FW] states that this may occurOAM system asa resultwell as giving overviews ofa defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues untilthefault is cleared. The consequent actionfunctionality ofthis functionthe OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network isdetailedIP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in[TP-OAM-FW]. 4.5.4.6. Remote Defect Indication Remote Defect Indication (RDI)environments where IP functionality isused proactively by a path end- point to reportnot available, the OAM tools must still be able toits peer end-point that a defect is detectedoperate without dependence ona bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be appliedIP forwarding and routing. o OAM packets and the user traffic are required toa unidirectional LSP only ifbe congruent (i.e. OAM packets are transmitted in-band) and there is areturn path exists. [TP-OAM-FW] points out thatneed to differentiate OAM packets from data plane ones. Inherent in thisfunction is associated with the proactive CC-V function. 4.5.4.7. Client Failure Indication Client Failure Indication (CFI)requirement isdefined in [MPLS-TP-OAM] to allowthepropagation information from one edgeprinciple that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of thenetwork to the other.control-plane functionality. 4.5.2. Terminology Maintenance Entity (ME) Theinformation concerns a defectMPLS-TP OAM tools are designed to monitor and manage aclient, in the case that the client does not support alarm notification. 4.5.4.8. Performance Monitoring The definition of MPLS performance monitoring was motivated by the MPLS-TP requirements [MPLS-TP-OAM], but wasMaintenance Entity (ME). An ME, as definedgenerically for MPLSin[MPLS-LM-DM]. An additional document [TP-LM-DM][TP-OAM-FW], defines aperformancerelationship between two points of a transport path to which maintenance and monitoringprofile for MPLS-TP. 4.5.4.8.1. Packet Loss Measurement (LM) Packet Loss Measurementoperations apply. The term Maintenance Entity (ME) isa functionusedto verify the quality of the service. Packet loss,in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well asdefinedin[IPPM-1LM] and [MPLS-TP-OAM], indicates the ratio ofthenumberMPLS-TP terminology ([TP-OAM-FW]). Maintenance Entity Group (MEG) The collection ofuser packets lostone or more MEs that belongs to thetotal number of user packets sent duringsame transport path and that are maintained and monitored as adefined time interval. Theregroup aretwo possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics basedknown as a Maintenance Entity Group (based on [TP-OAM-FW]). Maintenance Point (MP) A Maintenance Point (MP) is aseries of OAM packets. This, however, hasfunctional entity that is defined at a node in thedisadvantage of being artificial,network, andmay not be representative since partcan initiate and/or react to OAM messages. This document focuses on the data-plane functionality of MPs, while MPs interact with thepacket loss may be dependent upon packet sizescontrol plane andupon the implementation ofwith theMEPs that take partmanagement plane as well. The term MP is used inthe protocol. o Sending delimiting messages for the startIEEE 802.1ag, andendwas similarly adopted in MPLS-TP ([TP-OAM-FW]). Maintenance End Point (MEP) A Maintenance End Point (MEP) is one ofa measurement period during whichthesource and sinkend points of an ME, and can initiate OAM messages and respond to them (based on [TP-OAM-FW]). Maintenance Intermediate Point (MIP) In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). A Maintenance Intermediate Point (MIP) is an intermediate point that does not generally initiate OAM frames (one exception to this is thepath count theuse of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packetstransmitted and received. Afterdestined to it by theend delimiter,value of theratio would be calculated byTTL field in thepathOAMentity. 4.5.4.8.2. Packet Delay Measurement (DM) Packet Delay Measurementpacket. The term Maintenance Point is afunction that is used to measure one- way or two-way delay ofgeneral term for MEPs and MIPs. Up and Down MEPs The IEEE 802.1ag [IEEE802.1Q] defines apacket transmissiondistinction between Up MEPs and Down MEPs. A MEP is apair ofbridge interface that is monitored by an OAM protocol either in theend-points of a path (PW, LSP,direction facing the network, orSection). Where: o One-way packet delay, as definedin[IPPM-1DM], isthetime elapsed fromdirection facing thestart of transmission ofbridge. A Down MEP is a MEP that receives OAM packets from, and transmits them to thefirst bitdirection of thepacket by a source node untilnetwork. An Up MEP receives OAM packets from, and transmits them to thereceptiondirection of thelast bit of that packet bybridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on thedestination node. o Two-way packet delay, as defined in [IPPM-2DM], isplacement of thetime elapsed fromMEP - either at thestart of transmissioningress, egress, or forwarding function of thefirst bitnode (Down / Up MEPs). This placement is important for localization ofthe packet byasource node until the receptionfailure. 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 thelast bitwriting of this document. 4.5.3. Generic Associated Channel In order to address theloop-backed packet by the same source node, when the loopback is performed at the packet's destination node. For eachrequirement for in-band transmission ofthese two metrics,MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based on theDM function allowssame concepts as theMEPPWE3 ACH and VCCV mechanisms. However, tomeasureaddress thedelay, as wellneeds of LSPs as differentiated from PW, thedelay 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, asfollowing concepts were definedin [VCCV], provides a meansforend-to-end fault detection and diagnostics tools[G-ACh]: o An Associated Channel Header (ACH), that uses a format similar tobe extended for PWs (regardless oftheunderlying tunneling technology). The VCCV switching function provides a control channel associated with each PW. [VCCV] defines threePW ControlChannel (CC) types, i.e., three possible methods for transmitting and identifying OAM messages: o CC Type 1: In-band VCCV, as described in [VCCV],Word, isalso referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header [PW-ACH]. o CC Type 2: Out-of-band VCCV [VCCV],a 4-byte header that isalso referredprepended toas "MPLS Router Alert Label". In this case the control channelOAM packets. o A Generic Associated Label (GAL). The GAL iscreated by using thea reserved MPLSrouter alertlabel[RFC3032] immediately abovevalue (13) that indicates that thePW label. o CC Type 3: TTL expiry VCCV [VCCV],packet isalso referred to as "MPLS PW Label with TTL == 1", i.e.,an ACH packet and thecontrol channel is identified whenpayload follows immediately after thevaluelabel stack. It should be noted that while the G-ACh was defined as part of theTTL fieldMPLS-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 thePW labelfunctionality that isset to 1. VCCV currently supportsrequired of thefollowingOAMmechanisms: ICMP Ping, LSP Ping,toolset, the MPLS WG conducted an analysis of the existing IETF andBFD. ICMPITU-T OAM tools andLSP Ping are IP encapsulated before being sent overtheir ability to fulfill thePW ACH. BFD for VCCV [BFD-VCCV] supports two modesrequired functionality. The conclusions ofencapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status.this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture ofthe VCCV control channel provides the context,OAM tools that are based onthe MPLS-PW label, required to bindvarious existing standards, andbootstrap the BFD sessionadapt them toa particular pseudo wire (FEC), eliminatingtheneed to exchange Discriminator values. VCCV consistsrequirements oftwo components: (1) signaled component to communicate VCCV capabilities as part[MPLS-TP-OAM]. Some ofVC label,the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and(2) switching componentconnectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, tocauseaddress different functionality. o Performance measurement protocols that are based on thePW payload to be treated as a control packet. VCCVfunctionality that isnot directly dependent upondescribed in [ITU-T-Y1731]. The following sub-sections describe thepresenceOAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 4.5.4.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.7. ofa control plane. The VCCV capability negotiationthis document. As presented there, these tools may beperformed as part ofused either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, thePW signaling when LDPproactive tool isused. In case of manual configuration ofdefined in [TP-CC-CV] while thePW, iton-demand tool isthe responsibility of the operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too. 4.6.2. Pseudowire OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channelsdefined inVCCV, the G-ACh can be used as an alternative control channel. The usage of[OnDemand-CV]. In on-demand mode, this function should support monitoring between theG-ACh for PWs is definedMEPs and, in[PW-G-ACh]. 4.6.3. Attachment Circuit - Pseudowire Mapping The PWE3 working group has defined a mapping and notification of defect statesaddition, between apseudowire (PW)MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, theAttachment Circuits (ACs)need for the CC-V messages to include unique identification of theend-to-end emulated service. This mappingMEG that isof key importance tobeing monitored and theend-to-end functionality. Specifically,MEP that originated themappingmessage. The proactive tool [TP-CC-CV] isprovided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, andbased on extensions to BFD (see Section5.3 of [ATM-L2] for ATM. 4.7. OWAMP4.3.) with the additional limitation that the transmission andTWAMP 4.7.1. Overviewreceiving rates are based on configuration by the operator. TheIPPM working group inon-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 4.4.) for theIETFrequired behavior of MPLS-TP. 4.5.4.2. Route Tracing [MPLS-TP-OAM] definescommon criteria and metricsthat there is a need formeasuring 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 notedfunctionality that would allow a path end-point to identify theworkintermediate and end- points of theIETFpath. This function would be used inthe context of performance metrics is not limited to IP networks; [PM-CONS] presents general guidelineson-demand mode. Normally, this path will be used forconsidering new performance metrics. The IPPM working group has defined notbidirectional PW, LSP, and sections, however, unidirectional paths may be supported onlymetricsif a return path exists. The tool forperformance measurement, but also protocols that define how the measurementthis iscarried out. The One-way Active Measurement Protocol [OWAMP] andbased on theTwo-Way Active Measurement Protocol [TWAMP] define a methodLSP Ping (see Section 4.4.) functionality andprotocol for measuring performance metricsis described inIP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP][OnDemand-CV]. 4.5.4.3. Lock Instruct The Lock Instruct function [Lock-Loop] isa similar protocol that enables measurement of both one-way and two-way (round trip) characteristics. OWAMP and TWAMP are both comprised of two separate protocols: o OWAMP-Control/TWAMP-Control:used toinitiate, start, and stop test sessions andnotify a transport path end-point of an administrative need tofetch their results. Continuity Check and Connectivity Verification are tested and confirmed by establishingdisable theOWAMP/TWAMP Control Protocol TCP connection. o OWAMP-Test/TWAMP-Test:transport path. This functionality will generally be usedto 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]), andinEthernetconjunction with some intrusive OAM[ITU-T-Y1731]. 4.7.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose offunction, e.g. Performance measurement, Diagnostic testing, to minimize thecontrol protocolsside-effect on user data traffic. 4.5.4.4. Lock Reporting Lock Reporting is a function used by an end-point of a path toinitiate, start, and stop test sessions, and for OWAMPreport tofetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) alongits far-end end-point that a lock condition has been affected on theIP path under test accordingpath. 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 aschedule, and record statisticspath, that becomes aware ofpacket arrival. Multiple sessions may be simultaneously defined, each withasession identifier, and definingfault on thenumber of packetspath, tobe sent, the amount of paddingreport tobe added (and thus the packet size),thestart time, andend-points of thesend schedule (which can be eitherpath. [TP-OAM-FW] states that this may occur as aconstant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform toresult of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until therelevant IPPM RFCs. OWAMP and TWAMP test trafficfault isdesigned with securitycleared. The consequent action of this function is detailed inmind. Test packets are hard[TP-OAM-FW]. 4.5.4.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point todetect because they are simply UDP streamsreport to its peer end-point that a defect is detected on a bidirectional connection betweennegotiated port numbers,them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated withpotentially 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 definesthefollowing logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic thatproactive CC-V function. 4.5.4.7. Client Failure Indication Client Failure Indication (CFI) isreceived bydefined in [MPLS-TP-OAM] to allow theSession- Receiver. The Server configures and managespropagation information from one edge of thesession, as well as returningnetwork to theresults. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination.other. TheFetch-Client requests the results ofinformation concerns acompleted session. Multiple roles may be combined indefect to asingle host - for example, one host may playclient, in theroles of Control-Client, Fetch-Client, and Session-Sender, and a second playingcase that therolesclient does not support alarm notification. 4.5.4.8. Performance Monitoring The definition ofServer and Session-Receiver. In a typical OWAMP sessionMPLS performance monitoring was motivated by theControl-Client establishesMPLS-TP requirements [MPLS-TP-OAM], but was defined generically for MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines aTCP connectionperformance monitoring profile for MPLS-TP. 4.5.4.8.1. Packet Loss Measurement (LM) Packet Loss Measurement is a function used toport 861 ofverify theServer, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds withquality of thechosen communications modeservice. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], indicates theServer acceptsratio of themodes. The Control-Client then requests and fully describesnumber of user packets lost to the total number of user packets sent during atest sessiondefined time interval. There are two possible ways of determining this measurement: o Using OAM packets, it is possible towhichcompute theServer responds with its acceptancestatistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, andsupporting information. More than one test sessionmay not berequested with additional messages. The Control-Client then starts a test session andrepresentative since part of theServer acknowledges. The Session- Sender then sends test packets with pseudorandom padding topacket loss may be dependent upon packet sizes and upon theSession-Receiver untilimplementation of thesession is complete or untilMEPs that take part in theControl- client stopsprotocol. o Sending delimiting messages for thesession. Once finished, the Fetch-Client sendsstart and end of afetch request to the server,measurement period during whichresponds with an acknowledgementthe source andimmediately thereaftersink of theresult data. 4.7.4. TWAMP TWAMP definespath count thefollowing logical roles: session-sender, session- reflector, server,packets transmitted andcontrol-client. These are similar toreceived. After theOWAMP roles, except thatend delimiter, theSession-Reflector does not collect any packet information, and thereratio would be calculated by the path OAM entity. 4.5.4.8.2. Packet Delay Measurement (DM) Packet Delay Measurement isno need foraFetch-Client. Infunction that is used to measure one- way or two-way delay of atypical TWAMP session the Control-Client establishespacket transmission between aTCP connection to port 862pair of theServer, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 4.8. TRILL The requirementsend-points ofOAM in TRILL area path (PW, LSP, or Section). Where: o One-way packet delay, as defined in[TRILL-OAM]. The main challenge in TRILL OAM[IPPM-1DM], isthat 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 betweenthetwo RBridge. Duringtime elapsed from thewritingstart of transmission ofthis documentthedetailed definitionfirst bit of theTRILL OAM tools are still work in progress. This subsection presentspacket by a source node until themain requirementsreception of the last bit of that packet by the destination node. Note that one-way delay measurement requires the clocks ofTRILL OAM. The main requirements defined in [TRILL-OAM] are: o Continuity Checking (CC) -theTRILL OAM protocol must support a function for CC between any two RBridges RB1 and RB2. o Connectivity Verification (CV) - connectivity betweentwoRBridges RB1 and RB2 canend-points to beverified on a per-flow basis.synchronized. oPath Tracing - allows an RBridge to trace allTwo-way packet delay, as defined in [IPPM-2DM], is theavailable paths totime elapsed from the start of transmission of the first bit of the packet by apeer RBridge. o Performance monitoring - allows an RBridge to monitorsource node until the reception of the last bit of the loop-backed packetloss andby the same source node, when the loopback is performed at the packet's destination node. Note that due to possible path asymmetry, the one-way packet delay from one end- point toa peer RBridge. 4.9. Summary of OAM Mechanisms This subsection provides a short summaryanother is not necessarily equal to half of the two-way packet delay. As opposed to one-way delay measurement, two-way delay measurement does not require the two end-points to be synchronized. For each of these two metrics, theOAM mechanism categories described in this document. A detailed list ofDM function allows theRFCs relatedMEP toeach categorymeasure the delay, as well as the delay variation. Delay measurement isgivenperformed 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 inAppendix A.1. +-----------+------------------------------------------+------------+ | Category | Description | Transport | | | | Technology | +-----------+------------------------------------------+------------+ |IP Ping | Ping ([IntHost], [NetTerms]) is[VCCV], provides asimple | IPv4/IPv6 | | | applicationmeans fortesting 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 sourceend-to-end fault detection andan IP | | | | destination, i.e.,diagnostics tools toidentify the nodes | | | | along the path. If more than one path | | | | exists betweenbe extended for PWs (regardless of thesource and destination| | | | Traceroute traces *a* path.underlying tunneling technology). Themost | | | | common implementation of Traceroute | | | | uses UDP probe messages, although there | | | | are other implementations that use | | | | different probes, such as ICMP or TCP. | | +-----------+------------------------------------------+------------+ |BFD | Bidirectional Forwarding Detection (BFD) | generic | | | is defined in [BFD] asVCCV switching function provides aframeworkcontrol channel associated with each PW. [VCCV] defines three Control Channel (CC) types, i.e., three possible methods fora | | | | lightweight generictransmitting and identifying OAMmechanism. The | | | | intentionmessages: o CC Type 1: In-band VCCV, as described in [VCCV], is also referred todefine a base mechanism | | | | that can be usedas "PWE3 Control Word withvarious | | | | encapsulation types, network | | | | environments, and in various medium | | | | types. | | +-----------+------------------------------------------+------------+ |MPLS OAM | MPLS LSP Ping,0001b asdefined in [MPLS-OAM], | MPLS | | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | | | mechanism for point-to-point and | | | | point-to-multipoint MLPS LSPs. | | | | It includes two main functions: Ping and | | | | Traceroute. | | | |first nibble". It uses the PW Associated Channel Header [PW-ACH]. o CC Type 2: Out-of-band VCCV [VCCV], isnoted that whilealso referred to as "MPLS Router Alert Label". In thiscategory | | | | focuses on LSP Ping, other OAM mechanisms| | | | can be used in MPLS networks, e.g., BFD. | | +-----------+------------------------------------------+------------+ |MPLS-TP OAM| MPLS-TP OAMcase the control channel isdefined in a set of RFCs. | MPLS-TP | | | The OAM requirements forcreated by using the MPLSTransport | | | | Profile (MPLS-TP) are defined in | | | | [MPLS-TP-OAM]. Each ofrouter alert label [RFC3032] immediately above thetools inPW label. o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW Label with TTL == 1", i.e., the| | | | OAM toolsetcontrol channel isdefined in its own RFC, as| | | | specified in Section A.1. | | +-----------+------------------------------------------+------------+ |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | |OAM | channels that supportidentified when theusevalue ofexisting| | | | IETF OAM toolsthe TTL field in the PW label is set tobe used for a pseudo- | | | | wire (PW). The control channels that are| | | | defined in [VCCV] and [PW-G-ACh] may be | | | | used in conjunction with1. VCCV currently supports the following OAM tools: ICMP Ping, LSP| | | |Ping, andBFD to perform CCBFD. ICMP andCV | | | | functionality. In additionLSP Ping are IP encapsulated before being sent over thechannels | | | |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 ofany oftheMPLS-TPVCCV control channel provides the context, based| | | | OAM tools for completing their respective| | | | OAM functionality for a PW. | | +-----------+------------------------------------------+------------+ |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | |TWAMP | (OWAMP)on the MPLS-PW label, required to bind and bootstrap theTwo Way Active Measure- | | | | ment Protocols (TWAMP) are two protocols | | | | defined inBFD session to a particular pseudo wire (FEC), eliminating theIP Performance Metrics | | | | (IPPM) working group inneed to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause theIETF. These | | | | protocols allow various performance | | | | metricsPW payload to bemeasured, suchtreated aspacket | | | | loss, delay and delay variation, | | | | duplication and reordering. | | +-----------+------------------------------------------+------------+ |TRILL OAM |a control packet. VCCV is not directly dependent upon the presence of a control plane. TherequirementsVCCV capability negotiation may be performed as part ofOAM in TRILL are | TRILL | | | defined in [TRILL-OAM]. These | | | | requirements include continuity checking,| | | | connectivity verification, path tracing | | | | and performance monitoring. Duringthe| | | | writingPW signaling when LDP is used. In case ofthis document the detailed | | | | definitionmanual configuration of theTRILL OAM tools | | | |PW, it iswork in progress. | | +-----------+------------------------------------------+------------+ Table 3 Summarythe responsibility ofOAM-related IETF Mechanisms 4.10. Summarythe operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too. The PWE3 working group has conducted an implementation survey of VCCV [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in practice. 4.6.2. Pseudowire OAMFunctions Table 4 summarizes theusing G-ACh As mentioned above, VCCV enables OAMfunctions thatfor PWs by using a control channel for OAM packets. When PWs aresupportedused ineach ofMPLS-TP networks, rather than thecategories that were analyzedcontrol channels defined inthis section.VCCV, the G-ACh can be used as an alternative control channel. Thecolumnsusage ofthis tables arethetypical OAM functions describedG-ACh for PWs is defined inSection 1.3. +-----------+-------+--------+--------+-------+----------+ | |Continu|Connecti|Path |Perform|Other |[PW-G-ACh]. 4.6.3. Attachment Circuit - Pseudowire Mapping The PWE3 working group has defined a mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. This mapping is of key importance to the end-to-end functionality. Specifically, the mapping is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and Section 5.3 of [ATM-L2] for ATM. 4.7. OWAMP and TWAMP 4.7.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. It should be noted that the work of the IETF in the context of performance metrics is not limited to IP networks; [PM-CONS] presents general guidelines for considering new performance metrics. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring performance metrics in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of both one-way and two-way (round trip) characteristics. OWAMP and TWAMP are both comprised of two separate protocols: o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop test sessions and to fetch their results. Continuity Check and Connectivity Verification are tested and confirmed by establishing the OWAMP/TWAMP Control Protocol TCP connection. o OWAMP-Test/TWAMP-Test: used to exchange test packets between two measurement nodes. Enables the loss and delay measurement functions, as well as detection of other anomalies, such as packet duplication and packet reordering. It should be noted that while [OWAMP] and [TWAMP] define tools for performance measurement, they do not define the accuracy of these tools. The accuracy depends on scale, implementation and network configurations. Alternative protocols for performance monitoring are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. 4.7.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 4.7.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. 4.7.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 4.8. TRILL The requirements of OAM in TRILL are defined in [TRILL-OAM]. The challenge in TRILL OAM, much like in MPLS networks, is that traffic between RBridges RB1 and RB2 may be forwarded through more than one path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able to monitor all the available paths between the two RBridge. During the writing of this document the detailed definition of the TRILL OAM tools are still work in progress. This subsection presents the main requirements of TRILL OAM. The main requirements defined in [TRILL-OAM] are: o Continuity Checking (CC) - the TRILL OAM protocol must support a function for CC between any two RBridges RB1 and RB2. o Connectivity Verification (CV) - connectivity between two RBridges RB1 and RB2 can be verified on a per-flow basis. o Path Tracing - allows an RBridge to trace all the available paths to a peer RBridge. o Performance monitoring - allows an RBridge to monitor the packet loss and packet delay to a peer RBridge. 4.9. Summary of OAM Tools This subsection provides a short summary of each of the OAM tool categories described in this document. A detailed list of the RFCs related to each category is given in Appendix A.1. +-----------+------------------------------------------+------------+ | Category | Description | Transport | | | | Technology | +-----------+------------------------------------------+------------+ |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | | | application for testing reachability that| | | | uses ICMP Echo messages ([ICMPv4], | | | | [ICMPv6]). | | +-----------+------------------------------------------+------------+ |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | |Traceroute | an application that allows users to trace| | | | the path between an IP source and an IP | | | | destination, i.e., to identify the nodes | | | | along the path. If more than one path | | | | exists between the source and destination| | | | Traceroute traces *a* path. The most | | | | common implementation of Traceroute | | | | uses UDP probe messages, although there | | | | are other implementations that use | | | | different probes, such as ICMP or TCP. | | +-----------+------------------------------------------+------------+ |BFD | Bidirectional Forwarding Detection (BFD) | generic | | | is defined in [BFD] as a framework for a | | | | lightweight generic OAM tool. The | | | | intention is to define a base tool | | | | that can be used with various | | | | encapsulation types, network | | | | environments, and in various medium | | | | types. | | +-----------+------------------------------------------+------------+ |MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS | | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | | | tool for point-to-point and | | | | point-to-multipoint MLPS LSPs. | | | | It includes two main functions: Ping and | | | | Traceroute. | | | | It is noted that while this category | | | | focuses on LSP Ping, other OAM tools | | | | can be used in MPLS networks, e.g., BFD. | | +-----------+------------------------------------------+------------+ |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP | | | The OAM requirements for MPLS Transport | | | | Profile (MPLS-TP) are defined in | | | | [MPLS-TP-OAM]. Each of the tools in the | | | | OAM toolset is defined in its own RFC, as| | | | specified in Section A.1. | | +-----------+------------------------------------------+------------+ |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | |OAM | channels that support the use of existing| | | | IETF OAM tools to be used for a pseudo- | | | | wire (PW). The control channels that are| | | | defined in [VCCV] and [PW-G-ACh] may be | | | | used in conjunction with ICMP Ping, LSP | | | | Ping, and BFD to perform CC and CV | | | | functionality. In addition the channels | | | | support use of any of the MPLS-TP based | | | | OAM tools for completing their respective| | | | OAM functionality for a PW. | | +-----------+------------------------------------------+------------+ |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | |TWAMP | (OWAMP) and the Two Way Active Measure- | | | | ment Protocols (TWAMP) are two protocols | | | | defined in the IP Performance Metrics | | | | (IPPM) working group in the IETF. These | | | | protocols allow various performance | | | | metrics to be measured, such as packet | | | | loss, delay and delay variation, | | | | duplication and reordering. | | +-----------+------------------------------------------+------------+ |TRILL OAM | The requirements of OAM in TRILL are | TRILL | | | defined in [TRILL-OAM]. These | | | | requirements include continuity checking,| | | | connectivity verification, path tracing | | | | and performance monitoring. During the | | | | writing of this document the detailed | | | | definition of the TRILL OAM tools | | | | is work in progress. | | +-----------+------------------------------------------+------------+ Table 3 Summary of OAM-related IETF Tools 4.10. Summary of OAM Functions Table 4 summarizes the OAM functions that are supported in each of the categories that were analyzed in this section. The columns of this tables are the typical OAM functions described in Section 1.3. +-----------+-------+--------+--------+-------+----------+ | |Continu|Connecti|Path |Perform|Other | | |ity |vity |Discover|ance |Function | | |Check |Verifica|y |Monitor|s | | Category | |tion | |ing | | +-----------+-------+--------+--------+-------+----------+ |IP Ping |Echo | | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |IP | | |Tracerou| | | |Traceroute | | |te | | | + --------- + ----- + ------ + ------ + ----- + -------- + |BFD |BFD |BFD | | |RDI usi- | | |Control|Control | | |ng BFD | | |/ Echo | | | |Control | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS OAM | |"Ping" |"Tracero| | | |(LSP Ping) | |mode |ute" | | | | | | |mode | | | + --------- + ----- + ------ + ------ + ----- + -------- + |MPLS-TP |CC |CV/pro- |Route |-LM |-Diagnos- | |OAM | |active |Tracing |-DM | tic Test | | | |or on- | | |-Lock | | | |demand | | |-Alarm | | | | | | |Reporting | | | | | | |-Client | | | | | | |Failure | | | | | | |Indication| | | | | | |-RDI | + --------- + ----- + ------ + ------ + ----- + -------- + |Pseudowire |BFD |-BFD |LSP-Ping| | | |OAM | |-ICMP | | | | | | | Ping | | | | | | |-LSP- | | | | | | | Ping | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |OWAMP and | - control | |-Delay | | |TWAMP | protocol | | measur| | | | | | ement | | | | | |-Packet| | | | | | loss | | | | | | measur| | | | | | ement | | + --------- + ----- + ------ + ------ + ----- + -------- + |TRILL OAM |CC |CV |Path |-Delay | | | | | |tracing | measur| | | | | | | ement | | | | | | |-Packet| | | | | | | loss | | | | | | | measur| | | | | | | ement | | +-----------+-------+--------+--------+-------+----------+ Table 4 Summary of theOAM Functionality in IETF OAM Mechanisms 5. Security ConsiderationsOAM Functionality in IETF OAM Tools 5. Security Considerations This memo presents an overview of existing OAM tools, and proposes no new OAM tools. Therefore, this document introduces no security considerations. However, the OAM tools reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document referenced by this memo. 6. IANA Considerations There are no new IANA considerations implied by this document. 7. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. Thismemo presents an overviewdocument was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Informative References [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application ofexisting OAM mechanisms,Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 andproposes no new OAM mechanisms. Therefore, this document introduces no security considerations. However,IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for theOAM mechanism reviewed in this document canPseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [Comp] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008. [Cont] Dugal, D., Pignataro, C., Dunn, R., "Protecting the Router Control Plane", RFC 6192, March 2011. [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface anddo present security issues. The reader is encouraged to review the Security Considerations section of each document referenced by this memo. 6. IANA Considerations There are no new IANA considerations implied by this document. 7. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, CarlosNext-Hop Identification", RFC 5837, April 2010. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro,David Harrington, Dan Romascanu, Ron BonicaC., "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., andother members ofM. Gupta, "Internet Control Message Protocol (ICMPv6) for theOPSAWG mailing listInternet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard fortheir helpful comments. This document was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Informative References [LSP-Ping] Kompella, K., Swallow,Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [IntHost] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [IPPM-1DM] Almes, G.,"Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures",Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC4379, February 2006. [MPLS-OAM] Nadeau, T., Morrow,2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M.,Swallow,"A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G.,Allan, D., Matsushima,Kalidindi, S.,"Operations and Management (OAM) RequirementsZekauskas, M., "A Round-trip Delay Metric forMulti-Protocol Label Switched (MPLS) Networks",IPPM", RFC4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework2681, September 1999. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics forMulti-Protocol Label Switching (MPLS) Operations and Management (OAM)",Measuring Connectivity", RFC4378, February 2006. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label'2678, September 1999. [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework forMultiprotocol Label Switching Architecture (MPLS) OperationIP Performance Metrics", RFC 2330, May 1998. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance(OAM) Functions", RFC 3429, November 2002. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirementsmechanism forOAMMPLS-TP inMPLSPacket TransportNetworks", RFC 5860, May 2010. [G-ACh] Bocci, M., Vigoureux,Network (PTN)", November 2012. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-T-CT] Betts, M.,Bryant, S., "MPLS"Allocation of a Generic AssociatedChannel", RFC 5586, June 2009. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A ControlChannel Type forPseudowires",ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC5085, December 2007. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word6671, November 2012. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism forUse over anMPLSPSN", RFC 4385,networks", February2006. [ATM-L2] Singh, S., Townsley, M.,2004. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions andC. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006.Mechanisms for Ethernet-based Networks", July 2011. [ITU-Terms] ITU-R/ITU-T Terms and Definitions, online, 2013. [L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009.[PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow,[Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration,Dai, X., "MPLS Transport Profile Lock Instruct andMaintenance (OAM) Message Mapping",Loopback Functions", RFC6310, July6435, November 2011.[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,[LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC792, September 1981. [ICMPv6] Conta,4379, February 2006. [Mng] Farrel, A.,Deering,"Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss andM. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [IntHost] Braden, R., "RequirementsDelay Measurement forInternet Hosts -- Communication Layers", RFC 1122, October 1989. [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking Terms",MPLS Networks", RFC1208, March 1991. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D.,6374, September 2011. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements forPoint-to-Multipoint MPLSMulti-Protocol Label Switched (MPLS) Networks", RFC4687, September4377, February 2006.[ICMP-Ext] Bonica, R., Gan, D., Tappan,[MPLS-OAM-FW] Allan, D.,Pignataro, C., "ICMP ExtensionsNadeau, T., "A Framework forMultiprotocolMulti-Protocol LabelSwitching", RFC 4950, August 2007. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages",Switching (MPLS) Operations and Management (OAM)", RFC4884, April 2007. [ICMP-Int] Atlas,4378, February 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A.,Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for InterfaceKing, D., Nadeau, T., "Operations andNext-Hop Identification",Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC5837, April4687, September 2006. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010.[TCPIP-Tools] Kessler, G., Shepard, S.,[NetTerms] Jacobsen, O., Lynch, D., "APrimer On Internet and TCP/IP Tools and Utilities",Glossary of Networking Terms", RFC2151, June 1997.1208, March 1991. [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1470, June 1993.[IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework[OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set forIP Performance Metrics",MPLS based Transport Networks", RFC2330, May 1998. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics6669, July 2012. [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines forMeasuring Connectivity",the use of the OAM acronym in the IETF ", RFC2678, September 1999. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric6291, June 2011. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' forIPPM",Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi,3429, November 2002. [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S.,Zekauskas, M., "A One-way Packet Loss Metric for IPPM",Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi,6426, November 2011. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "ARound-trip Delay Metric for IPPM",One-way Active Measurement Protocol (OWAMP)", RFC2681,4656, September1999.2006. [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, "Measuring Load-balanced Paths in the Internet", IMC, 2007. [PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.[OWAMP] Shalunov,[PW-ACH] Bryant, S.,Teitelbaum, B., Karp, A., Boote,Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [PW-G-ACh] Li, H., Martini, L., He, J.,and Zekauskas,Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. [PW-MAP] Aissaoui, M.,"A One-way Active Measurement Protocol (OWAMP)",Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC4656, September 2006. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K.,6310, July 2011. [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, "Pseudowire (PW) Operations, Administration, andBabiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)",Maintenance (OAM) Message Mapping", RFC5357, October 2008.6310, July 2011. [Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.[Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)",[Signal] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC5885, June 2010. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration4461, April 2006. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet andMaintenance Framework for MPLS-based Transport Networks ",TCP/IP Tools and Utilities", RFC6371, September 2011.2151, June 1997. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011.[OnDemand-CV] Gray, E., Bahadur, N.,[TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,Aggarwal, R."MPLSOn-Demand Connectivity VerificationFault Management Operations, Administration, andRoute Tracing",Maintenance (OAM)", RFC6426,6427, November 2011.[MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.[TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.[TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and[TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration(MPLS-TP OAM)", RFC 6671, November 2012. [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, "Pseudowire (PW) Operations, Administration,and Maintenance(OAM) Message Mapping", RFC 6310, July 2011. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel LabelFramework forPseudowire in the MPLSMPLS-based TransportProfile (MPLS-TP)", RFC 6423, November 2011. [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETFNetworks ", RFC6291, June 2011. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012.6371, September 2011. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", work-in-progress, draft-ietf-mpls- tp-rosetta-stone, July 2012.[Cont] Dugal, D., Pignataro, C., Dunn, R., "Protecting the Router Control Plane", RFC 6192, March 2011. [Mng] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011.[TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, R., "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013.[IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., andVirtual Bridged Local Area Networks",Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October2012. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December2008.[ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism[VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel forMPLS-TP in Packet Transport Network (PTN)", November 2012.Pseudowires", RFC 5085, December 2007. [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", work-in-progress, draft-ietf-pwe3-vccv-impl-survey-results, August 2013. Appendix A. List of OAM Documents A.1. List of IETF OAM Documents Table 5 summarizes the OAM related RFCs published by the IETF. It is important to note that the table lists various RFCs that are different by nature. For example, some of these documents define OAM tools or OAM protocols (or both), while others define protocols that are not strictly OAM-related, but are used by OAM tools. The table also includesmemosRFCs that define the requirements or the framework of OAM inthe context ofa specifictransport technology, or describe how to use existing OAM tools in a new transport technology.context (e.g., MPLS-TP). The RFCs in the table are categorized in a few sets as defined in Section 1.3. +-----------+--------------------------------------+----------+ | Category | Title | RFC | +-----------+--------------------------------------+----------+ |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | | | Communication Layers [IntHost] | | | +--------------------------------------+----------+ | | A Glossary of Networking Terms | RFC 1208 | | | [NetTerms] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | +-----------+--------------------------------------+----------+ |IP | A Primer On Internet and TCP/IP | RFC 2151 | |Traceroute | Tools and Utilities [TCPIP-Tools] | | | +--------------------------------------+----------+ | | FYI on a Network Management Tool | RFC 1470 | | | Catalog: Tools for Monitoring and | | | | Debugging TCP/IP Internets and | | | | Interconnected Devices [NetTools] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | Version 6 (IPv6) Specification | | | | [ICMPv6] | | | +--------------------------------------+----------+ | | Extended ICMP to Support Multi-Part | RFC 4884 | | | Messages [ICMP-MP] | | | +--------------------------------------+----------+ | | Extending ICMP for Interface and | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | +-----------+--------------------------------------+----------+ |BFD | Bidirectional Forwarding Detection | RFC 5880 | | | [BFD] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | [BFD-IP] | | | +--------------------------------------+----------+ | | Generic Application of Bidirectional | RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | [BFD-LSP] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | +-----------+--------------------------------------+----------+ |MPLS OAM | Operations and Management (OAM) | RFC 4377 | | | Requirements for Multi-Protocol Label| | | | Switched (MPLS) Networks [MPLS-OAM] | | | +--------------------------------------+----------+ | | A Framework for Multi-Protocol | RFC 4378 | | | Label Switching (MPLS) Operations | | | | and Management (OAM) [MPLS-OAM-FW] | | | +--------------------------------------+----------+ | | Detecting Multi-Protocol Label | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | [LSP-Ping] | | | +--------------------------------------+----------+ | | Operations and Management (OAM) | RFC 4687 | | | Requirements for Point-to-Multipoint | | | | MPLS Networks [MPLS-P2MP] | | | +--------------------------------------+----------+ | | ICMP Extensions for Multiprotocol | RFC 4950 | | | Label Switching [ICMP-Ext] | | +-----------+--------------------------------------+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | |OAM | [MPLS-TP-OAM] | | | +--------------------------------------+----------+ | | MPLS Generic Associated Channel | RFC 5586 | | | [G-ACh] | | | +--------------------------------------+----------+ | | MPLS-TP OAM Framework | RFC 6371 | | | [TP-OAM-FW] | | | +--------------------------------------+----------+ | | Proactive Connectivity Verification, | RFC 6428 | | | Continuity Check, and Remote Defect | | | | Indication for the MPLS Transport | | | | Profile [TP-CC-CV] | | | +--------------------------------------+----------+ | | MPLS On-Demand Connectivity | RFC 6426 | | | Verification and Route Tracing | | | | [OnDemand-CV] | | | +--------------------------------------+----------+ | | MPLS Fault Management Operations, | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | [TP-Fault] | | | +--------------------------------------+----------+ | | MPLS Transport Profile Lock Instruct | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | +--------------------------------------+----------+ | | Packet Loss and Delay Measurement for| RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | +--------------------------------------+----------+ | | A Packet Loss and Delay Measurement | RFC 6375 | | | Profile for MPLS-Based Transport | | | | Networks [TP-LM-DM] | | +-----------+--------------------------------------+----------+ |Pseudowire | Pseudowire Virtual Circuit | RFC 5085 | |OAM | Connectivity Verification (VCCV): | | | | A Control Channel for Pseudowires | | | | [VCCV] | | | +--------------------------------------+----------+ | | Bidirectional Forwarding Detection | RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | Connectivity Verification (VCCV) | | | | [BFD-VCCV] | | | +--------------------------------------+----------+ | | Using the Generic Associated Channel | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | Transport Profile (MPLS-TP) | | | | [PW-G-ACh] | | | +--------------------------------------+----------+ | | Pseudowire (PW) Operations, | RFC 6310 | | | Administration, and Maintenance (OAM)| | | | Message Mapping [PW-Map] | | +-----------+--------------------------------------+----------+ |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | |TWAMP | [OWAMP] | | | +--------------------------------------+----------+ | | A Two-Way Active Measurement Protocol| RFC 5357 | | | [TWAMP] | | | +--------------------------------------+----------+ | | Framework for IP Performance Metrics | RFC 2330 | | | [IPPM-FW] | | | +--------------------------------------+----------+ | | IPPM Metrics for Measuring | RFC 2678 | | | Connectivity [IPPM-Con] | | | +--------------------------------------+----------+ | | A One-way Delay Metric for IPPM | RFC 2679 | | | [IPPM-1DM] | | | +--------------------------------------+----------+ | | A One-way Packet Loss Metric for IPPM| RFC 2680 | | | [IPPM-1LM] | | | +--------------------------------------+----------+ | | A Round-trip Delay Metric for IPPM | RFC 2681 | | | [IPPM-2DM] | | | +--------------------------------------+----------+ | | Packet Reordering Metrics | RFC 4737 | | | [Reorder] | | | +--------------------------------------+----------+ | | A One-Way Packet Duplication Metric | RFC 5560 | | | [Dup] | | +-----------+--------------------------------------+----------+ |TRILL OAM | Requirements for Operations, | RFC 6905 | | | Administration, and Maintenance (OAM)| | | | in Transparent Interconnection of | | | | Lots of Links (TRILL) | | +-----------+--------------------------------------+----------+ Table 5 Summary of IETF OAM Related RFCs A.2. List of Selected Non-IETF OAM Documents In addition to the OAMmechanismstools defined by the IETF, the IEEE and ITU-T have also defined various OAMmechanismstools that focus on Ethernet, and various other transport network environments. These variousmechanisms,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 OAMmechanismstools for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAMmechanismstools listed above and are mentioned here only as reference material: o OAMmechanismstools for Layer 2 have been defined by the ITU-T in [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. It should be noted that these non-IETF documents deal in many cases with OAM functions below the IP layer (Layer 2, Layer 2.5) and in some cases operators use a multi-layered OAM approach, which is a function of the way their networks are designed. Table 6 summarizes some of the main OAM standards published by non- IETF standard organizations. This document focuses on IETF OAM standards, but these non-IETF standards are referenced in this document where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 | |Ethernet | Ethernet-based Networks | | |OAM | [ITU-T-Y1731] | | +-----------+--------------------------------------+---------------+ |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1Q] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Management of Data Driven and Data | IEEE 802.1ag | |DDCFM | Dependent Connectivity Faults | | | | [IEEE802.1Q] | | | | | | | | Note: DDCFM was originally published| | | | as IEEE 802.1Qaw, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 6 Non-IETF OAM Standards Mentioned in this Document Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com