Network Working Group N. Bahadur, Ed. Internet-Draft R. Aggarwal Intended status: Standards Track Juniper Networks, Inc. Expires: January 6, 2010 T. Nadeau BT N. Sprecher Y. Weingarten Nokia Siemens Networks July 5, 2009 LSP-Ping and BFD for MPLS-TP draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-00 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 January 6, 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. Bahadur, et al. Expires January 6, 2010 [Page 1] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 Abstract LSP-Ping and BFD for MPLS are existing and widely deployment OAM mechanisms for MPLS LSPs. This document describes how LSP-Ping and BFD for MPLS can be used to perform OAM on MPLS-TP LSPs. This document describes extensions to LSP-Ping when IP addressing is not in use, in a MPLS-TP deployment scenario. These extensions are also meant to be applicable when it is desirable to avoid the use of IP encapsulation for exchanging LSP-Ping OAM messages. This document also clarifies the use of BFD for MPLS-TP LSPs when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4 1.2. Existing LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5 2. LSP-Ping extensions . . . . . . . . . . . . . . . . . . . . . 5 2.1. LSP-Ping packet over ACH . . . . . . . . . . . . . . . . . 5 2.2. LSP-Ping packet over PW-ACH . . . . . . . . . . . . . . . 6 2.3. New address type for Downstream Mapping TLV . . . . . . . 6 2.4. Source Address TLV . . . . . . . . . . . . . . . . . . . . 6 2.5. Destination Address TLV . . . . . . . . . . . . . . . . . 7 3. Performing LSP-Ping over MPLS-TP LSPs . . . . . . . . . . . . 7 3.1. Traditional LSP-Ping . . . . . . . . . . . . . . . . . . . 7 3.2. Non-IP based LSP-Ping . . . . . . . . . . . . . . . . . . 8 3.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 9 4. Performing LSP Traceroute over MPLS-TP LSPs . . . . . . . . . 9 4.1. Traditional LSP Traceroute . . . . . . . . . . . . . . . . 10 4.2. Non-IP based LSP Traceroute . . . . . . . . . . . . . . . 10 4.2.1. Ingress node procedure for sending echo request packets . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Ingress node procedure for receiving echo response packets . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Transit and egress node procedure . . . . . . . . . . 10 4.3. P2MP Considerations . . . . . . . . . . . . . . . . . . . 11 4.4. ECMP Considerations . . . . . . . . . . . . . . . . . . . 11 5. Running BFD over MPLS-TP LSPs . . . . . . . . . . . . . . . . 11 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8.1. New ACH Channel Type . . . . . . . . . . . . . . . . . . . 12 8.2. New LSP-Ping TLV Types . . . . . . . . . . . . . . . . . . 13 Bahadur, et al. Expires January 6, 2010 [Page 2] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Bahadur, et al. Expires January 6, 2010 [Page 3] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 1. Introduction LSP-Ping [RFC4379] and [I-D.ietf-bfd-mpls] are OAM mechanisms for MPLS LSPs. This document describes how LSP-Ping and BFD for MPLS can be used to perform OAM on MPLS-TP LSPs. The document considers two cases. The first is when IP addressing and host stack are available on egress and transit LSRs. The second is when such capabilities are either not available or it is not desirable to use them. Sections Section 3.2 and Section 4.2 describes the theory of operation for performing LSP-Ping over MPLS-TP LSPs. Section Section 2.1 describes the new TLVs and LSP-Ping extensions for performing LSP-Ping in the absence of IP addressing. 1.1. Conventions used in this document 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]. 1.2. Existing LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism LSP-Ping requires IP addressing on the egress and transit LSRs for performing OAM on MPLS signaled LSPs and pseudowires. BFD for MPLS LSPs also requires IP addressing. In particular, in these cases the LSP-Ping and BFD packets generated by an ingress LSR are encapsulated in an IP/UDP header with the destination address from the 127/8 range and then encapsulated in the MPLS label stack ([RFC4379] , [I-D.ietf-bfd-mpls]). Egress LSRs use the presence of the 127/8 destination address to identify the OAM packets and rely further on the UDP port number to determine whether the packet is a LSP-Ping or a BFD packet. It is to be noted that this determination does not require IP forwarding capabilities. It requires the presence of an IP host stack which enables egress LSRs to process packets with a destination address from the 127/8 range. [RFC1122] allocates the 127/8 range as "Internal host loopback address" and [RFC1812] states that "a router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127". LSP-Ping and BFD for MPLS specify procedures that allow an egress LSR to use a MPLS LSP for forwarding LSP-Ping or BFD packets to the ingress LSR. This ensures that IP forwarding capabilities are not required and meets the MPLS-TP requirement of not having IP forwarding capabilities. [I-D.ietf-mpls-tp-framework] specifies that IP addressing is the default addressing mechanism for MPLS-TP networks. An IP host stack must be present when IP addressing is in use. This implies that Bahadur, et al. Expires January 6, 2010 [Page 4] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 exisiting LSP-Ping and BFD procedures can be used as is in MPLS-TP environments when IP addressing is in use. 1.3. Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism In certain MPLS-TP deployment scenarios IP addressing might not be available or it may be preferred to use non-IP encapsulation for LSP- Ping and BFD packets. To enable re-use of OAM techniques provided by LSP-Ping and BFD in such networks, rest of this document defines extensions to LSP-Ping and procedures for using BFD. The document defines a new code-point for using LSP-Ping with an ACH header. Further, it describes how LSP-Ping can be used to perform Connectivity Verification, Route Tracing and Adjacency functions specified in [I-D.ietf-mpls-tp-oam-requirements]. This document also clarifies the usage of BFD in the context of MPLS-TP LSPs. Sections Section 3.2 and Section 4.2 describe the theory of operation for performing LSP-Ping over MPLS-TP LSPs with a non-IP encapsulation. Section 2.1 describes the new TLVs and LSP-Ping extensions for performing LSP-Ping in the absence of IP addressing. Section 5 describes procedures for using BFD with non-IP encapsulation." 2. LSP-Ping extensions 2.1. LSP-Ping packet over ACH [RFC5586] defines an ACH mechanism for MPLS LSPs. This document defines a new ACH channel type for when IP addressing is not in use for LSP-Ping over associated bi-directional LSPs and co-routed bi- directional LSPs. ACH TLVs CANNOT be associated with LSP-Ping channel type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LSP-Ping ACH Channel Type Bahadur, et al. Expires January 6, 2010 [Page 5] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 2.2. LSP-Ping packet over PW-ACH [RFC4385] defines an PW-ACH mechanism for pseudowires. The ACH channel type for LSP-Ping defined in Section 2.1 will be re-used for pseudowires so that IP addressing is not needed when using LSP-Ping OAM over pseudowires. 2.3. New address type for Downstream Mapping TLV [RFC4379] defines the Downstream Mapping TLV. A new type is being added to the Address Type field as follows: Type # Address Type K Octets ------ -------------- -------- 0 Not Applicable 8 Figure 2: Downstream Mapping TLV new Address Type The new address type indicates that no address is present in the Downstream Mapping TLV. Multipath type MAY be set to 0 (no mutlpath) when using this address type. When this address type is used, on receipt of a lsp-ping echo request, both interface verification and label stack validation MUST be bypassed. The new address type is also applicable to the Detailed Downstream Mapping TLV defined in [I-D.ietf-mpls-lsp-ping-enhanced-dsmap]. 2.4. Source Address TLV A new optional TLV is being defined for encapsulating the source address. The optional TLV will be part of the TLVs defined in [RFC4379]. Only 1 source address TLV MUST be present in a LSP-Ping packet. The source address MUST specify the address of the originator of the packet. If more than 1 such TLV is present in a LSP-Ping request packet, then an error of "Malformed echo request received" SHOULD be returned. If more than 1 source address TLV is present in a LSP-Ping response packet, then the packet SHOULD be dropped without further processing. The source address TLV MUST NOT be used if IP addressing is in use. If IP addressing is in use, then one should use lsp-ping with IP. The format of the TLV is TBD. Bahadur, et al. Expires January 6, 2010 [Page 6] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 2.5. Destination Address TLV A new optional TLV is being defined for encapsulating the destination address. The optional TLV will be part of the TLVs defined in [RFC4379]. One or more of this TLV MAY be included in a LSP-Ping request message. If more than 1 destination address TLV is present in a LSP-Ping response packet, then the packet SHOULD be dropped without further processing. The destination address MUST specify the intended receipient(s) of the packet. If the destination address specified in any of the Destination Address TLVs does not match any address associated with the node which receives the LSP-Ping packet, then the LSP-Ping packet SHOULD be dropped without further processing. The destination address TLV MUST NOT be used if IP addressing is in use. If IP addressing is in use, then one should use lsp-ping with IP. The format of the TLV is TBD. 3. Performing LSP-Ping over MPLS-TP LSPs This section specifies how LSP-Ping ping can be used in the context of MPLS-TP LSPs. The LSP-Ping ping function meets the Connectivity Verification requirement specified in [I-D.ietf-mpls-tp-oam-requirements]. 3.1. Traditional LSP-Ping Traditional LSP-Ping packets ride over the LSP and contain an IP/UDP packet within them. The IP header is not used for forwarding (since the LSP is forwarded using MPLS label switching). The IP header is used mainly for addressing and can be used in the context of MPLS-TP LSPs. This form of LSP-Ping OAM MUST be supported for MPLS-TP LSPs when IP addressing is in use. The figure below shows an MPLS-TP LSP- Ping OAM packet. Bahadur, et al. Expires January 6, 2010 [Page 7] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP/UDP Headers | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LSP-Ping packet The LSP-Ping Reply mode [RFC4379] in the LSP-Ping echo request MUST be set to 4 (Reply via application level control channel). The LSP-Ping reply message MUST be sent on the reverse path of the LSP. The reply MUST contain IP/UDP headers followed by the LSP-Ping payload. The destination address in the IP header MUST be set to that of the sender of the request message. The source adderss in the IP header MUST be set to a valid address of the replying node. 3.2. Non-IP based LSP-Ping The OAM procedures defined in [RFC4379] require the use of IP addressing and in some cases IP routing to perform OAM functions. When the ACH header is used, IP addressing and routing is not needed. This section describes procedures for performing lsp-ping without a dependency on IP. When ACH header is used, an LSP-Ping packet will look as follows: Bahadur, et al. Expires January 6, 2010 [Page 8] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: LSP-Ping packet with ACH When using LSP-Ping over the ACH header, the LSP-Ping Reply mode [RFC4379] in the LSP-Ping echo request MUST be set to 4 (Reply via application level control channel). The ingress node MAY attach a Source Address TLV (Section 2.4) to identify the node originating the request. The LSP-Ping reply message MUST be sent on the reverse path of the LSP using ACH. The LSP-Ping payload MUST directly follow the ACH header and no IP and/or UDP headers MUST be attached. If the request message contained the Source Address TLV and a response is being sent to the originator, then a Destination Address TLV (Section 2.5) SHOULD be added to the reply message. The contents of the LSP-Ping request Source Address TLV should be copied into the LSP-Ping response Destination Address TLV. The responding node MAY attach a Source Address TLV to identify the node sending the response. 3.3. P2MP Considerations [I-D.ietf-mpls-p2mp-lsp-ping] describes how LSP-Ping can be used for OAM on P2MP LSPs. The procedures described in this draft apply as is irrespective of whether we use the mechanism specified in Section 3.1 or the mechanism specified in Section 3.2. 4. Performing LSP Traceroute over MPLS-TP LSPs This section specifies how LSP-Ping traceroute can be used in the context of MPLS-TP LSPs. The LSP-Ping traceroute function meets the Adjancency and Route Tracing requirement specified in [I-D.ietf-mpls-tp-oam-requirements]. Bahadur, et al. Expires January 6, 2010 [Page 9] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 When performing lsp-ping traceroute, the ingress node inserts a Downstream Mapping TLV to get the downstream node information and to enable LSP verification along the transit nodes. The Downstream mapping TLV can be used as is for performing the traceroute. If IP addressing is not in use, then the Address Type field in the Downstream Mapping TLV can be set to "Not applicable" (Section 2.3). The Downstream Mapping TLV address type field can be extended to include other address types as need be. 4.1. Traditional LSP Traceroute The mechanics of LSP-Ping traceroute are similar to those described for ping in Section 3.1. Traceroute packets sent by the lsp ingress MUST adhere to the format described in Section 3.2.This form of LSP- Ping OAM MUST be supported for MPLS-TP LSPs, when IP addressing is in use. 4.2. Non-IP based LSP Traceroute This section describes the procedures for performing lsp-traceroute when using the ACH header and without any dependency on IP addressing. The procedures specified in Section 3.2 with regards to Source Address TLV and Destination Address TLV apply to LSP traceroute as well. 4.2.1. Ingress node procedure for sending echo request packets Traceroute packets sent by the lsp ingress MUST adhere to the format described in Section 3.2. MPLS-TTL expiry (as described in [RFC4379]) will be used to direct the packets to specific nodes along the LSP path. 4.2.2. Ingress node procedure for receiving echo response packets The lsp-ping traceroute responses will be received on the LSP itself and the presence of an ACH header with channel type of LSP-Ping is an indicator that the packet contains LSP-ping payload. 4.2.3. Transit and egress node procedure When a echo request reaches the transit or egress, the presence of the ACH channel type of LSP-Ping will indicate that the packet contains LSP-Ping data. The LSP-Ping data and the label stack should be able to identify the LSP associated with the echo request packet. In case if there is an error and the node is unable to idenfity the LSP on which the echo response should to be sent, the node MUST drop the echo request packet and not send any response back. All responses MUST always be sent on a LSP path using the ACH header and Bahadur, et al. Expires January 6, 2010 [Page 10] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 ACH channel type of LSP-Ping. 4.3. P2MP Considerations [I-D.ietf-mpls-p2mp-lsp-ping] describes how LSP-Ping can be used for OAM on P2MP LSPs. The procedures described in this draft apply as is irrespective of whether we use the mechanism specified in Section 4.1 or the mechanism specified in Section 4.2. 4.4. ECMP Considerations LSP-Ping using ACH SHOULD NOT be used when there is ECMP (equal cost multiple paths) for a given LSP. The addition of the additional ACH header may modify the hashing behavior for OAM packets which may result in incorrect modeling of path taken by data traffic. 5. Running BFD over MPLS-TP LSPs [I-D.ietf-bfd-mpls] describes how BFD can be used for Continuity Check for MPLS LSPs. When IP addressing is in use, the procedures described in [I-D.ietf-bfd-mpls] apply as is. This section clarifies the usage of BFD in the context of MPLS-TP LSPs when it is not desirable to use IP encapsulation. When using BFD over MPLS-TP LSPs, the BFD descriminator MAY either be signaled via LSP-Ping or be statically configured. The BFD packets MUST be sent over ACH when IP encapsulation is not used. BFD packets, for both directions, MUST be sent over the MPLS-TP LSP and IP forwarding SHOULD NOT be used for the reverse path. The format of a BFD packet when using it as an OAM tool for MPLS-TP LSPs SHOULD be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload depending on channel type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: BFD packet over MPLS-TP LSPs Bahadur, et al. Expires January 6, 2010 [Page 11] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 [I-D.ietf-pwe3-vccv-bfd] specifies how BFD can be used over MPLS PWs. Of specific interest are 2 modes: 1. Channel type is IP and payload contains BFD packet with IP/UDP headers. 2. Channel type is BFD and payload contains BFD packet without IP/ UDP headers. The first mode MUST be supported for BFD over MPLS-TP LSPs. The second mode MAY be supported in addition. Thus, no changes in BFD and no new code-points are needed to run BFD over MPLS-TP LSPs. BFD supports continuous fault monitoring and thus meets the Continuity Check requirement specified in [I-D.ietf-mpls-tp-oam-requirements]. For point to multipoint Continuity Check, there is work in progress on using BFD for P2MP MPLS LSPs ( [I-D.katz-ward-bfd-multipoint]) and this can be leveraged for MPLS-TP LSPs as well. 6. Applicability The procedures described in this document apply to MPLS LSPs and as well as to LSPs based on the MPLS-TP profile. The LSP-Ping procedures can be used for performing OAM on both LSPs and Pseudowires. 7. Security Considerations The draft does not introduce any new security considerations. Those discussed in [RFC4379] are also applicable to this document. 8. IANA Considerations 8.1. New ACH Channel Type A new Channel type is defined in Section 2.1. IANA is requested to assign a new value from the "PW Associated Channel Type" registry, as per IETF consensus policy. Value Meaning ----- ------- TBD Associated Channel carries LSP-Ping packet Bahadur, et al. Expires January 6, 2010 [Page 12] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 8.2. New LSP-Ping TLV Types New TLV types are defined in Section 2.4 and Section 2.5. IANA is requested to assign values from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, "TLVs and sub-TLVs" sub- registry from the range of 32768-64511. Value Meaning ----- ------- TBD Source Address TBD Destination Address 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC4385] 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. 9.2. Informative References [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), June 2008. [I-D.ietf-mpls-lsp-ping-enhanced-dsmap] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for performing LSP-Ping over MPLS tunnels", draft-ietf-mpls-lsp-ping-enhanced-dsmap-02 (work in progress), February 2009. [I-D.ietf-mpls-p2mp-lsp-ping] Yasukawa, S., Farrel, A., Ali, Z., Fenner, B., Swallow, G., and T. Nadeau, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-07 (work in progress), Bahadur, et al. Expires January 6, 2010 [Page 13] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 September 2008. [I-D.ietf-mpls-tp-framework] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-01 (work in progress), June 2009. [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-02 (work in progress), June 2009. [I-D.ietf-pwe3-vccv-bfd] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-05 (work in progress), June 2009. [I-D.katz-ward-bfd-multipoint] Katz, D. and D. Ward, "BFD for Multipoint Networks", draft-katz-ward-bfd-multipoint-02 (work in progress), February 2009. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. Authors' Addresses Nitin Bahadur (editor) Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Phone: +1 408 745 2000 Email: nitinb@juniper.net URI: www.juniper.net Bahadur, et al. Expires January 6, 2010 [Page 14] Internet-Draft LSP-Ping and BFD for MPLS-TP July 2009 Rahul Agrawal Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Phone: +1 408 745 2000 Email: rahul@juniper.net URI: www.juniper.net Thomas D. Nadeau BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom Email: tom.nadeau@bt.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel Phone: +972-9-775 1229 Email: nurit.sprecher@nsn.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 Bahadur, et al. Expires January 6, 2010 [Page 15]