%% You should probably cite draft-ietf-ccamp-rsvp-restart-ext instead of this I-D.
@techreport{aruns-ccamp-rsvp-restart-ext-01,
    number =    {draft-aruns-ccamp-rsvp-restart-ext-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-aruns-ccamp-rsvp-restart-ext/01/},
    author =    {Arun Satyanarayana and Lou Berger and Reshad Rahman and Dimitri Papadimitriou},
    title =     {{Extensions to GMPLS RSVP Graceful Restart}},
    pagetotal = 20,
    year =      2004,
    month =     jul,
    day =       20,
    abstract =  {This document describes extensions to the RSVP Graceful Restart mechanisms defined in {[}RFC3473{]}. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in {[}RFC3209{]}, and extensions for state recovery on nodal faults defined in {[}RFC3473{]}. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in {[}RFC2961{]}, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's.},
}