Network Working Group Ping Pan (Juniper Networks) Internet Draft Nischal Sheth (Juniper Networks) Expiration Date: January 2002 Dave Cooper (Global Crossing) Network Working Group Detecting Data Plane Liveliness in RSVP-TE draft-pan-lsp-ping-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2. Abstract This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSP's. The proposed mechanism requires a new optional RSVP object. The processing overhead imposed on LSR control plane is kept to minimum. draft-pan-lsp-ping-00.txt ^L[Page 1] Internet Draft draft-pan-lsp-ping-00.txt July 2001 3. Sub-IP Summary ID This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSP's. The proposed mechanism requires a new optional RSVP object. The processing overhead imposed on LSR control plane is kept to minimum. RELATED DOCUMENTS May be found in the "references" section. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Fits the MPLS box. WHY IS IT TARGETED AT THIS WG MPLS WG is currently looking at MPLS-specific error detection and recovery mechanisms. This work presents a simple mechanism to detect a specific MPLS data plane failure, that cannot be detected by MPLS control plane. One possible cause of such failure may be due to memory corruption. JUSTIFICATION The WG should consider this document, as it allows network operators to detect MPLS LSP data plane failures in the network. This type of failures had occurred in MPLS networks. 4. Motivation In the case where an LSP has failed to deliver user traffic, and the failure cannot be easily detected by the MPLS control plane (and specifically, RSVP-TE component), it would be desirable to provide a tool that would allow the users to detect such traffic "black holes" within a reasonable period of time. It is also important to make sure that while running a such tool, it does not introduce heavy processing overhead on LSR's, and does not open the doors for potential DOS attacks. In this document, we describe a mechanism, termed "LSP-ping", that allows to accomplish this goal. draft-pan-lsp-ping-00.txt ^L[Page 2] Internet Draft draft-pan-lsp-ping-00.txt July 2001 5. LSP-ping Extension 5.1. LSP-ping message During the LSP liveliness test, an ingress LSR may send a probe packet to an egress LSR's control plane. This packet must be encapsulated in UDP with a well-known port number. The reason for choosing UDP is described below. We call the UDP-encapsulated packet as "an LSP-ping message". Each LSP-ping message must carry sufficient amount of information that can identify the testing LSP. At minimum, it must contain an RSVP SESSION, an RSVP SENDER_TEMPLATE and an LSP_ECHO object, which is defined below. 5.2. RSVP-TE Extension To test an LSP's liveliness, an ingress LSR may send an LSP-ping message that contains an LSP_ECHO object over the testing LSP. When an egress LSR receives the message, it needs to acknowledge the ingress LSR by copying the LSP_ECHO object into a RSVP Resv message. The object has the following format: Class = LSP_ECHO (use form 11bbbbbb for compatibility) C-Type = 1 +-------------+-------------+-------------+-------------+ | Source Identifier | +-------------+-------------+-------------+-------------+ Source Identifier This value is assigned by ingress LSR to uniquely identify the sending process. This would allow an ingress LSR to identify the returned responses if there are multiple instances of LSP-ping running. draft-pan-lsp-ping-00.txt ^L[Page 3] Internet Draft draft-pan-lsp-ping-00.txt July 2001 6. Operation For the sake of brevity in the context of this document by "the control plane" we mean "the RSVP-TE component of the control plane". Consider there is an LSP between an ingress LSR and an egress LSR over multiple LSR hops. 6.1. Procedures at the ingress LSR Before initiating the liveliness test, the user must make sure that both ingress and egress LSR can support the LSR-ping. When an LSP needs to be tested, the ingress LSR sends ICMP ECHO_REQUEST packets [ICMP] over the LSP periodically (the value of the timer interval should be configurable). If the ingress LSR does not receive ICMP ECHO_REPLY packets from the egress for a long period of time, it is likely that there is an LSP failure on either the forward path (from ingress to egress) or the reverse path (from egress to ingress), or both. When the ingress LSR detects that the RSVP-TE states to the egress are still operational, the ingress LSR MUST send the LSP-ping messages to the egress periodically (the value of the timer interval should be configurable). If the ingress LSR does not receive an Resv message from the egress LSR that consists of an LSP_ECHO object within a period of time, it declares the LSP as "down". At this point, the ingress LSR should apply the necessary procedures to fix the LSP, that may include to generate a report message to the network operator, or tear-down the LSP and re-initiate a new LSP, or reroute user traffic to a backup LSP. 6.2. Procedures at the egress LSR When the egress LSR receives an ICMP ECHO_REQUEST message, it handles the message according to the procedures defined in [ICMP] (this is irrespective of whether the message is used for an LSP liveliness test or not). It is possible that the ICMP processing is entirely done by the hardware or in the IP fast data path, thus, the initial ICMP "ping" packets have little impact on control plane's performance. draft-pan-lsp-ping-00.txt ^L[Page 4] Internet Draft draft-pan-lsp-ping-00.txt July 2001 When the egress LSR receives an LSP-ping message, it needs to deliver the message to the control plane. To avoid potential DOS attacks, it is recommended to regulate the LSP-ping traffic going to the control plane. A rate limiter should be applied to the well-known UDP port defined above. At the control plane, base on the RSVP SESSION and SENDER_TEMPLATE objects carried in the LSP-ping message, the LSR can find the corresponding LSP from its RSVP-TE database. The LSR can insert the received LSP_ECHO object in a Resv message, and send it upstream toward the ingress LSR. 6.3. Procedures for the intermediate LSR's At the LSR's that support LSP-ping, the Resv messages that carry the LSP_ECHO object must be delivered upstream immediately. At LSR's that use RSVP refresh reduction, a Resv message that carries an LSP_ECHO object should be considered as a trigger message, and should be processed according to the procedures defined in [RSVP- REFRESH]. 7. Security Considerations The mechanism introduced in this document can prevent potential DOS attacks. The security considerations pertaining to the original RSVP protocol remain relevant. 8. Intellectual Property Considerations Juniper Networks, Inc. is seeking patent protection on technology described in this Internet-Draft. If technology in this Internet- Draft is adopted as a standard, Juniper Networks agrees to license, on reasonable and non-discriminatory terms, any patent rights it obtains covering such technology to the extent necessary to comply with the standard. draft-pan-lsp-ping-00.txt ^L[Page 5] Internet Draft draft-pan-lsp-ping-00.txt July 2001 9. Acknowledgments This is the outcome of many causal discussions among many people, that also include Manoj Leelanivas, Paul Traina, Kireeti Kompella, Yakov Rekhter, Der-Hwa Gan and Brook Bailey. 10. References [ICMP] J. Postel, "Internet Control Message Protocol", RFC792. [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205. [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels" Internet Draft. [RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction Extensions", RFC2961. 11. Author Information Ping Pan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: pingpan@juniper.net phone: 408.745.3704 Nischal Sheth Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: nsheth@juniper.net phone: 408.745.2068 Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089 email: dcooper@gblx.net phone: 916.415.0437 draft-pan-lsp-ping-00.txt ^L[Page 6] Internet Draft draft-pan-lsp-ping-00.txt July 2001 draft-pan-lsp-ping-00.txt ^L[Page 7]