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: ::= [ ] [ ] ::= [ ] [ ] 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: ::= [ ] [ ] ::= [ ] [ ] 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 ::= [] [ ]