--- 1/draft-ietf-opsawg-oam-overview-12.txt 2014-01-28 02:14:43.124123838 -0800 +++ 2/draft-ietf-opsawg-oam-overview-13.txt 2014-01-28 02:14:43.220126152 -0800 @@ -1,23 +1,23 @@ Operations and Management Area Working Group T. Mizrahi Internet Draft Marvell Intended status: Informational N. Sprecher -Expires: July 2014 NSN +Expires: July 2014 Nokia Solutions and Networks E. Bellagamba Ericsson Y. Weingarten - January 9, 2014 + January 28, 2014 An Overview of Operations, Administration, and Maintenance (OAM) Tools - draft-ietf-opsawg-oam-overview-12.txt + draft-ietf-opsawg-oam-overview-13.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 OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS for the transport profile @@ -49,21 +49,21 @@ 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 July 9, 2014. + This Internet-Draft will expire on July 28, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -96,58 +96,61 @@ 3. OAM Functions ............................................... 15 4. OAM Tools in the IETF - a Detailed Description .............. 16 4.1. IP Ping ................................................ 16 4.2. IP Traceroute .......................................... 17 4.3. Bidirectional Forwarding Detection (BFD) ............... 18 4.3.1. Overview .......................................... 18 4.3.2. Terminology ....................................... 18 4.3.3. BFD Control ....................................... 18 4.3.4. BFD Echo .......................................... 19 4.4. MPLS OAM ............................................... 19 - 4.5. MPLS-TP OAM ............................................ 20 - 4.5.1. Overview .......................................... 20 + 4.4.1. LSP Ping .......................................... 19 + 4.4.2. BFD for MPLS ...................................... 20 + 4.4.3. OAM for Virtual Private Networks (VPN) over MPLS .. 21 + 4.5. MPLS-TP OAM ............................................ 21 + 4.5.1. Overview .......................................... 21 4.5.2. Terminology ....................................... 21 - 4.5.3. Generic Associated Channel ........................ 22 + 4.5.3. Generic Associated Channel ........................ 23 4.5.4. MPLS-TP OAM Toolset ............................... 23 - 4.5.4.1. Continuity Check and Connectivity Verification 23 + 4.5.4.1. Continuity Check and Connectivity Verification 24 4.5.4.2. Route Tracing ................................ 24 - 4.5.4.3. Lock Instruct ................................ 24 - 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.3. Lock Instruct ................................ 25 + 4.5.4.4. Lock Reporting ............................... 25 + 4.5.4.5. Alarm Reporting .............................. 25 + 4.5.4.6. Remote Defect Indication ..................... 25 4.5.4.7. Client Failure Indication .................... 25 4.5.4.8. Performance Monitoring ....................... 25 - 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.5.4.8.1. Packet Loss Measurement (LM) ............ 26 + 4.5.4.8.2. Packet Delay Measurement (DM) ........... 26 + 4.6. Pseudowire OAM ......................................... 27 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 ............................................. 29 - 4.7.4. TWAMP ............................................. 29 - 4.8. TRILL .................................................. 30 - 5. Summary ..................................................... 30 + Verification (VCCV) ...................................... 27 + 4.6.2. Pseudowire OAM using G-ACh ........................ 28 + 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 28 + 4.7. OWAMP and TWAMP......................................... 28 + 4.7.1. Overview .......................................... 28 + 4.7.2. Control and Test Protocols ........................ 29 + 4.7.3. OWAMP ............................................. 30 + 4.7.4. TWAMP ............................................. 30 + 4.8. TRILL .................................................. 31 + 5. Summary ..................................................... 31 5.1. Summary of OAM Tools ................................... 31 - 5.2. Summary of OAM Functions ............................... 33 - 5.3. Guidance to Network Equipment Vendors .................. 34 - 6. Security Considerations ..................................... 34 - 7. IANA Considerations ......................................... 34 + 5.2. Summary of OAM Functions ............................... 34 + 5.3. Guidance to Network Equipment Vendors .................. 35 + 6. Security Considerations ..................................... 35 + 7. IANA Considerations ......................................... 35 8. Acknowledgments ............................................. 35 - 9. References .................................................. 35 - 9.1. Informative References ................................. 35 - Appendix A. List of OAM Documents .............................. 40 - A.1. List of IETF OAM Documents ............................. 40 - A.2. List of Selected Non-IETF OAM Documents ................ 45 + 9. References .................................................. 36 + 9.1. Informative References ................................. 36 + Appendix A. List of OAM Documents .............................. 42 + A.1. List of IETF OAM Documents ............................. 42 + A.2. List of Selected Non-IETF OAM Documents ................ 46 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 [OAM-Def]. @@ -317,20 +320,24 @@ FRR Fast Reroute G-ACh Generic Associated Channel GAL Generic Associated Label ICMP Internet Control Message Protocol L2TP Layer Two Tunneling Protocol + L2VPN Layer Two Virtual Private Network + + L3VPN Layer Three Virtual Private Network + LCCE L2TP Control Connection Endpoint LDP Label Distribution Protocol LER Label Edge Router LM Loss Measurement LSP Label Switched Path @@ -353,27 +360,29 @@ MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance OWAMP One-way Active Measurement Protocol PDH Plesiochronous Digital Hierarchy PE Provider Edge - PW Pseudowire + PSN Public Switched Network + PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RBridge Routing Bridge RDI Remote Defect Indication + SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networking TRILL Transparent Interconnection of Lots of Links TTL Time To Live TWAMP Two-way Active Measurement Protocol @@ -372,20 +381,22 @@ SONET Synchronous Optical Networking TRILL Transparent Interconnection of Lots of Links TTL Time To Live TWAMP Two-way Active Measurement Protocol VCCV Virtual Circuit Connectivity Verification + VPN Virtual Private Network + 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. An interesting overview of the term OAM and its derivatives is presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms @@ -843,62 +855,96 @@ MPLS-TP. 4.4. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP services is defined in [MPLS-P2MP]. + BFD for MPLS [BFD-LSP] is an alternative means for detecting data- + plane failures, as described below. + +4.4.1. LSP Ping + LSP Ping is modeled after the Ping/Traceroute paradigm and thus it may be used in one of two modes: o "Ping" mode: In this mode LSP Ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. - 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. + LSP Ping is based on ICMP Ping operation (of data-plane connectivity + verification) with additional functionality to verify data-plane vs. + control-plane consistency for a Forwarding Equivalence Class (FEC) + and also 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 + different Forwarding Equivalence Classes (FEC). Note that MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths. Another challenge is that an MPLS LSP does not necessarily have a - return path, 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. + return path; traffic that is sent back from the egress LSR to the + ingress LSR is not necessarily sent over an MPLS LSP, but can be sent + through a different route, such as an IP route. Thus, responding to + an LSP Ping message is not necessarily as trivial as in IP Ping, + where the responder just swaps the source and destination IP + addresses. Note that this challenge is not applicable to MPLS-TP, + where a return path is always available. It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is 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 activation. +4.4.2. BFD for MPLS + + BFD [BFD-LSP] can be used to detect MPLS LSP data plane failures. + + A BFD session is established for each MPLS LSP that is being + monitored. BFD Control packets must be sent along the same path as + the monitored LSP. If the LSP is associated with multiple FECs, a BFD + session is established for each FEC. + + While LSP Ping can be used for detecting MPLS data plane failures and + for verifying the MPLS LSP data plane against the control plane, BFD + can only be used for the former. The advantage of BFD is that it can + provide faster failure detection, and scales better to a large number + of LSPs. Thus, a combination of LSP Ping and BFD can provide the + advantages of BFD, as well as allow to verify the data plane against + the control plane. + +4.4.3. OAM for Virtual Private Networks (VPN) over MPLS + + The IETF has defined two classes of VPNs, Layer 2 VPNs (L2VPN) and + Layer 3 VPNs (L3VPN). [L2VPN-OAM] provides the requirements and + framework for OAM in the context of Layer 2 Virtual Private Networks + (L2VPN), and specifically it also defines the OAM layering of L2VPNs + over MPLS. [L3VPN-OAM] provides a framework for the operation and + management of Layer 3 Virtual Private Networks (L3VPNs). + 4.5. MPLS-TP OAM 4.5.1. Overview The MPLS working group has defined the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS- TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM tools and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which @@ -1163,22 +1210,22 @@ measure the delay, as well as the delay variation. Delay measurement is performed by exchanging timestamped OAM packets between the participating MEPs. 4.6. Pseudowire OAM 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault - detection and diagnostics tools to be extended for PWs (regardless of - the underlying tunneling technology). The VCCV switching function + detection and diagnostics tools to be used for PWs (regardless of the + underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW. [VCCV] defines three Control Channel (CC) types, i.e., three possible methods for transmitting and identifying OAM messages: o CC Type 1: In-band VCCV, as described in [VCCV], is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header [PW-ACH]. o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS Router Alert Label". In this case the control channel is created @@ -1197,21 +1244,21 @@ signal the AC status. The use of the VCCV control channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. - The VCCV capability negotiation may be performed as part of the PW + The VCCV capability advertisement may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too. The PWE3 working group has conducted an implementation survey of VCCV [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in practice. @@ -1226,20 +1273,27 @@ 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. + [L2VPN-OAM] provides the requirements and framework for OAM in the + context of Layer 2 Virtual Private Networks (L2VPN), and specifically + it also defines the OAM layering of L2VPNs over pseudowires. + + The mapping defined in [Eth-Int] allows an end-to-end emulated + Ethernet service over pseudowires. + 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 @@ -1418,23 +1471,22 @@ | | 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. | | + | | BFD [BFD-LSP] is an alternative means for| | + | | detecting MPLS LSP data plane failures. | | +-----------+------------------------------------------+------------+ |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| | @@ -1546,22 +1598,24 @@ the Security Considerations section of each document referenced by this memo. 7. IANA Considerations There are no new IANA considerations implied by this document. 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. + Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit + Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam + Aldrin, Thomas Narten, and other members of the OPSA WG for their + helpful comments on the mailing list. This document was prepared using 2-Word-v2.0.template.dot. 9. 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 @@ -1589,20 +1643,25 @@ Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [Comp] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008. [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. + [Eth-Int] Mohan, D., Bitar, N., Sajassi, A., Delord, S., Niger, + P., Qiu, R., "MPLS and Ethernet Operations, + Administration, and Maintenance (OAM) Interworking", + RFC 7023, October 2013. + [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. @@ -1671,20 +1730,30 @@ [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and 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. + [L2VPN-OAM] Sajassi, A., Mohan, D., "Layer 2 Virtual Private + Network (L2VPN) Operations, Administration, and + Maintenance (OAM) Requirements and Framework", RFC + 6136, March 2011. + + [L3VPN-OAM] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., + Gonguet, A., "Framework for Layer 3 Virtual Private + Networks (L3VPN) Operations and Management", RFC 4176, + October 2005. + [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [Mng] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", @@ -1906,20 +1975,24 @@ | | 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] | | + | +--------------------------------------+----------+ + | | Bidirectional Forwarding Detection | RFC 5884 | + | | for MPLS Label Switched Paths (LSPs) | | + | | [BFD-LSP] | | +-----------+--------------------------------------+----------+ |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] | | | +--------------------------------------+----------+ @@ -1957,20 +2030,24 @@ | | [BFD-VCCV] | | | +--------------------------------------+----------+ | | Using the Generic Associated Channel | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | Transport Profile (MPLS-TP) | | | | [PW-G-ACh] | | | +--------------------------------------+----------+ | | Pseudowire (PW) Operations, | RFC 6310 | | | Administration, and Maintenance (OAM)| | | | Message Mapping [PW-MAP] | | + | +--------------------------------------+----------+ + | | MPLS and Ethernet Operations, | RFC 7023 | + | | Administration, and Maintenance (OAM)| | + | | Interworking [Eth-Int] | | +-----------+--------------------------------------+----------+ |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | |TWAMP | [OWAMP] | | | +--------------------------------------+----------+ | | A Two-Way Active Measurement Protocol| RFC 5357 | | | [TWAMP] | | | +--------------------------------------+----------+ | | Framework for IP Performance Metrics | RFC 2330 | | | [IPPM-FW] | | | +--------------------------------------+----------+ @@ -2108,21 +2185,21 @@ Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher - NSN + Nokia Solutions and Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40