Internet Draft
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]