MPLS-TP OAM Analysis
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon
45241
Israel
nurit.sprecher@nsn.com
Huawei
Kolkgriend 38, 1356 BC Almere
Netherlands
hhelvoort@huawei.com
+31 36 5316076
Ericsson
6 Farogatan St
Stockholm
164 40
Sweden
elisa.bellagamba@ericsson.com
+46 761440785
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon
45241
Israel
yaacov.weingarten@nsn.com
+972-9-775 1827
This document analyzes the set of requirements for Operations, Administration,
and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in
, 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.
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.
in general, and
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).
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 , as a candidate to base
these new tools upon. The existing tools that are evaluated include LSP Ping
(defined in ), MPLS Bi-directional Forwarding Detection (BFD)
(defined in ) and Virtual Circuit Connectivity Verification
(VCCV) (defined in and ), and the
ITU-T OAM toolset defined in .
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.
Sections 1.3 – 1.6 provide an overview of the existing MPLS tools.
Section 2 of the document analyzes the requirements that are documented in
and provides basic principles of operation for the OAM
functionality that is required.
Section 3 evaluates which existing tools can provide coverage for the different
OAM functions that are required to support MPLS-TP.
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.
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.
LSP Ping is a variation of ICMP Ping and traceroute 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.
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.
As mentioned above, LSP Ping requires the presenece of the MPLS control plane when
verifying the consistency of the data-plane against the control-plane. However, LSP
Ping is not dependent on the MPLS control-plane for its operation, i.e. even though the
propagation of the LSP label may be performed over the control-plane via the Label
Distribution Protocol (LDP).
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.
LSP Ping can be activated both in on-demand and pro-active (asynchronous)
modes, as defined in .
clarifies the applicability of LSP Ping to MPLS P2MP
LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS
P2MP environment.
extends LSP Ping to operate over MPLS
tunnels or for a stitched LSP.
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.
Some of the drawbacks identified with LSP Ping include - LSP Ping is considered
to be computational intensive as pointed out in . 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.
BFD (Bidirectional Forwarding Detection) 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.
BFD can be used in pro-active (asynchronous) and on-demand modes, as defined
in , of operation.
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.
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 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.
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.
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 ), and allows
sending OAM packets in-band with PW data (using CC Type 1: In-band VCCV)
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.
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.
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.
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
.
The PDU and procedures defined in 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.
describes procedures to support the following OAM functions:
Connectivity and Continuity Monitoring – for pro-active mode
end-to-end checking
Loopback functionality – to verify connectivity to intermediate nodes in an
on-demand mode
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.
Alarm Indication Signaling – for alarm suppression in case of faults
that are detected at the server layer, activated pro-actively.
Remote Defect Indication – as part of the Connectivity and Continuity
Monitoring packets, performed pro-actively
Locked Signal – for alarm suppression in case of administrative locking
at the server layer. This function is performed pro-actively.
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.
The PDU defined in includes various information elements
(fields) including information on the MEG-Level, etc. Addressing of the PDU as
defined in 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
This draft uses the following acronyms:
ACAttachment Circuit
ACHAssociated Channel Header
BFDBidirectional Forwarding Detection
CC-VContinuity Check and Connectivity Verification
FECForwarding Equivalence Class
G-ACHGeneric Associated Channel Header
LDPLabel Distribution Protocol
LSPLabel Switched Path
MPLS-TPTransport Profile for MPLS
OAMOperations, Administration, and Maintenance
PDUPacket Data Unit
PWPseudowire
RDIRemote Defect Indication
SLAService Level Agreement
TLVType, Length, Value
TTLTime-to-live
VCCVVirtual Circuit Connectivity Verification
defines a set of requirements on OAM architecture
and general principles of operations which are evaluated below:
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.
requires that the MPLS-TP OAM MUST be able
to support both an IP based and non-IP based environment. If the network is IP
based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset
MUST be able to operate by relying on the IP routing and forwarding capabilities.
All of the existing MPLS tools (i.e. LSP Ping, VCCV Ping, MPLS BFD, and VCCV BFD)
can support this functionality. The Y.1731 toolset does not specifically support
this functionality, but rather relies on underlying technologies for forwarding
this could also be over IP, e.g. by using a VCCV extension. Note that some of
the MPLS-TP tools such as Alarm Report are very transport oriented and may not
support IP functionality.
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:
LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header (UDP/IP) and do not
completely comply with the requirement. In the on-demand mode, LSP Ping also
may use IP forwarding to reply back to the source router. This dependence on
IP, has further implications concerning the use of LSP Ping as the
bootstrap mechanism for BFD for MPLS. There are extensions to LSP-Ping that
are under discussion that allow LSP-Ping to restrict replies to the
backside of a bidirectional LSP.
VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
for PWs and can comply with the requirement.
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.
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.
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.
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).
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. 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.
requires that the MPLS-TP OAM mechanism
allows the propagation of AC (Attachment Circuit) failures and their
clearance across a MPLS-TP domain
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.
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.
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 .
The applicability of such a solution needs to be examined per OAM function. For details,
see below.
suggests that OAM messages MAY be
authenticated. BFD defines support for optional authentication fields using
different authentication methods as defined in .
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 when not available in
the OAM PDU.
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:
Define a generalized addressing scheme that can also support unique
identification of the monitored paths (or connections).
Use G-ACH for LSP and section levels.
Define architectural element that is based on LSP hierarchy to apply
the mechanisms to segments and concatenated segments.
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.
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.
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.
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.
Creating these extensions/mechanisms would fulfill the following architectural
requirements, mentioned above:
Independence of IP forwarding and routing, when needed.
OAM packets should be transmitted in-band.
Support a single OAM technology for LSP, PW, and Sections.
In addition, the following additional requirements can be satisfied:
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.
The design of the OAM mechanisms for MPLS-TP MUST allow the
ability to support vendor specific and experimental OAM functions.
The following sections discuss the required OAM functions that were
identified in .
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.
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.
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.
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.
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 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.
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
BFD could be extended to fill the gaps indicated above. The extension would include:
A mechanism should be defined to carry BFD packets over LSP without
reliance on IP functionality.
A mechanism should be defined to bootstrap BFD sessions for
MPLS that is not dependent on UDP.
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 –
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.
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.
Extensions to BFD would be needed to cover P2MP connections.
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.
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.
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.
Note that defines a method for using BFD to provide
verification of multipoint or multicast connectivity.
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.
There is no mechanism defined in the IETF to support this function.
Y.1731 does define a PDU and procedure for this functionality.
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.
Describe also how the Alarm Reporting functionality may be supported in the
control-plane and management-plane.
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.
There is no mechanism defined in the IETF to support this function.
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.
Define a new tool and PDU to support Diagnostic.
Functionality of route determination is used to determine the route of a connection
across the MPLS transport network. 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.
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.
Extend LSP Ping to support the Route Trace functionality and to address additional
options, i.e. PW and p2mp unidirectional LSP.
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.
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.
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.
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.
There is no mechanism defined in neither the IETF nor in Y.1731 to support
this function.
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.
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.
This function should be supported in pro-active mode.
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.
In this functionality is defined as part of the
CC-V function as a flag in the PDU.
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.
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.
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.
Use PWE3 tool to propagate Client Fail Indication via an ACH.
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.
There are two possible ways of determining this measurement –
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.
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.
There is no mechanism defined in the IETF to support this function.
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.
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.
A second possibility would be to define a functionality based on the description
of the loss-measurement function defined in that is dependent
on the counters maintained, by the MPLS LSR (as described in ,
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).
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:
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.
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.
Similarly to the packet loss measurement this could be performed in one of
two ways –
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.
Using delimited periods of transmission – may be too intrusive on the
client traffic.
There is no mechanism defined in the IETF toolset that fulfills all of the
MPLS-TP OAM requirements.
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.
Define a mechanism that would support Packe Delay Measurement, based on the
procedures defined in . 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.
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
(especially for performance monitoring) could also be adapted.
The guidelines that are used in this document are as follows:
Re-use/extend existing IETF protocols wherever applicable.
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.
Adapt Y.1731 functionality where applicable (mainly for performance monitoring).
The recommendations on the MPLS-TP OAM tools are as follows:
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.
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.
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.
The appropriate assignment of network-wide unique identifiers for transport
paths, needed to support connectivity verification, should be considered.
Extend existing MPLS tools to disengage from IP forwarding mechanisms.
Extend BFD to support the proactive CC-V functionalities. The extensions should
address the gaps described above.
Extend LSP Ping to support the on-demand Connectivity Verification functionality.
The extensions should address the gaps described above.
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.
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.
Extend BFD to support the Remote Defect Indication (RDI) functionality. The
extensions should address the gaps described above.
Extend LSP-Ping to support the Route tracing functionality. The extensions
should address the gaps described above.
Extend LSP-Ping to support the Lock Instruct functionality between end-points
of a path. The extensions should address the gaps described above.
Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH. There are
already some proposals in the PWE3 WG.
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.
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.
Define a new PDU which be transmitted over G-ACH to support the Diagnostic
functionality.
The tools may have the capability to authenticate the messages. The information
may be carried in a G-ACH TLV.
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.
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.
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 . However,
this document should be focused on the existing Lsp Ping and BFD, without necessarily
referring to their extended versions.
The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be considered as the
starting point for this definition.
In particular, the following sections will be taken into account for the scope:
nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping extensions")
for addressing the "Lsp Ping encapsulation in ACH"
nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD over MPLS-TP
LSPs") for addressing the "BFD encapsulation in ACH"
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 .
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:
draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd
draft-boutros-mpls-tp-cc-cv-01.txt
The scope of the document is to define:
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").
Usage of LSP Ping with MIPs and MEPs, which is partially covered in
nitinb-mpls-tp-lsp-ping-bfd-procedures.
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:
LSP Ping Loose ends. This section will describe what to do when receiving
an LSP Ping with MIP and MEP ids.
In an IP-Less environment Route Trace works only in co-routed bidirectional LSP.
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.
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".
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.
A new document describing Client Fault Indication procedure needs to be defined.
The following two drafts indicating a client fault indication transported across
MPLS-TP network will be compared and merged in the new document:
"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.
"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
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.
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.
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,
needs to be updated in order to clarify the
functionality behavior expected from this tool.
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 .
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
This document does not by itself raise any particular security
considerations.
The authors wish to thank the MEAD team for their review and proposed
enhancements to the text.
Internet Control Message Protocol
Key words for use in RFCs to Indicate Requirement Levels.
Internet Control Message Protocol
The Internet Control Message Protocol definition of the messages.
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
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.
Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
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.
Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
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.
Bidirectional Forwarding Detection
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.
BFD For MPLS LSPs
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.
Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping
Mechanism for performing LSP-Ping over MPLS tunnels
LSP Ping for MPLS tunnels.
Requirements for OAM in MPLS Transport Networks
Lists the requirements for the OAM functionality in support of MPLS-TP.
MPLS-TP OAM Framework and Overview
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.
Requirements for the Trasport Profile of MPLS
Lists the requirements for MPLS-TP with cross reference
MPLS Generic Associated Channel
Defines a Generic Associated Control Header for MPLS Transport Paths
Definition of ACH TLV Structure
Defines use of TLV fields for G-ACH
Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management
Information Base (MIB)
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).
OAM functions and mechanisms for Ethernet based networks
International Telecommunications Union - Standardization
This