RFC 4920

Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE, July 2007

Canonical URL:
https://www.rfc-editor.org/rfc/rfc4920.txt
File formats:
Plain TextPDF
Status:
PROPOSED STANDARD
Authors:
A. Farrel, Ed.
A. Satyanarayana
A. Iwata
N. Fujita
G. Ash
Stream:
IETF
Source:
ccamp (rtg)

Cite this RFC: TXT  |  XML

DOI:  10.17487/RFC4920

Discuss this RFC: Send questions or comments to ccamp@ietf.org

Other actions: View Errata  |  Submit Errata  |  Find IPR Disclosures from the IETF


Abstract

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 4844.


Download PDF Reader



Search RFCs
Advanced Search
×