[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/