| TOC |
|
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 7, 2010.
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.
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.
1.
Introduction
1.1.
Conventions used in this document
1.2.
Existing LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism
1.3.
Non-IP LSP-Ping and BFD for MPLS LSPs Encapsulation Mechanism
2.
LSP-Ping extensions
2.1.
LSP-Ping packet over ACH
2.2.
LSP-Ping packet over PW-ACH
2.3.
New address type for Downstream Mapping TLV
2.4.
Source Address TLV
2.5.
Destination Address TLV
3.
Performing LSP-Ping over MPLS-TP LSPs
3.1.
Traditional LSP-Ping
3.2.
Non-IP based LSP-Ping
3.3.
P2MP Considerations
4.
Performing LSP Traceroute over MPLS-TP LSPs
4.1.
Traditional LSP Traceroute
4.2.
Non-IP based LSP Traceroute
4.2.1.
Ingress node procedure for sending echo request packets
4.2.2.
Ingress node procedure for receiving echo response packets
4.2.3.
Transit and egress node procedure
4.3.
P2MP Considerations
4.4.
ECMP Considerations
5.
Running BFD over MPLS-TP LSPs
6.
Applicability
7.
Security Considerations
8.
IANA Considerations
8.1.
New ACH Channel Type
8.2.
New LSP-Ping TLV Types
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
| TOC |
LSP-Ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) and [I‑D.ietf‑bfd‑mpls] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.) 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 (Non-IP based LSP-Ping) and Section 4.2 (Non-IP based LSP Traceroute) describes the theory of operation for performing LSP-Ping over MPLS-TP LSPs. Section Section 2.1 (LSP-Ping packet over ACH) describes the new TLVs and LSP-Ping extensions for performing LSP-Ping in the absence of IP addressing.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
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] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) , [I‑D.ietf‑bfd‑mpls] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.)). 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] (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) allocates the 127/8 range as "Internal host loopback address" and [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) 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] (Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” April 2010.) 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 exisiting LSP-Ping and BFD procedures can be used as is in MPLS-TP environments when IP addressing is in use.
| TOC |
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] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.). This document also clarifies the usage of BFD in the context of MPLS-TP LSPs.
Sections Section 3.2 (Non-IP based LSP-Ping) and Section 4.2 (Non-IP based LSP Traceroute) describe the theory of operation for performing LSP-Ping over MPLS-TP LSPs with a non-IP encapsulation. Section 2.1 (LSP-Ping packet over ACH) describes the new TLVs and LSP-Ping extensions for performing LSP-Ping in the absence of IP addressing. Section 5 (Running BFD over MPLS-TP LSPs) describes procedures for using BFD with non-IP encapsulation."
| TOC |
| TOC |
[RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) 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 |
| TOC |
[RFC4385] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.) defines an PW-ACH mechanism for pseudowires. The ACH channel type for LSP-Ping defined in Section 2.1 (LSP-Ping packet over ACH) will be re-used for pseudowires so that IP addressing is not needed when using LSP-Ping OAM over pseudowires.
| TOC |
[RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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] (Bahadur, N., Kompella, K., and G. Swallow, “Mechanism for performing LSP-Ping over MPLS tunnels,” October 2009.).
| TOC |
A new optional TLV is being defined for encapsulating the source address. The optional TLV will be part of the TLVs defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). 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.
| TOC |
A new optional TLV is being defined for encapsulating the destination address. The optional TLV will be part of the TLVs defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). 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.
| TOC |
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] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.).
| TOC |
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.
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] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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.
| TOC |
The OAM procedures defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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:
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] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) 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 (Source Address TLV)) 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 (Destination Address TLV)) 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.
| TOC |
[I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) 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 (Traditional LSP-Ping) or the mechanism specified in Section 3.2 (Non-IP based LSP-Ping).
| TOC |
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] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.).
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 (New address type for Downstream Mapping TLV)). The Downstream Mapping TLV address type field can be extended to include other address types as need be.
| TOC |
The mechanics of LSP-Ping traceroute are similar to those described for ping in Section 3.1 (Traditional LSP-Ping). Traceroute packets sent by the lsp ingress MUST adhere to the format described in Section 3.2 (Non-IP based LSP-Ping).This form of LSP-Ping OAM MUST be supported for MPLS-TP LSPs, when IP addressing is in use.
| TOC |
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 (Non-IP based LSP-Ping) with regards to Source Address TLV and Destination Address TLV apply to LSP traceroute as well.
| TOC |
Traceroute packets sent by the lsp ingress MUST adhere to the format described in Section 3.2 (Non-IP based LSP-Ping). MPLS-TTL expiry (as described in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.)) will be used to direct the packets to specific nodes along the LSP path.
| TOC |
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.
| TOC |
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 ACH channel type of LSP-Ping.
| TOC |
[I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) 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 (Traditional LSP Traceroute) or the mechanism specified in Section 4.2 (Non-IP based LSP Traceroute).
| TOC |
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.
| TOC |
[I‑D.ietf‑bfd‑mpls] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.) 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] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs,” June 2008.) 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 |
[I‑D.ietf‑pwe3‑vccv‑bfd] (Nadeau, T. and C. Pignataro, “Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV),” July 2009.) specifies how BFD can be used over MPLS PWs. Of specific interest are 2 modes:
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] (Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” March 2010.). For point to multipoint Continuity Check, there is work in progress on using BFD for P2MP MPLS LSPs ( [I‑D.katz‑ward‑bfd‑multipoint] (Katz, D. and D. Ward, “BFD for Multipoint Networks,” February 2009.)) and this can be leveraged for MPLS-TP LSPs as well.
| TOC |
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.
| TOC |
The draft does not introduce any new security considerations. Those discussed in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) are also applicable to this document.
| TOC |
| TOC |
A new Channel type is defined in Section 2.1 (LSP-Ping packet over ACH). 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
| TOC |
New TLV types are defined in Section 2.4 (Source Address TLV) and Section 2.5 (Destination Address TLV). 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
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC4379] | Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” RFC 4379, February 2006 (TXT). |
| [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 (TXT). |
| TOC |
| [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 (TXT). |
| [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-04 (work in progress), October 2009 (TXT). |
| [I-D.ietf-mpls-p2mp-lsp-ping] | Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” draft-ietf-mpls-p2mp-lsp-ping-10 (work in progress), March 2010 (TXT). |
| [I-D.ietf-mpls-tp-framework] | Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” draft-ietf-mpls-tp-framework-11 (work in progress), April 2010 (TXT). |
| [I-D.ietf-mpls-tp-oam-requirements] | Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” draft-ietf-mpls-tp-oam-requirements-06 (work in progress), March 2010 (TXT). |
| [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-07 (work in progress), July 2009 (TXT). |
| [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 (TXT). |
| [RFC1122] | Braden, R., “Requirements for Internet Hosts - Communication Layers,” STD 3, RFC 1122, October 1989 (TXT). |
| [RFC1812] | Baker, F., “Requirements for IP Version 4 Routers,” RFC 1812, June 1995 (TXT). |
| [RFC5586] | Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” RFC 5586, June 2009 (TXT). |
| TOC |
| 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 |
| 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 |