idnits 2.17.1 draft-yuhara-rsvp-refresh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 1999) is 9142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2208' is mentioned on line 48, but not defined == Missing Reference: 'R1' is mentioned on line 145, but not defined == Missing Reference: 'R2' is mentioned on line 145, but not defined == Missing Reference: 'R3' is mentioned on line 141, but not defined == Missing Reference: 'R4' is mentioned on line 147, but not defined == Unused Reference: 'Bernet' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'Pan' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2208' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC2215' is defined on line 405, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-baker-rsvp-aggregation-00 -- Possible downref: Normative reference to a draft: ref. 'Baker' == Outdated reference: A later version (-03) exists of draft-berger-rsvp-refresh-reduct-00 -- Possible downref: Normative reference to a draft: ref. 'Berger' -- Possible downref: Normative reference to a draft: ref. 'Bernet' -- Possible downref: Normative reference to a draft: ref. 'Pan' ** Downref: Normative reference to an Informational RFC: RFC 2209 ** Downref: Normative reference to an Informational RFC: RFC 2208 ** Downref: Normative reference to an Informational RFC: RFC 2475 Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Yuhara 3 Expiration: October 1999 M. Tomikawa 4 File: draft-yuhara-rsvp-refresh-00.txt 5 Fujitsu Laboratories Ltd. 7 April 1999 9 RSVP Extensions for ID-based Refreshes 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The purpose of this document is to provide a discussion on the 35 refresh overhead reduction of RSVP. Specifically, this document 36 proposes some extensions to deal with route change while maintaining 37 the advantage of ID-based refreshes. For environments where PATH 38 refreshes must be used to detect route change, ID-only refreshes are 39 used to decrease the message size. For environments where route 40 change is informed to RSVP process by some other means, a new message 41 is introduced to invalidate ID. 43 1. Introduction 45 The combination of RSVP [RFC2205, RFC2209] and intserv [RFC2210, 46 RFC2215] was proposed to provide better quality of service than 47 traditional best effort service. When deploying this combination over 48 the internet, however, there are several concerns [RFC 2208], and the 49 scalability problem is regarded as the biggest problem. The 50 differentiated services (diffserv) [RFC2475] has challenged this 51 problem. Diffserv is expected to replace the role of intserv in the 52 internet backbones. However, to provide the end-to-end QoS, we still 53 need an end-to-end signaling protocol, and the only usable signaling 54 protocol now is RSVP. In fact, [Baker] and other drafts propose to 55 use RSVP as a signaling protocol for diffserv. 57 If we assume the aggregation region of [Baker] is a DS domain, RSVP 58 will be used (a) between a DS boundary node of a DS domain and an 59 external node which may be in a different DS domain or in an intserv 60 domain, (b) between DS boundary nodes of the same DS domain (for 61 individual reservation, bypassing interior nodes), (c) between two 62 RSVP neighbor nodes within the same DS domain (for behavior 63 aggregates). 65 Because the number of diffserv codepoints and the number of boundary 66 nodes are limited, (c) should not cause a scalability problem. 68 Scalability problems in the case of (a) and (b), however, still 69 exist. The refresh reduction draft [Berger] alleviates some of the 70 problems using several techniques. The techniques include refresh 71 suppression and packaging multiple RSVP messages into one message 72 (called aggregate messages; should not be confused with the 73 reservation aggregation in [Baker]). 75 The purpose of this document is to provide some discussion on that 76 draft and show some enhancements. Although multicast case will be 77 mentioned, it is not discussed extensively. 79 The extensions introduced in this draft surely complicate the 80 programming of RSVP process, but alleviate the RSVP processing cost 81 and the bandwidth required for refresh messages in the environments 82 where route change must be detected via PATH messages. Whether such 83 environments will exist in the core of the future internet, remains 84 to be seen. 86 2. Definition of route change 88 Let us defined what "route change at a node" means in the following 89 discussion. Route is said to have changed at an RSVP node when: 90 after sending the first PATH message for a session from this node, 91 the stream of packets for which this PATH message is intended 92 still goes through this node and 93 the next RSVP-capable node (or set of nodes of a multicast 94 group) for this stream has changed, or the outgoing interface 95 (or interfaces) for this stream has changed. 97 Note that this definition only concerns outgoing route from this 98 node. When the packets under consideration are no longer received by 99 this node due to a route change, the route is considered to have 100 changed at some upstream node, not at this node. 102 There are three cases for route change: 104 (case 1) There is no route change for this outgoing interface. An 105 example is an outgoing interface of a diffserv boundary node 106 that connects to another diffserv boundary. Since this kind of 107 link tend to be stable for a long period, we can consider that 108 there is no route change at this node. Maintenance shutdown may 109 be required, but that can be considered as a rare exception and 110 may be manually handled (for example, shutting down rsvp 111 processes on both sides). 113 (case 2) The route change may happen, but the necessary route change 114 information is provided to the rsvp process as soon as 115 possible. The information may be provided by means of routing 116 protocols or management protocols, or by measurements. In this 117 case, if the no-refresh option (Last_Refresh) [Berger] is 118 enabled and the (old) next hop has already registered an ID- 119 based state for PATH of this stream, that state must be 120 explicitly revoked. Otherwise, the state would remain there 121 forever. We will discuss this case in section 4. 123 (case 3) The route change may happen, and the necessary route change 124 information is NOT provided to the rsvp process. In this case, 125 we have to rely on the PATH refreshes. However, by exchanging 126 the ID between RSVP neighbor nodes, we can drastically reduce 127 the amount of PATH message size. We will discuss this case 128 first. 130 3. ID-only PATH refreshes 132 In (case 3), route change is detected using PATH refreshes, thus we 133 cannot eliminate PATH refreshes. In [Baker], detection of route 134 change within a domain depends on the refreshes of individual PATH 135 messages. An example of route change is shown below. Individual PATH 136 messages are not interpreted by interior nodes (Rx) but by boundary 137 nodes (ingress, egress1, egress2). 139 Before route change 141 [ingress] -----> [R1] -----> [R2] ------> [R3] -----> [egress1] 143 After route change 145 [ingress] -----> [R1] -----> [R2] ---+ 146 | 147 +--> [R4] -----> [egress2] 149 In general, the interior routing protocol does not inform the ingress 150 node of the route change at R2 (although some protocols could do so, 151 such protocols cannot be assumed in general). 153 Since the number of reservations on a DS boundary node may get large, 154 we still want the processing overhead and bandwidth overhead be small 155 to alleviate the scalability problem. 157 The ID-based refresh in [Berger] helps to quickly find a 158 corresponding state in the receiving node and to instantly check the 159 equality of the previous message and the incoming message 160 (Last_Refresh flag off). 162 In this draft, we further reduce the overhead by removing unnecessary 163 information from the PATH refresh. A PATH message with an ID consists 164 of the following elements (size is shown by the number of 4-byte 165 words). 167 Words 168 ------------------------------ 169 Common Header 2 170 INTEGRITY 0- (9 for HMAC-MD5) 171 MESSAGE_ID 2 [Berger] 172 SESSION 3 (IPv4) 173 RSVP_HOP 3 (IPv4) 175 TIME_VALUES 2 176 POLICY_DATA 0- 177 SENDER_TEMPLATE 3 (IPv4) 178 SENDER_TSPEC 9 (INTSERV) 179 ADSPEC about 21 (21 for General Param, Guaranteed Service, 180 Controlled-Load Service, no override) 182 Some objets are optional and vary in size. In particular, some 183 people has been worried that a POLICY_DATA object gets large 184 (possibly gets larger than MTU). So a PATH message could be very 185 large. 187 Now, we propose ID-only PATH refreshes. ID-only PATH refresh reduces 188 the PATH message size, once the PATH is confirmed. The ACK mechanism 189 in [Berger] is used for confirmation. ID-only PATH message looks like 190 this: 192 ::= [ ] 194 196 198 MESSAGE_ID ACK object is defined in [Berger]. The MESSAGE_REFRESH 199 object is similar to the MESSAGE_ID object in [Berger] but has a 200 different class number: 202 MESSAGE_REFRESH class 203 Class-Num is of 0bbbbbbb form (must report error if this object is 204 unknown) and should be assigned by IANA. 206 REFRESH_ID object 208 Class = MESSAGE_REFRESH class, C-Type = 1 210 +-------------+-------------+-------------+-------------+ 211 | Reserved | Message ID | 212 +-------------+-------------+-------------+-------------+ 214 Reserved: reserved and must be zero. 215 Message ID: Latest ID for this PATH state. The ID must have 216 been acknowledged by the next hop(s). 218 The IP header is the same as normal PATH messages. The IP destination 219 address is the session address. Unfortunately, since PATH REFRESH 220 messages must detect route change, PATH REFRESH messages cannot be 221 aggregated in a single message [Berger], whose destination address is 222 the address of the common next hop. 224 The recipient hop of this PATH REFRESH message must behave as if the 225 full PATH message previously received with this Message ID was 226 received, if such message was received from the same RSVP_HOP and 227 this node has sent its acknowledgement. However, this node does not 228 have to send another acknowledgment even if the original message 229 requested it. 231 In this way, the total message size is reduced significantly. If we 232 assume the numbers above, the message is reduced from 45 words to 10 233 words. If the POLICY_DATA object is very large, the reduction is more 234 effective. The smaller gets the message size, the smaller gets the 235 message handling cost. In addition, the bandwidth required for PATH 236 refreshes is reduced. 238 The rest of this section describes how route change is handled when 239 ID-only PATH refresh is used. 241 If a PATH receiving node has never heard of the Message ID from the 242 RSVP_HOP, or if this node has not send an acknowledgment for the 243 Message ID, then this node considers it detects a route change at 244 RSVP_HOP, and explicitly requests the RSVP_HOP node to send a full 245 PATH message. The request message is sent to the sending node 246 (RSVP_HOP) as follows: 248 ::= [ ] 250 [ ... ] 252 254 256 REFRESH_REQUEST object 258 Class = MESSAGE_REFRESH class, C-Type = 2 260 +-------------+-------------+-------------+-------------+ 261 | Reserved | Message ID | 262 +-------------+-------------+-------------+-------------+ 264 Reserved: reserved and must be zero. 265 Message ID: The received Message ID that should be sent 266 again in full format. 268 If a PATH sending node receives Refresh Request message with an ID 269 registered in this node, the node must send a full PATH message with 270 a newly allocated ID. 272 The PATH state in the receiving node will timeout if PATH or PATH 273 Refresh messages are not received for a long time as defined in 274 [RFC2205]. Or, it may be explicitly revoked by Invalidate ID 275 Messages described in the next section. 277 An RSVP node that does not support this extension will report a Path 278 Error when it receives a Path Refresh message, since it does not know 279 the REFRESH_ID object and its class is requesting an error report if 280 the object is unknown to the node. The SESSION and RSVP_HOP objects 281 are included in the Path Refresh Message so that such node can 282 construct a Path Error message. The PATH sending host which receives 283 a Path Error must first check if the previous PATH message was an 284 ID-only PATH, and if so, it should not forward the Path Error message 285 upstream, but should reset the ID-based state and send a full PATH 286 message. If the error reporting node only supports conventional RSVP, 287 it will not send back an acknowledgment, so the sending node 288 continues to send full PATH messages. 290 We could use Path Error in place of Refresh Request. However, we 291 provide a separate message type for easier handling. 293 The above route change handling for ID-only refreshes can also be 294 used for multicast sessions when ID-only refreshes are used. If a new 295 node joins a multicast group down-stream of a PATH sending node, and 296 the rsvp process of the PATH sending node is not informed of the 297 change, then the new node will request a full PATH message or will 298 report an error, since it receives unknown ID-only PATH refreshes. 299 The PATH sending node can try to re-establish ID-based relations with 300 all neighbor members. 302 4. Route change handling when refresh is suppressed 304 This section discusses the extension to [Berger] for previously 305 described (case 2). In this case, The route change may happen, but 306 the information on route change at this node is provided to the rsvp 307 process. With this information, the node can re-establish the PATH 308 state with a new next hop. 310 However, there is no means to revoke the old state in the old next 311 hop. We cannot use a Path Tear message for this purpose, because Path 312 Tear has the ultimate destination as its IP address and it would now 313 be routed to the new next hop. We need a message that can directly 314 reach the old next hop. To this end, we define INVALIDATE_ID RSVP 315 messages. 317 ::= [ ] 319 [ ... ] 321 323 325 INVALIDATE_ID object 327 Class = MESSAGE_REFRESH class, C-Type = 3 328 +-------------+-------------+-------------+-------------+ 329 | Reserved | Message ID | 330 +-------------+-------------+-------------+-------------+ 332 Reserved: reserved and must be zero. 333 Message ID: The Message ID that should be invalidated. 335 The host must retransmit the Invalidate ID Message until it is 336 acknowledged, or a maximum retry limit is reached (or Hello Message 337 has timed-out and all relating states are cleared). Since this 338 message must be acknowledged, the message ID for this message is 339 included in the message. 341 If a host receives an Invalidate ID Message that has a matching 342 state, the host must invalidate the state and send an acknowledgment. 343 The host must be prepared to repeatedly receive the same 344 INVALIDATE_ID messages, since the acknowledgment may be lost in the 345 network. 347 6. Possible modification to the RSVP aggregate reservation 349 The RSVP aggregate reservation proposed in [Baker] installs states in 350 DS-ingress and DS-egress boundary nodes to aggregate reservations. 351 Since this state handling is very similar to the one for ID-based 352 refreshes, reservation aggregation mechanism can relay on the ID- 353 based states. 355 In [Baker], Path Error messages with error code of NEW-AGGREGATE- 356 NEEDED are used for two purposes. One is for the ingress node to 357 identify an egress node for the session. This Path Error can be 358 replaced by an acknowledgment for the PATH message. The other is for 359 an egress node to request re-establishment of the states when it 360 receives an unknown PATH (due to route change). This Path Error can 361 be replaced by a Refresh Request message. By combining [Baker] and 362 [Berger] in this way, we can eliminate the duplicate state 363 management. 365 Security Considerations 367 No new security issues are raised in this document. See [RFC2205] for 368 a general discussion on RSVP security issues. 370 References 372 [Baker] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B., 373 "Aggregation of RSVP for IP4 and IP6 Reservations", Work In Progress, 374 draft-baker-rsvp-aggregation-00.txt, February 1999. 376 [Berger] Berger, L., Gan, D., Swallow, G., "RSVP Refresh Reduction 377 Extensions", draft-berger-rsvp-refresh-reduct-00.txt, Work In 378 Progress, March 1999. 380 [Bernet] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 381 Nichols, K., Speer, M., Braden, R., "Interoperation of RSVP/Int-Serv 382 and Diff-Serv Networks", Work In Progress, draft-ietf-diffserv-rsvp- 383 02.txt, February 1999. 385 [Pan] Pan, P., Schulzrinne, H., Guerin, R., "Staged Refresh Timers 386 for RSVP", draft-pan-rsvp-timer-00.txt, Work In Progress (already 387 expired), November 1997. 389 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 390 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 391 Specification", RFC 2205, September 1997. 393 [RFC2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol 394 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 395 1997. 397 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 398 Services", RFC 2210, September 1997. 400 [RFC2208] Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, 401 A., Weinrib, A., Zhang, L., "Resource ReSerVation Protocol (RSVP) 402 Version 1 Applicability Statement Some Guidelines on Deployment", RFC 403 2208, September 1997. 405 [RFC2215] Shenker, S., Wroclawski, J., "General Characterization 406 Parameters for Integrated Service Network Elements", RFC 2215, 407 September 1997. 409 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 410 Weiss, W., "An Architecture for Differentiated Services", RFC 2475, 411 December 1998. 413 Author's Address 415 Masanobu Yuhara 416 Fujitsu Laboratories Ltd. 417 4-1-1 Kamikodanaka, Nakahara-ku 418 Kawasaki, 211-8588, Japan 419 Phone: +81-44-777-1111 420 Email: yuhara@flab.fujitsu.co.jp 422 Mayumi Tomikawa 423 Fujitsu Laboratories Ltd. 425 4-1-1 Kamikodanaka, Nakahara-ku 426 Kawasaki, 211-8588, Japan 427 Phone: +81-44-777-1111 428 Email: ohya@flab.fujitsu.co.jp