Internet Engineering Task Force P. Pan/H. Schulzrinne/R. Guerin
INTERNET DRAFT IBM/Columbia University/IBM
21 November 1997
Staged Refresh Timers for RSVP
draft-pan-rsvp-timer-00.txt
Status of This Memo
This document is an Internet-Draft. 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 not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
The current resource Reservation Protocol (RSVP) design has
no reliability mechanism for the delivery of control messages.
Instead, RSVP relies on periodic refresh between routers to
maintain reservation states. This approach has several problems
in a congested network. End systems send Path and Resv messages
to set up RSVP connections. If the first Path or Resv message
from an end system is accidentally lost in the network, a copy of
the message will not be retransmitted until the end of a refresh
interval, causing a delay of 30 seconds or more until a reservation
is established. If a congested link causes a tear-down message
(PathTear or ResvTear) to be dropped, the corresponding reservation
will not be removed from the routers until the RSVP cleanup timer
expires.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page i]
Internet Draft RSVP Timer 21 November 1997
We present an RSVP enhancement called staged refresh timers to
support fast and reliable message delivery that ensures hop-by-hop
delivery of control messages without violating the soft-state design.
The enhancement is backwards-compatible and can be easily added to
current implementations. The new approach can speed up the delivery
of trigger messages while reducing the amount of refresh messages.
The approach is also applicable to other soft-state protocols.
The performance benefits of this approach are explored in [PS97].
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page ii]
Internet Draft RSVP Timer 21 November 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
2.1. Sending and Receiving Nodes . . . . . . . . . . . . . . . 2
2.2. Trigger and Refresh Message . . . . . . . . . . . . . . . 2
3. Protocol Mechanisms 3
3.1. Outline of Operation . . . . . . . . . . . . . . . . . . 3
3.2. Time Parameters . . . . . . . . . . . . . . . . . . . . . 3
3.3. Staged Refresh . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Extension 5
4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Echo-Reply Messages . . . . . . . . . . . . . . . . . . . 6
4.2.1. PathAck Messages . . . . . . . . . . . . . . . . 6
4.2.2. PathTearAck Messages . . . . . . . . . . . . . . 7
4.2.3. ResvAck Messages . . . . . . . . . . . . . . . . 7
4.2.4. ResvTearAck Messages . . . . . . . . . . . . . . 7
5. Special Considerations 8
5.1. Backward Compatibility . . . . . . . . . . . . . . . . . 8
5.2. Computing Cleanup Timeout Values . . . . . . . . . . . . 8
5.3. Handling of Tear-Down Messages . . . . . . . . . . . . . 9
5.4. Operation in an NBMA Environment . . . . . . . . . . . . 9
6. Discussion 11
A. Appendix: Processing Rules 12
A.1. Modification to the Existing Rules . . . . . . . . . . . 13
A.1.1. PATH MESSAGE ARRIVES: . . . . . . . . . . . . . . 13
A.1.2. PATHTEAR MESSAGE ARRIVES: . . . . . . . . . . . . 14
A.1.3. RESV MESSAGE ARRIVES: . . . . . . . . . . . . . . 15
A.1.4. RESVTEAR MESSAGE ARRIVES: . . . . . . . . . . . . 15
A.2. Processing Rules for New Messages . . . . . . . . . . . . 16
A.2.1. PATHACK MESSAGE ARRIVES . . . . . . . . . . . . . 16
A.2.2. PATHTEARACK MESSAGE ARRIVES . . . . . . . . . . . 17
A.2.3. RESVACK MESSAGE ARRIVES . . . . . . . . . . . . . 18
A.2.4. RESVTEARACK MESSAGE ARRIVES . . . . . . . . . . . 18
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page iii]
Internet Draft RSVP Timer 21 November 1997
A.2.5. PATH ACK . . . . . . . . . . . . . . . . . . . . 18
A.2.6. RESV ACK . . . . . . . . . . . . . . . . . . . . 19
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page iv]
Internet Draft RSVP Timer 21 November 1997
1. Introduction
The Reservation Protocol (RSVP) [ZDE+93, BZB+97] has been designed
to exchange resource reservation information among routers in an
internet. One of its advantages is that it relies on soft state
to maintain reservation state in each router: Reservations will
disappear by themselves if they are not refreshed periodically. This
avoids orphan reservations and allows reservations to adapt quickly
to routing changes, without involvement of the end systems. End
systems send explicit tear-down messages to speed up the removal of
reservations when routes change or the application exits.
RSVP sends its control messages as IP datagrams with no reliability
guarantee. It relies on the periodic refresh messages from hosts
and routers to handle the occasional loss of a Path or Resv message.
Each RSVP host or router maintains a cleanup timer. A state is
deleted if no refresh messages arrive before the expiration of a
cleanup timeout interval.
Packet losses in the current Internet can be frequent, unfortunately.
In today's Internet multicast backbone (Mbone), the packet loss rate
[YKT96] is approximately 1-2% on average, and can occasionally reach
20% or more on congested links. The existing RSVP message delivery
mechanism will not work well in such an environment. For example,
when a user tries to make a reservation over the network, if the
first reservation request (Resv message) is lost due to congestion,
it will not be retransmitted over the congested link until the next
refresh cycle arrives. The default refresh interval is 30 seconds.
Thus, the first few seconds of, say, a multimedia flow may experience
degraded quality of service as packets are carried on a best-effort
basis rather than as a reserved flow. Unfortunately, packet loss is
more likely to delay reservations just when needed most, i.e., when
packet loss rates for best-effort service are high.
RSVP soft states are managed hop-by-hop, i.e., no network entities
other than the node that sent the original refresh message can
retransmit a refresh message. Thus, a user cannot accelerate the
reservation process by retransmitting RSVP messages.
RSVP also does not retransmit tear-down messages. If, for example,
a user tries to remove a reservation, and the message (ResvTear) is
lost, the reservation will remain in place until it times out, by
default after 90 seconds. If holding a reservation incurs costs,
the user will have to pay for the extra time that has been spent
waiting for the reservation time-out. Also, network resources are
used inefficiently. Network providers will have to account for this
uncertainty in their billing policies.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 1]
Internet Draft RSVP Timer 21 November 1997
In this document, we propose a simple RSVP extension that provides
a mechanism to deliver RSVP messages faster and more reliably, that
is backward compatible with the existing implementations, and that
reduces the number of refreshes among routers, contributing to
protocol scalability.
2. Terminology
2.1. Sending and Receiving Nodes
A sending node is a router or host that generates RSVP messages. A
receiving node is defined as the RSVP router or host that is one RSVP
hop away from a sending node. In a shared-media or non-broadcast
multiple access (NBMA) network such as an ATM subnet, a sending node
may have multiple receiving nodes. In some cases, not all routers
between sending and receiving nodes implement RSVP. We refer to these
networks as non-RSVP clouds.
2.2. Trigger and Refresh Message
In RSVP, control traffic can be categorized into two types: trigger
and refresh messages. Trigger messages are generated by an RSVP
host or a router due to state changes. Such state changes include
the initiation of a new state, a route change that altered the
reservation paths, or a reservation modification by a downstream
router. Path, Resv, PathTear and ResvTear serve as RSVP trigger
messages.
Refresh messages, on the other hand, contain replicated state
information generated by a router to maintain state. As indicated in
the introduction, RSVP periodically refreshes state for robustness.
For instance, if the RSVP daemon on a router crashes and resets,
it loses all RSVP state information. However, since its neighbor
routers send copies of RSVP state information periodically, the
router can recover the lost states within one refresh interval. A
refresh message can be either a Path or Resv message.
The RSVP routing interface [Zap96, GSE97] can detect state changes,
so that refresh messages are not needed to update router reservation
states. If the RSVP daemon is reasonably reliable, refresh messages
are more of a safety mechanism than actually used for network
operation and can thus be sent very infrequently, in the range of
hours instead of 30 seconds. This greatly reduces the traffic and
processing impact of RSVP messages and makes RSVP signaling at least
as efficient as circuit-switched setup protocols. However, this
requires that trigger messages are delivered reliably.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 2]
Internet Draft RSVP Timer 21 November 1997
3. Protocol Mechanisms
3.1. Outline of Operation
We propose the following feedback mechanism for RSVP trigger message
delivery: When sending an RSVP trigger message, a node inserts a new
echo-request flag into the RSVP common header of the message. Upon
reception, a receiving node acknowledges the arrival of the message
by sending back an echo-reply. When the sending node receives this
echo-reply for a Path or Resv message, it will automatically scale
back the refresh rate for these messages for the flow. If the
trigger message was a flow tear-down, no more tear-down messages are
sent, just as in the current RSVP specification. Until the echo
reply is received, the sending node will retransmit the trigger
message. The interval between retransmissions is governed by a
staged refresh timer. The staged refresh timer starts at a small
interval which increases exponentially until it reaches a threshold.
From that point on, the sending node will use a fixed timer to
refresh Path and Resv messages and stop re-transmitting tear-down
messages. This mechanism is designed so that the message load is
only slightly larger than in the current specification even if a node
does not support this staged refresh timer.
3.2. Time Parameters
The new extension makes the use of the following time parameters.
All parameters should be modifiable per interface.
Fast refresh interval Rf:
Rf is the initial retransmission interval for trigger messages.
After sending the message for the first time, the sending node
will schedule a retransmission after Rf seconds. The value of
Rf could be as small as the round trip time (RTT) between a
sending and a receiving node, if known. Unless a node knows
that all receiving nodes support echo-replies, a slightly
larger value of, for example, 3 seconds is suggested.
Slow refresh interval Rs:
The sending node retransmits with this interval after it
has determined that the receiving nodes support the RSVP
echo-reply. To reduce the number of unnecessary refreshes in
a stable network, Rs can be set to a large value. The value
of Rs can be set for each egress interface. Throughout the
remainder of the document we assume a value of 15 minutes for
Rs.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 3]
Internet Draft RSVP Timer 21 November 1997
Fixed refresh interval R:
A node retransmits the trigger message with the interval Rf*(1
+ Delta)**i until the refresh interval reaches the fixed
refresh interval R or an echo reply has been received. If
no reply has been received, the node continues to retransmit
refreshes every R seconds. We choose a value for R of 30
seconds, the same value as the refresh interval in the current
RSVP specification.
Increment value Delta:
Delta governs the speed with which the sender increases
the refresh interval. The ratio of two successive refresh
intervals is (1 + Delta). We arbitrarily set Delta to 0.30,
which is also the the same value as the Slew.Max parameter that
has been defined in RSVP to increase the retransmission and
timeout interval for long-lived flows using local repairs.
3.3. Staged Refresh
After a sending node transmits a trigger message, it will immediately
schedule a retransmission after Rf seconds. If it receives
echo-replies, the sending node will change the refresh interval to
Rs. Otherwise, it will retransmit the message after (1 + Delta)*Rf
seconds. The staged retransmission will continue until either
echo-replies are received, or the refresh interval has been increased
to R.
The implementation of staged refresh is simple. A sending node can
use the following algorithm when the RSVP refresh timer for state
(flow) k has expired:
if (Rk < R) {
Rk = Rk * (1 + Delta);
send out a refresh message;
wake up in state k after Rk seconds;
exit;
}
else { /* no reply from receivers for too long: */
Rk = R;
if (the state k is for a tear-down message) {
clean up state k;
exit;
}
else {
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 4]
Internet Draft RSVP Timer 21 November 1997
send out a refresh message;
wake up state k after Rk seconds;
exit;
}
}
Asynchronously, when a sending node receives echo-replies from the
receiving nodes, it will change the refresh interval Rk to Rs for
state k.
4. Protocol Extension
The proposed mechanism requires several minor modifications to the
current version of RSVP: a new bit is defined in the flag field of
the RSVP common header, and four new message types are created for
echo-reply. The echo reply messages are simple copies of the message
to be confirmed, with the message type changed. While Path messages
are generated end-to-end, Path echo-replies are hop-by-hop, using the
previous hop (PHOP) field from the message.
4.1. Common Header
For Path, Resv, PathTear and ResvTear messages, there is an
additional echo-request flag in the RSVP common header. Four
additional new messages have also been defined to support feedback.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 5]
Internet Draft RSVP Timer 21 November 1997
The format of the RSVP common-header is:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
Flags: 4 bits
0x01: echo-request flag.
Msg Type: 8 bits
8 = PathAck
9 = PathTearAck
10 = ResvAck
11 = ResvTearAck
4.2. Echo-Reply Messages
4.2.1. PathAck Messages
The format of a PathAck message is as follows:
<PathAck Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
The RSVP_HOP object of each PathAck message contains the IP address
of the interface through which the Path message was received and the
LIH (Logical Interface Handle) which was carried in the Path message.
The destination address in IP header is the address stored in the
RSVP_HOP object of the original Path message.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 6]
Internet Draft RSVP Timer 21 November 1997
4.2.2. PathTearAck Messages
The format of a PathTearAck message is as follows:
<PathTearAck Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
The RSVP_HOP object of each PathTearAck message contains the IP
address of the interface through which the PathTear message was
received and the LIH of which was carried in the PathTear message.
The destination address in IP header is the address stored in the
RSVP_HOP object of the original PathTear message.
4.2.3. ResvAck Messages
<ResvAck Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see RSVP specification, RFC2205)
The RSVP_HOP (i.e., the PHOP) object contains the IP address of the
interface through which the Resv message was received. It also
carries the corresponding LIH.
4.2.4. ResvTearAck Messages
<ResvTearAck Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 7]
Internet Draft RSVP Timer 21 November 1997
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see RSVP specification, RFC2205)
The RSVP_HOP (i.e., the PHOP) object contains the IP address of the
interface through which the ResvTear message was received. It also
carries the corresponding LIH.
5. Special Considerations
5.1. Backward Compatibility
Backward compatibility is one of the main objectives in our design.
One cannot assume that both sending and receiving nodes on a link
will support the extension simultaneously.
In the current RSVP specification, sending nodes refresh the soft
states with fixed timers. In our design, sending nodes rely on echo
request/reply mechanism to ``learn'' about the status of receiving
nodes. If a sending node does not receive echo replies from the
receiving nodes after several tries, it will assume the receiving
nodes do not support the new extension, and switch its refresh
interval to a fixed value. The RSVP operation is not affected at the
receiving nodes.
5.2. Computing Cleanup Timeout Values
Each RSVP Path and Resv message carries a refresh interval in its
TIME_VALUES object. Receiver nodes use the refresh interval to
compute the cleanup timeout interval that governs the lifetime of
reservation state that has not been refreshed. Generally, the
cleanup timeout interval is a small multiple of refresh interval.
In the staged refresh design, a sending node initially places
the slow refresh timer, Rs, in the Path or Resv message. For the
receiving nodes that do not support the new extension, the sending
node will insert R in the refresh messages after the actual refresh
interval has been increased to R. If the receiving nodes do support
the new extension, they will set the cleanup timeout interval based
on Rs.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 8]
Internet Draft RSVP Timer 21 November 1997
5.3. Handling of Tear-Down Messages
RSVP uses PathTear and ResvTear messages to tear-down path and
reservation states, respectively. According to the current
specification, sending nodes only generate one tear-message per flow.
If the message is accidentally dropped along the way, the reserved
resource will not be released until the cleanup timer expires.
However, receiving duplicate tear-down messages at a receiving node
should not impact the operation of RSVP in a proper implementation.
In our RSVP extension, we have altered the processing rules for
tear-down messages at the sending node. Instead of deleting the
state after a tear-down message is sent, a sending node will release
all resource allocated to the state, and mark the state as closing.
The state information is saved for message retransmission. The
entire state information will be removed when echo-replies are
received, or when the sending node realizes that the receiving nodes
do not support the extension.
5.4. Operation in an NBMA Environment
For a multicast RSVP session in a non-broadcast multiple access
(NBMA) network (such as ATM), a sending node may not know the total
number of receiving nodes for a Path or PathTear message at an egress
interface. Therefore, a sending node cannot simply switch to the
longer refresh timer Rs based on having received echo-replies.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 9]
Internet Draft RSVP Timer 21 November 1997
Path
+-------------+ ------> +----+
| a |----------------| R3 |
| | +----+
| |
| | Path
+---+ | | ------> +----+
| S |-----------| Router b |----------------| R2 |
+---+ -----> | | <------ +----+
Path | | PathAck
| |
| |
| | Path
| | ------> +----+
| c |----------------| R1 |
+-------------+ <------ +----+
PathAck
Figure-1: Path/PathAck in an NBMA network
For example, as shown in Figure-1, if the receiving node R3 does
not support the new RSVP extension, the sending node S should not
change to the longer refresh interval Rs, even though it has received
echo-replies from R1 and R2.
In this case, a sending node has two alternatives:
- It can query a local database such as the ARP or MARS server
to find out the exact number of the next-hop receivers. It
then switches to a longer refresh interval after receiving
echo-replies from all receiving nodes.
- Since Path messages are mainly used for traffic advertisement
purposes, the sending node may not need to use staged refresh
timers for Path messages. In an NBMA network, the staged refresh
time mechanism would only make sense for the message delivery of
Resv, ResvTear and PathTear messages.
In case of PathTear message, a sending node always knows all the
receiving nodes that have made reservations. The following rules can
be used:
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 10]
Internet Draft RSVP Timer 21 November 1997
- A sending node stops re-transmitting PathTear messages once it
receives echo-replies from all its known next-hop receivers at an
egress interface.
- Otherwise, the sending node generates PathTear messages using
staged refresh timer until the refresh interval is increased to
the fixed refresh rate R. Then it stops re-transmitting.
PathTear
+-------------+ ------> +----+
| a |----------------| R3 |
| | +----+
| |
| | PathTear
+---+ | | ------> +----+
| S |-----------| Router b |----------------| R2 |
+---+ -----> | | <------ +----+
PathTear | | PathTearAck
| |
| |
| | PathTear
| | ------> +----+
| c |----------------| R1 |
+-------------+ <------ +----+
PathTearAck
Figure-2: PathTear/PathTearAck in an NBMA network
An example is shown in Figure-2. R1, R2 and R3 are the receiving
nodes to S. Initially, the sender S had the reservation state
information for receiving node R1 and R2. Since R3 did not make
any reservation, S would not know the existence of R3 from its
RSVP database. After sending the first PathTear message, S will
retransmit the message until it has received echo replies from R1 and
R2. After which, S stops generating PathTear messages.
6. Discussion
We believe that RSVP message delivery mechanism requires some
degree of reliability guarantee to make RSVP useful for individual
applications rather than reserving ``pipes''. One way of improving
reliability is to grant some minimal bandwidth for RSVP messages
to protect them from congestion losses, as suggested in the RSVP
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 11]
Internet Draft RSVP Timer 21 November 1997
specification [BZB+97]. However, this may require additional
functionality at both sending and receiving nodes and does not help
if RSVP messages have to traverse non-RSVP clouds. It is also not
clear how this can be achieved in a backward-compatible manner.
In this paper, we presented a mechanism called staged refresh timers
that enhances the current RSVP message delivery and is completely
backward compatible. Staged refresh timers are easy to add to
RSVP router and host implementations and save both processing and
bandwidth overhead.
The staged refresh timer mechanism is an example of state management
that falls somewhere between ``classical'' handshake-based
reliability as found in ATM signaling, for example, and purely
timer-based soft-state protocols such as the original RSVP proposal
[ZDE+93], delta-t [Wat89] or IGMPv1 [Dee89]. An approach similar
to staged refresh is also being used by the Session Initiation
Protocol [HSS97] to confirm state establishment. Generally speaking,
experience has shown that state management is greatly simplified
by requiring only one message (in each direction) to establish
state, rather than going through several intermedia states. State
establishment messages should be idempotent and should contain a
globally (spatially and temporally) unique state label, so that
retransmissions of the same message can be ignored.
Since only neighboring routers are involved in the reliability
mechanism described here, these routers can easily estimate
round-trip times, thus further tightening the retransmission
interval, if desired.
While staged refresh timers improve scalability, RSVP remains
a rather complex protocol. Alternative approaches to reserve
reservation [CW97, PS98] may offer better scaling properties.
A. Appendix: Processing Rules
We outline a set of algorithms to illustrate how the new scheme
works. The notations and definitions such as PSB and RSB are defined
in [BZ97]. However, this should not be considered as the actual
implementation requirements.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 12]
Internet Draft RSVP Timer 21 November 1997
A.1. Modification to the Existing Rules
A.1.1. PATH MESSAGE ARRIVES:
Two additional steps that are required during Path message
processing:
1. reply PathAck message back to a sending node;
2. use staged refresh timer to send Path if the PSB is new or
changed.
Reference Algorithm:
Assume the message arrives on interface InIf.
After message sanity checks:
o Search for a path state block (PSB) whose (session, sender_template)
pair matches the corresponding objects in the message, and whose
ingress interface matches InIf.
o If there is no matching PSB, then:
1. Create a new PSB.
2. Update all relevant information to the PSB.
o Otherwise (there is a matching PSB):
- Update all relevant information to the PSB.
o If the echo-request flag is set in the common-header, and the
echo-reply option is enabled for the ingress interface InIf:
- Execute the PATH ACK sequence (below) for the PHOP in PSB.
o Continue the Path message processing.
o If the PSB is new or modified, then:
1. Update the PSB's refresh timer to fast refresh interval Rf.
2. Execute the PATH REFRESH sequence.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 13]
Internet Draft RSVP Timer 21 November 1997
A.1.2. PATHTEAR MESSAGE ARRIVES:
The router can reply a PathTearAck message to the sending node,
release allocated resource and relay tear-down message downstream
with staged refresh timer.
During the process of PathTear message, unlike what's in the current
RSVP specification, where a state is deleted as a result, the state
is marked as PathTear_Pending in the new scheme. It will be deleted
by either the arrival of PathTearAck messages, or clean-up timer
expiration.
Reference Algorithm:
Assume the message arrives on interface InIf.
After message sanity checks:
o Search for a PSB whose (Session, Sender_Template) pair matches
the corresponding objects in the message, and the ingress
interface matches to InIf.
o If there is no matching PSB:
- Drop the message and return.
o If the echo-request flag is set in the common-header, and the
echo-reply option is enabled for the ingress interface,
- Execute the PATH ACK sequence (below) for the PHOP in PSB.
o Forward a copy of the PathTear message to each egress interface
listed in the PSB.
o If the PSB is marked as Pathtear_Pending, (that is, a repeated
PathTear message from upstream)
- Drop the message and return.
o Otherwise, (i.e., the Pathtear_Pending flag in the PSB is off):
1. Insert a Pathtear_Pending flag into the PSB.
2. Release all resource associated to the PSB.
3. Update the PSB's refresh timer to fast refresh interval Rf.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 14]
Internet Draft RSVP Timer 21 November 1997
o Drop the message and return.
A.1.3. RESV MESSAGE ARRIVES:
Similar to the modified Path processing rule, the new extension
requires a router to reply an acknowledgment message and schedule
refreshes with staged refresh timer.
Reference Algorithm:
After message sanity checks:
o Find all reservation state blocks (RSB's) that are corresponding
to the flows defined in the message.
- Execute RESV ACK sequence (below) to the NHOP in the message.
o Continue the Resv message processing.
o For all the RSB's that are new or modified,
1. Update their refresh interval to fast refresh interval Rf.
2. Execute RESV REFRESH sequence.
A.1.4. RESVTEAR MESSAGE ARRIVES:
The router will send an echo-reply to the sending node, and schedule
refreshes with the staged refresh timer.
During the process of the message, resource that is associated with
the state should be released and marked as pending. The state
information is finally removed during the processing of ResvTearAck
message or timer expiration.
Reference Algorithm:
After message sanity checks:
o Find all PSB's that are corresponding to the flows defined in
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 15]
Internet Draft RSVP Timer 21 November 1997
the message.
- Execute RESV ACK sequence (below) to the NHOP in the message.
o Continue the ResvTear message processing.
o For all the RSB's that are described the ResvTear message:
1. If a RSB is not marked with Resvtear\_Pending flag:
- remove the reserved resource indicated in the RSB.
- mark the RSB to be Resvtear\_Pending.
- mark the RSB's refresh interval to fast interval Rf.
2. Execute RESV REFRESH sequence to forward ResvTear messages
upstream.
o Drop the message and return.
A.2. Processing Rules for New Messages
A.2.1. PATHACK MESSAGE ARRIVES
From SESSION, SENDER_TEMPLATE and egress interface information, a
router finds the corresponding state and changes the refresh rate to
a slower one.
Reference Algorithm:
Assume the message arrives on interface OutIf.
o Search for a path state block (PSB) whose (session, sender_template)
pair matches the corresponding objects in the message, and
whose egress interface matches OutIf.
o If there is no matching PSB, then:
- Drop the message and return.
o Otherwise (there is a matching)
- Set the refresh timer of the PSB to slow refresh interval Rs.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 16]
Internet Draft RSVP Timer 21 November 1997
o Drop the message and return.
A.2.2. PATHTEARACK MESSAGE ARRIVES
From SESSION, SENDER_TEMPLATE and egress interface, a router finds
the corresponding state. However the state can not be removed until
the router has received acknowledgments from all known next-hop
routers of the RSVP flow.
Reference Algorithm:
Assume the message arrives on interface OutIf.
o Search for a path state block (PSB) whose (session, sender_template)
pair matches the corresponding objects in the message, and whose
egress interface matches OutIf.
o If there is no matching PSB, then:
- drop the message and return.
o Find the RSB that matches the PSB. (The resource associated
with the RSB should has been released during PathTear processing
time.)
- remove the RSB.
o Search for all RSB that matches this PSB.
- If no more RSB could be found, then:
- remove the PSB and return.
- Otherwise, (there may still be reserved flows downstream):
- return.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 17]
Internet Draft RSVP Timer 21 November 1997
A.2.3. RESVACK MESSAGE ARRIVES
Find all the states that are described in the message, and switches
their refresh timer to a slower one.
Reference Algorithm:
After message sanity checks:
o Find all the RSB's that are corresponding to the flows defined
in the message.
- Set the refresh timer of the RSB's to slow refresh interval Rs.
o Drop the message and return.
A.2.4. RESVTEARACK MESSAGE ARRIVES
Find the corresponding states, and remove them.
Reference Algorithm:
After message sanity checks:
o Find all RSB's that are corresponding to the flows defined in
the message.
- Delete the RSB's.
o Drop the message and return.
This sequence sends a PathAck or a PathTearAck towards a particular
previous hop. It is invoked from either PATH MESSAGE ARRIVES, or
PATHTEAR MESSAGE ARRIVES sequence.
o Copy SESSION object and sender descriptor from the received
Path (or PathTear) message into the PathAck (or PathTearAck)
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 18]
Internet Draft RSVP Timer 21 November 1997
message being built.
o Insert into its RSVP_HOP object the ingress interface address
and the LIH for the interface.
o Insert the PHOP address (from the Path/PathTear message) as the
destination address into the IP header being built.
o Update the RSVP common-header and IP header.
o Send the message out.
This sequence sends a ResvAck or a ResvTearAck towards a particular
next hop. It is invoked from either RESV MESSAGE ARRIVES, or
RESVTEAR MESSAGE ARRIVES sequence.
o Copy SESSION, STYLE, SCOPE (if WF style), and the flow
descriptor list from the received Resv (or ResvTear) message
into the Resv (or ResvTearAck) message being built.
o Insert into its RSVP_HOP objet the egress interface address and
the LIH for the interface.
o Insert the NHOP address (from the Resv/ResvTear message) as the
destination address into the IP header being built.
o Update the RSVP common-header and IP header.
o Send the message out.
References
[BZ97] R. Braden and L. Zhang. Resource reservation protocol
(rsvp) -- version 1 message processing rules. RFC 2209,
Internet Engineering Task Force, September 1997.
[BZB+97] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin.
Resource reservation protocol (RSVP) -- version 1
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 19]
Internet Draft RSVP Timer 21 November 1997
functional specification. , Internet Engineering Task
Force, September 1997.
[CW97] D. Clark and J. Wroclawski. An approach to service
allocation in the internet. Internet Draft, Internet
Engineering Task Force, August 1997. Work in progress.
[Dee89] S. Deering. Host extensions for IP multicasting. STD 5,
RFC 1112, Internet Engineering Task Force, August 1989.
[GSE97] R. Guerin, Kamat S., and Rosen E. Extended rsvp-routing
interface. Internet Draft, Internet Engineering Task
Force, July 1997. Work in progress.
[HSS97] Mark Handley, Henning Schulzrinne, and Eve Schooler. SIP:
Session initiation protocol. Internet Draft, Internet
Engineering Task Force, July 1997. Work in progress.
[PS97] Ping Pan and Henning Schulzrinne. Staged refresh timers
for RSVP. In Global Internet'97, Phoenix, Arizona,
November 1997. also IBM Research Technical Report TC20966.
[PS98] Ping P. Pan and Henning Schulzrinne. YESSIR: A simple
reservation mechanism for the Internet. In IBM Research
Technical Report TC20967, 1998.
[Wat89] Richard W. Watson. The Delta-t transport protocol:
Features and experience. In Harry Rudin and Robin
Williamson, editors, First IFIP WG6.1/WG6.4 International
Workshop on Protocols for High-Speed Networks, pages 3--17,
Z rich, Switzerland, May 1989.
[YKT96] Maya Yajnik, Jim Kurose, and Don Towsley. Packet loss
correlation in the MBone multicast network. In Proceedings
of Global Internet, London, England, November 1996.
[Zap96] Daniel Zappala. RSRR: a routing interface for RSVP.
Internet Draft (expired), Internet Engineering Task Force,
November 1996. Work in progress.
[ZDE+93] Lixia Zhang, Stephen Deering, Deborah Estrin, Scott
Shenker, and Daniel Zappala. RSVP: a new resource
ReSerVation protocol. IEEE Network, 7(5):8--18, September
1993.
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 20]
Internet Draft RSVP Timer 21 November 1997
Authors' Address
Ping Pan
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
USA
Phone: +1 914 784-6579
Email: pan@watson.ibm.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
electronic mail: schulzrinne@cs.columbia.edu
Roch Guerin
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
USA
Phone: +1 914 784-7038
Email: guerin@watson.ibm.com
Pan/Schulzrinne/Guerin Expires 26 May 1998 [Page 21]