idnits 2.17.1 draft-ietf-rsvp-refresh-reduct-01.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages 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 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RSVP Bundle messages MAY be sent to RSVP neighbors that support the message. Methods for discovering such information include: (1) manual configuration and (2) observing the Bundle-capable bit (see the description that follows) in the received RSVP messages. RSVP Bundle messages MUST not be used if the RSVP neighbor does not support RSVP Bundle messages. If the RSVP neighbor is not known or changes in next hops cannot be identified via routing, Bundle messages MUST NOT be sent. Note that when the routing next hop is not RSVP capable it will typically not be possible to identify changes in next hop. -- 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 (October 1999) is 8961 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' -- Possible downref: Normative reference to a draft: ref. 'Yuhara' Summary: 5 errors (**), 0 flaws (~~), 3 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: April 2000 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 Ping Pan 11 Bell Labs, Lucent 13 October 1999 15 RSVP Refresh Reduction Extensions 17 draft-ietf-rsvp-refresh-reduct-01.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes a number of mechanisms that reduce the 41 refresh overhead of RSVP. The extensions can be used to reduce 42 processing requirements of refresh messages, eliminate the state 43 synchronization latency incurred when an RSVP message is lost and, 44 when desired, refreshing state without the transmission of whole 45 refresh messages. The same extensions also support reliable RSVP 46 message delivery. These extension present no backwards compatibility 47 issues. 49 Contents 51 1 Introduction and Background ............................... 3 52 1.1 Trigger and Refresh Messages .............................. 4 53 2 RSVP Bundle Message ....................................... 5 54 2.1 Bundle Header ............................................. 5 55 2.2 Message Formats ........................................... 6 56 2.3 Sending RSVP Bundle Messages .............................. 7 57 2.4 Receiving RSVP Bundle Messages ............................ 8 58 2.5 Forwarding RSVP Bundle Messages ........................... 8 59 2.6 Bundle-Capable Bit ........................................ 8 60 3 MESSAGE_ID Extension ...................................... 9 61 3.1 MESSAGE_ID Objects ....................................... 10 62 3.2 MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................ 11 63 3.3 Ack Message Format ........................................ 12 64 3.4 MESSAGE_ID Object Usage ................................... 12 65 3.5 MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage .... 14 66 3.6 Multicast Considerations .................................. 15 67 3.6.1 Reference RSVP/Routing Interface .......................... 15 68 3.7 Compatibility ............................................. 16 69 4 Summary Refresh Extension ................................. 16 70 4.1 MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects .......... 18 71 4.2 Srefresh Message Format ................................... 21 72 4.3 Srefresh Message Usage .................................... 22 73 4.4 Srefresh NACK ............................................. 25 74 4.5 Compatibility ............................................. 25 75 5 Reference Exponential Back-Off Procedures ................. 26 76 5.1 Outline of Operation ...................................... 26 77 5.2 Time Parameters ........................................... 27 78 5.3 Example Retransmission Algorithm .......................... 28 79 6 Acknowledgments ........................................... 29 80 7 Security Considerations ................................... 29 81 8 References ................................................ 29 82 9 Authors' Addresses ........................................ 30 84 Changes from previous version 86 o Integrated feedback from working group chairs. 87 o No substantive changes were made to how extensions operate. 88 o Renamed Message_ID field to Message_Identifier. 89 o Broke MESSAGE_ID class into MESSAGE_ID, MESSAGE_ID_ACK and 90 MESSAGE_ID_LIST classes. 91 o Removed some text left over from previous versions and removed 92 reference to UDP encapsulation. 93 o Many other editorial and clarification related changes. 95 1. Introduction and Background 97 The resource requirements (in terms of CPU processing and memory) for 98 running RSVP on a router increases proportionally with the number of 99 sessions. Supporting a large number of sessions can present scaling 100 problems. 102 This document describes mechanisms to help alleviate one set of 103 scaling issues. RSVP Path and Resv messages must be periodically 104 refreshed to maintain state. The approach described effectively 105 reduces the volume of messages which must be periodically sent and 106 received, as well as the resources required to process refresh 107 messages. 109 The described mechanisms also address issues of latency and 110 reliability of RSVP Signaling. The latency and reliability problem 111 occurs when a non-refresh RSVP message is lost in transmission. 112 Standard RSVP [RFC2205] maintains state via the generation of RSVP 113 refresh messages. In the face of transmission loss of RSVP messages, 114 the end-to-end latency of RSVP signaling is tied to the refresh 115 interval of the node(s) experiencing the loss. When end-to-end 116 signaling is limited by the refresh interval, the establishment or 117 change of a reservation may be beyond the range of what is acceptable 118 for some applications. 120 One way to address the refresh volume problem is to increase the 121 refresh period, "R" as defined in Section 3.7 of [RFC2205]. 122 Increasing the value of R provides linear improvement on transmission 123 overhead, but at the cost of increasing the time it takes to 124 synchronize state. 126 One way to address the latency and reliability of RSVP Signaling is 127 to decrease the refresh period R. Decreasing the value of R provides 128 increased probability that state will be installed in the face of 129 message loss, but at the cost of increasing refresh message rate and 130 associated processing requirements. 132 An additional issue is the time to deallocate resources after a tear 133 message is lost. RSVP does not retransmit ResvTear or PathTear 134 messages. If the sole tear message transmitted is lost, then 135 resources will only be deallocated once the "cleanup timer" interval 136 has passed. This may result in resources being allocated for an 137 unnecessary period of time. Note that adjusting the refresh period 138 has no impact on this issues since tear messages are not 139 retransmitted. 141 The extensions defined in this document address both the refresh 142 volume and the reliability issues with mechanisms other than 143 adjusting refresh rate. A Bundle message is defined to reduce 144 overall message handling load. A MESSAGE_ID object is defined to 145 reduce refresh message processing by allowing the receiver to more 146 readily identify an unchanged message. A MESSAGE_ACK object is 147 defined which can be used to detect message loss and support reliable 148 RSVP message delivery. A summary refresh message is defined to 149 enable refreshing state without the transmission of whole refresh 150 messages, while maintaining RSVP's ability to indicate when state is 151 lost or when next hops change. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 1.1. Trigger and Refresh Messages 159 This document categorizes RSVP messages into two types: trigger and 160 refresh messages. Trigger messages are those RSVP messages that 161 advertise state or any other information not previously transmitted. 162 Trigger messages include messages advertising new state, a route 163 change that altered the reservation paths, or a reservation 164 modification by a downstream router. Trigger messages also include 165 those messages that include changes in non-RSVP processed objects, 166 such as changes in the Policy or ADSPEC objects. 168 Refresh messages represent previously advertised state and contain 169 exactly the same objects and same information as a previously 170 transmitted message, and are sent over the same path. Only Path and 171 Resv messages can be refresh messages. Refresh messages are 172 identical to the corresponding previously transmitted message, with 173 the exception of the INTEGRITY object, the flags in the MESSAGE_ID 174 object and the RSVP Checksum. The checksum, the flags and the 175 INTEGRITY object are allowed to differ in refresh messages. 177 2. RSVP Bundle Message 179 An RSVP Bundle message consists of a bundle header followed by a body 180 consisting of a variable number of standard RSVP messages. A Bundle 181 message is used to aggregated multiple RSVP messages within a single 182 PDU. The term "bundling" is used to avoid confusion with RSVP 183 reservation aggregation. The following subsections define the 184 formats of the bundle header and the rules for including standard 185 RSVP messages as part of the message. 187 2.1. Bundle Header 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Vers | Flags | Msg type | RSVP checksum | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Send_TTL | (Reserved) | RSVP length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 The format of the bundle header is identical to the format of the 198 RSVP common header [RFC2205]. The fields in the header are as 199 follows: 201 Vers: 4 bits 203 Protocol version number. This is version 1. 205 Flags: 4 bits 207 0x01: Bundle capable 209 If set, indicates to RSVP neighbors that this node is willing 210 and capable of receiving bundle messages. This bit is 211 meaningful only between adjacent RSVP neighbors. 213 0x02-0x08: Reserved 215 Msg type: 8 bits 217 12 = Bundle 219 RSVP checksum: 16 bits 221 The one's complement of the one's complement sum of the entire 222 message, with the checksum field replaced by zero for the 223 purpose of computing the checksum. An all-zero value means 224 that no checksum was transmitted. Because individual sub- 225 messages may carry their own checksum as well as the INTEGRITY 226 object for authentication, this field MAY be set to zero. If 227 the checksum is computed, individual sub-messages MAY set their 228 own checksum to zero. 230 Send_TTL: 8 bits 232 The IP TTL value with which the message was sent. This is used 233 by RSVP to detect a non-RSVP hop by comparing the IP TTL that a 234 Bundle message sent to the TTL in the received message. 236 RSVP length: 16 bits 238 The total length of this RSVP Bundle message in bytes, 239 including the bundle header and the sub-messages that follow. 241 2.2. Message Formats 243 An RSVP Bundle message must contain at least one sub-message. A sub- 244 message MAY be any message type except for another Bundle message. 246 Empty RSVP Bundle messages SHOULD NOT be sent. A Bundle message MUST 247 NOT include another RSVP Bundle message as a sub-message. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Vers | Flags | 12 | RSVP checksum | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Send_TTL | (Reserved) | RSVP length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 // First sub-message // 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 // More sub-messages.. // 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 2.3. Sending RSVP Bundle Messages 267 Support for RSVP Bundle messages is optional. While message bundling 268 helps in scaling RSVP, by reducing processing overhead and bandwidth 269 consumption, a node is not required to transmit every standard RSVP 270 message in a Bundle message. A node MUST always be ready to receive 271 standard RSVP messages. 273 RSVP Bundle messages MAY be sent to RSVP neighbors that support the 274 message. Methods for discovering such information include: (1) 275 manual configuration and (2) observing the Bundle-capable bit (see 276 the description that follows) in the received RSVP messages. RSVP 277 Bundle messages MUST not be used if the RSVP neighbor does not 278 support RSVP Bundle messages. If the RSVP neighbor is not known or 279 changes in next hops cannot be identified via routing, Bundle 280 messages MUST NOT be sent. Note that when the routing next hop is 281 not RSVP capable it will typically not be possible to identify 282 changes in next hop. 284 RSVP Bundle messages are sent hop by hop between RSVP-capable nodes 285 as "raw" IP datagrams with protocol number 46. The IP source address 286 is an address local to the system that originated the Bundle message. 287 The IP destination address is the RSVP neighbor for which the sub- 288 messages are intended. 290 RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP 291 option in their IP headers. This is because Bundle messages are 292 addressed directly to RSVP neighbors. 294 Each RSVP Bundle message MUST occupy exactly one IP datagram. If it 295 exceeds the MTU, the datagram is fragmented by IP and reassembled at 296 the recipient node. A single RSVP Bundle message MUST NOT exceed the 297 maximum IP datagram size, which is approximately 64K bytes. 298 Implementations may choose to limit each RSVP Bundle message to the 299 MTU size of the outgoing link, e.g. 1500 bytes. 301 Any message that will be handled by the RSVP neighbor indicated in a 302 Bundle Message's destination address may be included in the same 303 message. This includes all RSVP messages that would be sent out a 304 point-to-point link. It includes any message, such as a Resv, 305 addressed to the same destination address. It also includes Path and 306 PathTear messages when the next hop is know to be the destination and 307 changes in next hops can be detected. Path and PathTear messages for 308 multicast sessions MUST NOT be sent in Bundle messages when the 309 outgoing link is not a point-to-point link or when the next hop is 310 not Bundle capable. 312 2.4. Receiving RSVP Bundle Messages 314 If the local system does not recognize or does not wish to accept an 315 Bundle message, the received messages shall be discarded without 316 further analysis. 318 The receiver next compares the IP TTL with which a Bundle message is 319 sent to the TTL with which it is received. If a non-RSVP hop is 320 detected, the number of non-RSVP hops is recorded. It is used later 321 in processing of sub-messages. 323 Next, the receiver verifies the version number and checksum of the 324 RSVP Bundle message and discards the message if any mismatch is 325 found. 327 The receiver then starts decapsulating individual sub-messages. Each 328 sub-message has its own complete message length and authentication 329 information. Each sub-message is processed as if it was received 330 individually. 332 2.5. Forwarding RSVP Bundle Messages 334 When an RSVP router receives a Bundle messages which is not addressed 335 to one of it's IP addresses, it SHALL forward the message. Non-RSVP 336 routers will treat RSVP Bundle messages as any other IP datagram. 338 2.6. Bundle-Capable Bit 340 To support message bundling, an additional capability bit is added to 341 the common RSVP header, which is defined in [RFC2205]. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Vers | Flags | Msg Type | RSVP Checksum | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Send_TTL | (Reserved) | RSVP Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Flags: 4 bits 352 0x01: Bundle capable 354 When set, indicates to that this node is willing and capable 355 of receiving Bundle messages. This bit is meaningful only 356 between RSVP neighbors. 358 3. MESSAGE_ID Extension 360 Three new objects are defined as part of the MESSAGE_ID extension. 361 The objects are the MESSAGE_ID object, the MESSAGE_ID_ACK object, and 362 the MESSAGE_ID_NACK objects. The first two objects are used to 363 support acknowledgments and reliable RSVP message delivery. The last 364 object is used to support the summary refresh extension described in 365 Section 4. The MESSAGE_ID object can also be used to simply provide 366 a shorthand indication of when a message represents new state. Such 367 information can be used on the receiving node to reduce refresh 368 processing requirements. 370 Message identification and acknowledgment is done on a hop-by-hop 371 basis. Acknowledgment is handled independent of SESSION or message 372 type. Both types of MESSAGE_ID objects contain a message identifier. 373 The identifier MUST be unique on a per source IP address basis across 374 messages sent by an RSVP node and received by a particular node. No 375 more than one MESSAGE_ID object may be included in an RSVP message. 376 Each message containing an MESSAGE_ID object may be acknowledged via 377 a MESSAGE_ID_ACK object. MESSAGE_ID_ACK and MESSAGE_ID_NACK objects 378 may be sent piggy-backed in unrelated RSVP messages or in RSVP Ack 379 messages. 381 All three object types may be included in a bundle sub-message. When 382 included, the object is treated as if it were contained in a 383 standard, non-bundled, RSVP message. When present, one or more 384 MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST immediately follow the 385 INTEGRITY object. When no INTEGRITY object is present, the 386 MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST immediately follow the 387 message or sub-message header. Only one MESSAGE_ID object MAY be 388 included in a message or sub-message and it MUST follow any present 389 MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. When no MESSAGE_ID_ACK or 390 MESSAGE_ID_NACK objects are present, the MESSAGE_ID object MUST 391 immediately follow the INTEGRITY object. When no INTEGRITY object is 392 present, the MESSAGE_ID object MUST immediately follow the message or 393 sub-message header. 395 The ordering of the ACK objects are: 396 [ ] 397 [ | ... ] 398 [ ] 400 3.1. MESSAGE_ID Objects 402 MESSAGE_ID Class = 166 (Value to be assigned by IANA of form 403 10bbbbbb) 405 MESSAGE_ID object 407 Class = MESSAGE_ID Class, C_Type = 1 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Flags | Epoch | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Message_Identifier | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Flags: 8 bits 419 0x80 = Summary_Capable flag 421 Indicates that the sender supports the summary refresh 422 extension. This flag MUST be set if the node supports the 423 summary refresh extension. See Section 4.5 for description 424 of handling by receiver. 426 0x40 = ACK_Desired flag 428 Indicates that the sender requests the receiver to send an 429 acknowledgment for the message. 431 Epoch: 24 bits 433 A value that indicates when the Message_Identifier sequence has 434 reset. SHOULD be randomly generated each time a node reboots. 435 This value MUST NOT be changed during normal operation. 437 Message_Identifier: 32 bits 439 When combined with the message generator's IP address, the 440 Message_Identifier field uniquely identifies a message. This 441 field is ordered and only decreases in value when the Epoch 442 changes or the value wraps. 444 3.2. MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects 446 MESSAGE_ID_ACK Class = 167 (Value to be assigned by IANA of form 447 10bbbbbb) 449 MESSAGE_ID_ACK object 451 Class = MESSAGE_ID_ACK Class, C_Type = 1 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | Epoch | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Message_Identifier | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Flags: 8 bits 463 0x80 = Summary_Capable flag 465 Indicates that the sender supports the summary refresh 466 extension. This flag MUST be set if the node supports the 467 summary refresh extension. See Section 4.5 for description 468 of handling by receiver. 470 Epoch: 24 bits 472 The Epoch field copied from the message being acknowledged. 474 Message_Identifier: 32 bits 476 The Message_Identifier field copied from the message being 477 acknowledged. 479 MESSAGE_ID_NACK object 481 Class = MESSAGE_ID_ACK Class, C_Type = 2 483 Definition same as MESSAGE_ID_ACK object. 485 3.3. Ack Message Format 487 Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK 488 objects. They MUST NOT contain any MESSAGE_ID objects. Ack messages 489 are sent hop-by-hop between RSVP nodes. The IP destination address 490 of an Ack message is the unicast address of the node that generated 491 the message(s) being acknowledged. For messages with RSVP_HOP 492 objects, such as Path and Resv messages, the address is found in the 493 RSVP_HOP object. For other messages, such as ResvConf and Bundle 494 messages, the associated IP address is the source address in the IP 495 header. The IP source address is an address of the node that sends 496 the Ack message. 498 The Ack message format is as follows: 500 ::= [ ] 501 | 502 [ ... ] 503 [ ... ] 505 For Ack messages, the Msg Type field of the Common Header MUST be set 506 to 13 (This is a suggested value, the permanent value is to be 507 assigned by IANA). 509 3.4. MESSAGE_ID Object Usage 511 The MESSAGE_ID object may be included in any RSVP message other than 512 the Ack message. The MESSAGE_ID object is always generated and 513 processed hop-by-hop. The IP address of the object generator, i.e., 514 the node that creates the object, is represented in a per RSVP 515 message type specific fashion. For messages with RSVP_HOP objects, 516 such as Path and Resv messages, the generator's IP address is found 517 in the RSVP_HOP object. For other messages, such as ResvConf and 518 Bundle messages, the generator's IP address is the source address in 519 the IP header. Note that MESSAGE_ID objects can be used in both a 520 Bundle message and its sub-messages. As is always the case with the 521 Bundle message, each sub-message is processed as if it was received 522 individually. This includes processing of MESSAGE_ID objects. 524 The Epoch field contains a generator selected value. The value is 525 used to indicate when the sender resets the values used in the 526 Message_Identifier field. This information is used by the receiver 527 to detect out of order messages. On startup, a node SHOULD randomly 528 select a value to be used in the Epoch field. The node SHOULD ensure 529 that the selected value is not the same as was used when the node was 530 last operational. The value MUST NOT be changed unless the node or 531 the RSVP agent is restarted. 533 The Message_Identifier field contains a generator selected value. 534 This value, when combined with the generator's IP address, identifies 535 a particular RSVP message and the specific state information it 536 represents. When a node is sending a refresh message with a 537 MESSAGE_ID object, it SHOULD use the same Message_Identifier value 538 that was used in the RSVP message that first advertised the state 539 being refreshed. When a node is sending a trigger message, the 540 Message_Identifier value MUST have a value that is greater than any 541 other previously used value. A value is considered to have been used 542 when it has been sent in any message using the associated IP address. 543 Note that this 32-bit value MAY wrap. 545 The ACK_Desired flag is set when the MESSAGE_ID object generator 546 wants a MESSAGE_ID_ACK object sent in response to the message. Such 547 information can be used to ensure reliable delivery of error and 548 confirm messages and to support fast refreshes in the face of network 549 loss. Nodes setting the ACK_Desired flag SHOULD retransmit 550 unacknowledged messages at a more rapid interval than the standard 551 refresh period until the message is acknowledged or until a "rapid" 552 retry limit is reached. Rapid retransmission rate SHOULD be based on 553 well known exponential back-off procedures. See Section 5 for 554 details on one exponential back-off retransmission approach. Note 555 that nodes setting the ACK_Desired flag for unicast sessions, do not 556 need to track the identify of the next hop since all that is expected 557 is an ACK, not an ACK from a specific next hop. Issues relate to 558 multicast sessions are covered in a later section. The ACK_Desired 559 flag will typically be set only in trigger messages. The ACK_Desired 560 flag MAY be set in refresh messages. 562 Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a 563 newly received message is out of order and can be ignored. Out of 564 order messages SHOULD be ignored, i.e., silently dropped. Out of 565 order messages can be identified by examining the values in the Epoch 566 and Message_Identifier fields. To determine ordering, the received 567 Epoch value must match the value previously received from the message 568 sender. If the values differ then the receiver MUST NOT treat the 569 message as out of order. When the Epoch values match and the 570 Message_Identifier value is less than the largest value previously 571 received from the sender, then the receiver SHOULD check the value 572 previously received for the state associated with the message. This 573 check should be performed for any message that installs or changes 574 state. (Includes at least: Path, Resv, PathTear, ResvTear, PathErr 575 and ResvErr.) If no local state information can be associated with 576 the message, the receiver MUST NOT treat the message as out of order. 577 If local state can be associated with the message and the received 578 Message_Identifier value is less than the most recently received 579 value associated with the state, the message SHOULD be treated as 580 being out of order. 582 MESSAGE_ID objects of messages that are not out of order SHOULD be 583 used to aid in determining if the message represents new state or a 584 state refresh. Note that state is only refreshed in Path and Resv 585 messages. If the received Epoch values differs from the value 586 previously received from the message sender, the message is a trigger 587 message and the receiver MUST fully processes the message. If a Path 588 or Resv message contains the same Message_Identifier value that was 589 used in the most recently received message for the same session and, 590 for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the 591 message as a state refresh. If the Message_Identifier value is 592 greater than the most recently received value, the receiver MUST 593 fully processes the message. When fully processing a Path or Resv 594 message, the receiver MUST store the received Message_Identifier 595 value as part of the local Path or Resv state for future reference. 597 Nodes receiving a non-out of order message containing a MESSAGE_ID 598 object with the ACK_Desired flag set, SHOULD respond with a 599 MESSAGE_ID_ACK object. Note that MESSAGE_ID objects received in 600 messages containing errors, i.e., are not syntactically valid, MUST 601 NOT be acknowledged. PathErr and ResvErr messages SHOULD be treated 602 as implicit acknowledgments. 604 3.5. MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage 606 The MESSAGE_ID_ACK object is used to acknowledge receipt of messages 607 containing MESSAGE_ID objects that were sent with the ACK_Desired 608 flag set. A MESSAGE_ID_ACK object MUST NOT be generated in response 609 to a received MESSAGE_ID object when the ACK_Desired flag is not set. 611 The MESSAGE_ID_NACK object is used as part of the summary refresh 612 extension. The generation and processing of received MESSAGE_ID_NACK 613 objects is described in further detail in Section 4.4. 615 MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any RSVP 616 message that has an IP destination address matching the generator of 617 the associated MESSAGE_ID object. This means that the objects will 618 not typically be included in the non hop-by-hop Path, PathTear and 619 ResvConf messages. When no appropriate message is available, one or 620 more objects SHOULD be sent in an Ack message. Implementations 621 SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in standard 622 RSVP messages when possible. 624 3.6. Multicast Considerations 626 Path and PathTear messages may be sent to IP multicast destination 627 addresses. When the destination is a multicast address, it is 628 possible that a single message containing a single MESSAGE_ID object 629 will be received by multiple RSVP next hops. When the ACK_Desired 630 flag is set in this case, acknowledgment processing is more complex. 631 There are a number of issues to be addressed including ACK implosion, 632 number acknowledgments to be expected and handling of new receivers. 634 ACK implosion occurs when each receiver responds to the MESSAGE_ID 635 object at approximately the same time. This can lead to a 636 potentially large number of MESSAGE_ID_ACK objects being 637 simultaneously delivered to the message generator. To address this 638 case, the receiver MUST wait a random interval prior to acknowledging 639 a MESSAGE_ID object received in a message destined to a multicast 640 address. The random interval SHOULD be between zero (0) and a 641 configured maximum time. The configured maximum SHOULD be set in 642 proportion to the refresh and "rapid" retransmission interval, i.e, 643 such that the maximum back-off time does not result in 644 retransmission. 646 A more fundamental issue is the number of acknowledgments that the 647 upstream node, i.e., the message generator, should expect. The 648 number of acknowledgments that should be expected is the same as the 649 number of RSVP next hops. In the router-to-router case, the number 650 of next hops can usually be obtained from routing. When hosts are 651 either the upstream node or the next hops, the number of next hops 652 will typically not be readily available. Another case where the 653 number of RSVP next hops will typically not be known is when there 654 are non-RSVP routers between the message generator and the RSVP next 655 hops. 657 When the number of next hops is not known, the message generator 658 SHOULD only expect a single response. The result of this behavior 659 will be special retransmission handling until the message is 660 delivered to at least one next hop, then followed by standard RSVP 661 refreshes. Refresh messages will synchronize state with any next 662 hops that don't receive the original message. 664 3.6.1. Reference RSVP/Routing Interface 666 When using the MESSAGE_ID extension with multicast sessions it is 667 preferable for RSVP to obtain the number of next hops from routing 668 and to be notified when that number changes. The interface between 669 routing and RSVP is purely an implementation issue. Since RSVP 670 [RFC2205] describes a reference routing interface, a version of the 671 RSVP/routing interface updated to provide number of next hop 672 information is presented. See [RFC2205] for previously defined 673 parameters and function description. 675 o Route Query 676 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 677 Notify_flag ) 678 -> [ IncInterface, ] OutInterface_list, 679 NHops_list 681 o Route Change Notification 682 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 683 [ IncInterface, ] OutInterface_list, 684 NHops_list 686 NHops_list provides the number of multicast group members 687 reachable via each OutInterface_list entry. 689 3.7. Compatibility 691 There are no backward compatibility issues raised by the MESSAGE_ID 692 Class. The MESSAGE_ID Class has an assigned value whose form is 693 10bbbbbb. Per RSVP [RFC2205], classes with values of this form must 694 be ignored and not forwarded by nodes not supporting the class. When 695 the receiver of a MESSAGE_ID object does not support the class, the 696 object will be silently ignored. The generator of the MESSAGE_ID 697 object will not see any acknowledgments and therefore refresh 698 messages per standard RSVP. Lastly, since the MESSAGE_ID_ACK class 699 can only be issued in response to the MESSAGE_ID object, there are no 700 possible issues with this class or Ack messages. 702 4. Summary Refresh Extension 704 The summary refresh extension enables the refreshing of RSVP state 705 without the transmission of standard Path or Resv messages. The 706 benefits of the described extension are that it reduces the amount of 707 information that must be transmitted and processed in order to 708 maintain RSVP state synchronization. Importantly, the described 709 extension preserves RSVP's ability to handle non-RSVP next hops and 710 to adjust to changes in routing. This extension cannot be used with 711 Path or Resv messages that contain any change from previously 712 transmitted messages, i.e, are trigger messages. 714 The summary refresh extension builds on the previously defined 715 MESSAGE_ID extension. Only state that was previously advertised in 716 Path and Resv messages containing MESSAGE_ID objects can be refreshed 717 via the summary refresh extension. 719 The summary refresh extension uses the objects and the ACK message 720 previously defined as part of the MESSAGE_ID extension, and a new 721 Srefresh message. The new message carries a list of 722 Message_Identifier fields corresponding to the Path and Resv trigger 723 messages that established the state. The Message_Identifier fields 724 are carried in one of three Srefresh related objects. The three 725 objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST 726 object, and the MESSAGE_ID MCAST_LIST object. 728 The MESSAGE_ID LIST object is used to refresh all Resv state, and 729 Path state of unicast sessions. It is made up of a list of 730 Message_Identifier fields that were originally advertised in 731 MESSAGE_ID objects. The other two objects are used to refresh Path 732 state of multicast sessions. A node receiving a summary refresh for 733 multicast path state will at times need source and group information. 734 These two objects provide this information. The objects differ in 735 the information they contain and how they are sent. Both carry 736 Message_Identifier fields and corresponding source IP addresses. The 737 MESSAGE_ID SRC_LIST is sent in messages addressed to the session's 738 multicast IP address. The MESSAGE_ID MCAST_LIST object adds the 739 group address and is sent in messages addressed to the RSVP next hop. 740 The MESSAGE_ID MCAST_LIST may only used on point-to-point links. 742 An RSVP node receiving an Srefresh message, matches each listed 743 Message_Identifier field with installed Path or Resv state. All 744 matching state is updated as if a normal RSVP refresh message has 745 been received. If matching state cannot be found, then the Srefresh 746 message sender is notified via a refresh NACK. 748 A refresh NACK is sent via the MESSAGE_ID_NACK object. As described 749 in the previous section, the rules for sending a MESSAGE_ID_NACK 750 object are the same as for sending a MESSAGE_ID_ACK object. This 751 includes sending MESSAGE_ID_NACK object both piggy-backed in 752 unrelated RSVP messages or in RSVP ACK messages. 754 Nodes supporting the described extension can advertise their support 755 and detect if an RSVP neighbor also supports the extension. This is 756 accomplished via a flag in the MESSAGE_ID and MESSAGE_ID_ACK objects. 758 4.1. MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects 760 MESSAGE_ID LIST object 762 MESSAGE_ID_ACK Class = TBD (Value to be assigned by IANA of form 763 0bbbbbbb) 765 Class = MESSAGE_ID_LIST Class, C_Type = 1 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Flags | Epoch | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Message_Identifier | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | : | 775 // : // 776 | : | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Message_Identifier | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Flags: 8 bits 783 No flags are currently defined. This field MUST be zero on 784 transmission and ignored on receipt. 786 Epoch: 24 bits 788 The Epoch field from the MESSAGE_ID object corresponding to the 789 trigger message that advertised the state being refreshed. 791 Message_Identifier: 32 bits 793 The Message_Identifier field from the MESSAGE_ID object 794 corresponding to the trigger message that advertised the state 795 being refreshed. A variable number of Message_Identifiers may 796 be included. 798 MESSAGE_ID SRC_LIST object 800 Class = MESSAGE_ID_LIST Class, C_Type = 2 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Flags | Epoch | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Source_ | 808 | Message_Identifier_Tuple | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | : | 811 // : // 812 | : | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Source_ | 815 | Message_Identifier_Tuple | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Where a Source_Message_Identifier_Tuple consists of: 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Message_Identifier | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Source_IP_Address | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Flags: 8 bits 828 No flags are currently defined. This field MUST be zero on 829 transmission and ignored on receipt. 831 Epoch: 24 bits 833 The Epoch field from the MESSAGE_ID object corresponding to the 834 trigger message that advertised the state being refreshed. 836 Message_Identifier: 32 bits 838 The Message_Identifier field from the MESSAGE_ID object 839 corresponding to the trigger message that advertised the Path 840 state being refreshed. A variable number of 841 Message_Identifiers may be included. Each Message_Identifier 842 MUST be followed by the source IP address corresponding to the 843 sender of the Path state being refreshed. 845 Source_IP_Address: 32 bits 847 The IP address corresponding to the sender of the Path state 848 being refreshed. 850 MESSAGE_ID MCAST_LIST object 852 Class = MESSAGE_ID_LIST Class, C_Type = 3 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Flags | Epoch | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Multicast_ | 860 | Message_Identifier_ | 861 | Tuple | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | : | 864 // : // 865 | : | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Multicast_ | 868 | Message_Identifier_ | 869 | Tuple | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 Where a Multicast_Message_Identifier_Tuple consists of: 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Message_Identifier | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Source_IP_Address | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Destination_IP_Address | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Flags: 8 bits 884 No flags are currently defined. This field MUST be zero on 885 transmission and ignored on receipt. 887 Epoch: 24 bits 889 The Epoch field from the MESSAGE_ID object corresponding to the 890 trigger message that advertised the state being refreshed. 892 Message_Identifier: 32 bits 894 The Message_Identifier field from the MESSAGE_ID object 895 corresponding to the trigger message that advertised the Path 896 state being refreshed. A variable number of 897 Message_Identifiers may be included. Each Message_Identifier 898 MUST be followed by the source IP address corresponding to the 899 sender of the Path state being refreshed, and the destination 900 IP address of the session. 902 Source_IP_Address: 32 bits 904 The IP address corresponding to the sender of the Path state 905 being refreshed. 907 Destination_IP_Address: 32 bits 909 The destination IP address corresponding to the session of the 910 Path state being refreshed. 912 4.2. Srefresh Message Format 914 Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID 915 SRC_LIST, and MESSAGE_ID MCAST_LIST objects. MESSAGE_ID LIST and 916 MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh 917 message. MESSAGE_ID SRC_LIST can not be combined in Srefresh 918 messages with the other objects. A single Srefresh message MAY 919 refresh both Path and Resv state. 921 Srefresh messages carrying Message_Identifier fields corresponding to 922 Path state are normally sent with a destination IP address equal to 923 the address carried in the corresponding SESSION objects. The 924 destination IP address MAY be set to the RSVP next hop when the next 925 hop is known to be RSVP capable and either (a) the session is unicast 926 or (b) the outgoing interface is a point-to-point link. Srefresh 927 messages carrying Message_Identifier fields corresponding to Resv 928 state MUST be sent with a destination IP address set to the Resv 929 state's previous hop. 931 Srefresh messages sent to a multicast destination, MUST contain 932 MESSAGE_ID SRC_LIST objects and MUST NOT include any MESSAGE_ID LIST 933 or MESSAGE_ID MCAST_LIST objects. Srefresh messages sent to the RSVP 934 next hop MAY contain either or both MESSAGE_ID LIST and MESSAGE_ID 935 MCAST_LIST objects, but MUST NOT include any MESSAGE_ID SRC_LIST 936 objects. 938 The source IP address of an Srefresh message is an address of the 939 node that generates the message. The source IP address MUST match 940 the addressed associate with the MESSAGE_ID objects when they were 941 included in a standard RSVP message. As previously mentioned, the 942 source address associate with a MESSAGE_ID object is represented in a 943 per RSVP message type specific fashion. For messages with RSVP_HOP 944 objects, such as Path and Resv messages, the address is found in the 945 RSVP_HOP object. For other messages, such as ResvConf and Bundle 946 messages, the associated IP address is the source address in the IP 947 header. 949 Srefresh messages that are addressed to a session's destination IP 950 address MUST be sent the Router Alert IP option in their IP headers. 951 Srefresh messages addressed directly to RSVP neighbors SHOULD NOT be 952 sent with the Router Alert IP option in their IP headers. 954 Each Srefresh message MUST occupy exactly one IP datagram. If it 955 exceeds the MTU, the datagram is fragmented by IP and reassembled at 956 the recipient node. Srefresh messages MAY be sent within an RSVP 957 aggregate messages. Although this is not expected since Srefresh 958 messages can carry a list of Message_Identifier fields within a 959 single object. Implementations may choose to limit each Srefresh 960 message to the MTU size of the outgoing link, e.g. 1500 bytes. 962 The Srefresh message format is: 964 ::= [ ] 965 | 967 ::= | 968 [ ] 970 ::= 971 [ ... ] 973 For Srefresh messages, the Msg Type field of the Common Header MUST 974 be set to 15 (This is a suggested value, the permanent value is to be 975 assigned by IANA). 977 4.3. Srefresh Message Usage 979 An Srefresh message may be generated to refresh Resv and Path state. 980 If an Srefresh message is used to refresh some particular state, then 981 the generation of a standard refresh message SHOULD be suppressed. A 982 state's refresh interval is not affected by the use of Srefresh 983 message based refreshes. An Srefresh message MUST NOT be used in 984 place of a trigger Path or Resv message, i.e., one that would 985 advertise a state change. 987 When generating an Srefresh message, a node SHOULD refresh as much 988 Path and Resv state as is possible by including the information from 989 as many MESSAGE_ID objects in the same Srefresh message. Only the 990 information from MESSAGE_ID objects that meet the source and 991 destination IP address restrictions, as described in Sections 4.2, 992 may be included in the same Srefresh message. Identifying Resv state 993 that can refreshed using the same Srefresh message is fairly 994 straightforward. Identifying which Path state may be included is a 995 little more complex. 997 Independent of the state being refreshed, only state that was 998 previously advertised in Path and Resv messages containing MESSAGE_ID 999 objects can be refreshed via an Srefresh message. Srefresh message 1000 based refreshes must preserve the state synchronization properties of 1001 Path or Resv message based refreshes. Specifically, the use of 1002 Srefresh messages MUST NOT result in state being timed-out at the 1003 RSVP next hop. The period at which state is refreshed when using 1004 Srefresh messages MAY be shorter than the period that would be used 1005 when using Path or Resv message based refreshes, but it MUST NOT be 1006 longer. 1008 The particular approach used to trigger Srefresh message based 1009 refreshes is implementation specific. Some possibilities are 1010 triggering Srefresh message generation based on each state's refresh 1011 period or, on a per interface basis, periodically generating Srefresh 1012 messages to refresh all state that has not been refreshed within the 1013 state's refresh interval. Other approaches are also possible. 1015 When generating an Srefresh message, there are two methods for 1016 identifying which Path state may be refreshed in a specific message. 1017 In both cases, the previously mentioned refresh interval and source 1018 IP address restrictions must be followed. The primary method is to 1019 include only those sessions that share the same destination IP 1020 address in the same Srefresh message. 1022 The secondary method for identifying which Path state may be 1023 refreshed within a single Srefresh message is an optimization. This 1024 method MAY be used when the next hop is known to support RSVP and 1025 when either (a) the session is unicast or (b) the outgoing interface 1026 is a point-to-point link. This method MUST NOT be used when the next 1027 hop is not known to support RSVP or when the outgoing interface is to 1028 a multi-access network and the session is to a multicast address. 1029 When using this method, the destination address in the IP header of 1030 the Srefresh message is always the next hop's address. When the 1031 outgoing interface is a point-to-point link, all Path state 1032 associated with sessions advertised out the interface SHOULD be 1033 included in the same Srefresh message. When the outgoing interface 1034 is not a point-to-point link, all unicast session Path state SHOULD 1035 be included in the same Srefresh message. 1037 Identifying which Resv state may be refreshed within a single 1038 Srefresh message is based simply on the source and destination IP 1039 addresses. Any state that was previously advertised in Resv messages 1040 with the same IP addresses as an Srefresh message MAY be included. 1042 After identifying the Path and Resv state that can be included in a 1043 particular Srefresh message, the message generator adds to the 1044 message MESSAGE_ID information matching each identified state's 1045 previously used object. For all Resv state and for Path state of 1046 unicast sessions, the information is added to the message in an 1047 MESSAGE_ID LIST object that has a matching Epoch value. If no 1048 matching object exists, then a new MESSAGE_ID LIST object is created. 1049 Path state of multicast sessions may be added to the same message 1050 when the destination address of the Srefresh message is the RSVP next 1051 hop and the outgoing interface is a point-to-point link. In this 1052 case the information is added to the message in an MESSAGE_ID 1053 MCAST_LIST object that has a matching Epoch value. If no matching 1054 object exists, then a new MESSAGE_ID MCAST_LIST object is created. 1055 When the destination address of the message is a multicast address, 1056 then identified information is added to the message in an MESSAGE_ID 1057 SRC_LIST object that has a matching Epoch value. If no matching 1058 object exists, then a new MESSAGE_ID SRC_LIST object is created. 1059 Once the Srefresh message is composed, the message generator 1060 transmits the message out the proper interface. 1062 Upon receiving an Srefresh message, the node MUST attempt to identify 1063 matching installed Path or Resv state. Matching is done based on the 1064 source address in the IP header of the Srefresh message, the object 1065 type and each Message_Identifier field. If matching state can be 1066 found, then the receiving node MUST update the matching state 1067 information as if a standard refresh message had been received. If 1068 matching state cannot be identified, then an Srefresh NACK MUST be 1069 generated corresponding to the unmatched Message_Identifier field. 1070 Message_Identifier fields received in MESSAGE_ID LIST objects may 1071 correspond to any Resv state or to Path state of unicast sessions. 1072 Message_Identifier fields received in MESSAGE_ID SRC_LIST or 1073 MCAST_LIST objects correspond to Path state of multicast sessions. 1075 An additional check must be performed to determine if a NACK should 1076 be generated for unmatched Message_Identifier fields associated with 1077 Path state of multicast sessions, i.e. fields that were carried in 1078 MESSAGE_ID SRC_LIST or MCAST_LIST objects. The receiving node must 1079 check to see if the node would forward data packets originated from 1080 the source corresponding to the unmatched field. This check, 1081 commonly known as an RPF check, is performed based on the source and 1082 group information carried in the MESSAGE_ID SRC_LIST and MCAST_LIST 1083 objects. In both objects the IP address of the source is listed 1084 immediately after the corresponding Message_Identifier field. The 1085 group address is listed immediately after the source IP address in 1086 MESSAGE_ID MCAST_LIST objects. The group address is the message's 1087 destination IP address when MESSAGE_ID SRC_LIST objects are used. 1088 The receiving node only generates an Srefresh NACK when the node 1089 would forward packets to the identified group from the listed sender. 1090 If the node would forward multicast data packets from a listed sender 1091 and there is a corresponding unmatched Message_Identifier field, then 1092 an appropriate Srefresh NACK MUST be generated. If the node would 1093 not forward packets to the identified group from a listed sender, a 1094 corresponding unmatched Message_Identifier field is silently ignored. 1096 4.4. Srefresh NACK 1098 Srefresh NACKs are used to indicated that a received 1099 Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or 1100 MCAST_LIST object does not match any installed state. This may occur 1101 for a number of reasons including, for example, a route change. An 1102 Srefresh NACK is encoded in a MESSAGE_ID_NACK object. When 1103 generating an Srefresh NACK, the epoch and Message_Identifier fields 1104 of the MESSAGE_ID_NACK object MUST have the same value as was 1105 received. MESSAGE_ID_NACK objects are transmitted as described in 1106 Section 3.5. 1108 Received MESSAGE_ID_NACK objects indicate that the object generator 1109 does not have any installed state matching the object. Upon 1110 receiving a MESSAGE_ID_NACK object, the receiver performs an 1111 installed Path or Resv state lookup based on the Epoch and 1112 Message_Identifier values contained in the object. If matching state 1113 is found, then the receiver MUST transmit the matching state via a 1114 standard Path or Resv message. If the receiver cannot identify any 1115 installed state, then no action is required. 1117 4.5. Compatibility 1119 Nodes supporting the summary refresh extension advertise their 1120 support via the Summary_Capable flag in all MESSAGE_ID and 1121 MESSAGE_ID_ACK objects transmitted by the node. Support is also 1122 implied when a node transmits an Srefresh Message. This enables 1123 supporting nodes to detect each other. When it is not known if a 1124 next hop supports the extension, standard Path and Resv message based 1125 refreshes MUST be used. Note that when the routing next hop does not 1126 support RSVP, it will not always be possible to detect if the RSVP 1127 next hop supports the summary refresh extension. Therefore, when the 1128 routing next hop is not RSVP capable the Srefresh message based 1129 refresh SHOULD NOT be used. A node MAY be administratively 1130 configured to use Srefresh messages in all cases when all RSVP nodes 1131 in a network are known to support the summary refresh extension. 1132 This is useful since, when operating in this mode, the extension 1133 properly adjusts to the case of non-RSVP next hops and changes in 1134 routing. 1136 Nodes supporting the summary refresh extension must also take care to 1137 recognize when a next hop stops sending MESSAGE_ID and MESSAGE_ID_ACK 1138 objects with the Summary_Capable flag set. To cover this case, nodes 1139 supporting the summary refresh extension MUST examine each 1140 Summary_Capable flag received in a MESSAGE_ID or MESSAGE_ID_ACK 1141 object. Summary_Capable flags received in MESSAGE_ID_NACK objects 1142 SHOULD be ignored. If the flag changes from indicating support to 1143 indicating non-support then Srefresh messages MUST NOT be used for 1144 subsequent state refreshes to that neighbor. 1146 5. Reference Exponential Back-Off Procedures 1148 This section is based on [Pan] and provides an example of how to 1149 implement exponential back-off. Implementations MAY choose to use 1150 the described procedures. 1152 5.1. Outline of Operation 1154 The following is one possible feedback mechanism for exponential 1155 back-off retransmission of an RSVP message: When sending such a 1156 message, a node inserts a MESSAGE_ID object with the ACK_Desired flag 1157 set. Upon reception, a receiving node acknowledges the arrival of 1158 the message by sending back an message acknowledgment (that is, a 1159 corresponding MESSAGE_ID_ACK object.) When the sending node receives 1160 this message acknowledgment for a Path or Resv message, it will 1161 automatically scale back the retransmission rate for these messages 1162 for the flow. If the trigger message was for a different message 1163 type, no other further action is required. 1165 Until the message acknowledgment is received, the sending node will 1166 retransmit the message. The interval between retransmissions is 1167 governed by a rapid retransmission timer. The rapid retransmission 1168 timer starts at a small interval which increases exponentially until 1169 it reaches a threshold. From that point on, the sending node will 1170 use a fixed timer to refresh Path and Resv messages and stop re- 1171 transmitting other messages. This mechanism is designed so that the 1172 message load is only slightly larger than in the current 1173 specification even when the receiving node does not support message 1174 acknowledgment. 1176 5.2. Time Parameters 1178 The described procedures make use of the following time parameters. 1179 All parameters are per interface. 1181 Rapid retransmission interval Rf: 1183 Rf is the initial retransmission interval for unacknowledged 1184 messages. After sending the message for the first time, the 1185 sending node will schedule a retransmission after Rf seconds. 1186 The value of Rf could be as small as the round trip time (RTT) 1187 between a sending and a receiving node, if known. Unless a node 1188 knows that all receiving nodes support echo-replies, a slightly 1189 larger configurable value is suggested. 1191 Slow refresh interval Rs: 1193 The sending node retransmits Path and Resv messages with this 1194 interval after it has determined that the receiving node will 1195 generate MESSAGE_ID_ACK objects. To reduce the number of 1196 unnecessary retransmissions in a stable network, Rs can be set 1197 to a large value. The value of Rs should be configurable per 1198 each egress interface. 1200 Fixed retransmission interval R: 1202 A node retransmits the trigger message with the interval Rf*(1 + 1203 Delta)**i until the retransmission interval reaches the fixed 1204 retransmission interval R or a message acknowledgment has been 1205 received. If no acknowledgment has been received, the node 1206 continues to retransmit Resv and Path messages every R seconds. 1207 By default R should be the same value as the retransmission 1208 interval in the current RSVP specification. 1210 Increment value Delta: 1212 Delta governs the speed with which the sender increases the 1213 retransmission interval. The ratio of two successive 1214 retransmission intervals is (1 + Delta). 1216 5.3. Example Retransmission Algorithm 1218 After a sending node transmits a message containing a MESSAGE_ID 1219 object with the ACK_Desired flag set, it should immediately schedule 1220 a retransmission after Rf seconds. If a corresponding MESSAGE_ID_ACK 1221 object is received earlier than Rf seconds, then retransmission 1222 SHOULD be canceled. Otherwise, it will retransmit the message after 1223 (1 + Delta)*Rf seconds. The staged retransmission will continue 1224 until either an appropriate MESSAGE_ID_ACK object is received, or the 1225 retransmission interval has been increased to R. Once the 1226 retransmission interval has been increased to R, Path and Resv 1227 messages will be refreshed within the interval R. Other messages 1228 will not be retransmitted. 1230 The implementation of exponential back-off retransmission is simple. 1231 A sending node can use the following algorithm after transmitting a 1232 message containing a MESSAGE_ID object with the ACK_Desired flag set: 1234 On initial transmission initialize: Rk = Rf 1236 if (Rk < R) { 1237 retransmit the message; 1238 wake up after Rk seconds; 1239 Rk = Rk * (1 + Delta); 1240 exit; 1241 } 1242 else { /* no reply from receivers for too long: */ 1243 Rk = R; 1244 if (message is a Path or Resv Message) { 1245 send out a refresh message; 1246 wake up after Rk seconds; 1247 exit; 1248 } 1249 else { 1250 clean up any associated state and resources; 1251 exit; 1252 } 1253 } 1255 Asynchronously, when a sending node receives a corresponding 1256 MESSAGE_ID_ACK object, it will change the retransmission interval Rk 1257 to Rs and, for non Path or Resv messages, clean up any associated 1258 state and resources. Note that the transmitting node does not 1259 advertise the use of the described exponential back-off procedures 1260 via the TIME_VALUE object. 1262 6. Acknowledgments 1264 This document represents ideas and comments from the MPLS-TE design 1265 team and participants in the RSVP Working Group's interim meeting. 1266 Thanks to Fred Baker, Bob Braden, Roch Guerin, David Mankins, Henning 1267 Schulzrinne, Andreas Terzis and Masanobu Yuhara for specific feedback 1268 on the document. 1270 Portions of this work are based on work done by Masanobu Yuhara and 1271 Mayumi Tomikawa [Yuhara]. 1273 7. Security Considerations 1275 No new security issues are raised in this document. See [RFC2205] 1276 for a general discussion on RSVP security issues. 1278 8. References 1280 [Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP," 1281 Global Internet'97, Phoenix, AZ, November 1997. 1282 http://www.ctr.columbia.edu/~pan/papers/timergi.ps 1284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1285 Requirement Levels," RFC 2119. 1287 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 1288 -- Version 1 Functional Specification", RFC 2205, 1289 September 1997. 1291 [Yuhara] Yuhara, M., Tomikawa, M. "RSVP Extensions for ID-based 1292 Refreshes," Internet Draft, 1293 draft-yuhara-rsvp-refresh-00.txt, April 1999. 1295 9. Authors' Addresses 1297 Lou Berger 1298 LabN Consulting, LLC 1299 Voice: +1 301 468 9228 1300 Email: lberger@labn.net 1302 Der-Hwa Gan 1303 Juniper Networks, Inc. 1304 385 Ravendale Drive 1305 Mountain View, CA 94043 1306 Voice: +1 650 526 8074 1307 Email: dhg@juniper.net 1309 George Swallow 1310 Cisco Systems, Inc. 1311 250 Apollo Drive 1312 Chelmsford, MA 01824 1313 Voice: +1 978 244 8143 1314 Email: swallow@cisco.com 1316 Ping Pan 1317 Bell Labs, Lucent 1318 101 Crawfords Corner Road, Room 4C-508 1319 Holmdel, NJ 07733 1320 USA 1321 Phone: +1 732 332 6744 1322 Email: pingpan@dnrc.bell-labs.com