Network Working Group Arun Satyanarayana (Movaz Networks)
Internet Draft Lou Berger (Movaz Networks)
Expiration Date: August 2004 Dimitri Papadimitriou (Alcatel)
February 2004
Extensions to GMPLS RSVP Graceful Restart
draft-aruns-ccamp-rsvp-restart-ext-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
This document describes extensions to the RSVP Graceful Restart
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 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
recovery of 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.
Satyanarayana, et al. [Page 1]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
Contents
1 Introduction ................................................ 3
2 Extensions to Nodal Fault Handling .......................... 4
2.1 RecoveryPath Message Format ................................. 4
2.2 Related Procedures .......................................... 5
2.3 Procedures For The Downstream Neighbor ...................... 5
2.4 Procedures for the Restarting Node .......................... 6
3 Compatibility notes ......................................... 9
4 Security Considerations ..................................... 9
5 IANA Considerations ......................................... 9
6 References .................................................. 9
6.1 Normative References ........................................ 9
7 Authors' Addresses .......................................... 10
8 Full Copyright Statement .................................... 10
Satyanarayana, et al. [Page 2]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction
RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms
defined in [RFC3209]. [RFC3209] describes a mechanism, using RSVP
Hello messages, to detect the state of an adjacent RSVP signaling
process. [RFC3473] extends this mechanism to advertise the
capability of retaining data plane state across the restart of a node
or a "nodal fault". [RFC3473] also defines the Recovery Label object
for use in the Path message of the RSVP neighbor upstream of a
restarting node, to indicate that the Path message is for existing
data plane state.
This document presents extensions to address two aspects of graceful
restart not previously supported. The presented extensions enable
the recovery of an ERO previously transmitted by a restarting node,
from its downstream neighbor. The extensions also enable graceful
restart of an ingress node that does not preserve full control plane
state across restarts.
Per [RFC3473], a restarting node can distinguish Path messages
associated with LSPs being recovered by the presence of the Recovery
Label object. To determine the downstream (outgoing) interface, the
restarting node must consult the data plane. This may not be
possible for all types of nodes. Furthermore, data plane information
is not sufficient to reconstruct EROs in many cases. The restarting
node may have previously performed some form of path computation on
the received ERO, such as ERO expansion to a loose next hop or a
partial path computation up to the Egress node if an ERO was not
received. If the restarting node is an ingress node, it may have
performed a full path computation as part of the LSP setup process.
The restarting node has to recover the ERO it had sent in its Path
message prior to the restart, so that it can continue to include the
same ERO in its Path messages after the restart. If the restarting
node is an ingress node, the only source of RSVP state is the
downstream RSVP neighbor.
The defined extensions provide a restarting upstream node with
information previously transmitted by the node in Path messages.
This is accomplished by the downstream RSVP neighbor, after
reestablishing RSVP communication with the restarted node, sending a
new message for every Path message it has previously received from
Satyanarayana, et al. [Page 3]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
the restarting node.
The new message is called the RecoveryPath message. The message
conveys the contents of the last received Path message back to the
restarting node. The restarting node can use the RecoveryPath
message along with the state in the received Path message to
associate control and data plane state and to validate the forwarding
state with the state presented by the neighboring RSVP nodes.
If the restarting node is a transit node for an LSP being recovered,
it will receive a Path message with a Recovery Label object from its
upstream RSVP neighbor. Additionally, the RecoveryPath message
allows such transit nodes to reconstruct any state that was
previously dynamically constructed by the node, e.g., ERO sub-
objects. If the restarting node is an ingress node, all significant
signaling state can be recovered based on the RecoveryPath message.
Restarting egress nodes, and Resv message processing are not impacted
by the presented extensions, see [RFC3473] for details.
2. Extensions to Nodal Fault Handling
This section presents the protocol modifications to Section 9 of
[RFC3473].
2.1. RecoveryPath Message Format
The format of a RecoveryPath message is the same as the format of a
Path message as defined in [RFC3473]:
<RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath
message MUST be the same as the destination address used in the IP
header of the corresponding Resv message last sent by the sending
node. Except as specified below all objects in a RecoveryPath
message are identical to the objects in the corresponding Path
message last received by the sending node.
Satyanarayana, et al. [Page 4]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
2.2. Related Procedures
This document does not modify existing procedures for sending and
receiving RSVP Hello messages as defined in [RFC3209] and the
Restart_Caps object in the RSVP Hello messages as defined in
[RFC3473]. The procedures for control channel faults are defined in
[RFC3473] and are not changed by this document.
The presented extensions requires the use of RSVP Hellos as defined
in [RFC3209] and the use of the Restart_Caps object extension as
defined in [RFC3473]. The presented extensions addresses only "Nodal
Faults" as defined in [RFC3473]. Control channel faults are fully
addressed in [RFC3473].
Note: There are no changes to the procedures defined in Section 9.5.3
in [RFC3473] (Procedures for the Neighbor of a Restarting node).
There are no changes to the procedures defined in Section 9.5.2 in
[RFC3473] if the restarting node is an egress node.
The following sections assume previously defined procedures are
followed, except where explicitly modified.
2.3. Procedures For The Downstream Neighbor
After a downstream RSVP neighbor has detected that its upstream node
has restarted and is capable of recovery, as defined in [RFC3473],
the downstream RSVP neighbor MUST send a RecoveryPath message for
each LSP associated with the restarting node for which it has sent a
Resv message.
The RecoveryPath message is constructed by copying all objects from
the last received associated Path message, with the following
exceptions:
The Message ID object is not copied. Any Message ID objects used
in RecoveryPath messages are generated based on procedures defined
in [RFC2961].
The Integrity object is not copied. Any Integrity objects used in
RecoveryPath messages are generated based on procedures defined in
[RFC2747].
The RSVP Hop object is copied from the most recent associated Resv
message sent to the restarted node, for the LSP being recovered.
In the sender descriptor, the Recovery Label object MUST be
included, with the label value copied from the label value in the
Satyanarayana, et al. [Page 5]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
Label object in the most recent associated Resv message sent to
the restarted node, for the LSP being recovered.
All other objects from the most recent received Path message MUST be
included in the RecoveryPath message.
After sending a RecoveryPath message and during the Recovery Period,
the node SHOULD periodically re-send the RecoveryPath message until
it receives a corresponding response. A corresponding response is a
Message ID acknowledgment or a Path message matching the RecoveryPath
message. Note, per [RFC3473], Resv messages are suppressed during
this recovery period until a corresponding Path message is received.
2.4. Procedures for the Restarting Node
These procedures apply during the "state recovery process" and
"Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any
RecoveryPath message received after the Recovery Period has expired
MUST be discarded. A node MAY send a PathTear message downstream
matching the discarded message.
The remaining procedures are broken down into three sub-sections.
The term "resynchronized state" originally defined in [RFC3473] is
used and modified in these sections. This term refers to LSP state
that is fully recovered.
Signaling state may be recovered from sources other than the
mechanisms defined in this document. The ingress node SHOULD consider
signaling state as resynchronized for all such LSPs and follow
corresponding procedures defined below. Further, recovery procedures
defined below may be overridden by local policy.
Again, there are no changes to the procedures defined in Section
9.5.2 in [RFC3473] if the restarting node is an egress node.
2.4.1. Path and RecoveryPath Message Processing Related Procedures
When a node receives a RecoveryPath message during the Recovery
Period, the node first checks if it has resynchronized RSVP state
associated with the message. If there is resynchronized state, and a
Message ID object is present in the RecoveryPath message, the node
MUST follow Message ID acknowledgement procedures as defined in
[RFC2961], and, consider the message as processed. If there is
resynchronized state and there is no Message ID object, the node MAY
send a triggered Path message, and, consider the message as
processed.
Satyanarayana, et al. [Page 6]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
If non-resynchronized state is found or the node is the ingress, the
node saves the information contained in the RecoveryPath message and
continues with processing as defined in the next section.
If no associated RSVP state is found and the node is not the ingress
node, the node saves the information contained in the RecoveryPath
message for later use.
Note the following modifies Section 9.5.2 of [RFC3473]:
When a node receives a Path message during the Recovery Period, the
node first checks if it has an RSVP state associated with the
message. If resynchronized RSVP state is found, then the node
handles this message according to previously defined procedures.
If non-resynchronized state is found, the node saves the information
contained in Recovery_Label object and continues with processing as
defined in the next section.
Per [RFC3473], if the RSVP state is not found, and the message does
not carry a Recovery_Label object, the node treats this as a setup
for a new LSP, and handles it according to previously defined
procedures.
If the RSVP state is not found, and the message carries a
Recovery_Label object, the node saves the information contained in
the Recovery_Label object for later use.
2.4.2. Re-Synchronization Procedures
After receipt of the RecoveryPath message and, for non-ingress LSPs,
the corresponding Path message with a Recovery Label object, the
restarting node SHOULD locate and associate corresponding forwarding
state using the received information. The restarting node associates
the corresponding active forwarding plane state from the following
signaled information:
The upstream data interface is recovered from the received RSVP
HOP object in the Path message.
The label on the upstream data interface is recovered from the
Recovery Label object in the received Path message. If the LSP is
bidirectional, the label for the reverse direction is recovered
from the Upstream Label object in the received Path message.
The downstream data interface is recovered from the RSVP HOP
object in the received RecoveryPath message.
Satyanarayana, et al. [Page 7]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
The label on the downstream data interface is recovered from the
Recovery Label object in the received RecoveryPath message. If
the LSP is bidirectional, the label for the reverse direction is
recovered from the Upstream Label object in the RecoveryPath
message.
If complete forwarding state is located, the restarted node MUST
treat the LSP as resynchronized and MUST send a triggered Path
message downstream. The Explicit Route object in the Path message
SHOULD match the Explicit Route object received RecoveryPath message.
In addition, a node SHOULD recover state from the other objects
received in the RecoveryPath message. The optimal result is for the
resulting Path message to not cause any redundant or unnecessary re-
processing of state along the remaining downstream nodes. Ideally,
except for Message Id processing and recovery processing, the
transmitted Path message will be treated as a refresh by the
downstream RSVP neighbor (and hence should not trigger any generation
of Path messages with changed state further downstream).
If no forwarding state is located, the node treats the path message
as a setup for a new LSP. The outgoing interface and label(s)
indicated in the RecoveryPath message SHOULD be reused, when
possible. All other information contained in the RecoveryPath
message MAY also be used.
2.4.3. Procedures on Expiration of Recovery Period
There are several cleanup steps to follow at the end of the Recovery
Period. At the end of the Recovery Period, any state that was
installed as a resulted of a received RecoveryPath message and is not
resynchronized SHOULD be discarded.
Any received Path messages that were received containing a
Recovery_Label have not been resynchronized, SHOULD be treated as
being received during the Recovery Period and processed as per
[RFC3473].
Per [RFC3473], any other state that is not resynchronized during the
Recovery Period SHOULD be removed at the end of the Period.
Satyanarayana, et al. [Page 8]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
3. Compatibility notes
This document introduces a new RSVP signaling message to be generated
by the downstream RSVP neighbor of a restarting node.
If the restarting node does not support the RecoveryPath message and
associated procedures, it will discard all received RecoveryPath
messages, and revert to recovery processing as defined in [RFC3473].
If the downstream RSVP neighbor does not support the RecoveryPath
message and associated procedures, the restarting node processes
received Path messages as defined above, which essentially reverts
to the processing defined in [RFC3473].
4. Security Considerations
This document introduces a new RSVP message that is restricted to one
RSVP hop. This document introduces no new security considerations
beyond those already addressed for existing RSVP hop-by-hop messages.
5. IANA Considerations
A new RSVP message type is defined in this document. The RSVP
message type is TBA by IANA.
6. References
6.1. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification",
RFC 2205, Braden, et al, September 1997.
[RFC2747] "RSVP Cryptographic Authentication",
RFC 2747, F. Baker, et al, January 2000.
[RFC2961] "RSVP Refresh Overhead Reduction Extensions",
RFC 2961, L. Berger, et al, April 2001.
Satyanarayana, et al. [Page 9]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001.
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description",
RFC 3471, L. Berger, et al, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions",
RFC 3473, L. Berger, et al, January 2003.
7. Authors' Addresses
Arun Satyanarayana
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Email: aruns@movaz.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
Email: lberger@movaz.com
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
8. Full Copyright Statement
Copyright (c) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
Satyanarayana, et al. [Page 10]
Internet Draft draft-aruns-ccamp-rsvp-restart-ext-00.txt February 2004
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Satyanarayana, et al. [Page 11]