One document matched: draft-ietf-mpls-tp-oam-analysis-00.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-ietf-mpls-tp-oam-analysis-00.txt"
ipr="pre5378Trust200902">
<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>
<!-- Tom requested to be taken out of the list of editors (20.7.2009)
<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="Elisa Bellagamba" initials="E." role="" surname="Bellagamba">
<organization>Ericsson</organization>
<address>
<postal>
<street>6 Farogatan St</street>
<city>Stockholm</city>
<region />
<code>164 40</code>
<country>Sweden</country>
</postal>
<email>elisa.bellagamba@ericsson.com</email>
<phone>+46 761440785</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="09" month="Nov" year="2009" />
<abstract>
<t>This document analyzes 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. This document reports the conclusions
of the MPLS-TP design team discussions concerning the MPLS-TP OAM tools at IETF75.</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"/> 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="BASE 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>
<t>This document reports the conclusions of the MPLS-TP design team discussions
on the MPLS-TP OAM tools at IETF75 and the guidelines that were agreed. The
guidelines refer to a set of existing OAM tools that need to be enhanced to
fully support the MPLS-TP OAM requirements and identify new tools that need
to be defined. The organizational structure of the documents on MPLS-TP OAM tools
was also discussed and agreed at IETF75 and is described later in this document.</t>
</section>
<section title="Organization of the document">
<t>Sections 1.3 – 1.6 provide an overview of the existing MPLS tools.</t>
<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>The recommendations are summarized in section 4, and reflect the guidelines which
were agreed by the MPLS-TP design team during the meetings at IETF 75. These
guidelines relate to the 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>
<t>The OAM tools for MPLS-TP OAM will be defined in a set of documents. Section 5
describes the organization of this set of documents as agreed by the MPLS-TP design
team at IETF75.</t>
</section>
<section title="LSP Ping">
<t>LSP Ping is a variation of ICMP Ping and traceroute <xref target="ICMP" /> adapted
to the 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. For a bi-directional LSP (either associated or
co-routed) the return message of the LSP Ping could be sent on the return LSP. For
unidirectional LSPs and in some case for bi-directional LSPs, the return message
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 successfully traversed before the faulty link or node.</t>
<t>As mentioned above, LSP Ping requires the presenece of the MPLS control plane when
verifying the consistency of the data-plane against the control-plane. However, 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>It should be noted that LSP Ping does support unique identification of the LSP
within an addressing domain. The identification is checked using the full FEC
identification. LSP Ping is easily extensible to include additional information
needed to support new functionality, by use of Type-Length-Value (TLV) constructs.</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. This is used as part of the traceroute of a path and 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" />. The
applicability for a pro-active mode of operation is analyzed in the sections below.
Use of the loopback address range (to protect against leakage outside the LSP)
assumes that all of the intermediate nodes support some IP functionality. Note
that ECMP is not supported in MPLS-TP, therefore its implication on OAM
capabilities is not analyzed in this document.</t>
</section>
<section title="MPLS BFD">
<t>BFD (Bidirectional Forwarding Detection) <xref target="BASE BFD" /> 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><xref target="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 defined in <xref target="Y.1731"/> are described for 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 pro-active mode
end-to-end checking</t>
<t>Loopback functionality – to verify connectivity to intermediate nodes in an
on-demand mode</t>
<t>Link Trace – provides information on the intermediate nodes of the path
being monitored, may be used for fault localization. This is activated in an
on-demand mode.</t>
<t>Alarm Indication Signaling – for alarm suppression in case of faults
that are detected at the server layer, activated pro-actively.</t>
<t>Remote Defect Indication – as part of the Connectivity and Continuity
Monitoring packets, performed pro-actively</t>
<t>Locked Signal – for alarm suppression in case of administrative locking
at the server layer. This function is performed pro-actively.</t>
<t>Performance monitoring – including measurement of packet delays both uni and
bi-directional (on-demand), measurement of the ratio of lost packets (pro-active),
the effective bandwidth that is supported without packet loss, and throughput
measurement.</t>
</list> </t>
<t>The PDU defined in <xref target="Y.1731"/> includes various information elements
(fields) including information on the MEG-Level, etc. 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. The addressing
information is carried in <Type, Length, Value> (TLV) fields that follow the
actual PDU. In the LBM PDU the MAC address is used to identify the MIP to which
the message is intended</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>G-ACH</c><c>Generic Associated Channel Header</c>
<c>LDP</c><c>Label Distribution Protocol</c>
<c>LSP</c><c>Label Switched Path</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>TLV</c><c>Type, Length, Value</c>
<c>TTL</c><c>Time-to-live</c>
<c>VCCV</c><c>Virtual Circuit Connectivity Verification</c>
</texttable>
</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 the 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
MUST be able to operate by relying on the IP routing and forwarding capabilities.
All of the existing MPLS tools (i.e. LSP Ping, VCCV Ping, MPLS BFD, and VCCV BFD)
can support this functionality. The Y.1731 toolset does not specifically support
this functionality, but rather relies on underlying technologies for forwarding
this could also be over IP, e.g. by using a VCCV extension. Note that some of
the MPLS-TP tools such as Alarm Report are very transport oriented and may not
support IP functionality.</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. Except for the
LSP Ping operation of verifying the data-plane vs. the control-plane, 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
completely comply with the requirement. In the on-demand mode, LSP Ping also
may use 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. There are extensions to LSP-Ping that
are under discussion that allow LSP-Ping to restrict replies to the
backside of a bidirectional LSP.</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 VCCV or G-ACH control channels.</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. <xref target="MPLS G-ACH" /> generalizes the use
of the PW ACH and enables provision of control channels at the MPLS LSP and
sections levels. This new mechanism would support carrying the existing MPLS
OAM messages or the Y.1731 messages at the LSP and the section levels to be
transmitted over the G-ACH.</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. Note that in the PWE3 WG there are
two proposals regarding how to transmit the AC failures over an ACH
that may be applicable to this requirement.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires a single OAM technology and
consistent OAM capabilities for LSPs, PWs, and Sections. 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 could readily 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 point of a LSP/PW. Technically, this could be supported by the
proper setting of the TTL value. It is also recommended to include the identifier
of the intermediate point within the OAM message to allow the intermediate point
to validate that the message is really intended for it. The information can be
included in an ACH-TLV according to the definitions in <xref target="MPLS-TP ACH TLV" />.
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 defines support for optional authentication fields using
different authentication methods as defined in <xref target="BASE BFD"/>.
Other tools should support this capability as well. Y.1731 functionality
uses the identification of the path for authentication. Authentication
information could be included in an optional TLV field according to the
definitions in <xref target="MPLS-TP ACH TLV" /> when not available in
the OAM PDU.</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>Define a generalized addressing scheme that can also support unique
identification of the monitored paths (or connections).</t>
<t>Use G-ACH for LSP and section levels.</t>
<t>Define architectural element that is based on LSP hierarchy to apply
the mechanisms to segments and concatenated segments.</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, described below.</t>
<t>Similarly, LSP Ping could be extended to use only the LSP path (in both
directions) without IP Forwarding. Addressing for PW can be included by using
the VCCV mechanism. LSP Ping could be used to address the CC-V, Route Tracing,
RDI, and Lock/Alarm Reporting functionality cited in the requirements.</t>
<t>The Y.1731 PDU set could be used as a basis for defining the information units
to be transmitted over the G-ACH. The actual procedures and addressing schemes would
need to be adjusted for the MPLS-TP environment.</t>
<t>Define a mechanism that could be used to idnetify an intermediate point 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 exception mechanism to allow an OAM packet to be intercepted
by intermediate nodes.</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, when needed.</t>
<t>OAM packets should be transmitted in-band.</t>
<t>Support a single OAM technology for LSP, PW, and Sections.</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), Signaling Control Channel
(SCC)), by defining new types of communication channels for PWs, Sections,
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>
<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. These functions may be
split into separate mechanisms. Together they are used to detect loss of
traffic continuity and misconnections between path end-points 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 co-routed
bidirectional LSPs. As observed above, LSP Ping may be operated in both
asynchronous and on-demand mode. Addressing is based on the full FEC identification
that provides a unique identifier, 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 either LSP Ping or BFD packets that are not IP/UDP
encapsulated for CC-V on a PW. Note that PW termination/switching points use only
locally unique (to each node) labels. The PW label identifies the path uniquely
only at the LSP level.</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>LSP Ping could be used to cover the cases of co-routed 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.
LSP Ping uses a fully qualified LSP identifier, and when used in conjunction
with VCCV would use the PW label to identify the transport path. LSP Ping can
be extended to bypass the verification of the control plane</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 could 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 LSP Ping to fully support the on-demand Connectivity Verification function
resolving the gaps described above. Extend BFD to support proactive Continuity Check
& Connectivity Verification (CC-V) resolving the gaps described above.</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 Reporting">
<t>Alarm Reporting is a function that is used by an intermediate point in a path
to notify the end-points of the path of a fault or defect condition indirectly
affecting that path. Such information may be used by the endpoints, for example,
to suppress alarms that may be generated by maintenance end-points of the path.
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 new tool and PDU to support Alarm Reporting. The PDU should be
transmitted over a G-ACH. The frequency of transmision after the alarm is raised
and the continued frequency until it is cleared should be indicated in the definition.</t>
<t>Describe also how the Alarm Reporting functionality may be supported in the
control-plane and management-plane.</t>
</section>
</section>
<section title="Diagnostic">
<t>A diagnostic test is a function that is used between path end-points 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 new tool and PDU to support Diagnostic.</t>
</section>
</section>
<section title="Route Tracing">
<t>Functionality of route determination is used to determine the route of a connection
across the MPLS transport network. <xref target="MPLS-TP OAM Reqs" /> defines that
this functionality MUST allow a path end-point to identify the intermediate and
end-points of the path. This functionality MUST support co-routed bidirectional
paths, and MAY support associated bidirectional and unidirectional p2p paths, as
well as p2mp unidirectional paths. Unidirectional path support is dependent on
the existence of a return path to allow the original end-point to receive the trace
information.</t>
<section title="Existing tools">
<t>LSP Ping supports a trace route function that could be used for bidirectional
paths. Support of unidirectional paths would be dependent on the ability of
identifying a return path.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend LSP Ping to support the Route Trace functionality and to address additional
options, i.e. PW and p2mp unidirectional LSP.</t>
</section>
</section>
<section title="Lock Instruct">
<t>The Lock instruct 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, but LSP
Ping could be extended to support this functionality between the path endpoints.
Y.1731 does define a PDU and procedure for this functionality. </t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend LSP Ping to support Lock instruct. The frequency at which these
messages are transmitted until the lock situation is cleared, should be clearly
indicated.</t>
</section>
</section>
<section title="Lock Reporting">
<t>Lock reporting is used by an intermediate point to notify the end points of a
transport path (that the intermediate point is a member of) that an external
lock condition exits for this transport path. This function is used proactively.</t>
<section title="Existing tools">
<t>There is no mechanism defined in neither the IETF nor in Y.1731 to support
this function.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a new tool and PDU to support Lock reporting. This tool could be
designed similarly to the Alarm Reporting tool (described above), but would need
to be initiated by an intermediate point of the transport path. </t>
</section>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used by a path end-point to notify its peer
end-point 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 co-routed 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>Extend BFD (which is recommended to be used for proactive CC-V) to transmit
the signal of Remote Defect Indication without disrupting the CC-V functionality.
Such an extension could be similar to that suggested by the ITU recommendation.</t>
</section>
</section>
<section title="Client Failure Indication">
<t>Client Failure 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 signaling". However, there is a need to
differentiate between faults on the AC and the PW. In the PWE3 WG there are
some proposals regarding how to transmit the CFI over an ACH.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Use PWE3 tool to propagate Client Fail Indication via an ACH.</t>
</section>
</section>
<section title="Packet Loss Measurement">
<t>Packet Loss Measurement 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. Define a new PDU for the message that utilizes
G-ACH. This option appears more suitable for performance monitoring statistics,
which in transport applications are based on the continuous monitoring of the
traffic interested (100 ms gating).</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). 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>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 one-way and two-way measurement
of the delay. It should be noted that the functionality on the one-way delay
measurement is dependent upon a certain degree of synchronization between the
time clocks of the two-ends of the transport path.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a mechanism that would support Packe Delay Measurement, based on the
procedures defined in <xref target="Y.1731" />. The mechanism should be based
on measurement of the delay in transmission and reception of OAM packets,
transmitted in-band with normal traffic. Define an appropriate PDU that would
utilize the G-ACH.</t>
</section>
</section>
</section>
<section title="Recommendations">
<t>As indicated above, LSP-Ping could easily be extended to support some of the
functionality between the path end-points and between an end-point of a path and an
intermediate point. BFD could also be extended to support some of the functions
between the end-points of a path. Some of the OAM functions defined in
<xref target="Y.1731"/> (especially for performance monitoring) could also be adapted.</t>
<t>The guidelines that are used in this document are as follows:</t>
<list style="symbols">
<t>Re-use/extend existing IETF protocols wherever applicable.</t>
<t>Define new message format for each of the rest of the OAM functions, which
are aligned with the ACH and ACH-TLV definitions, and includes only relevant
information.</t>
<t>Adapt Y.1731 functionality where applicable (mainly for performance monitoring).</t>
</list>
<t>The recommendations on the MPLS-TP OAM tools are as follows:</t>
<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>Define a mechanism that would allow the unique addressing of the elements
that need to be monitored, e.g., the connections, end-points, and intermediate
points of a path. This mechanism needs to be flexible enough to support
different addressing schemes, e.g. IP addresses, NSAP, connection names. As
pointed out above, LSP Ping uses the full FEC identifier for the LSP - this
could easily be applied to Section OAM since this would be considered as a
stacked LSP.</t>
<t>The appropriate assignment of network-wide unique identifiers for transport
paths, needed to support connectivity verification, should be considered.</t>
<t>Extend existing MPLS tools to disengage from IP forwarding mechanisms.</t>
<t>Extend BFD to support the proactive CC-V functionalities. The extensions should
address the gaps described above.</t>
<t>Extend LSP Ping to support the on-demand Connectivity Verification functionality.
The extensions should address the gaps described above.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support the Alarm
Reporting functionality for data-plane implementations. Describe how Alarm
Reporting can be supported by a control-plane and by a management-plane.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support the Lock
Reporting functionality. Use the same procedures as for Alarm Reporting.</t>
<t>Extend BFD to support the Remote Defect Indication (RDI) functionality. The
extensions should address the gaps described above.</t>
<t>Extend LSP-Ping to support the Route tracing functionality. The extensions
should address the gaps described above.</t>
<t>Extend LSP-Ping to support the Lock Instruct functionality between end-points
of a path. The extensions should address the gaps described above.</t>
<t>Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH. There are
already some proposals in the PWE3 WG.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support the Packet
Loss Measurement functionality. Base the functionality on the procedures defined
in Y.1731.</t>
<t>Define a new PDU which be transmitted over G-ACH to support the Packet Delay
Measurement functionality. Base the functionality on the procedures defined in
Y.1731. For one-way delay measurement define mechanisms to ensure a certain degree
of synchronization between the time clocks of the two-ends of the transport path.</t>
<t>Define a new PDU which be transmitted over G-ACH to support the Diagnostic
functionality.</t>
<t>The tools may have the capability to authenticate the messages. The information
may be carried in a G-ACH TLV.</t>
</list> </t>
</section>
<section title="MPLS-TP OAM Documents Organization">
<t>The following paragraphs list the set of documents necessary to cover the OAM
functionalities analyzed above. This compilation of documents is one of the outcomes
of the MEAD team discussions that took place during IETF75 in Stockholm.</t>
<t>It should be noted that the various document titles listed here may not reflect the
draft titles that will be chosen at the time that the drafts are written, but they
serve just as a topic pointer from the current analysis.</t>
<section title="Document 1: "Encapsulation of BFD and LspPing in ACH"">
<t>The scope of the document is to define the usage of LSP Ping and BFD in both IP and
IP-less environments. As described in the following paragraphs, BFD and Lsp Ping need
to be extended in order to be compliant with <xref target="MPLS-TP OAM Reqs" />. However,
this document should be focused on the existing Lsp Ping and BFD, without necessarily
referring to their extended versions.</t>
<t>The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be considered as the
starting point for this definition.</t>
<t>In particular, the following sections will be taken into account for the scope:</t>
<list style="symbols">
<t>nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping extensions")
for addressing the "Lsp Ping encapsulation in ACH"</t>
<t>nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD over MPLS-TP
LSPs") for addressing the "BFD encapsulation in ACH"</t>
</list>
</section>
<section title="Document 2: "Extended BFD"">
<t>The scope of the document is to define the BFD extension and behavior to meet the
requirements for MPLS-TP proactive Continuity Check and Connectivity Verification
functionality and the RDI functionality as defined in <xref target="MPLS-TP OAM Reqs" />.</t>
<t>The document will likely take the name "draft-asm-mpls-tp-bfd-cc-cv-00" and will
be formed by the merging of the following two drafts:</t>
<list style="symbols">
<t>draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd</t>
<t>draft-boutros-mpls-tp-cc-cv-01.txt</t>
</list>
</section>
<section title="Document 3: "Extended LSP Ping"">
<t>The scope of the document is to define:</t>
<list style="symbols">
<t>A place holder for On Demand Connectivity Verification if LSP Ping needs to be
enhanced over and above the encapsulations changes (defined in Document 1
"Encapsulation of BFD and LSP Ping in ACH").</t>
<t>Usage of LSP Ping with MIPs and MEPs, which is partially covered in
nitinb-mpls-tp-lsp-ping-bfd-procedures.</t>
<t>Route Trace. This topic has already been partially covered in
"draft-boutros-mpls-tp-path-trace-00" and
"nitinb-mpls-tp-lsp-ping-bfd-procedures", which will be considered as
starting point for the Route Trace functionality included in Document 3. The
Route Trace section should also cover these aspects:</t>
<list style="symbols">
<t>LSP Ping Loose ends. This section will describe what to do when receiving
an LSP Ping with MIP and MEP ids.</t>
<t>In an IP-Less environment Route Trace works only in co-routed bidirectional LSP.</t>
<t>In Y.1731 the CV function is separate from the Route Trace function, it should
be captured how LSP Ping works for Route Trace using TTL.</t>
</list>
</list>
</section>
<section title="Document 4: "Extensions for Lock Instruct"">
<t>A new document describing the LSP Ping extensions to accomplish the Lock Instruct
desired behavior is needed. Some material useful for this scope can be found in
"draft-boutros-mpls-tp-loopback-02".</t>
</section>
<section title="Document 5: "AIS and Lock Reporting"">
<t>A new document is need for the definition of the AIS and Lock Reporting, however
the document definition has been temporarily deferred by the MEAD team. Therefore
this paragraph will be updated in future versions.</t>
</section>
<section title="Document 6: "Client Fault Indication"">
<t>A new document describing Client Fault Indication procedure needs to be defined.</t>
<t>The following two drafts indicating a client fault indication transported across
MPLS-TP network will be compared and merged in the new document:</t>
<list style="symbols">
<t>"draft-he-mpls-tp-csf", which describes a tool to propagate a client
failure indication across an MPLS-TP network in case the propagation of failure
status in the client layer is not supported.</t>
<t>"draft-martini-pwe3-static-pw-status", which describes the usage of
PW associated channel to signal PW status messages in case a static PW is used
without a control plane</t>
</list>
<t>It is worth noting that a Client Failure Indication is used if the client does
not support its own OAM (IP and MPLS as clients use their own). It has been also
agreed that CFI is used on PW and not on client directly mapped on LSP MPLS-TP.</t>
</section>
<section title="Document 7: "Packet Loss"">
<t>A new document needs to be defined in order to describe a stand alone tool for
Packet Loss measurements that can work both proactively and on demand. The tool
will be functionally based on Y.1731.</t>
</section>
<section title="Document 8: "Packet Delay"">
<t>A new document needs to be defined about the Packet Delay measurement which will
be based on Y.1731 from the functionality point of view. Moreover,
<xref target="MPLS-TP OAM Frwk"/> needs to be updated in order to clarify the
functionality behavior expected from this tool.</t>
</section>
<section title="Document 9: "Diagnostic Tests"">
<t>One or more new documents are needed for the tools definition for Diagnostic Tests.
However, the documents definition has been temporarily deferred by the MEAD team until
a clearer definition of "diagnostic test" in <xref target="MPLS-TP OAM Reqs"/>.</t>
</section>
</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 the MEAD team for their review and proposed
enhancements to the text.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.2119.xml. -->
<reference anchor="RFC 2119">
<front>
<title abbrev="RFC 2119">Internet Control Message Protocol</title>
<author fullname="S.Bradner" initials="S." surname="Bradner">
<organization />
</author>
<date month="March" year="1997" />
<abstract>
<t>Key words for use in RFCs to Indicate Requirement Levels.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<!-- End inclusion reference.RFC.2119.xml. -->
<!-- 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.BASE.BFD -->
<reference anchor="BASE BFD">
<front>
<title>Bidirectional Forwarding Detection</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization />
</author>
<author initials="D." surname="Ward" fullname="David Ward">
<organization />
</author>
<date year="2009" month="February" />
<abstract>
<t>This document describes a protocol intended to detect faults in the bidirectional
path between two forwarding engines, including interfaces, data link(s), and to the
extent possible the forwarding engines themselves, with potentially very low latency.
It operates independently of media, data protocols, and routing protocols. </t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-bfd-base-09.txt" />
</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 initials="R." surname="Aggarwal" fullname="Rahul Aggarwal">
<organization />
</author>
<author initials="K." surname="Kompella" fullname="Kiretti Kompella">
<organization />
</author>
<author initials="T." surname="Nadeau" fullname="Thomas Nadeau">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="George Swallow">
<organization />
</author>
<date year="2008" month="June" />
<abstract>
<t>One desirable application of Bi-directional Forwarding Detection (BFD) is to detect
a Multi Protocol Label Switched (MPLS) Label Switched Path (LSP) data plane failure.
LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for
verifying the MPLS LSP data plane against the control plane. BFD can be used for
the former, but not for the latter. However the control plane processing required
for BFD control packets is relatively smaller than the processing required for
LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster
data plane failure detection and/or make it possible to provide such detection on a
greater number of LSPs. This document describes the applicability of BFD in relation
to LSP-Ping for this application. It also describes procedures for using BFD in this
environment.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-bfd-mpls-07.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-07.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="B." surname="Niven-Jenkins" fullname="Ben Niven-Jenkins">
<organization />
</author>
<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 -->
<reference anchor="MPLS G-ACH">
<front>
<title>MPLS Generic Associated Channel</title>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization />
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization />
</author>
<author initials="M." surname="Vigoureux" fullname="Martin Vigoureux">
<organization />
</author>
<date year="2009" month="June" />
<abstract>
<t>Defines a Generic Associated Control Header for MPLS Transport Paths</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5586" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.G-ACH -->
<reference anchor="MPLS-TP ACH TLV">
<front>
<title>Definition of ACH TLV Structure</title>
<author initials="S." surname="Boutros" fullname="Sami Boutros">
<organization />
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization />
</author>
<author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="George Swallow">
<organization />
</author>
<author initials="D." surname="Ward" fullname="David Ward">
<organization />
</author>
<date year="2009" month="June" />
<abstract>
<t>Defines use of TLV fields for G-ACH</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-ach-tlv-00" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.ACH-TLV -->
<!--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 23:59:34 |