idnits 2.17.1 draft-pan-rsvp-timer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([PS97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 479 has weird spacing: '... Router b |--...' == Line 529 has weird spacing: '... Router b |--...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 November 1997) is 9645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2209 (ref. 'BZ97') -- Possible downref: Non-RFC (?) normative reference: ref. 'CW97' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSE97' -- Possible downref: Non-RFC (?) normative reference: ref. 'HSS97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PS97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Wat89' -- Possible downref: Non-RFC (?) normative reference: ref. 'YKT96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Zap96' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Pan/H. Schulzrinne/R. Guerin 2 INTERNET DRAFT IBM/Columbia University/IBM 3 21 November 1997 5 Staged Refresh Timers for RSVP 6 draft-pan-rsvp-timer-00.txt 8 Status of This Memo 10 This document is an Internet-Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as 18 reference material, or to cite them other than as a ``working draft'' 19 or ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the internet-drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 The current resource Reservation Protocol (RSVP) design has 30 no reliability mechanism for the delivery of control messages. 31 Instead, RSVP relies on periodic refresh between routers to 32 maintain reservation states. This approach has several problems 33 in a congested network. End systems send Path and Resv messages 34 to set up RSVP connections. If the first Path or Resv message 35 from an end system is accidentally lost in the network, a copy of 36 the message will not be retransmitted until the end of a refresh 37 interval, causing a delay of 30 seconds or more until a reservation 38 is established. If a congested link causes a tear-down message 39 (PathTear or ResvTear) to be dropped, the corresponding reservation 40 will not be removed from the routers until the RSVP cleanup timer 41 expires. 43 We present an RSVP enhancement called staged refresh timers to 44 support fast and reliable message delivery that ensures hop-by-hop 45 delivery of control messages without violating the soft-state design. 46 The enhancement is backwards-compatible and can be easily added to 47 current implementations. The new approach can speed up the delivery 48 of trigger messages while reducing the amount of refresh messages. 49 The approach is also applicable to other soft-state protocols. 51 The performance benefits of this approach are explored in [PS97]. 53 Contents 55 Status of This Memo i 57 Abstract i 59 1. Introduction 1 61 2. Terminology 2 62 2.1. Sending and Receiving Nodes . . . . . . . . . . . . . . . 2 63 2.2. Trigger and Refresh Message . . . . . . . . . . . . . . . 2 65 3. Protocol Mechanisms 3 66 3.1. Outline of Operation . . . . . . . . . . . . . . . . . . 3 67 3.2. Time Parameters . . . . . . . . . . . . . . . . . . . . . 3 68 3.3. Staged Refresh . . . . . . . . . . . . . . . . . . . . . 4 70 4. Protocol Extension 5 71 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. Echo-Reply Messages . . . . . . . . . . . . . . . . . . . 6 73 4.2.1. PathAck Messages . . . . . . . . . . . . . . . . 6 74 4.2.2. PathTearAck Messages . . . . . . . . . . . . . . 7 75 4.2.3. ResvAck Messages . . . . . . . . . . . . . . . . 7 76 4.2.4. ResvTearAck Messages . . . . . . . . . . . . . . 7 78 5. Special Considerations 8 79 5.1. Backward Compatibility . . . . . . . . . . . . . . . . . 8 80 5.2. Computing Cleanup Timeout Values . . . . . . . . . . . . 8 81 5.3. Handling of Tear-Down Messages . . . . . . . . . . . . . 9 82 5.4. Operation in an NBMA Environment . . . . . . . . . . . . 9 84 6. Discussion 11 86 A. Appendix: Processing Rules 12 87 A.1. Modification to the Existing Rules . . . . . . . . . . . 13 88 A.1.1. PATH MESSAGE ARRIVES: . . . . . . . . . . . . . . 13 89 A.1.2. PATHTEAR MESSAGE ARRIVES: . . . . . . . . . . . . 14 90 A.1.3. RESV MESSAGE ARRIVES: . . . . . . . . . . . . . . 15 91 A.1.4. RESVTEAR MESSAGE ARRIVES: . . . . . . . . . . . . 15 92 A.2. Processing Rules for New Messages . . . . . . . . . . . . 16 93 A.2.1. PATHACK MESSAGE ARRIVES . . . . . . . . . . . . . 16 94 A.2.2. PATHTEARACK MESSAGE ARRIVES . . . . . . . . . . . 17 95 A.2.3. RESVACK MESSAGE ARRIVES . . . . . . . . . . . . . 18 96 A.2.4. RESVTEARACK MESSAGE ARRIVES . . . . . . . . . . . 18 97 A.2.5. PATH ACK . . . . . . . . . . . . . . . . . . . . 18 98 A.2.6. RESV ACK . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 The Reservation Protocol (RSVP) [ZDE+93, BZB+97] has been designed 103 to exchange resource reservation information among routers in an 104 internet. One of its advantages is that it relies on soft state 105 to maintain reservation state in each router: Reservations will 106 disappear by themselves if they are not refreshed periodically. This 107 avoids orphan reservations and allows reservations to adapt quickly 108 to routing changes, without involvement of the end systems. End 109 systems send explicit tear-down messages to speed up the removal of 110 reservations when routes change or the application exits. 112 RSVP sends its control messages as IP datagrams with no reliability 113 guarantee. It relies on the periodic refresh messages from hosts 114 and routers to handle the occasional loss of a Path or Resv message. 115 Each RSVP host or router maintains a cleanup timer. A state is 116 deleted if no refresh messages arrive before the expiration of a 117 cleanup timeout interval. 119 Packet losses in the current Internet can be frequent, unfortunately. 120 In today's Internet multicast backbone (Mbone), the packet loss rate 121 [YKT96] is approximately 1-2% on average, and can occasionally reach 122 20% or more on congested links. The existing RSVP message delivery 123 mechanism will not work well in such an environment. For example, 124 when a user tries to make a reservation over the network, if the 125 first reservation request (Resv message) is lost due to congestion, 126 it will not be retransmitted over the congested link until the next 127 refresh cycle arrives. The default refresh interval is 30 seconds. 129 Thus, the first few seconds of, say, a multimedia flow may experience 130 degraded quality of service as packets are carried on a best-effort 131 basis rather than as a reserved flow. Unfortunately, packet loss is 132 more likely to delay reservations just when needed most, i.e., when 133 packet loss rates for best-effort service are high. 135 RSVP soft states are managed hop-by-hop, i.e., no network entities 136 other than the node that sent the original refresh message can 137 retransmit a refresh message. Thus, a user cannot accelerate the 138 reservation process by retransmitting RSVP messages. 140 RSVP also does not retransmit tear-down messages. If, for example, 141 a user tries to remove a reservation, and the message (ResvTear) is 142 lost, the reservation will remain in place until it times out, by 143 default after 90 seconds. If holding a reservation incurs costs, 144 the user will have to pay for the extra time that has been spent 145 waiting for the reservation time-out. Also, network resources are 146 used inefficiently. Network providers will have to account for this 147 uncertainty in their billing policies. 149 In this document, we propose a simple RSVP extension that provides 150 a mechanism to deliver RSVP messages faster and more reliably, that 151 is backward compatible with the existing implementations, and that 152 reduces the number of refreshes among routers, contributing to 153 protocol scalability. 155 2. Terminology 157 2.1. Sending and Receiving Nodes 159 A sending node is a router or host that generates RSVP messages. A 160 receiving node is defined as the RSVP router or host that is one RSVP 161 hop away from a sending node. In a shared-media or non-broadcast 162 multiple access (NBMA) network such as an ATM subnet, a sending node 163 may have multiple receiving nodes. In some cases, not all routers 164 between sending and receiving nodes implement RSVP. We refer to these 165 networks as non-RSVP clouds. 167 2.2. Trigger and Refresh Message 169 In RSVP, control traffic can be categorized into two types: trigger 170 and refresh messages. Trigger messages are generated by an RSVP 171 host or a router due to state changes. Such state changes include 172 the initiation of a new state, a route change that altered the 173 reservation paths, or a reservation modification by a downstream 174 router. Path, Resv, PathTear and ResvTear serve as RSVP trigger 175 messages. 177 Refresh messages, on the other hand, contain replicated state 178 information generated by a router to maintain state. As indicated in 179 the introduction, RSVP periodically refreshes state for robustness. 180 For instance, if the RSVP daemon on a router crashes and resets, 181 it loses all RSVP state information. However, since its neighbor 182 routers send copies of RSVP state information periodically, the 183 router can recover the lost states within one refresh interval. A 184 refresh message can be either a Path or Resv message. 186 The RSVP routing interface [Zap96, GSE97] can detect state changes, 187 so that refresh messages are not needed to update router reservation 188 states. If the RSVP daemon is reasonably reliable, refresh messages 189 are more of a safety mechanism than actually used for network 190 operation and can thus be sent very infrequently, in the range of 191 hours instead of 30 seconds. This greatly reduces the traffic and 192 processing impact of RSVP messages and makes RSVP signaling at least 193 as efficient as circuit-switched setup protocols. However, this 194 requires that trigger messages are delivered reliably. 196 3. Protocol Mechanisms 198 3.1. Outline of Operation 200 We propose the following feedback mechanism for RSVP trigger message 201 delivery: When sending an RSVP trigger message, a node inserts a new 202 echo-request flag into the RSVP common header of the message. Upon 203 reception, a receiving node acknowledges the arrival of the message 204 by sending back an echo-reply. When the sending node receives this 205 echo-reply for a Path or Resv message, it will automatically scale 206 back the refresh rate for these messages for the flow. If the 207 trigger message was a flow tear-down, no more tear-down messages are 208 sent, just as in the current RSVP specification. Until the echo 209 reply is received, the sending node will retransmit the trigger 210 message. The interval between retransmissions is governed by a 211 staged refresh timer. The staged refresh timer starts at a small 212 interval which increases exponentially until it reaches a threshold. 213 From that point on, the sending node will use a fixed timer to 214 refresh Path and Resv messages and stop re-transmitting tear-down 215 messages. This mechanism is designed so that the message load is 216 only slightly larger than in the current specification even if a node 217 does not support this staged refresh timer. 219 3.2. Time Parameters 221 The new extension makes the use of the following time parameters. 222 All parameters should be modifiable per interface. 224 Fast refresh interval Rf: 226 Rf is the initial retransmission interval for trigger messages. 227 After sending the message for the first time, the sending node 228 will schedule a retransmission after Rf seconds. The value of 229 Rf could be as small as the round trip time (RTT) between a 230 sending and a receiving node, if known. Unless a node knows 231 that all receiving nodes support echo-replies, a slightly 232 larger value of, for example, 3 seconds is suggested. 234 Slow refresh interval Rs: 236 The sending node retransmits with this interval after it 237 has determined that the receiving nodes support the RSVP 238 echo-reply. To reduce the number of unnecessary refreshes in 239 a stable network, Rs can be set to a large value. The value 240 of Rs can be set for each egress interface. Throughout the 241 remainder of the document we assume a value of 15 minutes for 242 Rs. 244 Fixed refresh interval R: 246 A node retransmits the trigger message with the interval Rf*(1 247 + Delta)**i until the refresh interval reaches the fixed 248 refresh interval R or an echo reply has been received. If 249 no reply has been received, the node continues to retransmit 250 refreshes every R seconds. We choose a value for R of 30 251 seconds, the same value as the refresh interval in the current 252 RSVP specification. 254 Increment value Delta: 256 Delta governs the speed with which the sender increases 257 the refresh interval. The ratio of two successive refresh 258 intervals is (1 + Delta). We arbitrarily set Delta to 0.30, 259 which is also the the same value as the Slew.Max parameter that 260 has been defined in RSVP to increase the retransmission and 261 timeout interval for long-lived flows using local repairs. 263 3.3. Staged Refresh 265 After a sending node transmits a trigger message, it will immediately 266 schedule a retransmission after Rf seconds. If it receives 267 echo-replies, the sending node will change the refresh interval to 268 Rs. Otherwise, it will retransmit the message after (1 + Delta)*Rf 269 seconds. The staged retransmission will continue until either 270 echo-replies are received, or the refresh interval has been increased 271 to R. 273 The implementation of staged refresh is simple. A sending node can 274 use the following algorithm when the RSVP refresh timer for state 275 (flow) k has expired: 277 if (Rk < R) { 278 Rk = Rk * (1 + Delta); 279 send out a refresh message; 280 wake up in state k after Rk seconds; 281 exit; 282 } 283 else { /* no reply from receivers for too long: */ 284 Rk = R; 285 if (the state k is for a tear-down message) { 286 clean up state k; 287 exit; 288 } 289 else { 290 send out a refresh message; 291 wake up state k after Rk seconds; 292 exit; 293 } 294 } 296 Asynchronously, when a sending node receives echo-replies from the 297 receiving nodes, it will change the refresh interval Rk to Rs for 298 state k. 300 4. Protocol Extension 302 The proposed mechanism requires several minor modifications to the 303 current version of RSVP: a new bit is defined in the flag field of 304 the RSVP common header, and four new message types are created for 305 echo-reply. The echo reply messages are simple copies of the message 306 to be confirmed, with the message type changed. While Path messages 307 are generated end-to-end, Path echo-replies are hop-by-hop, using the 308 previous hop (PHOP) field from the message. 310 4.1. Common Header 312 For Path, Resv, PathTear and ResvTear messages, there is an 313 additional echo-request flag in the RSVP common header. Four 314 additional new messages have also been defined to support feedback. 316 The format of the RSVP common-header is: 318 0 1 2 3 319 +-------------+-------------+-------------+-------------+ 320 | Vers | Flags| Msg Type | RSVP Checksum | 321 +-------------+-------------+-------------+-------------+ 322 | Send_TTL | (Reserved) | RSVP Length | 323 +-------------+-------------+-------------+-------------+ 325 Flags: 4 bits 327 0x01: echo-request flag. 329 Msg Type: 8 bits 331 8 = PathAck 332 9 = PathTearAck 333 10 = ResvAck 334 11 = ResvTearAck 336 4.2. Echo-Reply Messages 338 4.2.1. PathAck Messages 340 The format of a PathAck message is as follows: 342 ::= [ ] 344 346 [ ] 348 ::= [ ] 350 [ ] 352 The RSVP_HOP object of each PathAck message contains the IP address 353 of the interface through which the Path message was received and the 354 LIH (Logical Interface Handle) which was carried in the Path message. 356 The destination address in IP header is the address stored in the 357 RSVP_HOP object of the original Path message. 359 4.2.2. PathTearAck Messages 361 The format of a PathTearAck message is as follows: 363 ::= [ ] 365 367 [ ] 369 ::= [ ] 371 [ ] 373 The RSVP_HOP object of each PathTearAck message contains the IP 374 address of the interface through which the PathTear message was 375 received and the LIH of which was carried in the PathTear message. 377 The destination address in IP header is the address stored in the 378 RSVP_HOP object of the original PathTear message. 380 4.2.3. ResvAck Messages 382 ::= [] 384 386 [ ]