One document matched: draft-ietf-mpls-tp-oam-analysis-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-mpls-tp-oam-analysis-03.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="OAM Functions">OAM functions in MPLS based transport network</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="2011" />
<abstract>
<t>This document describes the outcome of the discussions on the
necessary OAM functionality for the first release of MPLS based transport
networks. The discussion is based on the set of requirements for Operations,
Administration, and Maintenance (OAM) for MPLS based transport networks
as defined in <xref target="MPLS-TP OAM Reqs"></xref>. An important
aspect was to evaluate whether existing OAM tools from the current MPLS
protocol suite can be used to fulfill these requirements. Eventually, the
purpose of the document is to map the set of functions to a set of tools
based on the existing OAM tool-set.</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 Segments, Label Switched Paths (LSPs) (network
infrastructure) and Pseudowires (PWs) (services).</t>
<t>The OAM solution developed by the joint IETF and ITU-T MPLS-TP project
has three objectives:</t>
<t><list style="symbols">
<t>The OAM tool-set should be developed based on existing MPLS
architecture, technology, and tool-sets.</t>
<t>It should be verified that the OAM tool-set for MPLS transport
networks should be aligned with the comparable tool-set in legacy
transport networks as much as possible.</t>
<t>The OAM tool-set developed for MPLS based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as documented
in <xref target="MPLS-TP OAM Reqs" />.</t>
</list></t>
<t>The discussion on the needed OAM tool-set took place, mainly, in the MPLS
Interoperability Design Team (the MEAD). A tool-set was agreed upon and was
reported to the MPLS working group in Stockholm (July 2009) during the IETF
meetings. This was also judged to be the working group consensus.</t>
<t>This document outlines these recommendations for the tool-set that
should be defined to fulfill the OAM functionality requirements as
documented in <xref target="MPLS-TP OAM Reqs" /> and <xref target=
"MPLS-TP OAM Frwk"></xref>. Based on the objectives cited above, it
was determined to base the MPLS-TP OAM tool-set on the following
existing MPLS tools:</t>
<t><list style="symbols">
<t>LSP-Ping as defined in <xref target="LSP Ping"></xref>.</t>
<t>Bidirectional Forwarding Detection (BFD) as defined in <xref
target="BASE BFD"></xref> and refined in <xref
target="MPLS BFD"></xref>.</t>
<t>ITU-T OAM for Ethernet tool-set as defined in <xref
target="Y.1731"></xref> this will be used for functionality
guidelines for the performance measurement tools that are not
currently supported in MPLS.</t>
</list> It should be noted that certain extensions and adjustments
may be made to the existing MPLS tools, in order to conform to the
transport environment and the requirements of MPLS based transport
networks.</t>
</section>
<section title="Organization of the document">
<t>Section 2 of the document reviews the requirements for MPLS-TP
OAM and shows how they are addressed by the top-level architectural
RFCs</t>
<t>Section 3 outlines the different functional tools that are required for
MPLS-TP OAM and references the documents that define the appropriate tools
based on the principles outlined above.</t>
<t>Section 4 provides the user with a cross-reference, pointing out which
tools are addressed by each of the OAM solutions RFCs.</t>
</section>
<section title="Contributing Authors">
<t>Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi
(Alcatel Lucent), Huub van Helvoort (Huawei)</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>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>G-ACH</c>
<c>Generic Associated Channel Header</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>PW</c>
<c>Pseudowire</c>
<c>RDI</c>
<c>Remote Defect Indication</c>
<c>SLA</c>
<c>Service Level Agreement</c>
<c>TLV</c>
<c>Type, Length, Value</c>
<c>VCCV</c>
<c>Virtual Circuit Connectivity Verification</c>
</texttable>
</section>
</section>
<section title="Basic OAM infrastructure functionality">
<t></t>
<t><xref target="MPLS-TP OAM Reqs"></xref> defines a set of requirements
on OAM architecture and general principles of operations which are
evaluated below:</t>
<t><xref target="MPLS-TP OAM Reqs"></xref> requires that<list style="symbols">
<t>OAM mechanisms in MPLS-TP are independent of the transmission media
and of the client service being emulated by the PW.</t>
<t>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 tool-set 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>all OAM protocols support identification information, at least in
the form of IP addressing structure and be extensible to support
additional identification schemes.</t>
<t>OAM packets and the user traffic are congruent (i.e. OAM packets
are transmitted in-band) and there is a need to differentiate OAM
packets from user-plane 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>
<t>a single OAM technology and consistent OAM capabilities for LSPs,
PWs, and Sections.</t>
<t>OAM packets may be directed to an intermediate point of a LSP/PW.</t>
</list></t>
<t>The following comprise the document-set that addresses the basic
requirements listed above:</t>
<t><list style="symbols">
<t>The <xref target="MPLS-TP OAM Frwk"></xref> document describes
the architectural framework for conformance to the basic requirements
listed above. It also defines the basic relationships between the
MPLS structures, e.g. LSP, PW, and the structures necessary for OAM
functionality, i.e. the Managed Entity Group, its End-points, and
Intermediate Points.</t>
<t>The <xref target="MPLS G-ACH"></xref> document specifies the use
of the MPLS-TP in- band control channel. This is modeled after the
VCCV channel described in <xref target="PW ACH"></xref> and allows
transporting the OAM messages congruently with the data traffic
while allowing the required identification of the packets. It is
expected that all of the OAM protocols will be used in conjunction
with this Generic Associated Channel.</t>
<!-- <t>The <xref target="MPLS-TP ACH TLV"></xref> document specifies a
basic set of TLV fields that could be used by different OAM
messages, in conjunction with the Generic Associated Channel, to
supply the additional parameter values necessary for the proper
functionality.</t>
-->
<t>The <xref target="MPLS TP Idents"></xref> document addresses the
need of MPLS-TP to support different addressing spaces. This
document describes different formats for addresses that could be
used to identify the transport entities in the network and
referenced by the different OAM protocols.</t>
</list></t>
</section>
<section title="MPLS-TP OAM Functions">
<t>The following sections discuss the OAM functions that are required in
<xref target="MPLS-TP OAM Reqs"></xref> and expanded upon in <xref
target="MPLS-TP OAM Frwk"></xref>.</t>
<section title="Continuity Check and Connectivity Verification">
<t>Continuity Check and Connectivity Verification (CC-V) are OAM
operations generally used in tandem, and compliment each other. These
functions are generally run pro-actively, but may also be used
on-demand, either due to bandwidth considerations or for diagnoses of
a specific condition. Pro-actively <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 pro-actively and in on-demand mode, needs to be transmitted at
regular transmission rates pre-configured by the operator.</t>
<section title="Documents for CC-V tools">
<t><xref target="Pro CC-V"></xref> defines the BFD extensions that
will be used for proactive CC-V applications. While <xref
target="Demand CV"></xref> provides the LSP-Ping extensions that
will be used to implement on-demand Connectivity Verification. Both
of these tools will be used together with the basic tools mentioned
above in section 2.</t>
</section>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used by a path end-point to
report 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 title="Documents for RDI">
<t>The <xref target="Pro CC-V"></xref> document includes an extension
for BFD that would include the RDI indication in the BFD format, and
a specification of how this indication is to be used.</t>
</section>
</section>
<section title="Route Tracing">
<t><xref target="MPLS-TP OAM Reqs"></xref> defines that there is a
need for functionality that would allow a path end-point to identify
the intermediate 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 title="Documents for Route Tracing">
<t>The <xref target="Demand CV"></xref> document that specifies the
LSP-Ping enhancements for MPLS-TP on-demand Connectivity
Verification includes information on the use of LSP-Ping for route
tracing of a MPLS-TP transport path.</t>
</section>
</section>
<section title="Alarm Reporting">
<t>Alarm Reporting is a function used by an intermediate point of a
path, 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"></xref>.</t>
<section title="Documents for Alarm Reporting">
<t>MPLS-TP defines a new protocol to address this functionality that
is documented in <xref target="Fault Mng"></xref>. This protocol
uses all of the basic mechanisms detailed in Section 2.</t>
</section>
</section>
<section title="Lock Reporting">
<t>Lock reporting, defined in <xref target="MPLS-TP OAM Reqs"></xref>,
is similar to the Alarm Reporting function described above. It is used
by an intermediate point to notify the end points of a transport path
that an administrative lock condition exists for this transport
path.</t>
<section title="Documents for Lock Reporting">
<t>MPLS-TP defines a new protocol to address this functionality that
is documented in <xref target="Fault Mng"></xref>. This protocol
uses all of the basic mechanisms detailed in Section 2.</t>
</section>
</section>
<!-- <section title="Diagnostic">
<t>The <xref target="MPLS-TP OAM Reqs"></xref> indicates that there is
need to provide a OAM function that would enable conducting different
diagnostic tests on a PW, LSP, or Section. The <xref
target="MPLS-TP OAM Frwk"></xref> provides two types of specific
tests to be used through this functionality:</t>
<t><list style="symbols">
<t>Throughput Estimation – allowing the provider to verify
the bandwidth/throughput of a transport path. This is an
out-of-service tool, that uses special packets of varying sizes to
test the actual bandwidth and/or throughput of the path.</t>
<t>Data-plane loopback – this out-of-service tool that
causes all traffic that reaches the target node, either a MEP or
MIP, to be looped back to the originating MEP. For targeting MIPs,
a co-routed bi-directional path is required.</t>
</list></t>
<t>This functionality will be further defined and developed in a future
release of MPLS-TP documentation.</t>
<section title="Documents for Diagnostic Testing">
<t>The functionality required for executing the various diagnostic tests is
described in the <xref target="Diagnostic"></xref> document that defines a new
G-ACH based protocol message that addresses the Throughput Estimation tool, and
also provides a platform for various flavors of testing functionality.</t>
</section>
</section> -->
<section title="Lock Instruct">
<t>The Lock Instruct function is an administrative control tool that
allows a path end-point to instruct its peer end-point to lock the
path. The tool is necessary to support single-side provisioning for
administrative locking, according to <xref target="MPLS-TP OAM Frwk" />.
This function is used on-demand.</t>
<section title="Documents for Lock Instruct">
<t>The <xref target="LiLoopback"></xref> document describes the
details of a new ACH based protocol format for this functionality.</t>
</section>
</section>
<section title="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 title="Documents for CFI">
<t>A new ACH-based protocol is described in <xref target="MPLS-TP CSF"></xref>
that addresses the functionality defined for client failure indication.</t>
</section>
</section>
<section title="Packet Loss Measurement">
<t>Packet Loss Measurement is required, by <xref
target="MPLS-TP OAM Reqs"></xref> to provide a quantification of the
packet loss ratio on a transport path. This is the ratio of the number
of user packets lost to the total number of user packets during a
defined time interval. To employ this function, <xref
target="MPLS-TP OAM Frwk"></xref> defines that the two end-points of
the transport path should exchange counters of messages transmitted
and received within a time period bounded by loss-measurement
messages. The framework warns that there may be small errors in the
computation that result from various issues.</t>
<section title="Documents for Packet Loss Measurement">
<t>The <xref target="Loss-Delay"></xref> document describes the protocol
formats and procedures for using the tool. The tool logic is based
on the behavior of the parallel function described in <xref
target="Y.1731"></xref>.</t>
</section>
</section>
<section title="Packet Delay Measurement">
<t>Packet Delay Measurement is a function that is used to measure
one-way or two-way delay of a packet transmission between a pair of
the end-points of a path (PW, LSP, or Section), as described in <xref
target="MPLS-TP OAM Reqs"></xref>. Where:</t>
<t><list style="symbols">
<t>One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of that packet by the destination
node.</t>
<t>Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.</t>
</list></t>
<t><xref target="MPLS-TP OAM Frwk"></xref> describes how the tool
could be performed (both in proactive and on-demand modes) for either
one-way or two-way measurement. However, it warns that the one-way
delay option requires precise time synchronization between the
end-points.</t>
<section title="Documents for Delay Measurement">
<t>The <xref target="Loss-Delay"></xref> document describes the protocol
formats and procedures for using the tool. The tool logic is based
on the behavior of the parallel function described in <xref
target="Y.1731"></xref>.</t>
</section>
</section>
</section>
<section title="MPLS-TP OAM documents guide">
<t>The complete MPLS-TP OAM protocol suite is covered by a small set of existing
IETF documents. This set of documents may be expanded in the future to cover
additional OAM functionality. in order, to allow the reader to understand this
set of documents a cross-reference of the existing documents for the initial
phase of the specification of MPLS based transport networks is provided.</t>
<t><xref target="MPLS G-ACH" /> provides a specification of the basic structure
of protocol messages for in-band data plane OAM in an MPLS environment.</t>
<t><xref target="MPLS TP Idents" /> provides definitions of different formats
that may be used within OAM protocol messages to identify the network elements
of a MPLS based transport network.</t>
<t><xref target="Pro CC-V" /> addresses the requirements for proactive use of
Continuity Check, Connectivity Verification, and Remote Defect Indication
functionality for MPLS transport networks.</t>
<t><xref target="Demand CV" /> addresses the requirements for activation of
the Connectivity Verification functionality between endpoints or between an
endpoint and intermediate point of a monitored domain of a transport path.</t>
<t><xref target="Fault Mng" /> specifies protocol messages that support the
functionality required to support Alarm Indication Signal and Lock Reporting
required for MPLS transport networks.</t>
<t><xref target="MPLS-TP CSF" /> addresses the requirements to support a Client
Signal Fail indication by clients that are being emulated by the MPLS transport
services.</t>
<t><xref target="LiLoopback" /> specifies protocol messages that support the
functionality required for the Lock Instruct command and activation of the
Loopback functionality for transport paths in MPLS networks.</t>
<t><xref target="Loss-Delay" /> addresses the requirements for performance
measurement functionality for MPLS transport networks. The protocol defined
supports both loss and delay measurement functions for the transport paths.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations. Security considerations for each function in the
OAM tool-set need to be documented in the document that specifies
the particular functionality.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The editors wish to thank the MPLS-TP Design Team members, from both
the IETF and ITU-T leadership teams, in formulating the recommendations
documented here. In particular, we would like to thank Loa Andersson,
Huub van Helvoort, and the Area Directors for their suggestions and
enhancements to the text.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--Begin inclusion reference.RFC.4379 -->
<reference anchor="LSP Ping">
<front>
<title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures</title>
<author fullname="K. Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="G. Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="February" year="2006" />
<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 network, 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.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="RFC" value="5880" />
</reference>
<!-- End inclusion reference.draft.BASE.BFD -->
<!-- Begin inclusion reference.draft.MPLS.BFD -->
<reference anchor="MPLS BFD">
<front>
<title>BFD For MPLS LSPs</title>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Kiretti Kompella" initials="K." surname="Kompella">
<organization></organization>
</author>
<author fullname="Thomas Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="June" year="2008" />
<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="RFC" value="5884" />
</reference>
<!-- End inclusion reference.draft.MPLS.BFD -->
<!-- Begin inclusion reference.draft.TP.Identifiers -->
<reference anchor="MPLS TP Idents">
<front>
<title>MPLS-TP Identifiers</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="March" year="2010" />
<abstract>
<t>This document specifies identifiers for MPLS-TP objects.
Included are identifiers conformant to existing ITU conventions
and identifiers which are compatible with existing IP, MPLS,
GMPLS, and Pseudowire definitions.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-identifiers-01.txt" />
</reference>
<!-- End inclusion reference.draft.TP.Identifiers -->
<!-- Begin inclusion reference.draft.Proactive.CCV -->
<reference anchor="Pro CC-V">
<front>
<title>Proactive Connection Verification, Continuity Check and
Remote Defect indication for MPLS Transport Profile</title>
<author fullname="David Allan" initials="D." surname="Allan">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<date month="June" year="2010" />
<abstract>
<t>Continuity Check (CC), Proactive Connectivity Verification (CV)
and Remote Defect Indication (RDI) functionalities required for
are MPLS-TP OAM.</t>
<t>Continuity Check monitors the integrity of the continuity of
the path for any loss of continuity defect. Connectivity
verification monitors the integrity of the routing of the path
between sink and source for any connectivity issues. RDI enables
an End Point to report, to its associated End Point, a fault or
defect condition that it detects on a PW, LSP or Section.</t>
<t>This document specifies methods for proactive CV, CC, and RDI
for MPLS-TP Label Switched Path (LSP), PWs and Sections using
Bidirectional Forwarding Detection (BFD).</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-cc-cv-rdi-00.txt" />
</reference>
<!-- End inclusion reference.draft.Proactive-ccv -->
<!-- Begin inclusion reference.draft.OnDemand.CV -->
<reference anchor="Demand CV">
<front>
<title>MPLS on-demand Connectivity Verification, Route Tracing and
Adjacency Verification</title>
<author fullname="Nitin Bahadur" initials="N." surname="Bahadur">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Eric Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="June" year="2010" />
<abstract>
<t>LSP Ping for MPLS tunnels.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-on-demand-cv-00" />
</reference>
<!-- End inclusion reference.draft.OnDemand.CV -->
<!-- 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-05" />
</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>
<author fullname="David Allan" initials="D." surname="Allan">
<organization></organization>
</author>
<date month="July" year="2010" />
<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-framework-07" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM.Framework -->
<!-- Begin inclusion reference.draft.MPLS.TP.Reqs -->
<reference anchor="MPLS-TP Reqs">
<front>
<title>Requirements for the Transport Profile of MPLS</title>
<author fullname="Ben Niven-Jenkins" initials="B."
surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="April" year="2009" />
<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.draft.Fault.Manage -->
<reference anchor="Fault Mng">
<front>
<title>MPLS Fault Management OAM</title>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="Annamaria Fulignoli" initials="A."
surname="Fulignoli">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M."
surname="Vigoureux">
<organization></organization>
</author>
<date month="March" year="2010" />
<abstract>
<t>This draft specifies OAM messages to indicate service
disruptive conditions for MPLS Transport Profile (MPLS-TP) Label
Switched Paths (LSPs). The notification mechanism employs a
generic method for a service disruptive condition to be
communicated to a Maintenance End Point (MEP). An MPLS Operation,
Administration, and Maintenance (OAM) channel is defined along
with messages to communicate various types of service disruptive
conditions.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-fault-00" />
</reference>
<!-- End inclusion reference.draft.Fault.Manage -->
<!-- Begin inclusion reference.draft.Diagnostic -->
<!-- <reference anchor="Diagnostic">
<front>
<title>Diagnostic tool-test for MPLS transport profile</title>
<author fullname="Feng Huang" initials="F." surname="Huang">
<organization></organization>
</author>
<author fullname="Lieven Levrau" initials="L." surname="Levrau">
<organization></organization>
</author>
<author fullname="Han LI" initials="H." surname="LI">
<organization></organization>
</author>
<author fullname="Ruiquan Jing" initials="R." surname="Jing">
<organization></organization>
</author>
<date month="May" year="2010" />
<abstract>
<t>This document describes a Multi-Protocol Label Switching Transport
Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
diagnostic tool-TST (test), which is used to perform one-way, or two
way on-demand out-of-service measuring throughput or in-service
diagnostics tests for verifying throughput.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-flh-mpls-tp-oam-diagnostic-test-01" />
</reference>
<!-- End inclusion reference.draft.Diagnostic -->
<!-- Begin inclusion reference.draft.Admin.Commands -->
<reference anchor="LiLoopback">
<front>
<title>MPLS Transport Profile Lock Instruct and Loopback Functions</title>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="Martin Vigoureux" initials="M." surname="Vigoureux">
<organization></organization>
</author>
<author fullname="Xuehui Dai" initials="X." surname="Dai">
<organization></organization>
</author>
<date month="September" year="2010" />
<abstract>
<t>This document specifies an extension to MPLS Operation, administration,
and Maintenance (OAM) to operate an MPLS Transport Profile (MPLS-TP)
Label Switched Path (LSP), bi-directional RSVP-TE tunnels, pseudowires
(PW), or Multi-segment PWs in loopback mode for management purpose. This
extension includes mechanism to lock and unlock MPLS-TP Tunnels (i.e.
data and control traffic) and can be used to loop all traffic (i.e, data
and control traffic) at a specified LSR on the path of the MPLS-TP LSP
back to the source.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-li-lb-00" />
</reference>
<!-- End inclusion reference.Admin.Commands -->
<!-- Begin inclusion reference.draft.Client.Indication -->
<reference anchor="MPLS-TP CSF">
<front>
<title>Indication of Client Failure in MPLS-TP</title>
<author fullname="Jia He" initials="J." surname="He">
<organization></organization>
</author>
<author fullname="Han Li" initials="H." surname="LI">
<organization></organization>
</author>
<author fullname="Elisa Bellagamba" initials="E." surname="Bellagamba">
<organization></organization>
</author>
<date month="July" year="2010" />
<abstract>
<t>This document describes a Multi-Protocol Label Switching Transport
Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
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>
</abstract>
</front>
<seriesInfo name="ID" value="draft-he-mpls-tp-csf-00" />
</reference>
<!-- End inclusion reference.draft.Client.Indication -->
<!-- Begin inclusion reference.draft.Loss.Delay -->
<reference anchor="Loss-Delay">
<front>
<title>Packet Loss and Delay Measurement for the MPLS Transport
Profile</title>
<author fullname="Dan Frost" initials="D." surname="Frost">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="April" year="2010" />
<abstract>
<t>An essential Operations, Administration and Maintenance
requirement of the MPLS Transport Profile (MPLS-TP) is the ability
to monitor performance metrics for packet loss and one-way and
two-way delay for MPLS-TP pseudowires, Label Switched Paths, and
Sections. This document specifies protocol mechanisms to
facilitate the efficient and accurate measurement of these
performance metrics.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-loss-delay-00" />
</reference>
<!-- End inclusion reference.draft.Loss.Delay -->
<!--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-22 23:56:29 |