Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, ccamp mailing list <email@example.com>, ccamp chair <firstname.lastname@example.org> Subject: Protocol Action: 'Extensions to GMPLS RSVP Graceful Restart' to Proposed Standard The IESG has approved the following document: - 'Extensions to GMPLS RSVP Graceful Restart ' <draft-ietf-ccamp-rsvp-restart-ext-10.txt> as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-10.txt
Technical Summary This document describes extensions to the 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. 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 LSPs. Working Group Summary no dissent reported (see PROTO writeup by Adrian Farrel) Protocol Quality Ross Callon reviewed this for the IESG. There are implementations and it is reported that there is some deployment by "optical vendors" (presumably optical switches).