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]