Extensions to GMPLS RSVP Graceful Restart
draft-aruns-ccamp-rsvp-restart-ext-01

 
Document
Type Replaced Internet-Draft (individual)
Last updated 2008-04-16 (latest revision 2004-07-20)
Replaced by draft-ietf-ccamp-rsvp-restart-ext
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html
Stream
Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG
IESG state Replaced by draft-ietf-ccamp-rsvp-restart-ext
Telechat date
Responsible AD (None)
Send notices to (None)

Email authors IPR References Referenced by Nits Search lists

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-aruns-ccamp-rsvp-restart-ext-01.txt

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.

Authors

Arun Satyanarayana (aruns@movaz.com)
Lou Berger (lberger@labn.net)
Reshad Rahman (rrahman@cisco.com)
Dimitri Papadimitriou (dimitri.papadimitriou@alcatel.be)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)