One document matched: draft-ietf-mpls-tp-oam-analysis-01.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-01.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="MPLS-TP OAM Analysis">MPLS-TP OAM Analysis</title>
<author fullname="Nurit Sprecher" initials="N." role="editor"
surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region></region>
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Huub van Helvoort" initials="H." role="editor"
surname="van Helvoort">
<organization>Huawei</organization>
<address>
<postal>
<street>Kolkgriend 38, 1356 BC Almere</street>
<city />
<region />
<code />
<country>Netherlands</country>
</postal>
<email>hhelvoort@huawei.com</email>
<phone>+31 36 5316076</phone>
</address>
</author>
<author fullname="Elisa Bellagamba" initials="E." role=""
surname="Bellagamba">
<organization>Ericsson</organization>
<address>
<postal>
<street>6 Farogatan St</street>
<city>Stockholm</city>
<region />
<code>164 40</code>
<country>Sweden</country>
</postal>
<email>elisa.bellagamba@ericsson.com</email>
<phone>+46 761440785</phone>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y." role=""
surname="Weingarten">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>yaacov.weingarten@nsn.com</email>
<phone>+972-9-775 1827</phone>
</address>
</author>
<date 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 recommend
which of the existing tools should be extended and what new tools should
be defined to support the set of OAM requirements for MPLS-TP. This
document reports the conclusions of the MPLS-TP design team discussions
concerning the MPLS-TP OAM tools at IETF75.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Scope">
<t>OAM (Operations, Administration, and Maintenance) plays a
significant role in carrier networks, providing methods for fault
management and performance monitoring in both the transport and the
service layers in order to improve their ability to support services
with guaranteed and strict Service Level Agreements (SLAs) while
reducing their operational costs.</t>
<t><xref target="MPLS-TP Reqs"></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) and
Pseudowires (PWs) (services).</t>
<t>The purpose of this document is to analyze the OAM requirements and
evaluate whether existing OAM tools defined for MPLS can be used to
meet the requirements, identify which tools need to be extended to
comply with the requirements, and which new tools need to be defined.
We also take the ITU-T OAM toolset, as defined in <xref
target="Y.1731"></xref>, as a candidate to base these new tools upon.
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>) and
Virtual Circuit Connectivity Verification (VCCV) (defined in <xref
target="PW VCCV"></xref> and <xref target="VCCV BFD"></xref>), and the
ITU-T OAM toolset defined in <xref target="Y.1731"></xref>.</t>
<t>This document reports the conclusions of the MPLS-TP design team
discussions on the MPLS-TP OAM tools at IETF75 and the guidelines that
were agreed. The guidelines refer to a set of existing OAM tools that
need to be enhanced to fully support the MPLS-TP OAM requirements and
identify new tools that need to be defined. The organizational
structure of the documents on MPLS-TP OAM tools was also discussed and
agreed at IETF75 and is described later in this document.</t>
</section>
<section title="Organization of the document">
<t>Sections 1.4 – 1.8 provide an overview of the existing MPLS
tools.</t>
<t>Section 2 of the document analyzes the requirements that are
documented in <xref target="MPLS-TP OAM Reqs"></xref> and provides
basic principles of operation for the OAM functionality that is
required.</t>
<t>Section 3 evaluates which existing tools can provide coverage for
the different OAM functions that are required to support MPLS-TP.</t>
<t>The recommendations are summarized in section 4, and reflect the
guidelines which were agreed by the MPLS-TP design team during the
meetings at IETF 75. These guidelines relate to the functionality
could be covered by the existing toolset and what extensions or new
tools would be needed in order to provide full coverage of the OAM
functionality for MPLS-TP.</t>
<t>The OAM tools for MPLS-TP OAM will be defined in a set of
documents. Section 5 describes the organization of this set of
documents as agreed by the MPLS-TP design team at IETF75.</t>
</section>
<section title="Contributing Authors">
<t>Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi (Alcatel
Lucent)</t>
</section>
<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 title="ITU Recommendation Y.1731">
<t><xref target="Y.1731"></xref> specifies a set of OAM procedures and
related packet data unit (PDU) formats that meet the transport network
requirements for OAM. These PDU and procedures address similar
requirements to those outlined in <xref
target="MPLS-TP OAM Reqs"></xref>.</t>
<t>The PDU and procedures defined in <xref target="Y.1731"></xref> are
described for an Ethernet environment, with the appropriate
encapsulation for that environment. However, the actual PDU formats
are technology agnostic and could be carried over different
encapsulations, e.g. VCCV control channel. The OAM procedures,
likewise, could be supported by MPLS-TP nodes just as they are
supported by Ethernet nodes.</t>
<t><xref target="Y.1731"></xref> describes procedures to support the
following OAM functions:</t>
<t><list style="symbols">
<t>Connectivity and Continuity Monitoring – for pro-active
mode end-to-end checking</t>
<t>Loopback functionality – to verify connectivity to
intermediate nodes in an on-demand mode</t>
<t>Link Trace – provides information on the intermediate
nodes of the path being monitored, may be used for fault
localization. This is activated in an on-demand mode.</t>
<t>Alarm Indication Signaling – for alarm suppression in
case of faults that are detected at the server layer, activated
pro-actively.</t>
<t>Remote Defect Indication – as part of the Connectivity
and Continuity Monitoring packets, performed pro-actively</t>
<t>Locked Signal – for alarm suppression in case of
administrative locking at the server layer. This function is
performed pro-actively.</t>
<t>Performance monitoring – including measurement of packet
delays both uni and bi-directional (on-demand), measurement of the
ratio of lost packets (pro-active), the effective bandwidth that
is supported without packet loss, and throughput measurement.</t>
</list></t>
<t>The PDU defined in <xref target="Y.1731"></xref> includes various
information elements (fields) including information on the MEG-Level,
etc. Addressing of the PDU as defined in <xref target="Y.1731"></xref>
is based on the MAC Address of the nodes, which would need to be
adjusted to support other addressing schemes. The addressing
information is carried in <Type, Length, Value> (TLV) fields
that follow the actual PDU. In the LBM PDU the MAC address is used to
identify the MIP to which the message is intended</t>
</section>
<section title="Acronyms">
<texttable 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>
<section title="Architectural requirements and general principles of operation">
<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" /> requires that OAM mechanisms
in MPLS-TP are independent of the transmission media and of the
client service being emulated by the PW. The existing tools comply
with this requirement.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires that the MPLS-TP OAM
MUST be able to support both an IP based and non-IP based
environment. If the network is IP based, i.e. IP routing and
forwarding are available, then the MPLS-TP OAM toolset MUST be able
to operate by relying on the IP routing and forwarding capabilities.
All of the existing MPLS tools (i.e. LSP Ping, VCCV Ping, MPLS BFD,
and VCCV BFD) can support this functionality. The Y.1731 toolset
does not specifically support this functionality, but rather relies
on underlying technologies for forwarding. The forwarding could also
be supported over IP, e.g. by using a VCCV extension. Note that some
of the MPLS-TP tools such as Alarm Report are very transport
oriented and may not support IP functionality.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires that MPLS-TP OAM MUST
be able to operate without IP functionality and without relying on
control and/or management planes. It is required that OAM
functionality MUST NOT be dependent on IP routing and forwarding
capabilities. Except for the LSP Ping operation of verifying the
data-plane vs. the control-plane, the existing tools do not rely on
control and/or management plane, however the following should be
observed regarding the reliance on IP functionality:</t>
<list style="symbols">
<t>LSP Ping, VCCV Ping, and MPLS BFD make use of IP header
(UDP/IP) and do not completely comply with the requirement. In the
on-demand mode, LSP Ping also may use IP forwarding to reply back
to the source router. This dependence on IP, has further
implications concerning the use of LSP Ping as the bootstrap
mechanism for BFD for MPLS. There are extensions to LSP-Ping that
are under discussion that allow LSP-Ping to restrict replies to
the backside of a bidirectional LSP.</t>
<t>VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
for PWs and can comply with the requirement.</t>
<t>Y.1731 PDU are technology agnostic and thereby not dependent on
IP functionality. These PDU could be carried by VCCV or G-ACH
control channels.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires that OAM tools for
fault management do not rely on user traffic, and the existing MPLS
OAM tools and Y.1731 already comply with this requirement.</t>
<t>It is also required that OAM packets and the user traffic are
congruent (i.e. OAM packets are transmitted in-band) and there is a
need to differentiate OAM packets from user-plane ones.</t>
<list style="symbols">
<t>For PWs, VCCV provides a control channel that can be associated
with each PW which allows sending OAM packets in band of PWs and
allow the receiving end-point to intercept, interpret, and process
them locally as OAM messages. VCCV defines different VCCV
Connectivity Verification Types for MPLS (like ICMP Ping, LSP Ping
and IP/UDP encapsulated BFD and PW-ACH encapsulated BFD).</t>
<t>Currently there is no distinct OAM payload identifier in MPLS
shim. BFD and LSP Ping packets for LSPs are carried over UDP/IP
and are addressed to the loopback address range. The router at the
end-point intercepts, interprets, and processes the packets. <xref
target="MPLS G-ACH" /> generalizes the use of the PW ACH and
enables provision of control channels at the MPLS LSP and sections
levels. This new mechanism would support carrying the existing
MPLS OAM messages or the Y.1731 messages at the LSP and the
section levels to be transmitted over the G-ACH.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires that the MPLS-TP OAM
mechanism allows the propagation of AC (Attachment Circuit) failures
and their clearance across a MPLS-TP domain</t>
<list style="symbols">
<t>BFD for VCCV supports a mechanism for "Fault detection and
AC/PW Fault status signaling." This can be used for both IP/UDP
encapsulated or PW-ACH encapsulated BFD sessions, i.e. by setting
the appropriate VCCV Connectivity Verification Type.This mechanism
could support this requirement. Note that in the PWE3 WG there are
two proposals regarding how to transmit the AC failures over an
ACH that may be applicable to this requirement.</t>
</list>
<t><xref target="MPLS-TP OAM Reqs" /> requires a single OAM
technology and consistent OAM capabilities for LSPs, PWs, and
Sections. The existing set of tools defines a different way of
operating the OAM functions (e.g. LSP Ping to bootstrap MPLS BFD vs.
VCCV). Currently, the Y.1731 functionality is defined for Ethernet
paths, and the procedures could readily be redefined for the various
MPLS-TP path concepts.</t>
<t><xref target="MPLS-TP OAM Reqs" /> requires allowing OAM packets
to be directed to an intermediate point of a LSP/PW. Technically,
this could be supported by the proper setting of the TTL value. It
is also recommended to include the identifier of the intermediate
point within the OAM message to allow the intermediate point to
validate that the message is really intended for it. The information
can be included in an ACH-TLV according to the definitions in <xref
target="MPLS-TP ACH TLV" />. The applicability of such a solution
needs to be examined per OAM function. For details, see below.</t>
<t><xref target="MPLS-TP OAM Reqs" /> suggests that OAM messages MAY
be authenticated. BFD defines support for optional authentication
fields using different authentication methods as defined in <xref
target="BASE BFD" />. Other tools should support this capability as
well. Y.1731 functionality uses the identification of the path for
authentication. Authentication information could be included in an
optional TLV field according to the definitions in <xref
target="MPLS-TP ACH TLV" /> when not available in the OAM PDU.</t>
</list></t>
<section title="Architectural and Principles of Operation – Recommendations and Guidelines">
<t>Based on the requirements analysis above, the following guidelines
should be followed to create an OAM environment that could more fully
support the requirements cited:</t>
<t><list style="symbols">
<t>Define a generalized addressing scheme that can also support
unique identification of the monitored paths (or connections).</t>
<t>Use G-ACH for LSP and section levels.</t>
<t>Define architectural element that is based on LSP hierarchy to
apply the mechanisms to segments and concatenated segments.</t>
<t>Apply BFD to these new mechanisms using the control channel
encapsulation, as defined above – allowing use of BFD for
MPLS-TP independent of IP functionality. This could be used to
address the CC-V functionality, described below.</t>
<t>Similarly, LSP Ping could be extended to use only the LSP path
(in both directions) without IP Forwarding. Addressing for PW can
be included by using the VCCV mechanism. LSP Ping could be used to
address the CC-V, Route Tracing, RDI, and Lock/Alarm Reporting
functionality cited in the requirements.</t>
<t>The Y.1731 PDU set could be used as a basis for defining the
information units to be transmitted over the G-ACH. The actual
procedures and addressing schemes would need to be adjusted for
the MPLS-TP environment.</t>
<t>Define a mechanism that could be used to idnetify an
intermediate point of a path in a unique way, to support the
maintenance functions. This addressing should be flexible to allow
support for different addressing schemes, and would supplement the
TTL exception mechanism to allow an OAM packet to be intercepted
by intermediate nodes.</t>
</list></t>
<t>Creating these extensions/mechanisms would fulfill the following
architectural requirements, mentioned above:</t>
<t><list style="symbols">
<t>Independence of IP forwarding and routing, when needed.</t>
<t>OAM packets should be transmitted in-band.</t>
<t>Support a single OAM technology for LSP, PW, and Sections.</t>
</list></t>
<t>In addition, the following additional requirements can be
satisfied:</t>
<t><list style="symbols">
<t>Provide the ability to carry other types of communications
(e.g., APS, Management Control Channel (MCC), Signaling Control
Channel (SCC)), by defining new types of communication channels
for PWs, Sections, and LSPs.</t>
<t>The design of the OAM mechanisms for MPLS-TP MUST allow the
ability to support vendor specific and experimental OAM
functions.</t>
</list></t>
</section>
</section>
<section title="MPLS-TP OAM Functions">
<t>The following sections discuss the required OAM functions that were
identified in <xref target="MPLS-TP OAM Reqs"></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 may be split into separate mechanisms. Together they are
used to detect loss of traffic continuity and misconnections between
path end-points and are useful for applications like Fault Management,
Performance Monitoring and Protection Switching, etc. To guarantee
that CC-V can identify misconnections from cross-connections it is
necessary that the tool use network-wide unique identifiers for the
path that is being checked in the session.</t>
<section title="Existing tools">
<t>LSP Ping provides much of the functionality required for
co-routed bidirectional LSPs. As observed above, LSP Ping may be
operated in both asynchronous and on-demand mode. Addressing is
based on the full FEC identification that provides a unique
identifier, and the basic functionality only requires support for
the loopback address range in each node on the LSP path.</t>
<t>BFD defines functionality that can be used to support the
pro-active OAM CC-V function when operated in the asynchronous mode.
However, the current definition of basic BFD is dependent on use of
LSP Ping to bootstrap the BFD session. Regarding the connectivity
functional aspects, basic BFD has a limitation that it uses only
locally unique (to each node) session identifiers.</t>
<t>VCCV can be used to carry either LSP Ping or BFD packets that are
not IP/UDP encapsulated for CC-V on a PW. Note that PW
termination/switching points use only locally unique (to each node)
labels. The PW label identifies the path uniquely only at the LSP
level.</t>
<t>Y.1731 provides functionality for all aspects of CC-V for an
Ethernet environment, this could be translated for the MPLS-TP
environment. The CCM PDU defined in <xref target="Y.1731"></xref>
includes the ability to set the frequency of the messages that are
transmitted, and provides for attaching the address of the path (in
the Ethernet case – the MEG Level) and a sequencing number to
verify that CCM messages were not dropped.</t>
</section>
<section title="Gap analysis">
<t>LSP Ping could be used to cover the cases of co-routed
bidirectional LSPs. However, there is a certain amount of
computational overhead involved with use of LSP Ping (as was
observed in sec 1.1), the verification of the control-plane, and the
need to support the loopback functionality at each intermediate
node. LSP Ping uses a fully qualified LSP identifier, and when used
in conjunction with VCCV would use the PW label to identify the
transport path. LSP Ping can be extended to bypass the verification
of the control plane</t>
<t>BFD could be extended to fill the gaps indicated above. The
extension would include: <list style="symbols">
<t>A mechanism should be defined to carry BFD packets over LSP
without reliance on IP functionality.</t>
<t>A mechanism should be defined to bootstrap BFD sessions for
MPLS that is not dependent on UDP.</t>
<t>BFD needs to be used in conjunction with "globally" unique
identifiers for the path or ME being checked to allow
connectivity verfication support. There are two possibilities,
to allow BFD to support this new type of identifier –
<list style="symbols">
<t>Change the semantics of the two Discriminator fields that
exist in BFD and have each node select the ME unique
identifier. This may have backward compatibility
implications.</t>
<t>Create a new optional field in the packet carrying the
BFD that would identify the path being checked, in addition
to the existing session identifiers.</t>
</list></t>
<t>Extensions to BFD would be needed to cover P2MP
connections.</t>
</list></t>
<t>Use of the Y.1731 functionality is another option that could be
considered. The basic PDU for CCM includes (in the flags field) an
indication of the frequency of the packets [eliminating the need to
"negotiate" the frequency between the end-points], and also a flag
used for RDI. The procedure itself would need adaptation to comply
with the MPLS environment.</t>
<t>An additional option would be to create a new tool that would
give coverage for both aspects of CC-V according to the requirements
and the principles of operation (see section 2.1). This option is
less preferable.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend LSP Ping to fully support the on-demand Connectivity
Verification function resolving the gaps described above. Extend BFD
to support proactive Continuity Check & Connectivity
Verification (CC-V) resolving the gaps described above.</t>
<t>Note that <xref target="MPLS BFD"></xref> defines a method for
using BFD to provide verification of multipoint or multicast
connectivity.</t>
</section>
</section>
<section title="Alarm Reporting">
<t>Alarm Reporting is a function that is used by an intermediate point
in a path to notify the end-points of the path of a fault or defect
condition indirectly affecting that path. Such information may be used
by the endpoints, for example, to suppress alarms that may be
generated by maintenance end-points of the path. This function should
also have the capability to differentiate an administrative lock from
a failure condition at a different execution level.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this
function. Y.1731 does define a PDU and procedure for this
functionality.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a new tool and PDU to support Alarm Reporting. The PDU
should be transmitted over a G-ACH. The frequency of transmision
after the alarm is raised and the continued frequency until it is
cleared should be indicated in the definition.</t>
<t>Describe also how the Alarm Reporting functionality may be
supported in the control-plane and management-plane.</t>
</section>
</section>
<section title="Diagnostic">
<t>A diagnostic test is a function that is used between path
end-points to verify bandwidth throughput, packet loss, bit errors,
etc. This is usually performed by sending packets of varying sizes at
increasing rates (until the limits of the service level) to measure
the actual utilization.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this
function. <xref target="Y.1731"></xref> describes a function that is
dependent on sending a series of TST packets (this is a PDU whose
size can be varied) at differing frequencies.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a new tool and PDU to support Diagnostic.</t>
</section>
</section>
<section title="Route Tracing">
<t>Functionality of route determination is used to determine the route
of a connection across the MPLS transport network. <xref
target="MPLS-TP OAM Reqs"></xref> defines that this functionality MUST
allow a path end-point to identify the intermediate and end-points of
the path. This functionality MUST support co-routed bidirectional
paths, and MAY support associated bidirectional and unidirectional p2p
paths, as well as p2mp unidirectional paths. Unidirectional path
support is dependent on the existence of a return path to allow the
original end-point to receive the trace information.</t>
<section title="Existing tools">
<t>LSP Ping supports a trace route function that could be used for
bidirectional paths. Support of unidirectional paths would be
dependent on the ability of identifying a return path.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend LSP Ping to support the Route Trace functionality and to
address additional options, i.e. PW and p2mp unidirectional LSP.</t>
</section>
</section>
<section title="Loopback tool">
<t>Editor's note: In recent discussions a requirement was raised to
support multiple maintenance points on a single node and the
definition of the Loopback function that would appropriately test
theconnectivity of these MP in order to identify fault location. This
functionality must be more fully specified in the OAM Framework
document before further analysis.</t>
</section>
<section title="Lock Instruct">
<t>The Lock instruct function allows the system to block off
transmission of data along a LSP. When a path end-point receives a
command, e.g. from the management system, that the path is blocked,
the end-point informs the far-end that the path has been locked and
that no data should be transmitted. This function is used
on-demand.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this
function, but LSP Ping could be extended to support this
functionality between the path endpoints. Y.1731 does define a PDU
and procedure for this functionality.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend LSP Ping to support Lock instruct. The frequency at which
these messages are transmitted until the lock situation is cleared,
should be clearly indicated.</t>
</section>
</section>
<section title="Lock Reporting">
<t>Lock reporting is used by an intermediate point to notify the end
points of a transport path (that the intermediate point is a member
of) that an external lock condition exits for this transport path.
This function is used proactively.</t>
<section title="Existing tools">
<t>There is no mechanism defined in neither the IETF nor in Y.1731
to support this function.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a new tool and PDU to support Lock reporting. This tool
could be designed similarly to the Alarm Reporting tool (described
above), but would need to be initiated by an intermediate point of
the transport path.</t>
</section>
</section>
<section title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used by a path end-point to
notify its peer end-point that a defect, usually a unidirectional
defect, is detected on a bi-directional connection between them.</t>
<t>This function should be supported in pro-active mode.</t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to fully support this
functionality, however BFD supports a mechanism of informing the
far-end that the session has gone down, and the Diagnostic field
indicates the reason. Similarly, when LSP Ping is used for a
co-routed bidirectional LSP the far-end LER could notify that there
was a misconnectivity.</t>
<t>In <xref target="Y.1731"></xref> this functionality is defined as
part of the CC-V function as a flag in the PDU.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Extend BFD (which is recommended to be used for proactive CC-V)
to transmit the signal of Remote Defect Indication without
disrupting the CC-V functionality. Such an extension could be
similar to that suggested by the ITU recommendation.</t>
</section>
</section>
<section title="Client Failure Indication">
<t>Client Failure Indication (CFI) function is used to propagate an
indication of a failure to the far-end sink when alarm suppression in
the client layer is not supported.</t>
<section title="Existing tools">
<t>There is a possibility of using the BFD over VCCV mechanism for
"Fault detection and AC/PW Fault status signaling". However, there
is a need to differentiate between faults on the AC and the PW. In
the PWE3 WG there are some proposals regarding how to transmit the
CFI over an ACH.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Use PWE3 tool to propagate Client Fail Indication via an ACH.</t>
</section>
</section>
<section title="Packet Loss Measurement">
<t>Packet Loss Measurement is a function that is used to verify the
quality of the service. This function indicates the ratio of packets
that are not delivered out of all packets that are transmitted by the
path source.</t>
<t>There are two possible ways of determining this measurement –
<list style="symbols">
<t>Using OAM packets, it is possible to compute the statistics
based on a series of OAM packets. This, however, has the
disadvantage of being artificial, and may not be representative
since part of the packet loss may be dependent upon packet
sizes.</t>
<t>Sending delimiting messages for the start and end of a
measurement period during which the source and sink of the path
count the packets transmitted and received. After the end
delimiter, the ratio would be calculated by the path OAM
entity.</t>
</list></t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF to support this
function. <xref target="Y.1731"></xref> describes a function that is
based on sending the CCM packets [used for CC-V support (see sec
3.1)] for proactive support and specialized loss-measurement packets
for on-demand measurement. These packets include information (in the
additional TLV fields) of packet counters that are maintained by
each of the end-points of a path. These counters maintain a count of
packets transmitted by the ingress end-point and the count of
packets received from the far-end of the path by the egress
end-point.</t>
</section>
<section title="Recommendations and Guidelines">
<t>One possibility is to define a mechanism to support Packet Loss
Measurement, based on the delimiting messages. This would include a
way for delimiting the periods for monitoring the packet
transmissions to measure the loss ratios, and computation of the
ratio between received and transmitted packets.</t>
<t>A second possibility would be to define a functionality based on
the description of the loss-measurement function defined in <xref
target="Y.1731"></xref> that is dependent on the counters
maintained, by the MPLS LSR (as described in <xref
target="RFC3813"></xref>, of received and transmitted octets. Define
a new PDU for the message that utilizes G-ACH. This option appears
more suitable for performance monitoring statistics, which in
transport applications are based on the continuous monitoring of the
traffic interested (100 ms gating).</t>
</section>
</section>
<section title="Packet Delay Measurement">
<t>Packet Delay Measurement is a function that is used to measure
one-way or two-way delay of a packet transmission between a pair of
the end-points of a path (PW, LSP, or Section). Where:</t>
<t><list style="symbols">
<t>One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of that packet by the destination
node.</t>
<t>Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.</t>
</list></t>
<t>Similarly to the packet loss measurement this could be performed in
one of two ways –</t>
<t><list style="symbols">
<t>Using OAM packets – checking delay (either one-way or
two-way) in transmission of OAM packets. May not fully reflect
delay of larger packets, however, gives feedback on general
service level.</t>
<t>Using delimited periods of transmission – may be too
intrusive on the client traffic.</t>
</list></t>
<section title="Existing tools">
<t>There is no mechanism defined in the IETF toolset that fulfills
all of the MPLS-TP OAM requirements.</t>
<t><xref target="Y.1731"></xref> describes a function in which
specific OAM packets are sent with a transmission time-stamp from
one end of the managed path to the other end (these are transparent
to the intermediate nodes). The delay measurement is supported for
both one-way and two-way measurement of the delay. It should be
noted that the functionality on the one-way delay measurement is
dependent upon a certain degree of synchronization between the time
clocks of the two-ends of the transport path.</t>
</section>
<section title="Recommendations and Guidelines">
<t>Define a mechanism that would support Packe Delay Measurement,
based on the procedures defined in <xref target="Y.1731"></xref>.
The mechanism should be based on measurement of the delay in
transmission and reception of OAM packets, transmitted in-band with
normal traffic. Define an appropriate PDU that would utilize the
G-ACH.</t>
</section>
</section>
</section>
<section title="Recommendations">
<t>As indicated above, LSP-Ping could easily be extended to support some
of the functionality between the path end-points and between an
end-point of a path and an intermediate point. BFD could also be
extended to support some of the functions between the end-points of a
path. Some of the OAM functions defined in <xref target="Y.1731" />
(especially for performance monitoring) could also be adapted.</t>
<t>The guidelines that are used in this document are as follows:</t>
<list style="symbols">
<t>Re-use/extend existing IETF protocols wherever applicable.</t>
<t>Define new message format for each of the rest of the OAM
functions, which are aligned with the ACH and ACH-TLV definitions, and
includes only relevant information.</t>
<t>Adapt Y.1731 functionality where applicable (mainly for performance
monitoring).</t>
</list>
<t>The recommendations on the MPLS-TP OAM tools are as follows:</t>
<t>
<list style="symbols">
<t>Define a maintenance entity that could be applied both to LSPs
and PWs that would support management of a sub-path. This entity
should allow for transmission of traffic by means of label stacking
and proper TTL setting.</t>
<t>Extend the control and the management planes to support the
configuration of the OAM maintenance entities and the set of
functions to be supported by these entities.</t>
<t>Define a mechanism that would allow the unique addressing of the
elements that need to be monitored, e.g., the connections,
end-points, and intermediate points of a path. This mechanism needs
to be flexible enough to support different addressing schemes, e.g.
IP addresses, NSAP, connection names. As pointed out above, LSP Ping
uses the full FEC identifier for the LSP - this could easily be
applied to Section OAM since this would be considered as a stacked
LSP.</t>
<t>The appropriate assignment of network-wide unique identifiers for
transport paths, needed to support connectivity verification, should
be considered.</t>
<t>Extend existing MPLS tools to disengage from IP forwarding
mechanisms.</t>
<t>Extend BFD to support the proactive CC-V functionalities. The
extensions should address the gaps described above.</t>
<t>Extend LSP Ping to support the on-demand Connectivity
Verification functionality. The extensions should address the gaps
described above.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support
the Alarm Reporting functionality for data-plane implementations.
Describe how Alarm Reporting can be supported by a control-plane and
by a management-plane.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support
the Lock Reporting functionality. Use the same procedures as for
Alarm Reporting.</t>
<t>Extend BFD to support the Remote Defect Indication (RDI)
functionality. The extensions should address the gaps described
above.</t>
<t>Extend LSP-Ping to support the Route tracing functionality. The
extensions should address the gaps described above.</t>
<t>Extend LSP-Ping to support the Lock Instruct functionality
between end-points of a path. The extensions should address the gaps
described above.</t>
<t>Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH.
There are already some proposals in the PWE3 WG.</t>
<t>Define a new PDU which will be transmitted over G-ACH to support
the Packet Loss Measurement functionality. Base the functionality on
the procedures defined in Y.1731.</t>
<t>Define a new PDU which be transmitted over G-ACH to support the
Packet Delay Measurement functionality. Base the functionality on
the procedures defined in Y.1731. For one-way delay measurement
define mechanisms to ensure a certain degree of synchronization
between the time clocks of the two-ends of the transport path.</t>
<t>Define a new PDU which be transmitted over G-ACH to support the
Diagnostic functionality.</t>
<t>The tools may have the capability to authenticate the messages.
The information may be carried in a G-ACH TLV.</t>
</list>
</t>
</section>
<section title="MPLS-TP OAM Documents Organization">
<t>The following paragraphs list the set of documents necessary to cover
the OAM functionalities analyzed above. This compilation of documents is
one of the outcomes of the MEAD team discussions that took place during
IETF75 in Stockholm.</t>
<t>It should be noted that the various document titles listed here may
not reflect the draft titles that will be chosen at the time that the
drafts are written, but they serve just as a topic pointer from the
current analysis.</t>
<section title="Document 1: "Encapsulation of BFD and LspPing in ACH"">
<t>The scope of the document is to define the usage of LSP Ping and
BFD in both IP and IP-less environments. As described in the following
paragraphs, BFD and Lsp Ping need to be extended in order to be
compliant with <xref target="MPLS-TP OAM Reqs" />. However, this
document should be focused on the existing Lsp Ping and BFD, without
necessarily referring to their extended versions.</t>
<t>The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be
considered as the starting point for this definition.</t>
<t>In particular, the following sections will be taken into account
for the scope:</t>
<list style="symbols">
<t>nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping
extensions") for addressing the "Lsp Ping encapsulation in ACH"</t>
<t>nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD
over MPLS-TP LSPs") for addressing the "BFD encapsulation in
ACH"</t>
</list>
</section>
<section title="Document 2: "Extended BFD"">
<t>The scope of the document is to define the BFD extension and
behavior to meet the requirements for MPLS-TP proactive Continuity
Check and Connectivity Verification functionality and the RDI
functionality as defined in <xref target="MPLS-TP OAM Reqs" />.</t>
<t>The document will likely take the name
"draft-asm-mpls-tp-bfd-cc-cv-00" and will be formed by the merging of
the following two drafts:</t>
<list style="symbols">
<t>draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd</t>
<t>draft-boutros-mpls-tp-cc-cv-01.txt</t>
</list>
</section>
<section title="Document 3: "Extended LSP Ping"">
<t>The scope of the document is to define:</t>
<list style="symbols">
<t>A place holder for On Demand Connectivity Verification if LSP
Ping needs to be enhanced over and above the encapsulations changes
(defined in Document 1 "Encapsulation of BFD and LSP Ping in
ACH").</t>
<t>Usage of LSP Ping with MIPs and MEPs, which is partially covered
in nitinb-mpls-tp-lsp-ping-bfd-procedures.</t>
<t>Route Trace. This topic has already been partially covered in
"draft-boutros-mpls-tp-path-trace-00" and
"nitinb-mpls-tp-lsp-ping-bfd-procedures", which will be considered
as starting point for the Route Trace functionality included in
Document 3. The Route Trace section should also cover these
aspects:</t>
<list style="symbols">
<t>LSP Ping Loose ends. This section will describe what to do when
receiving an LSP Ping with MIP and MEP ids.</t>
<t>In an IP-Less environment Route Trace works only in co-routed
bidirectional LSP.</t>
<t>In Y.1731 the CV function is separate from the Route Trace
function, it should be captured how LSP Ping works for Route Trace
using TTL.</t>
</list>
</list>
</section>
<section title="Document 4: "Extensions for Lock Instruct"">
<t>A new document describing the LSP Ping extensions to accomplish the
Lock Instruct desired behavior is needed. Some material useful for
this scope can be found in "draft-boutros-mpls-tp-loopback-02".</t>
</section>
<section title="Document 5: "AIS and Lock Reporting"">
<t>A new document is need for the definition of the AIS and Lock
Reporting, however the document definition has been temporarily
deferred by the MEAD team. Therefore this paragraph will be updated in
future versions.</t>
</section>
<section title="Document 6: "Client Fault Indication"">
<t>A new document describing Client Fault Indication procedure needs
to be defined.</t>
<t>The following two drafts indicating a client fault indication
transported across MPLS-TP network will be compared and merged in the
new document:</t>
<list style="symbols">
<t>"draft-he-mpls-tp-csf", which describes a tool to propagate a
client failure indication across an MPLS-TP network in case the
propagation of failure status in the client layer is not
supported.</t>
<t>"draft-martini-pwe3-static-pw-status", which describes the usage
of PW associated channel to signal PW status messages in case a
static PW is used without a control plane</t>
</list>
<t>It is worth noting that a Client Failure Indication is used if the
client does not support its own OAM (IP and MPLS as clients use their
own). It has been also agreed that CFI is used on PW and not on client
directly mapped on LSP MPLS-TP.</t>
</section>
<section title="Document 7: "Packet Loss"">
<t>A new document needs to be defined in order to describe a stand
alone tool for Packet Loss measurements that can work both proactively
and on demand. The tool will be functionally based on Y.1731.</t>
</section>
<section title="Document 8: "Packet Delay"">
<t>A new document needs to be defined about the Packet Delay
measurement which will be based on Y.1731 from the functionality point
of view. Moreover, <xref target="MPLS-TP OAM Frwk"></xref> needs to be
updated in order to clarify the functionality behavior expected from
this tool.</t>
</section>
<section title="Document 9: "Diagnostic Tests"">
<t>One or more new documents are needed for the tools definition for
Diagnostic Tests. However, the documents definition has been
temporarily deferred by the MEAD team until a clearer definition of
"diagnostic test" in <xref target="MPLS-TP OAM Reqs"></xref>.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to thank the MEAD team for their review and proposed
enhancements to the text.</t>
</section>
<appendix title="Proactive CC and CV BFD tool analysis">
<t>This appendix is focused on analyzing possible solutions and evaluating
their pros&cons for defining an MPLS-TP OAM mechanism BFD based,to meet
the requirements for proactive Continuity Check and Connectivity Verification
functionality as required in <xref target="MPLS-TP OAM Reqs" />. </t>
<t>The BFD tool needs to be extended for the CV functionality by the addition
of a unique identifier in order to meet the requirements. Proactive Continuity
Check (CC) and Continuity Verification (CV) function are used together to detect
loss of continuity (LOC), unintended connectivity between two MEs (e.g.
mismerging or misconnection) as well as unintended connectivity within the ME
with an unexpected MEP. It MUST operate both in bidirectional p2p and in
unidirectional p2mp connection.</t>
<t>The mechanism MUST foresee the configuration of the transmit frequency.</t>
<t>The mechanism is RECOMMENDED be the same for LSP, (MS-)PW and Section (See
<xref target="MPLS-TP OAM Reqs" />)</t>
<appendix title="Possible Solution">
<t>Several solutions have been analyzed:</t>
<list style="numbers">
<t>Define a new BFD version (BFDv2) that extends the current BFD (BFDv1)
to support also CV functionality. The new BFD version can be obtained by:</t>
<list style="symbols">
<t>changing the semantic of MY discriminator and Your discriminator
fields <xref target="BASE BFD" />,</t>
<t>adding a new globally unique source MEP ID field in the BFD packet
for the CV functionality to the existing session identifier.</t>
</list>
<t>Define two separate tools, running with two different ACH encapsulations
(i.e. two different ACH channel types):</t>
<list style="symbols">
<t>the current BFD with only CC functionality however profiled in behavior
to meet the CC MPLS-TP requirement;</t>
<t>a new tool that meet all the MPLS-TP OAM proactive CV requirement.</t>
</list>
</list>
<t>The new tool can be:</t>
<list style="numbers">
<t>based on current BFD;</t>
<t>an extension of the ACH encapsulation for the current BFD;</t>
<t>a new tool like Y.1731 CCM;</t>
</list>
<t>All analyzed solutions imply extension of CV types, foreseen by
<xref target="PW VCCV" /> yet extended by <xref target="VCCV BFD" />, in order
to include the MPLS-TP OAM mechanism too. This is due to the fact that VCCV also
includes mechanisms for negotiating the control channel and connectivity
verification (i.e. OAM functions) between PEs.</t>
</appendix>
<appendix title="Backward compatibility">
<t>For backward compatibility, it is possible to run the current BFD that supports
only CC functionality on some transport paths and the new tool that supports CC
and proactive CV functionality on other transport paths. In any case only one tool
for OAM instance at time, configurable by operator, can run.</t>
<t>A MEP that is configured to support proactive CV functionality MUST be capable
to receive existing BFD packets (encapsulated with GAL/G-ACH or PW-ACH) that
supports only CC functionality and MUST consider them as an unexpected packet,
i.e. detect a misconnection defect and vice versa.</t>
<t>The context of MPLS-TP OAM packets is based on MPLS label and G-ACH,
eliminating in the BFD the need to exchange Discriminator values. An MPLS-TP node
that desires to interoperate with a current BFD can apply the same discriminator
field semantic as described in <xref target="BASE BFD" /> or:</t>
<list style="symbols">
<t>It MUST set the My discriminator field to a nonzero value (it can be a
fixed value);</t>
<t>It MUST reflect back the received value of My discriminator field into the
transmitted Your discriminator field, or set it to zero if that value is
unknown.</t>
</list>
</appendix>
<appendix title="Definition of BFDv2">
<t>Common to both solutions detailed in this section are the following
considerations:</t>
<list style="symbols">
<t>The Channel Type field of the G-ACH is the one proposed by <xref
target="VCCV BFD" />, i.e. 0x0007, indicating the raw BFD control packet;</t>
<t>The version number of the protocol needs to be updated to protocol version 2
respect to protocol version 1 defined in <xref target="BASE BFD" />.</t>
</list>
<appendix title="New semantic for Discriminator fields">
<t>A possible BFD extension can be obtained changing the semantic of the two
32 bit fields, My Discriminator and Your Discriminator, to form a one 64 bit
field carrying the globally unique MEP Identifier.</t>
<t>One of the disadvantages of this solution is on the too limited number of
octets available for the globally unique MEP ID field: that doesn't allow the
possibility to have different format of ME identifier.</t>
</appendix>
<appendix anchor="A3s2" title="New MEP ID field">
<t>This solution adds the new field required for the CV functionality, i.e. a
globally unique MEP Identifier section, after the mandatory section of a BFD
control packet and before the optional Authentication section.</t>
<t>The advantages of this solution are that the discriminator behavior of the
current BFD protocol as defined in <xref target="BASE BFD" /> is unchanged
and on the variable length of the MEP ID Section.</t>
</appendix>
</appendix>
<appendix title="Two different ACH encapsulation of OAM tool">
<t>The current BFD, with only CC functionality, is encapsulated in the G-ACh
using as Channel type code point the 0x0007 value as described in <xref
target="VCCV BFD" />. This mechanism can be also extended to Section OAM and
LSP OAM.</t>
<t>In order to meet the MPLS-TP OAM proactive CV requirement, a new tool has to
be introduced, encapsulated into the G-ACh with a new channel type code point.
Common to all solutions detailed below are the following G-ACh format:</t>
<figure anchor="figure A-1" title="ACH Encapsulation">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>– first nibble: set to 0001b to indicate a channel associated with a
PW, a LSP or a Section;</t>
<t>– Version and Reserved fields are set to 0;</t>
<t>– G-ACH Channel Type field with a new TBD code point meaning "MPLS-TP
CC-CV proactive" indicating that the message is an MPLS-TP OAM CC-CV proactive
message. The value MUST be assigned</t>
<t>The sections below describe the format of the different possible new tool.</t>
<appendix anchor="A4s1" title="New tool based on current BFD">
<t>A new tool can be obtained introducing a globally unique MEP Identifier
TLV between the ACH and the current BFD (defined in <xref target="BASE BFD" />)
Control packet.</t>
<t>The benefit of this solution is to maintain the basic state machine and
protocol version of BFD as defined in <xref target="BASE BFD" /> and
<xref target="bfdMultipoint" />; considerations on the optional Authentication
Section is described in section <xref target="A7" />.</t>
</appendix>
<appendix title="New tool based on the extended BFD">
<t>The solutions and considerations are the same of what described in section
<xref target="A3s2" /> except the ACH Channel type code, rather than the
Version field, distinguishes between existing BFD (supporting CC) and the new
tools (supporting both CC&CV).</t>
<t>The Version field in this case is set to 0 (this is the first version for
this tool).</t>
</appendix>
<appendix anchor="A4s3" title="New tool like Y.1731 CCM">
<t>To be inserted</t>
</appendix>
</appendix>
<appendix title="Remote Defect Indication">
<t>Remote Defect Indication (RDI) is used by a MEP to notify its peer MEP that
a defect is detected on a bi-directional connection between them). RDI is only
used for bidirectional connections and is associated with proactive CC &
CV packet generation.<xref target="MPLS-TP OAM Frwk" /> The Diagnostic (Diag)
field of the Current BFD can be used for this functionality. However, there
isn't a total correspondence among the values foreseen by <xref
target="BASE BFD" /> and the defect conditions detected by the proactive CC-CV
tool that require the RDI function.</t>
<t>A solution could be that any defect that requires the RDI information being
sent to the peer MEP is encoded in the Diagnostic (Diag) field with the value 1
(corresponding to the "Control Detection Time Expired" in
<xref target="BASE BFD" />. The value 0 indicates RDI condition has been
cleared.</t>
<t>For the solution in section <xref target="A4s3" /> , RDI is foreseen in
the packet format with a single bit.</t>
</appendix>
<appendix title="Point to Multipoint transport paths">
<t>Solution described in section <xref target="A4s3" /> is valid for both
bidirectional and unidirectional connection: in unidirectional connection only
source MEP is enabled only to generate CC/CV OAM packets and sink MEP is
enabled only to receive CC/CV OAM packets.</t>
<t>The BFD tool has a straightforward state machine for bidirectional path.
Anyway the behavior and state machine need to be modified for the unidirectional
connection; this is described in <xref target="bfdMultipoint" />.</t>
</appendix>
<appendix anchor="A7" title="Security Considerations">
<t>Base BFD <xref target="BASE BFD" /> foresees an optional authentication
section; that can be extended even to the tool proposed in this document.</t>
<t>Authentication methods that require checksum calculation on the outgoing
packet must extend the checksum even on the ME Identifier Section. This is
possible but seems uncorrelated with the solution proposed in section
<xref target="A4s1" /> in this case it could be better to use the simple
password authentication method.</t>
<t>It is also worth noticing that the interactions between authentication
and connectivity verification need further analysis.</t>
</appendix>
</appendix>
</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-22 23:53:11 |