idnits 2.17.1 draft-berger-rsvp-refresh-reduct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 154 has weird spacing: '... and capab...' == Line 165 has weird spacing: '... of the entir...' == Line 167 has weird spacing: '...o value means...' == Line 168 has weird spacing: '... no check...' == Line 169 has weird spacing: '... object for...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 Aggregate messages MUST not be used if the next hop RSVP neighbor does not support RSVP Aggregate messages. Methods for discovering such information include: (1) manual configuration and (2) observing the Aggregate-capable bit (see the description that follows) in the received RSVP messages. -- 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 (March 1999) is 9175 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) == Unused Reference: 'RFC2119' is defined on line 769, 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' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lou Berger 2 Internet Draft FORE Systems, Inc. 3 Expiration Date: September 1999 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 March 1999 12 RSVP Refresh Reduction Extensions 14 draft-berger-rsvp-refresh-reduct-00.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 To view the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 31 Directory, see http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes a number of mechanisms that reduce the 36 refresh overhead of RSVP. The extensions can be used to reduce 37 processing requirements of refresh messages, eliminate the state 38 synchronization latency incurred when an RSVP message is lost and, 39 when desired, suppress the generation of refresh messages. An 40 extension to support detection of when an RSVP neighbor resets its 41 state is also defined. These extension present no backwards 42 compatibility issues. 44 Contents 46 1 Introduction and Background ............................ 3 47 2 RSVP Aggregate Message ................................. 4 48 2.1 Aggregate Header ....................................... 4 49 2.2 Message Formats ........................................ 5 50 2.3 Sending RSVP Aggregate Messages ........................ 6 51 2.4 Receiving RSVP Aggregate Messages ...................... 7 52 2.5 Forwarding RSVP Aggregate Messages ..................... 7 53 2.6 Aggregate-Capable Bit .................................. 7 54 3 MESSAGE_ID Extension ................................... 8 55 3.1 MESSAGE_ID Object ...................................... 9 56 3.2 Ack Message Format ..................................... 10 57 3.3 MESSAGE_ID Object Usage ................................ 10 58 3.4 MESSAGE_ID ACK Object Usage ............................ 12 59 3.5 Multicast Considerations ............................... 13 60 3.6 Compatibility .......................................... 14 61 4 Hello Extension ........................................ 15 62 4.1 Hello Message Format ................................... 16 63 4.2 HELLO Object ........................................... 16 64 4.3 Hello Message Usage .................................... 17 65 4.4 Compatibility .......................................... 17 66 5 Acknowledgments ........................................ 18 67 6 Security Considerations ................................ 18 68 7 References ............................................. 18 69 8 Authors' Addresses ..................................... 18 71 1. Introduction and Background 73 The extensions described in this document were motivated by MPLS 74 traffic engineering requirements as described in [Awduche]. These 75 extensions may be generally useful and may be supported independent 76 of other MPLS related RSVP extensions or LSP tunnels. 78 The resource requirements (in terms of cpu processing and memory) for 79 running RSVP on a router increases proportionally with the number of 80 sessions. Supporting a large number of sessions can present scaling 81 problems. 83 This document describes mechanisms to help alleviate one set of 84 scaling issues. RSVP Path and Resv messages must be periodically 85 refreshed to maintain state. The approach described effectively 86 reduces the volume of messages which must be periodically sent and 87 received. 89 The described mechanisms also address issues of latency and 90 reliability of RSVP Signaling. The latency and reliability problem 91 occurs when a non-refresh RSVP message is lost in transmission. 92 Standard RSVP [RFC2205] maintains state via the generation of RSVP 93 refresh messages. In the face of transmission loss of RSVP messages, 94 the end-to-end latency of RSVP signaling is tied to the refresh 95 interval of the node(s) experiencing the loss. When end-to-end 96 signaling is limited by the refresh interval, the establishment or 97 change of a reservation may be beyond the range of what is acceptable 98 for some applications. 100 One way to address the refresh volume problem is to increase the 101 refresh timer R. Increasing the value of R provides linear 102 improvement on transmission overhead, but at the cost of increasing 103 refresh timeout. 105 One way to address the latency and reliability of RSVP Signaling is 106 to decrease the refresh timer R. Decreasing the value of R provides 107 increased probability that state will be installed in the face of 108 message loss, but at the cost of increasing refresh message rate and 109 associated processing requirements. 111 The extensions defined in this document address both the refresh 112 volume and the reliability issues with mechanisms other than 113 adjusting refresh rate. An aggregate message is defined to reduce 114 overall message handing load. A Message_ID object is defined to 115 reduce refresh message processing by allowing the receiver to more 116 readily identify an unchanged message. A Message_ACK object is 117 defined which can be used to detect message loss and, when used in 118 combination with the Message_ID object, can be used to suppress 119 refresh messages altogether. Finally, a hello protocol is defined to 120 allow detection of the loss of a neighbor node or a reset of it's 121 RSVP state information. 123 2. RSVP Aggregate Message 125 An RSVP aggregate message consists of an aggregate header followed by 126 a body consisting of a variable number of standard RSVP messages. 127 The following subsections define the formats of the aggregate header 128 and the rules for including standard RSVP messages as part of the 129 message. 131 2.1. Aggregate Header 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Vers | Flags | Msg type | RSVP checksum | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Send_TTL | (Reserved) | RSVP length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 The format of the aggregate header is identical to the format of the 142 RSVP common header [RFC2205]. The fields in the header are as 143 follows: 145 Vers: 4 bits 147 Protocol version number. This is version 1. 149 Flags: 4 bits 151 0x01: Aggregate capable 153 If set, indicates to RSVP neighbors that this node is willing 154 and capable of receiving aggregate messages. This bit is 155 meaningful only between adjacent RSVP neighbors. 157 0x02-0x08: Reserved 159 Msg type: 8 bits 161 12 = Aggregate 163 RSVP checksum: 16 bits 165 The one's complement of the one's complement sum of the entire 166 message, with the checksum field replaced by zero for the pur- 167 pose of computing the checksum. An all-zero value means that 168 no checksum was transmitted. Because individual sub-messages 169 carry their own checksum as well as the INTEGRITY object for 170 authentication, this field MAY be set to zero. 172 Send_TTL: 8 bits 174 The IP TTL value with which the message was sent. This is used 175 by RSVP to detect a non-RSVP hop by comparing the IP TTL that 176 an Aggregate message sent to the TTL in the received message. 178 RSVP length: 16 bits 180 The total length of this RSVP aggregate message in bytes, in- 181 cluding the aggregate header and the sub-messages that follow. 183 2.2. Message Formats 185 An RSVP aggregate message must contain at least one sub-message. A 186 sub-message is one of the RSVP Path, PathTear, PathErr, Resv, 187 ResvTear, ResvErr, ResvConf, Ack or Hello messages. 189 Empty RSVP aggregate messages should not be sent. It is illegal to 190 include another RSVP aggregate message as a sub-message. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Vers | Flags | 12 | RSVP checksum | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Send_TTL | (Reserved) | RSVP length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 // First sub-message // 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 // More sub-messages.. // 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 2.3. Sending RSVP Aggregate Messages 210 RSVP Aggregate messages are sent hop by hop between RSVP-capable 211 neighbors as "raw" IP datagrams with protocol number 46. Raw IP 212 datagrams are also intended to be used between an end system and the 213 first/last hop router, although it is also possible to encapsulate 214 RSVP messages as UDP datagrams for end-system communication that 215 cannot perform raw network I/O. 217 RSVP Aggregate messages MUST not be used if the next hop RSVP 218 neighbor does not support RSVP Aggregate messages. Methods for 219 discovering such information include: (1) manual configuration and 220 (2) observing the Aggregate-capable bit (see the description that 221 follows) in the received RSVP messages. 223 Support for RSVP Aggregate messages is optional. While message 224 aggregation helps in scaling RSVP, and in reducing processing 225 overhead and bandwidth consumption, a node is not required to 226 transmit every standard RSVP message in an Aggregate message. A node 227 MUST always be ready to receive standard RSVP messages. 229 The IP source address is local to the system that originated the 230 Aggregate message. The IP destination address is the next hop node 231 for which the sub-messages are intended. These addresses need not be 232 identical to those used if the sub-messages were sent as standard 233 RSVP messages. 235 For example, the IP source address of Path and PathTear messages is 236 the address of the sender it describes, while the IP destination 237 address is the DestAddress for the session. These end-to-end 238 addresses are overridden by hop-by-hop addresses while encapsulated 239 in an Aggregate message. These addresses can easily be restored from 240 the SENDER_TEMPLATE and SESSION objects within Path and PathTear 241 messages. For Path and PathTear messages, the next hop node can be 242 identified either via a received ACK or from a received corresponding 243 Resv message. Path and PathTear messages for multicast sessions MUST 244 NOT be sent in Aggregate messages. 246 RSVP Aggregate messages SHOULD NOT be sent with the Router Alert IP 247 option in their IP headers. This is because Aggregate messages are 248 addressed directly to RSVP neighbors. 250 Each RSVP Aggregate message MUST occupy exactly one IP datagram. If 251 it exceeds the MTU, the datagram is fragmented by IP and reassembled 252 at the recipient node. A single RSVP Aggregate message MUST NOT 253 exceed the maximum IP datagram size, which is approximately 64K 254 bytes. 256 2.4. Receiving RSVP Aggregate Messages 258 If the local system does not recognize or does not wish to accept an 259 Aggregate message, the received messages shall be discarded without 260 further analysis. 262 The receiver next compares the IP TTL with which an Aggregate message 263 is sent to the TTL with which it is received. If a non-RSVP hop is 264 detected, the number of non-RSVP hops is recorded. It is used later 265 in processing of sub-messages. 267 Next, the receiver verifies the version number and checksum of the 268 RSVP aggregate message and discards the message if any mismatch is 269 found. 271 The receiver then starts decapsulating individual sub-messages. Each 272 sub-message has its own complete message length and authentication 273 information. Each sub-message is processed per standard RSVP. 275 2.5. Forwarding RSVP Aggregate Messages 277 When an RSVP router receives an Aggregate messages which is not 278 addressed to one of it's IP addresses, it SHALL forward the message. 279 Non-RSVP routers will treat RSVP Aggregate messages as any other IP 280 datagram. 282 When individual sub-messages are being forwarded, they MAY be 283 encapsulated in another aggregate message before sending to the next 284 hop neighbor. The Send_TTL field in the sub-messages should be 285 decremented properly before transmission. 287 2.6. Aggregate-Capable Bit 289 To support message aggregation, an additional capability bit is added 290 to the common RSVP header, which is defined in [RFC2205]. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Vers | Flags | Msg Type | RSVP Checksum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Send_TTL | (Reserved) | RSVP Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Flags: 4 bits 301 0x01: Aggregate capable 303 If set, indicates to RSVP neighbors that this node is willing 304 and capable of receiving aggregate messages. This bit is 305 meaningful only between adjacent RSVP neighbors. 307 3. MESSAGE_ID Extension 309 Two new objects are defined as part of the MESSAGE_ID extension. The 310 two object types are the MESSAGE_ID object and the MESSAGE_ID ACK 311 object. The objects are used to support acknowledgments and, when 312 used in conjunction with the Hello Extension described in Section 4, 313 to indicate when refresh messages are not needed after an 314 acknowledgment. When refreshes are normally generated, the 315 MESSAGE_ID object can also be used to simply provide a shorthand 316 indication of when a message represents new state. Such information 317 can be used on the receiving node to reduce refresh processing 318 requirements. 320 Message identification and acknowledgment is done on a hop-by-hop 321 basis. Acknowledgment is handled independent of SESSION or message 322 type. Both types of MESSAGE_ID objects contain a message identifier. 323 The identifier MUST be unique on a per source IP address basis across 324 messages sent by an RSVP node and received by a particular node. No 325 more than one MESSAGE_ID object may be included in an RSVP message. 326 Each message containing an MESSAGE_ID object may be acknowledged via 327 a MESSAGE_ID ACK object. MESSAGE_ID ACK objects may be sent 328 piggybacked in unrelated RSVP messages or in RSVP ACK messages 330 Either type of MESSAGE_ID object may be included in an aggregate 331 sub-message. When included, the object is treated as if it were 332 contained in a standard, unaggregated, RSVP message. Only one 333 MESSAGE_ID object MAY be included in a (sub)message and it MUST 334 follow any present MESSAGE_ID ACK objects. When no MESSAGE_ID ACK 335 objects are present, the MESSAGE_ID object MUST immediately follow 336 the INTEGRITY object. When no INTEGRITY object is present, the 337 MESSAGE_ID object MUST immediately follow the (sub)message header. 339 When present, one or more MESSAGE_ID ACK objects MUST immediately 340 follow the INTEGRITY object. When no INTEGRITY object is present, 341 the MESSAGE_ID ACK objects MUST immediately follow the the 342 (sub)message header. An MESSAGE_ID ACK object may only be included 343 in a message when the message's IP destination address matches the 344 unicast address of the node that generated the message(s) being 345 acknowledged. 347 3.1. MESSAGE_ID Object 349 MESSAGE_ID Class = 166 (Value to be assigned by IANA of form 350 10bbbbbb) 352 MESSAGE_ID object 354 Class = MESSAGE_ID Class, C_Type = 1 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flags | Message ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Flags: 8 bits 364 0x80 = ACK_Desired flag 366 Indicates that the sender is willing to accept a message 367 acknowledgment. Acknowledgments MUST be silently ignored 368 when they are sent in response to messages whose 369 ACK_Desired flag is not set. This flag MUST be set when 370 the Last_Refresh flag is set. 372 0x40 = Last_Refresh flag 374 Used in Resv and Path refresh messages to indicate that the 375 sender will not be sending further refreshes. When set, 376 the ACK_Desired flag MUST also be set. This flag MUST NOT 377 be set when the HELLO messages are not being exchanged with 378 the neighboring RSVP node. 380 Message ID: 24 bits 382 a 24-bit identifier. When combined with the message 383 generator's IP address, uniquely identifies a message. 385 MESSAGE_ID ACK object 387 Class = MESSAGE_ID Class, C_Type = 2 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Reserved | Message ID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Reserved 396 This field is reserved. It MUST be set to zero on transmis- 397 sion and MUST be ignored on receipt. 399 Message ID: 24 bits 401 a 24-bit identifier. When combined with the message 402 generator's IP address, uniquely identifies a message. 404 3.2. Ack Message Format 406 Ack messages carry one or more MESSAGE_ID ACK objects. They MUST NOT 407 contain any MESSAGE_ID objects. Ack messages are sent hop-by-hop 408 between RSVP nodes. The IP destination address of an Ack message is 409 the unicast address of the node that generated the message(s) being 410 acknowledged. For Path, PathTear, Resv, and RervErr messages this is 411 taken from the RSVP_HOP Object. For PathErr and ResvErr messages 412 this is taken from the message's source address. The IP source 413 address is an address of the node that sends the Ack message. 415 The Ack message format is as follows: 417 ::= [ ] 418 419 [ ... ] 421 For Ack messages, the Msg Type field of the Common Header MUST be set 422 to 13 (Value to be assigned by IANA). 424 3.3. MESSAGE_ID Object Usage 426 The MESSAGE_ID object may be included in any RSVP message other than 427 the Ack message. The MESSAGE_ID object is always generated and 428 processed hop-by-hop. The IP address of the object generator is 429 represented in a per RSVP message type specific fashion. For Path 430 and PathTear messages the generator's IP address is contained in the 431 RSVP_HOP. For Resv, ResvTear, PathErr, ResvErr, ResvConf and 432 Aggregate messages the generator's IP address is the source address 433 in the IP header. 435 The Message ID field contains a generator selected value. This 436 value, when combined with the generator's IP address, identifies a 437 particular RSVP message and the specific state information it 438 represents. When a node is sending a refresh message with a 439 MESSAGE_ID object, it SHOULD use the same Message ID value that was 440 used in the RSVP message that first advertised the state being 441 refreshed. When a node is sending a message that represents new or 442 changed state, the Message ID value MUST have a value that is not 443 otherwise in use. A value is considered to be in use when it has 444 been used in the most recent advertisement or refresh of any state 445 using the associated IP address. Care must also be taken to avoid 446 reuse of a previously used value during times of network loss. At 447 such times, the use of new values may not be noticed by receivers. 448 There is no requirement for Message ID values to be increasing or 449 ordered. 451 The ACK_Desired flag is set when the MESSAGE_ID object generator is 452 capable of accepting MESSAGE_ID ACK objects. Such information can be 453 used to ensure reliable delivery of error and confirm messages and to 454 support fast refreshes in the face of network loss. Nodes setting 455 the ACK_Desired flag SHOULD retransmit unacknowledged messages at a 456 faster interval than the standard refresh time until the message is 457 acknowledged or a "fast" retry limit is reached. Note that nodes 458 setting the ACK_Desired flag for unicast sessions, do not need to 459 track the identify of the next hop since all that is expected is an 460 ACK, not an ACK from a specific next hop. Issues relate to multicast 461 sessions are covered in a later section. 463 The Last_Refresh flag may be set in Path and Resv messages when the 464 MESSAGE_ID object generator is exchanging Hello messages, described 465 in Section 4, with the next hop RSVP node. When a refresh message 466 with the Last_Refresh flag set is generated, normal refresh 467 generation MUST continue until the message containing the 468 Last_Refresh flag is acknowledged. Although, messages removing state 469 advertised in such messages MUST be retransmit until acknowledged or 470 a maximum retry limit is reached in order to cover certain packet 471 loss conditions. Messages removing state include PathTear and 472 ResvTear. 474 When sending MESSAGE_ID objects with the Last_Refresh flag set, 475 special care must be taken to properly advertise state. 476 Specifically, refresh processing MUST continue per standard RSVP 477 processing until after a acknowledgment is received. Suppression of 478 refresh processing MAY ONLY occur after an acknowledgment is received 479 for a MESSAGE_ID object with the Last_Refresh flag set. Note that 480 the Last_Refresh flag MAY ONLY be set when the RSVP next hop is 481 exchanging Hello messages with the message generator. 483 When a Path message for a new session arrives, the RSVP next hop may 484 not always be known. When the RSVP next hop is not known, the 485 Last_Refresh flag MUST NOT be set. Once the next hop of a unicast 486 session is identified, only then may the Last_Refresh flag be set. 487 (Issues relate to multicast sessions are covered in a later section.) 488 There are several ways to identify the RSVP next hop of a new unicast 489 session. Some are more conservative than other, e.g., waiting for a 490 Resv message versus checking if the other end of a PPP link supports 491 Hello messages. Since there are no interoperability issues, the 492 specific mechanism used to identify the RSVP next hop of a new 493 session is a specific implementation choice. In most 494 implementations, it is expected that an advertiser of Path state will 495 do standard refresh processing until either an ACK is received for a 496 Path message advertising a new session, or a corresponding Resv 497 message is received. 499 Nodes receiving messages containing MESSAGE_ID objects SHOULD use the 500 information in the objects to aid in determining if a message 501 represents new state or a state refresh. Note that state is only 502 refreshed in Path and Resv messages. If a Path or Resv message 503 contains the same Message_ID value that was used in the most recently 504 received message for the same session and, for Path messages, 505 SENDER_TEMPLATE then the receiver SHOULD treat the message as a state 506 refresh. If the Message ID value differs from the most recently 507 received value, the receiver MUST fully processes the message. 509 Nodes receiving a message containing a MESSAGE_ID object with the 510 ACK_Desired flag set, SHOULD respond with a MESSAGE_ID ACK object. 511 If a node supports the Hello extension it MUST also check the 512 Last_Refresh flag of received Resv and Path messages. If the flag is 513 set, the receiver MUST NOT timeout state associated with associated 514 message. The receiver MUST also be prepared to properly process 515 refresh messages. Messages containing a MESSAGE_ID ACK object with 516 the Last_Refresh flag set MUST NOT be acknowledged when either the 517 receiving node doesn't support the Hello extension or Hello messages 518 aren't being exchanged with the message generator. 520 3.4. MESSAGE_ID ACK Object Usage 522 The MESSAGE_ID ACK object is used to acknowledge receipt of messages 523 containing MESSAGE_ID objects that were sent with the ACK_Desired 524 flag set. The Message ID field of a MESSAGE_ID ACK object MUST have 525 the same value as was received. A MESSAGE_ID ACK object MUST NOT be 526 generated in response to a received MESSAGE_ID object when the 527 ACK_Desired flag is not set. 529 A MESSAGE_ID ACK object MAY be sent in any RSVP message that has an 530 IP destination address matching the generator of the associated 531 MESSAGE_ID object. The MESSAGE_ID ACK object will not typically be 532 included in the non hop-by-hop Path, PathTear and ResvConf messages. 533 When no appropriate message is available, one or more MESSAGE_ID ACK 534 objects SHOULD be sent in an Ack message. Implementations SHOULD 535 include MESSAGE_ID ACK objects in standard RSVP messages when 536 possible. 538 Upon receiving a MESSAGE_ID ACK object for a message generated with a 539 MESSAGE_ID object with the Last_Refresh flag set, normal refresh 540 generation SHOULD be suppressed for the associated state. As 541 previously mentioned, special care must be taken to properly 542 advertise state when sending MESSAGE_ID objects with the Last_Refresh 543 flag set, see section 3.3. 545 3.5. Multicast Considerations 547 Path and PathTear messages may be sent to IP multicast destination 548 addresses. When the destination is a multicast address, it is 549 possible that a single message containing a single MESSAGE_ID object 550 will be received by multiple RSVP next hops. When the ACK_Desired 551 flag is set in this case, acknowledgment processing is more complex. 552 There are a number of issues to be addressed including ACK implosion, 553 number acknowledgments to be expected and handling of new receivers. 555 ACK implosion occurs when each receiver responds to the MESSAGE_ID 556 object at approximately the same time. This can lead to a 557 potentially large number of MESSAGE_ID ACK objects being 558 simultaneously delivered to the message generator. To address this 559 case, the receiver MUST wait a random interval prior to acknowledging 560 a MESSAGE_ID object received in a message destined to a multicast 561 address. The random interval SHOULD be between zero (0) and a 562 configured maximum time. The configured maximum SHOULD be set in 563 proportion to the refresh and "fast" retransmission interval. 565 A more fundamental issue is the number of acknowledgments that the 566 upstream node, i.e., the message generator, should expect. The 567 number of acknowledgments that should be expected is the same as the 568 number of RSVP next hops. In the router-to-router case, the number 569 of next hops can usually be obtained from routing. When hosts are 570 either the upstream node or the next hops, the number of next hops 571 will typically not be readily available. When the number of next 572 hops is not known, the message generator SHOULD only expect a single 573 response and MUST NOT set the Last_Refresh flag in MESSAGE_ID 574 objects. The result of this behavior will be special retransmission 575 handling until the message is delivered to at least one next hop, 576 then followed by standard RSVP refreshes. Standard refresh messages 577 will synchronize state with any next hops that don't receive the 578 original message. 580 Another issue is handling new receivers. It is possible that after 581 sending a Path message and handling of expected number of 582 acknowledgments that a new receiver joins the group. In this case a 583 new Path message must be sent to the new receiver. When normal 584 refresh processing is occurring, there is no issue. When normal 585 refresh processing is suppressed, a Path message must still be 586 generated. In the router-to-router case, the identification of new 587 next hops can usually be obtained from routing. When hosts are 588 either the upstream node or the next hops, the identification of new 589 next hops will typically not be possible. When identification of new 590 next hops is not possible, the message generator SHOULD only expect a 591 single response and MUST NOT set the Last_Refresh flag in MESSAGE_ID 592 objects. The result of this behavior will be special retransmission 593 handling until the message is delivered to at least one next hop, 594 then followed by standard RSVP refreshes. Standard refresh messages 595 will synchronize state with any next hops that don't receive the 596 original message either due to loss or not yet being a group member. 598 There is one additional minor issue with multiple next hops. The 599 issue is handling a combination of standard-refresh and non-refresh 600 next hops, i.e., Hello messages are being exchanged with some 601 neighboring nodes but not with others. When this case occurs, 602 refreshes MUST be generated per standard RSVP and the Last_Refresh 603 flag MUST NOT be set. 605 3.6. Compatibility 607 There are no backward compatibility issues raised by the MESSAGE_ID 608 Class. The MESSAGE_ID Class has an assigned value whose form is 609 10bbbbbb. Per RSVP [RFC2205], classes with values of this form must 610 be ignored and not forwarded by nodes not supporting the class. When 611 the receiver of a MESSAGE_ID object does not support the class, the 612 object will be silently ignored. The generator of the MESSAGE_ID 613 object will not see any acknowledgments and therefore refresh 614 messages per standard RSVP. Lastly, since the MESSAGE_ID ACK object 615 can only be issued in response to the MESSAGE_ID object, there are no 616 possible issues with this object or Ack messages. 618 Implementations supporting Path and Resv state refresh suppression 619 via the MESSAGE_ID object's Last_Refresh flag MUST also support the 620 Hello extension. 622 4. Hello Extension 624 The RSVP Hello extension enables RSVP nodes to detect a loss of a 625 neighboring node's state information. In standard RSVP, such 626 detection occurs as a consequence of RSVP's soft state model. When 627 refresh message generation is suppressed via the previously discussed 628 Last_Refresh flag processing, the Hello extension is needed to 629 address this failure case. The Hello extensions is not intended to 630 provide a link failure detection mechanism, particularly in the case 631 of multiple parallel unnumbered links. 633 The Hello extension is specifically designed so that one side can use 634 the mechanism while the other side does not. Neighbor RSVP state 635 tracking may be initiated at any time. This includes when neighbors 636 first learn about each other, or just when neighbors are sharing Resv 637 or Path state. As previously stated, all implementations supporting 638 state refresh suppression MUST also support the Hello Extension. 639 Such implementations SHOULD initiate Hello processing and MUST be 640 able to respond to Hello messages. 642 The Hello extension is composed of a Hello message, a HELLO REQUEST 643 object and a HELLO ACK object. Hello processing between two 644 neighbors supports independent selection of, typically configured, 645 failure detection intervals. Each neighbor can autonomously issue 646 HELLO REQUEST objects. Each request is answered by an 647 acknowledgment. Hello Messages also contain enough information so 648 that one neighbor can suppress issuing hello requests and still 649 perform neighbor failure detection. A Hello message may be included 650 as a sub-message within an aggregate message. 652 Neighbor state tracking is accomplished by collecting and storing a 653 neighbor's state "instance" value. If a change in value is seen, 654 then the neighbor is presumed to have reset it's RSVP state. The 655 HELLO objects provide a mechanism for polling for and providing an 656 RSVP state instance value. A poll request also includes the sender's 657 instance value. This allows the receiver of a poll to optionally 658 treat the poll as an implicit poll response. This optional handling 659 is an optimization that can reduce the total number of polls and 660 responses processed by a pair of neighbors. In all cases, when both 661 sides support the optimization the result will be only one set of 662 polls and responses per failure detection interval. Depending on 663 selected intervals, the same benefit can occur even when only one 664 neighbor supports the optimization. 666 4.1. Hello Message Format 668 Hello Messages are always sent between two RSVP neighbors. The IP 669 source address is the IP address of the sending node. The IP 670 destination address is the IP address of the neighbor node. 672 The Hello message format is as follows: 674 ::= [ ] 675 677 For Hello messages, the Msg Type field of the Common Header MUST be 678 set to 14 (Value to be assigned by IANA). 680 4.2. HELLO Object 682 HELLO Class = 22 (Value to be assigned by IANA of form 0bbbbbbb) 684 HELLO REQUEST object 686 Class = HELLO Class, C_Type = 1 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Instance | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 HELLO ACK object 695 Class = HELLO Class, C_Type = 2 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Instance | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Instance: 32 bits 705 a 32 bit value that represents the sender's RSVP agent's state. 706 This value must change when the agent is reset or the node 707 reboots and otherwise remains the same. This field MUST NOT be 708 set to zero (0). 710 4.3. Hello Message Usage 712 A Hello message containing a HELLO REQUEST object MUST be generated 713 for each neighbor who's state is being tracked. When generating a 714 message containing a HELLO REQUEST object, the sender fills in the 715 Instance field with a value representing it's RSVP agent state. This 716 value MUST NOT change while the agent is maintaining any RSVP state. 717 The generation of a message SHOULD be skipped when a HELLO REQUEST 718 object was received from the destination node within the failure 719 detection interval. 721 On receipt of a message containing a HELLO REQUEST object, the 722 receiver MUST generate a Hello message containing a HELLO ACK object. 723 The receiver SHOULD also verify that the neighbor has not reset. 724 This is done by comparing the sender's Instance field value with the 725 previously received value. If the value differs, than the neighbor 726 has reset and all state associated with the neighbor MUST be 727 "expired" and cleaned up per standard RSVP processing. Additionally, 728 all Path state advertised to the neighbor MUST be refreshed. 730 On receipt of a message containing a HELLO ACK object, the receiver 731 MUST verify that the neighbor has not reset. This is done by 732 comparing the sender's Instance field value with the previously 733 received value. If the value differs, than the neighbor has reset 734 and all state associated with the neighbor MUST be "expired" and 735 cleaned up per standard RSVP processing. Additionally, all Path 736 state advertised to the neighbor MUST be refreshed. 738 4.4. Compatibility 740 The Hello extension is fully backwards compatible. The Hello class 741 is assigned a class value of the form 0bbbbbbb. Depending on the 742 implementation, implementations that don't support the extension will 743 either silently discard Hello messages or will respond with an 744 "Unknown Object Class" error. In either case the sender will fail to 745 see an acknowledgment for the issued Hello. When a Hello sender does 746 not receive an acknowledgment, it MUST NOT send MESSAGE_ID objects 747 with the Last_Refresh flag set. This restriction will preclude 748 neighbors from getting out of RSVP state synchronization. 750 Implementations supporting the Hello extension MUST also support the 751 MESSAGE_ID extension and refresh suppression. 753 5. Acknowledgments 755 This document represents ideas and comments from the MPLS-TE design 756 team. Thanks to Yoram Bernet and Fred Baker for the good feedback. 758 6. Security Considerations 760 No new security issues are raised in this document. See [RFC2205] 761 for a general discussion on RSVP security issues. 763 7. References 765 [Awduche] Awduche, D. et al. Requirements for Traffic Engineering 766 over MPLS, Internet Draft, 767 draft-awduche-mpls-traffic-eng-00.txt, April 1998. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels," RFC 2119. 772 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 773 -- Version 1 Functional Specification", RFC 2205, 774 September 1997. 776 8. Authors' Addresses 778 Lou Berger 779 FORE Systems 780 1595 Spring Hill Road, Suite 500 781 Vienna, VA 22182 782 Voice: +1 703 245 4527 783 Email: lberger@fore.com 785 Der-Hwa Gan 786 Juniper Networks, Inc. 787 385 Ravendale Drive 788 Mountain View, CA 94043 789 Voice: +1 650 526 8074 790 Email: dhg@juniper.net 792 George Swallow 793 Cisco Systems, Inc. 794 250 Apollo Drive 795 Chelmsford, MA 01824 796 Voice: +1 978 244 8143 797 Email: swallow@cisco.com