File formats:

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  |   BibTeX

DOI:  https://doi.org/10.17487/RFC4920

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

Other actions: View Errata  |  Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 4920

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 8729.