draft-ietf-ccamp-rsvp-restart-ext-06.txt   draft-ietf-ccamp-rsvp-restart-ext-07.txt 
Network Working Group A. Satyanarayana, Ed. Network Working Group A. Satyanarayana, Ed.
Internet-Draft R. Rahman, Ed. Internet-Draft R. Rahman, Ed.
Updates: 2961, 3473 (if approved) Cisco Systems Updates: 2961, 3473 (if approved) Cisco Systems
Intended status: Standards Track December 2006 Intended status: Standards Track January 2007
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-06 draft-ietf-ccamp-rsvp-restart-ext-07
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 8, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract Abstract
This document describes extensions to the RSVP Graceful Restart This document describes extensions to the RSVP Graceful Restart
mechanisms defined in RFC 3473. The extensions enable the recovery mechanisms defined in RFC 3473. The extensions enable the recovery
of RSVP signaling state based on the Path message last sent by the of RSVP signaling state based on the Path message last sent by the
node being restarted. Previously defined Graceful Restart node being restarted.
mechanisms, also called recovery from nodal faults, permit recovery
of signaling state from adjacent nodes when the data plane has Previously defined Graceful Restart mechanisms, also called recovery
retained the associated forwarding state across a restart. These from nodal faults, permit recovery of signaling state from adjacent
mechanisms do not fully support signaling state recovery on ingress nodes when the data plane has retained the associated forwarding
nodes or recovery of all RSVP objects. The presented extensions use state across a restart. Those mechanisms do not fully support
the RSVP Hello extensions defined in RFC 3209, and extensions for signaling state recovery on ingress nodes or recovery of all RSVP
state recovery on nodal faults defined in RFC 3473. With the objects.
presented extensions the restarting node can recover all previously
transmitted Path state including the Explicit Route Object and the The extensions defined in this document build on the RSVP Hello
downstream (outgoing) interface identifiers. The extensions can also extensions defined in RFC 3209, and extensions for state recovery on
be used to recover signaling state after the restart of an ingress nodal faults defined in RFC 3473. Using these extensions the
node. The extensions optionally support the use of Summary Refresh, restarting node can recover all previously transmitted Path state
defined in RFC 2961, to reduce the number of messages exchanged including the Explicit Route Object and the downstream (outgoing)
during the Recovery Phase when the restarting node has recovered interface identifiers. The extensions can also be used to recover
signaling state locally for one or more LSPs. 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.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
4. Extensions to Nodal Fault Handling . . . . . . . . . . . 6 4. Extensions to Nodal Fault Handling . . . . . . . . . . . 6
4.1. RecoveryPath Message Format . . . . . . . . . . . . . . 6 4.1. RecoveryPath Message Format . . . . . . . . . . . . . . 6
4.2. Capability Object . . . . . . . . . . . . . . . . . . . 6 4.2. Capability Object . . . . . . . . . . . . . . . . . . . 6
4.2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.5.1. Procedures for the Downstream Neighbor . . . . . . . . . 9 4.5.1. Procedures for the Downstream Neighbor . . . . . . . . . 9
4.5.2. Procedures for the Restarting Node . . . . . . . . . . . 11 4.5.2. Procedures for the Restarting Node . . . . . . . . . . . 11
4.5.2.1. Path and RecoveryPath Message Procedures . . . . . . . . 11 4.5.2.1. Path and RecoveryPath Message Procedures . . . . . . . . 11
4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12 4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12
4.5.2.3. Procedures on Expiration of Recovery Period . . . . . . 13 4.5.2.3. Procedures on Expiration of Recovery Period . . . . . . 13
4.6. Compatibility . . . . . . . . . . . . . . . . . . . . . 13 4.6. Compatibility . . . . . . . . . . . . . . . . . . . . . 13
5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . 14 5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . 14
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . 15 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . 15
5.2. RecoveryPath Srefresh Capable bit . . . . . . . . . . . 16 5.2. RecoveryPath Srefresh Capable bit . . . . . . . . . . . 16
5.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . . 16
5.3. RecoveryPath Summary Refresh Procedures . . . . . . . . 17 5.3. RecoveryPath Summary Refresh Procedures . . . . . . . . 17
5.3.1. Generation of RecoveryPath-related Srefresh Messages . . 17 5.3.1. Generation of RecoveryPath-related Srefresh Messages . . 17
5.3.2. RecoveryPath-related Srefresh Receive Processing and 5.3.2. RecoveryPath-related Srefresh Receive Processing and
NACK Generation . . . . . . . . . . . . . . . . . . . . 19 NACK Generation . . . . . . . . . . . . . . . . . . . . 18
5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive
Processing . . . . . . . . . . . . . . . . . . . . . . . 19 Processing . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . 21
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
skipping to change at page 20, line 36 skipping to change at page 20, line 12
node carrying one or more LSPs is restarted due to external attacks, node carrying one or more LSPs is restarted due to external attacks,
the procedures introduced in this document provide the ability for the procedures introduced in this document provide the ability for
the restarting RSVP agent to recover the RSVP state corresponding to the restarting RSVP agent to recover the RSVP state corresponding to
the LSPs with the least possible perturbation to the rest of the the LSPs with the least possible perturbation to the rest of the
network. Ideally, only the neighboring RSVP agents should notice the network. Ideally, only the neighboring RSVP agents should notice the
restart and hence need to perform additional processing. This allows restart and hence need to perform additional processing. This allows
for a network with active LSPs to recover LSP state gracefully from for a network with active LSPs to recover LSP state gracefully from
an external attack, without perturbing the data/forwarding plane an external attack, without perturbing the data/forwarding plane
state. state.
[RFC2747] provides mechanisms to protect against external agents from [RFC2747] provides mechanisms to protect against external agents
compromising the RSVP signaling state in an RSVP agent. These compromising the RSVP signaling state in an RSVP agent. These
mechanisms, when used with the new message and procedures introduced mechanisms, when used with the new message and procedures introduced
in this document, provide the same degree of protection to the in this document, provide the same degree of protection to the
restarting RSVP agent, against installing compromised signaling state restarting RSVP agent, against installing compromised signaling state
from an external agent during its RSVP signaling state recovery. from an external agent during its RSVP signaling state recovery.
Note that the procedures assume a full trust model between RSVP
neighbors. That is, although the protocol exchanges before and after
restart can be secured, and although it is possible to authenticate
the identity of the neighbors, no mechanism is provided to verify
that the restart information is correctly mapped from the protocol
information exchanged before the restart. This is considered
acceptable because a similar trust model is required for normal
operation of the protocol.
The procedures defined in this document introduce additional The procedures defined in this document introduce additional
processing overhead for the RSVP agents that neighbor a restarting processing overhead for the RSVP agents that neighbor a restarting
RSVP agent. If an RSVP agent restarts due to external attacks, such RSVP agent. If an RSVP agent restarts due to external attacks, such
added processing on the neighboring RSVP agents may impact their added processing on the neighboring RSVP agents may impact their
ability to perform other control plane tasks including any processing ability to perform other control plane tasks including any processing
for other LSPs that do not involve the restarting node. Such impact for other LSPs that do not involve the restarting node. Such impact
can be minimalized by the restarting RSVP agent using a large enough can be minimalized by the restarting RSVP agent using a large enough
Recovery Time, so that its neighbors are provided sufficient time to Recovery Time, so that its neighbors are provided sufficient time to
handle the additional processing involved while continuing to perform handle the additional processing involved while continuing to perform
their other control plane functions normally during the Recovery their other control plane functions normally during the Recovery
Period. Period.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank participants of the CCAMP WG for The authors would like to thank participants of the CCAMP WG for
comments and suggestions. Also thanks to Arthi Ayyangar, Adrian comments and suggestions. Also thanks to Arthi Ayyangar, Adrian
Farrel, Nick Neate and Pavan Beeram for their helpful comments and Farrel, Nick Neate and Pavan Beeram for their helpful comments and
feedback. feedback.
Derek Atkins provided useful discussion during SecDir review.
8. IANA Considerations 8. IANA Considerations
[RFC2205] defines the Class-Number name space for RSVP objects. The [RFC2205] defines the Class-Number name space for RSVP objects. The
name space is managed by IANA. name space is managed by IANA.
A new RSVP object using a Class-Number of form 10bbbbbb called the A new RSVP object using a Class-Number of form 10bbbbbb called the
Capability Object is defined in Section 4.2 in this document. The Capability Object is defined in Section 4.2 in this document. The
Class-Number is TBA by IANA. A value of 132 is suggested. Class-Number is TBA by IANA. A value of 132 is suggested.
A new RSVP message type called a RecoveryPath message is defined in A new RSVP message type called a RecoveryPath message is defined in
skipping to change at page 23, line 4 skipping to change at page 22, line 40
EMail: asatyana@cisco.com EMail: asatyana@cisco.com
Reshad Rahman (editor) Reshad Rahman (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3519 Phone: 613 254-3519
EMail: rrahman@cisco.com EMail: rrahman@cisco.com
Lou Berger
LabN Consulting, L.L.C.
Phone: +1 301 468-9228
EMail: lberger@labn.net
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Lou Berger
LabN Consulting, L.L.C.
Phone: +1 301 468-9228
EMail: lberger@labn.net
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3484 Phone: 613 254-3484
EMail: ancaz@cisco.com EMail: ancaz@cisco.com
skipping to change at page 24, line 7 skipping to change at page 23, line 30
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3693 Phone: 613 254-3693
EMail: jisrar@cisco.com EMail: jisrar@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 14 change blocks. 
36 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/