One document matched: draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
CCAMP Working Group
Internet Draft Zafar Ali
Danny Prairie
Reshad Rahman
Cisco Systems, Inc.
Expires: August 2004 February 2004
Administrative Control of RSVP Hello and Graceful Restart Procedure
draft-ali-ccamp-rsvp-hello-gr-admin-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 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Ability to administratively shutdown RSVP Hellos and Graceful Restart
(GR) procedure without impacting the traffic is a desirable network
operation. Furthermore, there are applications that run RSVP Hellos
with intervals on the order of milliseconds. This poses a requirement
to reduce the number of RSVP messages to a minimal required count.
Fortunately RSVP Hellos are not mandatory and are only required to
run when needed. This allows applications to remove an RSVP Hello
session, when it is not needed. This ID proposes a procedure to
remove RSVP Hello and/ or GR sessions for administrative or
optimization purposes.
Conventions used in this document
Z. Ali, et al.
[Page 1]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
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].
Routing WG ID Summary
(This section to be removed before publication.)
SUMMARY
This draft proposes procedures to gracefully remove RSVP Hello
and/ or GR sessions. The procedures specified in this document are
OPTIONAL.
WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING WG WORK?
This work fits in the context of [RFC 3209] and [RFC 3473].
WHY IS IT TARGETED AT THIS WG?
This draft is targeted at CCAMP WG, because it addresses
procedures related to RSVP-TE Hello and GR protocols define in [RFC
3209] and [RFC 3473], respectively.
RELATED REFERENCES
Please refer to the reference section.
Table of Contents
1. Terminology....................................................2
2. Introduction...................................................3
3. Signaling Graceful Removal of RSVP Hello Session...............3
3.1 Procedure at the Initiating:...............................5
3.2 Procedure at the Neighbor of the Initiating Node:..........5
4. Signaling Graceful Removal of RSVP GR Session..................6
4.1 Procedure at the Initiating Node:..........................6
4.2 Procedure at the Neighbor of the Initiating Node:..........6
5. Backward Compatibility Note....................................6
6. Security Considerations........................................7
7. Acknowledgements...............................................7
1. Terminology
RSVP GR - Graceful Restart procedure for RSVP as specified in
[RFC3473].
Z. Ali, et al. Page 2 2/6/2004
[Page 2]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
RSVP Hello û RSVP Hello protocol as defined in [RFC3209]. Terms RSVP
Hello and Hello are used interchangeably in the document.
Hello messages: This term is applied collectively to refer to RSVP
Hello Request or Hello Ack message.
RSVP GR Session: This term refers to an RSVP Hello session where
Hello messages also contain Restart_Cap Object, as defined in
[RFC3473].
2. Introduction
Administrative control of RSVP Hellos and GR procedures is a
desirable network operation. Furthermore, RSVP Hellos are periodic in
nature. The frequency of RSVP Hello messaging depends on the failure
detection requirements. There are applications that run RSVP Hellos
with intervals on the order of milliseconds. This poses a requirement
for gracefully deleting RSVP Hello sessions when they are no longer
needed.
Presently, the specifications do not provide a procedure to signal
the intent to administratively shutdown or remove RSVP Hello
sessions. The only way to get around this limitation is to continue
to run Hellos even after applications have no use of them, which is
undesirable. Presently, the administrative shutdown of RSVP Hello or
GR sessions may cause traffic disruption for LSPs that depend on the
health of the Hello session. Specifically, if an FRR application
utilizes RSVP Hellos, removing Hellos triggers FRR for LSPs relying
on the health of the Hello session. Similarly, in the case of RSVP
graceful restart, if a node disabled Hellos, a neighbor with RSVP GR
Hello session will, after the Hello timeout has occurred, teardown
the corresponding LSPs.
The above mentioned administrative and resource reasons induce a need
to formalize removal of RSVP Hellos and GR sessions. This draft
proposes a solution that can be used to gracefully remove an RSVP
Hello session. We also clarify the significance of the absence of a
graceful restart object in a Hello message as a means for disabling
RSVP GR without removing RSVP Hellos. Both procedures are optional
and rely completely on existing RSVP objects.
3. Signaling Graceful Removal of RSVP Hello Session
This section outlines procedure that MUST be followed, for compliance
with this draft, if a node wishes to remove an RSVP Hello session. A
node may like to remove RSVP Hello session as it is no longer needed
Z. Ali, et al. Page 3 2/6/2004
[Page 3]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
or for administrative reasons. Furthermore, when a node initiates
removal of RSVP Hello session, its intent to remove application using
the RSVP Hello is implied.
The Admin_Status Object as defined in [RFC3471] and [RFC3473] is
overloaded by this proposal for the purpose of signaling removal of
RSVP Hello procedures. Specifically, in [RFC3473], the Admin_Status
object indicates the state of the RSVP-TE signaled LSP. In this
draft, we specify the use of the Admin_Status Object when it is
carried in the RSVP Hello Request or the RSVP Hello Ack message.
The use of Admin_Status Object in RSVP Hello messages is optional. It
uses Class-Number 196 (of form 11bbbbbb) and is defined as follows in
[RFC3471], [RFC3473].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and [RFC3473] for
usage of these parameters when carried to signal the state of an
RSVP-TE LSP. In the following we specify the use of these bits when
the Admin_Status Object is carried in the RSVP Hello Request or Hello
Ack message.
Reflect (Hello.Admin_Status.R) bit: When the Admin_Status
object is carried in Hello Request or Hello Ack messages, the
reflect bit is not used and MUST be set to 0 in transmission
and MUST be ignored on receipt.
Reserved bits: When the Admin_Status object is carried in Hello
Request or Hello Ack messages, the reserve bits MUST be set to
zero on transmission and MUST be ignored on receipt.
Test (Hello.Admin_Status.T) bit: When the Admin_Status object
is carried in Hello Request or Hello Ack messages, the Test bit
is not used and MUST be set to 0 in transmission and MUST be
ignored on receipt.
Administratively_down (Hello.Admin_Status.A) bit: In the case
of RSVP Hellos, administratively_down event also results in
deletion of RSVP Hello session. Therefore, for the sake of
simplicity, administratively_down event are also signaled using
Z. Ali, et al. Page 4 2/6/2004
[Page 4]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
the ôDeletion in progressö bit, as described in the following.
In other words, when the Admin_Status object is carried in
Hello Request or Hello Ack messages, the administratively_down
bit is not used and MUST be set to 0 in transmission and MUST
be ignored on the receipt.
Deletion in progress (Hello.Admin_Status.D) bit: When the
Admin_Status object is carried in Hello Request or Hello Ack
messages and deletion in progress bit is set, it indicates that
the sender node is deleting an RSVP Hello session; otherwise,
this bit MUST be set to 0 or the Admin_Status object MUST be
omitted.
Usage of the Admin_status object when carried in RSVP Hello messages
is detailed further in the following sections, where the method of
deleting RSVP Hellos is described. As detailed in the following, the
Admin_status object is inserted in Hello messages (Hello Request or
Hello Ack) on an as needed basis. In particular, the absence of the
object is equivalent with having the object with all bits/ flags set
to 0.
3.1 Procedure at the Initiating:
When a node desires to delete an RSVP Hello session, it begins
inserting the Admin_status object, with the Hello.Admin Status.D bit
set to 1, in RSVP Hello messages. As mentioned earlier, Hello
messages may be classified as either a Hello Ack or a Hello Request,
depending on the role of the node in the Hello protocol [RFC3209].
If the neighborÆs restart time is known, a node wishing to disable
RSVP GR transmits Hello messages with the Hello.Admin_Status.D bit
set to 1 for a period of time equal to (Hello dead interval +
neighborÆs restart time); otherwise the node transmits Hello messages
with the Hello.Admin_Status.D bit set to 1 for a period equal to
(Hello dead interval). After sending Hello messages with the
Hello.Admin_Status.D bit set to 1 for the above-mentioned interval,
the node stops sending Hello messages. If during the time of deleting
Hello session, or at a later time Hellos are needed again, the node
starts sending Hello messages without the Admin_status object.
While RSVP GR procedures are in progress with a given node, the said
nodes involved MUST NOT initiate the admin status change for Hello
sessions during the restart and recovery periods.
3.2 Procedure at the Neighbor of the Initiating Node:
Z. Ali, et al. Page 5 2/6/2004
[Page 5]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
When a node receives a Hello message with the Hello.Admin_Status.D
bit set to 1, it assumes that the neighbor is removing the Hello
session in question. Once the node stops receiving Hello messages
with Hello.Admin_Status.D bit set to 1, it MAY also stop sending
Hellos messages for the Hello session in question.
4. Signaling Graceful Removal of RSVP GR Session
The following procedure is applicable when a node wishes to signal
that it no longer participating in the RSVP GR procedure, without
removing RSVP Hellos. As mentioned earlier, when a node wishes to
remove RSVP Hellos, its intent to remove RSVP GR session is implied.
The procedure specified in this section may be considered to be a
clarification statement to [RFC3473]. Specifically, we formalize the
absence of Restart_Cap objects in the Hello message as an indication
that the node is no longer participating in the RSVP GR procedure.
4.1 Procedure at the Initiating Node:
When a node wishes to withdraw itself from the GR session, it removes
Restart_Cap objects from ALL Hello sessions that the node shares with
a given neighbor. Note that this does not preclude disabling GR
procedures with multiple neighbouring nodes. The node continues to
send Hello message without the Restart_Cap object as long as GR is
disabled.
A node cannot initiate an admin status change for a Hello session
during the recovery and restart periods.
When GR is re-enabled, the node simply starts including the
RESTART_CAP object in all Hello messages exchanged with a given
neighbor, as defined in [RFC 3473].
4.2 Procedure at the Neighbor of the Initiating Node:
When a node receives a Hello message without the Restart_Cap object,
it assumes that the neighbor has disabled GR procedures. If a Hello
session fails after the neighbor has disabled GR procedures, the node
does not trigger GR procedures with the neighbor.
The non-initiating node continues to send Hello messages with the
RESTART_CAP object. It can only remove the RESTART_CAP object when
RSVP GR is disabled locally.
5. Backward Compatibility Note
Z. Ali, et al. Page 6 2/6/2004
[Page 6]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
The procedures presented in this draft are backwards compatible with
both [RFC3209] and [RFC3473]. Furthermore, since no new object is
introduced and the Admin_Status object is of type 11bbbbbb, there are
no backward compatibility issues.
6. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant.
7. Acknowledgements
We would like to thank Anca Zamfir, Jean-Louis Le Roux and Carol
Iturralde for their useful comments and suggestions.
References
[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 3471, L. Berger, et al, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
Author's Addresses
Zafar Ali
Cisco Systems Inc.
100 South Main St. #200
Ann Arbor, MI 48104, USA.
Phone: (734) 276-2459
Email: zali@cisco.com
Danny Prairie
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada.
Phone: (613)-254-3519
Email: dprairie@cisco.com
Reshad Rahman
Cisco Systems Inc.
Z. Ali, et al. Page 7 2/6/2004
[Page 7]
draft-ali-ccamp-rsvp-hello-gr-admin-00.txt February 2004
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada.
Phone: (613)-254-3519
Email: rrahman@cisco.com
Z. Ali, et al. Page 8 2/6/2004
[Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 05:47:58 |