One document matched: draft-sprecher-mpls-tp-oam-analysis-04.xml
<?xml version="1.0"?>
<!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-sprecher-mpls-tp-oam-analysis-04.txt"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP OAM Analysis">MPLS-TP OAM Analysis</title>
<author fullname="Nurit Sprecher" initials="N." role="editor" surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Tom Nadeau" initials="T." role="editor"
surname="Nadeau">
<organization>BT</organization>
<address>
<postal>
<street />
<region />
<code />
<country>United States</country>
</postal>
<email>tom.nadeau@bt.com</email>
</address>
</author>
<author fullname="Huub van Helvoort" initials="H." role="editor" surname="van Helvoort">
<organization>Huawei</organization>
<address>
<postal>
<street>Kolkgriend 38, 1356 BC Almere</street>
<city></city>
<region />
<code></code>
<country>Netherlands</country>
</postal>
<email>hhelvoort@huawei.com</email>
<phone>+31 36 5316076</phone>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y." role="" surname="Weingarten">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>yaacov.weingarten@nsn.com</email>
<phone>+972-9-775 1827</phone>
</address>
</author>
<date day="10" month="May" year="2009" />
<abstract>
<t>The intention of this document is to analyze the set of
requirements for Operations, Administration, and Maintenance (OAM) for the
Transport Profile of MPLS(MPLS-TP) as defined in <xref target="MPLS-TP OAM Reqs"/>,
to evaluate whether existing OAM tools (either from the current MPLS toolset
or from the ITU-T documents) can be applied to these requirements. Eventually,
the purpose of the document is to recommend which of the existing tools should
be extended and what new tools should be defined to support the set of OAM
requirements for MPLS-TP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>OAM (Operations, Administration, and Maintenance) plays a significant
and fundamental 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"/> in general, and <xref target="MPLS-TP OAM Reqs"/>
in particular define a set of requirements for OAM functionality in MPLS-Transport
Profile (MPLS-TP) for MPLS-TP Label Switched Paths (LSPs) (network infrastructure)
and Pseudowires (PWs) (services).</t>
<t>The purpose of this document is to analyze the OAM requirements and
evaluate whether existing OAM tools defined for MPLS can be used to
meet the requirements, identify which tools need to be extended to
comply with the requirements, and which new tools need to be defined. We also
take the ITU-T OAM toolset, as defined in <xref target="Y.1731"/>, as a candidate to base
these new tools upon. The existing tools that are evaluated include LSP Ping
(defined in <xref target="LSP Ping"/>), MPLS Bi-directional Forwarding Detection (BFD)
(defined in <xref target="MPLS BFD"/>) and Virtual Circuit Connectivity Verification
(VCCV) (defined in <xref target="PW VCCV"/> and <xref target="VCCV BFD"/>), and the
ITU-T OAM toolset defined in <xref target="Y.1731"/>.</t>
<section title="LSP Ping">
<t>LSP Ping is a variation of ICMP Ping and traceroute <xref target="ICMP" />] adapted to
the different needs of MPLS LSP. Forwarding, of the LSP Ping packets, is
based upon the LSP Label and label stack, in order to guarantee that the
echo messages are switched in-band (i.e. over the same data route) of the LSP.
However, it should be noted that the messages are transmitted using IP/UDP
encapsulation and IP addresses in the 127/8 (loopback) range. The use of
the loopback range guarantees that the LSP Ping messages will be terminated,
by a loss of connectivity or inability to continue on the path, without being
transmitted beyond the LSP. The return message of the LSP Ping could be sent
either on the return LSP of a corouted bidirectional LSP, or for associated
bidirectional LSPs or unidirectional LSPs may be sent using IP forwarding to the
IP address of the LSP ingress node.</t>
<t>LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity and
continuity check) with functionality to verify data-plane vs. control-plane
consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission
Unit (MTU) problems. The traceroute functionality may be used to isolate and localize
the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the
sub-path of the LSP that is succesfully traversed before the faulty link or node. LSP
Ping is not dependent on the MPLS control-plane for its operation, i.e. even though the
propagation of the LSP label may be performed over the control-plane via the Label
Distribution Protocol (LDP).</t>
<t>LSP Ping can be activated both in on-demand and pro-active (asynchronous)
modes, as defined in <xref target="MPLS-TP OAM Reqs" />. </t>
<t><xref target="P2MP LSP Ping" /> clarifies the applicability of LSP Ping to MPLS P2MP
LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS
P2MP environment.</t>
<t><xref target="MPLS LSP Ping" /> extends LSP Ping to operate over MPLS
tunnels or for a stitched LSP.</t>
<t>As pointed out above, TTL exhaust is the method used to terminate flows at
intermediate LSRs, usually to locate a problem that was discovered previously.</t>
<t>Some of the drawbacks identified with LSP Ping include - LSP Ping is considered
to be computational intensive as pointed out in <xref target="MPLS BFD" />. Use of
the loopback address range (to protect against leakage outside the LSP) assumes that
all of the intermediate nodes support some IP functionality. When LSP bundling is
employed in the network, there is no guarantee that the LSP Ping packets will
follow the same physical path used by the data traffic.</t>
</section>
<section title="MPLS BFD">
<t>BFD (Bidirectional Forwarding Detection) is a mechanism that is defined
for fast fault detection for point-to-point connections. BFD defines a simple packet
that may be transmitted over any protocol, dependent on the application that is
employing the mechanism. BFD is dependent upon creation of a session that
is agreed upon by both ends of the link (which may be a single link, LSP,
etc.) that is being checked. The session is assigned a separate identifier by each
end of the path being monitored. This session identifier is by nature only unique
within the context of node that assigned it. As part of the session creation, the
end-points negotiate an agreed transmission rate for the BFD packets. BFD supports an
echo function to check the continuity, and verify the reachability of the desired
destination. BFD does not support neither a discovery mechanism nor a traceroute
capability for fault localization, these must be provided by use of other mechanisms.
The BFD packets support authentication between the routers being checked.</t>
<t>BFD can be used in pro-active (asynchronous) and on-demand modes, as defined
in <xref target="MPLS-TP OAM Reqs" />, of operation.</t>
<t><xref target="MPLS BFD" /> defines the use of BFD for P2P LSP end-points and is used to
verify data-plane continuity. It uses a simple hello protocol which can be
easily implemented in hardware. The end-points of the LSP exchange hello packets
at negotiated regular intervals and an end-point is declared down when expected
hello packets do not show up. Failures in each direction can be monitored
independently using the same BFD session. The use of the BFD echo function and
on-demand activation are outside the scope of the MPLS BFD specification.</t>
<t>The BFD session mechanism requires an additional (external) mechanism to
bootstrap and bind the session to a particular LSP or FEC. LSP Ping is designated
by <xref target="MPLS BFD" /> as the bootstrap mechanism for the BFD session in an
MPLS environment. The implication is that the session establishment BFD messages for
MPLS are transmitted using a IP/UDP encapsulation.</t>
<t>In order to be able to identify certain extreme cases of mis-connectivity, it is
necessary that each managed connection have its own unique identifiers. BFD uses
Discriminator values to identify the connection being verified, at both ends of the path.
These discriminator values are set by each end-node to be unique only in the context of
that node. This limited scope of uniqueness would not identify a misconnection of crossing
paths that could assign the same discriminators to the different sessions.</t>
</section>
<section title="PW VCCV">
<t>PW VCCV provides end-to-end fault detection and diagnostics for PWs
(regardless of the underlying tunneling technology). The VCCV switching function
provides a control channel associated with each PW (based on the PW Associated
Channel Header (ACH) which is defined in <xref target="PW ACH" />), and allows
sending OAM packets in-band with PW data (using CC Type 1: In-band VCCV)</t>
<t>VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD.
ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for
VCCV supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP
header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to
signal the AC status. The use of the VCCV control channel provides the context,
based on the MPLS-PW label, required to bind and bootstrap the BFD session to a
particular pseudo wire (FEC), eliminating the need to exchange Discriminator values.</t>
<t>VCCV consists of two components: (1) signaled component to communicate
VCCV capabilities as part of VC label, and (2) switching component to cause
the PW payload to be treated as a control packet.</t>
<t> VCCV is not directly dependent upon the presence of a control plane.
The VCCV capability negotiation may be performed as part of the PW signaling when LDP is used.
In case of manual configuration of the PW, it is the responsibility of the operator
to set consistent options at both ends. </t>
</section>
<section title="ITU Recommendation Y.1731">
<t><xref target="Y.1731"/> specifies a set of OAM procedures and related packet data
unit (PDU) formats that meet the transport network requirements for OAM. These PDU
and procedures address similar requirements to those outlined in
<xref target="MPLS-TP OAM Reqs" />.</t>
<t>The PDU and procedures are described relative to an Ethernet environment, with the
appropriate encapsulation for that environment. However, the actual PDU formats are
technology agnostic and could be carried over different encapsulations, e.g. VCCV control
channel. The OAM procedures, likewise, could be supported by MPLS-TP nodes just as they are
supported by Ethernet nodes.</t>
<t><xref target="Y.1731"/> describes procedures to support the following OAM functions:</t>
<t>
<list style="symbols">
<t>Connectivity and Continuity Monitoring – for end-to-end checking</t>
<t>Loopback functionality – to verify connectivity to intermediate nodes</t>
<t>Link trace – provides information on the intermediate nodes of the path
being monitored, may be used for fault localization.</t>
<t>Alarm indication signaling – for alarm suppression in case of faults
that are detected at the server layer.</t>
<t>Remote defect indication &ndash as part of the Connectivity and Continuity Monitoring
packets</t>
<t>Performance monitoring – including measurement of packet delays both uni and
bi-directional, measurement of the ratio of lost packets, and the effective bandwidth that
is supported without packet loss.</t>
</list> </t>
<t>It should be noted that the PDU defined in <xref target="Y.1731"/> includes various
information elements (fields) that may not be defined in [MPLS-TP OAM Framework]. These
fields include information on the MEG-Level, OpCode, and version. Addressing of the PDU
as defined in <xref target="Y.1731"/> is based on the MAC Address of the nodes, which
would need to be adjusted to support other addressing schemes, length of additional
information. The addressing information is carried in <Type, Length, Value> (TLV)
fields that follow the actual PDU.</t>
</section>
<section title="Acronyms">
<texttable>
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"/>
<ttcol align="left"/>
<c>AC</c><c>Attachment Circuit</c>
<c>ACH</c><c>Associated Channel Header</c>
<c>BFD</c><c>Bidirectional Forwarding Detection</c>
<c>CC-V</c><c>Continuity Check and Connectivity Verification</c>
<c>FEC</c><c>Forwarding Equivalence Class</c>
<c>LDP</c><c>Label Distribution Protocol</c>
<c>LSP</c><c>Label Switched Path</c>
<c>ME</c><c>Maintenance Entitity</c>
<c>MEP</c><c>Maintenance End Point</c>
<c>MIP</c><c>Maintenance Intermediate Point</c>
<c>MPLS-TP</c><c>Transport Profile for MPLS</c>
<c>OAM</c><c>Operations, Administration, and Maintenance</c>
<c>PDU</c><c>Packet Data Unit</c>
<c>PW</c><c>Pseudowire</c>
<c>RDI</c><c>Remote Defect Indication</c>
<c>SLA</c><c>Service Level Agreement</c>
<c>TC</c><c>Tandem Connection</c>
<c>TCME</c><c>Tandem Connection Maintenance Entity</c>
<c>TTL</c><c>Time-to-live</c>
<c>VCCV</c><c>Virtual Circuit Connectivity Verification</c>
<c>VPCV</c><c>Virtual Path Connectivity Verification</c>
</texttable>
</section>
<section title="Organization of the document">
<t>Section 2 of the document analyzes the requirements that are documented in
<xref target="MPLS-TP OAM Reqs" /> and provides basic principles of operation for the OAM
functionality that is required.</t>
<t>Section 3 evaluates which existing tools can provide coverage for the different OAM
functions that are required to support MPLS-TP.</t>
<t>Section 4 provides recommendations on what functionality could be covered by the
existing toolset and what extensions or new tools would be needed in order to provide
full coverage of the OAM functionality for MPLS-TP.</t>
</section>
</section>
<section title="Architectural requirements and general principles of operation">
<t />
<t><xref target="MPLS-TP OAM Reqs" /> defines a set of requirements on OAM architecture
and general principles of operations which are evaluated below:</t>
<t>
<list style="symbols">
<t><xref target="MPLS-TP OAM Reqs" /> requires that OAM mechanisms in MPLS-TP
are independent of the transmission media and of the client service
being emulated by the PW. The existing tools comply with this
requirement.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires that MPLS-TP OAM MUST be able
to operate without IP functionality and without relying on control
and/or management planes. It is required that OAM functionality MUST
NOT be dependent on IP routing and forwarding capabilities. The
existing tools do not rely on control and/or management plane, however
the following should be observed regarding the reliance on IP functionality:</t>
<list style="symbols">
<t>LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header (UDP/IP)
and do not comply with the requirement. In the on-demand mode, LSP Ping also
uses IP forwarding to reply back to the source router. This dependence on
IP, has further implications concerning the use of LSP Ping as the
bootstrap mechanism for BFD for MPLS.</t>
<t>VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
for PWs and can comply with the requirement.</t>
<t>Y.1731 PDU are technology agnostic and thereby not dependent on IP functionality.
These PDU could be carried by a VCCV control channel.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires that OAM tools for fault
management do not rely on user traffic, and the existing MPLS OAM
tools and Y.1731 already comply with this requirement. </t>
<t> It is also required that 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 ones. </t>
<list style="symbols">
<t>For PWs, VCCV provides a control channel that can be associated with each
PW which allows sending OAM packets in band of PWs and allow the
receiving end-point to intercept, interpret, and process them
locally as OAM messages. VCCV defines different VCCV Connectivity
Verification Types for MPLS (like ICMP Ping, LSP Ping and IP/UDP
encapsulated BFD and PW-ACH encapsulated BFD).</t>
<t>Currently there is no distinct OAM payload identifier in MPLS
shim. BFD and LSP Ping packets for LSPs are carried over UDP/IP
and are addressed to the loopback address range. The router at
the end-point intercepts, interprets, and processes the packets.</t>
<t>The Y.1731 PDU could be carried over a control channel defined along the
data path and the processing of the PDU would occur at the destination indicated
in the PDU.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires that the MPLS-TP OAM mechanism
allows the propagation of AC (Attachment Circuit) failures and their
clearance across a MPLS-TP domain</t>
<list style="symbols">
<t>BFD for VCCV supports a mechanism for "Fault detection and
AC/PW Fault status signaling." This can be used for both IP/UDP
encapsulated or PW-ACH encapsulated BFD sessions, i.e. by setting
the appropriate VCCV Connectivity Verification Type.This mechanism
could support this requirement.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> defines Maintenance Domain, Maintenance
End Points (MEPs) and Maintenance Intermediate Points (MIPs). Means
should be defined to provision these entities, both by static
configuration (as it is required to operate OAM in the absence of
any control plane or dynamic protocols) and by a control plane.
Note that the Y.1731 functionality currently supports these entities.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires a single OAM technology and
consistent OAM capabilities for LSPs, PWs, MPLS-TP Links, and Tandem Connections.
There is currently no mechanism in the IETF to support OAM for Tandem Connections.
Also, the existing set of tools defines a different way of operating
the OAM functions (e.g. LSP Ping to bootstrap MPLS BFD vs. VCCV). Currently, the
Y.1731 functionality is defined for Ethernet paths, and the procedures would need
to be redefined for the various MPLS-TP path concepts.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires allowing OAM packets to be
directed to an intermediate node (MIP) of a LSP/PW. Technically, this could be
supported by the proper setting of the TTL value. However, the applicability
of such a solution needs to be examined per OAM function. For details, see below.</t>
<t><xref target="MPLS-TP OAM Reqs" /> suggests that OAM messages MAY be
authenticated. BFD has a support for authentication. Other tools
should support this capability as well. Y.1731 functionality uses the
identification of the path for authentication.</t>
</list>
</t>
<section title="Architectural and Principles of Operation – Recommendations and Guidelines">
<t>Based on the requirements analysis above, the following guidelines
should be followed to create an OAM environment that could more fully
support the requirements cited:</t>
<t><list style="symbols">
<t>Extend the PW Associate Channel Header (ACH) to provide a control
channel at the path and section levels. This could then be associated
with a MPLS-TP Link, LSP, or a Tandem Connection (TC). The ACH should then
become a common mechanism for PW, LSP, MPLS-TP Link, and Tandem Connection.</t>
<t>Create a VPCV (Virtual Path Connectivity Verification) definition
that would apply the definitions and functionality of VCCV to the
MPLS-TP environment for LSP or Tandem Connection. Need a generalized addressing
scheme that can also support unique identification of the monitored paths (or
connections).</t>
<t>Create or extend the VCCV definition to define a mechanism that would
apply the definitions and functionality of VCCV to PW Tandem Connections</t>
<t>Apply BFD to these new mechanisms using the control channel
encapsulation, as defined above – allowing use of BFD for MPLS-TP
independent of IP functionality. This could be used to address the CC-V functionality</t>
<t>The Y.1731 PDU set could be used as a basis for defining the information units
to be transmitted over the VPCV. The actual procedures and addressing schemes would
need to be adjusted for the MPLS-TP environment.</t>
<t>Define a mechanism to create TCME and allow transmission
of the traffic via the Tandem Connection using label stacking.</t>
<t>Define a mechanism that could be used to address a MIP of a path in a unique
way, to support the maintenance functions. This addressing should be flexible to
allow support for different addressing schemes, and would supplement the TTL
addressing of intermediate points.</t>
</list></t>
<t>Creating these extensions/mechanisms would fulfill the following architectural
requirements, mentioned above:</t>
<t><list style="symbols">
<t>Independence of IP forwarding and routing.</t>
<t>OAM packets should be transmitted in-band.</t>
<t>Support a single OAM technology for LSP, PW, MPLS-TP Link, and TC.</t>
</list></t>
<t>In addition, the following additional requirements can be satisfied:</t>
<t><list style="symbols">
<t>Provide the ability to carry other types of communications (e.g.,
APS, Management Control Channel (MCC), Signalling Control Channel
(SCC)), by defining new types of communication channels for PWs, MPLS-TP Links,
and LSPs.</t>
<t>The design of the OAM mechanisms for MPLS-TP MUST allow the
ability to support vendor specific and experimental OAM functions.</t>
</list></t>
</section>
</section>
<section title="MPLS-TP OAM Functions">
<t>The following sections discuss the required OAM functions that were
identified in <xref target="MPLS-TP OAM Reqs" />.</t>
<t>LSP Ping is not considered a candidate to fulfill the required
functionality, due its failure to comply with the basic architectural requirement
for independence from IP routing and forwarding, as documented in Section
2 of this document. However, usage of LSP Ping, in addition to the MPLS-TP
OAM tools, or in MPLS-TP deployments with IP functionality is not
precluded.</t>
<section title="Continuity Check and Connectivity Verification">
<t>Continuity Check and Connectivity Verification (CC-V) are OAM operations
generally used in tandem, and compliment each other. Together they are used to
detect loss of traffic continuity and misconnections between
MEPs and are useful for applications like Fault Management, Performance
Monitoring and Protection Switching, etc. To guarantee that CC-V can identify
misconnections from cross-connections it is necessary that the tool use
network-wide unique identifiers for the path that is being checked in the session.</t>
<section title="Existing tools">
<t>LSP Ping provides much of the functionality required for corouted bidirectional LSPs.
As observed above, LSP Ping may be operated in both asynchronous and on-demand mode.
Addressing is based on the LSP label and the basic functionality only requires support
for the loopback address range in each node on the LSP path.</t>
<t>BFD defines functionality that can be used to support the pro-active OAM CC-V
function when operated in the asynchronous mode. However, the current definition
of basic BFD is dependent on use of LSP Ping to bootstrap the BFD session. Regarding
the connectivity functional aspects, basic BFD has a limitation that it uses only
locally unique (to each node) session identifiers.</t>
<t>VCCV can be used to carry BFD packets that are not IP/UDP
encapsulated for CC-V on a PW and use the PW label to identify the path.</t>
<t>Y.1731 provides functionality for all aspects of CC-V for an Ethernet
environment, this could be translated for the MPLS-TP environment. The CCM PDU
defined in <xref target="Y.1731"/> includes the ability to set the frequency
of the messages that are transmitted, and provides for attaching the address of
the path (in the Ethernet case – the MEG Level) and a sequencing number to
verify that CCM messages were not dropped.</t>
</section>
<section title="Gap analysis">
<t>There is currently no single MPLS tool that gives coverage for all aspects of CC-V
functionality.</t>
<t>LSP Ping could be used to cover the cases of corouted bidirectional LSPs. However,
there is a certain amount of computational overhead involved with use of LSP Ping
(as was observed in sec 1.1), the verification of the control-plane, and the need to
support the loopback functionality at each intermediate node.</t>
<t>BFD could be extended to fill the gaps indicated above. The extension would include:
<list style="symbols">
<t>A mechanism should be defined to carry BFD packets over LSP without
reliance on IP functionality.</t>
<t>A mechanism should be defined to bootstrap BFD sessions for
MPLS that is not dependent on UDP.</t>
<t>BFD needs to be used in conjunction with "globally" unique
identifiers for the path or ME being checked to allow connectivity
verfication support. There are two possibilities, to allow BFD to support
this new type of identifier –
<list style="symbols">
<t>Change the semantics of the two Discriminator fields that exist in
BFD and have each node select the ME unique identifier. This may have
backward compatibility implications.</t>
<t>Create a new optional field in the packet carrying the BFD that would
identify the path being checked, in addition to the existing session
identifiers.</t>
</list>
</t>
<t>Extensions to BFD would be needed to cover P2MP connections.</t>
</list>
</t>
<t>Use of the Y.1731 functionality is another option that should be considered. The
basic PDU for CCM includes (in the flags field) an indication of the frequency of the
packets [eliminating the need to "negotiate" the frequency between the end-points],
and also a flag used for RDI. The procedure itself would need adaptation to comply
with the MPLS environment.</t>
<t>An additional option would be to create a new tool that would give coverage
for both aspects of CC-V according to the requirements and the principles of operation
(see section 2.1). This option is less preferable.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend BFD to resolve the gaps, using a new optional field for the unique
path identifier. And optionally support the PDU format defined in
<xref target="Y.1731"/> with appropriate adjustments to support the MPLS-TP
architecture.</t>
<t>Note that <xref target="MPLS BFD" /> defines a method for using BFD to provide
verification of multipoint or multicast connectivity.</t>
</section>
</section>
<section title="Alarm Notification">
<t>Alarm Notification is a function that is used by a server layer MEP
to notify a failure condition to its client layer MEP(s) in order to
suppress alarms that may be generated by maintenance domains of the
client layer as a result of the failure condition in the server layer.
This function should also have the capability to differentiate an administrative
lock from a failure condition at a different execution level.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this function.
Y.1731 does define a PDU and procedure for this functionality. </t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a tool to support Alarm Notification. This tool could be designed
around the PDU proposed by <xref target="Y.1731"/> that includes support for
an indication of the frequency at which these messages are transmitted after
the alarm is raised until it is cleared.</t>
</section>
</section>
<section title="Diagnostic">
<t>A diagnostic test is a function that is used between MEPs to verify
bandwidth throughput, packet loss, bit errors, etc. This is usually performed
by sending packets of varying sizes at increasing rates (until the limits of the
service level) to measure the actual utilization.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this function.
<xref target="Y.1731"/> describes a function that is dependent on sending a
series of TST packets (this is a PDU whose size can be varied) at differing
frequencies.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a tool to support Diagnostic that could be based on the Y.1731
function.</t>
</section>
</section>
<section title="Adjacency and Route Tracing">
<t>Functinality of route determination is used to determine the route of a connection
across the MPLS transport network. <xref target="MPLS-TP OAM Reqs" /> defines two
closely related operations – one, Adjacency, for discovery of neighboring nodes
and the other, Route Tracing, for determination of the path that is being traversed and
location of a fault identified by e.g. the CC-V tool.</t>
<section title="Existing tools">
<t>LSP Ping supports a trace route function that could be used for co-routed
bidirectional paths. This could support the second type of fnctionality.</t>
<t>However, the discovery aspect that is described by the Adjacency function does
not have any available tools, neither in the IETF toolset nor in the ITU
recommendations.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a new tool to support the Adjacency functionality.</t>
<t>For the Route Trace functionality, either extend the LSP Ping functionality to
support other options, i.e. PW, associated bidirectional LSP, or define a new tool.</t>
</section>
</section>
<section title="Lock">
<t>The Lock function allows the system to block off transmission of data along a LSP.
When a path end-point receives a command, e.g. from the management system, that the
path is blocked, the end-point informs the far-end that the path has been locked
and that no data should be transmitted. This function is used on-demand.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this function.
Y.1731 does define a PDU and procedure for this functionality. </t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a tool to support Lock. This tool could be designed around the
procedure proposed by <xref target="Y.1731"/> that includes support for
an indication of the frequency at which these messages are transmitted
until the lock situation is cleared.</t>
</section>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used by a MEP to notify its peer MEP that
a defect, usually a unidirectional defect, is detected on a bi-directional
connection between them.</t>
<t>This function should be supported in pro-active mode.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to fully support this
functionality, however BFD supports a mechanism of informing the far-end
that the session has gone down, and the Diagnostic field indicates the
reason. Similarly, when LSP Ping is used for a corouted bidirectional LSP
the far-end LER could notify that there was a misconnectivity.</t>
<t>In <xref target="Y.1731"/> this functionality is defined as part of the
CC-V function as a flag in the PDU.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Either create a dedicated mechanism for this functionality or extend
the BFD session functionality to support the functionality without
disrupting the CC or CV functionality. Such an extension could be
similar to that suggested by the ITU recommendation</t>
</section>
</section>
<section title="Client Fail Indication">
<t>Client Fail Indication (CFI) function is used to propagate an indication of
a failure to the far-end sink when alarm suppression in the client layer
is not supported.</t>
<section title="Existing tools">
<t>There is a possibility of using the BFD over VCCV mechanism for "Fault
detection and AC/PW Fault status signalling". However, there is a need to
differentiate between faults on the AC and the PW.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Either extend the BFD tool or define a tool to support Client Fail Indication
propagation.</t>
</section>
</section>
<section title="Packet Loss ">
<t>Packet Loss is a function that is used to verify the quality of
the service. This function indicates the ratio of packets that are not delivered
out of all packets that are transmitted by the path source.</t>
<t>There are two possible ways of determining this measurement –
<list style="symbols">
<t>Using OAM packets, it is possible to compute the statistics based on a
series of OAM packets. This, however, has the disadvantage of being artificial,
and may not be representative since part of the packet loss may be dependent
upon packet sizes.</t>
<t>Sending delimiting messages for the start and end of a measurement period
during which the source and sink of the path count the packets transmitted and
received. After the end delimiter, the ratio would be calculated by the path
OAM entity.</t>
</list></t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this function.
<xref target="Y.1731"/> describes a function that is based on sending the
CCM packets [used for CC-V support (see sec 3.1)] for proactive support and
specialized loss-measurement packets for on-demand measurement. These packets
include information (in the additional TLV fields) of packet counters that are
maintained by each of the end-points of a path. These counters maintain a count
of packets transmitted by the ingress end-point and the count of packets
received from the far-end of the path by the egress end-point. </t>
</section>
<section title="Recommendations and Guidelines">
<t>One possibility is to define a mechanism to support Packet Loss Measurement, based
on the delimiting messages. This would include a way for delimiting the periods for
monitoring the packet transmissions to measure the loss ratios, and computation of
the ratio between received and transmitted packets.</t>
<t>A second possibility would be to define a functionality based on the description
of the loss-measurement function defined in <xref target="Y.1731"/> that is dependent
on the counters maintained, by the MPLS LSR (as described in <xref target='RFC3813'/>,
of received and transmitted octets.</t>
</section>
</section>
<section title="Delay Measurement">
<t>Delay Measurement is a function that is used to measure one-way or
two-way delay of a packet transmission between a pair of MEPs. 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 first 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>Similarly to the packet loss measurement this could be performed in one of
two ways –</t>
<t><list style="symbols">
<t>Using OAM packets – checking delay (either one-way or two-way) in
transmission of OAM packets. May not fully reflect delay of larger packets,
however, gives feedback on general service level.</t>
<t>Using delimited periods of transmission – may be too intrusive on the
client traffic.</t>
</list></t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF toolset that fulfills all of the
MPLS-TP OAM requirements.</t>
<t><xref target="Y.1731"/> describes a function in which specific OAM packets
are sent with a transmission time-stamp from one end of the managed path to the
other end (these are transparent to the intermediate nodes). The delay
measurement is supported for both unidirectional and bidirectional measurement
of the delay.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a mechanism that would allow to support Delay Measurement. The
mechanism should be based on measurement of the delay in transmission and
reception of OAM packets, transmitted in-band with normal traffic. This
tool could be based on the tool defined in <xref target="Y.1731"/>.</t>
</section>
</section>
</section>
<section title="Recommendations">
<t>
<list style="symbols">
<t>Define a maintenance entity that could be applied both to LSPs and PWs that
would support management of a sub-path. This entity should allow for
transmission of traffic by means of label stacking and proper TTL setting.</t>
<t>Extend the control and the management planes to support the
configuration of the OAM maintenance entities and the set of functions
to be supported by these entities.</t>
<t>Extend the ACH to provide a control channel for MPLS-TP Links, LSPs, and
Tandem Connections.</t>
<t>Define a mechanism that would allow the unique addressing of the elements
that need to be monitored, e.g., the connections, MEPs, and MIPs of a path.
This mechanism needs to be flexible enough to support different addressing
schemes, e.g. IP addresses, NSAP, connection names.</t>
<t>Define a VPCV mechanism for LSP and Tandem Connection. This mechanism
should reuse, as much as possible, the same principles of operation as VCCV.
The ACH should be extended to support CV types for each of the tools that are
defined below, in a way that is consistent for PW, LSP and Tandem Connection.</t>
<t>The appropriate assignment of network-wide unique identifiers needed to
support connectivity verification should be considered.</t>
<t>Tools should be defined to support the following functions. The tools could
be based on the procedures and PDU format defined by <xref target="Y.1731"/> or
extensions to existing MPLS tools:</t>
<list style="symbols">
<t>On-demand connectivity verification</t>
<t>Alarm suppression</t>
<t>Packet loss measurement</t>
<t>Diagnostic test</t>
<t>Route determination</t>
<t>Delay measurement</t>
<t>Remote defect indication</t>
<t>Client fail indication</t>
</list>
<t>The tools may have the capability to authenticate the messages.</t>
</list> </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to thank xxxxxxx for his review and proposed
enhancements to the text.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.792.xml. -->
<reference anchor="ICMP">
<front>
<title abbrev="ICMP">Internet Control Message Protocol</title>
<author fullname="J.Postel" initials="J." surname="Postel">
<organization />
</author>
<date month="Sept" year="1981" />
<abstract>
<t>The Internet Control Message Protocol definition of the messages.</t>
</abstract>
</front>
<seriesInfo name="STD" value="5" />
<seriesInfo name="RFC" value="792" />
</reference>
<!-- End inclusion reference.RFC.2119.xml. -->
<!--Begin inclusion reference.RFC.4379 -->
<reference anchor="LSP Ping">
<front>
<title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures</title>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization />
</author>
<date year="2006" month="February" />
<abstract>
<t>This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this document:
information carried in an MPLS "echo request" and "echo reply" for the
purposes of fault detection and isolation, and mechanisms for reliably
sending the echo reply.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4379" />
<format type="TXT" octets="116872" target="ftp://ftp.isi.edu/in-notes/rfc4379.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 initials="S." surname="Bryant" fullname="S. Bryant">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization />
</author>
<author initials="L." surname="Martini" fullname="L. Martini">
<organization />
</author>
<author initials="D." surname="McPherson" fullname="D. McPherson">
<organization />
</author>
<date year="2006" month="February" />
<abstract>
<t>This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word to be used over an MPLS packet switched n twork, and the Pseudowire
Associated Channel Header. The design of these fields is chosen so that an MPLS Label
Switching Router performing MPLS payload inspection will not confuse a PWE3 payload
with an IP payload. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="4385" />
<format type="TXT" octets="22440" target="ftp://ftp.isi.edu/in-notes/rfc4385.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 initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization />
</author>
<date year="2007" month="December" />
<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 type="TXT" octets="67847" target="ftp://ftp.isi.edu/in-notes/rfc5085.txt" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.draft.MPLS.BFD -->
<reference anchor="MPLS BFD">
<front>
<title>BFD for Multipoint Networks</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization />
</author>
<author initials="D." surname="Ward" fullname="David Ward">
<organization />
</author>
<date year="2007" month="December" />
<abstract>
<t>This document describes a simple echo protocol for verifying the connectivity of MPLS
LSP</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-katz-ward-bfd-multipoint-01.txt" />
</reference>
<!-- End inclusion reference.draft.MPLS.BFD -->
<!-- Begin inclusion reference.draft.VCCV.BFD -->
<reference anchor="VCCV BFD">
<front>
<title>Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)</title>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization />
</author>
<date year="2008" month="February" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-pwe3-vccv-bfd-01.txt" />
</reference>
<!-- End inclusion reference.draft.bfd.vccv -->
<!-- Begin inclusion reference.draft.p2mp.LSP.Ping -->
<reference anchor="P2MP LSP Ping">
<front>
<title>Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping</title>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="A." surname="Farrel" fullname="Adrian Farrel">
<organization />
</author>
<date year="2008" month="June" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-p2mp-lsp-ping-06.txt" />
</reference>
<!-- End inclusion reference.draft.p2mp.LSP.Ping -->
<!-- Begin inclusion reference.draft.LSP.Ping.MPLS -->
<reference anchor="MPLS LSP Ping">
<front>
<title>Mechanism for performing LSP-Ping over MPLS tunnels</title>
<author initials="N." surname="Bahadur" fullname="Nitin Bahadur">
<organization />
</author>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization />
</author>
<date year="2008" month="June" />
<abstract>
<t>LSP Ping for MPLS tunnels.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-lsp-ping-enhanced-dsmap-00" />
</reference>
<!-- End inclusion reference.draft.LSP.Ping.MPLS -->
<!-- Begin inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<reference anchor="MPLS-TP OAM Reqs">
<front>
<title>Requirements for OAM in MPLS Transport Networks</title>
<author initials="M." surname="Vigoureux" fullname="Martin Vigoureux">
<organization />
</author>
<author initials="M." surname="Betts" fullname="Malcolm Betts">
<organization />
</author>
<author initials="D." surname="Ward" fullname="Dave Ward">
<organization />
</author>
<date year="2009" month="April" />
<abstract>
<t>Lists the requirements for the OAM functionality in support of MPLS-TP.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-oam-requirements-01" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<!-- Begin inclusion reference.draft.MPLS.TP.OAM.Fwk -->
<reference anchor="MPLS-TP OAM Frwk">
<front>
<title>MPLS-TP OAM Framework and Overview</title>
<author initials="I." surname="Busi" fullname="Italo Busi">
<organization />
</author>
<author initials="B." surname="Niven-Jenkins" fullname="Ben Niven-Jenkins">
<organization />
</author>
<date year="2009" month="March" />
<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="ID" value="draft-ietf-mpls-tp-oam-requirements-01" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<!-- Begin inclusion reference.draft.MPLS.TP.Reqs -->
<reference anchor="MPLS-TP Reqs">
<front>
<title>Requirements for the Trasport Profile of MPLS</title>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization />
</author>
<date year="2009" month="April" />
<abstract>
<t>Lists the requirements for MPLS-TP with cross reference </t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-requirements-06" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Reqs -->
<!--Begin inclusion reference.RFC.3813 -->
<reference anchor="RFC3813">
<front>
<title>Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management
Information Base (MIB)</title>
<author initials="C." surname="Srinivasan" fullname="C. Srinivasan">
<organization />
</author>
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan">
<organization />
</author>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<date year="2004" month="June" />
<abstract>
<t>This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Multiprotocol Label Switching (MPLS) Label Switching Router
(LSR).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3813" />
<format type="TXT" octets="116872" target="ftp://ftp.isi.edu/in-notes/rfc3813.txt" />
</reference>
<!-- End inclusion reference.RFC.3813 -->
<!--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 year="2006" month="May" />
<abstract>
<t>This </t>
</abstract>
</front>
<seriesInfo name="ITU" value="Y.1731" />
</reference>
<!-- End inclusion reference.ITU.Y1731 -->
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 14:16:31 |