A new Request for Comments is now available in online RFC libraries.
RFC 5063
Title: Extensions to GMPLS Resource Reservation
Protocol (RSVP) Graceful Restart
Author: A. Satyanarayana, Ed.,
R. Rahman, Ed.
Status: Standards Track
Date: October 2007
Mailbox: asatyana@cisco.com,
rrahman@cisco.com
Pages: 24
Characters: 58542
Updates: RFC2961, RFC3473
See-Also:
I-D Tag: draft-ietf-ccamp-rsvp-restart-ext-09.txt
URL: http://www.rfc-editor.org/rfc/rfc5063.txt
This document describes extensions to the Resource Reservation
Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. 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. Those mechanisms do not fully support
signaling state recovery on ingress nodes or recovery of all RSVP
objects.
The extensions defined in this document build on the RSVP Hello
extensions defined in RFC 3209, and extensions for state recovery on
nodal faults defined in RFC 3473. Using these extensions, the
restarting node can recover all previously transmitted Path state,
including the Explicit Route Object and the downstream (outgoing)
interface identifiers. The extensions can also be used to recover
signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined
in RFC 2961, to reduce the number of messages exchanged during the
Recovery Phase when the restarting node has recovered signaling state
locally for one or more Label Switched Paths (LSPs). [STANDARDS TRACK]
This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.
This is now a Proposed Standard Protocol.
STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
The RFC Editor Team
USC/Information Sciences Institute
...
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
