draft-ietf-opsawg-oam-overview-10.txt   draft-ietf-opsawg-oam-overview-11.txt 
Operations and Management Area Working Group T. Mizrahi Operations and Management Area Working Group T. Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational N. Sprecher Intended status: Informational N. Sprecher
Expires: April 2014 Nokia Siemens Networks Expires: June 2014 NSN
E. Bellagamba E. Bellagamba
Ericsson Ericsson
Y. Weingarten Y. Weingarten
October 21, 2013 December 16, 2013
An Overview of Operations, Administration, and Maintenance (OAM) An Overview of
Data Plane Tools Operations, Administration, and Maintenance (OAM) Tools
draft-ietf-opsawg-oam-overview-10.txt draft-ietf-opsawg-oam-overview-11.txt
Abstract Abstract
Operations, Administration, and Maintenance (OAM) is a general term Operations, Administration, and Maintenance (OAM) is a general term
that refers to a toolset for fault detection and isolation, and for that refers to a toolset for fault detection and isolation, and for
performance measurement. Over the years various OAM tools have been performance measurement. Over the years various OAM tools have been
defined for various layers in the protocol stack. defined for various layers in the protocol stack.
This document summarizes some of the data plane OAM tools defined in This document summarizes some of the OAM tools defined in the IETF in
the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for the context of IP unicast, MPLS, MPLS for the transport profile
the transport profile (MPLS-TP), and TRILL. (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 The target audience of this document includes network equipment
vendors, network operators and standard development organizations, vendors, network operators and standard development organizations,
and can be used as an index to some of the main data plane OAM tools and can be used as an index to some of the main OAM tools defined in
defined in the IETF. 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 16
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 4
1.1. Background .............................................. 4 1.1. Background .............................................. 4
1.2. Target Audience.......................................... 5 1.2. Target Audience.......................................... 5
1.3. OAM-related Work in the IETF ............................ 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. Terminology .................................................. 7
2.1. Abbreviations ........................................... 7 2.1. Abbreviations ........................................... 7
2.2. Terminology used in OAM Standards ....................... 9 2.2. Terminology used in OAM Standards ....................... 9
2.2.1. General Terms ...................................... 9 2.2.1. General Terms ...................................... 9
2.2.2. Operations, Administration and Maintenance ......... 9 2.2.2. Operations, Administration and Maintenance ......... 9
2.2.3. Functions, Tools and Protocols ..................... 9 2.2.3. Functions, Tools and Protocols ..................... 9
2.2.4. Data Plane, Control Plane and Management Plane .... 10 2.2.4. Data Plane, Control Plane and Management Plane .... 10
2.2.5. The Players ....................................... 11 2.2.5. The Players ....................................... 11
2.2.6. Proactive and On-demand Activation ................ 12 2.2.6. Proactive and On-demand Activation ................ 12
2.2.7. Connectivity Verification and Continuity Checks ... 12 2.2.7. Connectivity Verification and Continuity Checks ... 12
skipping to change at page 3, line 20 skipping to change at page 3, line 28
4.5.3. Generic Associated Channel ........................ 22 4.5.3. Generic Associated Channel ........................ 22
4.5.4. MPLS-TP OAM Toolset ............................... 22 4.5.4. MPLS-TP OAM Toolset ............................... 22
4.5.4.1. Continuity Check and Connectivity Verification 23 4.5.4.1. Continuity Check and Connectivity Verification 23
4.5.4.2. Route Tracing ................................ 23 4.5.4.2. Route Tracing ................................ 23
4.5.4.3. Lock Instruct ................................ 23 4.5.4.3. Lock Instruct ................................ 23
4.5.4.4. Lock Reporting ............................... 24 4.5.4.4. Lock Reporting ............................... 24
4.5.4.5. Alarm Reporting .............................. 24 4.5.4.5. Alarm Reporting .............................. 24
4.5.4.6. Remote Defect Indication ..................... 24 4.5.4.6. Remote Defect Indication ..................... 24
4.5.4.7. Client Failure Indication .................... 24 4.5.4.7. Client Failure Indication .................... 24
4.5.4.8. Performance Monitoring ....................... 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.5.4.8.2. Packet Delay Measurement (DM) ........... 25
4.6. Pseudowire OAM ......................................... 26 4.6. Pseudowire OAM ......................................... 26
4.6.1. Pseudowire OAM using Virtual Circuit Connectivity 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity
Verification (VCCV) ...................................... 26 Verification (VCCV) ...................................... 26
4.6.2. Pseudowire OAM using G-ACh ........................ 27 4.6.2. Pseudowire OAM using G-ACh ........................ 27
4.6.3. Attachment Circuit - Pseudowire Mapping ........... 27 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 27
4.7. OWAMP and TWAMP......................................... 27 4.7. OWAMP and TWAMP......................................... 27
4.7.1. Overview .......................................... 27 4.7.1. Overview .......................................... 27
4.7.2. Control and Test Protocols ........................ 28 4.7.2. Control and Test Protocols ........................ 28
4.7.3. OWAMP ............................................. 28 4.7.3. OWAMP ............................................. 29
4.7.4. TWAMP ............................................. 29 4.7.4. TWAMP ............................................. 29
4.8. TRILL .................................................. 29 4.8. TRILL .................................................. 29
4.9. Summary of OAM Tools ................................... 30 5. Summary ..................................................... 30
4.10. Summary of OAM Functions .............................. 32 5.1. Summary of OAM Tools ................................... 30
5. Security Considerations ..................................... 33 5.2. Summary of OAM Functions ............................... 32
6. IANA Considerations ......................................... 34 5.3. Guidance to Network Equipment Vendors .................. 34
7. Acknowledgments ............................................. 34 6. Security Considerations ..................................... 34
8. References .................................................. 34 7. IANA Considerations ......................................... 34
8.1. Informative References ................................. 34 8. Acknowledgments ............................................. 34
9. References .................................................. 34
9.1. Informative References ................................. 34
Appendix A. List of OAM Documents .............................. 40 Appendix A. List of OAM Documents .............................. 40
A.1. List of IETF 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 1. Introduction
OAM is a general term that refers to a toolset for detecting, OAM is a general term that refers to a toolset for detecting,
isolating and reporting failures and for monitoring the network isolating and reporting failures and for monitoring the network
performance. performance.
There are several different interpretations to the "OAM" acronym. There are several different interpretations to the "OAM" acronym.
This document refers to Operations, Administration and Maintenance, This document refers to Operations, Administration and Maintenance,
as recommended in Section 3 of [RFC6291]. as recommended in Section 3 of [RFC6291].
This document summarizes some of the data plane OAM tools defined in This document summarizes some of the OAM tools defined in the IETF in
the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for the context of IP unicast, MPLS, MPLS for the transport profile
the transport profile (MPLS-TP), and TRILL. (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 This document focuses on tools for detecting and isolating failures
and for performance monitoring. Network repair functions such as Fast and for performance monitoring. Hence, this document focuses on the
Reroute (FRR) and protection switching, which are often triggered by tools used for monitoring and measuring the data plane; control and
OAM protocols, are out of the scope of this document. 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 1.1. Background
OAM was originally used in traditional communication technologies OAM was originally used in traditional communication technologies
such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM 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 was probably the first technology to include inherent OAM support
from day one, while in other technologies OAM was typically defined from day one, while in other technologies OAM was typically defined
in an ad hoc manner after the technology was already defined and in an ad hoc manner after the technology was already defined and
deployed. Packet-based networks were traditionally considered deployed. Packet-based networks were traditionally considered
unreliable and best-effort, but as packet-based networks evolved, unreliable and best-effort, but as packet-based networks evolved,
skipping to change at page 5, line 49 skipping to change at page 6, line 10
defined by the IETF. The set of OAM tools described in this memo are defined by the IETF. The set of OAM tools described in this memo are
applicable to IP unicast, MPLS, pseudowires, MPLS for the transport applicable to IP unicast, MPLS, pseudowires, MPLS for the transport
profile (MPLS-TP), and TRILL. While OAM tools that are applicable to profile (MPLS-TP), and TRILL. While OAM tools that are applicable to
other technologies exist, they are beyond the scope of this memo. other technologies exist, they are beyond the scope of this memo.
This document focuses on IETF documents that have been published as This document focuses on IETF documents that have been published as
RFCs, while other ongoing OAM-related work is outside the scope. RFCs, while other ongoing OAM-related work is outside the scope.
The IETF has defined OAM protocols and tools in several different The IETF has defined OAM protocols and tools in several different
contexts. We roughly categorize these efforts into a few sets of OAM- contexts. We roughly categorize these efforts into a few sets of OAM-
related RFCs, listed in Table 1. Each category defines a logically- related RFCs, listed in Table 1. Each set defines a logically-coupled
coupled set of RFCs, although the sets are in some cases intertwined set of RFCs, although the sets are in some cases intertwined by
by common tools and protocols. common tools and protocols.
The discussion in this document is ordered according to these The discussion in this document is ordered according to these sets.
categories.
+--------------+------------+ +--------------+------------+
| Category | Transport | | Toolset | Transport |
| | Technology | | | Technology |
+--------------+------------+ +--------------+------------+
|IP Ping | IPv4/IPv6 | |IP Ping | IPv4/IPv6 |
+--------------+------------+ +--------------+------------+
|IP Traceroute | IPv4/IPv6 | |IP Traceroute | IPv4/IPv6 |
+--------------+------------+ +--------------+------------+
|BFD | generic | |BFD | generic |
+--------------+------------+ +--------------+------------+
|MPLS OAM | MPLS | |MPLS OAM | MPLS |
+--------------+------------+ +--------------+------------+
|MPLS-TP OAM | MPLS-TP | |MPLS-TP OAM | MPLS-TP |
+--------------+------------+ +--------------+------------+
|Pseudowire OAM| Pseudowires| |Pseudowire OAM| Pseudowires|
+--------------+------------+ +--------------+------------+
|OWAMP and | IPv4/IPv6 | |OWAMP and | IPv4/IPv6 |
|TWAMP | | |TWAMP | |
+--------------+------------+ +--------------+------------+
|TRILL OAM | TRILL | |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 OAM tools may, and quite often do, work in conjunction with a control
plane and/or management plane. At the data plane, OAM provides plane and/or management plane. OAM provides instrumentation tools
instrumentation tools. OAM tools often use control plane functions, for measuring and monitoring the data plane. OAM tools often use
e.g., to initialize OAM sessions and to exchange various parameters. control plane functions, e.g., to initialize OAM sessions and to
The OAM tools communicate with the management plane to raise alarms, exchange various parameters. The OAM tools communicate with the
and often OAM tools may be activated by the management (as well as by management plane to raise alarms, and often OAM tools may be
the control plane), e.g. to locate and localize problems. 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 The considerations of the control plane maintenance tools and the
functionality of the management plane are out of scope for this functionality of the management plane are out of scope for this
document, which concentrates on presenting the data plane tools that document, which concentrates on presenting the data plane tools that
are used for OAM. Network repair functions such as Fast Reroute (FRR) are used for OAM. Network repair functions such as Fast Reroute (FRR)
and protection switching, which are often triggered by OAM protocols, and protection switching, which are often triggered by OAM protocols,
are also out of the scope of this document. are also out of the scope of this document.
Since OAM protocols are used for monitoring the data plane, it is Since OAM protocols are used for monitoring the data plane, it is
imperative for OAM tools to be capable of testing the actual data imperative for OAM tools to be capable of testing the actual data
skipping to change at page 10, line 34 skipping to change at page 10, line 34
implemented using UDP and ICMP messages, without using an OAM implemented using UDP and ICMP messages, without using an OAM
protocol per se. protocol per se.
2.2.4. Data Plane, Control Plane and Management Plane 2.2.4. Data Plane, Control Plane and Management Plane
Data Plane Data Plane
The data plane is the set of functions used to transfer data in the The data plane is the set of functions used to transfer data in the
stratum or layer under consideration [ITU-Terms]. stratum or layer under consideration [ITU-Terms].
.
The Data Plane is also known as the Forwarding Plane or the User The Data Plane is also known as the Forwarding Plane or the User
Plane. Plane.
Control Plane Control Plane
The control plane is the set of protocols and mechanisms that enable The control plane is the set of protocols and mechanisms that enable
routers to efficiently learn how to forward packets towards their routers to efficiently learn how to forward packets towards their
final destination (based on [Comp]). final destination (based on [Comp]).
Management Plane Management Plane
skipping to change at page 11, line 6 skipping to change at page 11, line 4
Management Plane Management Plane
The term Management Plane, as described in [Mng], is used to describe The term Management Plane, as described in [Mng], is used to describe
the exchange of management messages through management protocols the exchange of management messages through management protocols
(often transported by IP and by IP transport protocols) between (often transported by IP and by IP transport protocols) between
management applications and the managed entities such as network management applications and the managed entities such as network
nodes. nodes.
Data Plane vs. Control Plane vs. Management Plane Data Plane vs. Control Plane vs. Management Plane
The distinction between the planes is at times a bit vague. For The distinction between the planes is at times a bit vague. For
example, the definition of "Control Plane" above may imply that OAM 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. 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 This document focuses on tools used for monitoring the data plane.
monitoring the data plane. While these tools could arguably be While these tools could arguably be considered to be in the control
considered to be in the control plane, these tools monitor the data plane, these tools monitor the data plane, and hence it is imperative
plane, and hence it is imperative to have fate-sharing between OAM to have fate-sharing between OAM traffic that monitors the data plane
traffic that monitors the data plane and the data plane traffic it and the data plane traffic it monitors.
monitors.
Another potentially vague distinction is between the management plane Another potentially vague distinction is between the management plane
and control plane. The management plane should be seen as separate and control plane. The management plane should be seen as separate
from, but possibly overlapping with, the control plane (based on from, but possibly overlapping with, the control plane (based on
[Mng]). [Mng]).
2.2.5. The Players 2.2.5. The Players
An OAM tool is used between two (or more) "players". Various terms 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 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. discussed in this document.
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| Category | Terms | | Toolset | Terms |
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| Ping / Traceroute |-Host | | Ping / Traceroute |-Host |
| ([ICMPv4], [ICMPv6], |-Node | | ([ICMPv4], [ICMPv6], |-Node |
| [TCPIP-Tools]) |-Interface | | [TCPIP-Tools]) |-Interface |
| |-Gateway | | |-Gateway |
+ ------------------------ + ------------------------ + + ------------------------ + ------------------------ +
| BFD [BFD] | System | | BFD [BFD] | System |
+ ------------------------ + ------------------------ + + ------------------------ + ------------------------ +
| MPLS OAM [MPLS-OAM-FW] | LSR | | MPLS OAM [MPLS-OAM-FW] | LSR |
+ ------------------------ + ------------------------ + + ------------------------ + ------------------------ +
skipping to change at page 12, line 42 skipping to change at page 12, line 39
Continuity Check Continuity Check
Continuity checks are used to verify that a destination is reachable, Continuity checks are used to verify that a destination is reachable,
and are typically sent proactively, though they can be invoked on- and are typically sent proactively, though they can be invoked on-
demand as well. demand as well.
Connectivity Verification Connectivity Verification
A connectivity verification function allows Alice to check whether A connectivity verification function allows Alice to check whether
she is connected to Bob or not. This function also allows Alice to she is connected to Bob or not. It is noted that while the CV
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 function is performed in the data plane, the "expected path" is
predetermined either in the control plane or in the management plane. predetermined either in the control plane or in the management plane.
A connectivity verification (CV) protocol typically uses a CV A connectivity verification (CV) protocol typically uses a CV
message, followed by a CV reply that is sent back to the originator. message, followed by a CV reply that is sent back to the originator.
A CV function can be applied proactively or on-demand. 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 Connectivity verification and continuity checks are considered
complementary mechanisms, and are often used in conjunction with each complementary mechanisms, and are often used in conjunction with each
other. other.
2.2.8. Connection Oriented vs. Connectionless Communication 2.2.8. Connection Oriented vs. Connectionless Communication
Connection Oriented Connection Oriented
In Connection Oriented technologies an end-to-end connection is In Connection Oriented technologies an end-to-end connection is
established (by a control protocol or provisioned by a management established (by a control protocol or provisioned by a management
skipping to change at page 14, line 19 skipping to change at page 14, line 19
2.2.9. Point-to-point vs. Point-to-multipoint Services 2.2.9. Point-to-point vs. Point-to-multipoint Services
Point-to-point (P2P) Point-to-point (P2P)
A P2P service delivers data from a single source to a single A P2P service delivers data from a single source to a single
destination. destination.
Point-to-multipoint (P2MP) 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]). destinations (based on [Signal]).
[Signal] also defines a MP2MP service as a service that delivers data An MP2MP service as a service that delivers data from more than one
from more than one source to one or more receivers. source to one or more receivers (based on [Signal]).
Discussion Discussion
The OAM tools described in this document include tools for P2P The OAM tools described in this document include tools for P2P
services, as well as tools for P2MP services. services, as well as tools for P2MP services.
The distinction between P2P services and P2MP services affects the The distinction between P2P services and P2MP services affects the
corresponding OAM tools. A P2P service is typically simpler to corresponding OAM tools. A P2P service is typically simpler to
monitor, as it consists of a single pair of end points. P2MP services monitor, as it consists of a single pair of end points. P2MP services
present several challenges. For example, in a P2MP service, the OAM present several challenges. For example, in a P2MP service, the OAM
mechanism not only verifies that each of the destinations is mechanism not only verifies that each of the destinations is
reachable from the source, but also verifies that the P2MP reachable from the source, but also verifies that the P2MP
distribution tree is intact and loop-free. Another challenge in P2MP distribution tree is intact and loop-free.
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.
2.2.10. Failures 2.2.10. Failures
The terms Failure, Fault, and Defect are used interchangeably in the The terms Failure, Fault, and Defect are used interchangeably in the
standards, referring to a malfunction that can be detected by a standards, referring to a malfunction that can be detected by a
connectivity or a continuity check. In some standards, such as connectivity or a continuity check. In some standards, such as
802.1ag [IEEE802.1Q] , there is no distinction between these terms, 802.1ag [IEEE802.1Q] , there is no distinction between these terms,
while in other standards each of these terms refers to a different while in other standards each of these terms refers to a different
type of malfunction. type of malfunction.
skipping to change at page 15, line 32 skipping to change at page 15, line 25
The term Failure refers to the termination of the required function. The term Failure refers to the termination of the required function.
While a Defect typically refers to a limited period of time, a While a Defect typically refers to a limited period of time, a
failure refers to a long period of time. failure refers to a long period of time.
3. OAM Functions 3. OAM Functions
This subsection provides a brief summary of the common OAM functions This subsection provides a brief summary of the common OAM functions
used in OAM-related standards. These functions are used as building used in OAM-related standards. These functions are used as building
blocks in the OAM standards described in this document. 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. As defined in Section 2.2.7.
o Path Discovery / Fault Localization: o Path Discovery / Fault Localization:
This function can be used to trace the route to a destination, This function can be used to trace the route to a destination,
i.e., to identify the nodes along the route to the destination. i.e., to identify the nodes along the route to the destination.
When more than one route is available to a specific destination, When more than one route is available to a specific destination,
this function traces one of the available routes. When a failure this function traces one of the available routes. When a failure
occurs, this function also allows to detect the location of the occurs, this function also allows to detect the location of the
failure. failure.
Note that the term route tracing (or Traceroute) that is used in Note that the term route tracing (or Traceroute) that is used in
skipping to change at page 16, line 11 skipping to change at page 16, line 8
Typically refers to: Typically refers to:
o Loss Measurement (LM) - monitors the packet loss rate. o Loss Measurement (LM) - monitors the packet loss rate.
o Delay Measurement (DM) - monitors the delay and delay o Delay Measurement (DM) - monitors the delay and delay
variation. variation.
4. OAM Tools in the IETF - a Detailed Description 4. OAM Tools in the IETF - a Detailed Description
This section presents a detailed description of the sets of OAM- 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 4.1. IP Ping
Ping is a common network diagnosis application for IP networks that Ping is a common network diagnosis application for IP networks that
uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for
Packet internet groper, although the term has been so commonly used 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 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 used to test reachability of destinations by sending them an ICMP
echo request and waiting for a reply. echo request and waiting for a reply.
skipping to change at page 18, line 10 skipping to change at page 18, line 7
deployed over various encapsulating protocols, and in various medium deployed over various encapsulating protocols, and in various medium
types. The IETF has defined variants of the protocol for IP ([BFD- types. The IETF has defined variants of the protocol for IP ([BFD-
IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [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]. 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 includes two main OAM functions, using two types of BFD packets:
BFD Control packets, and BFD Echo packets. BFD Control packets, and BFD Echo packets.
4.3.2. Terminology 4.3.2. Terminology
BFD operates between two *systems*. The BFD protocol is run between BFD operates between *systems*. The BFD protocol is run between two
two systems after establishing a *session*. or more systems after establishing a *session*.
4.3.3. BFD Control 4.3.3. BFD Control
BFD supports a bidirectional continuity check, using BFD control BFD supports a bidirectional continuity check, using BFD control
packets, that are exchanged within a BFD session. BFD sessions packets, that are exchanged within a BFD session. BFD sessions
operate in one of two modes: operate in one of two modes:
o Asynchronous mode (i.e. proactive): in this mode BFD control o Asynchronous mode (i.e. proactive): in this mode BFD control
packets are sent periodically. When the receiver detects that no packets are sent periodically. When the receiver detects that no
BFD control packets have been received during a predetermined BFD control packets have been received during a predetermined
skipping to change at page 19, line 31 skipping to change at page 19, line 31
connectivity verification between two LERs. connectivity verification between two LERs.
o "Traceroute" mode: This mode is used for hop-by-hop fault o "Traceroute" mode: This mode is used for hop-by-hop fault
isolation. isolation.
LSP Ping extends the basic ICMP Ping operation (of data-plane LSP Ping extends the basic ICMP Ping operation (of data-plane
connectivity verification) with functionality to verify data-plane connectivity verification) with functionality to verify data-plane
vs. control-plane consistency for a Forwarding Equivalence Class vs. control-plane consistency for a Forwarding Equivalence Class
(FEC) and also Maximum Transmission Unit (MTU) problems. (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 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 be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping
monitors all the available paths of an LSP by monitoring its monitors all the available paths of an LSP by monitoring its
different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP different Forwarding Equivalence Classes (FEC). Conversely, MPLS-TP
does not use ECMP, and thus does not require OAM over multiple paths. 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 Another challenge is that an MPLS LSP does not necessarily have a
identify the sub-path of the LSP that is successfully traversed return path, and thus responding to an LSP Ping message is not
before the faulty link or node. 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 It should be noted that LSP Ping supports unique identification of
the LSP within an addressing domain. The identification is checked the LSP within an addressing domain. The identification is checked
using the full FEC identification. LSP Ping is easily extensible to using the full FEC identification. LSP Ping is easily extensible to
include additional information needed to support new functionality, include additional information needed to support new functionality,
by use of Type-Length-Value (TLV) constructs. The usage of TLVs is by use of Type-Length-Value (TLV) constructs. The usage of TLVs is
typically not easy to perform in hardware, and is thus typically typically not easy to perform in hardware, and is thus typically
handled by the control plane. handled by the control plane.
LSP Ping supports both asynchronous, as well as, on-demand LSP Ping supports both asynchronous, as well as, on-demand
skipping to change at page 20, line 34 skipping to change at page 20, line 40
in environments where IP functionality is not available, the OAM in environments where IP functionality is not available, the OAM
tools must still be able to operate without dependence on IP tools must still be able to operate without dependence on IP
forwarding and routing. forwarding and routing.
o OAM packets and the user traffic are required to be congruent 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 (i.e. OAM packets are transmitted in-band) and there is a need to
differentiate OAM packets from data plane ones. Inherent in this differentiate OAM packets from data plane ones. Inherent in this
requirement is the principle that MPLS-TP OAM be independent of requirement is the principle that MPLS-TP OAM be independent of
any existing control-plane, although it should not preclude use of any existing control-plane, although it should not preclude use of
the control-plane functionality. 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 4.5.2. Terminology
Maintenance Entity (ME) Maintenance Entity (ME)
The MPLS-TP OAM tools are designed to monitor and manage a 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 Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a
relationship between two points of a transport path to which relationship between two points of a transport path to which
maintenance and monitoring operations apply. maintenance and monitoring operations apply.
skipping to change at page 30, line 23 skipping to change at page 30, line 26
o Connectivity Verification (CV) - connectivity between two RBridges o Connectivity Verification (CV) - connectivity between two RBridges
RB1 and RB2 can be verified on a per-flow basis. RB1 and RB2 can be verified on a per-flow basis.
o Path Tracing - allows an RBridge to trace all the available paths o Path Tracing - allows an RBridge to trace all the available paths
to a peer RBridge. to a peer RBridge.
o Performance monitoring - allows an RBridge to monitor the packet o Performance monitoring - allows an RBridge to monitor the packet
loss and packet delay to a peer RBridge. 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 This section summarizes the OAM tools and functions presented in this
categories described in this document. 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. Appendix A.1.
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
| Category | Description | Transport | | Toolset | Description | Transport |
| | | Technology | | | | Technology |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
|IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 |
| | application for testing reachability that| | | | application for testing reachability that| |
| | uses ICMP Echo messages ([ICMPv4], | | | | uses ICMP Echo messages ([ICMPv4], | |
| | [ICMPv6]). | | | | [ICMPv6]). | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
|IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 |
|Traceroute | an application that allows users to trace| | |Traceroute | an application that allows users to trace| |
| | the path between an IP source and an IP | | | | the path between an IP source and an IP | |
skipping to change at page 32, line 25 skipping to change at page 32, line 36
| | defined in [TRILL-OAM]. These | | | | defined in [TRILL-OAM]. These | |
| | requirements include continuity checking,| | | | requirements include continuity checking,| |
| | connectivity verification, path tracing | | | | connectivity verification, path tracing | |
| | and performance monitoring. During the | | | | and performance monitoring. During the | |
| | writing of this document the detailed | | | | writing of this document the detailed | |
| | definition of the TRILL OAM tools | | | | definition of the TRILL OAM tools | |
| | is work in progress. | | | | is work in progress. | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
Table 3 Summary of OAM-related IETF Tools 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 Table 4 summarizes the OAM functions that are supported in each of
the categories that were analyzed in this section. The columns of the toolsets that were analyzed in this section. The columns of this
this tables are the typical OAM functions described in Section 1.3. tables are the typical OAM functions described in Section 1.3.
+-----------+-------+--------+--------+-------+----------+ +-----------+-------+--------+--------+-------+----------+
| |Continu|Connecti|Path |Perform|Other | | |Continu|Connecti|Path |Perform|Other |
| |ity |vity |Discover|ance |Function | | |ity |vity |Discover|ance |Function |
| |Check |Verifica|y |Monitor|s | | |Check |Verifica|y |Monitor|s |
| Category | |tion | |ing | | | Toolset | |tion | |ing | |
+-----------+-------+--------+--------+-------+----------+ +-----------+-------+--------+--------+-------+----------+
|IP Ping |Echo | | | | | |IP Ping |Echo | | | | |
+ --------- + ----- + ------ + ------ + ----- + -------- + + --------- + ----- + ------ + ------ + ----- + -------- +
|IP | | |Tracerou| | | |IP | | |Tracerou| | |
|Traceroute | | |te | | | |Traceroute | | |te | | |
+ --------- + ----- + ------ + ------ + ----- + -------- + + --------- + ----- + ------ + ------ + ----- + -------- +
|BFD |BFD |BFD | | |RDI usi- | |BFD |BFD |BFD | | |RDI usi- |
| |Control|Control | | |ng BFD | | |Control|Control | | |ng BFD |
| |/ Echo | | | |Control | | |/ Echo | | | |Control |
+ --------- + ----- + ------ + ------ + ----- + -------- + + --------- + ----- + ------ + ------ + ----- + -------- +
skipping to change at page 33, line 42 skipping to change at page 34, line 12
|TRILL OAM |CC |CV |Path |-Delay | | |TRILL OAM |CC |CV |Path |-Delay | |
| | | |tracing | measur| | | | | |tracing | measur| |
| | | | | ement | | | | | | | ement | |
| | | | |-Packet| | | | | | |-Packet| |
| | | | | loss | | | | | | | loss | |
| | | | | measur| | | | | | | measur| |
| | | | | ement | | | | | | | ement | |
+-----------+-------+--------+--------+-------+----------+ +-----------+-------+--------+--------+-------+----------+
Table 4 Summary of the OAM Functionality in IETF OAM Tools 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 This memo presents an overview of existing OAM tools, and proposes
no new OAM tools. Therefore, this document introduces no security no new OAM tools. Therefore, this document introduces no security
considerations. However, the OAM tools reviewed in this document can considerations. However, the OAM tools reviewed in this document can
and do present security issues. The reader is encouraged to review and do present security issues. The reader is encouraged to review
the Security Considerations section of each document referenced by the Security Considerations section of each document referenced by
this memo. this memo.
6. IANA Considerations 7. IANA Considerations
There are no new IANA considerations implied by this document. There are no new IANA considerations implied by this document.
7. Acknowledgments 8. Acknowledgments
The authors gratefully acknowledge Sasha Vainshtein, Carlos The authors gratefully acknowledge Sasha Vainshtein, Carlos
Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other
members of the OPSAWG mailing list for their helpful comments. members of the OPSAWG mailing list for their helpful comments.
This document was prepared using 2-Word-v2.0.template.dot. 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, [ATM-L2] Singh, S., Townsley, M., and C. Pignataro,
"Asynchronous Transfer Mode (ATM) over Layer 2 "Asynchronous Transfer Mode (ATM) over Layer 2
Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May
2006. 2006.
[BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010.
[BFD-Gen] Katz, D., Ward, D., "Generic Application of [BFD-Gen] Katz, D., Ward, D., "Generic Application of
skipping to change at page 40, line 27 skipping to change at page 40, line 47
different by nature. For example, some of these documents define OAM different by nature. For example, some of these documents define OAM
tools or OAM protocols (or both), while others define protocols that tools or OAM protocols (or both), while others define protocols that
are not strictly OAM-related, but are used by OAM tools. The table are not strictly OAM-related, but are used by OAM tools. The table
also includes RFCs that define the requirements or the framework of also includes RFCs that define the requirements or the framework of
OAM in a specific context (e.g., MPLS-TP). OAM in a specific context (e.g., MPLS-TP).
The RFCs in the table are categorized in a few sets as defined in The RFCs in the table are categorized in a few sets as defined in
Section 1.3. Section 1.3.
+-----------+--------------------------------------+----------+ +-----------+--------------------------------------+----------+
| Category | Title | RFC | | Toolset | Title | RFC |
+-----------+--------------------------------------+----------+ +-----------+--------------------------------------+----------+
|IP Ping | Requirements for Internet Hosts -- | RFC 1122 | |IP Ping | Requirements for Internet Hosts -- | RFC 1122 |
| | Communication Layers [IntHost] | | | | Communication Layers [IntHost] | |
| +--------------------------------------+----------+ | +--------------------------------------+----------+
| | A Glossary of Networking Terms | RFC 1208 | | | A Glossary of Networking Terms | RFC 1208 |
| | [NetTerms] | | | | [NetTerms] | |
| +--------------------------------------+----------+ | +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 792 | | | Internet Control Message Protocol | RFC 792 |
| | [ICMPv4] | | | | [ICMPv4] | |
| +--------------------------------------+----------+ | +--------------------------------------+----------+
skipping to change at page 47, line 16 skipping to change at page 47, line 34
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Yokneam, 20692
Israel Israel
Email: talmi@marvell.com Email: talmi@marvell.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks NSN
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Elisa Bellagamba Elisa Bellagamba
Ericsson Ericsson
6 Farogatan St. 6 Farogatan St.
Stockholm, 164 40 Stockholm, 164 40
Sweden Sweden
Phone: +46 761440785 Phone: +46 761440785
Email: elisa.bellagamba@ericsson.com Email: elisa.bellagamba@ericsson.com
Yaacov Weingarten Yaacov Weingarten
34 Hagefen St. 34 Hagefen St.
Karnei Shomron, 4485500 Karnei Shomron, 4485500
Israel Israel
 End of changes. 52 change blocks. 
94 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/