--- 1/draft-ietf-mpls-tp-oam-requirements-03.txt 2009-12-16 21:12:12.000000000 +0100 +++ 2/draft-ietf-mpls-tp-oam-requirements-04.txt 2009-12-16 21:12:12.000000000 +0100 @@ -1,21 +1,28 @@ MPLS Working Group M. Vigoureux, Ed. Internet-Draft Alcatel-Lucent Intended status: Standards Track D. Ward, Ed. -Expires: March 4, 2010 Cisco Systems, Inc. +Expires: June 19, 2010 Cisco Systems, Inc. M. Betts, Ed. Huawei - August 31, 2009 + December 16, 2009 Requirements for OAM in MPLS Transport Networks - draft-ietf-mpls-tp-oam-requirements-03 + draft-ietf-mpls-tp-oam-requirements-04 + +Abstract + + This document lists architectural and functional requirements for the + Operations, Administration and Maintenance of MPLS Transport Profile. + These requirements apply to pseudowires, Label Switched Paths, and + Sections. 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. @@ -24,78 +31,75 @@ 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 4, 2010. + This Internet-Draft will expire on June 19, 2010. 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. - -Abstract - - This document lists architectural and functional requirements for the - Operations, Administration and Maintenance of MPLS Transport Profile. - These requirements apply to pseudowires, Label Switched Paths, and - Sections. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language and Terminology . . . . . . . . . . 4 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5 - 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 + 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 6 + 2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 2.1.4. Interoperability and Interworking . . . . . . . . . . 7 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 7 + 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 - 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 + 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 - 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9 - 2.2.4. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 9 - 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 - 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 10 + 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10 + 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 + 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 10 + 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 - 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 11 + 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 - 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 12 - 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 12 + 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13 + 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13 - 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 13 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction - In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), + In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), the rationales for Operations, Administration and Maintenance (OAM) are twofold as it can serve: o as a network-oriented functionality, used by a transport network operator to monitor his network infrastructure and to implement internal mechanisms in order to enhance the general behaviour and the level of performance of his network (e.g., protection mechanism in case of node or link failure). As an example, fault localization is typically associated with this use case. @@ -126,102 +130,125 @@ domain environment and allows for the determination of service degradation due, for example, to packet delay or packet loss. 1.1. Scope of this Document This document lists architectural and functional requirements for the OAM functionality of MPLS-TP. These requirements apply to pseudowires (PWs), Label Switched Paths (LSPs) and Sections. These requirements are derived from the set of requirements specified - by ITU-T and published in the ITU-T Supplement Y.Sup4 [7]. + by ITU-T and published in the ITU-T Supplement Y.Sup4 [10]. By covering transport specificities, these requirements complement - those identified in RFC 4377 [8], yet some requirements may be + those identified in RFC 4377 [11], yet some requirements may be similar. This document only lists architectural and functional OAM requirements. It does not detail the implications of their applicability to the various types (e.g., point-to-point, point-to- multipoint, unidirectional, bidirectional ...) of PWs, LSPs and Sections. Furthermore, this document does not provide requirements on how the protocol solution(s) should behave to achieve the - functional objectives. Please see [9] for further information. + functional objectives. Please see [12] for further information. Note that the OAM functions identified in this document may be used for fault management, performance monitoring and/or protection switching applications. For example, connectivity verification can be used for fault management by detecting failure conditions, but may also be used for performance monitoring through its contribution to the evaluation of performance metrics (e.g., unavailability time). Nevertheless, it is outside the scope of this document to specify which function should be used for which application. + Note also that it is anticipated that implementers may wish to + implement OAM message handling in hardware. Although not a + requirement, this fact could be taken as a design consideration. + 1.2. Requirements Language and Terminology Although this document is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be - interpreted as described in RFC 2119 [1] and are to be interpreted as + interpreted as described in RFC 2119 [2] and are to be interpreted as instructions to the protocol designers producing solutions that satisfy the requirements set out in this document. In this document we refer to the inability of a function to perform a required action, as a fault. This does not include an inability due to preventive maintenance, lack of external resources, or planned - actions. See also ITU-T G.806 [2]. + actions. See also ITU-T G.806 [3]. In this document we refer to the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted, as a defect. See also ITU-T G.806 - [2]. + [3]. + + In this document we refer to OAM actions which are carried out + continuously or at least on long periods of time, permitting + proactive reporting of fault and/or performance results, as proactive + OAM. + + In this document we refer to OAM actions which are initiated via + manual intervention for a limited time to carry out troubleshooting, + as on-demand OAM. In this document we refer to a Label Edge Router (LER), for a given LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a given PW, as an End Point. Further, we refer to a Label Switching Router (LSR), for a given LSP, and to a PW Switching Provider Edge (S-PE), for a given PW, as an Intermediate Point. This document does not make a distinction between End Points (e.g., source and destination) as it can be inferred from the context of the sentences. In this document we use the term "node" as a general reference to End Points and Intermediate Points. In this document we refer to both segment and concatenated segments - as segments (see [6] for definitions relating to the term "segment" + as segments (see [1] for definitions relating to the term "segment" as well as for other definitions relating to MPLS-TP). In this document we refer to both single segment PWs and multi- segment PWs as PWs. In this document we refer to both bidirectional associated LSPs and bidirectional co-routed LSPs as bidirectional LSPs. 2. OAM Requirements This section lists the requirements by which the OAM functionality of MPLS-TP should abide. The requirements listed below may be met by one or more OAM protocols; the definition or selection of these protocols is outside the scope of this document. + RFC5654 [1] states (Requirement #2) that the MPLS-TP design SHOULD as + far as reasonably possible reuse existing MPLS standards. This + general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined + in this document through a set of functional requirements. These + requirements will be met by protocol solutions defined in other + documents. The way in which those protocols are operated and the way + in which a network operator can control and use the MPLS-TP OAM + functions SHOULD be as similar as possible to the mechanisms and + techniques used to operate OAM in other transport technologies. + 2.1. Architectural Requirements 2.1.1. Scope of OAM The protocol solution(s) developed to meet the requirements identified in this document MUST at least be applicable to point-to- point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections. Section 2.2 provides additional information with regards to the applicability to point-to- - point associated bidirectional LSPs, point-to-point undirectional + point associated bidirectional LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs. The service emulated by a PW may span multiple domains. An LSP may also span multiple domains. The protocol solution(s) MUST be applicable end-to-end and to segments. More generally, it MUST be possible to operate OAM functions on a per domain basis and across multiple domains. Since LSPs may be stacked, the protocol solution(s) MUST be applicable on any LSP, regardless of the label stack depth. @@ -284,31 +311,32 @@ 2.1.4. Interoperability and Interworking It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.3. It is also REQUIRED that the first two requirements of Section 2.1.3 still hold and MUST still be met when interoperability is achieved. When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM - protocols (e.g., LSP-Ping [3], MPLS-BFD [10], VCCV [4] and VCCV-BFD - [11]). + protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD + [14]). 2.1.5. Data Plane OAM functions operate in the data plane. OAM packets MUST run in- band; that is, OAM packets for a specific PW, LSP or Section MUST follow the exact same data path as user traffic of that PW, LSP or Section. This is often referred to as fate sharing. It MUST be possible to discriminate user traffic from OAM packets. + This includes a means to differentiate OAM packets from user traffic as well as the capability to apply specific treatment to OAM packets, at the nodes processing these OAM packets. As part of the design of OAM protocol solution(s) for MPLS-TP, a mechanism, for enabling the encapsulation and differentiation of OAM messages on a PW, LSP or Section, MUST be provided. Such mechanism SHOULD also support the encapsulation and differentiation of existing IP/MPLS and PW OAM messages. @@ -353,103 +381,105 @@ It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), effectively provides a fully featured function; that is, a function which is applicable to all the cases identified for that functionality. In that context, protocol solution(s) MUST state their applicability. Unless otherwise stated, the OAM functionalities MUST NOT rely on user traffic; that is, only OAM messages MUST be used to achieve the objectives. + For the on-demand OAM functions, the result of which may vary + depending on packet size, it SHOULD be possible to perform these + functions using different packet sizes. + 2.2.1. General Requirements If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST be provided to detect it, diagnose it, localize it, and notify the appropriate nodes. Mechanisms SHOULD exist such that corrective actions can be taken. Furthermore, mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides, even if the fault or defect is located outside of his domain. Protocol solution(s) developed to meet these requirements may rely on information exchange. Information exchange between various nodes involved in the operation of an OAM function SHOULD be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes. 2.2.2. Continuity Checks The MPLS-TP OAM toolset MUST provide a function to enable an End - Point to determine whether or not it receives traffic on a PW, LSP or - Section. + Point to monitor the liveness of a PW, LSP or Section. This function SHOULD be performed between End Points of PWs, LSPs and Sections. This function SHOULD be performed pro-actively. The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs. 2.2.3. Connectivity Verifications The MPLS-TP OAM toolset MUST provide a function to enable an End - Point of a PW, LSP or Section to determine whether or not the - connectivity provided to an other node through a PW, LSP or Section - is effective (i.e., that a packet sent on that PW, LSP or Section, - reaches the expected node). + Point to determine whether or not it is connected to specific End + Point(s) by means of the expected PW, LSP or Section. This function SHOULD be performed pro-actively between End Points of PWs, LSPs and Sections. This function SHOULD be performed on-demand between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. The protocol solution(s) developed to perform this function pro- actively MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs. The protocol solution(s) developed to perform this function on-demand MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs and point-to-multipoint LSPs in case a return path exists. -2.2.4. Diagnostic Tests +2.2.4. Route Tracing - The MPLS-TP OAM toolset MUST provide a function to enable conducting - diagnostic tests on a PW, LSP or Section. An example of such - diagnostic test consists in looping the traffic at an Intermediate - Point back to the originating End Point. Another example of such - diagnostic test consists in estimating the bandwidth of e.g., an LSP. + The MPLS-TP OAM toolset MUST provide functionality to enable an End + Point to discover the Intermediate (if any) and End Point(s) along a + PW, LSP or Section, and more generally to trace the route of a PW, + LSP or Section. The information collected MUST include identifiers + related to the nodes and interfaces composing that route. This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to- point unidirectional LSPs and point-to-multipoint LSPs in case a return path exists. -2.2.5. Route Tracing +2.2.5. Diagnostic Tests - The MPLS-TP OAM toolset MUST provide functionality to enable an End - Point to discover the Intermediate (if any) and End Point(s) along a - PW, LSP or Section, and more generally to trace the route of a PW, - LSP or Section. The information collected MUST include identifiers - related to the nodes and interfaces composing that route. + The MPLS-TP OAM toolset MUST provide a function to enable conducting + diagnostic tests on a PW, LSP or Section. An example of such + diagnostic test consists of performing a loop-back function at a node + such that all OAM and data traffic are looped back to the originating + End Point. Another example of such diagnostic test consists in + estimating the bandwidth of e.g., an LSP. This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to- point unidirectional LSPs and point-to-multipoint LSPs in case a @@ -554,47 +584,51 @@ 2.2.11. Packet Loss Measurement The MPLS-TP OAM toolset MUST provide a function to enable the quantification of packet loss ratio over a PW, LSP or Section. Note that packet loss ratio is the ratio of the user packets not delivered to the total number of user packets transmitted during a defined time interval. The number of user packets not delivered is the difference between the number of user packets transmitted by an End Point and the number of user packets received at an End Point. + See also [6]. This function MAY either be performed pro-actively or on-demand. This function SHOULD be performed between End Points of PWs, LSPs and Sections. It SHOULD be possible to rely on user traffic to perform that functionality. The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs. 2.2.12. Packet Delay Measurement The MPLS-TP OAM toolset MUST provide a function to enable the quantification of the one-way, and if appropriate, the two-way, delay of a PW, LSP or Section. + Note that o One-way delay is the time elapsed from the start of transmission of the first bit of a packet by an End Point until the reception - of the last bit of that packet by the other End Point. + of the last bit of that packet by the other End Point. See also + [7]. o Two-way delay is the time elapsed from the start of transmission of the first bit of a packet by a End Point until the reception of - the last bit of that packet by the same End Point, when loopback - is performed at the other End Point. + the last bit of that packet by the same End Point. See also [8]. + Two-way delay may be quantified using data traffic loopback at the + remote End Point of the PW, LSP or Section (see Section 2.2.5). This function SHOULD be performed on-demand and MAY be performed pro- actively. This function SHOULD be performed between End Points of PWs, LSPs and Sections. The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs and point-to-multipoint LSPs but only to enable @@ -611,25 +645,27 @@ but OAM, as such, is subject to several security considerations. OAM messages can reveal sensitive information such as passwords, performance data and details about e.g., the network topology. The nature of OAM therefore suggests having some form of authentication, authorization and encryption in place. This will prevent unauthorized access to MPLS-TP equipment and it will prevent third parties from learning about sensitive information about the transport network. - In general, mechanisms SHOULD be provided to ensure that OAM - functions cannot be accessed unauthorized. + OAM systems (network management stations) SHOULD be designed such + that OAM functions cannot be accessed without authorization. - Further, OAM messages MAY be authenticated to prove their origin and - to make sure that they are destined for the receiving node. + OAM protocol solutions MUST include the facility for OAM messages to + authenticated to prove their origin and to make sure that they are + destined for the receiving node. The use of such facilities MUST be + configurable. An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. 5. IANA Considerations There are no IANA actions required by this draft. 6. Acknowledgements @@ -642,66 +678,75 @@ The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS-TP. 7. References 7.1. Normative References - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and + S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, + September 2009. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] ITU-T Recommendation G.806, "Characteristics of transport + [3] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", 2009. - [3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label + [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. - [4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit + [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. -7.2. Informative References + [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet + Loss Metric for IPPM", RFC 2680, September 1999. - [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in - Transport Networks", draft-ietf-mpls-tp-framework-03 (work in - progress), August 2009. + [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay + Metric for IPPM", RFC 2679, September 1999. - [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and - S. Ueno, "MPLS-TP Requirements", - draft-ietf-mpls-tp-requirements-10 (work in progress), - August 2009. + [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay + Metric for IPPM", RFC 2681, September 1999. - [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on +7.2. Informative References + + [9] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework + for MPLS in Transport Networks", + draft-ietf-mpls-tp-framework-06 (work in progress), + October 2009. + + [10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", 2008. - [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. + [11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. - [9] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and - Overview", draft-ietf-mpls-tp-oam-framework-01 (work in - progress), July 2009. + [12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM + Framework", draft-ietf-mpls-tp-oam-framework-04 (work in + progress), December 2009. - [10] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD + [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), June 2008. - [11] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding - Detection (BFD) for the Pseudowire Virtual Circuit - Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 - (work in progress), July 2009. + [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding + Detection (BFD) for the Pseudowire Virtual Circuit Connectivity + Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in + progress), July 2009. Authors' Addresses Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France Email: martin.vigoureux@alcatel-lucent.com