Search RFCs

RFC Editor

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 listccamp@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, theinformation used to compute a path may be out of date. This meansthat Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setuprequests may be blocked by links or nodes without sufficientresources. Crankback is a scheme whereby setup failure information isreturned from the point of failure to allow new setup attempts to bemade avoiding the blocked resources. Crankback can also be applied toLSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use in MPLSsignaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP forLSP Tunnels", RFC 3209, and GMPLS signaling as defined in "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling FunctionalDescription", RFC 3473. These extensions mean that the LSP setuprequest can be retried on an alternate path that detours aroundblocked links or nodes. This offers significant improvementsin the successful setup and recovery ratios for LSPs, especially insituations where a large number of setup requests are triggered at thesame time. [STANDARDS-TRACK]

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.