--- 1/draft-ietf-opsawg-oam-overview-10.txt 2013-12-16 08:14:33.074972597 -0800 +++ 2/draft-ietf-opsawg-oam-overview-11.txt 2013-12-16 08:14:33.166974941 -0800 @@ -1,39 +1,46 @@ Operations and Management Area Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational N. Sprecher -Expires: April 2014 Nokia Siemens Networks +Expires: June 2014 NSN E. Bellagamba Ericsson Y. Weingarten - October 21, 2013 + December 16, 2013 - An Overview of Operations, Administration, and Maintenance (OAM) - Data Plane Tools - draft-ietf-opsawg-oam-overview-10.txt + An Overview of + Operations, Administration, and Maintenance (OAM) Tools + draft-ietf-opsawg-oam-overview-11.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years various OAM tools have been defined for various layers in the protocol stack. - This document summarizes some of the data plane OAM tools defined in - the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for - the transport profile (MPLS-TP), and TRILL. + This document summarizes some of the OAM tools defined in the IETF in + the context of IP unicast, MPLS, MPLS for the transport profile + (MPLS-TP), pseudowires, and TRILL. This document focuses on tools for + detecting and isolating failures in networks and for performance + monitoring. Control and management aspects of OAM are outside the + scope of this document. Network repair functions such as Fast Reroute + (FRR) and protection switching, which are often triggered by OAM + protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators and standard development organizations, - and can be used as an index to some of the main data plane OAM tools - defined in the IETF. + and can be used as an index to some of the main OAM tools defined in + the IETF. This document provides a brief description of each of the + OAM tools in the IETF. At the end of the document a list of the OAM + toolsets and a list of the OAM functions are presented as a summary. 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. @@ -42,44 +49,44 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 21, 2014. + This Internet-Draft will expire on June 16, 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. Introduction ................................................. 4 1.1. Background .............................................. 4 1.2. Target Audience.......................................... 5 1.3. OAM-related Work in the IETF ............................ 5 - 1.4. Focusing on Data Plane OAM Tools ........................ 6 + 1.4. Focusing on the Data Plane .............................. 6 2. Terminology .................................................. 7 2.1. Abbreviations ........................................... 7 2.2. Terminology used in OAM Standards ....................... 9 2.2.1. General Terms ...................................... 9 2.2.2. Operations, Administration and Maintenance ......... 9 2.2.3. Functions, Tools and Protocols ..................... 9 2.2.4. Data Plane, Control Plane and Management Plane .... 10 2.2.5. The Players ....................................... 11 2.2.6. Proactive and On-demand Activation ................ 12 2.2.7. Connectivity Verification and Continuity Checks ... 12 @@ -102,64 +109,67 @@ 4.5.3. Generic Associated Channel ........................ 22 4.5.4. MPLS-TP OAM Toolset ............................... 22 4.5.4.1. Continuity Check and Connectivity Verification 23 4.5.4.2. Route Tracing ................................ 23 4.5.4.3. Lock Instruct ................................ 23 4.5.4.4. Lock Reporting ............................... 24 4.5.4.5. Alarm Reporting .............................. 24 4.5.4.6. Remote Defect Indication ..................... 24 4.5.4.7. Client Failure Indication .................... 24 4.5.4.8. Performance Monitoring ....................... 24 - 4.5.4.8.1. Packet Loss Measurement (LM) ............ 24 + 4.5.4.8.1. Packet Loss Measurement (LM) ............ 25 4.5.4.8.2. Packet Delay Measurement (DM) ........... 25 4.6. Pseudowire OAM ......................................... 26 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) ...................................... 26 4.6.2. Pseudowire OAM using G-ACh ........................ 27 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 27 4.7. OWAMP and TWAMP......................................... 27 4.7.1. Overview .......................................... 27 4.7.2. Control and Test Protocols ........................ 28 - 4.7.3. OWAMP ............................................. 28 + 4.7.3. OWAMP ............................................. 29 4.7.4. TWAMP ............................................. 29 4.8. TRILL .................................................. 29 - 4.9. Summary of OAM Tools ................................... 30 - 4.10. Summary of OAM Functions .............................. 32 - 5. Security Considerations ..................................... 33 - 6. IANA Considerations ......................................... 34 - 7. Acknowledgments ............................................. 34 - 8. References .................................................. 34 - 8.1. Informative References ................................. 34 + 5. Summary ..................................................... 30 + 5.1. Summary of OAM Tools ................................... 30 + 5.2. Summary of OAM Functions ............................... 32 + 5.3. Guidance to Network Equipment Vendors .................. 34 + 6. Security Considerations ..................................... 34 + 7. IANA Considerations ......................................... 34 + 8. Acknowledgments ............................................. 34 + 9. References .................................................. 34 + 9.1. Informative References ................................. 34 Appendix A. List of OAM Documents .............................. 40 A.1. List of IETF OAM Documents ............................. 40 - A.2. List of Selected Non-IETF OAM Documents ................ 44 + A.2. List of Selected Non-IETF OAM Documents ................ 45 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 Section 3 of [RFC6291]. - This document summarizes some of the data plane OAM tools defined in - the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for - the transport profile (MPLS-TP), and TRILL. + This document summarizes some of the OAM tools defined in the IETF in + the context of IP unicast, MPLS, MPLS for the transport profile + (MPLS-TP), pseudowires, 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. + and for performance monitoring. Hence, this document focuses on the + tools used for monitoring and measuring the data plane; control and + management aspects of OAM are outside the scope of this document. + Network repair functions such as Fast Reroute (FRR) and protection + switching, which are often triggered by OAM protocols, are also out + of the scope of this document. 1.1. Background OAM was originally used in traditional communication technologies such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM was probably the first technology to include inherent OAM support from day one, while in other technologies OAM was typically defined in an ad hoc manner after the technology was already defined and deployed. Packet-based networks were traditionally considered unreliable and best-effort, but as packet-based networks evolved, @@ -218,59 +228,59 @@ defined by the IETF. The set of OAM tools described in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. While OAM tools that are applicable to other technologies exist, they are beyond the scope of this memo. This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM-related work is outside the scope. The IETF has defined OAM protocols and tools in several different contexts. We roughly categorize these efforts into a few sets of OAM- - related RFCs, listed in Table 1. Each category defines a logically- - coupled set of RFCs, although the sets are in some cases intertwined - by common tools and protocols. + related RFCs, listed in Table 1. Each set defines a logically-coupled + set of RFCs, although the sets are in some cases intertwined by + common tools and protocols. - The discussion in this document is ordered according to these - categories. + The discussion in this document is ordered according to these sets. +--------------+------------+ - | Category | Transport | + | Toolset | Transport | | | Technology | +--------------+------------+ |IP Ping | IPv4/IPv6 | +--------------+------------+ |IP Traceroute | IPv4/IPv6 | +--------------+------------+ |BFD | generic | +--------------+------------+ |MPLS OAM | MPLS | +--------------+------------+ |MPLS-TP OAM | MPLS-TP | +--------------+------------+ |Pseudowire OAM| Pseudowires| +--------------+------------+ |OWAMP and | IPv4/IPv6 | |TWAMP | | +--------------+------------+ |TRILL OAM | TRILL | +--------------+------------+ - Table 1 Categories of OAM-related IETF Documents + Table 1 OAM Toolset Packages in the IETF Documents -1.4. Focusing on Data Plane OAM Tools +1.4. Focusing on the Data Plane OAM tools may, and quite often do, work in conjunction with a control - plane and/or management plane. 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. + plane and/or management plane. OAM provides instrumentation tools + for measuring and monitoring the data plane. OAM tools often use + control plane functions, e.g., to initialize OAM sessions and to + exchange various parameters. The OAM tools communicate with the + management plane to raise alarms, and often OAM tools may be + activated by the management (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 @@ -427,22 +436,20 @@ implemented using UDP and ICMP messages, without using an OAM protocol per se. 2.2.4. Data Plane, Control Plane and Management Plane Data Plane The data plane is the set of functions used to transfer data in the stratum or layer under consideration [ITU-Terms]. - . - The Data Plane is also known as the Forwarding Plane or the User Plane. Control Plane The control plane is the set of protocols and mechanisms that enable routers to efficiently learn how to forward packets towards their final destination (based on [Comp]). Management Plane @@ -447,46 +454,44 @@ Management Plane The term Management Plane, as described in [Mng], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. Data Plane vs. Control Plane vs. Management Plane - The distinction between the planes is at times a bit vague. For example, the definition of "Control Plane" above may imply that OAM tools such as ping, BFD and others are in fact in the control plane. - This document focuses on 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. + This document focuses on tools used for monitoring the data plane. + While these tools could arguably be considered to be in the control + plane, these tools monitor the data plane, and hence it is imperative + to have fate-sharing between OAM traffic that monitors the data plane + and the data plane traffic it monitors. Another potentially vague distinction is between the management plane and control plane. The management plane should be seen as separate from, but possibly overlapping with, the control plane (based on [Mng]). 2.2.5. The Players An OAM tool is used between two (or more) "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 + OAM. Table 2 summarizes the terms used in each of the toolsets discussed in this document. +--------------------------+--------------------------+ - | Category | Terms | + | Toolset | Terms | +--------------------------+--------------------------+ | Ping / Traceroute |-Host | | ([ICMPv4], [ICMPv6], |-Node | | [TCPIP-Tools]) |-Interface | | |-Gateway | + ------------------------ + ------------------------ + | BFD [BFD] | System | + ------------------------ + ------------------------ + | MPLS OAM [MPLS-OAM-FW] | LSR | + ------------------------ + ------------------------ + @@ -528,31 +533,33 @@ 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 + she is connected to Bob or not. It is noted that while the CV function is performed in the data plane, the "expected path" is predetermined 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 tools often perform path verification as + well, allowing Alice to verify that messages from Bob are received + through the correct path, thereby verifying not only that the two MPs + are connected, but also that they are connected through the expected + path, allowing detection of unexpected topology changes. + Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.8. Connection Oriented vs. Connectionless Communication Connection Oriented In Connection Oriented technologies an end-to-end connection is established (by a control protocol or provisioned by a management @@ -595,43 +602,38 @@ 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 + A P2MP service delivers data from a single source to a one or more destinations (based on [Signal]). - [Signal] also defines a MP2MP service as a service that delivers data - from more than one source to one or more receivers. + An MP2MP service as a service that delivers data from more than one + source to one or more receivers (based on [Signal]). Discussion The OAM tools described in this document include tools for P2P services, as well as tools for P2MP services. The distinction between P2P services and P2MP services affects the corresponding OAM tools. A P2P service is typically simpler to monitor, as it consists of a single pair of end points. P2MP services present several challenges. For example, in a P2MP service, the OAM mechanism not only verifies that each of the destinations is reachable from the source, but also verifies that the P2MP - distribution tree is intact and loop-free. Another challenge in P2MP - services is performance monitoring; while in P2P packet loss is - measured by maintaining packet counters at the two end-points, in - P2MP packet loss must be carefully measured by generating synthetic - traffic to each corresponding end-point and maintaining a separate - counter for each peer end-point. + distribution tree is intact and loop-free. 2.2.10. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as 802.1ag [IEEE802.1Q] , there is no distinction between these terms, while in other standards each of these terms refers to a different type of malfunction. @@ -655,21 +656,22 @@ The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Functions This subsection provides a brief summary of the common OAM functions used in OAM-related standards. These functions are used as building blocks in the OAM standards described in this document. - o Connectivity Verification (CV) and/or Continuity Checks (CC): + o Connectivity Verification (CV), Path Verification and Continuity + Checks (CC): As defined in Section 2.2.7. o Path Discovery / Fault Localization: This function can be used to trace the route to a destination, i.e., to identify the nodes along the route to the destination. When more than one route is available to a specific destination, this function traces one of the available routes. When a failure occurs, this function also allows to detect the location of the failure. Note that the term route tracing (or Traceroute) that is used in @@ -680,21 +682,21 @@ Typically refers to: o Loss Measurement (LM) - monitors the packet loss rate. o Delay Measurement (DM) - monitors the delay and delay variation. 4. OAM Tools in the IETF - a Detailed Description This section presents a detailed description of the sets of OAM- - related tools in each of the categories in Table 1. + related tools in each of the toolsets in Table 1. 4.1. IP Ping Ping is a common network diagnosis application for IP networks that uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for Packet internet groper, although the term has been so commonly used that it stands on its own. As defined in [NetTerms], it is a program used to test reachability of destinations by sending them an ICMP echo request and waiting for a reply. @@ -772,22 +774,22 @@ deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD- IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 4.3.2. Terminology - BFD operates between two *systems*. The BFD protocol is run between - two systems after establishing a *session*. + BFD operates between *systems*. The BFD protocol is run between two + or more systems after establishing a *session*. 4.3.3. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packets have been received during a predetermined @@ -841,29 +843,36 @@ connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. + The Traceroute functionality may be used to isolate and localize the + MPLS faults, using the Time-to-live (TTL) indicator to incrementally + identify the sub-path of the LSP that is successfully traversed + before the faulty link or node. + The challenge in MPLS networks is that the traffic of a given LSP may be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping monitors all the available paths of an LSP by monitoring its different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths. - The Traceroute functionality may be used to isolate and localize the - MPLS faults, using the Time-to-live (TTL) indicator to incrementally - identify the sub-path of the LSP that is successfully traversed - before the faulty link or node. + + Another challenge is that an MPLS LSP does not necessarily have a + return path, and thus responding to an LSP Ping message is not + necessarily as trivial as in IP Ping, where the responder just swaps + the source and destination IP addresses. Note that this challenge is + not applicable to MPLS-TP, where a return path is always available. It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand @@ -891,20 +900,22 @@ in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from data plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. + OAM packets are identified by the Generic Associated Label (GAL), + which is a reserved MPLS label value (13). 4.5.2. Terminology Maintenance Entity (ME) The MPLS-TP OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. @@ -1339,30 +1351,39 @@ 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 +5. Summary - This subsection provides a short summary of each of the OAM tool - categories described in this document. + This section summarizes the OAM tools and functions presented in this + document. This summary is an index to some of the main OAM tools + defined in the IETF. This compact index that can be useful to all + readers from network operators to standard development organizations. + The summary includes a short subsection that presents some guidance + to network equipment vendors. - A detailed list of the RFCs related to each category is given in +5.1. Summary of OAM Tools + + This subsection provides a short summary of each of the OAM toolsets + described in this document. + + A detailed list of the RFCs related to each toolset is given in Appendix A.1. +-----------+------------------------------------------+------------+ - | Category | Description | Transport | + | Toolset | Description | Transport | | | | Technology | +-----------+------------------------------------------+------------+ |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | | | application for testing reachability that| | | | uses ICMP Echo messages ([ICMPv4], | | | | [ICMPv6]). | | +-----------+------------------------------------------+------------+ |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | |Traceroute | an application that allows users to trace| | | | the path between an IP source and an IP | | @@ -1427,31 +1448,31 @@ | | 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 +5.2. 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. + the toolsets 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 | | + | Toolset | |tion | |ing | | +-----------+-------+--------+--------+-------+----------+ |IP Ping |Echo | | | | | + --------- + ----- + ------ + ------ + ----- + -------- + |IP | | |Tracerou| | | |Traceroute | | |te | | | + --------- + ----- + ------ + ------ + ----- + -------- + |BFD |BFD |BFD | | |RDI usi- | | |Control|Control | | |ng BFD | | |/ Echo | | | |Control | + --------- + ----- + ------ + ------ + ----- + -------- + @@ -1486,44 +1507,52 @@ |TRILL OAM |CC |CV |Path |-Delay | | | | | |tracing | measur| | | | | | | ement | | | | | | |-Packet| | | | | | | loss | | | | | | | measur| | | | | | | ement | | +-----------+-------+--------+--------+-------+----------+ Table 4 Summary of the OAM Functionality in IETF OAM Tools -5. Security Considerations +5.3. Guidance to Network Equipment Vendors + + As mentioned in Section 1.4. , it is imperative for OAM tools to be + capable of testing the actual data plane in as much accuracy as + possible. Thus, it is important to enforce fate-sharing between OAM + traffic that monitors the data plane and the data plane traffic it + monitors. + +6. 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 +7. IANA Considerations There are no new IANA considerations implied by this document. -7. Acknowledgments +8. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. -8. References +9. References -8.1. Informative References +9.1. Informative References [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of @@ -1789,21 +1818,21 @@ different by nature. For example, some of these documents define OAM tools or OAM protocols (or both), while others define protocols that are not strictly OAM-related, but are used by OAM tools. The table also includes RFCs that define the requirements or the framework of OAM in a specific context (e.g., MPLS-TP). The RFCs in the table are categorized in a few sets as defined in Section 1.3. +-----------+--------------------------------------+----------+ - | Category | Title | RFC | + | Toolset | Title | RFC | +-----------+--------------------------------------+----------+ |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | | | Communication Layers [IntHost] | | | +--------------------------------------+----------+ | | A Glossary of Networking Terms | RFC 1208 | | | [NetTerms] | | | +--------------------------------------+----------+ | | Internet Control Message Protocol | RFC 792 | | | [ICMPv4] | | | +--------------------------------------+----------+ @@ -2069,30 +2098,31 @@ Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher - Nokia Siemens Networks + NSN 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