draft-ietf-opsawg-oam-overview-14.txt   draft-ietf-opsawg-oam-overview-15.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: August 2014 Nokia Solutions and Networks Expires: September 2014 Nokia Solutions and Networks
E. Bellagamba E. Bellagamba
Ericsson Ericsson
Y. Weingarten Y. Weingarten
February 18, 2014 March 25, 2014
An Overview of An Overview of
Operations, Administration, and Maintenance (OAM) Tools Operations, Administration, and Maintenance (OAM) Tools
draft-ietf-opsawg-oam-overview-14.txt draft-ietf-opsawg-oam-overview-15.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 OAM tools defined in the IETF in This document summarizes some of the OAM tools defined in the IETF in
the context of IP unicast, MPLS, MPLS for the transport profile the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP),
(MPLS-TP), pseudowires, and TRILL. This document focuses on tools for pseudowires, and TRILL. This document focuses on tools for detecting
detecting and isolating failures in networks and for performance and isolating failures in networks and for performance monitoring.
monitoring. Control and management aspects of OAM are outside the Control and management aspects of OAM are outside the scope of this
scope of this document. Network repair functions such as Fast Reroute document. Network repair functions such as Fast Reroute (FRR) and
(FRR) and protection switching, which are often triggered by OAM protection switching, which are often triggered by OAM protocols, are
protocols, are also out of the scope of this document. 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 standards development organizations,
and can be used as an index to some of the main OAM tools defined in 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 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 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. 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.
skipping to change at page 2, line 16 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 August 18, 2014. This Internet-Draft will expire on September 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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 ................................................. 4 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 the Data Plane .............................. 6 1.4. Focusing on the Data Plane .............................. 7
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 .................... 10 2.2.3. Functions, Tools and Protocols .................... 10
2.2.4. Data Plane, Control Plane and Management Plane .... 10 2.2.4. Data Plane, Control Plane and Management Plane .... 11
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 ... 13
2.2.8. Connection Oriented vs. Connectionless Communication13 2.2.8. Connection Oriented vs. Connectionless Communication13
2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14 2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14
2.2.10. Failures ......................................... 15 2.2.10. Failures ......................................... 15
3. OAM Functions ............................................... 15 3. OAM Functions ............................................... 16
4. OAM Tools in the IETF - a Detailed Description .............. 16 4. OAM Tools in the IETF - a Detailed Description .............. 16
4.1. IP Ping ................................................ 16 4.1. IP Ping ................................................ 16
4.2. IP Traceroute .......................................... 17 4.2. IP Traceroute .......................................... 17
4.3. Bidirectional Forwarding Detection (BFD) ............... 18 4.3. Bidirectional Forwarding Detection (BFD) ............... 18
4.3.1. Overview .......................................... 18 4.3.1. Overview .......................................... 18
4.3.2. Terminology ....................................... 18 4.3.2. Terminology ....................................... 18
4.3.3. BFD Control ....................................... 18 4.3.3. BFD Control ....................................... 19
4.3.4. BFD Echo .......................................... 19 4.3.4. BFD Echo .......................................... 19
4.4. MPLS OAM ............................................... 19 4.4. MPLS OAM ............................................... 20
4.4.1. LSP Ping .......................................... 19 4.4.1. LSP Ping .......................................... 20
4.4.2. BFD for MPLS ...................................... 20 4.4.2. BFD for MPLS ...................................... 21
4.4.3. OAM for Virtual Private Networks (VPN) over MPLS .. 21 4.4.3. OAM for Virtual Private Networks (VPN) over MPLS .. 21
4.5. MPLS-TP OAM ............................................ 21 4.5. MPLS-TP OAM ............................................ 21
4.5.1. Overview .......................................... 21 4.5.1. Overview .......................................... 21
4.5.2. Terminology ....................................... 21 4.5.2. Terminology ....................................... 22
4.5.3. Generic Associated Channel ........................ 23 4.5.3. Generic Associated Channel ........................ 23
4.5.4. MPLS-TP OAM Toolset ............................... 23 4.5.4. MPLS-TP OAM Toolset ............................... 24
4.5.4.1. Continuity Check and Connectivity Verification 24 4.5.4.1. Continuity Check and Connectivity Verification 24
4.5.4.2. Route Tracing ................................ 24 4.5.4.2. Route Tracing ................................ 25
4.5.4.3. Lock Instruct ................................ 25 4.5.4.3. Lock Instruct ................................ 25
4.5.4.4. Lock Reporting ............................... 25 4.5.4.4. Lock Reporting ............................... 25
4.5.4.5. Alarm Reporting .............................. 25 4.5.4.5. Alarm Reporting .............................. 25
4.5.4.6. Remote Defect Indication ..................... 25 4.5.4.6. Remote Defect Indication ..................... 26
4.5.4.7. Client Failure Indication .................... 25 4.5.4.7. Client Failure Indication .................... 26
4.5.4.8. Performance Monitoring ....................... 25 4.5.4.8. Performance Monitoring ....................... 26
4.5.4.8.1. Packet Loss Measurement (LM) ............ 26 4.5.4.8.1. Packet Loss Measurement (LM) ............ 26
4.5.4.8.2. Packet Delay Measurement (DM) ........... 26 4.5.4.8.2. Packet Delay Measurement (DM) ........... 27
4.6. Pseudowire OAM ......................................... 27 4.6. Pseudowire OAM ......................................... 27
4.6.1. Pseudowire OAM using Virtual Circuit Connectivity 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity
Verification (VCCV) ...................................... 27 Verification (VCCV) ...................................... 27
4.6.2. Pseudowire OAM using G-ACh ........................ 28 4.6.2. Pseudowire OAM using G-ACh ........................ 28
4.6.3. Attachment Circuit - Pseudowire Mapping ........... 28 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 29
4.7. OWAMP and TWAMP......................................... 28 4.7. OWAMP and TWAMP......................................... 29
4.7.1. Overview .......................................... 28 4.7.1. Overview .......................................... 29
4.7.2. Control and Test Protocols ........................ 29 4.7.2. Control and Test Protocols ........................ 30
4.7.3. OWAMP ............................................. 30 4.7.3. OWAMP ............................................. 30
4.7.4. TWAMP ............................................. 30 4.7.4. TWAMP ............................................. 31
4.8. TRILL .................................................. 31 4.8. TRILL .................................................. 31
5. Summary ..................................................... 31 5. Summary ..................................................... 32
5.1. Summary of OAM Tools ................................... 31 5.1. Summary of OAM Tools ................................... 32
5.2. Summary of OAM Functions ............................... 34 5.2. Summary of OAM Functions ............................... 34
5.3. Guidance to Network Equipment Vendors .................. 35 5.3. Guidance to Network Equipment Vendors .................. 36
6. Security Considerations ..................................... 35 6. Security Considerations ..................................... 36
7. IANA Considerations ......................................... 35 7. IANA Considerations ......................................... 36
8. Acknowledgments ............................................. 35 8. Acknowledgments ............................................. 37
9. References .................................................. 36 9. References .................................................. 37
9.1. Informative References ................................. 36 9.1. Informative References ................................. 37
Appendix A. List of OAM Documents .............................. 42 Appendix A. List of OAM Documents .............................. 43
A.1. List of IETF OAM Documents ............................. 42 A.1. List of IETF OAM Documents ............................. 43
A.2. List of Selected Non-IETF OAM Documents ................ 46 A.2. List of Selected Non-IETF OAM Documents ................ 48
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 [OAM-Def]. as recommended in Section 3 of [OAM-Def].
This document summarizes some of the OAM tools defined in the IETF in This document summarizes some of the OAM tools defined in the IETF in
the context of IP unicast, MPLS, MPLS for the transport profile the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP),
(MPLS-TP), pseudowires, and TRILL. pseudowires, and TRILL.
This document focuses on tools for detecting and isolating failures This document focuses on tools for detecting and isolating failures
and for performance monitoring. Hence, this document focuses on the and for performance monitoring. Hence, this document focuses on the
tools used for monitoring and measuring the data plane; control and tools used for monitoring and measuring the data plane; control and
management aspects of OAM are outside 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 Network repair functions such as Fast Reroute (FRR) and protection
switching, which are often triggered by OAM protocols, are also out switching, which are often triggered by OAM protocols, are also out
of the scope of this document. 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. As packet-based networks evolved, they
they have become the common transport for both data and telephony, have become the common transport for both data and telephony,
replacing traditional transport protocols. Consequently, packet-based replacing traditional transport protocols. Consequently, packet-based
networks were expected to provide a similar "carrier grade" networks were expected to provide a similar "carrier grade"
experience, and specifically to support OAM. experience, and specifically to support more advanced OAM functions,
beyond ICMP and router hellos, that were traditionally used for fault
detection.
As typical networks have a multi-layer architecture, the set of OAM As typical networks have a multi-layer architecture, the set of OAM
protocols similarly take a multi-layer structure; each layer has its protocols similarly take a multi-layer structure; each layer has its
own OAM protocols. Moreover, OAM can be used at different levels of own OAM protocols. Moreover, OAM can be used at different levels of
hierarchy in the network to form a multi-layer OAM solution, as shown hierarchy in the network to form a multi-layer OAM solution, as shown
in the example in Figure 1. in the example in Figure 1.
Figure 1 illustrates a network in which IP traffic between two Figure 1 illustrates a network in which IP traffic between two
customer edges is transported over an MPLS provider network. MPLS OAM customer edges is transported over an MPLS provider network. MPLS OAM
is used at the provider-level for monitoring the connection between is used at the provider-level for monitoring the connection between
skipping to change at page 5, line 32 skipping to change at page 5, line 34
+-----+ +----+ +----+ +-----+ +-----+ +----+ +----+ +-----+
Customer Provider Provider Customer Customer Provider Provider Customer
Edge Edge Edge Edge Edge Edge Edge Edge
Figure 1 Example: Multi-layer OAM Figure 1 Example: Multi-layer OAM
1.2. Target Audience 1.2. Target Audience
The target audience of this document includes: The target audience of this document includes:
o Standard development organizations - both IETF working groups and o Standards development organizations - both IETF working groups and
non-IETF organizations can benefit from this document when non-IETF organizations can benefit from this document when
designing new OAM protocols, or when looking to reuse existing OAM designing new OAM protocols, or when looking to reuse existing OAM
tools for new technologies. tools for new technologies.
o Network equipment vendors and network operators - can use this o Network equipment vendors and network operators - can use this
document as an index to some of the common IETF OAM tools. document as an index to some of the common IETF OAM tools.
It should be noted that this document is not necessarily suitable for It should be noted that this document is not necessarily suitable for
beginners without any background in OAM. beginners without any background in OAM.
1.3. OAM-related Work in the IETF 1.3. OAM-related Work in the IETF
This memo provides an overview of the different sets of OAM tools This memo provides an overview of the different sets of OAM tools
defined by the IETF. The set of OAM tools described in this memo are 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 Transport Profile
profile (MPLS-TP), and TRILL. While OAM tools that are applicable to (MPLS-TP), and TRILL. While OAM tools that are applicable to other
other technologies exist, they are beyond the scope of this memo. 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 set defines a logically-coupled related RFCs, listed in Table 1. Each set defines a logically-coupled
set of RFCs, although the sets are in some cases intertwined by set of RFCs, although the sets are in some cases intertwined by
common tools and protocols. common tools and protocols.
The discussion in this document is ordered according to these sets. The discussion in this document is ordered according to these sets
(the acronyms and abbreviations are listed in Section 2.1.).
+--------------+------------+ +--------------+------------+
| Toolset | 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 |
skipping to change at page 7, line 7 skipping to change at page 7, line 13
Appendix A.2. Appendix A.2.
1.4. Focusing on the Data Plane 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. OAM provides instrumentation tools plane and/or management plane. OAM provides instrumentation tools
for measuring and monitoring the data plane. OAM tools often use for measuring and monitoring the data plane. OAM tools often use
control plane functions, e.g., to initialize OAM sessions and to control plane functions, e.g., to initialize OAM sessions and to
exchange various parameters. The OAM tools communicate with the exchange various parameters. The OAM tools communicate with the
management plane to raise alarms, and often OAM tools may be management plane to raise alarms, and often OAM tools may be
activated by the management (as well as by the control plane), e.g. activated by the management (as well as by the control plane), e.g.,
to locate and localize problems. 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
plane in as much accuracy as possible. Thus, it is important to plane with as much accuracy as possible. Thus, it is important to
enforce fate-sharing between OAM traffic that monitors the data plane enforce fate-sharing between OAM traffic that monitors the data plane
and the data plane traffic it monitors. and the data plane traffic it monitors.
2. Terminology 2. Terminology
2.1. Abbreviations 2.1. Abbreviations
ACH Associated Channel Header ACH Associated Channel Header
AIS Alarm Indication Signal AIS Alarm Indication Signal
skipping to change at page 11, line 41 skipping to change at page 11, line 48
to have fate-sharing between OAM traffic that monitors the data plane to have fate-sharing between OAM traffic that monitors the data plane
and the data plane traffic it monitors. and the data plane traffic it 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) peers. Various terms are
are used in IETF documents to refer to the players that take part in used in IETF documents to refer to the players that take part in OAM.
OAM. Table 2 summarizes the terms used in each of the toolsets Table 2 summarizes the terms used in each of the toolsets discussed
discussed in this document. in this document.
+--------------------------+--------------------------+ +--------------------------+--------------------------+
| Toolset | 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 |
skipping to change at page 13, line 21 skipping to change at page 13, line 28
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. 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 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 Connectivity verification tools often perform path verification as
well, allowing Alice to verify that messages from Bob are received well, allowing Alice to verify that messages from Bob are received
through the correct path, thereby verifying not only that the two MPs through the correct path, thereby verifying not only that the two MPs
are connected, but also that they are connected through the expected are connected, but also that they are connected through the expected
path, allowing detection of unexpected topology changes. path, allowing detection of unexpected topology changes.
Connectivity verification functions can also be used for checking the
MTU of the path between the two peers.
Connectivity verification and continuity checks are considered 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 15, line 7 skipping to change at page 15, line 17
MP2MP which is MPLS-specific, these two definitions also apply to MP2MP which is MPLS-specific, these two definitions also apply to
non-MPLS cases. non-MPLS cases.
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 and
present several challenges. For example, in a P2MP service, the OAM MP2MP services present several challenges. For example, in a P2MP
mechanism not only verifies that each of the destinations is service, the OAM mechanism not only verifies that each of the
reachable from the source, but also verifies that the P2MP destinations is reachable from the source, but also verifies that the
distribution tree is intact and loop-free. P2MP distribution tree is intact and loop-free.
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 16, line 10 skipping to change at page 16, line 20
o Connectivity Verification (CV), Path Verification and Continuity o Connectivity Verification (CV), Path Verification and Continuity
Checks (CC): 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 attempts 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
the context of IP and MPLS, is sometimes referred to as path the context of IP and MPLS, is sometimes referred to as path
tracing in the context of other protocols, such as TRILL. tracing in the context of other protocols, such as TRILL.
o Performance Monitoring: o Performance Monitoring:
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 (jitter).
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 toolsets 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
skipping to change at page 16, line 44 skipping to change at page 17, line 7
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.
The ICMP Echo request/reply exchange in Ping is used as a continuity The ICMP Echo request/reply exchange in Ping is used as a continuity
check function for the Internet Protocol. The originator transmits an check function for the Internet Protocol. The originator transmits an
ICMP Echo request packet, and the receiver replies with an Echo ICMP Echo request packet, and the receiver replies with an Echo
reply. ICMP ping is defined in two variants, [ICMPv4] is used for reply. ICMP ping is defined in two variants, [ICMPv4] is used for
IPv4, and [ICMPv6] is used for IPv6. IPv4, and [ICMPv6] is used for IPv6.
Ping can be invoked either to a unicast destination or to a multicast
destination. In the latter case, all members of the multicast group
send an Echo reply back to the originator.
Ping implementations typically use ICMP messages. UDP Ping is a Ping implementations typically use ICMP messages. UDP Ping is a
variant that uses UDP messages instead of ICMP echo messages. variant that uses UDP messages instead of ICMP echo messages.
Ping is a single-ended continuity check, i.e., it allows the Ping is a single-ended continuity check, i.e., it allows the
*initiator* of the Echo request to test the reachability. If it is *initiator* of the Echo request to test the reachability. If it is
desirable for both ends to test the reachability, both ends have to desirable for both ends to test the reachability, both ends have to
invoke Ping independently. invoke Ping independently.
Note that since ICMP filtering is deployed in some routers and Note that since ICMP filtering is deployed in some routers and
firewalls, the usefulness of Ping is sometimes limited in the wider firewalls, the usefulness of Ping is sometimes limited in the wider
skipping to change at page 18, line 7 skipping to change at page 18, line 22
Note that IP routing may be asymmetric. While Traceroute discovers a Note that IP routing may be asymmetric. While Traceroute discovers a
path between a source and destination, it does not reveal the reverse path between a source and destination, it does not reveal the reverse
path. path.
A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in
the context of Traceroute. These documents define several extensions, the context of Traceroute. These documents define several extensions,
including extensions to the ICMP Destination Unreachable message, including extensions to the ICMP Destination Unreachable message,
that can be used by Traceroute applications. that can be used by Traceroute applications.
Traceroute allows path discovery to *unicast* destination addresses.
A similar tool [mtrace] was defined for multicast destination
addresses, allowing to trace the route that a multicast IP packet
takes from a source to a particular receiver.
4.3. Bidirectional Forwarding Detection (BFD) 4.3. Bidirectional Forwarding Detection (BFD)
4.3.1. Overview 4.3.1. Overview
While multiple OAM tools have been defined for various protocols in While multiple OAM tools have been defined for various protocols in
the protocol stack, Bidirectional Forwarding Detection [BFD], defined the protocol stack, Bidirectional Forwarding Detection [BFD], defined
by the IETF BFD working group, is a generic OAM tool that can be by the IETF BFD working group, is a generic OAM tool that can be
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-
skipping to change at page 18, line 33 skipping to change at page 19, line 11
BFD operates between *systems*. The BFD protocol is run between two BFD operates between *systems*. The BFD protocol is run between two
or more 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
period of time, a failure is detected. period of time, a failure is reported.
o Demand mode: in this mode, BFD control packets are sent on-demand. o Demand mode: in this mode, BFD control packets are sent on-demand.
Upon need, a system initiates a series of BFD control packets to Upon need, a system initiates a series of BFD control packets to
check the continuity of the session. BFD control packets are sent check the continuity of the session. BFD control packets are sent
independently in each direction. independently in each direction.
Each of the end-points (referred to as systems) of the monitored path Each of the end-points (referred to as systems) of the monitored path
maintains its own session identification, called a Discriminator, maintains its own session identification, called a Discriminator,
both of which are included in the BFD Control Packets that are both of which are included in the BFD Control Packets that are
exchanged between the end-points. At the time of session exchanged between the end-points. At the time of session
establishment, the Discriminators are exchanged between the two-end establishment, the Discriminators are exchanged between the two-end
points. In addition, the transmission (and reception) rate is points. In addition, the transmission (and reception) rate is
negotiated between the two end-points, based on information included negotiated between the two end-points, based on information included
in the control packets. These transmission rates may be renegotiated in the control packets. These transmission rates may be renegotiated
during the session. during the session.
During normal operation of the session, i.e. no failures are During normal operation of the session, i.e., when no failures have
detected, the BFD session is in the Up state. If no BFD Control been detected, the BFD session is in the Up state. If no BFD Control
packets are received during a period of time called the Detection packets are received during a period of time called the Detection
Time, the session is declared to be Down. The detection time is a Time, the session is declared to be Down. The detection time is a
function of the pre-configured or negotiated transmission time, and a function of the pre-configured or negotiated transmission rate, and a
parameter called Detect Mult. Detect Mult determines the number of parameter called Detect Mult. Detect Mult determines the number of
missing BFD Control packets that cause the session to be declared as missing BFD Control packets that cause the session to be declared as
Down. This parameter is included in the BFD Control packet. Down. This parameter is included in the BFD Control packet.
4.3.4. BFD Echo 4.3.4. BFD Echo
A BFD echo packet is sent to a peer system, and is looped back to the A BFD echo packet is sent to a peer system, and is looped back to the
originator. The echo function can be used proactively, or on-demand. originator. The echo function can be used proactively, or on-demand.
The BFD echo function has been defined in BFD for IPv4 and IPv6 The BFD echo function has been defined in BFD for IPv4 and IPv6
skipping to change at page 19, line 50 skipping to change at page 20, line 30
o "Ping" mode: In this mode LSP Ping is used for end-to-end o "Ping" mode: In this mode LSP Ping is used for end-to-end
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 is based on ICMP Ping operation (of data-plane connectivity LSP Ping is based on ICMP Ping operation (of data-plane connectivity
verification) with additional functionality to verify data-plane vs. verification) with additional functionality to verify data-plane vs.
control-plane consistency for a Forwarding Equivalence Class (FEC) control-plane consistency for a Forwarding Equivalence Class (FEC)
and also Maximum Transmission Unit (MTU) problems. and also identify Maximum Transmission Unit (MTU) problems.
The Traceroute functionality may be used to isolate and localize the The Traceroute functionality may be used to isolate and localize MPLS
MPLS faults, using the Time-to-live (TTL) indicator to incrementally faults, using the Time-to-live (TTL) indicator to incrementally
identify the sub-path of the LSP that is successfully traversed identify the sub-path of the LSP that is successfully traversed
before the faulty link or node. 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). Note that MPLS-TP different Forwarding Equivalence Classes (FEC). Note that 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.
Another challenge is that an MPLS LSP does not necessarily have a Another challenge is that an MPLS LSP does not necessarily have a
return path; traffic that is sent back from the egress LSR to the 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 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 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, an LSP Ping message is not necessarily as trivial as in IP Ping,
where the responder just swaps the source and destination IP where the responder just swaps the source and destination IP
addresses. Note that this challenge is not applicable to MPLS-TP, addresses. Note that this challenge is not applicable to MPLS-TP,
where a return path is always available. 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 extensible to include
include additional information needed to support new functionality, additional information needed to support new functionality, by use of
by use of Type-Length-Value (TLV) constructs. The usage of TLVs is Type-Length-Value (TLV) constructs. The usage of TLVs is typically
typically not easy to perform in hardware, and is thus typically handled by the control plane, as it is not easy to implement in
handled by the control plane. hardware.
LSP Ping supports both asynchronous, as well as, on-demand LSP Ping supports both asynchronous, as well as, on-demand
activation. activation.
4.4.2. BFD for MPLS 4.4.2. BFD for MPLS
BFD [BFD-LSP] can be used to detect MPLS LSP data plane failures. 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 A BFD session is established for each MPLS LSP that is being
monitored. BFD Control packets must be sent along the same path as monitored. BFD Control packets must be sent along the same path as
skipping to change at page 21, line 30 skipping to change at page 22, line 8
TP OAM are defined in [MPLS-TP-OAM], and include both general TP OAM are defined in [MPLS-TP-OAM], and include both general
requirements for the behavior of the OAM tools and a set of requirements for the behavior of the OAM tools and a set of
operations that should be supported by the OAM toolset. The set of operations that should be supported by the OAM toolset. The set of
mechanisms required are further elaborated in [TP-OAM-FW], which mechanisms required are further elaborated in [TP-OAM-FW], which
describes the general architecture of the OAM system as well as describes the general architecture of the OAM system as well as
giving overviews of the functionality of the OAM toolset. giving overviews of the functionality of the OAM toolset.
Some of the basic requirements for the OAM toolset for MPLS-TP are: Some of the basic requirements for the OAM toolset for MPLS-TP are:
o MPLS-TP OAM must be able to support both an IP based and non-IP o MPLS-TP OAM must be able to support both an IP based and non-IP
based environment. If the network is IP based, i.e. IP routing and based environment. If the network is IP based, i.e., IP routing
forwarding are available, then the MPLS-TP OAM toolset should rely and forwarding are available, then the MPLS-TP OAM toolset should
on the IP routing and forwarding capabilities. On the other hand, rely on the IP routing and forwarding capabilities. On the other
in environments where IP functionality is not available, the OAM hand, in environments where IP functionality is not available, the
tools must still be able to operate without dependence on IP OAM 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 ordinary user packets in the data
requirement is the principle that MPLS-TP OAM be independent of plane. Inherent in this requirement is the principle that MPLS-TP
any existing control-plane, although it should not preclude use of OAM be independent of any existing control-plane, although it
the control-plane functionality. should not preclude use of the control-plane functionality.
OAM packets are identified by the Generic Associated Label (GAL), OAM packets are identified by the Generic Associated Label (GAL),
which is a reserved MPLS label value (13). 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.
The term Maintenance Entity (ME) is used in ITU-T Recommendations The term Maintenance Entity (ME) is used in ITU-T Recommendations
(e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology (e.g., [ITU-T-Y1731]), as well as in the MPLS-TP terminology
([TP-OAM-FW]). ([TP-OAM-FW]).
Maintenance Entity Group (MEG) Maintenance Entity Group (MEG)
The collection of one or more MEs that belongs to the same transport The collection of one or more MEs that belongs to the same transport
path and that are maintained and monitored as a group are known as a path and that are maintained and monitored as a group are known as a
Maintenance Entity Group (based on [TP-OAM-FW]). Maintenance Entity Group (based on [TP-OAM-FW]).
Maintenance Point (MP) Maintenance Point (MP)
skipping to change at page 22, line 42 skipping to change at page 23, line 22
Maintenance Intermediate Point (MIP) Maintenance Intermediate Point (MIP)
In between MEPs, there are zero or more intermediate points, called In between MEPs, there are zero or more intermediate points, called
Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]).
A Maintenance Intermediate Point (MIP) is an intermediate point that A Maintenance Intermediate Point (MIP) is an intermediate point that
does not generally initiate OAM frames (one exception to this is the does not generally initiate OAM frames (one exception to this is the
use of AIS notifications), but is able to respond to OAM frames that use of AIS notifications), but is able to respond to OAM frames that
are destined to it. A MIP in MPLS-TP identifies OAM packets destined are destined to it. A MIP in MPLS-TP identifies OAM packets destined
to it by the value of the TTL field in the OAM packet. The term to it by the expiration of the TTL field in the OAM packet. The term
Maintenance Point is a general term for MEPs and MIPs. Maintenance Point is a general term for MEPs and MIPs.
Up and Down MEPs Up and Down MEPs
The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs
and Down MEPs. A MEP is a bridge interface that is monitored by an and Down MEPs. A MEP monitors traffic either in the direction facing
OAM protocol either in the direction facing the network, or in the the network, or in the direction facing the bridge. A Down MEP is a
direction facing the bridge. A Down MEP is a MEP that receives OAM MEP that receives OAM packets from, and transmits them to the
packets from, and transmits them to the direction of the network. An direction of the network. An Up MEP receives OAM packets from, and
Up MEP receives OAM packets from, and transmits them to the direction transmits them to the direction of the bridging entity. MPLS-TP ([TP-
of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar OAM-FW]) uses a similar distinction on the placement of the MEP -
distinction on the placement of the MEP - either at the ingress, either at the ingress, egress, or forwarding function of the node
egress, or forwarding function of the node (Down / Up MEPs). This (Down / Up MEPs). This placement is important for localization of a
placement is important for localization of a failure. failure.
Note that the terms Up and Down MEPs are entirely unrelated to the
conventional up/down terminology, where down means faulty, and up is
nonfaulty.
The distinction between Up and Down MEPs was defined in [TP-OAM-FW], The distinction between Up and Down MEPs was defined in [TP-OAM-FW],
but has not been used in other MPLS-TP RFCs, as of the writing of but has not been used in other MPLS-TP RFCs, as of the writing of
this document. this document.
4.5.3. Generic Associated Channel 4.5.3. Generic Associated Channel
In order to address the requirement for in-band transmission of MPLS- In order to address the requirement for in-band transmission of MPLS-
TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based
on the same concepts as the PWE3 ACH and VCCV mechanisms. However, on the same concepts as the PWE3 ACH [PW-ACH] and VCCV [VCCV]
to address the needs of LSPs as differentiated from PW, the following mechanisms. However, to address the needs of LSPs as differentiated
concepts were defined for [G-ACh]: from PW, the following concepts were defined for [G-ACh]:
o An Associated Channel Header (ACH), that uses a format similar to o An Associated Channel Header (ACH), that uses a format similar to
the PW Control Word, is a 4-byte header that is prepended to OAM the PW Control Word [PW-ACH], is a 4-byte header that is prepended
packets. to OAM packets.
o A Generic Associated Label (GAL). The GAL is a reserved MPLS label o A Generic Associated Label (GAL). The GAL is a reserved MPLS label
value (13) that indicates that the packet is an ACH packet and the value (13) that indicates that the packet is an ACH packet and the
payload follows immediately after the label stack. payload follows immediately after the label stack.
It should be noted that while the G-ACh was defined as part of the It should be noted that while the G-ACh was defined as part of the
MPLS-TP definition effort, the G-ACh is a generic tool that can be MPLS-TP definition effort, the G-ACh is a generic tool that can be
used in MPLS in general, and not only in MPLS-TP. used in MPLS in general, and not only in MPLS-TP.
4.5.4. MPLS-TP OAM Toolset 4.5.4. MPLS-TP OAM Toolset
skipping to change at page 25, line 10 skipping to change at page 25, line 35
Normally, this path will be used for bidirectional PW, LSP, and Normally, this path will be used for bidirectional PW, LSP, and
sections, however, unidirectional paths may be supported only if a sections, however, unidirectional paths may be supported only if a
return path exists. The tool for this is based on the LSP Ping (see return path exists. The tool for this is based on the LSP Ping (see
Section 4.4.) functionality and is described in [OnDemand-CV]. Section 4.4.) functionality and is described in [OnDemand-CV].
4.5.4.3. Lock Instruct 4.5.4.3. Lock Instruct
The Lock Instruct function [Lock-Loop] is used to notify a transport The Lock Instruct function [Lock-Loop] is used to notify a transport
path end-point of an administrative need to disable the transport path end-point of an administrative need to disable the transport
path. This functionality will generally be used in conjunction with path. This functionality will generally be used in conjunction with
some intrusive OAM function, e.g. Performance measurement, Diagnostic some intrusive OAM function, e.g., Performance measurement,
testing, to minimize the side-effect on user data traffic. Diagnostic testing, to minimize the side-effect on user data traffic.
4.5.4.4. Lock Reporting 4.5.4.4. Lock Reporting
Lock Reporting is a function used by an end-point of a path to report Lock Reporting is a function used by an end-point of a path to report
to its far-end end-point that a lock condition has been affected on to its far-end end-point that a lock condition has been affected on
the path. the path.
4.5.4.5. Alarm Reporting 4.5.4.5. Alarm Reporting
Alarm Reporting [TP-Fault] provides the means to suppress alarms Alarm Reporting [TP-Fault] provides the means to suppress alarms
skipping to change at page 25, line 36 skipping to change at page 26, line 13
defect condition discovered at a server sub-layer. This generates an defect condition discovered at a server sub-layer. This generates an
Alarm Indication Signal (AIS) that continues until the fault is Alarm Indication Signal (AIS) that continues until the fault is
cleared. The consequent action of this function is detailed in cleared. The consequent action of this function is detailed in
[TP-OAM-FW]. [TP-OAM-FW].
4.5.4.6. Remote Defect Indication 4.5.4.6. Remote Defect Indication
Remote Defect Indication (RDI) is used proactively by a path end- Remote Defect Indication (RDI) is used proactively by a path end-
point to report to its peer end-point that a defect is detected on a point to report to its peer end-point that a defect is detected on a
bidirectional connection between them. [MPLS-TP-OAM] points out that bidirectional connection between them. [MPLS-TP-OAM] points out that
this function may be applied to a unidirectional LSP only if there a this function may be applied to a unidirectional LSP only if a return
return path exists. [TP-OAM-FW] points out that this function is path exists. [TP-OAM-FW] points out that this function is associated
associated with the proactive CC-V function. with the proactive CC-V function.
4.5.4.7. Client Failure Indication 4.5.4.7. Client Failure Indication
Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow
the propagation information from one edge of the network to the the propagation information from one edge of the network to the
other. The information concerns a defect to a client, in the case other. The information concerns a defect to a client, in the case
that the client does not support alarm notification. that the client does not support alarm notification.
4.5.4.8. Performance Monitoring 4.5.4.8. Performance Monitoring
skipping to change at page 30, line 7 skipping to change at page 30, line 39
results. The test protocols introduce test packets (which contain results. The test protocols introduce test packets (which contain
sequence numbers and timestamps) along the IP path under test sequence numbers and timestamps) along the IP path under test
according to a schedule, and record statistics of packet arrival. according to a schedule, and record statistics of packet arrival.
Multiple sessions may be simultaneously defined, each with a session Multiple sessions may be simultaneously defined, each with a session
identifier, and defining the number of packets to be sent, the amount identifier, and defining the number of packets to be sent, the amount
of padding to be added (and thus the packet size), the start time, of padding to be added (and thus the packet size), the start time,
and the send schedule (which can be either a constant time between and the send schedule (which can be either a constant time between
test packets or exponentially distributed pseudo-random). Statistics test packets or exponentially distributed pseudo-random). Statistics
recorded conform to the relevant IPPM RFCs. recorded conform to the relevant IPPM RFCs.
OWAMP and TWAMP test traffic is designed with security in mind. Test From a security perspective, OWAMP and TWAMP test packets are hard to
packets are hard to detect because they are simply UDP streams detect because they are simply UDP streams between negotiated port
between negotiated port numbers, with potentially nothing static in numbers, with potentially nothing static in the packets. OWAMP and
the packets. OWAMP and TWAMP also include optional authentication TWAMP also include optional authentication and encryption for both
and encryption for both control and test packets. control and test packets.
4.7.3. OWAMP 4.7.3. OWAMP
OWAMP defines the following logical roles: Session-Sender, Session- OWAMP defines the following logical roles: Session-Sender, Session-
Receiver, Server, Control-Client, and Fetch-Client. The Session- Receiver, Server, Control-Client, and Fetch-Client. The Session-
Sender originates test traffic that is received by the Session- Sender originates test traffic that is received by the Session-
Receiver. The Server configures and manages the session, as well as Receiver. The Server configures and manages the session, as well as
returning the results. The Control-Client initiates requests for returning the results. The Control-Client initiates requests for
test sessions, triggers their start, and may trigger their test sessions, triggers their start, and may trigger their
termination. The Fetch-Client requests the results of a completed termination. The Fetch-Client requests the results of a completed
session. Multiple roles may be combined in a single host - for session. Multiple roles may be combined in a single host - for
example, one host may play the roles of Control-Client, Fetch-Client, example, one host may play the roles of Control-Client, Fetch-Client,
and Session-Sender, and a second playing the roles of Server and and Session-Sender, and a second playing the roles of Server and
Session-Receiver. Session-Receiver.
In a typical OWAMP session the Control-Client establishes a TCP In a typical OWAMP session the Control-Client establishes a TCP
connection to port 861 of the Server, which responds with a server connection to port 861 of the Server, which responds with a server
greeting message indicating supported security/integrity modes. The greeting message indicating supported security/integrity modes. The
Control-Client responds with the chosen communications mode and the Control-Client responds with the chosen communications mode and the
Server accepts the modes. The Control-Client then requests and fully Server accepts the mode. The Control-Client then requests and fully
describes a test session to which the Server responds with its describes a test session to which the Server responds with its
acceptance and supporting information. More than one test session acceptance and supporting information. More than one test session
may be requested with additional messages. The Control-Client then may be requested with additional messages. The Control-Client then
starts a test session and the Server acknowledges. The Session- starts a test session and the Server acknowledges, and instructs the
Sender then sends test packets with pseudorandom padding to the Session-Sender to start the test. The Session-Sender then sends test
Session-Receiver until the session is complete or until the Control- packets with pseudorandom padding to the Session-Receiver until the
client stops the session. Once finished, the Fetch-Client sends a session is complete or until the Control-client stops the session.
fetch request to the server, which responds with an acknowledgement Once finished, the Session-Sender reports to the Server which
and immediately thereafter the result data. recovers data from the Session-Receiver. The Fetch-Client can then
send a fetch request to the Server, which responds with an
acknowledgement and immediately thereafter the result data.
4.7.4. TWAMP 4.7.4. TWAMP
TWAMP defines the following logical roles: session-sender, session- TWAMP defines the following logical roles: session-sender, session-
reflector, server, and control-client. These are similar to the reflector, server, and control-client. These are similar to the
OWAMP roles, except that the Session-Reflector does not collect any OWAMP roles, except that the Session-Reflector does not collect any
packet information, and there is no need for a Fetch-Client. packet information, and there is no need for a Fetch-Client.
In a typical TWAMP session the Control-Client establishes a TCP In a typical TWAMP session the Control-Client establishes a TCP
connection to port 862 of the Server, and mode is negotiated as in connection to port 862 of the Server, and mode is negotiated as in
skipping to change at page 31, line 40 skipping to change at page 32, line 28
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.
5. Summary 5. Summary
This section summarizes the OAM tools and functions presented in this This section summarizes the OAM tools and functions presented in this
document. This summary is an index to some of the main OAM tools 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 defined in the IETF. This compact index that can be useful to all
readers from network operators to standard development organizations. readers from network operators to standards development
The summary includes a short subsection that presents some guidance organizations. The summary includes a short subsection that presents
to network equipment vendors. some guidance to network equipment vendors.
5.1. Summary of OAM Tools 5.1. Summary of OAM Tools
This subsection provides a short summary of each of the OAM toolsets This subsection provides a short summary of each of the OAM toolsets
described in this document. described in this document.
A detailed list of the RFCs related to each toolset is given in A detailed list of the RFCs related to each toolset is given in
Appendix A.1. Appendix A.1.
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
skipping to change at page 32, line 25 skipping to change at page 33, line 14
|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 | |
| | destination, i.e., to identify the nodes | | | | destination, i.e., to identify the nodes | |
| | along the path. If more than one path | | | | along the path. If more than one path | |
| | exists between the source and destination| | | | exists between the source and destination| |
| | Traceroute traces *a* path. The most | | | | Traceroute traces *a* path. The most | |
| | common implementation of Traceroute | | | | common implementation of Traceroute | |
| | uses UDP probe messages, although there | | | | uses UDP probe messages, although there | |
| | are other implementations that use | | | | are other implementations that use | |
| | different probes, such as ICMP or TCP. | | | | different probes, such as ICMP or TCP. | |
| | Paris Traceroute [PARIS] is an extension | |
| | that attempts to discovers all the | |
| | available paths from A to B by scanning | |
| | different values of header fields. | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
|BFD | Bidirectional Forwarding Detection (BFD) | generic | |BFD | Bidirectional Forwarding Detection (BFD) | generic |
| | is defined in [BFD] as a framework for a | | | | is defined in [BFD] as a framework for a | |
| | lightweight generic OAM tool. The | | | | lightweight generic OAM tool. The | |
| | intention is to define a base tool | | | | intention is to define a base tool | |
| | that can be used with various | | | | that can be used with various | |
| | encapsulation types, network | | | | encapsulation types, network | |
| | environments, and in various medium | | | | environments, and in various medium | |
| | types. | | | | types. | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
skipping to change at page 33, line 22 skipping to change at page 34, line 16
| | wire (PW). The control channels that are| | | | wire (PW). The control channels that are| |
| | defined in [VCCV] and [PW-G-ACh] may be | | | | defined in [VCCV] and [PW-G-ACh] may be | |
| | used in conjunction with ICMP Ping, LSP | | | | used in conjunction with ICMP Ping, LSP | |
| | Ping, and BFD to perform CC and CV | | | | Ping, and BFD to perform CC and CV | |
| | functionality. In addition the channels | | | | functionality. In addition the channels | |
| | support use of any of the MPLS-TP based | | | | support use of any of the MPLS-TP based | |
| | OAM tools for completing their respective| | | | OAM tools for completing their respective| |
| | OAM functionality for a PW. | | | | OAM functionality for a PW. | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
|OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 |
|TWAMP | (OWAMP) and the Two Way Active Measure- | | |TWAMP | [OWAMP] and the Two Way Active Measure- | |
| | ment Protocols (TWAMP) are two protocols | | | | ment Protocols [TWAMP] are two protocols | |
| | defined in the IP Performance Metrics | | | | defined in the IP Performance Metrics | |
| | (IPPM) working group in the IETF. These | | | | (IPPM) working group in the IETF. These | |
| | protocols allow various performance | | | | protocols allow various performance | |
| | metrics to be measured, such as packet | | | | metrics to be measured, such as packet | |
| | loss, delay and delay variation, | | | | loss, delay and delay variation, | |
| | duplication and reordering. | | | | duplication and reordering. | |
+-----------+------------------------------------------+------------+ +-----------+------------------------------------------+------------+
|TRILL OAM | The requirements of OAM in TRILL are | TRILL | |TRILL OAM | The requirements of OAM in TRILL are | TRILL |
| | defined in [TRILL-OAM]. These | | | | defined in [TRILL-OAM]. These | |
| | requirements include continuity checking,| | | | requirements include continuity checking,| |
skipping to change at page 35, line 32 skipping to change at page 36, line 23
As mentioned in Section 1.4. , it is imperative for OAM tools to be 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 capable of testing the actual data plane in as much accuracy as
possible. While this guideline may appear obvious, it is worthwhile possible. While this guideline may appear obvious, it is worthwhile
to emphasize the key importance of enforcing fate-sharing between OAM to emphasize the key importance of enforcing fate-sharing between OAM
traffic that monitors the data plane and the data plane traffic it traffic that monitors the data plane and the data plane traffic it
monitors. monitors.
6. Security Considerations 6. Security Considerations
This memo presents an overview of existing OAM tools, and proposes OAM is tightly coupled with the stability of the network. A
no new OAM tools. Therefore, this document introduces no security successful attack on an OAM protocol can create a false illusion of
considerations. However, the OAM tools reviewed in this document can non-existent failures, or prevent the detection of actual ones. In
and do present security issues. The reader is encouraged to review both cases the attack may result in denial of service.
the Security Considerations section of each document referenced by
this memo. Some of the OAM tools presented in this document include security
mechanisms that provide integrity protection, thereby preventing
attackers from forging or tampering with OAM packets. For example,
[BFD] includes an optional authentication mechanism for BFD Control
packets, using either SHA1, MD5, or a simple password. [OWAMP] and
[TWAMP] have 3 modes of security: unauthenticated, authenticated,
and encrypted. The authentication uses SHA1 as the HMAC algorithm,
and the encrypted mode uses AES encryption.
Confidentiality is typically not considered a requirement for OAM
protocols. However, the use of encryption (e.g., [OWAMP] and
[TWAMP]) can make it difficult for attackers to identify OAM
packets, thus making it more difficult to attack the OAM protocol.
For further details about the security considerations of each OAM
protocol, the reader is encouraged to review the Security
Considerations section of each document referenced by this memo.
7. 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.
8. Acknowledgments 8. Acknowledgments
The authors gratefully acknowledge Sasha Vainshtein, Carlos The authors gratefully acknowledge Sasha Vainshtein, Carlos
Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit
Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam
skipping to change at page 39, line 38 skipping to change at page 40, line 47
(OAM)", RFC 4378, February 2006. (OAM)", RFC 4378, February 2006.
[MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T.,
"Operations and Management (OAM) Requirements for "Operations and Management (OAM) Requirements for
Point-to-Multipoint MPLS Networks", RFC 4687, Point-to-Multipoint MPLS Networks", RFC 4687,
September 2006. September 2006.
[MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for
OAM in MPLS Transport Networks", RFC 5860, May 2010. OAM in MPLS Transport Networks", RFC 5860, May 2010.
[mtrace] Fenner, W., Casner, S., "A "traceroute" facility for IP
Multicast", draft-ietf-idmr-traceroute-ipm-07
(expired), July 2000.
[NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking
Terms", RFC 1208, March 1991. Terms", RFC 1208, March 1991.
[NetTools] Enger, R., Reynolds, J., "FYI on a Network Management [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management
Tool Catalog: Tools for Monitoring and Debugging Tool Catalog: Tools for Monitoring and Debugging
TCP/IP Internets and Interconnected Devices", RFC TCP/IP Internets and Interconnected Devices", RFC
1470, June 1993. 1470, June 1993.
[OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool
Set for MPLS based Transport Networks", RFC 6669, Set for MPLS based Transport Networks", RFC 6669,
 End of changes. 61 change blocks. 
134 lines changed or deleted 179 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/