datatracker.ietf.org
Sign in
Version 5.13.0, 2015-03-25
Report a bug

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

Document type: Replaced Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2008-04-16 (latest revision 2004-07-20)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Replaced by draft-ietf-ccamp-rsvp-restart-ext
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:
http://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)