|
|
|
|
|
|
IETF RFC 6669
Last modified on Monday, July 16th, 2012
 Permanent link to RFC 6669
 Search GitHub Wiki for RFC 6669
 Show other RFCs mentioning RFC 6669
Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6669 Nokia Siemens Networks
Category: Informational L. Fang
ISSN: 2070-1721 Cisco Systems
July 2012
An Overview of the Operations, Administration, and Maintenance (OAM)
Toolset for MPLS-Based Transport Networks
 Abstract
This document provides an overview of the Operations, Administration,
and Maintenance (OAM) toolset for MPLS-based transport networks. The
toolset consists of a comprehensive set of fault management and
performance monitoring capabilities (operating in the data plane)
that are appropriate for transport networks as required in RFC 5860
and support the network and services at different nested levels.
This overview includes a brief recap of the MPLS Transport Profile
(MPLS-TP) OAM requirements and functions and the generic mechanisms
created in the MPLS data plane that allow the OAM packets to run
in-band and share their fate with data packets. The protocol
definitions for each of the MPLS-TP OAM tools are defined in separate
documents (RFCs or Working Group documents), which are referenced by
this document.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
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.
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/RFC 6669.
Sprecher & Fang Informational PAGE 1 
RFC 6669 OAM Toolset July 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Sprecher & Fang Informational PAGE 2
RFC 6669 OAM Toolset July 2012
Table of Contents
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Acronyms ...................................................5
2. Basic OAM Infrastructure Functionality ..........................6
3. MPLS-TP OAM Functions ...........................................8
3.1. Continuity Check and Connectivity Verification .............8
3.1.1. Documents for CC-CV Tools ...........................8
3.2. Remote Defect Indication ...................................8
3.2.1. Documents for RDI ...................................9
3.3. Route Tracing ..............................................9
3.3.1. Documents for Route Tracing .........................9
3.4. Alarm Reporting ............................................9
3.4.1. Documents for Alarm Reporting .......................9
3.5. Lock Instruct ..............................................9
3.5.1. Documents for Lock Instruct ........................10
3.6. Lock Reporting ............................................10
3.6.1. Documents for Lock Reporting .......................10
3.7. Diagnostic ................................................10
3.7.1. Documents for Diagnostic Testing ...................10
3.8. Packet Loss Measurement ...................................10
3.8.1. Documents for Packet Loss Measurement ..............11
3.9. Packet Delay Measurement ..................................11
3.9.1. Documents for Delay Measurement ....................11
4. MPLS-TP OAM Documents Guide ....................................12
5. OAM Toolset Applicability and Utilization ......................13
5.1. Connectivity Check and Connectivity Verification ..........14
5.2. Diagnostic Tests and Lock Instruct ........................14
5.3. Lock Reporting ............................................15
5.4. Alarm Reporting and Link Down Indication ..................15
5.5. Remote Defect Indication ..................................16
5.6. Packet Loss and Delay Measurement .........................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
Contributors ......................................................21
Sprecher & Fang Informational PAGE 3
RFC 6669 OAM Toolset July 2012
1. Introduction
1.1. Scope
The MPLS Transport Profile (MPLS-TP) architectural framework is
defined in [RFC 5921], and it describes a common set of protocol
functions that supports the operational models and capabilities
typical of such transport networks.
Operations, Administration, and Maintenance (OAM) plays a significant
role in carrier networks. It provides methods for fault management
and performance monitoring in both the transport and service layers,
in order to improve their ability to support services with guaranteed
and strict Service Level Agreements (SLAs) while reducing their
operational costs.
[RFC 5654], in general, and [RFC 5860], in particular, define a set of
requirements for the OAM functionality for MPLS-TP Label Switched
Paths (LSPs), Pseudowires (PWs), and Sections.
The OAM solution, developed by the joint IETF and ITU-T MPLS-TP
project, has three objectives:
o The OAM toolset should be developed based on existing MPLS
architecture, technology, and toolsets.
o The OAM operational experience should be similar to that in other
transport networks.
o The OAM toolset developed for MPLS-based transport networks needs
to be fully interoperable with existing MPLS OAM tools as
documented in Section 2.1.5. of [RFC 5860].
The MPLS-TP OAM toolset is based on the following existing tools:
o LSP ping, as defined in [RFC 4379].
o Bidirectional Forwarding Detection (BFD), as defined in [RFC 5880]
and refined in [RFC 5884].
o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This
has been used as functionality guidelines for the performance
measurement tools that were not previously supported in MPLS.
Note that certain extensions and adjustments have been specified,
relative to the existing MPLS tools, in order to conform to the
transport environment and the requirements of MPLS-TP. However,
compatibility with the existing MPLS tools has been maintained.
Sprecher & Fang Informational PAGE 4
RFC 6669 OAM Toolset July 2012
This document provides an overview of the MPLS-TP OAM toolset, which
consists of tools for MPLS-TP fault management and performance
monitoring. This overview includes a brief recap of MPLS-TP OAM
requirements, their functions, and the generic mechanisms used to
support the MPLS-TP OAM operation.
The protocol definitions for individual MPLS-TP OAM tools are
specified in separate RFCs (or Working Group documents), which are
referenced by this document.
In addition, this document includes a table that cross-references the
solution documents of the OAM functionality supported. Finally, the
document presents the applicability and utilization of each tool in
the MPLS-TP OAM toolset.
1.2. Acronyms
This document uses the following acronyms:
ACH Associated Channel Header
AIS Alarm Indication Signal
BFD Bidirectional Forwarding Detection
CC-CV Continuity Check and Connectivity Verification
DM Delay Measurement
FM Fault Management
G-ACh Generic Associated Channel
GAL G-ACh Label
GMPLS Generalized Multiprotocol Label Switching
IANA Internet Assigned Numbers Authority
LDI Link Down Indication
LKR Lock Report
LM Loss Measurement
LOC Loss of Continuity
LSP Label Switched Path
MEP Maintenance Entity Group End Point
MEG Maintenance Entity Group
MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching
MPLS-TP Transport Profile for MPLS
OAM Operations, Administration, and Maintenance
PM Performance Monitoring
PW Pseudowire
RDI Remote Defect Indication
SLA Service Level Agreement
TLV Type, Length, Value
VCCV Virtual Circuit Connectivity Verification
Sprecher & Fang Informational PAGE 5
RFC 6669 OAM Toolset July 2012
2. Basic OAM Infrastructure Functionality
[RFC 5860] defines a set of requirements for OAM architecture and
general principles of operations, which are evaluated below:
[RFC 5860] requires that --
o OAM mechanisms in MPLS-TP are independent of the transmission
media and the client service being emulated by the PW ([RFC 5860],
Section 2.1.2).
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 forwarding are available, then it must be possible to choose
to make use of IP capabilities. On the other hand, in
environments where IP functionality is not available, the OAM
tools must still be able to operate independent of IP forwarding
and routing ([RFC 5860], Section 2.1.4). It is required to have
OAM interoperability between distinct domains materializing the
environments ([RFC 5860], Section 2.1.5).
o All OAM protocols support identification information, at least in
the form of IP addressing structure, and are extensible to support
additional identification schemes ([RFC 5860], Section 2.1.4).
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
packets from user-plane packets [RFC 5860], Section 2.1.3.
Inherent in this requirement is the principle that full operation
of the MPLS-TP OAM must be possible independently of the control
or management plane used to operate the network [RFC 5860], Section
2.1.3.
o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-
point co-routed bidirectional LSPs, and point-to-point
bidirectional Sections ([RFC 5860], Section 2.1.1). The
applicability of particular MPLS-TP OAM functions to point-to-
point associated bidirectional LSPs, point-to-point unidirectional
LSPs, and point-to-multipoint LSPs, is described in [RFC 5860],
Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs
when they span either single or multiple domains ([RFC 5860],
Section 2.1.1).
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).
Sprecher & Fang Informational PAGE 6
RFC 6669 OAM Toolset July 2012
[RFC 5860], Section 2.2 recommends that any protocol solution meeting
one or more functional requirement(s) be the same for PWs, LSPs, and
Sections.
The following document set addresses the basic requirements listed
above:
o [RFC 6371] describes the architectural framework for conformance to
the basic requirements listed above. It also defines the basic
relationships between the MPLS structures, e.g., LSP, PW, and the
structures necessary for OAM functionality, i.e., the Maintenance
Entity Group (MEG), its end points, and intermediate points.
o [RFC 5586] specifies the use of the MPLS-TP in-band control
channels. It generalizes the applicability of the PW ACH to MPLS
LSPs and Sections by defining a Generic Associated Channel
(G-ACh). The G-ACh allows control packets to be multiplexed
transparently over LSPs and Sections similar to that of PW VCCV
[RFC 5085]. The Generic Association Label (GAL) is defined by
assigning a reserved MPLS label value and is used to identify the
OAM control packets. The value of the ACH Channel Type field
indicates the specific protocol carried on the associated control
channel. Each MPLS-TP OAM protocol has an IANA-assigned channel
type allocated to it.
[RFC 5085] defines an Associated Channel Header (ACH) that provides a
PW associated control channel between a PW's end points, over which
OAM and other control messages can be exchanged. [RFC 5586]
generalizes the PW Associated Channel Header (ACH) to provide common
in-band control channels also at the LSP and MPLS-TP link levels.
The G-ACh allows control packets to be multiplexed transparently over
the same LSP or MPLS-TP link as in PW VCCV. Multiple control
channels can exist between end points.
[RFC 5085] also defines a label-based exception mechanism that helps a
Label Switching Router (LSR) to identify the control packets and
direct them to the appropriate entity for processing. The use of
G-ACh and GAL provides the necessary mechanisms to allow OAM packets
to run in-band and share their fate with data packets. It is
expected that all of the OAM protocols will be used in conjunction
with this Generic Associated Channel.
o [RFC 6370] provides an IP-based identifier set for MPLS-TP that can
be used to identify the transport entities in the network and
referenced by the different OAM protocols.
Sprecher & Fang Informational PAGE 7
RFC 6669 OAM Toolset July 2012
Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to
include identifier information in a format used by the ITU-T.
Other identifier sets may be defined as well.
3. MPLS-TP OAM Functions
The following sections discuss the OAM functions that are required in
[RFC 5860] and expanded upon in [RFC 6371].
3.1. Continuity Check and Connectivity Verification
Continuity Check and Connectivity Verification (CC-CV) are OAM
operations generally used in tandem and complement each other. These
functions are generally run proactively, but may also be used
on-demand for diagnoses of a specific condition. [RFC 5860] states
that the function should allow the MEPs to proactively monitor the
liveliness and connectivity of a transport path (LSP, PW, or a
Section) between them. In on-demand mode, this function should
support monitoring between the MEPs and between a MEP and MIP. Note
that as specified in [RFC 6371], Sections 3.3 and 3.4, a MEP and a MIP
can reside in an unspecified location within a node, or in a
particular interface on a specific side of the forwarding engine.
[RFC 6371] highlights the need for the CC-CV messages to include
unique identification of the MEG that is being monitored and the MEP
that originated the message. The function, both proactively and in
on-demand mode, needs to be transmitted at regular transmission rates
pre-configured by the operator.
3.1.1. Documents for CC-CV Tools
[RFC 6428] defines BFD extensions to support proactive CC-CV
applications.
[RFC 6426] provides LSP ping extensions that are used to implement
on-demand connectivity verification.
Both of these tools will be used within the basic functionality
framework described in Section 2.
3.2. Remote Defect Indication
Remote Defect Indication (RDI) is used by a path end point to report
that a defect is detected on a bidirectional connection to its peer
end point. [RFC 5860] points out that this function may be applied to
a unidirectional LSP only if a return path exists. [RFC 6371] points
out that this function is associated with the proactive CC-CV
function.
Sprecher & Fang Informational PAGE 8
RFC 6669 OAM Toolset July 2012
3.2.1. Documents for RDI
[RFC 6428] provides an extension for BFD that includes the RDI
indication in the BFD format and a specification of how this
indication is to be used.
3.3. Route Tracing
[RFC 5860] defines the need for functionality that would allow a path
end point to identify the intermediate points (if any) and end
point(s) along the path (LSP, PW, or a Section). This function would
be used in on-demand mode. Normally, this path will be used for
bidirectional PW, LSP, and Sections; however, unidirectional paths
may be supported only if a return path exists.
3.3.1. Documents for Route Tracing
[RFC 6426] specifies that the LSP ping enhancements for MPLS-TP on-
demand connectivity verification include information on the use of
LSP ping for route tracing of an MPLS-TP path.
3.4. Alarm Reporting
Alarm Reporting is a function used by an intermediate point of a path
(LSP or PW) to report to the end points of the path that a fault
exists on the path. [RFC 6371] states that this may occur as a result
of a defect condition discovered at a server layer. The intermediate
point generates an Alarm Indication Signal (AIS) that continues until
the fault is cleared. The consequent action of this function is
detailed in [RFC 6371].
3.4.1. Documents for Alarm Reporting
MPLS-TP defines a new protocol to address this functionality that is
documented in [RFC 6427]. This protocol uses all of the basic
mechanisms detailed in Section 2.
3.5. Lock Instruct
The Lock Instruct function is an administrative control tool that
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-
side provisioning for administrative locking, according to [RFC 6371].
This function is used on-demand.
Sprecher & Fang Informational PAGE 9
RFC 6669 OAM Toolset July 2012
3.5.1. Documents for Lock Instruct
[RFC 6435] describes the details of a new ACH-based protocol format
for this functionality.
3.6. Lock Reporting
Lock Reporting, defined in [RFC 5860], is similar to the Alarm
Reporting function described above. It is used by an intermediate
point to notify the end points of a transport path (LSP or PW) that
an administrative lock condition exists for the transport path.
3.6.1. Documents for Lock Reporting
MPLS-TP defines a new protocol to address this functionality that is
documented in [RFC 6427]. This protocol uses all the basic mechanisms
detailed in Section 2.
3.7. Diagnostic
[RFC 5860] indicates a need to provide an OAM function that would
enable conducting different diagnostic tests on a PW, LSP, or
Section. [RFC 6371] provides two types of specific tests to be used
through this functionality:
o Throughput estimation - allowing the provider to verify the
bandwidth/throughput of a transport path. This is an out-of-
service tool that uses special packets of varying sizes to test
the actual bandwidth and/or throughput of the path.
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
back to the originating MEP. For targeting MIPs, a co-routed
bidirectional path is required.
3.7.1. Documents for Diagnostic Testing
[RFC 6435] describes the details of a new ACH-based protocol format
for the data-plane loopback functionality.
The tool for throughput estimation is under study.
3.8. Packet Loss Measurement
Packet Loss Measurement is required by [RFC 5860] to provide a
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
user packets during a defined time interval. To employ this
Sprecher & Fang Informational PAGE 10
RFC 6669 OAM Toolset July 2012
function, [RFC 6371] defines that the two end points of the transport
path should exchange counters of messages transmitted and received
within a time period bounded by loss-measurement messages. The
framework warns that there may be small errors in the computation,
which result from various issues.
3.8.1. Documents for Packet Loss Measurement
[RFC 6374] describes the protocol formats and procedures for using the
tool and enabling efficient and accurate measurement of packet loss,
delay, and throughput in MPLS networks. [RFC 6375] describes a
profile of the general MPLS loss, delay, and throughput measurement
techniques that suffice to meet the specific requirements of MPLS-TP.
Note that the tool logic is based on the behavior of the parallel
function described in [Y.1731].
3.9. Packet Delay Measurement
Packet Delay Measurement is a function that is used to measure 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 5860], where:
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
the reception of the last bit of that packet by the destination
node.
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
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
destination node.
[RFC 6371] describes how the tool could be used (both in proactive and
on-demand modes) for either one-way or two-way measurement. However,
it warns that the one-way delay option requires precise time
synchronization between the end points.
3.9.1. Documents for Delay Measurement
[RFC 6374] describes the protocol formats and procedures for using the
tool and enabling efficient and accurate measurement of packet loss,
delay, and throughput in MPLS networks. [RFC 6375] describes a
profile of the general MPLS loss, delay, and throughput measurement
techniques that suffices to meet the specific requirements of MPLS-
TP. Note that the tool logic is based on the behavior of the
parallel function described in [Y.1731].
Sprecher & Fang Informational PAGE 11
RFC 6669 OAM Toolset July 2012
4. MPLS-TP OAM Documents Guide
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
the future to cover additional OAM functionality. In order to allow
the reader to understand this set of documents, a cross-reference of
the existing documents (RFCs or Working Group documents) for the
initial phase of the specification of MPLS-based transport networks
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
within OAM protocol messages to identify the network elements of an
MPLS-based transport network.
The following table (Table 1) provides the summary of proactive MPLS-
TP OAM Fault Management toolset functions, the associated
tool/protocol, and the corresponding RFCs in which they are defined.
+--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC 6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC 6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC 6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC 6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC 6427]|
| | | |
+--------------------------+-------------------------------+---------+
Table 1. Proactive Fault Management OAM Toolset
Sprecher & Fang Informational PAGE 12
RFC 6669 OAM Toolset July 2012
The following table (Table 2) provides an overview of the on-demand
MPLS-TP OAM Fault Management toolset functions, the associated
tool/protocol, and the corresponding RFCs in which they are defined.
+------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC 6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC 6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC 6426]|
| | | |
+------------------------+---------------------------------+---------+
Table 2. On Demand Fault Management OAM Toolset
The following table (Table 3) provides the Performance Monitoring
Functions, the associated tool/protocol definitions, and the
corresponding RFCs in which they are defined.
+----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh-based LM & DM | [RFC 6374] |
| Measurement (LM) | query messages | [RFC 6375] |
+----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh-based LM & DM | [RFC 6374] |
| Measurement (DM) | query messages | [RFC 6375] |
+----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC 6374] |
| Measurement | Measurement | [RFC 6375] |
+----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC 6374] |
| Measurement | Measurement | [RFC 6375] |
+----------------------+--------------------------+-----------------+
Table 3. Performance Monitoring OAM Toolset
5. OAM Toolset Applicability and Utilization
The following subsections present the MPLS-TP OAM toolset from the
perspective of the specified protocols and identifies the required
functionality that is supported by the particular protocol.
Sprecher & Fang Informational PAGE 13
RFC 6669 OAM Toolset July 2012
5.1. Connectivity Check and Connectivity Verification
Proactive Continuity Check and Connectivity Verification (CC-CV)
functions are used to detect loss of continuity (LOC) and unintended
connectivity between two MEPs. Loss of connectivity, mis-merging,
mis-connectivity, or unexpected Maintenance Entity Group End Points
(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.
The CC-CV tools are used to support MPLS-TP fault management,
performance management, and protection switching. Proactive CC-CV
control packets are sent by the source MEP to the sink MEP. The
sink-MEP monitors the arrival of the CC-CV control packets and
detects the defect. For bidirectional transport paths, the CC-CV
protocol is usually transmitted simultaneously in both directions.
The transmission interval of the CC-CV control packets can be
configured. For example:
o 3.3 ms is the default interval for protection switching.
o 100 ms is the default interval for performance monitoring.
o 1 s is the default interval for fault management.
5.2. Diagnostic Tests and Lock Instruct
[RFC 6435] describes a protocol that provides a mechanism to Lock and
Unlock traffic (e.g., data and control traffic or specific OAM
traffic) at a specific LSR on the path of the MPLS-TP LSP to allow
loopback of the traffic to the source.
These diagnostic functions apply to associated bidirectional MPLS-TP
LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering
(RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-
plane option with GMPLS), and single-segment and multi-segment
Pseudowires. [RFC 6435] provides the protocol definition for
diagnostic tests functions.
[RFC 6435] defines a mechanism where a lock instruction is sent by a
management application to both ends of a point-to-point LSP,
requesting them to take the LSP out-of-service. When an end point
gets the management request, it locks the LSP and sends a Lock
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
Sprecher & Fang Informational PAGE 14
RFC 6669 OAM Toolset July 2012
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, [RFC 6435] does not define a Lock
Instruct response message.
The loopback operations include:
o Lock: take an LSP out of service for maintenance.
o Unlock: Restore a previously locked LSP to service.
o Set_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
performance (loss, delay, delay variation, and throughput) of a given
LSP up to a specific node on the path of the LSP.
5.3. Lock Reporting
The Lock Report (LKR) function is used to communicate to the MEPS of
the client (sub-)layer MEPs the administrative locking of a server
(sub-)layer MEP, and consequential interruption of data traffic
forwarding in the client layer. See Section 3.6 in this document for
Lock Reporting protocol references.
When an operator is taking the LSP out of service for maintenance or
another operational reason, using the LKR function can help to
distinguish the condition as administrative locking from a defect
condition.
The Lock Report function may also serve the purpose of alarm
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
equivalent of the loss of continuity at the client layer.
5.4. Alarm Reporting and Link Down Indication
Alarm Indication Signal (AIS) message is used to suppress alarms
following detection of defect conditions at the server (sub-)layer.
When the Link Down Indication (LDI) is set, the AIS message may be
used to trigger recovery mechanisms.
Sprecher & Fang Informational PAGE 15
RFC 6669 OAM Toolset July 2012
When a server MEP detects the failure, it asserts LOC or signal fail,
which sets the flag up to generate an OAM packet with the AIS
message. The AIS message is forwarded to the downstream sink MEP in
the client layer. This enables the client layer to suppress the
generation of secondary alarms.
An LDI flag is defined in the AIS message. The LDI flag is set in
the AIS message in response to detecting a fatal failure in the
server layer. Receipt of an AIS message with this flag set may be
interpreted by a MEP as an indication of signal fail at the client
layer.
The protocols for AIS and LDI are defined in [RFC 6427].
Fault OAM messages are generated by intermediate nodes where an LSP
is switched and propagated to the end points (MEPs).
From a practical point of view, when both proactive Continuity Check
functions and LDI are used, one may consider running the proactive
Continuity Check functions at a slower rate (e.g., longer BFD hello
intervals), and reply on LDI to trigger fast protection switch over
upon failure detection in a given LSP.
5.5. Remote Defect Indication
The Remote Defect Indication (RDI) function enables an end point to
report to its peer end point that a fault or defect condition is
detected on the PW, LSP, or Section.
The RDI OAM function is supported by the use of BFD control packets
[RFC 6428]. RDI is only used for bidirectional connections and is
associated with proactive CC-CV activation.
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
to a particular value to indicate the failure condition on the
associated PW, LSP, or Section. Additionally, the BFD control packet
is transmitted with the failure flag up to the other end point (its
peer MEP).
The RDI function can be used to facilitate protection switching by
synchronizing the two end points when unidirectional failure occurs
and is detected by one end.
Sprecher & Fang Informational PAGE 16
RFC 6669 OAM Toolset July 2012
5.6. Packet Loss and Delay Measurement
The packet loss and delay measurement toolset enables operators to
measure the quality of the packet transmission over a PW, LSP, or
Section. Section 3.8 in this document defines the protocols for
packet loss measurement, and Section 3.9 defines the protocols for
packet delay measurement.
The loss and delay protocols have the following characteristics and
capabilities:
o They support the measurement of packet loss, delay, and throughput
over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections.
o The same LM and DM protocols can be used for both
continuous/proactive and selective/on-demand measurements.
o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node -- the querier
-- to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss
and delay measurement. The measurement can either be carried out
at the downstream node(s), or at the querier if an out-of-band
return path is available.
o The LM and DM protocols do not require that the transmit-and-
receive interfaces be the same when performing bidirectional
measurement.
o The LM supports test-message-based measurement (i.e., inferred
mode) as well as measurement based on data-plane counters (i.e.,
direct mode).
o The LM protocol supports both 32-bit and 64-bit counters.
o The LM protocol supports measurement in terms of both packet
counts and octet counts; although for simplicity, only packet
counters are currently included in the MPLS-TP profile.
o The LM protocol can be used to measure channel throughput as well
as packet loss.
o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes.
o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default
but also supports other timestamp formats, such as NTP.
Sprecher & Fang Informational PAGE 17
RFC 6669 OAM Toolset July 2012
6. Security Considerations
This document, as an overview of MPLS OAM tools, does not by itself
raise any particular security considerations.
The general security considerations are provided in [RFC 5920] and
[MPLS-TP-SEC]. Security considerations for each function within the
OAM toolset have been recorded in each document that specifies a
particular functionality.
In general, OAM is always an area where the security risk is high.
For example, confidential information may be intercepted by attackers
to gain access to networks; therefore, authentication, authorization,
and encryption must be enforced to prevent security breaches.
It is also important to strictly follow operational security
procedures. For example, in the case of MPLS-TP static provisioning,
the operator interacts directly with the Network Management System
(NMS) and devices, and it is critical in order to prevent human
errors and malicious attacks.
Since MPLS-TP OAM uses G-ACh, the security risks and mitigations
described in [RFC 5085] also apply here. In short, messages on the
G-ACh could be intercepted, or false G-ACh packets could be inserted.
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
[RFC 5085].
7. Acknowledgements
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
like to thank Loa Andersson and the Area Directors for their
suggestions and enhancements to the text.
Thanks to Tom Petch for useful comments and discussions.
Thanks to Rui Costa for his review and comments, which helped improve
this document.
Sprecher & Fang Informational PAGE 18
RFC 6669 OAM Toolset July 2012
8. References
8.1. Normative References
[RFC 4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC 5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC 5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC 5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[RFC 5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
May 2010.
[RFC 5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC 5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC 5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010.
[RFC 6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC 6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, September 2011.
[RFC 6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC 6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and
Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, September 2011.
Sprecher & Fang Informational PAGE 19
RFC 6669 OAM Toolset July 2012
[RFC 6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
[RFC 6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)", RFC
6427, November 2011.
[RFC 6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, November 2011.
[RFC 6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
Profile Lock Instruct and Loopback Functions", RFC 6435,
November 2011.
8.2. Informative References
[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
Security Framework", Work in Progress, March 2012.
[RFC 5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[Y.1731] International Telecommunications Union - Standardization,
"OAM functions and mechanisms for Ethernet based
networks", ITU Y.1731, May 2006.
Sprecher & Fang Informational PAGE 20
RFC 6669 OAM Toolset July 2012
Contributors
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
Authors' Addresses
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
EMail: nurit.sprecher@nsn.com
Luyuan Fang
Cisco Systems
111 Wood Avenue South
Iselin, NJ 08830
USA
EMail: lufang@cisco.com
Sprecher & Fang Informational PAGE 21
RFC TOTAL SIZE: 46171 bytes
PUBLICATION DATE: Monday, July 16th, 2012
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
