One document matched: draft-sprecher-mpls-tp-oam-primer-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-sprecher-mpls-tp-oam-primer-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="MPLS OAM Primer">MPLS-TP OAM Primer</title>
<author fullname="Nurit Sprecher" initials="N." role=""
surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region></region>
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="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 year="2010" />
<abstract>
<t>This document provides basic information on the existing MPLS
Operations, Administration, and Maintenance (OAM) toolset and analyzes
these tools relative to the set of requirements for OAM for the Transport
Profile of MPLS(MPLS-TP) as defined in <xref target="MPLS-TP OAM Reqs" />.
On this basis the document tries to highlight features that need to be
extended in order to deliver the higher-quality OAM required for transport
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Scope">
<t>OAM (Operations, Administration, and Maintenance) plays a
significant role in carrier networks, providing methods for fault
management and performance monitoring in both the transport and the
service layers in order to improve their ability to support services
with guaranteed and strict Service Level Agreements (SLAs) while
reducing their operational costs.</t>
<t><xref target="MPLS-TP Reqs"></xref> in general, and <xref
target="MPLS-TP OAM Reqs"></xref> in particular define a set of
requirements for OAM functionality in MPLS-Transport Profile (MPLS-TP)
for MPLS-TP Label Switched Paths (LSPs) (network infrastructure),
Pseudowires (PWs) (services), and MPLS-TP Sections.</t>
<t>The purpose of this document is to evaluate whether existing OAM
tools defined for MPLS can be used to meet the requirements, identify
possible extensions to the tools to comply with the requirements.
The existing tools that are evaluated include LSP Ping (defined in
<xref target="LSP Ping"></xref>), MPLS Bi-directional Forwarding
Detection (BFD) (defined in <xref target="BASE BFD"></xref>), Virtual
Circuit Connectivity Verification (VCCV) (defined in <xref
target="PW VCCV"></xref> and <xref target="VCCV BFD"></xref>), and IETF
performance measurement tools defined in <xref target="RFC4656" /> and
<xref target="RFC5357" />.</t>
</section>
<section title="Organization of the document">
<t>Section 2 provides an overview of the existing MPLS/IETF tools.</t>
<t>Section 3 highlights the requirements for enhanced OAM functionality
for the transport environment.</t>
<t>Section 4 identifies the enhancements to the existing OAM tools that
are needed to address the additional requirements.</t>
</section>
<section title="Acronyms">
<texttable align="left" style="none">
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<c>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>OWAMP</c>
<c>One Way Active Measurement Protocol</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>TWAMP</c>
<c>Two Way Active Measurement Protocol</c>
<c>VCCV</c>
<c>Virtual Circuit Connectivity Verification</c>
</texttable>
</section>
<section title="Contributing Authors">
<t>Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi (Alcatel
Lucent)</t>
</section>
</section>
<section title="Pre-existing OAM tools">
<section title="LSP Ping">
<t>LSP Ping is a variation of ICMP Ping and traceroute <xref
target="ICMP"></xref> 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 presence 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"></xref>.</t>
<t><xref target="P2MP LSP Ping"></xref> 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"></xref> 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"></xref>. 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"></xref> 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"></xref>, of
operation.</t>
<t><xref target="MPLS BFD"></xref> 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"></xref> 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"></xref> 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"></xref>), 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="IETF Performance Measurement">
<t>OWAMP (One-Way Active Measurement Protocol) <xref target="RFC4656" />
enables measurement of unidirectional characteristics of IP networks,
such as packet loss and one-way delay. For its proper operation OWAMP
requires accurate time of day setting at its end points.</t>
<t>TWAMP (Two-Way Active Measurement Protocol) <xref target="RFC5357" />
is a similar protocol that enables measurement of two-way (round trip)
characteristics. TWAMP does not require accurate time of day, and,
furthermore, allows the use of a simple session reflector, making it
an attractive alternative to OWAMP.</t>
<t>Both OWAMP and TWAMP consist of inter-related control and test
protocols, although "TWAMP Light" eliminates the need for
the control protocol.</t>
<t>OWAMP and TWAMP control protocols run over TCP, while the test
protocols run over UDP. The purpose of the control protocols is to
initiate, start, and stop test sessions, and for OWAMP to fetch results.
The test protocols introduce test packets (which contain sequence
numbers and timestamps) along the IP path under test according to a
schedule, and record statistics of packet arrival. Multiple sessions
may be simultaneously defined, each with a session identifier, and
defining the number of packets to be sent, the amount of padding to be
added (and thus the packet size), the start time, and the send schedule
(which can be either a constant time between test packets or exponentially
distributed pseudo-random). Statistics recorded conform to the relevant
IPPM RFCs.</t>
<t>OWAMP defines the following logical roles: Session-Sender,
Session-Receiver, Server, Control-Client, and Fetch-Client. The
Session-Sender originates test traffic that is received by the
Session-receiver. The Server configures and manages the session, as well
as returning the results. The Control-Client initiates requests for test
sessions, triggers their start, and may trigger their termination. The
Fetch-Client requests the results of a completed session. Multiple roles
may be combined in a single host – for example, one host may play
the roles of Control-Client, Fetch-Client, and Session-Sender, and a
second playing the roles of Server and Session-Receiver.</t>
<t>In a typical OWAMP session the Control-Client establishes a TCP
connection to port 861 of the Server, which responds with a server
greeting message indicating supported security/integrity modes. The
Control-Client responds with the chosen communications mode and the
Server accepts the modes. The Control-Client then requests and fully
describes a test session to which the Server responds with its acceptance
and supporting information. More than one test session may be requested
with additional messages. The Control-Client then starts a test session
and the Server acknowledges. The Session-Sender then sends test packets
with pseudorandom padding to the Session-Receiver until the session is
complete or until the Control-Client stops the session. Once finished,
the Fetch-Client sends a fetch request to the server, which responds with
an acknowledgement and immediately thereafter the result data.</t>
<t>TWAMP defines the following logical roles: session-sender,
session-reflector, server, and control-client. These are similar to the
OWAMP roles, except that the Session-Reflector does not collect any
packet information, and there is no need for a Fetch-Client.</t>
<t>In a typical TWAMP session the Control-Client establishes a TCP
connection to port 862 of the Server, and mode is negotiated as in OWAMP.
The Control-Client then requests sessions and starts them. The
Session-Sender sends test packets with pseudorandom padding to the
Session-Reflector which returns them with insertion of timestamps.</t>
<t>OWAMP and TWAMP test traffic is designed with security in mind. Test
packets are hard to detect because they are simply UDP streams between
negotiated port numbers, with potentially nothing static in the packets.
OWAMP and TWAMP also include optional authentication and encryption for
both control and test packets.</t>
</section>
</section>
<section title="MPLS-TP OAM Functionality">
<t>The following sections discuss the required OAM functionality as
required by <xref target="MPLS-TP OAM Reqs"></xref>.</t>
<section title="Basic OAM functionality">
<t><xref target="MPLS-TP OAM Reqs"></xref> includes a set of basic
requirements for all OAM tools to be used for MPLS-TP transport paths.
This includes the following:</t>
<t><list style="symbols">
<t><xref target="MPLS-TP OAM Reqs"></xref> 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 should rely
on the IP routing and forwarding capabilities. On the other hand, in
environments where IP functionality is not available, the OAM tools
must still be able to operate without dependence on IP forwarding
and routing.</t>
<t><xref target="MPLS-TP OAM Reqs"></xref> requires that all OAM
protocols support identification information, at least in the form
of IP addressing structure and be extensible to support additional
identification schemes.</t>
<t>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. Inherent in
this requirement is the principle that MPLS-TP OAM be independent of
any existing control-plane, although it should not preclude use of
the control-plane functionality.</t>
</list></t>
<t>In addition, the requirements for specific OAM functions will be
highlighted in the following sub-sections.</t>
</section>
<section title="Fault detection functionality">
<t>MPLS supports tools that provide basic fault detection functionality
for different forms of paths, as outlined in section 2 of this document.
These tools provide the basic functionality for an MPLS environment. The
transport environment requires certain additional functionality that is
outlined in the following subsections.</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 are generally run proactively, but may also be used
on-demand, either due to bandwidth considerations or for diagnoses of
a specific condition. Proactively <xref
target="MPLS-TP OAM Reqs"></xref> states that the function should
allow the MEPs to monitor the liveness and connectivity of a transport
path. In on-demand mode, this function should support monitoring
between the MEPs and, in addition, between a MEP and MIP.</t>
<t>The <xref target="MPLS-TP OAM Frwk"></xref> highlights the need for
the CC-V messages to include unique identification of the MEG that is
being monitored and the MEP that originated the message. The function,
both proactively and in on-demand mode, need to be transmitted at
regular rates pre-configured by the operator.</t>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used proactively by a path end-point
to report to its peer end-point that a defect is detected on a
bi-directional connection between them. <xref target="MPLS-TP OAM Reqs">
</xref> points out that this function may be applied to a unidirectional
LSP only if there a return path exists. <xref target="MPLS-TP OAM Frwk">
</xref> points out that this function is associated with the proactive
CC-V function.</t>
</section>
<section title="Route Tracing">
<t><xref target="MPLS-TP OAM Reqs"></xref> defines that there is a
need for functionality that would allow a path end-point to identify
the intermediate and end-points of the path. This function would be
used in on-demand mode. Normally, this path will be used for
bidirectional PW, LSP, and sections, however, unidirectional paths may
be supported only if a return path exists.</t>
</section>
<section title="Alarm Reporting">
<t>Alarm Reporting is a function used by an intermediate point of a
path, that becomes aware of a fault on the path, to report to the
end-points of the path. <xref target="MPLS-TP OAM Frwk"></xref>
states that this may occur as a result of a defect condition
discovered at a server sub-layer. This generates an Alarm Indication
Signal (AIS) that continues until the fault is cleared. The consequent
action of this function is detailed in <xref
target="MPLS-TP OAM Frwk" />.</t>
</section>
<section title="Client Failure Indication">
<t>Client Failure Indication (CFI) is defined in <xref
target="MPLS-TP OAM Reqs"></xref> to allow the propagation information
from one edge of the network to the other. The information concerns a
defect to a client, in the case that the client does not support alarm
notification.</t>
</section>
</section>
<section title="Performance Measurement Functionality">
<t>The current performance measurement tools defined in the IETF, outlined
in Section 2 of this document, do not directly address MPLS paths. In
addition, when extending MPLS to address the needs of the transport
community there is a need to support enhanced performance measurement
functionality, as detailed in the following sub-sections.</t>
<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>
<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>
</section>
</section>
<section title="Enhancing the existing toolset for MPLS-TP">
<section title="Gap Analysis">
<section title="OAM Infrastructure">
<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="BFD enhancements">
</section>
<section title="LSP Ping enhancements">
</section>
<section title="Performance Measurement enhancements">
</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 acknowledge the encouragement of the MPLS WG chairs
and the area directors in directing this work.</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></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></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.792.xml. -->
<!--Begin inclusion reference.RFC.4379 -->
<reference anchor="LSP Ping">
<front>
<title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures</title>
<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="February" year="2006" />
<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 octets="116872"
target="ftp://ftp.isi.edu/in-notes/rfc4379.txt" type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4379 -->
<!-- Begin inclusion reference.RFC.4385 -->
<reference anchor="PW ACH">
<front>
<title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN</title>
<author fullname="S. Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="L. Martini" initials="L." surname="Martini">
<organization></organization>
</author>
<author fullname="D. McPherson" initials="D." surname="McPherson">
<organization></organization>
</author>
<date month="February" year="2006" />
<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 octets="22440" target="ftp://ftp.isi.edu/in-notes/rfc4385.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.4385 -->
<!-- Begin inclusion reference.RFC.5085 -->
<reference anchor="PW VCCV">
<front>
<title>Pseudowire Virtual Circuit Connectivity Verification (VCCV):
A Control Channel for Pseudowires</title>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="December" year="2007" />
<abstract>
<t>This document describes Virtual Circuit Connectivity
Verification (VCCV), which provides a control channel that is
associated with a pseudowire (PW), as well as the corresponding
operations and management functions (such as connectivity
verification) to be used over that control channel. VCCV applies
to all supported access circuit and transport types currently
defined for PWs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5085" />
<format octets="67847" target="ftp://ftp.isi.edu/in-notes/rfc5085.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.draft.BASE.BFD -->
<reference anchor="BASE BFD">
<front>
<title>Bidirectional Forwarding Detection</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization></organization>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="February" year="2009" />
<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 fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Kiretti Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="Thomas Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="June" year="2008" />
<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 fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="February" year="2008" />
<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.BFD.multipoint -->
<reference anchor="bfdMultipoint">
<front>
<title>Bidirectional Forwarding Detection for Multipoint Networks</title>
<author fullname="Dave Katz" initials="D." surname="Katz">
<organization></organization>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="February" year="2009" />
<abstract>
<t>This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks. </t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-katz-ward-bfd-multipoint-02.txt" />
</reference>
<!-- End inclusion reference.draft.BFD.multipoint -->
<!-- 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 fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="June" year="2008" />
<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 fullname="Nitin Bahadur" initials="N." surname="Bahadur">
<organization></organization>
</author>
<author fullname="Kireeti Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<date month="June" year="2008" />
<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.RFC.4656.xml. -->
<reference anchor="RFC4656">
<front>
<title abbrev="OWAMP">A One-way Active Measurement Protocol</title>
<author fullname="Stanislav Shalunov" initials="S." surname="Shalunov">
<organization></organization>
</author>
<author fullname="Benjamin Teitelbaum" initials="B." surname="Teitelbaum">
<organization></organization>
</author>
<author fullname="Anatoly Karp" initials="A." surname="Karp">
<organization></organization>
</author>
<author fullname="Jeff Boote" initials="J." surname="Boote">
<organization></organization>
</author>
<author fullname="Matthew Zekauskas" initials="M." surname="Zekauskas">
<organization></organization>
</author>
<date month="September" year="2006" />
<abstract>
<t>The One-Way Active Measurement Protocol (OWAMP) measures
unidirectional characteristics such as one-way delay and one-way
loss. High-precision measurement of these one-way IP performance
metrics became possible with wider availability of good time sources
(such as GPS and CDMA). OWAMP enables the interoperability of these
measurements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4656" />
</reference>
<!-- End inclusion reference.RFC.4656.xml. -->
<!-- Begin inclusion reference.RFC.5357.xml. -->
<reference anchor="RFC5357">
<front>
<title abbrev="TWAMP">A Two-Way Active Measurement Protocol</title>
<author fullname="Kaynam Hedayat" initials="K." surname="Hedayat">
<organization></organization>
</author>
<author fullname="Roman Krzanowski" initials="R." surname="Krzanowski">
<organization></organization>
</author>
<author fullname="Al Morton" initials="A." surname="Morton">
<organization></organization>
</author>
<author fullname="Kiho Yum" initials="K." surname="Yum">
<organization></organization>
</author>
<author fullname="Jozef Babiarz" initials="J." surname="Babiarz">
<organization></organization>
</author>
<date month="Oct" year="2008" />
<abstract>
<t>The One-way Active Measurement Protocol (OWAMP), specified in RFC
4656, provides a common protocol for measuring one-way metrics
between network devices. OWAMP can be used bi-directionally to
measure one-way metrics in both directions between two network
elements. However, it does not accommodate round-trip or two-way
measurements. This memo specifies a Two-Way Active Measurement
Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip
measurement capabilities. The TWAMP measurement architecture is
usually comprised of two hosts with specific roles, and this allows
for some protocol simplifications, making it an attractive
alternative in some circumstances.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5357" />
</reference>
<!-- End inclusion reference.RFC.5357.xml. -->
<!-- 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 fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<author fullname="Malcolm Betts" initials="M." surname="Betts">
<organization></organization>
</author>
<author fullname="Dave Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="April" year="2009" />
<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 fullname="Italo Busi" initials="I." surname="Busi">
<organization></organization>
</author>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<date month="March" year="2009" />
<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 fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="April" year="2009" />
<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 fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<date month="June" year="2009" />
<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 fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="S. Sivabalan" initials="S." surname="Sivabalan">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="June" year="2009" />
<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 fullname="C. Srinivasan" initials="C." surname="Srinivasan">
<organization></organization>
</author>
<author fullname="A. Viswanathan" initials="A."
surname="Viswanathan">
<organization></organization>
</author>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<date month="June" year="2004" />
<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 octets="116872"
target="ftp://ftp.isi.edu/in-notes/rfc3813.txt" type="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 month="May" year="2006" />
<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-24 04:41:30 |