draft-ietf-mpls-tp-oam-analysis-09.txt   rfc6669.txt 
Network Working Group N. Sprecher Internet Engineering Task Force (IETF) N. Sprecher
Internet-Draft Nokia Siemens Networks Request for Comments: 6669 Nokia Siemens Networks
Intended status: Informational L. Fang Category: Informational L. Fang
Expires: October 18, 2012 Cisco ISSN: 2070-1721 Cisco Systems
April 17, 2012 July 2012
An Overview of the OAM Tool Set for MPLS based Transport Networks An Overview of the Operations, Administration, and Maintenance (OAM)
draft-ietf-mpls-tp-oam-analysis-09.txt Toolset for MPLS-Based Transport Networks
Abstract Abstract
This document provides an overview of the OAM toolset for MPLS based This document provides an overview of the Operations, Administration,
Transport Networks (MPLS-TP). The toolset consists of a comprehensive and Maintenance (OAM) toolset for MPLS-based transport networks. The
set of fault management and performance monitoring capabilities toolset consists of a comprehensive set of fault management and
(operating in the data-plane) which are appropriate for transport performance monitoring capabilities (operating in the data plane)
networks as required in RFC 5860 and support the network and services that are appropriate for transport networks as required in RFC 5860
at different nested levels. This overview includes a brief recap of and support the network and services at different nested levels.
MPLS-TP OAM requirements and functions, and of generic mechanisms This overview includes a brief recap of the MPLS Transport Profile
created in the MPLS data plane to allow the OAM packets run in-band (MPLS-TP) OAM requirements and functions and the generic mechanisms
and share their fate with data packets. The protocol definitions for created in the MPLS data plane that allow the OAM packets to run
each of the MPLS-TP OAM tools are defined in separate documents (RFCs in-band and share their fate with data packets. The protocol
or Working Group drafts) which are referenced by this document. definitions for each of the MPLS-TP OAM tools are defined in separate
documents (RFCs or Working Group documents), which are referenced by
Status of this Memo this document.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 18, 2012. Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6669.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope ......................................................4
1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 1.2. Acronyms ...................................................5
1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Basic OAM Infrastructure Functionality ..........................6
2. Basic OAM Infrastructure Functionality . . . . . . . . . . . . 6 3. MPLS-TP OAM Functions ...........................................8
3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 8 3.1. Continuity Check and Connectivity Verification .............8
3.1. Continuity Check and Connectivity Verification . . . . . . 8 3.1.1. Documents for CC-CV Tools ...........................8
3.1.1. Documents for CC-CV tools . . . . . . . . . . . . . . 9 3.2. Remote Defect Indication ...................................8
3.2. Remote Defect Indication . . . . . . . . . . . . . . . . . 9 3.2.1. Documents for RDI ...................................9
3.2.1. Documents for RDI . . . . . . . . . . . . . . . . . . 9 3.3. Route Tracing ..............................................9
3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Documents for Route Tracing .........................9
3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 10 3.4. Alarm Reporting ............................................9
3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Documents for Alarm Reporting .......................9
3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 10 3.5. Lock Instruct ..............................................9
3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 10 3.5.1. Documents for Lock Instruct ........................10
3.5.1. Documents for Lock Instruct . . . . . . . . . . . . . 10 3.6. Lock Reporting ............................................10
3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1. Documents for Lock Reporting .......................10
3.6.1. Documents for Lock Reporting . . . . . . . . . . . . . 10 3.7. Diagnostic ................................................10
3.7. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7.1. Documents for Diagnostic Testing ...................10
3.7.1. Documents for Diagnostic Testing . . . . . . . . . . . 11 3.8. Packet Loss Measurement ...................................10
3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11 3.8.1. Documents for Packet Loss Measurement ..............11
3.8.1. Documents for Packet Loss Measurement . . . . . . . . 11 3.9. Packet Delay Measurement ..................................11
3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 12 3.9.1. Documents for Delay Measurement ....................11
3.9.1. Documents for Delay Measurement . . . . . . . . . . . 12 4. MPLS-TP OAM Documents Guide ....................................12
4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 12 5. OAM Toolset Applicability and Utilization ......................13
5. OAM Toolset Applicability and Utilization . . . . . . . . . . 14 5.1. Connectivity Check and Connectivity Verification ..........14
5.1. Connectivity Check and Connectivity Verification . . . . . 14 5.2. Diagnostic Tests and Lock Instruct ........................14
5.2. Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15 5.3. Lock Reporting ............................................15
5.3. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Alarm Reporting and Link Down Indication ..................15
5.4. Alarm Reporting and Link Down Indication . . . . . . . . . 16 5.5. Remote Defect Indication ..................................16
5.5. Remote Defect Indication . . . . . . . . . . . . . . . . . 17 5.6. Packet Loss and Delay Measurement .........................17
5.6. Packet Loss and Delay Measurement . . . . . . . . . . . . 17 6. Security Considerations ........................................18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements ...............................................18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. References .....................................................19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References ......................................19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References ....................................20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Contributors ......................................................21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1. Scope 1.1. Scope
The MPLS Transport Profile (MPLS-TP) architectural framework is The MPLS Transport Profile (MPLS-TP) architectural framework is
defined in [RFC 5921], and it describes common set of protocol defined in [RFC5921], and it describes a common set of protocol
functions that supports the operational models and capabilities functions that supports the operational models and capabilities
typical of such networks. typical of such transport networks.
OAM (Operations, Administration, and Maintenance) plays a significant Operations, Administration, and Maintenance (OAM) plays a significant
role in carrier networks, providing methods for fault management and role in carrier networks. It provides methods for fault management
performance monitoring in both the transport and the service layers and performance monitoring in both the transport and service layers,
in order to improve their ability to support services with guaranteed in order to improve their ability to support services with guaranteed
and strict Service Level Agreements (SLAs) while reducing their and strict Service Level Agreements (SLAs) while reducing their
operational costs. operational costs.
[RFC 5654], in general, and [RFC 5860], in particular, define a set [RFC5654], in general, and [RFC5860], in particular, define a set of
of requirements for OAM functionality for MPLS-Transport Profile requirements for the OAM functionality for MPLS-TP Label Switched
(MPLS-TP)Label Switched Paths (LSPs) ), Pseudowires (PWs) and Paths (LSPs), Pseudowires (PWs), and Sections.
sections.
The OAM solution, developed by the joint IETF and ITU-T MPLS-TP The OAM solution, developed by the joint IETF and ITU-T MPLS-TP
project, has three objectives: project, has three objectives:
o The OAM toolset should be developed based on existing MPLS o The OAM toolset should be developed based on existing MPLS
architecture, technology, and toolsets. architecture, technology, and toolsets.
o The OAM operational experience should be similar to that in other o The OAM operational experience should be similar to that in other
transport networks. transport networks.
o The OAM toolset developed for MPLS based transport networks needs o The OAM toolset developed for MPLS-based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as to be fully interoperable with existing MPLS OAM tools as
documented in [RFC 5860]. documented in Section 2.1.5. of [RFC5860].
The MPLS-TP OAM toolset is based on the following existing tools: The MPLS-TP OAM toolset is based on the following existing tools:
o LSP-Ping as defined in [RFC 4379]. o LSP ping, as defined in [RFC4379].
o Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880] o Bidirectional Forwarding Detection (BFD), as defined in [RFC5880]
and refined in [RFC 5884]. and refined in [RFC5884].
o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This
been used for functionality guidelines for the performance has been used as functionality guidelines for the performance
measurement tools that were not previously supported in MPLS. measurement tools that were not previously supported in MPLS.
It should be noted that certain extensions and adjustments have been Note that certain extensions and adjustments have been specified,
specified relative to the existing MPLS tools, in order to conform to relative to the existing MPLS tools, in order to conform to the
the transport environment and the requirements of MPLS-TP. However, transport environment and the requirements of MPLS-TP. However,
compatibility with the existing tools has been maintained. compatibility with the existing MPLS tools has been maintained.
This document provides an overview of the MPLS-TP OAM toolset, which This document provides an overview of the MPLS-TP OAM toolset, which
consists of tools for MPLS-TP fault management and performance consists of tools for MPLS-TP fault management and performance
monitoring. This overview includes a brief recap of MPLS-TP OAM monitoring. This overview includes a brief recap of MPLS-TP OAM
requirements and functions, and of the generic mechanisms used to requirements, their functions, and the generic mechanisms used to
support the MPLS-TP OAM operation. support the MPLS-TP OAM operation.
The protocol definitions for each individual MPLS-TP OAM tool are The protocol definitions for individual MPLS-TP OAM tools are
specified in separate RFCs (or Working Group documents while this specified in separate RFCs (or Working Group documents), which are
document is work in progress), which are referenced by this document. referenced by this document.
In addition, the document includes a table that cross-references the In addition, this document includes a table that cross-references the
solution documents to the OAM functionality supported. Finally, the solution documents of the OAM functionality supported. Finally, the
document presents the applicability and utilization of each tool in document presents the applicability and utilization of each tool in
the MPLS-TP OAM toolset. the MPLS-TP OAM toolset.
1.2. Contributing Authors 1.2. Acronyms
Elisa Bellagamba Ericsson
Yaacov Weingarten Nokia Siemens Networks
Dan Frost Cisco
Nabil Bitar Verizon
Raymond Zhang Alcatel Lucent
Lei Wang Telenor
Kam Lee Yap XO Communications
John Drake Juniper
Yaakov Stein RAD
Anamaria Fulignoli Ericsson
Italo Busi Alcatel Lucent
Huub van Helvoort Huawei
Thomas Nadeau Computer Associate
Henry Yu TW Telecom
Mach Chen Huawei
Manuel Paul Deutsche Telekom
1.3. Acronyms
This document uses the following acronyms: This document uses the following acronyms:
ACH Associated Channel Header ACH Associated Channel Header
AIS Alarm Indication Signal AIS Alarm Indication Signal
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
CC-CV Continuity Check and Connectivity Verification CC-CV Continuity Check and Connectivity Verification
DM Delay Measurement DM Delay Measurement
FM Fault Management FM Fault Management
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label GAL G-ACh Label
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multiprotocol Label Switching
IANA Internet Assigned Names Authority IANA Internet Assigned Numbers Authority
LDI Link Down Indication LDI Link Down Indication
LKR Lock Report LKR Lock Report
LM Loss Measurement LM Loss Measurement
LOC Loss of Continuity LOC Loss of Continuity
LSP Label Switched Path LSP Label Switched Path
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MEG Maintenance Entity Group MEG Maintenance Entity Group
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
MPLS MultiProtocol Label Switching MPLS Multiprotocol Label Switching
MPLS-TP Transport Profile for MPLS MPLS-TP Transport Profile for MPLS
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
PM Performance Monitoring PM Performance Monitoring
PW Pseudowire PW Pseudowire
RDI Remote Defect Indication RDI Remote Defect Indication
SLA Service Level Agreement SLA Service Level Agreement
TLV Type, Length, Value TLV Type, Length, Value
VCCV Virtual Circuit Connectivity Verification VCCV Virtual Circuit Connectivity Verification
2. Basic OAM Infrastructure Functionality 2. Basic OAM Infrastructure Functionality
[RFC 5860] defines a set of requirements on OAM architecture and [RFC5860] defines a set of requirements for OAM architecture and
general principles of operations, which are evaluated below: general principles of operations, which are evaluated below:
[RFC 5860] requires that -- [RFC5860] requires that --
o OAM mechanisms in MPLS-TP are independent of the transmission o OAM mechanisms in MPLS-TP are independent of the transmission
media and of the client service being emulated by the PW ([RFC media and the client service being emulated by the PW ([RFC5860],
5860], section 2.1.2). Section 2.1.2).
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 based environment. If the network is IP based, i.e., IP routing
and forwarding are available, then it must be possible to choose and forwarding are available, then it must be possible to choose
to make use of IP capabilities. On the other hand, in to make use of IP capabilities. On the other hand, in
environments where IP functionality is not available, the OAM environments where IP functionality is not available, the OAM
tools must still be able to operate independent of IP forwarding tools must still be able to operate independent of IP forwarding
and routing ([RFC 5860], section 2.1.4). It is required to have and routing ([RFC5860], Section 2.1.4). It is required to have
OAM interoperability between distinct domains materializing the OAM interoperability between distinct domains materializing the
environments ([RFC 5860], section 2.1.5). environments ([RFC5860], Section 2.1.5).
o all OAM protocols support identification information, at least in o All OAM protocols support identification information, at least in
the form of IP addressing structure and be extensible to support the form of IP addressing structure, and are extensible to support
additional identification schemes ([RFC 5860], section 2.1.4). additional identification schemes ([RFC5860], Section 2.1.4).
o OAM packets and the user traffic are congruent (i.e. OAM packets o OAM packets and the user traffic are congruent (i.e., OAM packets
are transmitted in-band) and there is a need to differentiate OAM are transmitted in-band) and there is a need to differentiate OAM
packets from user-plane packets ([RFC 5860], section 2.1.3). packets from user-plane packets [RFC5860], Section 2.1.3.
Inherent in this requirement is the principle that full operation Inherent in this requirement is the principle that full operation
of the MPLS-TP OAM must be possible independently of the control of the MPLS-TP OAM must be possible independently of the control
or management plane used to operate the network ([RFC 5860], or management plane used to operate the network [RFC5860], Section
section 2.1.3). 2.1.3.
o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to- o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
point co-routed bidirectional LSPs, point-to-point bidirectional point co-routed bidirectional LSPs, and point-to-point
Sections ([RFC 5860], section 2.1.1). The applicability of bidirectional Sections ([RFC5860], Section 2.1.1). The
particular MPLS-TP OAM functions to point-to-point associated applicability of particular MPLS-TP OAM functions to point-to-
bidirectional LSPs, point-to-point unidirectional LSPs, and point- point associated bidirectional LSPs, point-to-point unidirectional
to-multipoint LSPs, is described in ([RFC 5860], section 2.2)). LSPs, and point-to-multipoint LSPs, is described in [RFC5860],
In addition, MPLS-TP OAM supports these LSPs and PWs when they Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs
span either a single or multiple domains ([RFC 5860], section when they span either single or multiple domains ([RFC5860],
2.1.1). Section 2.1.1).
o OAM packets may be directed to an intermediate point of a LSP/PW o OAM packets may be directed to an intermediate point of an LSP/PW
([RFC 5860], sections 2.2.3, 2.2.4 and 2.2.5). ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5).
[RFC 5860] recommends that any protocol solution, meeting one or more [RFC5860], Section 2.2 recommends that any protocol solution meeting
functional requirement(s), be the same for PWs, LSPs, and Sections one or more functional requirement(s) be the same for PWs, LSPs, and
(section 2.2). Sections.
The following document-set addresses the basic requirements listed The following document set addresses the basic requirements listed
above: above:
o The [RFC 6371] document describes the architectural framework for o [RFC6371] describes the architectural framework for conformance to
conformance to the basic requirements listed above. It also the basic requirements listed above. It also defines the basic
defines the basic relationships between the MPLS structures, e.g. relationships between the MPLS structures, e.g., LSP, PW, and the
LSP, PW, and the structures necessary for OAM functionality, i.e. structures necessary for OAM functionality, i.e., the Maintenance
the Managed Entity Group, its End-points, and Intermediate Points. Entity Group (MEG), its end points, and intermediate points.
o The [RFC 5586] document specifies the use of the MPLS-TP in-band o [RFC5586] specifies the use of the MPLS-TP in-band control
control channels. It generalizes the applicability of the channels. It generalizes the applicability of the PW ACH to MPLS
Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and LSPs and Sections by defining a Generic Associated Channel
Sections, by defining a Generic Associated Channel (G-ACh). The (G-ACh). The G-ACh allows control packets to be multiplexed
G-ACh allows control packets to be multiplexed transparently over transparently over LSPs and Sections similar to that of PW VCCV
LSPs and sections, similar to that of PW VCCV [RFC 5085]. The [RFC5085]. The Generic Association Label (GAL) is defined by
Generic Association Label (GAL) is defined by assigning a reserved assigning a reserved MPLS label value and is used to identify the
MPLS label value and is used to identify the OAM control packets. OAM control packets. The value of the ACH Channel Type field
The value of the ACH Channel Type field indicates the specific indicates the specific protocol carried on the associated control
protocol carried on the associated control channel. Each MPLS-TP channel. Each MPLS-TP OAM protocol has an IANA-assigned channel
OAM protocol has an IANA assigned channel type allocated to it. type allocated to it.
[RFC 5085] defines an Associated Channel Header (ACH) which [RFC5085] defines an Associated Channel Header (ACH) that provides a
provides a PW associated control channel between a PW's endpoints, PW associated control channel between a PW's end points, over which
over which OAM and other control messages can be exchanged. [RFC OAM and other control messages can be exchanged. [RFC5586]
5586] generalizes MPLS-TP generalized the PW Associated Channel generalizes the PW Associated Channel Header (ACH) to provide common
Header (ACH) to provide common in-band control channels also at in-band control channels also at the LSP and MPLS-TP link levels.
the LSP and MPLS-TP link levels. The G-ACh allows control packets The G-ACh allows control packets to be multiplexed transparently over
to be multiplexed transparently over the same LSP or MPLS-TP link the same LSP or MPLS-TP link as in PW VCCV. Multiple control
as in PW VCCV. Multiple control channels can exist between end channels can exist between end points.
points.
[RFC 5085] also defines a label-based exception mechanism that [RFC5085] also defines a label-based exception mechanism that helps a
helps an LSR to identify the control packets and direct them to Label Switching Router (LSR) to identify the control packets and
the appropriate entity for processing. The use of G-ACh and GAL direct them to the appropriate entity for processing. The use of
provides the necessary mechanisms to allow OAM packets run in-band G-ACh and GAL provides the necessary mechanisms to allow OAM packets
and share their fate with data packets. It is expected that all to run in-band and share their fate with data packets. It is
of the OAM protocols will be used in conjunction with this Generic expected that all of the OAM protocols will be used in conjunction
Associated Channel. with this Generic Associated Channel.
o The [RFC 6370] document provides an IP-based identifier set for o [RFC6370] provides an IP-based identifier set for MPLS-TP that can
MPLS-TP that can be used to identify the transport entities in the be used to identify the transport entities in the network and
network and referenced by the different OAM protocols. referenced by the different OAM protocols.
[MPLS TP ITU Idents] augments that set of identifiers to include
identifier information in a format used by the ITU-T. Other Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to
identifier sets may be defined as well. include identifier information in a format used by the ITU-T.
Other identifier sets may be defined as well.
3. MPLS-TP OAM Functions 3. MPLS-TP OAM Functions
The following sections discuss the OAM functions that are required in The following sections discuss the OAM functions that are required in
[RFC 5860] and expanded upon in [RFC 6371]. [RFC5860] and expanded upon in [RFC6371].
3.1. Continuity Check and Connectivity Verification 3.1. Continuity Check and Connectivity Verification
Continuity Check and Connectivity Verification (CC-CV) are OAM Continuity Check and Connectivity Verification (CC-CV) are OAM
operations generally used in tandem, and complement each other. operations generally used in tandem and complement each other. These
These functions are generally run proactively, but may also be used functions are generally run proactively, but may also be used
on-demand for diagnoses of a specific condition. Proactively [RFC on-demand for diagnoses of a specific condition. [RFC5860] states
5860] states that the function should allow the MEPs to monitor the that the function should allow the MEPs to proactively monitor the
liveliness and connectivity of a transport path (LSP, PW or a liveliness and connectivity of a transport path (LSP, PW, or a
section) between them. In on-demand mode, this function should Section) between them. In on-demand mode, this function should
support monitoring between the MEPs and, in addition, between a MEP support monitoring between the MEPs and between a MEP and MIP. Note
and MIP. Note that as specified in sections 3.3 and 3.4 of [RFC that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP
6371], a MEP and a MIP can reside in an unspecified location within a can reside in an unspecified location within a node, or in a
node, or in a particular interface on a specific side of the particular interface on a specific side of the forwarding engine.
forwarding engine.
The [RFC 6371] highlights the need for the CC-CV messages to include [RFC6371] highlights the need for the CC-CV messages to include
unique identification of the MEG that is being monitored and the MEP unique identification of the MEG that is being monitored and the MEP
that originated the message. The function, both proactively and in that originated the message. The function, both proactively and in
on-demand mode, needs to be transmitted at regular transmission rates on-demand mode, needs to be transmitted at regular transmission rates
pre-configured by the operator. pre-configured by the operator.
3.1.1. Documents for CC-CV tools 3.1.1. Documents for CC-CV Tools
[RFC 6428] defines BFD extensions to support proactive CC-CV [RFC6428] defines BFD extensions to support proactive CC-CV
applications. applications.
[RFC 6426] provides LSP-Ping extensions that are used to implement [RFC6426] provides LSP ping extensions that are used to implement
on-demand Connectivity Verification. on-demand connectivity verification.
Both of these tools will be used within the framework of the basic Both of these tools will be used within the basic functionality
tools described above, in section 2. framework described in Section 2.
3.2. Remote Defect Indication 3.2. Remote Defect Indication
Remote Defect Indication (RDI) is used by a path end-point to report Remote Defect Indication (RDI) is used by a path end point to report
that a defect is detected on a bi-directional connection to its peer that a defect is detected on a bidirectional connection to its peer
end-point. [RFC 5860] points out that this function may be applied end point. [RFC5860] points out that this function may be applied to
to a unidirectional LSP only if a return path exists. [RFC 6371] a unidirectional LSP only if a return path exists. [RFC6371] points
points out that this function is associated with the proactive CC-CV out that this function is associated with the proactive CC-CV
function. function.
3.2.1. Documents for RDI 3.2.1. Documents for RDI
The [RFC 6428] document includes an extension for BFD that would [RFC6428] provides an extension for BFD that includes the RDI
include the RDI indication in the BFD format, and a specification of indication in the BFD format and a specification of how this
how this indication is to be used. indication is to be used.
3.3. Route Tracing 3.3. Route Tracing
[RFC 5860] defines that there is a need for functionality that would [RFC5860] defines the need for functionality that would allow a path
allow a path end-point to identify the intermediate (if any) and end- end point to identify the intermediate points (if any) and end
points of the path (LSP, PW or a section). This function would be point(s) along the path (LSP, PW, or a Section). This function would
used in on-demand mode. Normally, this path will be used for be used in on-demand mode. Normally, this path will be used for
bidirectional PW, LSP, and sections, however, unidirectional paths bidirectional PW, LSP, and Sections; however, unidirectional paths
may be supported only if a return path exists. may be supported only if a return path exists.
3.3.1. Documents for Route Tracing 3.3.1. Documents for Route Tracing
The [RFC 6426] document that specifies the LSP-Ping enhancements for [RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-
MPLS-TP on-demand Connectivity Verification includes information on demand connectivity verification include information on the use of
the use of LSP-Ping for route tracing of a MPLS-TP transport path. LSP ping for route tracing of an MPLS-TP path.
3.4. Alarm Reporting 3.4. Alarm Reporting
Alarm Reporting is a function used by an intermediate point of a path Alarm Reporting is a function used by an intermediate point of a path
(LSP or PW), that becomes aware of a fault on the path, to report to (LSP or PW) to report to the end points of the path that a fault
the end-points of the path. [RFC 6371] states that this may occur as exists on the path. [RFC6371] states that this may occur as a result
a result of a defect condition discovered at a server layer. The of a defect condition discovered at a server layer. The intermediate
intermediate point generates an Alarm Indication Signal (AIS) that point generates an Alarm Indication Signal (AIS) that continues until
continues until the fault is cleared. The consequent action of this the fault is cleared. The consequent action of this function is
function is detailed in [RFC 6371]. detailed in [RFC6371].
3.4.1. Documents for Alarm Reporting 3.4.1. Documents for Alarm Reporting
MPLS-TP defines a new protocol to address this functionality that is MPLS-TP defines a new protocol to address this functionality that is
documented in [RFC 6427]. This protocol uses all of the basic documented in [RFC6427]. This protocol uses all of the basic
mechanisms detailed in Section 2. mechanisms detailed in Section 2.
3.5. Lock Instruct 3.5. Lock Instruct
The Lock Instruct function is an administrative control tool that The Lock Instruct function is an administrative control tool that
allows a path end-point to instruct its peer end-point to lock the allows a path end point to instruct its peer end point to lock the
path (LSP, PW or section). The tool is necessary to support single- path (LSP, PW, or Section). The tool is necessary to support single-
side provisioning for administrative locking, according to [RFC side provisioning for administrative locking, according to [RFC6371].
6371]. This function is used on-demand. This function is used on-demand.
3.5.1. Documents for Lock Instruct 3.5.1. Documents for Lock Instruct
The [RFC 6435] document describes the details of a new ACH based [RFC6435] describes the details of a new ACH-based protocol format
protocol format for this functionality. for this functionality.
3.6. Lock Reporting 3.6. Lock Reporting
Lock reporting, defined in [RFC 5860], is similar to the Alarm Lock Reporting, defined in [RFC5860], is similar to the Alarm
Reporting function described above. It is used by an intermediate Reporting function described above. It is used by an intermediate
point to notify the end points of a transport path (LSP or PW) that point to notify the end points of a transport path (LSP or PW) that
an administrative lock condition exists for this transport path. an administrative lock condition exists for the transport path.
3.6.1. Documents for Lock Reporting 3.6.1. Documents for Lock Reporting
MPLS-TP defines a new protocol to address this functionality that is MPLS-TP defines a new protocol to address this functionality that is
documented in [RFC 6427]. This protocol uses all of the basic documented in [RFC6427]. This protocol uses all the basic mechanisms
mechanisms detailed in Section 2. detailed in Section 2.
3.7. Diagnostic 3.7. Diagnostic
The [RFC 5860] indicates that there is need to provide a OAM function [RFC5860] indicates a need to provide an OAM function that would
that would enable conducting different diagnostic tests on a PW, LSP, enable conducting different diagnostic tests on a PW, LSP, or
or Section. The [RFC 6371] provides two types of specific tests to Section. [RFC6371] provides two types of specific tests to be used
be used through this functionality: through this functionality:
o Throughput Estimation - allowing the provider to verify the o Throughput estimation - allowing the provider to verify the
bandwidth/throughput of a transport path. This is an out-of- bandwidth/throughput of a transport path. This is an out-of-
service tool, that uses special packets of varying sizes to test service tool that uses special packets of varying sizes to test
the actual bandwidth and/or throughput of the path. the actual bandwidth and/or throughput of the path.
o Data-plane loopback - this out-of-service tool causes all traffic o Data-plane loopback - this out-of-service tool causes all traffic
that reaches the target node, either a MEP or MIP, to be looped that reaches the target node, either a MEP or MIP, to be looped
back to the originating MEP. For targeting MIPs, a co-routed bi- back to the originating MEP. For targeting MIPs, a co-routed
directional path is required. bidirectional path is required.
3.7.1. Documents for Diagnostic Testing 3.7.1. Documents for Diagnostic Testing
The [RFC 6435] document describes the details of a new ACH based [RFC6435] describes the details of a new ACH-based protocol format
protocol format for the Data-plane loopback functionality. for the data-plane loopback functionality.
The tool for Throughput Estimation tool is under study. The tool for throughput estimation is under study.
3.8. Packet Loss Measurement 3.8. Packet Loss Measurement
Packet Loss Measurement is required by [RFC 5860] to provide a Packet Loss Measurement is required by [RFC5860] to provide a
quantification of the packet loss ratio on a transport path. This is quantification of the packet loss ratio on a transport path. This is
the ratio of the number of user packets lost to the total number of the ratio of the number of user packets lost to the total number of
user packets during a defined time interval. To employ this user packets during a defined time interval. To employ this
function, [RFC 6371] defines that the two end-points of the transport function, [RFC6371] defines that the two end points of the transport
path should exchange counters of messages transmitted and received path should exchange counters of messages transmitted and received
within a time period bounded by loss-measurement messages. The within a time period bounded by loss-measurement messages. The
framework warns that there may be small errors in the computation framework warns that there may be small errors in the computation,
that result from various issues. which result from various issues.
3.8.1. Documents for Packet Loss Measurement 3.8.1. Documents for Packet Loss Measurement
The [RFC 6374] document describes the protocol formats and procedures [RFC6374] describes the protocol formats and procedures for using the
for using the tool and enable efficient and accurate measurement of tool and enabling efficient and accurate measurement of packet loss,
packet loss, delay, and throughput in MPLS networks. [RFC 6375] delay, and throughput in MPLS networks. [RFC6375] describes a
describes a profile of the general MPLS loss, delay, and throughput profile of the general MPLS loss, delay, and throughput measurement
measurement techniques that suffices to meet the specific techniques that suffice to meet the specific requirements of MPLS-TP.
requirements of MPLS-TP. Note that the tool logic is based on the Note that the tool logic is based on the behavior of the parallel
behavior of the parallel function described in [Y.1731]. function described in [Y.1731].
3.9. Packet Delay Measurement 3.9. Packet Delay Measurement
Packet Delay Measurement is a function that is used to measure one- Packet Delay Measurement is a function that is used to measure the
way or two-way delay of a packet transmission between a pair of the one-way or two-way delay of packet transmission between a pair of the
end-points of a path (PW, LSP, or Section), as described in [RFC end points of a path (PW, LSP, or Section), as described in
5860]. Where: [RFC5860], where:
o One-way packet delay is the time elapsed from the start of o One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until transmission of the first bit of the packet by a source node until
the reception of the last bit of that packet by the destination the reception of the last bit of that packet by the destination
node. node.
o Two-way packet delay is the time elapsed from the start of o Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's same source node, when the loopback is performed at the packet's
destination node. destination node.
[RFC 6371] describes how the tool could be performed (both in [RFC6371] describes how the tool could be used (both in proactive and
proactive and on-demand modes) for either one-way or two-way on-demand modes) for either one-way or two-way measurement. However,
measurement. However, it warns that the one-way delay option it warns that the one-way delay option requires precise time
requires precise time synchronization between the end-points. synchronization between the end points.
3.9.1. Documents for Delay Measurement 3.9.1. Documents for Delay Measurement
The [RFC 6374] document describes the protocol formats and procedures [RFC6374] describes the protocol formats and procedures for using the
for using the tool and enable efficient and accurate measurement of tool and enabling efficient and accurate measurement of packet loss,
packet loss, delay, and throughput in MPLS networks. [RFC 6375] delay, and throughput in MPLS networks. [RFC6375] describes a
describes a profile of the general MPLS loss, delay, and throughput profile of the general MPLS loss, delay, and throughput measurement
measurement techniques that suffices to meet the specific techniques that suffices to meet the specific requirements of MPLS-
requirements of MPLS-TP. Note that the tool logic is based on the TP. Note that the tool logic is based on the behavior of the
behavior of the parallel function described in [Y.1731]. parallel function described in [Y.1731].
4. MPLS-TP OAM documents guide 4. MPLS-TP OAM Documents Guide
The complete MPLS-TP OAM protocol suite is covered by a small set of The complete MPLS-TP OAM protocol suite is covered by a small set of
existing IETF documents. This set of documents may be expanded in existing IETF documents. This set of documents may be expanded in
the future to cover additional OAM functionality. In order to allow the future to cover additional OAM functionality. In order to allow
the reader to understand this set of documents, a cross-reference of the reader to understand this set of documents, a cross-reference of
the existing documents (IETF RFCs or Internet drafts while this the existing documents (RFCs or Working Group documents) for the
document is work in progress) for the initial phase of the initial phase of the specification of MPLS-based transport networks
specification of MPLS based transport networks is provided below. is provided below.
[RFC 5586] provides a specification of the basic structure of
protocol messages for in-band data plane OAM in an MPLS environment.
[RFC 6370] provides definitions of different formats that may be used [RFC5586] provides a specification of the basic structure of protocol
within OAM protocol messages to identify the network elements of a messages for in-band data-plane OAM in an MPLS environment.
MPLS based transport network.
The following table (Table 1) provides the summary of proactive [RFC6370] provides definitions of different formats that may be used
MPLS-TP OAM Fault Management toolset functions, associated tool/ within OAM protocol messages to identify the network elements of an
protocol, and the corresponding IETF RFCs where they are defined. MPLS-based transport network.
+--------------------------+-------------------------------+--------+ The following table (Table 1) provides the summary of proactive MPLS-
| OAM Functions | OAM Tools/Protocols | RFCs | TP OAM Fault Management toolset functions, the associated
+--------------------------+-------------------------------+--------+ tool/protocol, and the corresponding RFCs in which they are defined.
| Continuity Check and | Bidirectional Forwarding | [RFC |
| Connectivity | Detection (BFD) | 6428] |
| Verification | | |
+--------------------------+-------------------------------+--------+
| Remote Defect Indication | Flag in Bidirectional | [RFC |
| (RDI) | Forwarding Detection (BFD) | 6428] |
| | message | |
+--------------------------+-------------------------------+--------+
| Alarm Indication Signal | G-ACh bases AIS message | [RFC |
| (AIS) | | 6427] |
+--------------------------+-------------------------------+--------+
| Link Down Indication | Flag in AIS message | [RFC |
| (LDI) | | 6427] |
+--------------------------+-------------------------------+--------+
| Lock Reporting (LKR) | G-ACh bases LKR message | [RFC |
| | | 6427] |
+--------------------------+-------------------------------+--------+
Proactive Fault Management OAM Toolset +--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
| | | |
+--------------------------+-------------------------------+---------+
Table 1 Table 1. Proactive Fault Management OAM Toolset
The following table (Table 2) provides an overview of the on-demand The following table (Table 2) provides an overview of the on-demand
MPLS-TP OAM Fault Management toolset functions, associated tool/ MPLS-TP OAM Fault Management toolset functions, the associated
protocol, and the corresponding IETF RFCs they are defined. tool/protocol, and the corresponding RFCs in which they are defined.
+------------------------+---------------------------------+--------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+--------+
| Connectivity | LSP Ping | [RFC |
| Verification | | 6426] |
+------------------------+---------------------------------+--------+
| Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC |
| and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] |
+------------------------+---------------------------------+--------+
+------------------------+---------------------------------+--------+
| Lock Instruct(LI) | Flag in AIS message | [RFC |
| | | 6427] |
+------------------------+---------------------------------+--------+
On Demand Fault Management OAM Toolset +------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC6426]|
| | | |
+------------------------+---------------------------------+---------+
Table 2 Table 2. On Demand Fault Management OAM Toolset
The following table (Table 3) provides the Performance Monitoring The following table (Table 3) provides the Performance Monitoring
Fuctions, asscociated tool/protocol definitions, and corresponding Functions, the associated tool/protocol definitions, and the
RFCs. corresponding RFCs in which they are defined.
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs | | OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh based LM & DM | [RFC 6374] [RFC | | Packet Loss | G-ACh-based LM & DM | [RFC6374] |
| Measurement (LM) | query messages | 6375] | | Measurement (LM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh based LM & DM | [RFC 6374] [RFC | | Packet Delay | G-ACh-based LM & DM | [RFC6374] |
| Measurement (DM) | query messages | 6375] | | Measurement (DM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC 6374] [RFC | | Throughput | derived from Loss | [RFC6374] |
| Measurement | Measurement | 6375] | | Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC 6374] [RFC | | Delay Variation | derived from Delay | [RFC6374] |
| Measurement | Measurement | 6375] | | Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+ +----------------------+--------------------------+-----------------+
Performance Monitoring OAM Toolset Table 3. Performance Monitoring OAM Toolset
Table 3
5. OAM Toolset Applicability and Utilization 5. OAM Toolset Applicability and Utilization
The following subsections present the MPLS-TP OAM toolset from the The following subsections present the MPLS-TP OAM toolset from the
perspective of the specified protocols and identifies which of the perspective of the specified protocols and identifies the required
required functionality is supported by the particular protocol. functionality that is supported by the particular protocol.
5.1. Connectivity Check and Connectivity Verification 5.1. Connectivity Check and Connectivity Verification
Proactive Continuity Check and Connectivity Verification (CC-CV) Proactive Continuity Check and Connectivity Verification (CC-CV)
functions are used to detect loss of continuity (LOC), and unintended functions are used to detect loss of continuity (LOC) and unintended
connectivity between two MEPs. Loss of connectivity, mis-merging, connectivity between two MEPs. Loss of connectivity, mis-merging,
mis-connectivity, or unexpected Maintenance Entity Group End Points mis-connectivity, or unexpected Maintenance Entity Group End Points
(MEPs) can be detected using the CC-CV tools. See Section 3.1, 3.2, (MEPs) can be detected using the CC-CV tools. See Sections 3.1, 3.2,
3.3 in this document for CC-CV protocol references. 3.3 in this document for CC-CV protocol references.
The CC-CV tools are used to support MPLS-TP fault management, The CC-CV tools are used to support MPLS-TP fault management,
performance management, and protection switching. Proactive CC-CV performance management, and protection switching. Proactive CC-CV
control packets are sent by the source MEP to sink MEP. The sink MEP control packets are sent by the source MEP to the sink MEP. The
monitors the arrival of the CC-CV control packets and detects the sink-MEP monitors the arrival of the CC-CV control packets and
defect. For bidirectional transport paths, the CC-CV protocol is, detects the defect. For bidirectional transport paths, the CC-CV
usually, transmitted simultaneously in both directions. protocol is usually transmitted simultaneously in both directions.
The transmission interval of CC-CV control packet can be configured. The transmission interval of the CC-CV control packets can be
For example: configured. For example:
o 3.3ms is the default interval for protection switching. o 3.3 ms is the default interval for protection switching.
o 100ms is the default interval for performance monitoring. o 100 ms is the default interval for performance monitoring.
o 1s is the default interval for fault management. o 1 s is the default interval for fault management.
5.2. Diagnostic Tests and Lock Instruct 5.2. Diagnostic Tests and Lock Instruct
[RFC 6435] describes a protocol that provides a mechanism is provided [RFC6435] describes a protocol that provides a mechanism to Lock and
to Lock and unlock traffic (e.g. data and control traffic) or Unlock traffic (e.g., data and control traffic or specific OAM
specific OAM traffic at a specific LSR on the path of the MPLS-TP LSP traffic) at a specific LSR on the path of the MPLS-TP LSP to allow
to allow loop back of the traffic to the source. loopback of the traffic to the source.
These diagnostic functions apply to associated bidirectional MPLS-TP These diagnostic functions apply to associated bidirectional MPLS-TP
LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering
is relevant for MPLS-TP dynamic control plane option with GMPLS), and (RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-
single segment and multi-segment pseudowires. [RFC 6435] provides plane option with GMPLS), and single-segment and multi-segment
the protocol definition for diagnostic tests functions. Pseudowires. [RFC6435] provides the protocol definition for
diagnostic tests functions.
The Lock operation instruction is carried in an MPLS Loopback request [RFC6435] defines a mechanism where a lock instruction is sent by a
message sent from a MEP to a trail-end MEP of the LSP to request that management application to both ends of a point-to-point LSP,
the LSP be taken out of service. In response, the Lock operation requesting them to take the LSP out-of-service. When an end point
reply is carried in a Loopback response message sent from the trail- gets the management request, it locks the LSP and sends a Lock
end MEP back to the originating MEP to report the result. Instruct message to the other end of the LSP. The Lock Instruct
message is carried in a Generic ACH message and is sent periodically.
The time between successive messages is no longer than the value set
in the Refresh Timer field of the Lock Instruct message. An LSP end
point keeps the LSP locked while it is either receiving the periodic
Lock Instruct messages or has an in-force lock instruction from the
management application.
Note that since the management application will receive a management
plane response from both ends of the LSP confirming that the LSP has
been locked, there is no requirement for the Lock Instruct message to
have a response. Therefore, [RFC6435] does not define a Lock
Instruct response message.
The loopback operations include: The loopback operations include:
o Lock: take an LSP out of service for maintenance. o Lock: take an LSP out of service for maintenance.
o Unlock: Restore a previously locked LSP to service. o Unlock: Restore a previously locked LSP to service.
o Set_Full_Loopback and Set_OAM_Loopback o Set_Full_Loopback and Set_OAM_Loopback.
o Unset_Full_Loopback and Set_OAM_Loopback o Unset_Full_Loopback and Set_OAM_Loopback.
Operators can use the loopback mode to test the connectivity or Operators can use the loopback mode to test the connectivity or
performance (loss, delay, delay variation, and throughput) of given performance (loss, delay, delay variation, and throughput) of a given
LSP up to a specific node on the path of the LSP. LSP up to a specific node on the path of the LSP.
5.3. Lock Reporting 5.3. Lock Reporting
The Lock Report (LKR) function is used to communicate to the client The Lock Report (LKR) function is used to communicate to the MEPS of
(sub-) layer MEPs the administrative locking of a server (sub-) layer the client (sub-)layer MEPs the administrative locking of a server
MEP, and consequential interruption of data traffic forwarding in the (sub-)layer MEP, and consequential interruption of data traffic
client (sub-) layer. See Section 3.6 in this document for Lock forwarding in the client layer. See Section 3.6 in this document for
Reporting protocol references. Lock Reporting protocol references.
When operator is taking the LSP out of service for maintenance or When an operator is taking the LSP out of service for maintenance or
other operational reason, using the LKR function can help to another operational reason, using the LKR function can help to
distinguish the condition as administrative locking from defect distinguish the condition as administrative locking from a defect
condition. condition.
The Lock Report function would also serve the purpose of alarm The Lock Report function may also serve the purpose of alarm
suppression in the MPLS-TP network above the level at which the Lock suppression in the MPLS-TP network above the level at which the Lock
has occurred. The receipt of an LKR message may be treated as the has occurred. The receipt of an LKR message may be treated as the
equivalent of loss of continuity at the client layer. equivalent of the loss of continuity at the client layer.
5.4. Alarm Reporting and Link Down Indication 5.4. Alarm Reporting and Link Down Indication
Alarm Indication Signal (AIS) message serves the purpose of alarm Alarm Indication Signal (AIS) message is used to suppress alarms
suppression upon the failure detection in the server (-sub) layer. following detection of defect conditions at the server (sub-)layer.
When the Link Down Indication (RDI) is set, the AIS message may be When the Link Down Indication (LDI) is set, the AIS message may be
used to trigger recovery mechanisms. used to trigger recovery mechanisms.
When a server MEP detects the failure, it asserts Loss of Continuity When a server MEP detects the failure, it asserts LOC or signal fail,
(LOC) or signal fail which sets the flag up to generate OAM packet which sets the flag up to generate an OAM packet with the AIS
with AIS message. The AIS message is forwarded to downstream sink message. The AIS message is forwarded to the downstream sink MEP in
MEP in the client layer. This would enable the client layer to the client layer. This enables the client layer to suppress the
suppress the generation of secondary alarms. generation of secondary alarms.
A Link Down Indication (LDI) flag is defined in the AIS message. The An LDI flag is defined in the AIS message. The LDI flag is set in
LDI flag is set in the AIS message in response to detecting a fatal the AIS message in response to detecting a fatal failure in the
failure in the server layer. Receipt of an AIS message with this server layer. Receipt of an AIS message with this flag set may be
flag set may be interpreted by a MEP as an indication of signal fail interpreted by a MEP as an indication of signal fail at the client
at the client layer. layer.
The protocols for Alarm Indication Signal (AIS) and Link Down The protocols for AIS and LDI are defined in [RFC6427].
Indication (LDI) are defined in [RFC 6427].
Fault OAM messages are generated by intermediate nodes where an LSP Fault OAM messages are generated by intermediate nodes where an LSP
is switched, and propagated to the end points (MEPs). is switched and propagated to the end points (MEPs).
From a practical point of view, when both proactive Continuity Check From a practical point of view, when both proactive Continuity Check
functions and LDI are used, one may consider running the proactive functions and LDI are used, one may consider running the proactive
Continuity Check functions at a slower rate (e.g. longer BFD hello Continuity Check functions at a slower rate (e.g., longer BFD hello
intervals), and reply on LDI to trigger fast protection switch over intervals), and reply on LDI to trigger fast protection switch over
upon failure detection in a given LSP. upon failure detection in a given LSP.
5.5. Remote Defect Indication 5.5. Remote Defect Indication
Remote Defect Indication (RDI) function enables an End Point to The Remote Defect Indication (RDI) function enables an end point to
report to the other End Point that a fault or defect condition is report to its peer end point that a fault or defect condition is
detected on the PW, LSP, or Section for which they are the End detected on the PW, LSP, or Section.
Points.
The RDI OAM function is supported by the use of Bidirectional The RDI OAM function is supported by the use of BFD control packets
Forwarding Detection (BFD) Control Packets [RFC 6428]. RDI is only [RFC6428]. RDI is only used for bidirectional connections and is
used for bidirectional connections and is associated with proactive associated with proactive CC-CV activation.
CC-CV activation.
When an end point (MEP) detects a signal failure condition, it sets When an end point (MEP) detects a signal failure condition, it sets
the flag up by setting the diagnostic field of the BFD control packet the flag up by setting the diagnostic field of the BFD control packet
to a particular value to indicate the failure condition on the to a particular value to indicate the failure condition on the
associated PW, LSP, or Section, and transmitting the BFD control associated PW, LSP, or Section. Additionally, the BFD control packet
packet with the failure flag up to the other end point (its peer is transmitted with the failure flag up to the other end point (its
MEP). peer MEP).
The RDI function can be used to facilitate protection switching by The RDI function can be used to facilitate protection switching by
synchronizing the two end points when unidirectional failure occurs synchronizing the two end points when unidirectional failure occurs
and is detected by one end. and is detected by one end.
5.6. Packet Loss and Delay Measurement 5.6. Packet Loss and Delay Measurement
The packet loss and delay measurement toolset enables operators to The packet loss and delay measurement toolset enables operators to
measure the quality of the packet transmission over a PW, LSP, or measure the quality of the packet transmission over a PW, LSP, or
Section. Section 3.8 in this document defined the protocols for Section. Section 3.8 in this document defines the protocols for
packet loss measurement and 3.9 in defined the protocols for packet packet loss measurement, and Section 3.9 defines the protocols for
delay measurement. packet delay measurement.
The loss and delay protocols have the following characteristics and The loss and delay protocols have the following characteristics and
capabilities: capabilities:
o They support measurement of packet loss, delay and throughput over o They support the measurement of packet loss, delay, and throughput
Label Switched Paths (LSPs), pseudowires, and MPLS sections. over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections.
o The same LM and DM protocols can be used for both continuous/ o The same LM and DM protocols can be used for both
proactive and selective/on-demand measurement. continuous/proactive and selective/on-demand measurements.
o The LM and DM protocols use a simple query/response model for o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node - the querier bidirectional measurement that allows a single node -- the querier
- to measure the loss or delay in both directions. -- to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss o The LM and DM protocols use query messages for unidirectional loss
and delay measurement. The measurement can either be carried out and delay measurement. The measurement can either be carried out
at the downstream node(s) or at the querier if an out-of-band at the downstream node(s), or at the querier if an out-of-band
return path is available. return path is available.
o The LM and DM protocols do not require that the transmit and o The LM and DM protocols do not require that the transmit-and-
receive interfaces be the same when performing bidirectional receive interfaces be the same when performing bidirectional
measurement. measurement.
o The LM supports test-message-based measurement (i.e. inferred o The LM supports test-message-based measurement (i.e., inferred
mode) as well as measurement based on data-plane counters (i.e. mode) as well as measurement based on data-plane counters (i.e.,
direct mode). direct mode).
o The LM protocol supports both 32-bit and 64-bit counters. o The LM protocol supports both 32-bit and 64-bit counters.
o The LM protocol supports measurement in terms of both packet o The LM protocol supports measurement in terms of both packet
counts and octet counts although for simplicity only packet counts and octet counts; although for simplicity, only packet
counters are currently included in the MPLS-TP profile. counters are currently included in the MPLS-TP profile.
o The LM protocol can be used to measure channel throughput as well o The LM protocol can be used to measure channel throughput as well
as packet loss. as packet loss.
o The DM protocol supports varying the measurement message size in o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes. order to measure delays associated with different packet sizes.
o The DM protocol uses IEEE 1588 timestamps by default but also o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default
supports other timestamp formats such as NTP. but also supports other timestamp formats, such as NTP.
6. IANA Considerations
This document makes no request of IANA.
The OAM tools and functions defined under G-ACh use IANA assigned
code points. the codes are defined in the corresponding IETF RFCs
Note to RFC Editor:
this section may be removed on publication as an RFC.
7. Security Considerations 6. Security Considerations
This document as an overview of MPLS OAM tools does not by itself This document, as an overview of MPLS OAM tools, does not by itself
raise any particular security considerations. raise any particular security considerations.
The general security considerations are provided in [RFC 6920] and The general security considerations are provided in [RFC5920] and
[MPLS-TP Security Frwk]. Security considerations for each function [MPLS-TP-SEC]. Security considerations for each function within the
in the OAM toolset have been documented in each document that OAM toolset have been recorded in each document that specifies a
specifies the particular functionality. particular functionality.
OAM in general is always an area where the security risk is high, In general, OAM is always an area where the security risk is high.
e.g. confidential information may be intercepted for attackers to For example, confidential information may be intercepted by attackers
again access to the networks, therefore authentication, to gain access to networks; therefore, authentication, authorization,
authorization, and encryption need to be enforced for prevent and encryption must be enforced to prevent security breaches.
security breach.
In addition to implement security protocol, tools, and mechanisms, It is also important to strictly follow operational security
following strict operation security procedures is very important, procedures. For example, in the case of MPLS-TP static provisioning,
especially MPSL-TP static provisioning processes involve operator the operator interacts directly with the Network Management System
direct interactions with NMS and devices, its critical to prevent (NMS) and devices, and it is critical in order to prevent human
human errors and malicious attacks. errors and malicious attacks.
Since MPLS-TP OAM uses G-ACh, the security risks and mitigation Since MPLS-TP OAM uses G-ACh, the security risks and mitigations
described in [RFC 5085] apply here. In short, the G-ACh could be described in [RFC5085] also apply here. In short, messages on the
intercepted, or false G-ACh packets could be inserted. DoS attack G-ACh could be intercepted, or false G-ACh packets could be inserted.
could happen by flooding G-ACh messages to peer devices. To mitigate
this type of attacks, throttling mechanisms can be used. For more
details, please see [RFC 5085].
8. Acknowledgements Additionally, DoS attacks can be mounted by flooding G-ACh messages
to peer devices. To mitigate this type of attack, throttling
mechanisms or rate limits can be used. For more details, please see
[RFC5085].
7. Acknowledgements
The authors would like to thank the MPLS-TP experts from both the The authors would like to thank the MPLS-TP experts from both the
IETF and ITU-T for their helpful comments. In particular, we would IETF and ITU-T for their helpful comments. In particular, we would
like to thank Loa Andersson, and the Area Directors for their like to thank Loa Andersson and the Area Directors for their
suggestions and enhancements to the text. suggestions and enhancements to the text.
Thanks to Tom Petch for useful comments and discussions. Thanks to Tom Petch for useful comments and discussions.
Thanks to Rui Costa for his review and comments which helped improve Thanks to Rui Costa for his review and comments, which helped improve
this doecument. this document.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC 4379] [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC 5085] [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Virtual Circuit Connectivity Verification (VCCV): A
Connectivity Verification (VCCV): A Control Channel for Control Channel for Pseudowires", RFC 5085, December 2007.
Pseudowires", RFC 5085, December 2007.
[RFC 5586] [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic "MPLS Generic Associated Channel", RFC 5586, June 2009.
Associated Channel", RFC 5586, June 2009.
[RFC 5654] [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Niven-Jenkins, B., Nadeau, T., and C. Pignataro, Sprecher, N., and S. Ueno, "Requirements of an MPLS
"Requirements for the Transport Profile of MPLS", Transport Profile", RFC 5654, September 2009.
RFC 5654, April 2009.
[RFC 5860] [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
Vigoureux, M., Betts, M., and D. Ward, "Requirements for "Requirements for Operations, Administration, and
OAM in MPLS Transport Networks", RFC 5860, April 2009. Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
May 2010.
[RFC 5880] [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Katz, D. and D. Ward, "Bidirectional Forwarding (BFD)", RFC 5880, June 2010.
Detection", RFC 5880, February 2009.
[RFC 5884] [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label
"BFD For MPLS LSPs", RFC 5884, June 2008. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC 5921] [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. L., and L. Berger, "A Framework for MPLS in Transport
Berger, "A Framework for MPLS in Transport Networks", Networks", RFC 5921, July 2010.
RFC 5921, July 2010.
[RFC 6370] [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
Identifiers", RFC 6370, September 2011.
[RFC 6371] [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM Administration, and Maintenance Framework for MPLS-Based
Framework and Overview", RFC 6371, September 2011. Transport Networks", RFC 6371, September 2011.
[RFC 6374] [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC 6375] [RFC6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
Frost, D. and S. Bryant, "A Packet Loss and Delay Delay Measurement Profile for MPLS-Based Transport
Measurement Profile for MPLS-based Transport Networks", Networks", RFC 6375, September 2011.
RFC 6375, September 2011.
[RFC 6426] [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS On-Demand Connectivity Verification and Route Tracing",
on-demand Connectivity Verification, Route Tracing and RFC 6426, November 2011.
Adjacency Verification", RFC 6426, August 2011.
[RFC 6427] [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault Boutros, S., and D. Ward, "MPLS Fault Management
Management OAM", RFC 6427, September 2011. Operations, Administration, and Maintenance (OAM)", RFC
6427, November 2011.
[RFC 6428] [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
Allan, D. and G. Swallow, "Proactive Connectivity "Proactive Connectivity Verification, Continuity Check,
Verification, Continuity Check and Remote Defect and Remote Defect Indication for the MPLS Transport
indication for MPLS Transport Profile", RFC 6428, Profile", RFC 6428, November 2011.
August 2011.
[RFC 6435] [RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
and X. Dai, "MPLS Transport Profile Lock Instruct and Profile Lock Instruct and Loopback Functions", RFC 6435,
Loopback Functions", RFC 6435, September 2011. November 2011.
9.2. Informative References 8.2. Informative References
[MPLS-TP Security Frwk] [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[MPLS-TP-ITU-Idents]
Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions", Work in
Progress, March 2012.
[MPLS-TP-SEC]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework", Security Framework", Work in Progress, March 2012.
ID draft-ietf-mpls-tp-security-framework-02, May 2011.
[RFC 6920] [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[Y.1731] International Telecommunications Union - Standardization, [Y.1731] International Telecommunications Union - Standardization,
"OAM functions and mechanisms for Ethernet based "OAM functions and mechanisms for Ethernet based
networks", ITU Y.1731, May 2006. networks", ITU Y.1731, May 2006.
[MPLS TP ITU Idents] Contributors
Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions", Elisa Bellagamba Ericsson
ID draft-ietf-mpls-tp-itu-t-identifiers-02, July 2011. Yaacov Weingarten Nokia Siemens Networks
Dan Frost Cisco
Nabil Bitar Verizon
Raymond Zhang Alcatel Lucent
Lei Wang Telenor
Kam Lee Yap XO Communications
John Drake Juniper
Yaakov Stein RAD
Anamaria Fulignoli Ericsson
Italo Busi Alcatel Lucent
Huub van Helvoort Huawei
Thomas Nadeau Computer Associate
Henry Yu TW Telecom
Mach Chen Huawei
Manuel Paul Deutsche Telekom
Authors' Addresses Authors' Addresses
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
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
Luyuan Fang Luyuan Fang
Cisco Cisco Systems
111 Wood Avenue South 111 Wood Avenue South
Iselin, NJ 08830 Iselin, NJ 08830
USA USA
Email: lufang@cisco.com EMail: lufang@cisco.com
 End of changes. 162 change blocks. 
533 lines changed or deleted 517 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/