[rfc-dist] RFC 5063 on Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart

[rfc-editor at rfc-editor.org ([e-mail])]

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 at cisco.com, 
                    rrahman at 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 at IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info at 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 at 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 at RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...