idnits 2.17.1 draft-berger-rsvp-refresh-reduct-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 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 32 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: ---------------------------------------------------------------------------- == Line 144 has weird spacing: '... enable refre...' == Line 164 has weird spacing: '...changes in th...' == Line 556 has weird spacing: '...n 6 for detai...' == 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 MUST not be used if the next hop RSVP neighbor does not support RSVP Bundle messages. 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. If the next hop 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 (June 1999) is 9082 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) == Unused Reference: 'Awduche' is defined on line 1323, but no explicit reference was found in the text -- No information found for draft-awduche-mpls-traffic-eng - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Awduche' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pan' -- Possible downref: Normative reference to a draft: ref. 'Yuhara' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 3 Expiration Date: December 1999 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 Ping Pan 11 Bell Labs, Lucent 13 June 1999 15 RSVP Refresh Reduction Extensions 17 draft-berger-rsvp-refresh-reduct-03.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 To view the current status of any Internet-Draft, please check the 39 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 40 Directory, see http://www.ietf.org/shadow.html. 42 Abstract 44 This document describes a number of mechanisms that reduce the 45 refresh overhead of RSVP. The extensions can be used to reduce 46 processing requirements of refresh messages, eliminate the state 47 synchronization latency incurred when an RSVP message is lost and, 48 when desired, suppress the generation of refresh messages. An 49 extension to support detection of when an RSVP neighbor resets its 50 state is also defined. These extension present no backwards 51 compatibility issues. 53 Contents 55 1 Introduction and Background ............................... 4 56 1.1 Trigger and Refresh Messages .............................. 5 57 2 RSVP Bundle Message ....................................... 5 58 2.1 Bundle Header ............................................. 6 59 2.2 Message Formats ........................................... 7 60 2.3 Sending RSVP Bundle Messages .............................. 7 61 2.4 Receiving RSVP Bundle Messages ............................ 8 62 2.5 Forwarding RSVP Bundle Messages ........................... 9 63 2.6 Bundle-Capable Bit ........................................ 9 64 3 MESSAGE_ID Extension ...................................... 10 65 3.1 MESSAGE_ID Object ......................................... 11 66 3.2 Ack Message Format ........................................ 13 67 3.3 MESSAGE_ID Object Usage ................................... 13 68 3.4 MESSAGE_ID ACK Object Usage ............................... 16 69 3.5 Multicast Considerations .................................. 16 70 3.5.1 Reference RSVP/Routing Interface .......................... 18 71 3.6 Compatibility ............................................. 18 72 4 Summary Refresh Extension ................................. 19 73 4.1 Srefresh Message Format ................................... 20 74 4.2 Srefresh Message Usage .................................... 21 75 4.3 Srefresh NACK ............................................. 22 76 4.4 Compatibility ............................................. 23 77 5 Hello Extension ........................................... 23 78 5.1 Hello Message Format ...................................... 24 79 5.2 HELLO Object .............................................. 25 80 5.3 Hello Message Usage ....................................... 26 81 5.4 Multi-Link Considerations ................................. 27 82 5.5 Compatibility ............................................. 27 83 6 Reference Exponential Back-Off Procedures ................. 28 84 6.1 Outline of Operation ...................................... 28 85 6.2 Time Parameters ........................................... 28 86 6.3 Example Retransmission Algorithm .......................... 29 87 7 Acknowledgments ........................................... 30 88 8 Security Considerations ................................... 30 89 9 References ................................................ 31 90 10 Authors' Addresses ........................................ 32 91 1. Introduction and Background 93 The resource requirements (in terms of CPU processing and memory) for 94 running RSVP on a router increases proportionally with the number of 95 sessions. Supporting a large number of sessions can present scaling 96 problems. 98 This document describes mechanisms to help alleviate one set of scal- 99 ing issues. RSVP Path and Resv messages must be periodically 100 refreshed to maintain state. The approach described effectively 101 reduces the volume of messages which must be periodically sent and 102 received, as well as the resources required to process refresh mes- 103 sages. 105 The described mechanisms also address issues of latency and reliabil- 106 ity of RSVP Signaling. The latency and reliability problem occurs 107 when a non-refresh RSVP message is lost in transmission. Standard 108 RSVP [RFC2205] maintains state via the generation of RSVP refresh 109 messages. In the face of transmission loss of RSVP messages, the 110 end-to-end latency of RSVP signaling is tied to the refresh interval 111 of the node(s) experiencing the loss. When end-to-end signaling is 112 limited by the refresh interval, the establishment or change of a 113 reservation may be beyond the range of what is acceptable for some 114 applications. 116 One way to address the refresh volume problem is to increase the 117 refresh period, "R" as defined in section 3.7 of [RFC2205]. Increas- 118 ing the value of R provides linear improvement on transmission over- 119 head, but at the cost of increasing the time it takes to synchronize 120 state. 122 One way to address the latency and reliability of RSVP Signaling is 123 to decrease the refresh period R. Decreasing the value of R provides 124 increased probability that state will be installed in the face of 125 message loss, but at the cost of increasing refresh message rate and 126 associated processing requirements. 128 An additional issue is the time to deallocate resources after a tear 129 message is lost. RSVP does not retransmit ResvTear or PathTear mes- 130 sages. If the sole tear message transmitted is lost, then resources 131 will only be deallocated once the "cleanup timer" interval has 132 passed. This may result in resources being allocated for an unneces- 133 sary period of time. Note that adjusting the refresh period has no 134 impact on this issues since tear messages are not retransmitted. 136 The extensions defined in this document address both the refresh vol- 137 ume and the reliability issues with mechanisms other than adjusting 138 refresh rate. A Bundle message is defined to reduce overall message 139 handling load. A Message_ID object is defined to reduce refresh mes- 140 sage processing by allowing the receiver to more readily identify an 141 unchanged message. A Message_ACK object is defined which can be used 142 to detect message loss and, when used in combination with the Mes- 143 sage_ID object, can be used to suppress refresh messages altogether. 144 A summary refresh message is defined to enable refreshing state 145 without the transmission of whole refresh messages, while maintaining 146 RSVP's ability to indicate when state is lost or when next hops 147 change. Finally, a hello protocol is defined to allow detection of 148 the loss of a neighbor node or a reset of it's RSVP state informa- 149 tion. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 1.1. Trigger and Refresh Messages 157 This document categorizes RSVP messages into two types: trigger and 158 refresh messages. Trigger messages are those RSVP messages that 159 advertise state or any other information not previously transmitted. 160 Trigger messages include messages advertising new state, a route 161 change that altered the reservation paths, or a reservation modifica- 162 tion by a downstream router. Trigger messages also include those 163 messages that include changes in non-RSVP processed objects, such as 164 changes in the Policy or ADSPEC objects. 166 Refresh messages represent previously advertised state and contain 167 exactly the same objects and same information as a previously trans- 168 mitted message. Only Path and Resv messages can be refresh messages. 169 Refresh messages are typically bit for bit identical to the corre- 170 sponding previously transmitted message, with the exception of the 171 flags in the MESSAGE_ID object. These flags allowed to differ in 172 refresh messages. 174 2. RSVP Bundle Message 176 An RSVP Bundle message consists of a bundle header followed by a body 177 consisting of a variable number of standard RSVP messages. A Bundle 178 message is used to aggregated multiple RSVP messages within a single 179 PDU. The term "bundling" is used to avoid confusion with RSVP reser- 180 vation aggregation. The following subsections define the formats of 181 the bundle header and the rules for including standard RSVP messages 182 as part of the message. 184 2.1. Bundle Header 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Vers | Flags | Msg type | RSVP checksum | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Send_TTL | (Reserved) | RSVP length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 The format of the bundle header is identical to the format of the 195 RSVP common header [RFC2205]. The fields in the header are as fol- 196 lows: 198 Vers: 4 bits 200 Protocol version number. This is version 1. 202 Flags: 4 bits 204 0x01: Bundle capable 206 If set, indicates to RSVP neighbors that this node is willing 207 and capable of receiving bundle messages. This bit is mean- 208 ingful only between adjacent RSVP neighbors. 210 0x02-0x08: Reserved 212 Msg type: 8 bits 214 12 = Bundle 216 RSVP checksum: 16 bits 218 The one's complement of the one's complement sum of the entire 219 message, with the checksum field replaced by zero for the pur- 220 pose of computing the checksum. An all-zero value means that 221 no checksum was transmitted. Because individual sub-messages 222 carry their own checksum as well as the INTEGRITY object for 223 authentication, this field MAY be set to zero. 225 Send_TTL: 8 bits 227 The IP TTL value with which the message was sent. This is used 228 by RSVP to detect a non-RSVP hop by comparing the IP TTL that a 229 Bundle message sent to the TTL in the received message. 231 RSVP length: 16 bits 233 The total length of this RSVP Bundle message in bytes, includ- 234 ing the bundle header and the sub-messages that follow. 236 2.2. Message Formats 238 An RSVP Bundle message must contain at least one sub-message. A sub- 239 message MAY be any message type except for another Bundle message. 240 Current valid sub-messages are RSVP Path, PathTear, PathErr, Resv, 241 ResvTear, ResvErr, ResvConf, Ack or Hello messages. 243 Empty RSVP Bundle messages SHOULD NOT be sent. A Bundle message MUST 244 NOT include another RSVP Bundle message as a sub-message. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Vers | Flags | 12 | RSVP checksum | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Send_TTL | (Reserved) | RSVP length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 // First sub-message // 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 // More sub-messages.. // 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 2.3. Sending RSVP Bundle Messages 264 RSVP Bundle messages are sent hop by hop between RSVP-capable neigh- 265 bors as "raw" IP datagrams with protocol number 46. Raw IP datagrams 266 are also intended to be used between an end system and the first/last 267 hop router, although it is also possible to encapsulate RSVP messages 268 as UDP datagrams for end-system communication that cannot perform raw 269 network I/O. 271 RSVP Bundle messages MUST not be used if the next hop RSVP neighbor 272 does not support RSVP Bundle messages. Methods for discovering such 273 information include: (1) manual configuration and (2) observing the 274 Bundle-capable bit (see the description that follows) in the received 275 RSVP messages. If the next hop RSVP neighbor is not known or changes 276 in next hops cannot be identified via routing, Bundle messages MUST 277 NOT be sent. Note that when the routing next hop is not RSVP capable 278 it will typically not be possible to identify changes in next hop. 280 Support for RSVP Bundle messages is optional. While message bundling 281 helps in scaling RSVP, and in reducing processing overhead and band- 282 width consumption, a node is not required to transmit every standard 283 RSVP message in a Bundle message. A node MUST always be ready to 284 receive standard RSVP messages. 286 The IP source address is local to the system that originated the Bun- 287 dle message. The IP destination address is the next hop node for 288 which the sub-messages are intended. These addresses need not be 289 identical to those used if the sub-messages were sent as standard 290 RSVP messages. 292 For example, the IP source address of Path and PathTear messages is 293 the address of the sender it describes, while the IP destination 294 address is the DestAddress for the session. These end-to-end 295 addresses are overridden by hop-by-hop addresses while encapsulated 296 in a Bundle message. These addresses can easily be restored from the 297 SENDER_TEMPLATE and SESSION objects within Path and PathTear mes- 298 sages. For Path and PathTear messages, the next hop node can be 299 identified either via a received ACK or from a received corresponding 300 Resv message. Path and PathTear messages for multicast sessions MUST 301 NOT be sent in Bundle messages except when the outgoing interface is 302 a point-to-point interface and it is known that the next hop is RSVP 303 capable. 305 RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP 306 option in their IP headers. This is because Bundle messages are 307 addressed directly to RSVP neighbors. 309 Each RSVP Bundle message MUST occupy exactly one IP datagram. If it 310 exceeds the MTU, the datagram is fragmented by IP and reassembled at 311 the recipient node. A single RSVP Bundle message MUST NOT exceed the 312 maximum IP datagram size, which is approximately 64K bytes. 314 2.4. Receiving RSVP Bundle Messages 316 If the local system does not recognize or does not wish to accept an 317 Bundle message, the received messages shall be discarded without fur- 318 ther analysis. 320 The receiver next compares the IP TTL with which a Bundle message is 321 sent to the TTL with which it is received. If a non-RSVP hop is 322 detected, the number of non-RSVP hops is recorded. It is used later 323 in processing of sub-messages. 325 Next, the receiver verifies the version number and checksum of the 326 RSVP Bundle message and discards the message if any mismatch is 327 found. 329 The receiver then starts decapsulating individual sub-messages. Each 330 sub-message has its own complete message length and authentication 331 information. Each sub-message is processed per standard RSVP. 333 2.5. Forwarding RSVP Bundle Messages 335 When an RSVP router receives a Bundle messages which is not addressed 336 to one of it's IP addresses, it SHALL forward the message. Non-RSVP 337 routers will treat RSVP Bundle messages as any other IP datagram. 339 When individual sub-messages are being forwarded, they MAY be encap- 340 sulated in another Bundle message before sending to the next hop 341 neighbor. The Send_TTL field in the sub-messages should be decre- 342 mented properly before transmission. 344 2.6. Bundle-Capable Bit 346 To support message bundling, an additional capability bit is added to 347 the common RSVP header, which is defined in [RFC2205]. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Vers | Flags | Msg Type | RSVP Checksum | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Send_TTL | (Reserved) | RSVP Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Flags: 4 bits 359 0x01: Bundle capable 361 If set, indicates to RSVP neighbors that this node is willing 362 and capable of receiving Bundle messages. This bit is mean- 363 ingful only between adjacent RSVP neighbors. 365 3. MESSAGE_ID Extension 367 Two new objects are defined as part of the MESSAGE_ID extension. The 368 two object types are the MESSAGE_ID object and the MESSAGE_ID ACK 369 object. The objects are used to support acknowledgments and, when 370 used in conjunction with the Hello Extension described in Section 5, 371 to indicate when refresh messages are not needed after an acknowledg- 372 ment. When refreshes are normally generated, the MESSAGE_ID object 373 can also be used to simply provide a shorthand indication of when a 374 message represents new state. Such information can be used on the 375 receiving node to reduce refresh processing requirements. 377 Message identification and acknowledgment is done on a hop-by-hop 378 basis. Acknowledgment is handled independent of SESSION or message 379 type. Both types of MESSAGE_ID objects contain a message identifier. 380 The identifier MUST be unique on a per source IP address basis across 381 messages sent by an RSVP node and received by a particular node. No 382 more than one MESSAGE_ID object may be included in an RSVP message. 383 Each message containing an MESSAGE_ID object may be acknowledged via 384 a MESSAGE_ID ACK object. MESSAGE_ID ACK objects may be sent piggy- 385 backed in unrelated RSVP messages or in RSVP Ack messages. 387 Either type of MESSAGE_ID object may be included in a bundle sub-mes- 388 sage. When included, the object is treated as if it were contained 389 in a standard, unbundled, RSVP message. Only one MESSAGE_ID object 390 MAY be included in a (sub)message and it MUST follow any present MES- 391 SAGE_ID ACK objects. When no MESSAGE_ID ACK objects are present, the 392 MESSAGE_ID object MUST immediately follow the INTEGRITY object. When 393 no INTEGRITY object is present, the MESSAGE_ID object MUST immedi- 394 ately follow the (sub)message header. 396 When present, one or more MESSAGE_ID ACK objects MUST immediately 397 follow the INTEGRITY object. When no INTEGRITY object is present, 398 the MESSAGE_ID ACK objects MUST immediately follow the the (sub)mes- 399 sage header. An MESSAGE_ID ACK object may only be included in a mes- 400 sage when the message's IP destination address matches the unicast 401 address of the node that generated the message(s) being acknowledged. 403 3.1. MESSAGE_ID Object 405 MESSAGE_ID Class = 166 (Value to be assigned by IANA of form 406 10bbbbbb) 408 MESSAGE_ID object 410 Class = MESSAGE_ID Class, C_Type = 1 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Flags | Epoch | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Message_ID | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Flags: 8 bits 422 0x80 = Summary_Capable flag 424 Indicates that the sender supports the summary refresh 425 extension. This flag MUST be set if the node supports the 426 summary refresh extension. See Section 4.4 for description 427 of handling by receiver. 429 0x40 = ACK_Desired flag 431 Indicates that the sender is willing to accept a message 432 acknowledgment. Acknowledgments MUST be silently ignored 433 when they are sent in response to messages whose 434 ACK_Desired flag is not set. This flag MUST be set when 435 the Last_Refresh flag is set. 437 0x20 = Last_Refresh flag 439 Used in Resv and Path refresh messages to indicate that the 440 sender will not be sending further refreshes. When set, 441 the ACK_Desired flag MUST also be set. This flag MUST NOT 442 be set when the HELLO messages are not being exchanged with 443 the neighboring RSVP node. 445 Epoch: 24 bits 447 A value that indicates when the Message_ID sequence has reset. 448 SHOULD be randomly generated each time a node reboots. This value 449 MUST NOT be changed during normal operation. 451 Message_ID: 32 bits 453 When combined with the message generator's IP address, the Message_ID 454 field uniquely identifies a message. This field is ordered and only 455 decreases in value when the Epoch changes or the value wraps. 457 MESSAGE_ID ACK object 459 Class = MESSAGE_ID Class, C_Type = 2 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Flags | Epoch | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Message_ID | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Flags: 8 bits 471 0x80 = Summary_Capable flag 473 Indicates that the sender supports the summary refresh 474 extension. This flag MUST be set if the node supports the 475 summary refresh extension. See Section 4.4 for description 476 of handling by receiver. 478 0x40 = Refresh_NACK flag 480 Indicates that no state was found corresponding to the 481 indicated message identifier. This flag SHALL ONLY be set 482 when the matching Epoch and Message_ID field values were 483 received in a Summary Refresh message, and MUST NOT be set 484 in response to a MESSAGE_ID object received in any other 485 message. See Section 4 for details. 487 Epoch: 24 bits 489 The Epoch field copied from the message being acknowledged. 491 Message_ID: 32 bits 493 The Message_ID field copied from the message being acknowl- 494 edged. 496 3.2. Ack Message Format 498 Ack messages carry one or more MESSAGE_ID ACK objects. They MUST NOT 499 contain any MESSAGE_ID objects. Ack messages are sent hop-by-hop 500 between RSVP nodes. The IP destination address of an Ack message is 501 the unicast address of the node that generated the message(s) being 502 acknowledged. For Path, PathTear, Resv, and RervErr messages this is 503 taken from the RSVP_HOP Object. For PathErr and ResvErr messages 504 this is taken from the message's source address. The IP source 505 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 13 (Value to be assigned by IANA). 516 3.3. MESSAGE_ID Object Usage 518 The MESSAGE_ID object may be included in any RSVP message other than 519 the Ack message. The MESSAGE_ID object is always generated and pro- 520 cessed hop-by-hop. The IP address of the object generator is repre- 521 sented in a per RSVP message type specific fashion. For Path and 522 PathTear messages the generator's IP address is contained in the 523 RSVP_HOP. For Resv, ResvTear, PathErr, ResvErr, ResvConf and Bundle 524 messages the generator's IP address is the source address in the IP 525 header. 527 The Epoch field contains a generator selected value. The value is 528 used to indicate when the sender resets the values used in the Mes- 529 sage_ID field. This information is used by the receiver to detect 530 out of order messages. On startup, a node SHOULD randomly select a 531 value to be used in the Epoch field. The node SHOULD ensure that the 532 selected value is not the same as was used when the node was last 533 operational. The value MUST NOT be changed unless the node or the 534 RSVP agent is restarted. 536 The Message_ID field contains a generator selected value. This 537 value, when combined with the generator's IP address, identifies a 538 particular RSVP message and the specific state information it repre- 539 sents. When a node is sending a refresh message with a MESSAGE_ID 540 object, it SHOULD use the same Message_ID value that was used in the 541 RSVP message that first advertised the state being refreshed. When a 542 node is sending a trigger message, the Message_ID value MUST have a 543 value that is greater than any other previously used value. A value 544 is considered to have been used when it has been sent in any message 545 using the associated IP address. Note that this 32-bit value MAY 546 wrap. 548 The ACK_Desired flag is set when the MESSAGE_ID object generator is 549 capable of accepting MESSAGE_ID ACK objects. Such information can be 550 used to ensure reliable delivery of error and confirm messages and to 551 support fast refreshes in the face of network loss. Nodes setting 552 the ACK_Desired flag SHOULD retransmit unacknowledged messages at a 553 more rapid interval than the standard refresh period until the mes- 554 sage is acknowledged or until a "rapid" retry limit is reached. 555 Rapid retransmission rate SHOULD be based on well known exponential 556 back-off procedures. See Section 6 for details on one exponential 557 back-off retransmission approach. Note that nodes setting the 558 ACK_Desired flag for unicast sessions, do not need to track the iden- 559 tify of the next hop since all that is expected is an ACK, not an ACK 560 from a specific next hop. Issues relate to multicast sessions are 561 covered in a later section. The ACK_Desired flag will typically be 562 set only in trigger messages. The ACK_Desired flag MAY be set in 563 refresh messages. 565 The Last_Refresh flag may be set in Path and Resv messages when the 566 MESSAGE_ID object generator is exchanging Hello messages, described 567 in Section 5, with the next hop RSVP node. When a refresh message 568 with the Last_Refresh flag set is generated, normal refresh genera- 569 tion MUST continue until the message containing the Last_Refresh flag 570 is acknowledged. Although, messages removing state advertised in 571 such messages MUST be retransmit until acknowledged or a maximum 572 retry limit is reached in order to cover certain packet loss condi- 573 tions. Messages removing state include PathTear and ResvTear. 575 When sending MESSAGE_ID objects with the Last_Refresh flag set, spe- 576 cial care must be taken to properly advertise state. Specifically, 577 refresh processing MUST continue per standard RSVP processing until 578 after a acknowledgment is received. Suppression of refresh process- 579 ing MAY ONLY occur after an acknowledgment is received for a MES- 580 SAGE_ID object with the Last_Refresh flag set. Note that the 581 Last_Refresh flag MAY ONLY be set when the RSVP next hop is exchang- 582 ing Hello messages with the message generator. 584 When a Path message for a new session arrives, the RSVP next hop may 585 not always be known. When the RSVP next hop is not known, the 586 Last_Refresh flag MUST NOT be set. Once the next hop of a unicast 587 session is identified, only then may the Last_Refresh flag be set. 588 (Issues relate to multicast sessions are covered in a later section.) 589 There are several ways to identify the RSVP next hop of a new unicast 590 session. Some are more conservative than other, e.g., waiting for a 591 Resv message versus checking if the other end of a PPP link supports 592 Hello messages. Since there are no interoperability issues, the spe- 593 cific mechanism used to identify the RSVP next hop of a new session 594 is a specific implementation choice. In most implementations, it is 595 expected that an advertiser of Path state will do standard refresh 596 processing until either an ACK is received for a Path message adver- 597 tising a new session, or a corresponding Resv message is received. 599 Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a 600 newly received message is out of order and can be ignored. Out of 601 order messages can be identified by examining the values in the Epoch 602 and Message_ID fields. If the Epoch value differs from the value 603 previously received from the message sender, the receiver MUST fully 604 processes the message. If the Epoch values match and the Message_ID 605 value is greater than the largest value previously received from the 606 sender, the receiver MUST fully processes the message. If the value 607 is less than the largest value previously received from the sender, 608 then the receiver SHOULD check the value previously received for the 609 state associated with the message. This check should be performed 610 for the currently defined messages: Path, Resv, PathTear, ResvTear, 611 PathErr and ResvErr. If no local state information can be associated 612 with the message, the receiver MUST fully processes the message. If 613 local state can be associated with the message and the received Mes- 614 sage_ID value is less than the most recently received value associ- 615 ated with the state, the message SHOULD be ignored, i.e., silently 616 dropped. 618 Nodes receiving messages containing MESSAGE_ID objects SHOULD use the 619 information in the objects to aid in determining if a message repre- 620 sents new state or a state refresh. Note that state is only 621 refreshed in Path and Resv messages. If the received Epoch values 622 differs from the value previously received from the message sender, 623 the message is a trigger message and the receiver MUST fully pro- 624 cesses the message. If a Path or Resv message contains the same Mes- 625 sage_ID value that was used in the most recently received message for 626 the same session and, for Path messages, SENDER_TEMPLATE then the 627 receiver SHOULD treat the message as a state refresh. If the Mes- 628 sage_ID value is grater than the most recently received value, the 629 receiver MUST fully processes the message. If the Message_ID value 630 is less than the most recently received value, the receiver SHOULD 631 ignore the message. 633 Nodes receiving a non-out of order message containing a MESSAGE_ID 634 object with the ACK_Desired flag set, SHOULD respond with a MES- 635 SAGE_ID ACK object. If a node supports the Hello extension it MUST 636 also check the Last_Refresh flag of received Resv and Path messages. 637 If the flag is set, the receiver MUST NOT timeout state associated 638 with associated message. The receiver MUST also be prepared to 639 properly process refresh messages. Messages containing a MESSAGE_ID 640 ACK object with the Last_Refresh flag set MUST NOT be acknowledged 641 when either the receiving node doesn't support the Hello extension or 642 Hello messages aren't being exchanged with the message generator. 644 3.4. MESSAGE_ID ACK Object Usage 646 The MESSAGE_ID ACK object is used to acknowledge receipt of messages 647 containing MESSAGE_ID objects that were sent with the ACK_Desired 648 flag set. The Epoch and Message_ID fields of a MESSAGE_ID ACK object 649 MUST have the same value as was received. A MESSAGE_ID ACK object 650 MUST NOT be generated in response to a received MESSAGE_ID object 651 when the ACK_Desired flag is not set, except as noted in Section 4.3. 653 A MESSAGE_ID ACK object MAY be sent in any RSVP message that has an 654 IP destination address matching the generator of the associated MES- 655 SAGE_ID object. The MESSAGE_ID ACK object will not typically be 656 included in the non hop-by-hop Path, PathTear and ResvConf messages. 657 When no appropriate message is available, one or more MESSAGE_ID ACK 658 objects SHOULD be sent in an Ack message. Implementations SHOULD 659 include MESSAGE_ID ACK objects in standard RSVP messages when possi- 660 ble. 662 MESSAGE_ID ACK objects received with the Refresh_NACK flag set MUST 663 process the object as described in Section 4.3. Upon receiving a 664 MESSAGE_ID ACK object with the Refresh_NACK flag not set, a node 665 SHOULD stop retransmitting the message at the "rapid" retry rate. If 666 the received object also has the Last_Refresh flag set, normal 667 refresh generation SHOULD be suppressed for the associated state. As 668 previously mentioned, special care must be taken to properly adver- 669 tise state when sending MESSAGE_ID objects with the Last_Refresh flag 670 set, see section 3.3. 672 3.5. Multicast Considerations 674 Path and PathTear messages may be sent to IP multicast destination 675 addresses. When the destination is a multicast address, it is possi- 676 ble that a single message containing a single MESSAGE_ID object will 677 be received by multiple RSVP next hops. When the ACK_Desired flag is 678 set in this case, acknowledgment processing is more complex. There 679 are a number of issues to be addressed including ACK implosion, num- 680 ber acknowledgments to be expected and handling of new receivers. 682 ACK implosion occurs when each receiver responds to the MESSAGE_ID 683 object at approximately the same time. This can lead to a poten- 684 tially large number of MESSAGE_ID ACK objects being simultaneously 685 delivered to the message generator. To address this case, the 686 receiver MUST wait a random interval prior to acknowledging a MES- 687 SAGE_ID object received in a message destined to a multicast address. 688 The random interval SHOULD be between zero (0) and a configured maxi- 689 mum time. The configured maximum SHOULD be set in proportion to the 690 refresh and "rapid" retransmission interval, i.e, such that the maxi- 691 mum back-off time does not result in retransmission. 693 A more fundamental issue is the number of acknowledgments that the 694 upstream node, i.e., the message generator, should expect. The num- 695 ber of acknowledgments that should be expected is the same as the 696 number of RSVP next hops. In the router-to-router case, the number 697 of next hops can usually be obtained from routing. When hosts are 698 either the upstream node or the next hops, the number of next hops 699 will typically not be readily available. Another case where the num- 700 ber of RSVP next hops will typically not be known is when there are 701 non-RSVP routers between the message generator and the RSVP next 702 hops. 704 When the number of next hops is not known, the message generator 705 SHOULD only expect a single response and MUST NOT set the 706 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 707 will be special retransmission handling until the message is deliv- 708 ered to at least one next hop, then followed by standard RSVP 709 refreshes. Standard refresh messages will synchronize state with any 710 next hops that don't receive the original message. 712 Another issue is handling new receivers. It is possible that after 713 sending a Path message and handling of expected number of acknowledg- 714 ments that a new receiver joins the group. In this case a new Path 715 message must be sent to the new receiver. When normal refresh pro- 716 cessing is occurring, there is no issue. When normal refresh pro- 717 cessing is suppressed, a Path message must still be generated. In 718 the router-to-router case, the identification of new next hops can 719 usually be obtained from routing. When hosts are either the upstream 720 node or the next hops, the identification of new next hops will typi- 721 cally not be possible. Another case where the identification of new 722 RSVP next hops will typically not be possible is when there are non- 723 RSVP routers between the message generator and the RSVP next hops. 725 When identification of new next hops is not possible, the message 726 generator SHOULD only expect a single response and MUST NOT set the 727 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 728 will be special retransmission handling until the message is deliv- 729 ered to at least one next hop, then followed by standard RSVP 730 refreshes. Standard refresh messages will synchronize state with any 731 next hops that don't receive the original message either due to loss 732 or not yet being a group member. 734 There is one additional minor issue with multiple next hops. The 735 issue is handling a combination of standard-refresh and non-refresh 736 next hops, i.e., Hello messages are being exchanged with some neigh- 737 boring nodes but not with others. When this case occurs, refreshes 738 MUST be generated per standard RSVP and the Last_Refresh flag MUST 739 NOT be set. 741 3.5.1. Reference RSVP/Routing Interface 743 When using the MESSAGE_ID extension with multicast sessions it is 744 preferable for RSVP to obtain the number of next hops from routing 745 and to be notified when that number changes. The interface between 746 routing and RSVP is purely an implementation issue. Since RSVP 747 [RFC2205] describes a reference routing interface, we present a ver- 748 sion of the RSVP/routing interface updated to provide number of next 749 hop information. See [RFC2205] for previously defined parameters and 750 function description. 752 o Route Query 753 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 754 Notify_flag ) 755 -> [ IncInterface, ] OutInterface_list, 756 NHops_list 758 o Route Change Notification 759 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 760 [ IncInterface, ] OutInterface_list, 761 NHops_list 763 NHops_list provides the number of multicast group members 764 reachable via each OutInterface_list entry. 766 3.6. Compatibility 768 There are no backward compatibility issues raised by the MESSAGE_ID 769 Class. The MESSAGE_ID Class has an assigned value whose form is 770 10bbbbbb. Per RSVP [RFC2205], classes with values of this form must 771 be ignored and not forwarded by nodes not supporting the class. When 772 the receiver of a MESSAGE_ID object does not support the class, the 773 object will be silently ignored. The generator of the MESSAGE_ID 774 object will not see any acknowledgments and therefore refresh mes- 775 sages per standard RSVP. Lastly, since the MESSAGE_ID ACK object can 776 only be issued in response to the MESSAGE_ID object, there are no 777 possible issues with this object or Ack messages. 779 Implementations supporting Path and Resv state refresh suppression 780 via the MESSAGE_ID object's Last_Refresh flag MUST also support the 781 Hello extension. Such implementations SHOULD initiate Hello process- 782 ing and MUST be able to respond to Hello messages. 784 4. Summary Refresh Extension 786 The Summary Refresh extension enables the refreshing of RSVP state 787 without the transmission of standard Path or Resv messages. The ben- 788 efits of the described extension are that it reduces the amount of 789 information that must be transmitted and processed in order to main- 790 tain RSVP state synchronization. Importantly, the described exten- 791 sion preserves RSVP's ability to handle non-RSVP next hops and to 792 adjust to changes in routing. This extension cannot be used with 793 Path or Resv messages that contain any change from previously trans- 794 mitted messages, i.e, are not refresh messages. 796 The summary refresh extension uses the previously defined MESSAGE_ID 797 object class, the ACK message, and a new Srefresh message. The new 798 message carries a list of MESSAGE_ID objects corresponding to the 799 Path and Resv states that are to be refreshed. An RSVP node receiv- 800 ing an Srefresh message, matches each received MESSAGE_ID object with 801 installed Path or Resv state. All matching state is updated as if a 802 normal RSVP refresh message is received. If matching state cannot be 803 found, then the Srefresh message sender is notified via a refresh 804 NACK. 806 Since Srefresh messages can carry multiple MESSAGE_ID objects, Sre- 807 fresh messages are not expected to be sent in an RSVP aggregate mes- 808 sages. The flags field of MESSAGE_ID objects carried in Srefresh 809 messages may be set. 811 A refresh NACK is indicated by setting the Refresh_NACK flag in the 812 MESSAGE_ID ACK object. The rules for sending a MESSAGE_ID ACK object 813 with the Refresh_NACK flag set are the same as was described in the 814 previous section. This includes sending MESSAGE_ID ACK object both 815 piggy-backed in unrelated RSVP messages or in RSVP ACK messages. 817 Nodes supporting the described extension can advertise their support 818 and detect if an RSVP neighbor also supports the extension. This is 819 accomplished via flag in the MESSAGE_ID class objects. 821 4.1. Srefresh Message Format 823 Srefresh messages carry one or more MESSAGE_ID objects. A single 824 Srefresh message MAY refresh both Path or Resv state. Srefresh mes- 825 sages carrying MESSAGE_ID objects corresponding to Path state SHOULD 826 be sent with a destination IP address equal to the address carried in 827 the corresponding SESSION objects. The destination IP address MAY be 828 set to the RSVP next hop when the next hop is known to be RSVP capa- 829 ble and the session is unicast or the outgoing interface is a point- 830 to-point interface. Srefresh messages carrying MESSAGE_ID objects 831 corresponding to Resv state MUST be sent with an destination IP 832 address set to the Resv state's previous hop. 834 The source IP address of an Srefresh message is an address of the 835 node that generates the message. The source IP address MUST match 836 the addressed associate with the MESSAGE_ID objects when they were 837 included in a standard RSVP message. As previously mentioned, the 838 address associate with a MESSAGE_ID object is represented in a per 839 RSVP message type specific fashion. For Path and PathTear messages 840 the associated IP address is contained in the RSVP_HOP. For Resv, 841 ResvTear, PathErr, ResvErr, ResvConf and Bundle messages the associ- 842 ated IP address is the source address in the IP header. 844 Srefresh messages that are sent destined to a session's destination 845 IP address MUST be sent the Router Alert IP option in their IP head- 846 ers. Srefresh messages addressed directly to RSVP neighbors SHOULD 847 NOT be sent with the Router Alert IP option in their IP headers. 849 Each Srefresh message MUST occupy exactly one IP datagram. If it 850 exceeds the MTU, the datagram is fragmented by IP and reassembled at 851 the recipient node. A single RSVP Srefresh message MUST NOT exceed 852 the maximum IP datagram size, which is approximately 64K bytes. 854 The Srefresh message format is as follows: 856 ::= [ ] 857 858 [ ... ] 860 For Srefresh messages, the Msg Type field of the Common Header MUST 861 be set to 14 (Value to be assigned by IANA). 863 4.2. Srefresh Message Usage 865 An Srefresh message MAY be generated to refresh Resv or Path state. 866 If an Srefresh message is used to refresh some particular state, then 867 the generation of a standard refresh message SHOULD be suppressed. A 868 state's refresh interval is not affected by the use of Srefresh mes- 869 sage based refreshes. An Srefresh message MUST NOT be used in place 870 of a trigger Path or Resv message, i.e., one that would advertise a 871 state change. 873 When generating an Srefresh message, a node SHOULD refresh as much 874 Path and Resv state as is possible by including as many MESSAGE_ID 875 objects in the same Srefresh message. Only MESSAGE_ID objects that 876 meet the previously described source and destination IP address 877 restrictions may be included in the same Srefresh message. Identify- 878 ing Resv state that can refreshed using the same Srefresh message is 879 fairly straightforward. Identifying which Path state may be included 880 is a little more complex. 882 Independent of the state being refreshed, only state that was previ- 883 ously advertised in Path and Resv messages containing MESSAGE_ID 884 objects can be refreshed via an Srefresh message. Srefresh message 885 based refreshes must also have the state synchronization properties 886 of Path or Resv message based refreshes. Specifically, the use of 887 Srefresh messages MUST NOT result in state being timed-out at the 888 RSVP next hop. The period at which state is refreshed when using 889 Srefresh messages MAY be shorter than the period that would be used 890 when using Path or Resv message based refreshes, but it MUST NOT be 891 longer. The particular approach used to trigger Srefresh message 892 based refreshes is implementation specific. Some possibilities are 893 triggering Srefresh message generation based on each state's refresh 894 period or, on a per interface basis, periodically generating Srefresh 895 messages to refresh all state that has not been refreshed within the 896 state's refresh interval. Other approaches are also possible. 898 When generating an Srefresh message, there are two methods for iden- 899 tifying which Path state may be refreshed in a specific message. In 900 both cases, the previously mentioned refresh interval and source IP 901 address restrictions must be followed. The primary method is to 902 include only those sessions that share the same destination IP 903 address in the same Srefresh message. When using this method, the 904 destination address of each session MUST be the same as the destina- 905 tion address in the IP header of the Srefresh message. 907 The secondary method for identifying which Path state may be 908 refreshed within a single Srefresh message is an optimization. This 909 method MAY be used when the next hop is known to support RSVP and 910 either the session is unicast or the outgoing interface is a point- 911 to-point interface. This method MUST NOT be used when the next hop 912 is not known to support RSVP or when the outgoing interface is to a 913 multi-access network and the session is to a multicast address. When 914 using this method, the destination address in the IP header of the 915 Srefresh message is always the next hop's address. When the outgoing 916 interface is a point-to-point interface, all Path state advertised 917 out the interface SHOULD be included in the same Srefresh message. 918 When the outgoing interface is not a point-to-point interface, all 919 unicast session Path state SHOULD be included in the same Srefresh 920 message. 922 Identifying which Resv state may be refreshed within a single Sre- 923 fresh message is based simply on the source and destination IP 924 addresses. Any state that was previously advertised in Resv messages 925 with the same IP addresses as an Srefresh message MAY be included. 927 After identifying the Path and Resv state that can be included in a 928 particular Srefresh message, the message generator adds to the mes- 929 sage a MESSAGE_ID object matching each identified state's previously 930 used object. Once the Srefresh message is composed, the message gen- 931 erator transmits the message out the proper interface. 933 Upon receiving an Srefresh message, a receiver MUST attempt to iden- 934 tify matching Path or Resv state. Matching is done based on the 935 source address in the IP header of the Srefresh message and each MES- 936 SAGE_ID object contained in the message. For each received MES- 937 SAGE_ID object, the receiver performs an installed state lookup based 938 on the values contained in the object. If matching state can be 939 found, then the receiver MUST update the matching state information 940 as if a standard refresh had been received. The receiver MUST also 941 process the flags contained in the MESSAGE_ID object per Sections 3 942 and 4.4. If the receiver cannot identify any matching installed 943 state, then a Srefresh NACK MUST be generated corresponding to the 944 unmatched MESSAGE_ID object. 946 4.3. Srefresh NACK 948 Srefresh NACKs are used to indicated that a received MESSAGE_ID 949 object does not match any installed state. An Srefresh NACK is 950 encoded in a MESSAGE_ID ACK object with the Refresh_NACK flag set. 951 When generating an Srefresh NACK, The epoch and Message_ID fields of 952 a MESSAGE_ID ACK object MUST have the same value as was received. 953 Objects with the Refresh_NACK flag set are transmitted as previously 954 described, see Section 3.4. 956 MESSAGE_ID ACK objects received with the Refresh_NACK flag set indi- 957 cate that the object generator does not have any installed state 958 matching the object. Upon receiving a MESSAGE_ID ACK object with the 959 Refresh_NACK flag set, the receiver performs an installed Path or 960 Resv state lookup based on the values contained in the object. If 961 matching state is found, then the receiver MUST transmit the matching 962 state via a standard Path or Resv message. If the receiver cannot 963 identify any installed state, then no action is required. 965 4.4. Compatibility 967 Nodes supporting the Summary Refresh extension advertise their sup- 968 port via the Summary_Capable flag in all MESSAGE_ID call objects 969 transmitted by the node. This enables supporting nodes to detect 970 each other. When it is not known if a next hop supports the exten- 971 sion, standard Path and Resv message based refreshes MUST be used. 972 Note that when the routing next hop does not support RSVP, it will 973 not always be possible to detect if the RSVP next hop supports the 974 Summary Refresh extension. Therefore, when the routing next hop is 975 not RSVP capable the Srefresh message based refresh SHOULD NOT be 976 used. A node MAY be administratively configured to use Srefresh mes- 977 sages in all cases when all RSVP nodes in a network are known to sup- 978 port the Summary Refresh extension. 980 Nodes supporting the Summary Refresh extension must also take care to 981 recognize when a next hop stops sending MESSAGE_ID objects with the 982 Summary_Capable flag set. To cover this case, nodes supporting the 983 Summary Refresh extension MUST examine each received Summary_Capable 984 flag. If the flag changes from indicating support to indicating non- 985 support then Srefresh messages MUST NOT be used for subsequent state 986 refreshes to that neighbor. 988 5. Hello Extension 990 The RSVP Hello extension enables RSVP nodes to detect a loss of a 991 neighboring node's state information. In standard RSVP, such detec- 992 tion occurs as a consequence of RSVP's soft state model. When 993 refresh message generation is suppressed via the previously discussed 994 Last_Refresh flag processing, the Hello extension is needed to 995 address this failure case. The Hello extensions is not intended to 996 provide a link failure detection mechanism, particularly in the case 997 of multiple parallel unnumbered links. 999 The Hello extension is specifically designed so that one side can use 1000 the mechanism while the other side does not. Neighbor RSVP state 1001 tracking may be initiated at any time. This includes when neighbors 1002 first learn about each other, or just when neighbors are sharing Resv 1003 or Path state. As previously stated, all implementations supporting 1004 state refresh suppression are required to also support the Hello 1005 Extension. 1007 The Hello extension is composed of a Hello message, a HELLO REQUEST 1008 object and a HELLO ACK object. Hello processing between two neigh- 1009 bors supports independent selection of, typically configured, failure 1010 detection intervals. Each neighbor can autonomously issue HELLO 1011 REQUEST objects. Each request is answered by an acknowledgment. 1012 Hello Messages also contain enough information so that one neighbor 1013 can suppress issuing hello requests and still perform neighbor fail- 1014 ure detection. A Hello message may be included as a sub-message 1015 within a bundle message. 1017 Neighbor state tracking is accomplished by collecting and storing a 1018 neighbor's state "instance" value. If a change in value is seen or 1019 if the neighbor is not properly reporting the locally advertised 1020 value, then the neighbor is presumed to have reset it's RSVP state. 1021 When communication is lost with a neighbor, then the instance value 1022 advertised to that neighbor is also changed. The HELLO objects pro- 1023 vide a mechanism for polling for and providing an RSVP state instance 1024 value. A poll request also includes the sender's instance value. 1025 This allows the receiver of a poll to optionally treat the poll as an 1026 implicit poll response. This optional handling is an optimization 1027 that can reduce the total number of polls and responses processed by 1028 a pair of neighbors. In all cases, when both sides support the opti- 1029 mization the result will be only one set of polls and responses per 1030 failure detection interval. Depending on selected intervals, the 1031 same benefit can occur even when only one neighbor supports the opti- 1032 mization. 1034 5.1. Hello Message Format 1036 Hello Messages are always sent between two RSVP neighbors. The IP 1037 source address is the IP address of the sending node. The IP desti- 1038 nation address is the IP address of the neighbor node. 1040 HELLO messages SHOULD be exchanged between immediate RSVP neighbors. 1041 When HELLO messages are being the exchanged between immediate neigh- 1042 bors, the IP TTL field of all outgoing HELLO messages SHOULD be set 1043 to 1. 1045 The Hello message format is as follows: 1047 ::= [ ] 1048 1050 For Hello messages, the Msg Type field of the Common Header MUST be 1051 set to 14 (Value to be assigned by IANA). 1053 5.2. HELLO Object 1055 HELLO Class = 22 (Value to be assigned by IANA of form 0bbbbbbb) 1057 HELLO REQUEST object 1059 Class = HELLO Class, C_Type = 1 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Src_Instance | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Dst_Instance | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 HELLO ACK object 1070 Class = HELLO Class, C_Type = 2 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Src_Instance | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Dst_Instance | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Src_Instance: 32 bits 1082 a 32 bit value that represents the sender's RSVP agent's state. 1083 The advertiser maintains a per neighbor representation/value. 1084 This value MUST change when the agent is reset, when the node 1085 reboots, or when communication is lost to the neighboring node 1086 and otherwise remains the same. This field MUST NOT be set to 1087 zero (0). 1089 Dst_Instance: 32 bits 1091 The most recently received Src_Instance value received from the 1092 neighbor. This field MUST be be set to zero (0) when no value 1093 has ever been seen from the neighbor. 1095 5.3. Hello Message Usage 1097 A Hello message containing a HELLO REQUEST object MUST be generated 1098 for each neighbor who's state is being tracked. When generating a 1099 message containing a HELLO REQUEST object, the sender fills in the 1100 Src_Instance field with a value representing it's per neighbor RSVP 1101 agent state. This value MUST NOT change while the agent is maintain- 1102 ing any RSVP state with the corresponding neighbor. The sender also 1103 fills in the Dst_Instance field with the Src_Instance value most 1104 recently received from the neighbor. If no value has ever been 1105 received from the neighbor, a value of zero (0) is used. The genera- 1106 tion of a message SHOULD be skipped when a HELLO REQUEST object was 1107 received from the destination node within the failure detection 1108 interval. 1110 On receipt of a message containing a HELLO REQUEST object, the 1111 receiver MUST generate a Hello message containing a HELLO ACK object. 1112 The receiver SHOULD also verify that the neighbor has not reset. 1113 This is done by comparing the sender's Src_Instance field value with 1114 the previously received value. If the value differs, than the neigh- 1115 bor has reset and all state associated with the neighbor MUST be 1116 "expired" and cleaned up per standard RSVP processing. Additionally, 1117 all Path state advertised to the neighbor MUST be refreshed. The 1118 receiver SHOULD also verify that the neighbor is reflecting back the 1119 receiver's Instance value. This is done by comparing the received 1120 Dst_Instance field with the Src_Instance field value most recently 1121 transmitted to that neighbor. If the neighbor continues to advertise 1122 a wrong non-zero value after a configured number of intervals, then a 1123 node MUST treat the neighbor as if communication has been lost. In 1124 this case all state associated with the neighbor MUST be "expired" 1125 and cleaned up per standard RSVP processing. Additionally, the 1126 Src_Instance value advertised in the HELLO ACK object MUST be be dif- 1127 ferent from the previously advertised value. This new value MUST 1128 continue to be advertised to the corresponding neighbor until a reset 1129 or reboot occurs, or until another communication failure is detected. 1131 On receipt of a message containing a HELLO ACK object, the receiver 1132 MUST verify that the neighbor has not reset. This is done by compar- 1133 ing the sender's Src_Instance field value with the previously 1134 received value. If the value differs, than the neighbor has reset 1135 and all state associated with the neighbor MUST be "expired" and 1136 cleaned up per standard RSVP processing. Additionally, all Path 1137 state advertised to the neighbor MUST be refreshed. The receiver 1138 MUST also verify that the neighbor is reflecting back the receiver's 1139 Instance value. If the neighbor advertises a wrong value in the 1140 Dst_Instance field, then a node MUST treat the neighbor as if commu- 1141 nication has been lost. In this case all state associated with the 1142 neighbor MUST be "expired" and cleaned up per standard RSVP 1143 processing. 1145 If no Instance values are received, via either REQUEST or ACK 1146 objects, from a neighbor within a configured number of failure detec- 1147 tion intervals, then a node MUST presume that it cannot communicate 1148 with the neighbor. When this occurs, all state associated with the 1149 neighbor MUST be "expired" and cleaned up per standard RSVP process- 1150 ing, and all Path state advertised to the neighbor MUST be refreshed. 1151 If any state is removed or needs to be refreshed as a result of this 1152 case, then a new HELLO message MUST be immediately issued with a 1153 Src_Instance value different then the one advertised in the previous 1154 HELLO message. This new value MUST continue to be advertised to the 1155 corresponding neighbor until a reset or reboot occurs, or until 1156 another communication failure is detected. 1158 5.4. Multi-Link Considerations 1160 As previously noted, the Hello extension is targeted at detecting 1161 node failures not per link failures. When there is only one link 1162 between neighboring nodes or when all links between a pair of nodes 1163 fail, the distinction between node and link failures is not really 1164 meaningful and handling of such failures has already been covered. 1165 When there are multiple links shared between neighbors, there are 1166 special considerations. When the links between neighbors are num- 1167 bered, then Hellos MUST be run on each link and the previously 1168 described mechanisms apply. 1170 When the links are unnumbered, link failure detection MUST be pro- 1171 vided by some means other than Hellos. Each node SHOULD use a single 1172 Hello exchange with the neighbor. When a node removes state due to a 1173 link failure, the node MUST advertise the removal of the state, via 1174 appropriate Tear messages, over a non-failed link. The case where 1175 all links have failed, is the same as the no received value case men- 1176 tioned in the previous section. 1178 5.5. Compatibility 1180 The Hello extension is fully backwards compatible. The Hello class 1181 is assigned a class value of the form 0bbbbbbb. Depending on the 1182 implementation, implementations that don't support the extension will 1183 either silently discard Hello messages or will respond with an 1184 "Unknown Object Class" error. In either case the sender will fail to 1185 see an acknowledgment for the issued Hello. When a Hello sender does 1186 not receive an acknowledgment, it MUST NOT send MESSAGE_ID objects 1187 with the Last_Refresh flag set. This restriction will preclude 1188 neighbors from getting out of RSVP state synchronization. 1190 Implementations supporting the Hello extension MUST also support the 1191 MESSAGE_ID extension and refresh suppression. 1193 6. Reference Exponential Back-Off Procedures 1195 This section is based on [Pan] and provides an example of how to 1196 implement exponential back-off. Implementations MAY choose to use 1197 the described procedures. 1199 6.1. Outline of Operation 1201 We propose the following feedback mechanism for exponential back-off 1202 retransmission of an RSVP message: When sending such a message, a 1203 node inserts a MESSAGE_ID object with the the ACK_Desired flag set. 1204 Upon reception, a receiving node acknowledges the arrival of the mes- 1205 sage by sending back an message acknowledgment (that is, a corre- 1206 sponding MESSAGE_ID ACK object.) When the sending node receives this 1207 message acknowledgment for a Path or Resv message, it will automati- 1208 cally scale back the retransmission rate for these messages for the 1209 flow. If the trigger message was for a different message type, no 1210 other further action is required. 1212 Until the message acknowledgment is received, the sending node will 1213 retransmit the message. The interval between retransmissions is gov- 1214 erned by a rapid retransmission timer. The rapid retransmission 1215 timer starts at a small interval which increases exponentially until 1216 it reaches a threshold. From that point on, the sending node will 1217 use a fixed timer to refresh Path and Resv messages and stop re- 1218 transmitting other messages. This mechanism is designed so that the 1219 message load is only slightly larger than in the current specifica- 1220 tion even when the receiving node does not support message acknowl- 1221 edgment. 1223 6.2. Time Parameters 1225 The described procedures make use of the following time parameters. 1226 All parameters are per interface. 1228 Rapid retransmission interval Rf: 1230 Rf is the initial retransmission interval for unacknowledged 1231 messages. After sending the message for the first time, the 1232 sending node will schedule a retransmission after Rf seconds. 1233 The value of Rf could be as small as the round trip time (RTT) 1234 between a sending and a receiving node, if known. Unless a node 1235 knows that all receiving nodes support echo-replies, a slightly 1236 larger configurable value is suggested. 1238 Slow refresh interval Rs: 1240 The sending node retransmits Path and Resv messages with this 1241 interval after it has determined that the receiving node will 1242 generate MESSAGE_ID ACK objects. To reduce the number of 1243 unnecessary retransmissions in a stable network, Rs can be set 1244 to a large value. The value of Rs should be configurable per 1245 each egress interface. 1247 Fixed retransmission interval R: 1249 A node retransmits the trigger message with the interval Rf*(1 + 1250 Delta)**i until the retransmission interval reaches the fixed 1251 retransmission interval R or a message acknowledgment has been 1252 received. If no acknowledgment has been received, the node 1253 continues to retransmit Resv and Path messages every R seconds. 1254 By default R should be the same value as the retransmission 1255 interval in the current RSVP specification. 1257 Increment value Delta: 1259 Delta governs the speed with which the sender increases the 1260 retransmission interval. The ratio of two successive 1261 retransmission intervals is (1 + Delta). 1263 6.3. Example Retransmission Algorithm 1265 After a sending node transmits a message containing a MESSAGE_ID 1266 object with the ACK_Desired flag set, it should immediately schedule 1267 a retransmission after Rf seconds. If a corresponding MESSAGE_ID ACK 1268 object is received earlier than Rf seconds, then retransmission 1269 SHOULD be canceled. Otherwise, it will retransmit the message after 1270 (1 + Delta)*Rf seconds. The staged retransmission will continue 1271 until either an appropriate MESSAGE_ID ACK object is received, or the 1272 retransmission interval has been increased to R. Once the retrans- 1273 mission interval has been increased to R, Path and Resv messages will 1274 be refreshed within the interval R. Other messages will not be 1275 retransmitted. 1277 The implementation of exponential back-off retransmission is simple. 1278 A sending node can use the following algorithm after transmitting a 1279 message containing a MESSAGE_ID object with the ACK_Desired flag set: 1281 if (Rk < R) { 1282 Rk = Rk * (1 + Delta); 1283 retransmit the message; 1284 wake up after Rk seconds; 1285 exit; 1286 } 1287 else { /* no reply from receivers for too long: */ 1288 Rk = R; 1289 if (message is a Path or Resv Message) { 1290 send out a refresh message; 1291 wake up after Rk seconds; 1292 exit; 1293 } 1294 else { 1295 clean up any associated state and resources; 1296 exit; 1297 } 1298 } 1300 Asynchronously, when a sending node receives a corresponding MES- 1301 SAGE_ID ACK object, it will change the retransmission interval Rk to 1302 Rs and, for non Path or Resv messages, clean up any associated state 1303 and resources. 1305 7. Acknowledgments 1307 This document represents ideas and comments from the MPLS-TE design 1308 team and participants in the RSVP Working Group's interim meeting. 1309 Thanks to Yoram Bernet, Fred Baker, Roch Guerin, Henning Schulzrinne, 1310 Andreas Terzis, David Mankins and Masanobu Yuhara for specific feed- 1311 back on the document. 1313 Portions of this work are based on work done by Masanobu Yuhara and 1314 Mayumi Tomikawa [Yuhara]. 1316 8. Security Considerations 1318 No new security issues are raised in this document. See [RFC2205] 1319 for a general discussion on RSVP security issues. 1321 9. References 1323 [Awduche] Awduche, D. et al. Requirements for Traffic Engineering 1324 over MPLS, Internet Draft, 1325 draft-awduche-mpls-traffic-eng-00.txt, April 1998. 1327 [Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP," 1328 Global Internet'97, Phoenix, AZ, Nov. 1997. 1329 http://www.ctr.columbia.edu/~pan/papers/timergi.ps 1331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1332 Requirement Levels," RFC 2119. 1334 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 1335 -- Version 1 Functional Specification", RFC 2205, 1336 September 1997. 1338 [Yuhara] Yuhara, M., Tomikawa, M. "RSVP Extensions for ID-based 1339 Refreshes," Internet Draft, 1340 draft-yuhara-rsvp-refresh-00.txt, April 1999. 1342 10. Authors' Addresses 1344 Lou Berger 1345 LabN Consulting 1346 Voice: +1 301 468 9228 1347 Email: lberger@labn.net 1349 Der-Hwa Gan 1350 Juniper Networks, Inc. 1351 385 Ravendale Drive 1352 Mountain View, CA 94043 1353 Voice: +1 650 526 8074 1354 Email: dhg@juniper.net 1356 George Swallow 1357 Cisco Systems, Inc. 1358 250 Apollo Drive 1359 Chelmsford, MA 01824 1360 Voice: +1 978 244 8143 1361 Email: swallow@cisco.com 1363 Ping Pan 1364 Bell Labs, Lucent 1365 101 Crawfords Corner Road, Room 4C-508 1366 Holmdel, NJ 07733 1367 USA 1368 Phone: +1 732 332 6744 1369 Email: pingpan@dnrc.bell-labs.com