Network Working Group N. Sprecher, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Informational T. Nadeau, Ed.
Expires: October 25, 2009 BT
H. van Helvoort, Ed.
Huawei
Y. Weingarten
Nokia Siemens Networks
April 23, 2009
MPLS-TP OAM Analysis
draft-sprecher-mpls-tp-oam-analysis-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 25, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Sprecher, et al. Expires October 25, 2009 [Page 1]
Internet-Draft MPLS-TP OAM Analysis April 2009
Abstract
The intention of this document is to analyze the set of requirements
for Operations, Administration, and Maintenance (OAM) for the
Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM
Requirements], to evaluate whether existing MPLS OAM tools 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.
Sprecher, et al. Expires October 25, 2009 [Page 2]
Internet-Draft MPLS-TP OAM Analysis April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Organization of the document . . . . . . . . . . . . . . . 7
2. Architectural requirements and general principles of
operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Architectural and Principles of Operation -
Recommendations and Guidelines . . . . . . . . . . . . . . 9
3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 10
3.1. Continuity and Connectivity Verification . . . . . . . . . 11
3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Gap analysis . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 12
3.2. Alarm Suppression . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Recommendations and Guidelines . . . . . . . . . . . . 12
3.3. Packet Loss Measurement . . . . . . . . . . . . . . . . . 12
3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 13
3.4. Diagnostic Test . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 13
3.5. Route Determination . . . . . . . . . . . . . . . . . . . 13
3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 14
3.6. Delay Measurement . . . . . . . . . . . . . . . . . . . . 14
3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 14
3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 14
3.7. Remote Defect Indication . . . . . . . . . . . . . . . . . 14
3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 15
3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 15
3.8. Client Fail Indication . . . . . . . . . . . . . . . . . . 15
3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 15
3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 15
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Sprecher, et al. Expires October 25, 2009 [Page 3]
Internet-Draft MPLS-TP OAM Analysis April 2009
1. Introduction
OAM (Operations, Administration, and Maintenance) plays a significant
and fundamental 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.
[MPLS-TP Requirements] in general, and [MPLS-TP OAM Requirements] 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.
The existing tools that are evaluated include LSP Ping (defined in
[LSP Ping]), MPLS Bi-directional Forwarding Detection (BFD) (defined
in [MPLS BFD]) and Virtual Circuit Connectivity Verification (VCCV)
(defined in [PW VCCV] and [VCCV BFD]).
1.1. LSP Ping
LSP Ping is a variation of ICMP Ping and traceroute [ICMP] adapted to
the different 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.
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 succesfully traversed before
the faulty link or node. 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).
Sprecher, et al. Expires October 25, 2009 [Page 4]
Internet-Draft MPLS-TP OAM Analysis April 2009
LSP Ping can be activated both in on-demand and pro-active
(asynchronous) modes, as defined in [MPLS-TP OAM Requirements].
[P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP
LSPs, and extends the techniques and mechanisms of LSP Ping to the
MPLS P2MP environment.
[LSP Ping over MPLS Tunnels] 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, usually 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 [MPLS
BFD]. When LSP bundling is employed in the network, there is no
guarantee that the LSP Ping packets will follow the same physical
path used by the data traffic.
1.2. MPLS BFD
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. In addition to the control packets that BFD defines, 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 [MPLS-TP OAM Requirements], of operation.
[MPLS BFD] 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
Sprecher, et al. Expires October 25, 2009 [Page 5]
Internet-Draft MPLS-TP OAM Analysis April 2009
to bootstrap and bind the session to a particular LSP or FEC. LSP
Ping is designated by [MPLS BFD] 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 use the same
discriminators at their end-points.
1.3. PW VCCV
PW VCCV 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
[PW-ACH]), and allows sending OAM packets in-band with PW data (using
CC Type 1: In-band VCCV)
VCCV 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.
Sprecher, et al. Expires October 25, 2009 [Page 6]
Internet-Draft MPLS-TP OAM Analysis April 2009
1.4. Acronyms
This draft uses the following acronyms:
+---------+---------------------------------------------+
| AC | Attachment Circuit |
| ACH | Associated Channel Header |
| BFD | Bidirectional Forwarding Detection |
| FEC | Forwarding Equivalence Class |
| LDP | Label Distribution Protocol |
| LSP | Label Switched Path |
| ME | Maintenance Entitity |
| MEP | Maintenance End Point |
| MIP | Maintenance Intermediate Point |
| MPLS-TP | Transport Profile for MPLS |
| OAM | Operations, Administration, and Maintenance |
| PW | Pseudowire |
| RDI | Remote Defect Indication |
| SLA | Service Level Agreement |
| TC | Tandem Connection |
| TCME | Tandem Connection Maintenance Entity |
| TTL | Time-to-live |
| VCCV | Virtual Circuit Connectivity Verification |
| VPCV | Virtual Path Connectivity Verification |
+---------+---------------------------------------------+
1.5. Organization of the document
Section 2 of the document analyzes the requirements that are
documented in [MPLS-TP OAM Requirements] 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.
Section 4 provides recommendations on what 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.
2. Architectural requirements and general principles of operation
[MPLS-TP OAM Requirements] defines a set of requirements on OAM
architecture and general principles of operations which are evaluated
below:
Sprecher, et al. Expires October 25, 2009 [Page 7]
Internet-Draft MPLS-TP OAM Analysis April 2009
o [MPLS-TP OAM Requirements] 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.
o [MPLS-TP OAM Requirements] 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.
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 comply with the requirement. In the on-
demand mode, LSP Ping also uses 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.
* VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
for PWs and can comply with the requirement.
o [MPLS-TP OAM Requirements] requires that OAM tools for fault
management do not rely on user traffic, and the existing MPLS OAM
tools already comply with this requirement.
o 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.
o [MPLS-TP OAM Requirements] requires that the MPLS-TP OAM mechanism
allows the propagation of AC (Attachment Circuit) failures and
their clearance across a MPLS-TP domain
Sprecher, et al. Expires October 25, 2009 [Page 8]
Internet-Draft MPLS-TP OAM Analysis April 2009
* 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.
o [MPLS-TP OAM Requirements] defines Maintenance Domain, Maintenance
End Points (MEPs) and Maintenance Intermediate Points (MIPs).
Means should be defined to provision these entities, both by
static configuration (as it is required to operate OAM in the
absence of any control plane or dynamic protocols) and by a
control plane.
o [MPLS-TP OAM Requirements] requires a single OAM technology and
consistent OAM capabilities for LSPs, PWs, MPLS-TP Links, and
Tandem Connections. There is currently no mechanism in the IETF
to support OAM for Tandem Connections. Also, the existing set of
tools defines a different way of operating the OAM functions (e.g.
LSP Ping to bootstrap MPLS BFD vs. VCCV).
o [MPLS-TP OAM Requirements] requires allowing OAM packets to be
directed to an intermediate node (MIP) of a LSP/PW. Technically,
this could be supported by the proper setting of the TTL value.
However, the applicability of such a solution needs to be examined
per OAM function. For details, see below.
o [MPLS-TP OAM Requirements] suggests that OAM messages MAY be
authenticated. BFD has a support for authentication. Other tools
should support this capability as well.
2.1. Architectural and Principles of Operation - Recommendations and
Guidelines
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:
o Extend the PW Associate Channel Header (ACH) to provide a control
channel at the path and section levels. This could then be
associated with a MPLS-TP Link, LSP, or a Tandem Connection (TC).
The ACH should then become a common mechanism for PW, LSP, MPLS-TP
Link, and Tandem Connection.
o Create a VPCV (Virtual Path Connectivity Verification) definition
that would apply the definitions and functionality of VCCV to the
MPLS-TP environment for LSP or Tandem Connection. Need a
generalized addressing scheme that can also support unique
identification of the monitored paths (or connections).
Sprecher, et al. Expires October 25, 2009 [Page 9]
Internet-Draft MPLS-TP OAM Analysis April 2009
o Create or extend the VCCV definition to define a mechanism that
would apply the definitions and functionality of VCCV to PW Tandem
Connections
o 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.
o Define a mechanism to create TCME and allow transmission of the
traffic via the Tandem Connection using label stacking.
o Define a mechanism that could be used to address a MIP 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 addressing of
intermediate points.
Creating these extensions/mechanisms would fulfill the following
architectural requirements, mentioned above:
o Independence of IP forwarding and routing.
o OAM packets should be transmitted in-band.
o Support a single OAM technology for LSP, PW, MPLS-TP Link, and TC.
In addition, the following additional requirements can be satisfied:
o Provide the ability to carry other types of communications (e.g.,
APS, Management Control Channel (MCC), Signalling Control Channel
(SCC)), by defining new types of communication channels for PWs,
MPLS-TP Links, and LSPs.
o The design of the OAM mechanisms for MPLS-TP MUST allow the
ability to support vendor specific and experimental OAM functions.
3. MPLS-TP OAM Functions
The following sections discuss the required OAM functions that were
identified in [MPLS-TP OAM Requirements].
LSP Ping is not considered a candidate to fulfill the required
functionality, due its failure to comply with the basic architectural
requirement for independence from IP routing and forwarding, as
documented in Section 2 of this document. However, usage of LSP
Ping, in addition to the MPLS-TP OAM tools, or in MPLS-TP deployments
with IP functionality is not precluded.
Sprecher, et al. Expires October 25, 2009 [Page 10]
Internet-Draft MPLS-TP OAM Analysis April 2009
3.1. Continuity and Connectivity Verification
Continuity and Connectivity Verification (CC-V) are OAM operations
generally used in tandem, and compliment each other. Together they
are used to detect loss of traffic continuity and misconnections
between MEPs 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.
3.1.1. Existing tools
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
session identifiers.
VCCV can be used to carry BFD packets that are not IP/UDP
encapsulated for CC-V on a PW and use the PW label to identify the
path.
3.1.2. Gap analysis
There is currently no tool that gives coverage for both aspects of
CC-V functionality.
One possible option, is to extend BFD to fill the gaps indicated
above. The extension would include:
o A mechanism should be defined to carry BFD packets over LSP
without reliance on IP functionality.
o A mechanism should be defined to bootstrap BFD sessions for MPLS
that is not dependent on UDP.
o 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.
Sprecher, et al. Expires October 25, 2009 [Page 11]
Internet-Draft MPLS-TP OAM Analysis April 2009
* 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.
o Extensions to BFD would be needed to cover P2MP connections.
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.
3.1.3. Recommendations and Guidelines
Extend BFD to resolve the gaps, using a new optional field for the
unique path identifier.
Note that [MP BFD] defines a method for using BFD to provide
verification of multipoint or multicast connectivity.
3.2. Alarm Suppression
Alarm Suppression is a function that is used by a server layer MEP to
notify a failure condition to its client layer MEP(s) in order to
suppress alarms that may be generated by maintenance domains of the
client layer as a result of the failure condition in the server
layer. This function should also have the capability to
differentiate an administrative lock from a failure condition at a
different execution level.
3.2.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.2.2. Recommendations and Guidelines
Define a tool to support Alarm Suppression.
3.3. Packet Loss Measurement
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 -
o Using OAM packets, it is possible to compute the statistics based
on a series of OAM packets. This, however, has the disadvantage
Sprecher, et al. Expires October 25, 2009 [Page 12]
Internet-Draft MPLS-TP OAM Analysis April 2009
of being artificial, and may not be representative since part of
the packet loss may be dependent upon packet sizes.
o 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.
3.3.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.3.2. Recommendations and Guidelines
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.
3.4. Diagnostic Test
A diagnostic test is a function that is used between MEPs to verify
bandwidth throughput, packet loss, bit errors, etc.
3.4.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.4.2. Recommendations and Guidelines
Define a tool to support Diagnostic Test.
3.5. Route Determination
Route Determination is used to determine the route of a connection
across the MPLS transport network.
3.5.1. Existing tools
LSP Ping supports a trace route function that could be used but as it
does not comply with the requirement for OAM functions to be
independent of IP routing and forwarding capabilities. Therefore, it
can not be utilized for MPLS-TP
Sprecher, et al. Expires October 25, 2009 [Page 13]
Internet-Draft MPLS-TP OAM Analysis April 2009
3.5.2. Recommendations and Guidelines
Define a new tool to support Route Determination.
3.6. Delay Measurement
Delay Measurement is a function that is used to measure one-way or
two-way delay of a packet transmission between a pair of MEPs.
Where:
o 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 first bit of that packet by the destination
node.
o 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 -
o 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.
o Using delimited periods of transmission - may be too intrusive on
the client traffic.
3.6.1. Existing tools
There is no mechanism defined in the IETF that fulfills all of the
MPLS-TP OAM requirements.
3.6.2. Recommendations and Guidelines
Define a mechanism that would allow to support Delay Measurement.
The mechanism should be based on measurement of the delay in
transmission and reception of OAM packets, transmitted in-band with
normal traffic.
3.7. Remote Defect Indication
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.
Sprecher, et al. Expires October 25, 2009 [Page 14]
Internet-Draft MPLS-TP OAM Analysis April 2009
This function should be supported in pro-active mode.
3.7.1. Existing tools
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.
3.7.2. Recommendations and Guidelines
Either create a dedicated mechanism for this functionality or extend
the BFD session functionality to support the functionality without
disrupting the CC or CV functionality.
3.8. Client Fail Indication
Client Fail 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.
3.8.1. Existing tools
There is a possibility of using the BFD over VCCV mechanism for
"Fault detection and AC/PW Fault status signalling". However, there
is a need to differentiate between faults on the AC and the PW.
3.8.2. Recommendations and Guidelines
Either extend the BFD tool or define a tool to support Client Fail
Indication propagation.
4. Recommendations
o 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.
o 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.
o Extend the ACH to provide a control channel for MPLS-TP Links,
LSPs, and Tandem Connections.
Sprecher, et al. Expires October 25, 2009 [Page 15]
Internet-Draft MPLS-TP OAM Analysis April 2009
o Define a mechanism that would allow the unique addressing of the
elements that need to be monitored, e.g., the connections, MEPs,
and MIPs of a path. This mechanism needs to be flexible enough to
support different addressing schemes, e.g. IP addresses, NSAP,
connection names.
o Define a VPCV mechanism for LSP and Tandem Connection. This
mechanism should reuse, as much as possible, the same principles
of operation as VCCV. The ACH should be extended to support CV
types for each of the tools that are defined below, in a way that
is consistent for PW, LSP and Tandem Connection.
o The appropriate assignment of network-wide unique identifiers
needed to support connectivity verification should be considered.
o Tools should be defined to support the following functions:
* On-demand connectivity verification
* Alarm suppression
* Packet loss measurement
* Diagnostic test
* Route determination
* Delay measurement
* Remote defect indication
* Client fail indication
o The tools may have the capability to authenticate the messages.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document does not by itself raise any particular security
considerations.
Sprecher, et al. Expires October 25, 2009 [Page 16]
Internet-Draft MPLS-TP OAM Analysis April 2009
7. Acknowledgements
The authors wish to thank xxxxxxx for his review and proposed
enhancements to the text.
8. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LSP Ping]
Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[MP BFD] Katz, D. and D. Ward, "BFD for Multipoint Networks",
ID draft-katz-ward-bfd-multipoint-01.txt, December 2007.
[VCCV BFD]
Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)",
ID draft-ietf-pwe3-vccv-bfd-01.txt, February 2008.
[P2MP LSP Ping]
Nadeau, T. and A. Farrel, "Detecting Data Plane Failures
in Point-to-Multipoint Multiprotocol Label Switching
(MPLS) - Extensions to LSP Ping",
ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.
[MPLS LSP Ping]
Bahadur, N. and K. Kompella, "Mechanism for performing
LSP-Ping over MPLS tunnels",
ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008.
[MPLS-TP OAM Requirements]
Vigoureux, M., Betts, M., and D. Ward, "Requirements for
OAM in MPLS Transport Networks",
ID draft-vigoureux-mpls-tp-oam-requirements-00, July 2008.
Sprecher, et al. Expires October 25, 2009 [Page 17]
Internet-Draft MPLS-TP OAM Analysis April 2009
[MPLS-TP Requirments]
Nadeau, T. and C. Pignataro, "Requirements for the
Trasport Profile of MPLS",
ID draft-jenkins-mpls-mplstp-requirements-00, July 2008.
Authors' Addresses
Nurit Sprecher (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: nurit.sprecher@nsn.com
Tom Nadeau (editor)
BT
United States
Email: tom.nadeau@bt.com
Huub van Helvoort (editor)
Huawei
Kolkgriend 38, 1356 BC Almere
Netherlands
Phone: +31 36 5316076
Email: hhelvoort@huawei.com
Yaacov Weingarten
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972-9-775 1827
Email: yaacov.weingarten@nsn.com
Sprecher, et al. Expires October 25, 2009 [Page 18]