idnits 2.17.1 draft-ietf-rsvp-refresh-reduct-04.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: ---------------------------------------------------------------------------- ** 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 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 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 2 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 2000) is 8748 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Pan' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Normative reference to a draft: ref. 'Yuhara' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lou Berger 2 Internet Draft LabN Consulting, LLC 3 Expiration Date: October 2000 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 Ping Pan 11 Bell Labs, Lucent 13 Franco Tommasi 14 Simone Molendini 15 University of Lecce 17 April 2000 19 RSVP Refresh Overhead Reduction Extensions 21 draft-ietf-rsvp-refresh-reduct-04.txt 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 To view the current status of any Internet-Draft, please check the 37 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 38 Directory, see http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes a number of mechanisms that can be used to 43 reduce processing overhead requirements of refresh messages, 44 eliminate the state synchronization latency incurred when an RSVP 45 message is lost and, when desired, refreshing state without the 46 transmission of whole refresh messages. The same extensions also 47 support reliable RSVP message delivery on a per hop basis. These 48 extension present no backwards compatibility issues. 50 Contents 52 1 Introduction and Background ............................... 3 53 1.1 Trigger and Refresh Messages .............................. 4 54 2 Refresh-Reduction-Capable Bit ............................. 5 55 3 RSVP Bundle Message ....................................... 6 56 3.1 Bundle Header ............................................. 6 57 3.2 Message Formats ........................................... 7 58 3.3 Sending RSVP Bundle Messages .............................. 8 59 3.4 Receiving RSVP Bundle Messages ............................ 9 60 4 MESSAGE_ID Extension ...................................... 9 61 4.1 Modification of Standard Message Formats .................. 10 62 4.2 MESSAGE_ID Objects ....................................... 10 63 4.3 MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................ 11 64 4.4 Ack Message Format ........................................ 12 65 4.5 MESSAGE_ID Object Usage ................................... 13 66 4.6 MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage .... 15 67 4.7 Multicast Considerations .................................. 16 68 4.7.1 Reference RSVP/Routing Interface .......................... 17 69 4.8 Compatibility ............................................. 17 70 5 Summary Refresh Extension ................................. 18 71 5.1 MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects .......... 19 72 5.2 Srefresh Message Format ................................... 25 73 5.3 Srefresh Message Usage .................................... 26 74 5.4 Srefresh NACK ............................................. 29 75 5.5 Preserving RSVP Soft State ................................ 29 76 5.6 Compatibility ............................................. 30 77 6 Reference Exponential Back-Off Procedures ................. 31 78 6.1 Outline of Operation ...................................... 31 79 6.2 Time Parameters ........................................... 31 80 6.3 Example Retransmission Algorithm .......................... 32 81 7 Acknowledgments ........................................... 32 82 8 Security Considerations ................................... 33 83 9 References ................................................ 33 84 10 Authors' Addresses ........................................ 34 85 Changes from previous version: 87 o All suggest values removed to avoid implementation confusion. 88 IANA has not responded to repeated requests for assignment. 89 o Some minor text cleanup as suggested on mailing list. 91 1. Introduction and Background 93 Standard RSVP [RFC2205] maintains state via the generation of RSVP 94 refresh messages. Refresh messages are used to both synchronize 95 state between RSVP neighbors and to recover from lost RSVP messages. 96 The use of Refresh messages to cover many possible failures has 97 resulted in a number of operational problems. One problem relates to 98 scaling, another relates to the reliability and latency of RSVP 99 Signaling. 101 The scaling problems are linked to the resource requirements (in 102 terms of processing and memory) of running RSVP. The resource 103 requirements increase proportionally with the number of sessions. 104 Each session requires the generation, transmission, reception and 105 processing of RSVP Path and Resv messages per refresh period. 106 Supporting a large number of sessions, and the corresponding volume 107 of refresh messages, presents a scaling problem. 109 The reliability and latency problem occurs when a non-refresh RSVP 110 message is lost in transmission. Standard RSVP [RFC2205] recovers 111 from a lost message via RSVP refresh messages. In the face of 112 transmission loss of RSVP messages, the end-to-end latency of RSVP 113 signaling is tied to the refresh interval of the node(s) experiencing 114 the loss. When end-to-end signaling is limited by the refresh 115 interval, the delay incurred in the establishment or the change of a 116 reservation may be beyond the range of what is acceptable for some 117 applications. 119 One way to address the refresh volume problem is to increase the 120 refresh period, "R" as defined in Section 3.7 of [RFC2205]. 121 Increasing the value of R provides linear improvement on transmission 122 overhead, but at the cost of increasing the time it takes to 123 synchronize state. 125 One way to address the reliability and latency of RSVP Signaling is 126 to decrease the refresh period R. Decreasing the value of R 127 increases the probability that state will be installed in the face of 128 message loss, but at the cost of increasing refresh message rate and 129 associated processing requirements. 131 An additional issue is the time to deallocate resources after a tear 132 message is lost. RSVP does not retransmit ResvTear or PathTear 133 messages. If the sole tear message transmitted is lost, then 134 resources will only be deallocated once the "cleanup timer" interval 135 has passed. This may result in resources being allocated for an 136 unnecessary period of time. Note that even when the refresh period 137 is adjusted, the "cleanup timer" must still expire since tear 138 messages are not retransmitted. 140 The extensions defined in this document address both the refresh 141 volume and the reliability issues with mechanisms other than 142 adjusting refresh rate. The extensions are collectively referred to 143 as the "Refresh Overhead Reduction" or the "Refresh Reduction" 144 extensions. A Bundle message is defined to reduce overall message 145 handling load. A MESSAGE_ID object is defined to reduce refresh 146 message processing by allowing the receiver to more readily identify 147 an unchanged message. A MESSAGE_ACK object is defined which can be 148 used to detect message loss and support reliable RSVP message 149 delivery on a per hop basis. A summary refresh message is defined to 150 enable refreshing state without the transmission of whole refresh 151 messages, while maintaining RSVP's ability to indicate when state is 152 lost and to adjust to changes in routing. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 1.1. Trigger and Refresh Messages 160 This document categorizes RSVP messages into two types: trigger and 161 refresh messages. Trigger messages are those RSVP messages that 162 advertise state or any other information not previously transmitted. 163 Trigger messages include messages advertising new state, a route 164 change that alters a reservation path, or a modification to an 165 existing RSVP session or reservation. Trigger messages also include 166 those messages that include changes in non-RSVP processed objects, 167 such as changes in the Policy or ADSPEC objects. 169 Refresh messages represent previously advertised state and contain 170 exactly the same objects and same information as a previously 171 transmitted message, and are sent over the same path. Only Path and 172 Resv messages can be refresh messages. Refresh messages are 173 identical to the corresponding previously transmitted message, with 174 some possible exceptions. Specifically, the checksum field, the 175 flags field and the INTEGRITY object may differ in refresh messages. 177 2. Refresh-Reduction-Capable Bit 179 To indicate support for the refresh overhead reduction extensions, an 180 additional capability bit is added to the common RSVP header, which 181 is defined in [RFC2205]. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Vers | Flags | Msg Type | RSVP Checksum | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Send_TTL | (Reserved) | RSVP Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Flags: 4 bits 193 0x01: Refresh (overhead) reduction capable 195 When set, indicates that this node is willing and capable of 196 receiving all the messages and objects described in this 197 document. This includes the Bundle message described in 198 Section 3, the MESSAGE_ID objects and Ack messages described 199 in Section 4, and the MESSAGE_ID LIST objects and Srefresh 200 message described in Section 5. This bit is meaningful only 201 between RSVP neighbors. 203 Nodes supporting the refresh overhead reduction extensions must also 204 take care to recognize when a next hop stops sending RSVP messages 205 with the Refresh-Reduction-Capable bit set. To cover this case, 206 nodes supporting the refresh overhead reduction extensions MUST 207 examine the flags field of each received RSVP message. If the flag 208 changes from indicating support to indicating non-support then, 209 unless configured otherwise, Srefresh messages (described in Section 210 5) MUST NOT be used for subsequent state refreshes to that neighbor 211 and Bundle messages (Section 3) MUST NOT be sent to that neighbor. 212 Note, a node that supports reliable RSVP message delivery (Section 4) 213 but not Bundle and Srefresh messages, will not set the Refresh- 214 Reduction-Capable bit. 216 3. RSVP Bundle Message 218 An RSVP Bundle message consists of a bundle header followed by a body 219 consisting of a variable number of standard RSVP messages. A Bundle 220 message is used to aggregate multiple RSVP messages within a single 221 PDU. The term "bundling" is used to avoid confusion with RSVP 222 reservation aggregation. The following subsections define the 223 formats of the bundle header and the rules for including standard 224 RSVP messages as part of the message. 226 3.1. Bundle Header 228 0 1 2 3 229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Vers | Flags | Msg type | RSVP checksum | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Send_TTL | (Reserved) | RSVP length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The format of the bundle header is identical to the format of the 237 RSVP common header [RFC2205]. The fields in the header are as 238 follows: 240 Vers: 4 bits 242 Protocol version number. This is version 1. 244 Flags: 4 bits 246 0x01: Refresh (overhead) reduction capable 248 See Section 2. 250 0x02-0x08: Reserved 252 Msg type: 8 bits 254 TBA = Bundle (Value not yet assigned by IANA) 256 RSVP checksum: 16 bits 258 The one's complement of the one's complement sum of the entire 259 message, with the checksum field replaced by zero for the 260 purpose of computing the checksum. An all-zero value means 261 that no checksum was transmitted. Because individual sub- 262 messages may carry their own checksum as well as the INTEGRITY 263 object for authentication, this field MAY be set to zero. Note 264 that when the checksum is not computed, the header of the 265 bundle message will not be covered by any checksum. If the 266 checksum is computed, individual sub-messages MAY set their own 267 checksum to zero. 269 Send_TTL: 8 bits 271 The IP TTL value with which the message was sent. This is used 272 by RSVP to detect a non-RSVP hop by comparing the Send_TTL with 273 the IP TTL in a received message. 275 RSVP length: 16 bits 277 The total length of this RSVP Bundle message in bytes, 278 including the bundle header and the sub-messages that follow. 280 3.2. Message Formats 282 An RSVP Bundle message must contain at least one sub-message. A sub- 283 message MAY be any message type except for another Bundle message. 285 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Vers | Flags | TBA (IANA) | RSVP checksum | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Send_TTL | (Reserved) | RSVP length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 // First sub-message // 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 // More sub-messages.. // 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 3.3. Sending RSVP Bundle Messages 303 Support for RSVP Bundle messages is optional. While message bundling 304 helps in scaling RSVP, by reducing processing overhead and bandwidth 305 consumption, a node is not required to transmit every standard RSVP 306 message in a Bundle message. A node MUST always be ready to receive 307 standard RSVP messages. 309 RSVP Bundle messages can only be sent to RSVP neighbors that support 310 bundling. Methods for discovering such information include: (1) 311 manual configuration and (2) observing the Refresh-Reduction-Capable 312 bit (see Section 2) in the received RSVP messages. RSVP Bundle 313 messages MUST NOT be used if the RSVP neighbor does not support RSVP 314 Bundle messages. 316 RSVP Bundle messages are sent hop by hop between RSVP-capable nodes 317 as "raw" IP datagrams with protocol number 46. The IP source address 318 is an address local to the system that originated the Bundle message. 319 The IP destination address is the RSVP neighbor for which the sub- 320 messages are intended. 322 RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP 323 option in their IP headers. This is because Bundle messages are 324 addressed directly to RSVP neighbors. 326 Each RSVP Bundle message MUST occupy exactly one IP datagram, which 327 is approximately 64K bytes. If it exceeds the MTU, the datagram is 328 fragmented by IP and reassembled at the recipient node. 329 Implementations may choose to limit each RSVP Bundle message to the 330 MTU size of the outgoing link, e.g. 1500 bytes. Implementations 331 SHOULD also limit the amount of time that a message is delayed in 332 order to be bundled. Different limits may be used for trigger and 333 standard refresh messages. Trigger messages SHOULD be delayed a 334 minimal amount of time. Refresh messages may be delayed up to their 335 refresh interval. Note that messages related to the same Resv or 336 Path state should not be delayed at different intervals in order to 337 preserve ordering. 339 If the RSVP neighbor is not known or changes in next hops cannot be 340 identified via routing, Bundle messages MUST NOT be used. Note that 341 when the routing next hop is not RSVP capable it will typically not 342 be possible to identify changes in next hop. 344 Any message that will be handled by the RSVP neighbor indicated in a 345 Bundle Message's destination address may be included in the same 346 message. This includes all RSVP messages that would be sent out a 347 point-to-point link. It includes any message, such as a Resv, 348 addressed to the same destination address. It also includes Path and 349 PathTear messages when the next hop is known to be the destination 350 and changes in next hops can be detected. Path and PathTear messages 351 for multicast sessions MUST NOT be sent in Bundle messages when the 352 outgoing link is not a point-to-point link or when the next hop does 353 not support the refresh overhead reduction extensions. 355 3.4. Receiving RSVP Bundle Messages 357 If the local system does not recognize or does not wish to accept a 358 Bundle message, the received messages shall be discarded without 359 further analysis. 361 The receiver next compares the Send_TTL with which a Bundle message 362 is sent to the IP TTL with which it is received. If a non-RSVP hop 363 is detected, the number of non-RSVP hops is recorded. It is used 364 later in processing of sub-messages. 366 Next, the receiver verifies the version number and checksum of the 367 RSVP Bundle message and discards the message if any mismatch is 368 found. 370 The receiver then starts decapsulating individual sub-messages. Each 371 sub-message has its own complete message length and authentication 372 information. With the exception of using the Send_TTL from the 373 header of the Bundle message, each sub-message is processed as if it 374 was received individually. 376 4. MESSAGE_ID Extension 378 Three new objects are defined as part of the MESSAGE_ID extension. 379 The objects are the MESSAGE_ID object, the MESSAGE_ID_ACK object, and 380 the MESSAGE_ID_NACK objects. The first two objects are used to 381 support acknowledgments and reliable RSVP message delivery. The last 382 object is used to support the summary refresh extension described in 383 Section 5. The MESSAGE_ID object can also be used to simply provide 384 a shorthand indication of when the message carrying the object is a 385 refresh message. Such information can be used by the receiving node 386 to reduce refresh processing requirements. 388 Message identification and acknowledgment is done on a per hop basis. 389 All types of MESSAGE_ID objects contain a message identifier. The 390 identifier MUST be unique on a per object generator's IP address 391 basis. No more than one MESSAGE_ID object may be included in an RSVP 392 message. Each message containing a MESSAGE_ID object may be 393 acknowledged via a MESSAGE_ID_ACK object, when so indicated. 394 MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggy-backed 395 in unrelated RSVP messages or in RSVP Ack messages. RSVP messages 396 carrying any of the three object types may be included in a bundle 397 message. When included, each object is treated as if it were 398 contained in a standard, non-bundled, RSVP message. 400 4.1. Modification of Standard Message Formats 402 The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be 403 included in the standard RSVP messages, as defined in [RFC2205]. 404 When included, one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects 405 MUST immediately follow the INTEGRITY object. When no INTEGRITY 406 object is present, the MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST 407 immediately follow the message or sub-message header. Only one 408 MESSAGE_ID object MAY be included in a message or sub-message and it 409 MUST follow any present MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. 410 When no MESSAGE_ID_ACK or MESSAGE_ID_NACK objects are present, the 411 MESSAGE_ID object MUST immediately follow the INTEGRITY object. When 412 no INTEGRITY object is present, the MESSAGE_ID object MUST 413 immediately follow the message or sub-message header. 415 The ordering of the ACK objects for all standard RSVP messages is: 416 [ ] 417 [ [ | ] ... ] 418 [ ] 420 4.2. MESSAGE_ID Objects 422 MESSAGE_ID Class = TBA (Value not yet assigned by IANA of form 423 0bbbbbbb) 425 MESSAGE_ID object 427 Class = MESSAGE_ID Class, C_Type = 1 429 0 1 2 3 430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Flags | Epoch | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Message_Identifier | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Flags: 8 bits 438 0x01 = ACK_Desired flag 440 Indicates that the sender requests the receiver to send an 441 acknowledgment for the message. 443 Epoch: 24 bits 445 A value that indicates when the Message_Identifier sequence has 446 reset. SHOULD be randomly generated each time a node reboots 447 or the RSVP agent is restarted. The value SHOULD NOT be the 448 same as was used when the node was last operational. This 449 value MUST NOT be changed during normal operation. 451 Message_Identifier: 32 bits 453 When combined with the message generator's IP address, the 454 Message_Identifier field uniquely identifies a message. The 455 values placed in this field change incrementally and only 456 decrease when the Epoch changes or when the value wraps. 458 4.3. MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects 460 MESSAGE_ID_ACK Class = TBA (Value not yet assigned by IANA of form 461 0bbbbbbb) 463 MESSAGE_ID_ACK object 465 Class = MESSAGE_ID_ACK Class, C_Type = 1 467 0 1 2 3 468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Flags | Epoch | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Message_Identifier | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Flags: 8 bits 477 No flags are currently defined. This field MUST be zero on 478 transmission and ignored on receipt. 480 Epoch: 24 bits 482 The Epoch field copied from the message being acknowledged. 484 Message_Identifier: 32 bits 486 The Message_Identifier field copied from the message being 487 acknowledged. 489 MESSAGE_ID_NACK object 491 Class = MESSAGE_ID_ACK Class, C_Type = 2 493 Definition is the same as the MESSAGE_ID_ACK object. 495 4.4. Ack Message Format 497 Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK 498 objects. They MUST NOT contain any MESSAGE_ID objects. Ack messages 499 are sent between neighboring RSVP nodes. The IP destination address 500 of an Ack message is the unicast address of the node that generated 501 the message(s) being acknowledged. For messages with RSVP_HOP 502 objects, such as Path and Resv messages, the address is found in the 503 RSVP_HOP object. For other messages, such as ResvConf, the 504 associated IP address is the source address in the IP header. The IP 505 source address is an address of the node that sends the Ack message. 507 The Ack message format is as follows: 509 ::= [ ] 510 | 511 [ [ | ] ... ] 513 For Ack messages, the Msg Type field of the Common Header MUST be set 514 to TBA (Value is to be assigned by IANA). 516 Section 4.6 provides guidance on when an Ack message should be used 517 and when MESSAGE_ID objects should be sent piggy-backed in other RSVP 518 messages. 520 4.5. MESSAGE_ID Object Usage 522 The MESSAGE_ID object may be included in any RSVP message other than 523 the Ack and Bundle messages. The MESSAGE_ID object is always 524 generated and processed over a single hop between RSVP neighbors. 525 The IP address of the object generator, i.e., the node that creates 526 the object, is represented in a per RSVP message type specific 527 fashion. For messages with RSVP_HOP objects, such as Path and Resv 528 messages, the generator's IP address is found in the RSVP_HOP object. 529 For other messages, such as ResvConf message, the generator's IP 530 address is the source address in the IP header. Note that MESSAGE_ID 531 objects can only be used in a Bundle sub-messages, but not in a 532 Bundle message. As is always the case with the Bundle message, each 533 sub-message is processed as if it was received individually. This 534 includes processing of MESSAGE_ID objects. 536 The Epoch field contains a generator selected value. The value is 537 used to indicate when the sender resets the values used in the 538 Message_Identifier field. On startup, a node SHOULD randomly select 539 a value to be used in the Epoch field. The node SHOULD ensure that 540 the selected value is not the same as was used when the node was last 541 operational. The value MUST NOT be changed unless the node or the 542 RSVP agent is restarted. 544 The Message_Identifier field contains a generator selected value. 545 This value, when combined with the generator's IP address, identifies 546 a particular RSVP message and the specific state information it 547 represents. The combination of Message_Identifier and Epoch can also 548 be used to detect out of order messages. When a node is sending a 549 refresh message with a MESSAGE_ID object, it SHOULD use the same 550 Message_Identifier value that was used in the RSVP message that first 551 advertised the state being refreshed. When a node is sending a 552 trigger message, the Message_Identifier value MUST have a value that 553 is greater than any other value previously used with the same Epoch 554 field value. A value is considered to have been used when it has 555 been sent in any message using the associated IP address with the 556 same Epoch field value. 558 The ACK_Desired flag is set when the MESSAGE_ID object generator 559 wants a MESSAGE_ID_ACK object sent in response to the message. Such 560 information can be used to ensure reliable delivery of RSVP messages 561 in the face of network loss. Nodes setting the ACK_Desired flag 562 SHOULD retransmit unacknowledged messages at a more rapid interval 563 than the standard refresh period until the message is acknowledged or 564 until a "rapid" retry limit is reached. Rapid retransmission rate 565 SHOULD be based on well known exponential back-off procedures. See 566 Section 6 for an example of an exponential back-off retransmission 567 approach. Suggested default values are an initial retransmission 568 timeout of 500ms, a power of 2 exponential back-off and a default 569 retry limit of 3. The ACK_Desired flag will typically be set only in 570 trigger messages. The ACK_Desired flag MAY be set in refresh 571 messages. Issues relate to multicast sessions are covered in a later 572 section. 574 Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a 575 newly received message is out of order and can be ignored. Out of 576 order messages SHOULD be ignored, i.e., silently dropped. Out of 577 order messages can be identified by examining the values in the Epoch 578 and Message_Identifier fields. To determine ordering, the received 579 Epoch value must match the value previously received from the message 580 sender. If the values differ then the receiver MUST NOT treat the 581 message as out of order. When the Epoch values match and the 582 Message_Identifier value is less than the largest value previously 583 received from the sender, then the receiver SHOULD check the value 584 previously received for the state associated with the message. This 585 check should be performed for any message that installs or changes 586 state. (Includes at least: Path, Resv, PathTear, ResvTear, PathErr 587 and ResvErr.) If no local state information can be associated with 588 the message, the receiver MUST NOT treat the message as out of order. 589 If local state can be associated with the message and the received 590 Message_Identifier value is less than the most recently received 591 value associated with the state, the message SHOULD be treated as 592 being out of order. 594 Note that the 32-bit Message_Identifier value MAY wrap. To cover the 595 wrap case, the following expression may be used to test if a newly 596 received Message_Identifier value is less than a previously received 597 value: 598 if ((int) old_id - (int) new_id > 0) { 599 new value is less than old value; 600 } 602 MESSAGE_ID objects of messages that are not out of order SHOULD be 603 used to aid in determining if the message represents new state or a 604 state refresh. Note that state is only refreshed in Path and Resv 605 messages. If the received Epoch values differs from the value 606 previously received from the message sender, the message is a trigger 607 message and the receiver MUST fully process the message. If a Path 608 or Resv message contains the same Message_Identifier value that was 609 used in the most recently received message for the same session and, 610 for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the 611 message as a state refresh. If the Message_Identifier value is 612 greater than the most recently received value, the receiver MUST 613 fully processes the message. When fully processing a Path or Resv 614 message, the receiver MUST store the received Message_Identifier 615 value as part of the local Path or Resv state for future reference. 617 Nodes receiving a non-out of order message containing a MESSAGE_ID 618 object with the ACK_Desired flag set, SHOULD respond with a 619 MESSAGE_ID_ACK object. Note that MESSAGE_ID objects received in 620 messages containing errors, i.e., are not syntactically valid, MUST 621 NOT be acknowledged. PathErr and ResvErr messages SHOULD be treated 622 as implicit acknowledgments. 624 4.6. MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage 626 The MESSAGE_ID_ACK object is used to acknowledge receipt of messages 627 containing MESSAGE_ID objects that were sent with the ACK_Desired 628 flag set. A MESSAGE_ID_ACK object MUST NOT be generated in response 629 to a received MESSAGE_ID object when the ACK_Desired flag is not set. 631 The MESSAGE_ID_NACK object is used as part of the summary refresh 632 extension. The generation and processing of MESSAGE_ID_NACK objects 633 is described in further detail in Section 5.4. 635 MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any RSVP 636 message that has an IP destination address matching the generator of 637 the associated MESSAGE_ID object. This means that the objects will 638 not typically be included in the non hop-by-hop Path, PathTear and 639 ResvConf messages. When no appropriate message is available, one or 640 more objects SHOULD be sent in an Ack message. Implementations 641 SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in standard 642 RSVP messages when possible. 644 Implementations SHOULD limit the amount of time that an object is 645 delayed in order to be piggy-backed or sent in an Ack message. 646 Different limits may be used for MESSAGE_ID_ACK and MESSAGE_ID_NACK 647 objects. MESSAGE_ID_ACK objects are used to detect link transmission 648 losses. If an ACK object is delayed too long, the corresponding 649 message will be retransmitted. To avoid such retransmission, ACK 650 objects SHOULD be delayed a minimal amount of time. A delay time 651 equal to the link transit time MAY be used. MESSAGE_ID_NACK objects 652 may be delayed an independent and longer time, although additional 653 delay increases the amount of time a desired reservation is not 654 installed. 656 4.7. Multicast Considerations 658 Path and PathTear messages may be sent to IP multicast destination 659 addresses. When the destination is a multicast address, it is 660 possible that a single message containing a single MESSAGE_ID object 661 will be received by multiple RSVP next hops. When the ACK_Desired 662 flag is set in this case, acknowledgment processing is more complex. 663 There are a number of issues to be addressed including ACK implosion, 664 number of acknowledgments to be expected and handling of new 665 receivers. 667 ACK implosion occurs when each receiver responds to the MESSAGE_ID 668 object at approximately the same time. This can lead to a 669 potentially large number of MESSAGE_ID_ACK objects being 670 simultaneously delivered to the message generator. To address this 671 case, the receiver MUST wait a random interval prior to acknowledging 672 a MESSAGE_ID object received in a message destined to a multicast 673 address. The random interval SHOULD be between zero (0) and a 674 configured maximum time. The configured maximum SHOULD be set in 675 proportion to the refresh and "rapid" retransmission interval, i.e, 676 such that the maximum time before sending an acknowledgment does not 677 result in retransmission. It should be noted that ACK implosion is 678 being addressed by spreading acknowledgments out in time, not by ACK 679 suppression. 681 A more fundamental issue is the number of acknowledgments that the 682 upstream node, i.e., the message generator, should expect. The 683 number of acknowledgments that should be expected is the same as the 684 number of RSVP next hops. In the router-to-router case, the number 685 of next hops can often be obtained from routing. When hosts are 686 either the upstream node or the next hops, the number of next hops 687 will typically not be readily available. Another case where the 688 number of RSVP next hops will typically not be known is when there 689 are non-RSVP routers between the message generator and the RSVP next 690 hops. 692 When the number of next hops is not known, the message generator 693 SHOULD only expect a single response. The result of this behavior 694 will be special retransmission handling until the message is 695 delivered to at least one next hop, then followed by standard RSVP 696 refreshes. Refresh messages will synchronize state with any next 697 hops that don't receive the original message. 699 4.7.1. Reference RSVP/Routing Interface 701 When using the MESSAGE_ID extension with multicast sessions it is 702 preferable for RSVP to obtain the number of next hops from routing 703 and to be notified when that number changes. The interface between 704 routing and RSVP is purely an implementation issue. Since RSVP 705 [RFC2205] describes a reference routing interface, a version of the 706 RSVP/routing interface updated to provide number of next hop 707 information is presented. See [RFC2205] for previously defined 708 parameters and function description. 710 o Route Query 711 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 712 Notify_flag ) 713 -> [ IncInterface, ] OutInterface_list, 714 NHops_list 716 o Route Change Notification 717 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 718 [ IncInterface, ] OutInterface_list, 719 NHops_list 721 NHops_list provides the number of multicast group members 722 reachable via each OutInterface_list entry. 724 4.8. Compatibility 726 All nodes sending messages with the Refresh-Reduction-Capable bit set 727 will support the MESSAGE_ID Extension. There are no backward 728 compatibility issues raised by the MESSAGE_ID Class with nodes that 729 do not set the Refresh-Reduction-Capable bit. The MESSAGE_ID Class 730 has an assigned value whose form is 0bbbbbbb. Per RSVP [RFC2205], 731 classes with values of this form must be rejected with an "Unknown 732 Object Class" error by nodes not supporting the class. When the 733 receiver of a MESSAGE_ID object does not support the class, a 734 corresponding error message will be generated. The generator of the 735 MESSAGE_ID object will see the error and then MUST re-send the 736 original message without the MESSAGE_ID object. In this case, the 737 message generator MAY still choose to retransmit messages at the 738 "rapid" retransmission interval. Lastly, since the MESSAGE_ID_ACK 739 class can only be issued in response to the MESSAGE_ID object, there 740 are no possible issues with this class or Ack messages. A node MAY 741 support the MESSAGE_ID Extension without supporting the other refresh 742 overhead reduction extensions. 744 5. Summary Refresh Extension 746 The summary refresh extension enables the refreshing of RSVP state 747 without the transmission of standard Path or Resv messages. The 748 benefits of the described extension are that it reduces the amount of 749 information that must be transmitted and processed in order to 750 maintain RSVP state synchronization. Importantly, the described 751 extension preserves RSVP's ability to handle non-RSVP next hops and 752 to adjust to changes in routing. This extension cannot be used with 753 Path or Resv messages that contain any change from previously 754 transmitted messages, i.e, are trigger messages. 756 The summary refresh extension builds on the previously defined 757 MESSAGE_ID extension. Only state that was previously advertised in 758 Path and Resv messages containing MESSAGE_ID objects can be refreshed 759 via the summary refresh extension. 761 The summary refresh extension uses the objects and the ACK message 762 previously defined as part of the MESSAGE_ID extension, and a new 763 Srefresh message. The new message carries a list of 764 Message_Identifier fields corresponding to the Path and Resv trigger 765 messages that established the state. The Message_Identifier fields 766 are carried in one of three Srefresh related objects. The three 767 objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST 768 object, and the MESSAGE_ID MCAST_LIST object. 770 The MESSAGE_ID LIST object is used to refresh all Resv state, and 771 Path state of unicast sessions. It is made up of a list of 772 Message_Identifier fields that were originally advertised in 773 MESSAGE_ID objects. The other two objects are used to refresh Path 774 state of multicast sessions. A node receiving a summary refresh for 775 multicast path state will at times need source and group information. 776 These two objects provide this information. The objects differ in 777 the information they contain and how they are sent. Both carry 778 Message_Identifier fields and corresponding source IP addresses. The 779 MESSAGE_ID SRC_LIST is sent in messages addressed to the session's 780 multicast IP address. The MESSAGE_ID MCAST_LIST object adds the 781 group address and is sent in messages addressed to the RSVP next hop. 782 The MESSAGE_ID MCAST_LIST is normally used on point-to-point links. 784 An RSVP node receiving an Srefresh message, matches each listed 785 Message_Identifier field with installed Path or Resv state. All 786 matching state is updated as if a normal RSVP refresh message has 787 been received. If matching state cannot be found, then the Srefresh 788 message sender is notified via a refresh NACK. 790 A refresh NACK is sent via the MESSAGE_ID_NACK object. As described 791 in the previous section, the rules for sending a MESSAGE_ID_NACK 792 object are the same as for sending a MESSAGE_ID_ACK object. This 793 includes sending MESSAGE_ID_NACK object both piggy-backed in 794 unrelated RSVP messages or in RSVP ACK messages. 796 5.1. MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects 798 MESSAGE_ID LIST object 800 MESSAGE_ID_LIST Class = TBA (Value not yet assigned by IANA of form 801 0bbbbbbb) 803 Class = MESSAGE_ID_LIST Class, C_Type = 1 805 0 1 2 3 806 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Flags | Epoch | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Message_Identifier | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | : | 813 // : // 814 | : | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Message_Identifier | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Flags: 8 bits 821 No flags are currently defined. This field MUST be zero on 822 transmission and ignored on receipt. 824 Epoch: 24 bits 826 The Epoch field from the MESSAGE_ID object corresponding to the 827 trigger message that advertised the state being refreshed. 829 Message_Identifier: 32 bits 831 The Message_Identifier field from the MESSAGE_ID object 832 corresponding to the trigger message that advertised the state 833 being refreshed. One or more Message_Identifiers may be 834 included. 836 IPv4/MESSAGE_ID SRC_LIST object 838 Class = MESSAGE_ID_LIST Class, C_Type = 2 840 0 1 2 3 841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Flags | Epoch | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Source_ | 846 | Message_Identifier_Tuple | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | : | 849 // : // 850 | : | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Source_ | 853 | Message_Identifier_Tuple | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Where a Source_Message_Identifier_Tuple consists of: 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Message_Identifier | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Source_IP_Address | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 IPv6/MESSAGE_ID SRC_LIST object 866 Class = MESSAGE_ID_LIST Class, C_Type = 3 868 0 1 2 3 869 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Flags | Epoch | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 | IPv6_Source_ | 875 | Message_Identifier_Tuple | 876 | | 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | : | 880 // : // 881 | : | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | | 884 | IPv6_Source_ | 885 | Message_Identifier_Tuple | 886 | | 887 | | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Where a IPv6 Source_Message_Identifier_Tuple consists of: 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Message_Identifier | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | 896 | IPv6 Source_IP_Address | 897 | | 898 | | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Flags: 8 bits 903 No flags are currently defined. This field MUST be zero on 904 transmission and ignored on receipt. 906 Epoch: 24 bits 908 The Epoch field from the MESSAGE_ID object corresponding to the 909 trigger message that advertised the state being refreshed. 911 Message_Identifier: 32 bits 913 The Message_Identifier field from the MESSAGE_ID object 914 corresponding to the trigger message that advertised the Path 915 state being refreshed. One or more Message_Identifiers may be 916 included. Each Message_Identifier MUST be followed by the 917 source IP address corresponding to the sender described in the 918 Path state being refreshed. 920 Source_IP_Address: 32 bits 922 The IP address corresponding to the sender of the Path state 923 being refreshed. 925 IPv4/MESSAGE_ID MCAST_LIST object 927 Class = MESSAGE_ID_LIST Class, C_Type = 4 929 0 1 2 3 930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Flags | Epoch | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Multicast_ | 935 | Message_Identifier_ | 936 | Tuple | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | : | 939 // : // 940 | : | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Multicast_ | 943 | Message_Identifier_ | 944 | Tuple | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 Where a Multicast_Message_Identifier_Tuple consists of: 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Message_Identifier | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Source_IP_Address | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Destination_IP_Address | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 IPv6/MESSAGE_ID MCAST_LIST object 959 Class = MESSAGE_ID_LIST Class, C_Type = 5 961 0 1 2 3 962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Flags | Epoch | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | | 967 | | 968 | | 969 | IPv6 Multicast_ | 970 | Message_Identifier_ | 971 | Tuple | 972 | | 973 | | 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | : | 977 // : // 978 | : | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 | | 982 | | 983 | IPv6 Multicast_ | 984 | Message_Identifier_ | 985 | Tuple | 986 | | 987 | | 988 | | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Where a IPv6 Multicast_Message_Identifier_Tuple consists of: 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Message_Identifier | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | | 997 | IPv6 Source_IP_Address | 998 | | 999 | | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | | 1002 | IPv6 Destination_IP_Address | 1003 | | 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Flags: 8 bits 1009 No flags are currently defined. This field MUST be zero on 1010 transmission and ignored on receipt. 1012 Epoch: 24 bits 1014 The Epoch field from the MESSAGE_ID object corresponding to the 1015 trigger message that advertised the state being refreshed. 1017 Message_Identifier: 32 bits 1019 The Message_Identifier field from the MESSAGE_ID object 1020 corresponding to the trigger message that advertised the Path 1021 state being refreshed. One or more Message_Identifiers may be 1022 included. Each Message_Identifier MUST be followed by the 1023 source IP address corresponding to the sender of the Path state 1024 being refreshed, and the destination IP address of the session. 1026 Source_IP_Address: 32 bits 1028 The IP address corresponding to the sender of the Path state 1029 being refreshed. 1031 Destination_IP_Address: 32 bits 1033 The destination IP address corresponding to the session of the 1034 Path state being refreshed. 1036 5.2. Srefresh Message Format 1038 Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID 1039 SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and 1040 MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh 1041 message. MESSAGE_ID SRC_LIST can not be combined in Srefresh 1042 messages with the other objects. A single Srefresh message MAY 1043 refresh both Path and Resv state. 1045 Srefresh messages carrying Message_Identifier fields corresponding to 1046 Path state are normally sent with a destination IP address equal to 1047 the address carried in the corresponding SESSION objects. The 1048 destination IP address MAY be set to the RSVP next hop when the next 1049 hop is known to be RSVP capable and either (a) the session is unicast 1050 or (b) the outgoing interface is a point-to-point link. Srefresh 1051 messages carrying Message_Identifier fields corresponding to Resv 1052 state MUST be sent with a destination IP address set to the Resv 1053 state's previous hop. 1055 Srefresh messages sent to a multicast session's destination IP 1056 address, MUST contain MESSAGE_ID SRC_LIST objects and MUST NOT 1057 include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects. 1058 Srefresh messages sent to the RSVP next hop MAY contain either or 1059 both MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST objects, but MUST NOT 1060 include any MESSAGE_ID SRC_LIST objects. 1062 The source IP address of an Srefresh message is an address of the 1063 node that generates the message. The source IP address MUST match 1064 the address associate with the MESSAGE_ID objects when they were 1065 included in a standard RSVP message. As previously mentioned, the 1066 source address associated with a MESSAGE_ID object is represented in 1067 a per RSVP message type specific fashion. For messages with RSVP_HOP 1068 objects, such as Path and Resv messages, the address is found in the 1069 RSVP_HOP object. For other messages, such as ResvConf message, the 1070 associated IP address is the source address in the IP header. 1072 Srefresh messages that are addressed to a session's destination IP 1073 address MUST be sent with the Router Alert IP option in their IP 1074 headers. Srefresh messages addressed directly to RSVP neighbors 1075 SHOULD NOT be sent with the Router Alert IP option in their IP 1076 headers. 1078 Each Srefresh message MUST occupy exactly one IP datagram. If it 1079 exceeds the MTU, the datagram is fragmented by IP and reassembled at 1080 the recipient node. Srefresh messages MAY be sent within an RSVP 1081 Bundle messages. Although this is not expected since Srefresh 1082 messages can carry a list of Message_Identifier fields within a 1083 single object. Implementations may choose to limit each Srefresh 1084 message to the MTU size of the outgoing link, e.g. 1500 bytes. 1086 The Srefresh message format is: 1088 ::= [ ] 1089 [ [ | ] ... ] 1090 [ ] 1091 | 1093 ::= | 1094 [ ] 1096 ::= 1097 [ ] 1099 For Srefresh messages, the Msg Type field of the Common Header MUST 1100 be set to TBA (Value not yet assigned by IANA). 1102 5.3. Srefresh Message Usage 1104 An Srefresh message may be generated to refresh Resv and Path state. 1105 If an Srefresh message is used to refresh some particular state, then 1106 the generation of a standard refresh message for that particular 1107 state SHOULD be suppressed. A state's refresh interval is not 1108 affected by the use of Srefresh message based refreshes. 1110 When generating an Srefresh message, a node SHOULD refresh as much 1111 Path and Resv state as is possible by including the information from 1112 as many MESSAGE_ID objects in the same Srefresh message. Only the 1113 information from MESSAGE_ID objects that meet the source and 1114 destination IP address restrictions, as described in Sections 5.2, 1115 may be included in the same Srefresh message. Identifying Resv state 1116 that can be refreshed using the same Srefresh message is fairly 1117 straightforward. Identifying which Path state may be included is a 1118 little more complex. 1120 Only state that was previously advertised in Path and Resv messages 1121 containing MESSAGE_ID objects can be refreshed via an Srefresh 1122 message. Srefresh message based refreshes must preserve the state 1123 synchronization properties of Path or Resv message based refreshes. 1124 Specifically, the use of Srefresh messages MUST NOT result in state 1125 being timed-out at the RSVP next hop. The period at which state is 1126 refreshed when using Srefresh messages MAY be shorter than the period 1127 that would be used when using Path or Resv message based refreshes, 1128 but it MUST NOT be longer. 1130 The particular approach used to trigger Srefresh message based 1131 refreshes is implementation specific. Some possibilities are 1132 triggering Srefresh message generation based on each state's refresh 1133 period or, on a per interface basis, periodically generating Srefresh 1134 messages to refresh all state that has not been refreshed within the 1135 state's refresh interval. Other approaches are also possible. A 1136 default Srefresh message generation interval of 30 seconds is 1137 suggested for nodes that do not dynamically calculate a generation 1138 interval. 1140 When generating an Srefresh message, there are two methods for 1141 identifying which Path state may be refreshed in a specific message. 1142 In both cases, the previously mentioned refresh interval and source 1143 IP address restrictions must be followed. The primary method is to 1144 include only those sessions that share the same destination IP 1145 address in the same Srefresh message. 1147 The secondary method for identifying which Path state may be 1148 refreshed within a single Srefresh message is an optimization. This 1149 method MAY be used when the next hop is known to support RSVP and 1150 when either (a) the session is unicast or (b) the outgoing interface 1151 is a point-to-point link. This method MUST NOT be used when the next 1152 hop is not known to support RSVP or when the outgoing interface is to 1153 a multi-access network and the session is to a multicast address. 1154 The use of this method MAY be administratively configured. When 1155 using this method, the destination address in the IP header of the 1156 Srefresh message is usually the next hop's address. When the use of 1157 this method is administratively configured, the destination address 1158 should be the well known group address 224.0.0.14. When the outgoing 1159 interface is a point-to-point link, all Path state associated with 1160 sessions advertised out the interface SHOULD be included in the same 1161 Srefresh message. When the outgoing interface is not a point-to- 1162 point link, all unicast session Path state SHOULD be included in the 1163 same Srefresh message. 1165 Identifying which Resv state may be refreshed within a single 1166 Srefresh message is based simply on the source and destination IP 1167 addresses. Any state that was previously advertised in Resv messages 1168 with the same IP addresses as an Srefresh message MAY be included. 1170 After identifying the Path and Resv state that can be included in a 1171 particular Srefresh message, the message generator adds to the 1172 message MESSAGE_ID information matching each identified state's 1173 previously used object. For all Resv state and for Path state of 1174 unicast sessions, the information is added to the message in a 1175 MESSAGE_ID LIST object that has a matching Epoch value. (Note only 1176 one Epoch value will be in use during normal operation.) If no 1177 matching object exists, then a new MESSAGE_ID LIST object is created. 1178 Path state of multicast sessions may be added to the same message 1179 when the destination address of the Srefresh message is the RSVP next 1180 hop and the outgoing interface is a point-to-point link. In this 1181 case the information is added to the message in a MESSAGE_ID 1182 MCAST_LIST object that has a matching Epoch value. If no matching 1183 object exists, then a new MESSAGE_ID MCAST_LIST object is created. 1184 When the destination address of the message is a multicast address, 1185 then identified information is added to the message in a MESSAGE_ID 1186 SRC_LIST object that has a matching Epoch value. If no matching 1187 object exists, then a new MESSAGE_ID SRC_LIST object is created. 1188 Once the Srefresh message is composed, the message generator 1189 transmits the message out the proper interface. 1191 Upon receiving an Srefresh message, the node MUST attempt to identify 1192 matching installed Path or Resv state. Matching is done based on the 1193 source address in the IP header of the Srefresh message, the object 1194 type and each Message_Identifier field. If matching state can be 1195 found, then the receiving node MUST update the matching state 1196 information as if a standard refresh message had been received. If 1197 matching state cannot be identified, then an Srefresh NACK MUST be 1198 generated corresponding to the unmatched Message_Identifier field. 1199 Message_Identifier fields received in MESSAGE_ID LIST objects may 1200 correspond to any Resv state or to Path state of unicast sessions. 1201 Message_Identifier fields received in MESSAGE_ID SRC_LIST or 1202 MCAST_LIST objects correspond to Path state of multicast sessions. 1204 An additional check must be performed to determine if a NACK should 1205 be generated for unmatched Message_Identifier fields associated with 1206 Path state of multicast sessions, i.e. fields that were carried in 1207 MESSAGE_ID SRC_LIST or MCAST_LIST objects. The receiving node must 1208 check to see if the node would forward data packets originated from 1209 the source corresponding to the unmatched field. This check, 1210 commonly known as an RPF check, is performed based on the source and 1211 group information carried in the MESSAGE_ID SRC_LIST and MCAST_LIST 1212 objects. In both objects the IP address of the source is listed 1213 immediately after the corresponding Message_Identifier field. The 1214 group address is listed immediately after the source IP address in 1215 MESSAGE_ID MCAST_LIST objects. The group address is the message's 1216 destination IP address when MESSAGE_ID SRC_LIST objects are used. 1217 The receiving node only generates an Srefresh NACK when the node 1218 would forward packets to the identified group from the listed sender. 1219 If the node would forward multicast data packets from a listed sender 1220 and there is a corresponding unmatched Message_Identifier field, then 1221 an appropriate Srefresh NACK MUST be generated. If the node would 1222 not forward packets to the identified group from a listed sender, a 1223 corresponding unmatched Message_Identifier field is silently ignored. 1225 5.4. Srefresh NACK 1227 Srefresh NACKs are used to indicate that a received 1228 Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or 1229 MCAST_LIST object does not match any installed state. This may occur 1230 for a number of reasons including, for example, a route change. An 1231 Srefresh NACK is encoded in a MESSAGE_ID_NACK object. When 1232 generating an Srefresh NACK, the epoch and Message_Identifier fields 1233 of the MESSAGE_ID_NACK object MUST have the same value as was 1234 received. MESSAGE_ID_NACK objects are transmitted as described in 1235 Section 4.6. 1237 Received MESSAGE_ID_NACK objects indicate that the object generator 1238 does not have any installed state matching the object. Upon 1239 receiving a MESSAGE_ID_NACK object, the receiver performs an 1240 installed Path or Resv state lookup based on the Epoch and 1241 Message_Identifier values contained in the object. If matching state 1242 is found, then the receiver MUST transmit the matching state via a 1243 standard Path or Resv message. If the receiver cannot identify any 1244 installed state, then no action is required. 1246 5.5. Preserving RSVP Soft State 1248 As discussed in [RFC2205], RSVP uses soft state to address a large 1249 class of potential errors. RSVP does this by periodically sending a 1250 full representation of installed state in Resv and Path messages. 1251 Srefresh messages are used in place of the periodic sending of 1252 standard Path and Resv refresh messages. While this provides scaling 1253 benefits and protects against common network events such as packet 1254 loss or routing change, it does not provide exactly the same error 1255 recovery properties. An example error that could potentially be 1256 recovered from via standard messages but not with Srefresh messages 1257 is internal corruption of state. This section recommends two methods 1258 that can be used to better preserve RSVP's soft state error recovery 1259 mechanism. Both mechanisms are supported using existing protocol 1260 messages. 1262 The first mechanism uses a checksum or other algorithm to detect a 1263 previously unnoticed change in internal state. This mechanism does 1264 not protect against internal state corruption. It just covers the 1265 case where a trigger message should have been sent, but was not. 1266 When sending a Path or Resv trigger message, a node should run a 1267 checksum or other algorithm, such as [MD5], over the internal state 1268 and store the result. The choice of algorithm is an administrative 1269 decision. Periodically the node should rerun the algorithm and 1270 compare the new result with the stored result. If the values differ, 1271 then a corresponding standard Path or Resv refresh message should be 1272 sent and the new value should be stored. The recomputation period 1273 should be set based on the computation resources of the node and the 1274 reliability requirements of the network. 1276 The second mechanism is simply to periodically send standard Path and 1277 Resv refresh messages. Since this mechanism uses standard refresh 1278 messages, it can recover from the same set of errors as standard 1279 RSVP. When using this mechanism, the period that standard refresh 1280 messages are sent must be longer than the interval that Srefresh 1281 messages are generated in order to gain the benefits of using the 1282 summary refresh extension. When a standard refresh message is sent, 1283 a corresponding summary refresh SHOULD NOT be sent during the same 1284 refresh period. When a node supports the periodic generation of 1285 standard refresh messages while Srefreshes are being used, the 1286 frequency of generation of standard refresh messages relative to the 1287 generation of summary refreshes SHOULD be configurable by the network 1288 administrator. 1290 5.6. Compatibility 1292 Nodes supporting the summary refresh extension advertise their 1293 support via the Refresh-Reduction-Capable bit in the RSVP message 1294 header. This enables nodes supporting the extension to detect each 1295 other. When it is not known if a next hop supports the extension, 1296 standard Path and Resv message based refreshes MUST be used. Note 1297 that when the routing next hop does not support RSVP, it will not 1298 always be possible to detect if the RSVP next hop supports the 1299 summary refresh extension. Therefore, when the routing next hop is 1300 not RSVP capable the Srefresh message based refresh SHOULD NOT be 1301 used. A node MAY be administratively configured to use Srefresh 1302 messages in all cases when all RSVP nodes in a network are known to 1303 support the summary refresh extension. This is useful since when 1304 operating in this mode, the extension properly adjusts to the case of 1305 non-RSVP next hops and changes in routing. 1307 Per section 2, nodes supporting the summary refresh extension must 1308 also take care to recognize when a next hop stops sending RSVP 1309 messages with the Refresh-Reduction-Capable bit set. 1311 6. Reference Exponential Back-Off Procedures 1313 This section is based on [Pan] and provides an example of how to 1314 implement exponential back-off for retransmission of messages 1315 awaiting acknowledgment, see Section 4.5. Implementations MAY choose 1316 to use the described procedures. 1318 6.1. Outline of Operation 1320 The following is one possible mechanism for exponential back-off 1321 retransmission of an unacknowledged RSVP message: When sending such a 1322 message, a node inserts a MESSAGE_ID object with the ACK_Desired flag 1323 set. The sending node will retransmit the message until a message 1324 acknowledgment is received or the message has been transmitted a 1325 maximum number of times. Upon reception, a receiving node 1326 acknowledges the arrival of the message by sending back a message 1327 acknowledgment (that is, a corresponding MESSAGE_ID_ACK object.) 1328 When the sending node receives the acknowledgment retransmission of 1329 the message is stopped. The interval between retransmissions is 1330 governed by a rapid retransmission timer. The rapid retransmission 1331 timer starts at a small interval and increases exponentially until it 1332 reaches a threshold. 1334 6.2. Time Parameters 1336 The described procedures make use of the following time parameters. 1337 All parameters are per interface. 1339 Rapid retransmission interval Rf: 1341 Rf is the initial retransmission interval for unacknowledged 1342 messages. After sending the message for the first time, the 1343 sending node will schedule a retransmission after Rf seconds. 1344 The value of Rf could be as small as the round trip time (RTT) 1345 between a sending and a receiving node, if known. 1347 Rapid retry limit Rl: 1349 Rl is the maximum number of times a message will be transmitted 1350 without being acknowledged. 1352 Increment value Delta: 1354 Delta governs the speed with which the sender increases the 1355 retransmission interval. The ratio of two successive 1356 retransmission intervals is (1 + Delta). 1358 6.3. Example Retransmission Algorithm 1360 After a sending node transmits a message containing a MESSAGE_ID 1361 object with the ACK_Desired flag set, it should immediately schedule 1362 a retransmission after Rf seconds. If a corresponding MESSAGE_ID_ACK 1363 object is received earlier than Rf seconds, then retransmission 1364 SHOULD be canceled. Otherwise, it will retransmit the message after 1365 (1 + Delta)*Rf seconds. The staged retransmission will continue 1366 until either an appropriate MESSAGE_ID_ACK object is received, or the 1367 rapid retry limit, Rl, has been reached. 1369 A sending node can use the following algorithm when transmitting a 1370 message containing a MESSAGE_ID object with the ACK_Desired flag set: 1372 Prior to initial transmission initialize: Rk = Rf and Rn = 0 1374 while (Rn++ < Rl) { 1375 transmit the message; 1376 wake up after Rk seconds; 1377 Rk = Rk * (1 + Delta); 1378 } 1379 /* acknowledged or no reply from receiver for too long: */ 1380 do any needed clean up; 1381 exit; 1383 Asynchronously, when a sending node receives a corresponding 1384 MESSAGE_ID_ACK object, it will change the retry count, Rn, to Rl. 1386 Note that the transmitting node does not advertise the use of the 1387 described exponential back-off procedures via the TIME_VALUE object. 1389 7. Acknowledgments 1391 This document represents ideas and comments from the MPLS-TE design 1392 team and participants in the RSVP Working Group's interim meeting. 1393 Thanks to Bob Braden, Lixia Zhang, Fred Baker, Adrian Farrel, Roch 1394 Guerin, Kireeti Kompella, David Mankins, Henning Schulzrinne, Andreas 1395 Terzis, Lan Wang and Masanobu Yuhara for specific feedback on the 1396 various versions of the document. 1398 Portions of this work are based on work done by Masanobu Yuhara and 1399 Mayumi Tomikawa [Yuhara]. 1401 8. Security Considerations 1403 No new security issues are raised in this document. See [RFC2205] 1404 for a general discussion on RSVP security issues. 1406 9. References 1408 [Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP," 1409 Global Internet'97, Phoenix, AZ, November 1997. 1410 http://www.ctr.columbia.edu/~pan/papers/timergi.ps 1412 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 1413 April 1992. 1415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1416 Requirement Levels," RFC 2119. 1418 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 1419 -- Version 1 Functional Specification", RFC 2205, 1420 September 1997. 1422 [Yuhara] Yuhara, M., Tomikawa, M. "RSVP Extensions for ID-based 1423 Refreshes," Internet Draft, 1424 draft-yuhara-rsvp-refresh-00.txt, April 1999. 1426 10. Authors' Addresses 1428 Lou Berger 1429 LabN Consulting, LLC 1430 Voice: +1 301 468 9228 1431 Email: lberger@labn.net 1433 Der-Hwa Gan 1434 Juniper Networks, Inc. 1435 385 Ravendale Drive 1436 Mountain View, CA 94043 1437 Voice: +1 650 526 8074 1438 Email: dhg@juniper.net 1440 George Swallow 1441 Cisco Systems, Inc. 1442 250 Apollo Drive 1443 Chelmsford, MA 01824 1444 Voice: +1 978 244 8143 1445 Email: swallow@cisco.com 1447 Ping Pan 1448 Bell Labs, Lucent 1449 101 Crawfords Corner Road, Room 4C-508 1450 Holmdel, NJ 07733 1451 Phone: +1 732 332 6744 1452 Email: pingpan@dnrc.bell-labs.com 1454 Franco Tommasi 1455 University of Lecce, Fac. Ingegneria 1456 Via Monteroni 73100 Lecce, ITALY 1457 Email: tommasi@ilenic.unile.it 1459 Simone Molendini 1460 University of Lecce, Fac. Ingegneria 1461 Via Monteroni 73100 Lecce, ITALY 1462 Email: molendini@ultra5.unile.it