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]