idnits 2.17.1 draft-berger-rsvp-refresh-reduct-02.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 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 132 has weird spacing: '... enable refre...' == 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 (May 1999) is 9112 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- 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 (~~), 4 warnings (==), 6 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: November 1999 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 May 1999 12 RSVP Refresh Reduction Extensions 14 draft-berger-rsvp-refresh-reduct-02.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a number of mechanisms that reduce the 37 refresh overhead of RSVP. The extensions can be used to reduce 38 processing requirements of refresh messages, eliminate the state 39 synchronization latency incurred when an RSVP message is lost and, 40 when desired, suppress the generation of refresh messages. An 41 extension to support detection of when an RSVP neighbor resets its 42 state is also defined. These extension present no backwards 43 compatibility issues. 45 Contents 47 1 Introduction and Background ............................... 4 48 2 RSVP Bundle Message ....................................... 5 49 2.1 Bundle Header ............................................. 5 50 2.2 Message Formats ........................................... 6 51 2.3 Sending RSVP Bundle Messages .............................. 7 52 2.4 Receiving RSVP Bundle Messages ............................ 8 53 2.5 Forwarding RSVP Bundle Messages ........................... 9 54 2.6 Bundle-Capable Bit ........................................ 9 55 3 MESSAGE_ID Extension ...................................... 9 56 3.1 MESSAGE_ID Object ......................................... 10 57 3.2 Ack Message Format ........................................ 12 58 3.3 MESSAGE_ID Object Usage ................................... 13 59 3.4 MESSAGE_ID ACK Object Usage ............................... 16 60 3.5 Multicast Considerations .................................. 16 61 3.5.1 Reference RSVP/Routing Interface .......................... 18 62 3.6 Compatibility ............................................. 18 63 4 Summary Refresh Extension ................................. 19 64 4.1 Srefresh Message Format ................................... 19 65 4.2 Srefresh Message Usage .................................... 20 66 4.3 Srefresh NACK ............................................. 22 67 4.4 Compatibility ............................................. 22 68 5 Hello Extension ........................................... 23 69 5.1 Hello Message Format ...................................... 24 70 5.2 HELLO Object .............................................. 25 71 5.3 Hello Message Usage ....................................... 25 72 5.4 Multi-Link Considerations ................................. 26 73 5.5 Compatibility ............................................. 27 74 6 Acknowledgments ........................................... 27 75 7 Security Considerations ................................... 27 76 8 References ................................................ 28 77 9 Authors' Addresses ........................................ 28 79 1. Introduction and Background 81 The extensions described in this document were motivated by MPLS 82 traffic engineering requirements as described in [Awduche]. These 83 extensions may be generally useful and may be supported independent 84 of other MPLS related RSVP extensions or LSP tunnels. Portions of 85 this work are similar to earlier work done by Ping Pan and Henning 86 Schulzrinne [Pan]. Other portions are based on work done by Masanobu 87 Yuhara and Mayumi Tomikawa [Yuhara]. 89 The resource requirements (in terms of CPU processing and memory) for 90 running RSVP on a router increases proportionally with the number of 91 sessions. Supporting a large number of sessions can present scaling 92 problems. 94 This document describes mechanisms to help alleviate one set of scal- 95 ing issues. RSVP Path and Resv messages must be periodically 96 refreshed to maintain state. The approach described effectively 97 reduces the volume of messages which must be periodically sent and 98 received, as well as the resources required to process refresh mes- 99 sages. 101 The described mechanisms also address issues of latency and reliabil- 102 ity of RSVP Signaling. The latency and reliability problem occurs 103 when a non-refresh RSVP message is lost in transmission. Standard 104 RSVP [RFC2205] maintains state via the generation of RSVP refresh 105 messages. In the face of transmission loss of RSVP messages, the 106 end-to-end latency of RSVP signaling is tied to the refresh interval 107 of the node(s) experiencing the loss. When end-to-end signaling is 108 limited by the refresh interval, the establishment or change of a 109 reservation may be beyond the range of what is acceptable for some 110 applications. 112 One way to address the refresh volume problem is to increase the 113 refresh period, "R" as defined in section 3.7 of [RFC2205]. Increas- 114 ing the value of R provides linear improvement on transmission over- 115 head, but at the cost of increasing the time it takes to synchronize 116 state. 118 One way to address the latency and reliability of RSVP Signaling is 119 to decrease the refresh period R. Decreasing the value of R provides 120 increased probability that state will be installed in the face of 121 message loss, but at the cost of increasing refresh message rate and 122 associated processing requirements. 124 The extensions defined in this document address both the refresh vol- 125 ume and the reliability issues with mechanisms other than adjusting 126 refresh rate. A Bundle message is defined to reduce overall message 127 handling load. A Message_ID object is defined to reduce refresh mes- 128 sage processing by allowing the receiver to more readily identify an 129 unchanged message. A Message_ACK object is defined which can be used 130 to detect message loss and, when used in combination with the Mes- 131 sage_ID object, can be used to suppress refresh messages altogether. 132 A summary refresh message is defined to enable refreshing state 133 without the transmission of whole refresh messages, while maintaining 134 RSVP's ability to indicate when state is lost or when next hops 135 change. Finally, a hello protocol is defined to allow detection of 136 the loss of a neighbor node or a reset of it's RSVP state informa- 137 tion. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. RSVP Bundle Message 145 An RSVP Bundle message consists of a bundle header followed by a body 146 consisting of a variable number of standard RSVP messages. A Bundle 147 message is used to aggregated multiple RSVP messages within a single 148 PDU. The term "bundling" is used to avoid confusion with RSVP reser- 149 vation aggregation. The following subsections define the formats of 150 the bundle header and the rules for including standard RSVP messages 151 as part of the message. 153 2.1. Bundle Header 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Vers | Flags | Msg type | RSVP checksum | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Send_TTL | (Reserved) | RSVP length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 The format of the bundle header is identical to the format of the 164 RSVP common header [RFC2205]. The fields in the header are as fol- 165 lows: 167 Vers: 4 bits 169 Protocol version number. This is version 1. 171 Flags: 4 bits 173 0x01: Bundle capable 175 If set, indicates to RSVP neighbors that this node is willing 176 and capable of receiving bundle messages. This bit is mean- 177 ingful only between adjacent RSVP neighbors. 179 0x02-0x08: Reserved 181 Msg type: 8 bits 183 12 = Bundle 185 RSVP checksum: 16 bits 187 The one's complement of the one's complement sum of the entire 188 message, with the checksum field replaced by zero for the pur- 189 pose of computing the checksum. An all-zero value means that 190 no checksum was transmitted. Because individual sub-messages 191 carry their own checksum as well as the INTEGRITY object for 192 authentication, this field MAY be set to zero. 194 Send_TTL: 8 bits 196 The IP TTL value with which the message was sent. This is used 197 by RSVP to detect a non-RSVP hop by comparing the IP TTL that a 198 Bundle message sent to the TTL in the received message. 200 RSVP length: 16 bits 202 The total length of this RSVP Bundle message in bytes, includ- 203 ing the bundle header and the sub-messages that follow. 205 2.2. Message Formats 207 An RSVP Bundle message must contain at least one sub-message. A sub- 208 message MAY be any message type except for another Bundle message. 209 Current valid sub-messages are RSVP Path, PathTear, PathErr, Resv, 210 ResvTear, ResvErr, ResvConf, Ack or Hello messages. 212 Empty RSVP Bundle messages SHOULD NOT be sent. A Bundle message MUST 213 NOT include another RSVP Bundle message as a sub-message. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Vers | Flags | 12 | RSVP checksum | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Send_TTL | (Reserved) | RSVP length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 // First sub-message // 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 // More sub-messages.. // 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 2.3. Sending RSVP Bundle Messages 233 RSVP Bundle messages are sent hop by hop between RSVP-capable neigh- 234 bors as "raw" IP datagrams with protocol number 46. Raw IP datagrams 235 are also intended to be used between an end system and the first/last 236 hop router, although it is also possible to encapsulate RSVP messages 237 as UDP datagrams for end-system communication that cannot perform raw 238 network I/O. 240 RSVP Bundle messages MUST not be used if the next hop RSVP neighbor 241 does not support RSVP Bundle messages. Methods for discovering such 242 information include: (1) manual configuration and (2) observing the 243 Bundle-capable bit (see the description that follows) in the received 244 RSVP messages. If the next hop RSVP neighbor is not known or changes 245 in next hops cannot be identified via routing, Bundle messages MUST 246 NOT be sent. Note that when the routing next hop is not RSVP capable 247 it will typically not be possible to identify changes in next hop. 249 Support for RSVP Bundle messages is optional. While message bundling 250 helps in scaling RSVP, and in reducing processing overhead and band- 251 width consumption, a node is not required to transmit every standard 252 RSVP message in a Bundle message. A node MUST always be ready to 253 receive standard RSVP messages. 255 The IP source address is local to the system that originated the Bun- 256 dle message. The IP destination address is the next hop node for 257 which the sub-messages are intended. These addresses need not be 258 identical to those used if the sub-messages were sent as standard 259 RSVP messages. 261 For example, the IP source address of Path and PathTear messages is 262 the address of the sender it describes, while the IP destination 263 address is the DestAddress for the session. These end-to-end 264 addresses are overridden by hop-by-hop addresses while encapsulated 265 in a Bundle message. These addresses can easily be restored from the 266 SENDER_TEMPLATE and SESSION objects within Path and PathTear mes- 267 sages. For Path and PathTear messages, the next hop node can be 268 identified either via a received ACK or from a received corresponding 269 Resv message. Path and PathTear messages for multicast sessions MUST 270 NOT be sent in Bundle messages except when the outgoing interface is 271 a point-to-point interface and it is known that the next hop is RSVP 272 capable. 274 RSVP Bundle messages SHOULD NOT be sent with the Router Alert IP 275 option in their IP headers. This is because Bundle messages are 276 addressed directly to RSVP neighbors. 278 Each RSVP Bundle message MUST occupy exactly one IP datagram. If it 279 exceeds the MTU, the datagram is fragmented by IP and reassembled at 280 the recipient node. A single RSVP Bundle message MUST NOT exceed the 281 maximum IP datagram size, which is approximately 64K bytes. 283 2.4. Receiving RSVP Bundle Messages 285 If the local system does not recognize or does not wish to accept an 286 Bundle message, the received messages shall be discarded without fur- 287 ther analysis. 289 The receiver next compares the IP TTL with which a Bundle message is 290 sent to the TTL with which it is received. If a non-RSVP hop is 291 detected, the number of non-RSVP hops is recorded. It is used later 292 in processing of sub-messages. 294 Next, the receiver verifies the version number and checksum of the 295 RSVP Bundle message and discards the message if any mismatch is 296 found. 298 The receiver then starts decapsulating individual sub-messages. Each 299 sub-message has its own complete message length and authentication 300 information. Each sub-message is processed per standard RSVP. 302 2.5. Forwarding RSVP Bundle Messages 304 When an RSVP router receives a Bundle messages which is not addressed 305 to one of it's IP addresses, it SHALL forward the message. Non-RSVP 306 routers will treat RSVP Bundle messages as any other IP datagram. 308 When individual sub-messages are being forwarded, they MAY be encap- 309 sulated in another Bundle message before sending to the next hop 310 neighbor. The Send_TTL field in the sub-messages should be decre- 311 mented properly before transmission. 313 2.6. Bundle-Capable Bit 315 To support message bundling, an additional capability bit is added to 316 the common RSVP header, which is defined in [RFC2205]. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Vers | Flags | Msg Type | RSVP Checksum | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Send_TTL | (Reserved) | RSVP Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Flags: 4 bits 328 0x01: Bundle capable 330 If set, indicates to RSVP neighbors that this node is willing 331 and capable of receiving Bundle messages. This bit is mean- 332 ingful only between adjacent RSVP neighbors. 334 3. MESSAGE_ID Extension 336 Two new objects are defined as part of the MESSAGE_ID extension. The 337 two object types are the MESSAGE_ID object and the MESSAGE_ID ACK 338 object. The objects are used to support acknowledgments and, when 339 used in conjunction with the Hello Extension described in Section 5, 340 to indicate when refresh messages are not needed after an acknowledg- 341 ment. When refreshes are normally generated, the MESSAGE_ID object 342 can also be used to simply provide a shorthand indication of when a 343 message represents new state. Such information can be used on the 344 receiving node to reduce refresh processing requirements. 346 Message identification and acknowledgment is done on a hop-by-hop 347 basis. Acknowledgment is handled independent of SESSION or message 348 type. Both types of MESSAGE_ID objects contain a message identifier. 349 The identifier MUST be unique on a per source IP address basis across 350 messages sent by an RSVP node and received by a particular node. No 351 more than one MESSAGE_ID object may be included in an RSVP message. 352 Each message containing an MESSAGE_ID object may be acknowledged via 353 a MESSAGE_ID ACK object. MESSAGE_ID ACK objects may be sent piggy- 354 backed in unrelated RSVP messages or in RSVP Ack messages. 356 Either type of MESSAGE_ID object may be included in a bundle sub-mes- 357 sage. When included, the object is treated as if it were contained 358 in a standard, unbundled, RSVP message. Only one MESSAGE_ID object 359 MAY be included in a (sub)message and it MUST follow any present MES- 360 SAGE_ID ACK objects. When no MESSAGE_ID ACK objects are present, the 361 MESSAGE_ID object MUST immediately follow the INTEGRITY object. When 362 no INTEGRITY object is present, the MESSAGE_ID object MUST immedi- 363 ately follow the (sub)message header. 365 When present, one or more MESSAGE_ID ACK objects MUST immediately 366 follow the INTEGRITY object. When no INTEGRITY object is present, 367 the MESSAGE_ID ACK objects MUST immediately follow the the (sub)mes- 368 sage header. An MESSAGE_ID ACK object may only be included in a mes- 369 sage when the message's IP destination address matches the unicast 370 address of the node that generated the message(s) being acknowledged. 372 3.1. MESSAGE_ID Object 374 MESSAGE_ID Class = 166 (Value to be assigned by IANA of form 375 10bbbbbb) 377 MESSAGE_ID object 379 Class = MESSAGE_ID Class, C_Type = 1 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Flags | Epoch | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Message_ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Flags: 8 bits 390 0x80 = Summary_Capable flag 392 Indicates that the sender supports the summary refresh 393 extension. This flag MUST be set if the node supports the 394 summary refresh extension. See Section 4.4 for description 395 of handling by receiver. 397 0x40 = ACK_Desired flag 399 Indicates that the sender is willing to accept a message 400 acknowledgment. Acknowledgments MUST be silently ignored 401 when they are sent in response to messages whose 402 ACK_Desired flag is not set. This flag MUST be set when 403 the Last_Refresh flag is set. 405 0x20 = Last_Refresh flag 407 Used in Resv and Path refresh messages to indicate that the 408 sender will not be sending further refreshes. When set, 409 the ACK_Desired flag MUST also be set. This flag MUST NOT 410 be set when the HELLO messages are not being exchanged with 411 the neighboring RSVP node. 413 Epoch: 24 bits 415 A value that indicates when the Message_ID sequence has reset. 416 SHOULD be randomly generated each time a node reboots. This value 417 MUST NOT be changed during normal operation. 419 Message_ID: 32 bits 421 When combined with the message generator's IP address, the Message_ID 422 field uniquely identifies a message. This field is ordered and only 423 decreases in value when the Epoch changes or the value wraps. 425 MESSAGE_ID ACK object 427 Class = MESSAGE_ID Class, C_Type = 2 429 0 1 2 3 430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Flags | Epoch | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Message_ID | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Flags: 8 bits 439 0x80 = Summary_Capable flag 441 Indicates that the sender supports the summary refresh 442 extension. This flag MUST be set if the node supports the 443 summary refresh extension. See Section 4.4 for description 444 of handling by receiver. 446 0x40 = Refresh_NACK flag 448 Indicates that no state was found corresponding to the 449 indicated message identifier. This flag SHALL ONLY be set 450 when the matching Epoch and Message_ID field values were 451 received in a Summary Refresh message, and MUST NOT be set 452 in response to a MESSAGE_ID object received in any other 453 message. See Section 4 for details. 455 Epoch: 24 bits 457 The Epoch field copied from the message being acknowledged. 459 Message_ID: 32 bits 461 The Message_ID field copied from the message being acknowl- 462 edged. 464 3.2. Ack Message Format 466 Ack messages carry one or more MESSAGE_ID ACK objects. They MUST NOT 467 contain any MESSAGE_ID objects. Ack messages are sent hop-by-hop 468 between RSVP nodes. The IP destination address of an Ack message is 469 the unicast address of the node that generated the message(s) being 470 acknowledged. For Path, PathTear, Resv, and RervErr messages this is 471 taken from the RSVP_HOP Object. For PathErr and ResvErr messages 472 this is taken from the message's source address. The IP source 473 address is an address of the node that sends the Ack message. 475 The Ack message format is as follows: 477 ::= [ ] 478 479 [ ... ] 481 For Ack messages, the Msg Type field of the Common Header MUST be set 482 to 13 (Value to be assigned by IANA). 484 3.3. MESSAGE_ID Object Usage 486 The MESSAGE_ID object may be included in any RSVP message other than 487 the Ack message. The MESSAGE_ID object is always generated and pro- 488 cessed hop-by-hop. The IP address of the object generator is repre- 489 sented in a per RSVP message type specific fashion. For Path and 490 PathTear messages the generator's IP address is contained in the 491 RSVP_HOP. For Resv, ResvTear, PathErr, ResvErr, ResvConf and Bundle 492 messages the generator's IP address is the source address in the IP 493 header. 495 The Epoch field contains a generator selected value. The value is 496 used to indicate when the sender resets the values used in the Mes- 497 sage_ID field. This information is used by the receiver to detect 498 out of order messages. On startup, a node SHOULD randomly select a 499 value to be used in the Epoch field. The node SHOULD ensure that the 500 selected value is not the same as was used when the node was last 501 operational. The value MUST NOT be changed unless the node or the 502 RSVP agent is restarted. 504 The Message_ID field contains a generator selected value. This 505 value, when combined with the generator's IP address, identifies a 506 particular RSVP message and the specific state information it repre- 507 sents. When a node is sending a refresh message with a MESSAGE_ID 508 object, it SHOULD use the same Message_ID value that was used in the 509 RSVP message that first advertised the state being refreshed. When a 510 node is sending a message that represents new or changed state, the 511 Message_ID value MUST have a value that is greater than any other 512 previously used value. A value is considered to have been used when 513 it has been sent in any message using the associated IP address. 514 Note that this 32-bit value MAY wrap. 516 The ACK_Desired flag is set when the MESSAGE_ID object generator is 517 capable of accepting MESSAGE_ID ACK objects. Such information can be 518 used to ensure reliable delivery of error and confirm messages and to 519 support fast refreshes in the face of network loss. Nodes setting 520 the ACK_Desired flag SHOULD retransmit unacknowledged messages at a 521 more rapid interval than the standard refresh period until the mes- 522 sage is acknowledged or until a "rapid" retry limit is reached. 523 Rapid retransmission rate SHOULD be based on well known exponential 524 back-off procedures. See [Pan] for a details on one approach to 525 retransmission using exponential back-off. Note that nodes setting 526 the ACK_Desired flag for unicast sessions, do not need to track the 527 identify of the next hop since all that is expected is an ACK, not an 528 ACK from a specific next hop. Issues relate to multicast sessions 529 are covered in a later section. 531 The Last_Refresh flag may be set in Path and Resv messages when the 532 MESSAGE_ID object generator is exchanging Hello messages, described 533 in Section 5, with the next hop RSVP node. When a refresh message 534 with the Last_Refresh flag set is generated, normal refresh genera- 535 tion MUST continue until the message containing the Last_Refresh flag 536 is acknowledged. Although, messages removing state advertised in 537 such messages MUST be retransmit until acknowledged or a maximum 538 retry limit is reached in order to cover certain packet loss condi- 539 tions. Messages removing state include PathTear and ResvTear. 541 When sending MESSAGE_ID objects with the Last_Refresh flag set, spe- 542 cial care must be taken to properly advertise state. Specifically, 543 refresh processing MUST continue per standard RSVP processing until 544 after a acknowledgment is received. Suppression of refresh process- 545 ing MAY ONLY occur after an acknowledgment is received for a MES- 546 SAGE_ID object with the Last_Refresh flag set. Note that the 547 Last_Refresh flag MAY ONLY be set when the RSVP next hop is exchang- 548 ing Hello messages with the message generator. 550 When a Path message for a new session arrives, the RSVP next hop may 551 not always be known. When the RSVP next hop is not known, the 552 Last_Refresh flag MUST NOT be set. Once the next hop of a unicast 553 session is identified, only then may the Last_Refresh flag be set. 554 (Issues relate to multicast sessions are covered in a later section.) 555 There are several ways to identify the RSVP next hop of a new unicast 556 session. Some are more conservative than other, e.g., waiting for a 557 Resv message versus checking if the other end of a PPP link supports 558 Hello messages. Since there are no interoperability issues, the spe- 559 cific mechanism used to identify the RSVP next hop of a new session 560 is a specific implementation choice. In most implementations, it is 561 expected that an advertiser of Path state will do standard refresh 562 processing until either an ACK is received for a Path message adver- 563 tising a new session, or a corresponding Resv message is received. 565 Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a 566 newly received message is out of order and can be ignored. Out of 567 order messages can be identified by examining the values in the Epoch 568 and Message_ID fields. If the Epoch value differs from the value 569 previously received from the message sender, the receiver MUST fully 570 processes the message. If the Epoch values match and the Message_ID 571 value is greater than the largest value previously received from the 572 sender, the receiver MUST fully processes the message. If the value 573 is less than the largest value previously received from the sender, 574 then the receiver SHOULD check the value previously received for the 575 state associated with the message. This check should be performed 576 for the currently defined messages: Path, Resv, PathTear, ResvTear, 577 PathErr and ResvErr. If no local state information can be associated 578 with the message, the receiver MUST fully processes the message. If 579 local state can be associated with the message and the received Mes- 580 sage_ID value is less than the most recently received value associ- 581 ated with the state, the message SHOULD be ignored, i.e., silently 582 dropped. 584 Nodes receiving messages containing MESSAGE_ID objects SHOULD use the 585 information in the objects to aid in determining if a message repre- 586 sents new state or a state refresh. Note that state is only 587 refreshed in Path and Resv messages. If the received Epoch values 588 differs from the value previously received from the message sender, 589 the receiver MUST fully processes the message. If a Path or Resv 590 message contains the same Message_ID value that was used in the most 591 recently received message for the same session and, for Path mes- 592 sages, SENDER_TEMPLATE then the receiver SHOULD treat the message as 593 a state refresh. If the Message_ID value is grater than the most 594 recently received value, the receiver MUST fully processes the mes- 595 sage. If the Message_ID value is less than the most recently 596 received value, the receiver SHOULD ignore the message. 598 Nodes receiving a non-out of order message containing a MESSAGE_ID 599 object with the ACK_Desired flag set, SHOULD respond with a MES- 600 SAGE_ID ACK object. If a node supports the Hello extension it MUST 601 also check the Last_Refresh flag of received Resv and Path messages. 602 If the flag is set, the receiver MUST NOT timeout state associated 603 with associated message. The receiver MUST also be prepared to prop- 604 erly process refresh messages. Messages containing a MESSAGE_ID ACK 605 object with the Last_Refresh flag set MUST NOT be acknowledged when 606 either the receiving node doesn't support the Hello extension or 607 Hello messages aren't being exchanged with the message generator. 609 3.4. MESSAGE_ID ACK Object Usage 611 The MESSAGE_ID ACK object is used to acknowledge receipt of messages 612 containing MESSAGE_ID objects that were sent with the ACK_Desired 613 flag set. The Epoch and Message_ID fields of a MESSAGE_ID ACK object 614 MUST have the same value as was received. A MESSAGE_ID ACK object 615 MUST NOT be generated in response to a received MESSAGE_ID object 616 when the ACK_Desired flag is not set, except as noted in Section 4.3. 618 A MESSAGE_ID ACK object MAY be sent in any RSVP message that has an 619 IP destination address matching the generator of the associated MES- 620 SAGE_ID object. The MESSAGE_ID ACK object will not typically be 621 included in the non hop-by-hop Path, PathTear and ResvConf messages. 622 When no appropriate message is available, one or more MESSAGE_ID ACK 623 objects SHOULD be sent in an Ack message. Implementations SHOULD 624 include MESSAGE_ID ACK objects in standard RSVP messages when possi- 625 ble. 627 MESSAGE_ID ACK objects received with the Refresh_NACK flag set MUST 628 process the object as described in Section 4.3. Upon receiving a 629 MESSAGE_ID ACK object with the Refresh_NACK flag not set, a node 630 SHOULD stop retransmitting the message at the "rapid" retry rate. If 631 the received object also has the Last_Refresh flag set, normal 632 refresh generation SHOULD be suppressed for the associated state. As 633 previously mentioned, special care must be taken to properly adver- 634 tise state when sending MESSAGE_ID objects with the Last_Refresh flag 635 set, see section 3.3. 637 3.5. Multicast Considerations 639 Path and PathTear messages may be sent to IP multicast destination 640 addresses. When the destination is a multicast address, it is possi- 641 ble that a single message containing a single MESSAGE_ID object will 642 be received by multiple RSVP next hops. When the ACK_Desired flag is 643 set in this case, acknowledgment processing is more complex. There 644 are a number of issues to be addressed including ACK implosion, num- 645 ber acknowledgments to be expected and handling of new receivers. 647 ACK implosion occurs when each receiver responds to the MESSAGE_ID 648 object at approximately the same time. This can lead to a poten- 649 tially large number of MESSAGE_ID ACK objects being simultaneously 650 delivered to the message generator. To address this case, the 651 receiver MUST wait a random interval prior to acknowledging a MES- 652 SAGE_ID object received in a message destined to a multicast address. 653 The random interval SHOULD be between zero (0) and a configured maxi- 654 mum time. The configured maximum SHOULD be set in proportion to the 655 refresh and "rapid" retransmission interval, i.e, such that the 656 maximum back-off time does not result in retransmission. 658 A more fundamental issue is the number of acknowledgments that the 659 upstream node, i.e., the message generator, should expect. The num- 660 ber of acknowledgments that should be expected is the same as the 661 number of RSVP next hops. In the router-to-router case, the number 662 of next hops can usually be obtained from routing. When hosts are 663 either the upstream node or the next hops, the number of next hops 664 will typically not be readily available. Another case where the num- 665 ber of RSVP next hops will typically not be known is when there are 666 non-RSVP routers between the message generator and the RSVP next 667 hops. 669 When the number of next hops is not known, the message generator 670 SHOULD only expect a single response and MUST NOT set the 671 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 672 will be special retransmission handling until the message is deliv- 673 ered to at least one next hop, then followed by standard RSVP 674 refreshes. Standard refresh messages will synchronize state with any 675 next hops that don't receive the original message. 677 Another issue is handling new receivers. It is possible that after 678 sending a Path message and handling of expected number of acknowledg- 679 ments that a new receiver joins the group. In this case a new Path 680 message must be sent to the new receiver. When normal refresh pro- 681 cessing is occurring, there is no issue. When normal refresh pro- 682 cessing is suppressed, a Path message must still be generated. In 683 the router-to-router case, the identification of new next hops can 684 usually be obtained from routing. When hosts are either the upstream 685 node or the next hops, the identification of new next hops will typi- 686 cally not be possible. Another case where the identification of new 687 RSVP next hops will typically not be possible is when there are non- 688 RSVP routers between the message generator and the RSVP next hops. 690 When identification of new next hops is not possible, the message 691 generator SHOULD only expect a single response and MUST NOT set the 692 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 693 will be special retransmission handling until the message is deliv- 694 ered to at least one next hop, then followed by standard RSVP 695 refreshes. Standard refresh messages will synchronize state with any 696 next hops that don't receive the original message either due to loss 697 or not yet being a group member. 699 There is one additional minor issue with multiple next hops. The 700 issue is handling a combination of standard-refresh and non-refresh 701 next hops, i.e., Hello messages are being exchanged with some neigh- 702 boring nodes but not with others. When this case occurs, refreshes 703 MUST be generated per standard RSVP and the Last_Refresh flag MUST 704 NOT be set. 706 3.5.1. Reference RSVP/Routing Interface 708 When using the MESSAGE_ID extension with multicast sessions it is 709 preferable for RSVP to obtain the number of next hops from routing 710 and to be notified when that number changes. The interface between 711 routing and RSVP is purely an implementation issue. Since RSVP 712 [RFC2205] describes a reference routing interface, we present a ver- 713 sion of the RSVP/routing interface updated to provide number of next 714 hop information. See [RFC2205] for previously defined parameters and 715 function description. 717 o Route Query 718 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 719 Notify_flag ) 720 -> [ IncInterface, ] OutInterface_list, 721 NHops_list 723 o Route Change Notification 724 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 725 [ IncInterface, ] OutInterface_list, 726 NHops_list 728 NHops_list provides the number of multicast group members 729 reachable via each OutInterface_list entry. 731 3.6. Compatibility 733 There are no backward compatibility issues raised by the MESSAGE_ID 734 Class. The MESSAGE_ID Class has an assigned value whose form is 735 10bbbbbb. Per RSVP [RFC2205], classes with values of this form must 736 be ignored and not forwarded by nodes not supporting the class. When 737 the receiver of a MESSAGE_ID object does not support the class, the 738 object will be silently ignored. The generator of the MESSAGE_ID 739 object will not see any acknowledgments and therefore refresh mes- 740 sages per standard RSVP. Lastly, since the MESSAGE_ID ACK object can 741 only be issued in response to the MESSAGE_ID object, there are no 742 possible issues with this object or Ack messages. 744 Implementations supporting Path and Resv state refresh suppression 745 via the MESSAGE_ID object's Last_Refresh flag MUST also support the 746 Hello extension. Such implementations SHOULD initiate Hello process- 747 ing and MUST be able to respond to Hello messages. 749 4. Summary Refresh Extension 751 The Summary Refresh extension enables the refreshing of RSVP state 752 without the transmission of standard Path or Resv messages. The ben- 753 efits of the described extension are that it reduces the amount of 754 information that must be transmitted and processed in order to main- 755 tain RSVP state synchronization. Importantly, the described exten- 756 sion preserves RSVP's ability to handle non-RSVP next hops and to 757 adjust to changes in routing. This extension cannot be used with 758 Path or Resv messages that contain any change from previously trans- 759 mitted messages, i.e, are not refresh messages. 761 The summary refresh extension uses the previously defined MESSAGE_ID 762 object class, the ACK message, and a new Srefresh message. The new 763 message carries a list of MESSAGE_ID objects corresponding to the 764 Path and Resv states that are to be refreshed. An RSVP node receiv- 765 ing an Srefresh message, matches each received MESSAGE_ID object with 766 installed Path or Resv state. All matching state is updated as if a 767 normal RSVP refresh message is received. If matching state cannot be 768 found, then the Srefresh message sender is notified via a refresh 769 NACK. 771 Since Srefresh messages can carry multiple MESSAGE_ID objects, Sre- 772 fresh messages are not expected to be sent in an RSVP aggregate mes- 773 sages. The flags field of MESSAGE_ID objects carried in Srefresh 774 messages may be set. 776 A refresh NACK is indicated by setting the Refresh_NACK flag in the 777 MESSAGE_ID ACK object. The rules for sending a MESSAGE_ID ACK object 778 with the Refresh_NACK flag set are the same as was described in the 779 previous section. This includes sending MESSAGE_ID ACK object both 780 piggy-backed in unrelated RSVP messages or in RSVP ACK messages. 782 Nodes supporting the described extension can advertise their support 783 and detect if an RSVP neighbor also supports the extension. This is 784 accomplished via flag in the MESSAGE_ID class objects. 786 4.1. Srefresh Message Format 788 Srefresh messages carry one or more MESSAGE_ID objects. A single 789 Srefresh message MAY refresh both Path or Resv state. Srefresh mes- 790 sages carrying MESSAGE_ID objects corresponding to Path state SHOULD 791 be sent with a destination IP address equal to the address carried in 792 the corresponding SESSION objects. The destination IP address MAY be 793 set to the RSVP next hop when the next hop is known to be RSVP capa- 794 ble and the session is unicast or the outgoing interface is a point- 795 to-point interface. Srefresh messages carrying MESSAGE_ID objects 796 corresponding to Resv state MUST be sent with an destination IP 797 address set to the Resv state's previous hop. 799 The source IP address of an Srefresh message is an address of the 800 node that generates the message. The source IP address MUST match 801 the addressed associate with the MESSAGE_ID objects when they were 802 included in a standard RSVP message. As previously mentioned, the 803 address associate with a MESSAGE_ID object is represented in a per 804 RSVP message type specific fashion. For Path and PathTear messages 805 the associated IP address is contained in the RSVP_HOP. For Resv, 806 ResvTear, PathErr, ResvErr, ResvConf and Bundle messages the associ- 807 ated IP address is the source address in the IP header. 809 Srefresh messages that are sent destined to a session's destination 810 IP address MUST be sent the Router Alert IP option in their IP head- 811 ers. Srefresh messages addressed directly to RSVP neighbors SHOULD 812 NOT be sent with the Router Alert IP option in their IP headers. 814 Each Srefresh message MUST occupy exactly one IP datagram. If it 815 exceeds the MTU, the datagram is fragmented by IP and reassembled at 816 the recipient node. A single RSVP Srefresh message MUST NOT exceed 817 the maximum IP datagram size, which is approximately 64K bytes. 819 The Srefresh message format is as follows: 821 ::= [ ] 822 823 [ ... ] 825 For Srefresh messages, the Msg Type field of the Common Header MUST 826 be set to 14 (Value to be assigned by IANA). 828 4.2. Srefresh Message Usage 830 An Srefresh message MAY be generated to refresh Resv or Path state. 831 If an Srefresh message is used to refresh some particular state, then 832 the generation of a standard refresh message SHOULD be suppressed. A 833 state's refresh interval is not affected by the use of Srefresh mes- 834 sage based refreshes. An Srefresh message MUST NOT be used in place 835 of a Path or Resv message that would advertise a state change. 837 When generating an Srefresh message, a node SHOULD refresh as much 838 Path and Resv state as is possible by including as many MESSAGE_ID 839 objects in the same Srefresh message. Only MESSAGE_ID objects that 840 meet the previously described source and destination IP address 841 restrictions may be included in the same Srefresh message. Identify- 842 ing Resv state that can refreshed using the same Srefresh message is 843 fairly straightforward. Identifying which Path state may be included 844 is a little more complex. 846 Independent of the state being refreshed, only state that was previ- 847 ously advertised in Path and Resv messages containing MESSAGE_ID 848 objects can be refreshed via an Srefresh message. Srefresh message 849 based refreshes must also have the state synchronization properties 850 of Path or Resv message based refreshes. Specifically, the use of 851 Srefresh messages MUST NOT result in state being timed-out at the 852 RSVP next hop. The period at which state is refreshed when using 853 Srefresh messages MAY be shorter than the period that would be used 854 when using Path or Resv message based refreshes, but it MUST NOT be 855 longer. The particular approach used to trigger Srefresh message 856 based refreshes is implementation specific. Some possibilities are 857 triggering Srefresh message generation based on each state's refresh 858 period or, on a per interface basis, periodically generating Srefresh 859 messages to refresh all state that has not been refreshed within the 860 state's refresh interval. Other approaches are also possible. 862 When generating an Srefresh message, there are two methods for iden- 863 tifying which Path state may be refreshed in a specific message. In 864 both cases, the previously mentioned refresh interval and source IP 865 address restrictions must be followed. The primary method is to 866 include only those sessions that share the same destination IP 867 address in the same Srefresh message. When using this method, the 868 destination address of each session MUST be the same as the destina- 869 tion address in the IP header of the Srefresh message. 871 The secondary method for identifying which Path state may be 872 refreshed within a single Srefresh message is an optimization. This 873 method MAY be used when the next hop is known to support RSVP and 874 either the session is unicast or the outgoing interface is a point- 875 to-point interface. This method MUST NOT be used when the next hop 876 is not known to support RSVP or when the outgoing interface is to a 877 multi-access network and the session is to a multicast address. When 878 using this method, the destination address in the IP header of the 879 Srefresh message is always the next hop's address. When the outgoing 880 interface is a point-to-point interface, all Path state advertised 881 out the interface SHOULD be included in the same Srefresh message. 882 When the outgoing interface is not a point-to-point interface, all 883 unicast session Path state SHOULD be included in the same Srefresh 884 message. 886 Identifying which Resv state may be refreshed within a single Sre- 887 fresh message is based simply on the source and destination IP 888 addresses. Any state that was previously advertised in Resv messages 889 with the same IP addresses as an Srefresh message MAY be included. 891 After identifying the Path and Resv state that can be included in a 892 particular Srefresh message, the message generator adds to the mes- 893 sage a MESSAGE_ID object matching each identified state's previously 894 used object. Once the Srefresh message is composed, the message gen- 895 erator transmits the message out the proper interface. 897 Upon receiving an Srefresh message, a receiver MUST attempt to iden- 898 tify matching Path or Resv state. Matching is done based on the 899 source address in the IP header of the Srefresh message and each MES- 900 SAGE_ID object contained in the message. For each received MES- 901 SAGE_ID object, the receiver performs an installed state lookup based 902 on the values contained in the object. If matching state can be 903 found, then the receiver MUST update the matching state information 904 as if a standard refresh had been received. The receiver MUST also 905 process the flags contained in the MESSAGE_ID object per Sections 3 906 and 4.4. If the receiver cannot identify any matching installed 907 state, then a Srefresh NACK MUST be generated corresponding to the 908 unmatched MESSAGE_ID object. 910 4.3. Srefresh NACK 912 Srefresh NACKs are used to indicated that a received MESSAGE_ID 913 object does not match any installed state. An Srefresh NACK is 914 encoded in a MESSAGE_ID ACK object with the Refresh_NACK flag set. 915 When generating an Srefresh NACK, The epoch and Message_ID fields of 916 a MESSAGE_ID ACK object MUST have the same value as was received. 917 Objects with the Refresh_NACK flag set are transmitted as previously 918 described, see Section 3.4. 920 MESSAGE_ID ACK objects received with the Refresh_NACK flag set indi- 921 cate that the object generator does not have any installed state 922 matching the object. Upon receiving a MESSAGE_ID ACK object with the 923 Refresh_NACK flag set, the receiver performs an installed Path or 924 Resv state lookup based on the values contained in the object. If 925 matching state is found, then the receiver MUST transmit the matching 926 state via a standard Path or Resv message. If the receiver cannot 927 identify any installed state, then no action is required. 929 4.4. Compatibility 931 Nodes supporting the Summary Refresh extension advertise their sup- 932 port via the Summary_Capable flag in all MESSAGE_ID call objects 933 transmitted by the node. This enables supporting nodes to detect 934 each other. When it is not known if a next hop supports the exten- 935 sion, standard Path and Resv message based refreshes MUST be used. 936 Note that when the routing next hop does not support RSVP, it will 937 not always be possible to detect if the RSVP next hop supports the 938 Summary Refresh extension. Therefore, when the routing next hop is 939 not RSVP capable the Srefresh message based refresh SHOULD NOT be 940 used. A node MAY be administratively configured to use Srefresh mes- 941 sages in all cases when all RSVP nodes in a network are known to sup- 942 port the Summary Refresh extension. 944 Nodes supporting the Summary Refresh extension must also take care to 945 recognize when a next hop stops sending MESSAGE_ID objects with the 946 Summary_Capable flag set. To cover this case, nodes supporting the 947 Summary Refresh extension MUST examine each received Summary_Capable 948 flag. If the flag changes from indicating support to indicating non- 949 support then Srefresh messages MUST NOT be used for subsequent state 950 refreshes to that neighbor. 952 5. Hello Extension 954 The RSVP Hello extension enables RSVP nodes to detect a loss of a 955 neighboring node's state information. In standard RSVP, such detec- 956 tion occurs as a consequence of RSVP's soft state model. When 957 refresh message generation is suppressed via the previously discussed 958 Last_Refresh flag processing, the Hello extension is needed to 959 address this failure case. The Hello extensions is not intended to 960 provide a link failure detection mechanism, particularly in the case 961 of multiple parallel unnumbered links. 963 The Hello extension is specifically designed so that one side can use 964 the mechanism while the other side does not. Neighbor RSVP state 965 tracking may be initiated at any time. This includes when neighbors 966 first learn about each other, or just when neighbors are sharing Resv 967 or Path state. As previously stated, all implementations supporting 968 state refresh suppression are required to also support the Hello 969 Extension. 971 The Hello extension is composed of a Hello message, a HELLO REQUEST 972 object and a HELLO ACK object. Hello processing between two neigh- 973 bors supports independent selection of, typically configured, failure 974 detection intervals. Each neighbor can autonomously issue HELLO 975 REQUEST objects. Each request is answered by an acknowledgment. 976 Hello Messages also contain enough information so that one neighbor 977 can suppress issuing hello requests and still perform neighbor fail- 978 ure detection. A Hello message may be included as a sub-message 979 within a bundle message. 981 Neighbor state tracking is accomplished by collecting and storing a 982 neighbor's state "instance" value. If a change in value is seen, 983 then the neighbor is presumed to have reset it's RSVP state. When a 984 neighbor's value is seen to change or when communication is lost with 985 a neighbor, then the instance value advertised to that neighbor is 986 also changed. The HELLO objects provide a mechanism for polling for 987 and providing an RSVP state instance value. A poll request also 988 includes the sender's instance value. This allows the receiver of a 989 poll to optionally treat the poll as an implicit poll response. This 990 optional handling is an optimization that can reduce the total number 991 of polls and responses processed by a pair of neighbors. In all 992 cases, when both sides support the optimization the result will be 993 only one set of polls and responses per failure detection interval. 994 Depending on selected intervals, the same benefit can occur even when 995 only one neighbor supports the optimization. 997 5.1. Hello Message Format 999 Hello Messages are always sent between two RSVP neighbors. The IP 1000 source address is the IP address of the sending node. The IP desti- 1001 nation address is the IP address of the neighbor node. 1003 HELLO messages SHOULD be exchanged between immediate RSVP neighbors. 1004 When HELLO messages are being the exchanged between immediate neigh- 1005 bors, the IP TTL field of all outgoing HELLO messages SHOULD be set 1006 to 1. 1008 The Hello message format is as follows: 1010 ::= [ ] 1011 1013 For Hello messages, the Msg Type field of the Common Header MUST be 1014 set to 14 (Value to be assigned by IANA). 1016 5.2. HELLO Object 1018 HELLO Class = 22 (Value to be assigned by IANA of form 0bbbbbbb) 1020 HELLO REQUEST object 1022 Class = HELLO Class, C_Type = 1 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Instance | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 HELLO ACK object 1031 Class = HELLO Class, C_Type = 2 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Instance | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Instance: 32 bits 1041 a 32 bit value that represents the sender's RSVP agent's state. 1042 The advertiser maintains a per neighbor representation/value. 1043 This value MUST change when the agent is reset, when the node 1044 reboots, or when a failure of the neighboring node is detected 1045 and otherwise remains the same. This field MUST NOT be set to 1046 zero (0). 1048 5.3. Hello Message Usage 1050 A Hello message containing a HELLO REQUEST object MUST be generated 1051 for each neighbor who's state is being tracked. When generating a 1052 message containing a HELLO REQUEST object, the sender fills in the 1053 Instance field with a value representing it's per neighbor RSVP agent 1054 state. This value MUST NOT change while the agent is maintaining any 1055 RSVP state with the corresponding neighbor. The generation of a mes- 1056 sage SHOULD be skipped when a HELLO REQUEST object was received from 1057 the destination node within the failure detection interval. 1059 On receipt of a message containing a HELLO REQUEST object, the 1060 receiver MUST generate a Hello message containing a HELLO ACK object. 1061 The receiver SHOULD also verify that the neighbor has not reset. 1063 This is done by comparing the sender's Instance field value with the 1064 previously received value. If the value differs, than the neighbor 1065 has reset and all state associated with the neighbor MUST be 1066 "expired" and cleaned up per standard RSVP processing. Additionally, 1067 all Path state advertised to the neighbor MUST be refreshed. If any 1068 state is removed or needs to be refreshed as a result of detecting a 1069 change in a received Instance field value, then the value advertised 1070 in the HELLO ACK object MUST be be different from the previously 1071 advertised value. This new value MUST continue to be advertised to 1072 the corresponding neighbor until a reset or reboot occurs, or until 1073 another neighbor reset is detected. 1075 On receipt of a message containing a HELLO ACK object, the receiver 1076 MUST verify that the neighbor has not reset. This is done by compar- 1077 ing the sender's Instance field value with the previously received 1078 value. If the value differs, than the neighbor has reset and all 1079 state associated with the neighbor MUST be "expired" and cleaned up 1080 per standard RSVP processing. Additionally, all Path state adver- 1081 tised to the neighbor MUST be refreshed. If any state is removed or 1082 needs to be refreshed as a result of detecting a change in a received 1083 Instance field value, then a new HELLO message MUST be immediately 1084 issued with a value different then the one advertised in the previous 1085 HELLO message. This new value MUST continue to be advertised to the 1086 corresponding neighbor until a reset or reboot occurs, or until 1087 another neighbor reset is detected. 1089 If no Instance value is received, via either REQUEST or ACK objects, 1090 from a neighbor within a configured number of failure detection 1091 intervals, then a node MUST treat the neighbor as if it has reset. 1092 Specifically, all state associated with the neighbor MUST be 1093 "expired" and cleaned up per standard RSVP processing, and all Path 1094 state advertised to the neighbor MUST be refreshed. If any state is 1095 removed or needs to be refreshed as a result of this case, then a new 1096 HELLO message MUST be immediately issued with a value different then 1097 the one advertised in the previous HELLO message. This new value 1098 MUST continue to be advertised to the corresponding neighbor until a 1099 reset or reboot occurs, or until another neighbor reset is detected. 1101 5.4. Multi-Link Considerations 1103 As previously noted, the Hello extension is targeted at detecting 1104 node failures not per link failures. When there is only one link 1105 between neighboring nodes or when all links between a pair of nodes 1106 fail, the distinction between node and link failures is not really 1107 meaningful and handling of such failures has already been covered. 1108 When there are multiple links shared between neighbors, there are 1109 special considerations. When the links between neighbors are 1110 numbered, then Hellos MUST be run on each link and the previously 1111 described mechanisms apply. 1113 When the links are unnumbered, link failure detection MUST be pro- 1114 vided by some means other than Hellos. Each node SHOULD use a single 1115 Hello exchange with the neighbor. When a node removes state due to a 1116 link failure, the node MUST advertise the removal of the state, via 1117 appropriate Tear messages, over a non-failed link. The case where 1118 all links have failed, is the same as the no received value case men- 1119 tioned in the previous section. 1121 5.5. Compatibility 1123 The Hello extension is fully backwards compatible. The Hello class 1124 is assigned a class value of the form 0bbbbbbb. Depending on the 1125 implementation, implementations that don't support the extension will 1126 either silently discard Hello messages or will respond with an 1127 "Unknown Object Class" error. In either case the sender will fail to 1128 see an acknowledgment for the issued Hello. When a Hello sender does 1129 not receive an acknowledgment, it MUST NOT send MESSAGE_ID objects 1130 with the Last_Refresh flag set. This restriction will preclude 1131 neighbors from getting out of RSVP state synchronization. 1133 Implementations supporting the Hello extension MUST also support the 1134 MESSAGE_ID extension and refresh suppression. 1136 6. Acknowledgments 1138 This document represents ideas and comments from the MPLS-TE design 1139 team and participants in the RSVP Working Group's interim meeting. 1140 Thanks to Yoram Bernet, Fred Baker, Andreas Terzis and David Mankins 1141 for specific feedback on the document. 1143 7. Security Considerations 1145 No new security issues are raised in this document. See [RFC2205] 1146 for a general discussion on RSVP security issues. 1148 8. References 1150 [Awduche] Awduche, D. et al. Requirements for Traffic Engineering 1151 over MPLS, Internet Draft, 1152 draft-awduche-mpls-traffic-eng-00.txt, April 1998. 1154 [Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP," 1155 Global Internet'97, Phoenix, AZ, Nov. 1997. 1156 http://www.ctr.columbia.edu/~pan/papers/timergi.ps 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels," RFC 2119. 1161 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 1162 -- Version 1 Functional Specification", RFC 2205, 1163 September 1997. 1165 [Yuhara] Yuhara, M., Tomikawa, M. "RSVP Extensions for ID-based 1166 Refreshes," Internet Draft, 1167 draft-yuhara-rsvp-refresh-00.txt, April 1999. 1169 9. Authors' Addresses 1171 Lou Berger 1172 LabN Consulting 1173 Voice: +1 301 468 9228 1174 Email: lberger@tidalwave.net 1176 Der-Hwa Gan 1177 Juniper Networks, Inc. 1178 385 Ravendale Drive 1179 Mountain View, CA 94043 1180 Voice: +1 650 526 8074 1181 Email: dhg@juniper.net 1183 George Swallow 1184 Cisco Systems, Inc. 1185 250 Apollo Drive 1186 Chelmsford, MA 01824 1187 Voice: +1 978 244 8143 1188 Email: swallow@cisco.com