Network Working Group George Swallow Internet Draft Cisco Systems, Inc. Expiration Date: April 2000 October 1999 RSVP Hierarchical Summary Refresh draft-swallow-rsvp-hierarchical-refresh-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." 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. 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 Summary refresh techniques for RSVP are described in draft-ietf- rsvp-refresh-reduct-00.txt. This document extends the summary refresh technique by allowing hierarchical summary refreshes. Essentially, the summary refresh messages themselves may be refreshed using another summary refresh message. Swallow [Page 1] Internet Draftraft-swallow-rsvp-hierarchical-refresh-00.txt October 1999 Contents 1 Introduction ........................................... 3 2 Background ............................................. 3 3 Hierarchical summary refresh procedures ................ 4 4 Modified Srefresh message format ....................... 5 5 Acknowledgments ........................................ 5 6 Security Considerations ................................ 5 7 References ............................................. 5 8 Author's Address ....................................... 6 Swallow [Page 2] Internet Draftraft-swallow-rsvp-hierarchical-refresh-00.txt October 1999 1. Introduction Draft-ietf-rsvp-refresh-reduct-00.txt [Berger] describes a number of mechanisms to reduce the refresh load for RSVP [RFC2205]. In particular it describes a summary refresh mechanism. The summary refresh message allow a number of RSVP messages to be refreshed by including message IDs in a single refresh message. This document extends the summary refresh technique by allowing hierarchical summary refreshes. Essentially, the summary refresh messages themselves may be refreshed using another summary refresh message. The intent of this draft is to have these techniques added to draft- ietf-rsvp-refresh-reduct. 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 [RFC2119]. 2. Background A means of hierarchical refresh for RSVP was proposed in draft-wang- rsvp-state-compression-02.txt [WTZ]. The means in that draft was to compress the protocol state information so that the number of refresh messages is greatly reduced. Concerns were raised about implementation difficulties with that draft. That mechanism depends on MD-5 hashes being consistently computed by the sending and receiving nodes. This would in turn mandate that the RSVP state in those nodes be kept in identical formats. Internal data formats are normally beyond the scope of a protocol specification. This draft proposes a simpler mechanism which largely achieves the same effect. Here the hierarchy is achieved by simple extensions to the use of message IDs and summary refresh messages. In this proposal, message Ids may be carried in Srefresh messages and acknowledgments may be requested. Once an Srefresh message is acknowledged, it may then be refreshed by sending its message ID in another Srefresh message. When an Srefresh message is refreshed it is simply processed again as if it had just been received. With this method, a two level hierarchy could refresh more than 90,000 messages if the MTU were as small as 1500 bytes. The one feature of the previous proposal not covered by this proposal is detection and correction of memory corruption. Operational experience with BGP and other protocols has shown this to be a non- Swallow [Page 3] Internet Draftraft-swallow-rsvp-hierarchical-refresh-00.txt October 1999 issue. 3. Hierarchical summary refresh procedures Srefresh messages themselves may carry a MESSAGE_ID with the ack request bit set. Normally, Srefresh messages are processed and flushed. If, however, the Srefresh message contained a MESSAGE_ID with the ack request bit, the message is stored and reprocessed as it itself is refreshed. The reprocessing rate of the refreshed message need not be as fast as the refresh rate provided that this does not change the timeout behavior of the messages which it is refreshing. An exaple is described at the end of this section. On the sender side, a MESSAGE_ID with the ack request bit set may be included in an Srefresh message. A TIME_VALUES object may be included to set the timeout interval. Once that message has been acked, that MESSAGE_ID may be included in another Srefresh message and further transmission the first Srefresh suppressed. If the contents of the original Srefresh message changes in anyway, then the message MUST be resent. If the retransmitted message contains a MESSAGE_ID, the MESSAGE_ID MUST be higher than the previous MESSAGE_ID. When an Srefresh message which carries its own MESSAGE_ID with the ack request bit set is received, it is processed as normal. Additionally the MESSAGE_ID MUST be acked and the message saved until it times out. If second Srefresh message arrives which refreshes the MESSAGE_ID of the first message, then the first Srefresh message is reprocessed as if it were just received and its timeout interval is reset. Note that it may not be necessary to reprocess the first Srefresh message every time it is refreshed. In particular, suppose S is a refresh message which contains the message IDs for messages M1 to Mn. Suppose further that the refresh interval of the S is considerably shorter than the refresh interval of any of the messages M1 to Mn. Let Rm be the minimum refresh period of the messages M1 to Mn. Then an implementation could set a timer to Rm and reprocess S (assuming that S had not expired) each time Rm expires. Swallow [Page 4] Internet Draftraft-swallow-rsvp-hierarchical-refresh-00.txt October 1999 4. Modified Srefresh message format The Srefresh message format is as follows: ::= [ ] [ ... ] [ ] [ ] | ::= | [ ... ] [ ... ] ::= [ ... ] 5. Acknowledgments The basic ideas of RSVP state compression were first put forward by Lan Wang, Andreas Terzis, and Lixia Zhang in [WTZ]. 6. Security Considerations No new security issues are raised in this document. See [RFC2205] for a general discussion on RSVP security issues. 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [Berger] Berger, L. et al, "RSVP Refresh Reduction Extensions", draft-ietf-rsvp-refresh-reduct-00.txt, September 1999. [WTZ] Wang, L., et al, "A Proposal for reducing RSVP Refresh Overhead using State Compression", draft-wang-rsvp-state-compression-02.txt, June 1999. Swallow [Page 5] Internet Draftraft-swallow-rsvp-hierarchical-refresh-00.txt October 1999 8. Author's Address George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 Email: swallow@cisco.com Swallow [Page 6]