One document matched: draft-ietf-mpls-tp-oam-analysis-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-mpls-tp-oam-analysis-06.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="OAM Tool Set">An Overview of the OAM Tool Set for
MPLS based Transport Networks</title>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region></region>
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization>Cisco</organization>
<address>
<postal>
<street>111 Wood Avenue South</street>
<city>Iselin</city>
<region>NJ</region>
<code>08830</code>
<country>USA</country>
</postal>
<email>lufang@cisco.com</email>
</address>
</author>
<date year="2011" />
<abstract>
<t>This document provides an overview of the 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) which are appropriate for transport
networks as required in <xref target="MPLS-TP OAM Reqs"></xref> and support the network
and services at different nested levels.
This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic
mechanisms created in the MPLS data plane to allow the OAM packets 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 drafts) which are referenced by this document.</t>
<t>This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Scope">
<t>OAM (Operations, Administration, and Maintenance) plays a
significant role in carrier networks, providing methods for fault
management and performance monitoring in both the transport and the
service layers in order to improve their ability to support services
with guaranteed and strict Service Level Agreements (SLAs) while
reducing their operational costs.</t>
<t><xref target="MPLS-TP Reqs"></xref>, in general, and <xref
target="MPLS-TP OAM Reqs"></xref>, in particular, define a set of
requirements for OAM functionality for MPLS-Transport Profile (MPLS-TP)
Segments, Label Switched Paths (LSPs) (network infrastructure) and
Pseudowires (PWs) (services).</t>
<t>The OAM solution, developed by the joint IETF and ITU-T MPLS-TP project,
has three objectives:</t>
<t><list style="symbols">
<t>The OAM toolset should be developed based on existing MPLS
architecture, technology, and toolsets.</t>
<t>The OAM operational experience should be similar to that in other transport
networks.</t>
<t>The OAM toolset developed for MPLS based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as documented
in <xref target="MPLS-TP OAM Reqs" />.</t>
</list></t>
<t>The MPLS-TP OAM toolset is based on the following existing tools:</t>
<t><list style="symbols">
<t>LSP-Ping as defined in <xref target="LSP Ping"></xref>.</t>
<t>Bidirectional Forwarding Detection (BFD) as defined in <xref
target="BASE BFD"></xref> and refined in <xref
target="MPLS BFD"></xref>.</t>
<t>ITU-T OAM for Ethernet toolset as defined in <xref target="Y.1731"></xref>.
This has been used for functionality guidelines for the performance measurement
tools that were not previously supported in MPLS.</t>
</list> It should be noted 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 tools has been maintained.</t>
<t>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 and functions, and of the
generic mechanisms used to support the MPLS-TP OAM operation.</t>
<t>The protocol definitions for each individual MPLS-TP OAM tool are specified
in separate RFCs (or Working Group documents while this document is work in
progress), which are referenced by this document.</t>
<t>In addition, the document includes a table that cross-references the solution
documents to the OAM functionality supported. Finally, the document presents the
applicability and utilization of each tool in the MPLS-TP OAM toolset.</t>
</section>
<section title="Contributing Authors">
<texttable align="left" style="none">
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<c>Elisa Bellagamba</c>
<c>Ericsson</c>
<c>Yaacov Weingarten</c>
<c>Nokia Siemens Networks</c>
<c>Dan Frost</c>
<c>Cisco</c>
<c>Nabil Bitar</c>
<c>Verizon</c>
<c>Raymond Zhang</c>
<c>Alcatel Lucent</c>
<c>Lei Wang</c>
<c>Telenor</c>
<c>Kam Lee Yap</c>
<c>XO Communications</c>
<c>John Drake</c>
<c>Juniper</c>
<c>Yaakov Stein</c>
<c>RAD</c>
<c>Anamaria Fulignoli</c>
<c>Ericsson</c>
<c>Italo Busi</c>
<c>Alcatel Lucent</c>
<c>Huub van Helvoort</c>
<c>Huawei</c>
<c>Thomas Nadeau</c>
<c>Computer Associate</c>
<c>Henry Yu</c>
<c>TW Telecom</c>
<c>Mach Chen</c>
<c>Huawei</c>
<c>Manuel Paul</c>
<c>Deutsche Telekom</c>
</texttable>
</section>
<section title="Acronyms">
<texttable align="left" style="none">
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<c>ACH</c>
<c>Associated Channel Header</c>
<c>AIS</c>
<c>Alarm Indication Signal</c>
<c>BFD</c>
<c>Bidirectional Forwarding Detection</c>
<c>CC-V</c>
<c>Continuity Check and Connectivity Verification</c>
<c>FM</c>
<c>Fault Management</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>G-ACh Label</c>
<c>GMPLS</c>
<c>Generalized Multi-Protocol Label Switching</c>
<c>IANA</c>
<c>Internet Assigned Names Authority</c>
<c>LDI</c>
<c>Link Down Indication</c>
<c>LKR</c>
<c>Lock Report</c>
<c>LM</c>
<c>Loss Measurement</c>
<c>LOC</c>
<c>Loss of Continuity</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>MEP</c>
<c>Maintenance Entity Group End Point</c>
<c>MEG</c>
<c>Maintenance Entity Group</c>
<c>MIP</c>
<c>Maintenance Entity Group Intermediate Point</c>
<c>MPLS</c>
<c>MultiProtocol Label Switching</c>
<c>MPLS-TP</c>
<c>Transport Profile for MPLS</c>
<c>OAM</c>
<c>Operations, Administration, and Maintenance</c>
<c>PM</c>
<c>Performance Monitoring</c>
<c>PW</c>
<c>Pseudowire</c>
<c>RDI</c>
<c>Remote Defect Indication</c>
<c>SLA</c>
<c>Service Level Agreement</c>
<c>TLV</c>
<c>Type, Length, Value</c>
<c>VCCV</c>
<c>Virtual Circuit Connectivity Verification</c>
</texttable>
</section>
</section>
<section title="Basic OAM Infrastructure Functionality">
<t></t>
<t><xref target="MPLS-TP OAM Reqs"></xref> defines a set of requirements
on OAM architecture and general principles of operations, which are
evaluated below:</t>
<t><xref target="MPLS-TP OAM Reqs"></xref> requires that —
<list style="symbols">
<t>OAM mechanisms in MPLS-TP are independent of the transmission media
and of the client service being emulated by the PW.</t>
<t>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 the MPLS-TP OAM toolset should rely on the IP routing
and forwarding 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.</t>
<t>all OAM protocols support identification information, at least in
the form of IP addressing structure and be extensible to support
additional identification schemes.</t>
<t>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. 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.</t>
<t>there is a single OAM solution and that OAM capabilities for LSPs,
PWs, and Sections are consistent.</t>
<t>MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-point
co-routed bidirectional LSPs, point-to-point bidirectional
Sections, point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs, and point-to-multipoint LSPs. In addition, MPLS-TP
OAM supports these LSPs and PWs when they span either a single or multiple
domains.</t>
<t>OAM packets may be directed to an intermediate point of a LSP/PW.</t>
</list></t>
<t>The following document-set addresses the basic requirements listed above:</t>
<t><list style="symbols">
<t>The <xref target="MPLS-TP OAM Frwk"></xref> document 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 Managed Entity Group, its End-points, and
Intermediate Points.</t>
<t>The <xref target="MPLS G-ACH"></xref> document specifies the use
of the MPLS-TP in-band control channels. It generalizes the applicability
of the Pseudowire (PW) Associated Channel Header (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 <xref target="PW VCCV" />. 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.</t>
<t>The creation of G-ACh and GAL provided the necessary mechanisms to allow
OAM packets 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.</t>
<t>The <xref target="MPLS TP Idents"></xref> document provides an IP-based
identifier set for MPLS-TP that can be used to identify the transport entities
in the network and referanced by the different OAM protocols. <xref target="TP-Loss-Delay-Profile"></xref>
augments that set of identifiers to include identifier information in a format
used by the ITU-T. Other spaces may be deifned as well.</t>
</list></t>
</section>
<section title="MPLS-TP OAM Functions">
<t>The following sections discuss the OAM functions that are required in
<xref target="MPLS-TP OAM Reqs"></xref> and expanded upon in <xref
target="MPLS-TP OAM Frwk"></xref>.</t>
<section title="Continuity Check and Connectivity Verification">
<t>Continuity Check and Connectivity Verification (CC-V) 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. Proactively <xref target="MPLS-TP OAM Reqs"></xref>
states that the function should allow the MEPs to 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,
in addition, between a MEP and MIP. Note that as specified in sections 3.3
and 3.4 of [MPLS-TP OAM Frwk], 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.</t>
<t>The <xref target="MPLS-TP OAM Frwk"></xref> highlights the need for the
CC-V 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.</t>
<section title="Documents for CC-V tools">
<t><xref target="Pro CC-V"></xref> defines BFD extensions to support proactive
CC-V applications.</t>
<t><xref target="Demand CV"></xref> provides LSP-Ping extensions that
are used to implement on-demand Connectivity Verification.</t>
<t>Both of these tools will be used within the framework of the basic tools
described above, in section 2.</t>
</section>
</section>
<section title="Remote Defect Indication">
<t>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 end-point. <xref
target="MPLS-TP OAM Reqs" /> points out that this function may be applied to a
unidirectional LSP only if a return path exists. <xref target="MPLS-TP OAM Frwk">
</xref> points out that this function is associated with the proactive CC-V function.</t>
<section title="Documents for RDI">
<t>The <xref target="Pro CC-V"></xref> document includes an extension for BFD
that would include the RDI indication in the BFD format, and a specification of
how this indication is to be used.</t>
</section>
</section>
<section title="Route Tracing">
<t><xref target="MPLS-TP OAM Reqs"></xref> defines that there is a need for
functionality that would allow a path end-point to identify the intermediate (if
any) and end-points of 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.</t>
<section title="Documents for Route Tracing">
<t>The <xref target="Demand CV"></xref> document that specifies the LSP-Ping
enhancements for MPLS-TP on-demand Connectivity Verification includes
information on the use of LSP-Ping for route tracing of a MPLS-TP transport
path.</t>
</section>
</section>
<section title="Alarm Reporting">
<t>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 the end-points of
the path. <xref target="MPLS-TP OAM Frwk"></xref> 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 <xref
target="MPLS-TP OAM Frwk"></xref>.</t>
<section title="Documents for Alarm Reporting">
<t>MPLS-TP defines a new protocol to address this functionality that is documented
in <xref target="Fault Mng"></xref>. This protocol uses all of the basic
mechanisms detailed in Section 2.</t>
</section>
</section>
<section title="Lock Instruct">
<t>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 <xref target="MPLS-TP OAM Frwk"></xref>. This function is used on-demand.</t>
<section title="Documents for Lock Instruct">
<t>The <xref target="LiLoopback"></xref> document describes the details of a
new ACH based protocol format for this functionality.</t>
</section>
</section>
<section title="Lock Reporting">
<t>Lock reporting, defined in <xref target="MPLS-TP OAM Reqs"></xref>,
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 this transport path.</t>
<section title="Documents for Lock Reporting">
<t>MPLS-TP defines a new protocol to address this functionality that
is documented in <xref target="Fault Mng"></xref>. This protocol
uses all of the basic mechanisms detailed in Section 2.</t>
</section>
</section>
<section title="Diagnostic">
<t>The <xref target="MPLS-TP OAM Reqs"></xref> indicates that there is need
to provide a OAM function that would enable conducting different diagnostic
tests on a PW, LSP, or Section. The <xref target="MPLS-TP OAM Frwk"></xref>
provides two types of specific tests to be used through this functionality:</t>
<t><list style="symbols">
<t>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.</t>
<t>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 bi-directional path is
required.</t>
</list></t>
<section title="Documents for Diagnostic Testing">
<t>The <xref target="LiLoopback"></xref> document describes the details of a
new ACH based protocol format for the Data-plane loopback functionality.</t>
<t>The tool for Throughput Estimation tool is under study.</t>
</section>
</section>
<section title="Packet Loss Measurement">
<t>Packet Loss Measurement is required by <xref target="MPLS-TP OAM Reqs">
</xref> 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 function, <xref
target="MPLS-TP OAM Frwk"></xref> 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 that result from various issues.</t>
<section title="Documents for Packet Loss Measurement">
<t>The <xref target="Loss-Delay"></xref> document describes the protocol formats
and procedures for using the tool and enable efficient and accurate measurement of
packet loss, delay, and throughput in MPLS networks. <xref target="TP-Loss-Delay-Profile"></xref>
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 <xref target="Y.1731"></xref>.</t>
</section>
</section>
<section title="Packet Delay Measurement">
<t>Packet Delay Measurement is a function that is used to measure one-way or
two-way delay of a packet transmission between a pair of the end-points of a path
(PW, LSP, or Section), as described in <xref target="MPLS-TP OAM Reqs"></xref>.
Where:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t><xref target="MPLS-TP OAM Frwk"></xref> describes how the tool
could be performed (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.</t>
<section title="Documents for Delay Measurement">
<t>The <xref target="Loss-Delay"></xref> document describes the protocol formats
and procedures for using the tool and enable efficient and accurate measurement of
packet loss, delay, and throughput in MPLS networks. <xref target="TP-Loss-Delay-Profile"></xref>
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 <xref target="Y.1731"></xref>.</t>
</section>
</section>
</section>
<section title="MPLS-TP OAM documents guide">
<t>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 (IETF RFCs or Internet
drafts while this document is work in progress) for the initial phase of the
specification of MPLS based transport networks is provided below.</t>
<note title="Editor's note:">
<t>Only RFCs will be referenced in the final version of the document.</t>
</note>
<t><xref target="MPLS G-ACH" /> provides a specification of the basic structure
of protocol messages for in-band data plane OAM in an MPLS environment.</t>
<t><xref target="MPLS TP Idents" /> provides definitions of different formats
that may be used within OAM protocol messages to identify the network elements
of a MPLS based transport network.</t>
<t>The following table (Table 1) provides the summary of proactive MPLS-TP OAM Fault
Management toolset functions, associated tool/protocol, and the corresponding IETF RFCs or
Internet drafts where they are defined.</t>
<texttable anchor="Proactive Fault Management OAM Toolset" style="all">
<ttcol align="left">OAM Functions</ttcol>
<ttcol align="left">OAM Tools/Protocols</ttcol>
<ttcol align="left">RFCs / Internet Drafts</ttcol>
<c>Continuity Check and Connectivity Verification</c>
<c>Bidirectional Forwarding Detection (BFD)</c>
<c><xref target="Pro CC-V" /></c>
<c>Remote Defect Indication (RDI)</c>
<c>Flag in Bidirectional Forwarding Detection (BFD) message</c>
<c><xref target="Pro CC-V" /></c>
<c>Alarm Indication Signal (AIS)</c>
<c>G-ACh bases AIS message</c>
<c><xref target="Fault Mng" /></c>
<c>Link Down Indication (LDI)</c>
<c>Flag in AIS message</c>
<c><xref target="Fault Mng" /></c>
<c>Lock Reporting (LKR)</c>
<c>G-ACh bases LKR message</c>
<c><xref target="Fault Mng" /></c>
<postamble>Proactive Fault Management OAM Toolset</postamble>
</texttable>
<t>The following table (Table 2) provides an overview of the on-demand MPLS-TP OAM Fault
Management toolset functions, associated tool/protocol, and the corresponding IETF RFCs or
Internet drafts where they are defined.</t>
<texttable anchor="On Demand Fault Management OAM Toolset" style="all">
<ttcol align="left">OAM Functions</ttcol>
<ttcol align="left">OAM Tools/Protocols</ttcol>
<ttcol align="left">RFCs / Internet Drafts</ttcol>
<c>Connectivity Verification</c>
<c>LSP Ping</c>
<c><xref target="Demand CV" /></c>
<c>Diagnostic: Loopback and Lock Instruct</c>
<c>(1) G-ACh based Loopback and Lock Instruct, (2) LSP Ping</c>
<c><xref target="LiLoopback" /></c>
<c>Lock Instruct(LI)</c>
<c>Flag in AIS message</c>
<c><xref target="Fault Mng" /></c>
<postamble>On Demand Fault Management OAM Toolset</postamble>
</texttable>
<t>The following table (Table 3) provides the Performance Monitoring
Fuctions, asscociated tool/protocol definitions, and corresponding RFCs or
Internet Drafts.</t>
<texttable anchor="Performance Monitoring OAM Toolset" style="all">
<ttcol align="left">OAM Functions</ttcol>
<ttcol align="left">OAM Tools/Protocols</ttcol>
<ttcol align="left">RFCs / Internet Drafts</ttcol>
<c>Packet Loss Measurement (LM)</c>
<c>G-ACh based LM & DM query messages</c>
<c><xref target="Loss-Delay" /> <xref target="TP-Loss-Delay-Profile" /></c>
<c>Packet Delay Measurement (DM)</c>
<c>G-ACh based LM & DM query messages</c>
<c><xref target="Loss-Delay" /> <xref target="TP-Loss-Delay-Profile" /></c>
<c>Throughput Measurement</c>
<c>derived from Loss Measurement</c>
<c><xref target="Loss-Delay" /> <xref target="TP-Loss-Delay-Profile" /></c>
<c>Delay Variation Measurement</c>
<c>derived from Delay Measurement</c>
<c><xref target="Loss-Delay" /> <xref target="TP-Loss-Delay-Profile" /></c>
<postamble>Performance Monitoring OAM Toolset</postamble>
</texttable>
</section>
<section title="OAM Toolset Applicability and Utilization">
<t>The following subsections present the MPLS-TP OAM toolset from the perspective
of the specified protocols and identifies which of the required functionality is
supported by the particular protocol.</t>
<section title="Connectivity Check and Connectivity Verification">
<t>Proactive Continuity Check and Connectivity Verification (CC-V)
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-V tools.</t>
<t>The CC-V tools are used to support MPLS-TP fault management, performance
management, and protection switching. Proactive CC-V control packets are sent
by the source MEP to sink MEP. The sink MEP monitors the arrival of the CC-V
control packets and detects the defect. For bidirectional transport paths, the
CC-V protocol is, usually, transmitted simultaneously in both directions.</t>
<t>The transmission interval of CC-V control packet can be configured. For example:</t>
<t><list style="symbols">
<t>3.3ms is the default interval for protection switching.</t>
<t>100ms is the default interval for performance monitoring.</t>
<t>1s is the default interval for fault management.</t>
</list></t>
</section>
<section title="Diagnostic Tests and Lock Instruct">
<t><xref target="LiLoopback" /> describes a protocol that provides a mechanism is
provided 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 loop back of the traffic to the source.</t>
<t>These diagnostic functions apply to associated bidirectional MPLS-TP
LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which is relevant
for MPLS-TP dynamic control plane option with GMPLS), and single segment
and multi-segment pseudowires.</t>
<t>The Lock operation instruction is carried in an MPLS Loopback request
message sent from a MEP to a trail-end MEP of the LSP to request that the
LSP be taken out of service. In response, the Lock operation reply is
carried in a Loopback response message sent from the trail-end MEP back to
the originating MEP to report the result.</t>
<t>The loopback operations include:</t>
<t><list style="symbols">
<t>Lock: take an LSP out of service for maintenance.</t>
<t>Unlock: Restore a previously locked LSP to service.</t>
<t>Set_Full_Loopback and Set_OAM_Loopback</t>
<t>Unset_Full_Loopback and Set_OAM_Loopback</t>
</list></t>
<t>Operators can use the loopback mode to test the connectivity or performance
(loss, delay, delay variation, and throughput) of given LSP up to a specific node
on the path of the LSP.</t>
</section>
<section title="Lock Reporting">
<t>The Lock Report (LKR) function is used to communicate to the client (sub-) layer
MEPs the administrative locking of a server (sub-) layer MEP, and consequential
interruption of data traffic forwarding in the client (sub-) layer.</t>
<t>When operator is taking the LSP out of service for maintenance or other operational
reason, using the LKR function can help to distinguish the condition as administrative
locking from defect condition.</t>
<t>The Lock Report function would 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 loss of continuity at the client
layer.</t>
</section>
<section title="Alarm Reporting and Link Down Indication">
<t>Alarm Indication Signal (AIS) message serves the purpose of alarm suppression
upon the failure detection in the server (-sub) layer. When the Link Down
Indication (RDI) is set, the AIS message MAY be used to trigger recovery
mechanisms. </t>
<t>When a server MEP detects the failure, it asserts Loss of Continuity (LOC) or
signal fail which sets the flag up to generate OAM packet with AIS message. The
AIS message is forwarded to downstream sink MEP in the client layer. This would
enable the client layer to suppress the generation of secondary alarms.</t>
<t>A Link Down Indication (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.</t>
<t>Fault OAM messages are generated by intermediate nodes where an LSP is switched,
and propagated to the end points (MEPs).</t>
<t>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.</t>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) function enables an End Point to report to the other
End Point that a fault or defect condition is detected on the PW, LSP, or Section for which
they are the End Points.</t>
<t>The RDI OAM function is supported by the use of Bidirectional Forwarding Detection (BFD)
Control Packets [cc-cv]. RDI is only used for bidirectional connections and is associated
with proactive CC-V activation.</t>
<t>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, and transmitting the BFD
control packet with the failure flag up to the other end point (its peer MEP).</t>
<t>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.</t>
</section>
<section title="Packet Loss and Delay Measurement">
<t>The packet loss and delay measurement toolset enables operators to measure the quality
of the packet transmission over a PW, LSP, or Section.</t>
<t>The loss and delay protocols have the following characteristics and capabilities:</t>
<t><list style="symbols">
<t>They support measurement of packet loss, delay and throughput over Label Switched
Paths (LSPs), pseudowires, and MPLS sections.</t>
<t>The same LM and DM protocols can be used for both continuous/proactive and
selective/on-demand measurement.</t>
<t>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.</t>
<t>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.</t>
<t>The LM and DM protocols do not require that the transmit and receive
interfaces be the same when performing bidirectional measurement.</t>
<t>The LM protocol supports both 32-bit and 64-bit counters although for simplicity
only 32-bit packet counters are currently included in the MPLS-TP profile.</t>
<t>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.</t>
<t>The LM protocol can be used to measure channel throughput as well as packet
loss.</t>
<t>The DM protocol supports varying the measurement message size in order to
measure delays associated with different packet sizes.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>The OAM tools and functions defined under G-ACh use IANA assigned code points.
the codes are defined in the corresponding IETF RFCs</t>
<note title="Note to RFC Editor:">
<t>this section may be removed on publication as an RFC.</t>
</note>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations. Security considerations for each function in the
OAM toolset need to be documented in the document that specifies
the particular functionality.</t>
<t>The general security considerations are provided in
<xref target="MPLS and GMPLS Security Frwk" />
and <xref target="MPLS-TP Security Frwk" />.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The discussion on the needed OAM toolset took place, mainly, in the MPLS
Interoperability Design Team (the MEAD). A toolset was agreed upon and was
reported to the MPLS working group in Stockholm (July 2009) during the IETF (#75)
meetings. This was also judged to be the working group consensus.</t>
<t>The editors wish to thank the MPLS-TP Design Team members, from both
the IETF and ITU-T leadership teams, in formulating the recommendations
documented here. In particular, we would like to thank Loa Andersson,
Huub van Helvoort, and the Area Directors for their suggestions and
enhancements to the text.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--Begin inclusion reference.RFC.4379 -->
<reference anchor="LSP Ping">
<front>
<title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures</title>
<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4379" />
<format octets="116872"
target="ftp://ftp.isi.edu/in-notes/rfc4379.txt" type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4379 -->
<!-- Begin inclusion reference.RFC.4385 -->
<reference anchor="PW ACH">
<front>
<title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN</title>
<author fullname="S. Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="L. Martini" initials="L." surname="Martini">
<organization></organization>
</author>
<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization></organization>
</author>
<date month="February" year="2006" />
</front>
<seriesInfo name="RFC" value="4385" />
<format octets="22440" target="ftp://ftp.isi.edu/in-notes/rfc4385.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4385 -->
<!-- Begin inclusion reference.RFC.5085 -->
<reference anchor="PW VCCV">
<front>
<title>Pseudowire Virtual Circuit Connectivity Verification (VCCV):
A Control Channel for Pseudowires</title>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="December" year="2007" />
<abstract>
<t>This document describes Virtual Circuit Connectivity
Verification (VCCV), which provides a control channel that is
associated with a pseudowire (PW), as well as the corresponding
operations and management functions (such as connectivity
verification) to be used over that control channel. VCCV applies
to all supported access circuit and transport types currently
defined for PWs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5085" />
<format octets="67847" target="ftp://ftp.isi.edu/in-notes/rfc5085.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.RFC.5586-->
<reference anchor="MPLS G-ACH">
<front>
<title>MPLS Generic Associated Channel</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
<seriesInfo name="RFC" value="5586" />
</reference>
<!-- End inclusion reference.RFC.5586 -->
<!-- Begin inclusion reference.RFC.5654 -->
<reference anchor="MPLS-TP Reqs">
<front>
<title>Requirements for the Transport Profile of MPLS</title>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="RFC" value="5654" />
</reference>
<!-- End inclusion reference.RFC.5654 -->
<!-- Begin inclusion reference.RFC.5860 -->
<reference anchor="MPLS-TP OAM Reqs">
<front>
<title>Requirements for OAM in MPLS Transport Networks</title>
<author fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<author fullname="Malcolm Betts" initials="M." surname="Betts">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="RFC" value="5860" />
<format octets="116872"
target="ftp://ftp.isi.edu/in-notes/rfc5860.txt" type="TXT" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<!-- Begin inclusion reference.draft.BASE.BFD -->
<reference anchor="BASE BFD">
<front>
<title>Bidirectional Forwarding Detection</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization></organization>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="February" year="2009" />
</front>
<seriesInfo name="RFC" value="5880" />
</reference>
<!-- End inclusion reference.draft.BASE.BFD -->
<!-- Begin inclusion reference.draft.MPLS.BFD -->
<reference anchor="MPLS BFD">
<front>
<title>BFD For MPLS LSPs</title>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Kiretti Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="Thomas Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="June" year="2008" />
</front>
<seriesInfo name="RFC" value="5884" />
</reference>
<!-- End inclusion reference.draft.MPLS.BFD -->
<!-- Begin inclusion reference.RFC.6370 -->
<reference anchor="MPLS TP Idents">
<front>
<title>MPLS-TP Identifiers</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="Eric Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6370" />
</reference>
<!-- End inclusion reference.RFC.6370 -->
<!-- Begin inclusion reference.RFC.6371 -->
<reference anchor="MPLS-TP OAM Frwk">
<front>
<title>MPLS-TP OAM Framework and Overview</title>
<author fullname="Italo Busi" initials="I." surname="Busi">
<organization></organization>
</author>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="David Allan" initials="D." surname="Allan">
<organization></organization>
</author>
<date month="September" year="2011" />
<abstract>
<t>Multi-Protocol Label Switching (MPLS) Transport Profile
(MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW)
procedures as specified in the MPLS Traffic Engineering (MPLS-TE),
Pseudowire (PW) and multi-segment PW (MS-PW) architectures
complemented with additional Operations, Administration and
Maintenance (OAM) procedures for fault, performance and
protection-switching management for packet transport applications
that do not rely on the presence of a control plane. This document
provides a framework that supports a comprehensive set of OAM
procedures that fulfills the MPLS-TP OAM requirements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6371" />
</reference>
<!-- End inclusion reference.RFC.6371 -->
<!-- Begin inclusion reference.RFC.6374 -->
<reference anchor="Loss-Delay">
<front>
<title>Packet Loss and Delay Measurement for MPLS Networks</title>
<author fullname="Dan Frost" initials="D." surname="Frost">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6374" />
</reference>
<!-- End inclusion reference.RFC.6374 -->
<!-- Begin inclusion reference.RFC.6375 -->
<reference anchor="TP-Loss-Delay-Profile">
<front>
<title>A Packet Loss and Delay Measurement Profile for MPLS-based
Transport Networks</title>
<author fullname="Dan Frost" initials="D." surname="Frost">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6375" />
</reference>
<!-- End inclusion reference.RFC.6375 -->
<!-- Begin inclusion reference.draft.Proactive.CCV -->
<reference anchor="Pro CC-V">
<front>
<title>Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile</title>
<author fullname="David Allan" initials="D." surname="Allan">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="August" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-cc-cv-rdi-06" />
</reference>
<!-- End inclusion reference.draft.Proactive-ccv -->
<!-- Begin inclusion reference.draft.OnDemand.CV -->
<reference anchor="Demand CV">
<front>
<title>MPLS on-demand Connectivity Verification, Route Tracing and
Adjacency Verification</title>
<author fullname="Nitin Bahadur" initials="N." surname="Bahadur">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Eric Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="August" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-on-demand-cv-06" />
</reference>
<!-- End inclusion reference.draft.OnDemand.CV -->
<!-- Begin inclusion reference.draft.Fault.Manage -->
<reference anchor="Fault Mng">
<front>
<title>MPLS Fault Management OAM</title>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="Annamaria Fulignoli" initials="A."
surname="Fulignoli">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-fault-07" />
</reference>
<!-- End inclusion reference.draft.Fault.Manage -->
<!-- Begin inclusion reference.draft.Admin.Commands -->
<reference anchor="LiLoopback">
<front>
<title>MPLS Transport Profile Lock Instruct and Loopback Functions</title>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M." surname="Vigoureux">
<organization></organization>
</author>
<author fullname="Xuehui Dai" initials="X." surname="Dai">
<organization></organization>
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-li-lb-05" />
</reference>
<!-- End inclusion reference.Admin.Commands -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.draft.MPLS.TP.Security.Fwk -->
<reference anchor="MPLS-TP Security Frwk">
<front>
<title>MPLS-TP Security Framework</title>
<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization></organization>
</author>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="Scott Mansfield" initials="S." surname="Mansfield">
<organization></organization>
</author>
<date month="May" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-security-framework-01" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Security.Framework -->
<!-- Begin inclusion reference.RFC.5920 -->
<reference anchor="MPLS and GMPLS Security Frwk">
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization></organization>
</author>
<date month="July" year="2010" />
</front>
<seriesInfo name="RFC" value="5920" />
</reference>
<!-- End inclusion reference.RFC.5920 -->
<!--Begin inclusion reference.ITU.Y1731 -->
<reference anchor="Y.1731">
<front>
<title>OAM functions and mechanisms for Ethernet based
networks</title>
<author>
<organization abbrev="ITU-T">International Telecommunications
Union - Standardization</organization>
</author>
<date month="May" year="2006" />
</front>
<seriesInfo name="ITU" value="Y.1731" />
</reference>
<!-- End inclusion reference.ITU.Y1731 -->
<!-- Begin inclusion reference.draft.TP.ITU.Identifiers -->
<reference anchor="MPLS TP ITU Idents">
<front>
<title>MPLS-TP Identifiers Following ITU-T Conventions</title>
<author fullname="R Winter" initials="R." surname="Winter">
<organization></organization>
</author>
<author fullname="Huub van Helvoort" initials="H." surname="van Helvoort">
<organization></organization>
</author>
<author fullname="Malcolm Betts" initials="M." surname="Betts">
<organization></organization>
</author>
<date month="July" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-itu-t-identifiers-00" />
</reference>
<!-- End inclusion reference.draft.TP.ITU.Identifiers -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:53:09 |