Skip to main content

Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
RFC 4920

Revision differences

Document history

Date By Action
2020-01-21
(System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
(System)
Received changes through RFC Editor sync (changed abstract to 'In a distributed, constraint-based routing environment, the information used to compute a path may be out …
Received changes through RFC Editor sync (changed abstract to '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]')
2015-10-14
(System) Notify list changed from ccamp-chairs@ietf.org to (None)
2007-07-16
Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-07-16
Amy Vezza [Note]: 'RFC 4920' added by Amy Vezza
2007-07-14
(System) RFC published