One document matched: draft-ietf-mpls-tp-oam-analysis-02.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-02.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="MPLS-TP OAM Analysis">MPLS-TP OAM Analysis</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 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"></xref>, 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 map the set
of functions to a set of tools based on the existing OAM toolset.</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). One of the mandates
of the joint (IETF and ITU-T) MPLS-TP work-item is the objective of
developing a Transport Profile is to base the toolset on existing MPLS
technologies. In addition, <xref target="MPLS-TP Reqs"></xref>
indicates the need for the OAM toolset for MPLS-TP to be fully
interoperable with existing MPLS OAM tools.</t>
<t>The purpose of this document is to outline the recommendations of
the MPLS-TP design team and confirmed by the working group for the
toolset that should be defined to fulfill the OAM functionality
requirements as documented in <xref target="MPLS-TP OAM Reqs"></xref>
and <xref target="MPLS-TP OAM Frwk"></xref>. Based on the principles
cited above, it was determined to base the MPLS-TP OAM toolset 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 toolset 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-TP.</t>
</section>
<section title="Organization of the document">
<t>Section 2 of the document provides references to the basic OAM tools
that are provided for MPLS-TP OAM.</t>
<t>Section 3 outlines the different tools that are required for
MPLS-TP OAM and references the documents that will define the
appropriate tools based on the principles outlined above.</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><list style="symbols">
<t><xref target="MPLS-TP OAM Reqs"></xref> requires that OAM
mechanisms in MPLS-TP are independent of the transmission media and
of the client service being emulated by the PW.</t>
<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>
<t><xref target="MPLS-TP OAM Reqs"></xref> requires a single OAM
technology and consistent OAM capabilities for LSPs, PWs, and
Sections.</t>
<t><xref target="MPLS-TP OAM Reqs"></xref> requires allowing OAM
packets to 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 architecural 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 required OAM functions that were
identified 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 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 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 and
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 corouted bi-directional path is required.</t>
</list></t>
<section title="Documents for Diagnostic Testing">
<t>These diagnostic functions are being defined in a merge of existing
separate individual drafts. The merged <!-- <xref target="Diagnostic"></xref> -->
document will define a new G-ACH based protocol message that addresses
the Throughput Estimation tool, and also provide various flavors of loopback
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
administartive locking, according to <xfer
target="MPLS-TP OAM Frwk" />. This function is used on-demand.</t>
<section title="Documents for Lock Instruct">
<t>Work is being done on a document <!-- <xref target="Admin Commands"></xref> -->
that will specify the new ACH based protocol format for this tool.</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>Work is being done on a document <!-- <xref target="MPLS-TP CFI"></xref> -->
that will specify the new ACH based protocol format for this tool.</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> 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> 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 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 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="Informative 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 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.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.Idnetifiers -->
<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 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.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>MPLS-TP OAM Diagnostic Test Tools</title>
<author fullname="George Swallow" initials="G." surname="Swallow">
<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="Marin Vigoureux" initials="M." surname="Vigoureux">
<organization></organization>
</author>
<date month="August" year="2010" />
<abstract>
<t>Specification of the protocol messages and functionality for
MPLS-TP OAM throughput validation and data-plane loopback
tools.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-diagnostic-test-00" />
</reference>
<!-- End inclusion reference.draft.Diagnostic -->
<!-- Begin inclusion reference.draft.Admin.Commands -->
<!--
<reference anchor="Admin Commands">
<front>
<title>MPLS-TP Administrative OAM Commands</title>
<author fullname="John Drake" initials="J." surname="Drake">
<organization></organization>
</author>
<author fullname="Sami Boutros" initials="S." surname="Boutros">
<organization></organization>
</author>
<author fullname="Eric Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="August" year="2010" />
<abstract>
<t>Provides the description of the MPLS-TP Lockout Instruct
message and functionality</t>
</abstract>
</front>
<seriesInfo name="ID"
value="draft-ietf-mpls-tp-administrative-cmnds-00" />
</reference>
<!-- End inclusion reference.Admin.Commands -->
<!-- Begin inclusion reference.draft.Client.Indication -->
<!--
<reference anchor="MPLS-TP CFI">
<front>
<title>MPLS TP Client Failure Indication</title>
<author fullname="Annamaria Fulignoli" initials="A."
surname="Fulignoli">
<organization></organization>
</author>
<author fullname="Eric Gray" initials="E." surname="Gray">
<organization></organization>
</author>
<date month="August" year="2010" />
<abstract>
<t>Provides the description of the MPLS-TP CFI message and
functionality.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-cfi-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-frost-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:57:03 |