Network Working Group N. Sprecher, Ed. Internet-Draft Nokia Siemens Networks Intended status: Informational T. Nadeau, Ed. Expires: March 7, 2009 BT H. van Helvoort, Ed. Huawei Y. Weingarten Nokia Siemens Networks September 3, 2008 MPLS-TP OAM Analysis draft-sprecher-mpls-tp-oam-analysis-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 March 7, 2009. Abstract The intention of this document is to analyze the set of requirements for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to verify whether the existing MPLS OAM tools can be applied to these requirements, identify which of the existing tools need to be extended, and which new tools should be defined. 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 Sprecher, et al. Expires March 7, 2009 [Page 1] Internet-Draft MPLS-TP OAM Analysis September 2008 the set of OAM requirements for MPLS-TP. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Sprecher, et al. Expires March 7, 2009 [Page 2] Internet-Draft MPLS-TP OAM Analysis September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Organization of the document . . . . . . . . . . . . . . . 6 2. Architectural requirements and general principles of operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Architectural and Principles of Operation - Recommendations and Guidelines . . . . . . . . . . . . . . 8 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 9 3.1. Continuity Check and Connectivity Verification . . . . . . 10 3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Gaps analysis . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 11 3.2. Alarm Suppression . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Recommendations and Guidelines . . . . . . . . . . . . 11 3.3. Lock Indication . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 12 3.4. Packet Loss Measurement . . . . . . . . . . . . . . . . . 12 3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 12 3.5. Diagnostic Test . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 12 3.6. Trace Route . . . . . . . . . . . . . . . . . . . . . . . 12 3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 12 3.7. Delay Measurement . . . . . . . . . . . . . . . . . . . . 13 3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13 3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 13 3.8. Remote Defect Indication . . . . . . . . . . . . . . . . . 13 3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13 3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 13 3.9. Client Signal Fail . . . . . . . . . . . . . . . . . . . . 14 3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 14 3.9.2. Recommendations and Guidelines . . . . . . . . . . . . 14 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Sprecher, et al. Expires March 7, 2009 [Page 3] Internet-Draft MPLS-TP OAM Analysis September 2008 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 on order to improve their ability to support services with guaranteed and strict SLAs while reducing their operational costs. [MPLS-TP Requirements] in general and [MPLS-TP OAM Requirements] in particular define a set of requirements on OAM functionality in MPLS-TP for MPLS-TP LSPs (network infrastructure) and PWs (services). The purpose of this document is to analyze the OAM requirements and verify whether the existing OAM tools defined for MPLS can be used to fulfill 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 BFD (defined in [ MPLS BFD ]) and Virtual Circuit Connectivity Verification (defined in [PW VCCV] and [VCCV BFD]). 1.1. LSP Ping LSP Ping is a variation of ICMP Ping and Traceroute [ICMP] that is adapted to MPLS LSP. Addressing is based upon the LSP Label and label stack in order to guarantee that the echo messages are switched in-band of the LSP. 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 not be transmitted outside 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 FEC and also MTU problems. The traceroute functionality is used to isolate and localize the MPLS faults, using the TTL to incrementally verify the path. While LSP Ping is dependent upon the label propogation that may be performed over the control-plane via LDP, there is no direct dependence of LSP Ping on the control-plane. LSP Ping can be activated both in on-demand and pro-active (asynchronous) modes. [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 Sprecher, et al. Expires March 7, 2009 [Page 4] Internet-Draft MPLS-TP OAM Analysis September 2008 tunnels or for a stitched LSP. TTL exhaust is the method for terminating flows at intermediate LSRs. LSP Ping is considered to be computational intensive. In cases of LSP bundling, 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. 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 a discovery mechanism nor support 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 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. There is a need for a mechanism to bootstrap a BFD session and bind the session to a particular LSP or FEC. LSP Ping is designated by [MPLS BFD] to bootstrap the BFD session in an MPLS environment. The session BFD messages for MPLS are transmitted using a IP/UDP encapsulation. The Discriminator values, as currently used, provide only a locally unique context, since they are defined by the end-points of the ME. This limitation of the uniqueness of the session discriminator limits the used of BFD for connectivity verification, since (in extreme cases) it may be possible for crossing paths to use identical discriminators at their end-points. . Sprecher, et al. Expires March 7, 2009 [Page 5] Internet-Draft MPLS-TP OAM Analysis September 2008 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 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. Note: There is a need to prevent confusion between the Connectivity Verification function defined in [MPLS-TP OAM Requirements], and the ACH's CV type defined in [PW VCCV], that identifies the protocol that is being used over the control channel. 1.4. Organization of the document The analysis of the architectural requirements and the general principles of operations are discussed first and then the requirements on the set of OAM functions. 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 in MPLS-TP. 2. Architectural requirements and general principles of operation [MPLS-TP OAM Requirements] defines a set of requirements on OAM Sprecher, et al. Expires March 7, 2009 [Page 6] Internet-Draft MPLS-TP OAM Analysis September 2008 architecture and general principles of operations which are evaluated below: 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. It is also required that OAM packets and the user traffic are congruent (i.e. OAM packets are transmitted in-band) ad there is a need to differentiate OAM packets from user-plane ones. * For PWs, VCCV provides a control channel 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/UD 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. Sprecher, et al. Expires March 7, 2009 [Page 7] Internet-Draft MPLS-TP OAM Analysis September 2008 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 * 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 comply with 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. Sprecher, et al. Expires March 7, 2009 [Page 8] Internet-Draft MPLS-TP OAM Analysis September 2008 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 to support distinct identifier or label for all types of paths. 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. Creating these extensions/mechanisms would fulfil 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 March 7, 2009 [Page 9] Internet-Draft MPLS-TP OAM Analysis September 2008 3.1. Continuity Check and Connectivity Verification Continuity Check (CC) and Connectivity Verification (CV) 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 CV can identify misconnections from cross- connections it is necessary that the CV tool use network-wide unique identifiers for the path checked in the session. 3.1.1. Existing tools BFD can be used to support the pro-active OAM CC 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 CV functional aspects, basic BFD has the 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 on a PW and use the PW label to identify the path. 3.1.2. Gaps analysis There is currently no tool that gives coverage for both CC and CV 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. * Create a new optional field in the BFD packet that would identify the path being checked, in addition to the existing Sprecher, et al. Expires March 7, 2009 [Page 10] Internet-Draft MPLS-TP OAM Analysis September 2008 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 CC and CV 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. 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. Lock Indication Lock Indication is a function that is used by a server layer MEP to indicate an administrative locking of a server layer which may result in consequential interruption of data traffic forwarding towards the client layer MEP(s) expecting this traffic. The reception of a Lock Indication allows a MEP to suppress alarms and to differentiate between a defect condition and an administrative locking action at the server layer MEP. 3.3.1. Existing tools There is no mechanism defined in the IETF to support this function. Sprecher, et al. Expires March 7, 2009 [Page 11] Internet-Draft MPLS-TP OAM Analysis September 2008 3.3.2. Recommendations and Guidelines Define a tool to support Lock Indication. 3.4. Packet Loss Measurement Packet Loss Measurement is a function that is used to verify the quality of the service. 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 Packet Loss Measurement. 3.5. Diagnostic Test A diagnostic test is a function that is used between MEPs to verify bandwidth throughput, packet loss, bit errors, etc. 3.5.1. Existing tools There is no mechanism defined in the IETF to support this function. 3.5.2. Recommendations and Guidelines Define a tool to support Diagnostic Test. 3.6. Trace Route Trace route is a function that is used to determine the route of a connection across the MPLS transport network. 3.6.1. Existing tools LSP Ping supports trace route but as it does not comply with the requirement for OAM functions to be independent on IP routing and forwarding capabilities, it can not be utilized for MPLS-TP 3.6.2. Recommendations and Guidelines Define a new tool to support Trace Route. Sprecher, et al. Expires March 7, 2009 [Page 12] Internet-Draft MPLS-TP OAM Analysis September 2008 3.7. 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. 3.7.1. Existing tools There is no mechanism defined in the IETF that fulfills all of the MPLS-TP OAM requirements. 3.7.2. Recommendations and Guidelines Define a tool to support Delay Measurement. 3.8. 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. This function should be supported in pro-active mode. 3.8.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.8.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. Sprecher, et al. Expires March 7, 2009 [Page 13] Internet-Draft MPLS-TP OAM Analysis September 2008 3.9. Client Signal Fail Client Signal Fail function (CSF) is used to propagate a Client Failure indication to the far-end sink when alarm suppression in the client layer is not supported. 3.9.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.9.2. Recommendations and Guidelines Either extend the BFD tool or define a tool to support Client Signal Fail propagation. 4. Recommendation o Define a Tandem Connection entity for both LSPs and PWs and allow the transmission of traffic by means of label stacking and proper TTL setting. o Extend the ACH to provide a control channel for MPLS-TP Links, LSPs, and Tandem Connections. 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 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 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: * Connectivity verification * Alarm suppression * Lock indication Sprecher, et al. Expires March 7, 2009 [Page 14] Internet-Draft MPLS-TP OAM Analysis September 2008 * Packet loss measurement * Diagnostic test * Trace-route * Delay measurement * Remote defect indication * Client signal fail o The tools may have the capability to authenticate the messages. Notes: 1. We may consider having a document to define common CC and CV types of ACH for the use of VCCV and VPCV. 2. We may consider changing the name of the ACH "CV Type" to "Protocol Type" in order to avoid confusion with the CV function that is defined in [MPLS-TP OAM Requirements] 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. 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. Sprecher, et al. Expires March 7, 2009 [Page 15] Internet-Draft MPLS-TP OAM Analysis September 2008 [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] Vigoreux, M., Betts, M., and D. Ward, "Requirements for OAM in MPLS Transport Networks", ID draft-vigoreux-mpls-tp-oam-requirements-00, July 2008. [MPLS-TP Requirments] Nadeau, T. and C. Pignataro, "Requirements for the Trasport Profile of MPLS", ID draft-jenkins-mpls-mplstp-requirements-00, July 2008. Sprecher, et al. Expires March 7, 2009 [Page 16] Internet-Draft MPLS-TP OAM Analysis September 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 March 7, 2009 [Page 17] Internet-Draft MPLS-TP OAM Analysis September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Sprecher, et al. Expires March 7, 2009 [Page 18]