%% You should probably cite rfc4920 instead of this I-D.
@techreport{ietf-ccamp-crankback-06,
    number =    {draft-ietf-ccamp-crankback-06},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-ccamp-crankback/06/},
    author =    {Adrian Farrel and Gerald Ash and Arun Satyanarayana and Norihito Fujita and Atsushi Iwata},
    title =     {{Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE}},
    pagetotal = 38,
    year =      2007,
    month =     jan,
    day =       18,
    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{]}},
}