idnits 2.17.1 draft-berger-rsvp-refresh-reduct-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- == 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 neigh-bor does not support RSVP Aggregate messages. Methods for discover-ing such information include: (1) manual configuration and (2) observing the Aggregate-capable bit (see the description that fol-lows) 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 (April 1999) is 9133 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 849, 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 (~~), 4 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 LabN Consulting 3 Expiration Date: October 1999 4 Der-Hwa Gan 5 Juniper Networks, Inc. 7 George Swallow 8 Cisco Systems, Inc. 10 April 1999 12 RSVP Refresh Reduction Extensions 14 draft-berger-rsvp-refresh-reduct-01.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 ................................... 11 58 3.4 MESSAGE_ID ACK Object Usage ............................... 13 59 3.5 Multicast Considerations .................................. 13 60 3.5.1 Reference RSVP/Routing Interface .......................... 15 61 3.6 Compatibility ............................................. 15 62 4 Hello Extension ........................................... 16 63 4.1 Hello Message Format ...................................... 17 64 4.2 HELLO Object .............................................. 17 65 4.3 Hello Message Usage ....................................... 18 66 4.4 Multi-Link Considerations ................................. 19 67 4.5 Compatibility ............................................. 19 68 5 Acknowledgments ........................................... 20 69 6 Security Considerations ................................... 20 70 7 References ................................................ 20 71 8 Authors' Addresses ........................................ 20 73 1. Introduction and Background 75 The extensions described in this document were motivated by MPLS 76 traffic engineering requirements as described in [Awduche]. These 77 extensions may be generally useful and may be supported independent 78 of other MPLS related RSVP extensions or LSP tunnels. 80 The resource requirements (in terms of cpu processing and memory) for 81 running RSVP on a router increases proportionally with the number of 82 sessions. Supporting a large number of sessions can present scaling 83 problems. 85 This document describes mechanisms to help alleviate one set of scal- 86 ing issues. RSVP Path and Resv messages must be periodically 87 refreshed to maintain state. The approach described effectively 88 reduces the volume of messages which must be periodically sent and 89 received. 91 The described mechanisms also address issues of latency and reliabil- 92 ity of RSVP Signaling. The latency and reliability problem occurs 93 when a non-refresh RSVP message is lost in transmission. Standard 94 RSVP [RFC2205] maintains state via the generation of RSVP refresh 95 messages. In the face of transmission loss of RSVP messages, the 96 end-to-end latency of RSVP signaling is tied to the refresh interval 97 of the node(s) experiencing the loss. When end-to-end signaling is 98 limited by the refresh interval, the establishment or change of a 99 reservation may be beyond the range of what is acceptable for some 100 applications. 102 One way to address the refresh volume problem is to increase the 103 refresh timer R. Increasing the value of R provides linear improve- 104 ment on transmission overhead, but at the cost of increasing refresh 105 timeout. 107 One way to address the latency and reliability of RSVP Signaling is 108 to decrease the refresh timer R. Decreasing the value of R provides 109 increased probability that state will be installed in the face of 110 message loss, but at the cost of increasing refresh message rate and 111 associated processing requirements. 113 The extensions defined in this document address both the refresh vol- 114 ume and the reliability issues with mechanisms other than adjusting 115 refresh rate. An aggregate message is defined to reduce overall mes- 116 sage handing load. A Message_ID object is defined to reduce refresh 117 message processing by allowing the receiver to more readily identify 118 an unchanged message. A Message_ACK object is defined which can be 119 used to detect message loss and, when used in combination with the 120 Message_ID object, can be used to suppress refresh messages 121 altogether. Finally, a hello protocol is defined to allow detection 122 of the loss of a neighbor node or a reset of it's RSVP state informa- 123 tion. 125 2. RSVP Aggregate Message 127 An RSVP aggregate message consists of an aggregate header followed by 128 a body consisting of a variable number of standard RSVP messages. 129 The following subsections define the formats of the aggregate header 130 and the rules for including standard RSVP messages as part of the 131 message. 133 2.1. Aggregate Header 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Vers | Flags | Msg type | RSVP checksum | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Send_TTL | (Reserved) | RSVP length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 The format of the aggregate header is identical to the format of the 144 RSVP common header [RFC2205]. The fields in the header are as fol- 145 lows: 147 Vers: 4 bits 149 Protocol version number. This is version 1. 151 Flags: 4 bits 153 0x01: Aggregate capable 155 If set, indicates to RSVP neighbors that this node is willing 156 and capable of receiving aggregate messages. This bit is 157 meaningful only between adjacent RSVP neighbors. 159 0x02-0x08: Reserved 161 Msg type: 8 bits 163 12 = Aggregate 165 RSVP checksum: 16 bits 167 The one's complement of the one's complement sum of the entire 168 message, with the checksum field replaced by zero for the pur- 169 pose of computing the checksum. An all-zero value means that 170 no checksum was transmitted. Because individual sub-messages 171 carry their own checksum as well as the INTEGRITY object for 172 authentication, this field MAY be set to zero. 174 Send_TTL: 8 bits 176 The IP TTL value with which the message was sent. This is used 177 by RSVP to detect a non-RSVP hop by comparing the IP TTL that 178 an Aggregate message sent to the TTL in the received message. 180 RSVP length: 16 bits 182 The total length of this RSVP aggregate message in bytes, 183 including the aggregate header and the sub-messages that fol- 184 low. 186 2.2. Message Formats 188 An RSVP aggregate message must contain at least one sub-message. A 189 sub-message is one of the RSVP Path, PathTear, PathErr, Resv, 190 ResvTear, ResvErr, ResvConf, Ack or Hello messages. 192 Empty RSVP aggregate messages should not be sent. It is illegal to 193 include another RSVP aggregate message as a sub-message. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Vers | Flags | 12 | RSVP checksum | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Send_TTL | (Reserved) | RSVP length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 // First sub-message // 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 // More sub-messages.. // 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 2.3. Sending RSVP Aggregate Messages 213 RSVP Aggregate messages are sent hop by hop between RSVP-capable 214 neighbors as "raw" IP datagrams with protocol number 46. Raw IP 215 datagrams are also intended to be used between an end system and the 216 first/last hop router, although it is also possible to encapsulate 217 RSVP messages as UDP datagrams for end-system communication that can- 218 not perform raw network I/O. 220 RSVP Aggregate messages MUST not be used if the next hop RSVP neigh- 221 bor does not support RSVP Aggregate messages. Methods for discover- 222 ing such information include: (1) manual configuration and (2) 223 observing the Aggregate-capable bit (see the description that fol- 224 lows) in the received RSVP messages. 226 Support for RSVP Aggregate messages is optional. While message 227 aggregation helps in scaling RSVP, and in reducing processing over- 228 head and bandwidth consumption, a node is not required to transmit 229 every standard RSVP message in an Aggregate message. A node MUST 230 always be ready to receive standard RSVP messages. 232 The IP source address is local to the system that originated the 233 Aggregate message. The IP destination address is the next hop node 234 for which the sub-messages are intended. These addresses need not be 235 identical to those used if the sub-messages were sent as standard 236 RSVP messages. 238 For example, the IP source address of Path and PathTear messages is 239 the address of the sender it describes, while the IP destination 240 address is the DestAddress for the session. These end-to-end 241 addresses are overridden by hop-by-hop addresses while encapsulated 242 in an Aggregate message. These addresses can easily be restored from 243 the SENDER_TEMPLATE and SESSION objects within Path and PathTear mes- 244 sages. For Path and PathTear messages, the next hop node can be 245 identified either via a received ACK or from a received corresponding 246 Resv message. Path and PathTear messages for multicast sessions MUST 247 NOT be sent in Aggregate messages. 249 RSVP Aggregate messages SHOULD NOT be sent with the Router Alert IP 250 option in their IP headers. This is because Aggregate messages are 251 addressed directly to RSVP neighbors. 253 Each RSVP Aggregate message MUST occupy exactly one IP datagram. If 254 it exceeds the MTU, the datagram is fragmented by IP and reassembled 255 at the recipient node. A single RSVP Aggregate message MUST NOT 256 exceed the maximum IP datagram size, which is approximately 64K 257 bytes. 259 2.4. Receiving RSVP Aggregate Messages 261 If the local system does not recognize or does not wish to accept an 262 Aggregate message, the received messages shall be discarded without 263 further analysis. 265 The receiver next compares the IP TTL with which an Aggregate message 266 is sent to the TTL with which it is received. If a non-RSVP hop is 267 detected, the number of non-RSVP hops is recorded. It is used later 268 in processing of sub-messages. 270 Next, the receiver verifies the version number and checksum of the 271 RSVP aggregate message and discards the message if any mismatch is 272 found. 274 The receiver then starts decapsulating individual sub-messages. Each 275 sub-message has its own complete message length and authentication 276 information. Each sub-message is processed per standard RSVP. 278 2.5. Forwarding RSVP Aggregate Messages 280 When an RSVP router receives an Aggregate messages which is not 281 addressed to one of it's IP addresses, it SHALL forward the message. 282 Non-RSVP routers will treat RSVP Aggregate messages as any other IP 283 datagram. 285 When individual sub-messages are being forwarded, they MAY be encap- 286 sulated in another aggregate message before sending to the next hop 287 neighbor. The Send_TTL field in the sub-messages should be decre- 288 mented properly before transmission. 290 2.6. Aggregate-Capable Bit 292 To support message aggregation, an additional capability bit is added 293 to the common RSVP header, which is defined in [RFC2205]. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Vers | Flags | Msg Type | RSVP Checksum | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Send_TTL | (Reserved) | RSVP Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Flags: 4 bits 304 0x01: Aggregate capable 306 If set, indicates to RSVP neighbors that this node is willing 307 and capable of receiving aggregate messages. This bit is 308 meaningful only between adjacent RSVP neighbors. 310 3. MESSAGE_ID Extension 312 Two new objects are defined as part of the MESSAGE_ID extension. The 313 two object types are the MESSAGE_ID object and the MESSAGE_ID ACK 314 object. The objects are used to support acknowledgments and, when 315 used in conjunction with the Hello Extension described in Section 4, 316 to indicate when refresh messages are not needed after an acknowledg- 317 ment. When refreshes are normally generated, the MESSAGE_ID object 318 can also be used to simply provide a shorthand indication of when a 319 message represents new state. Such information can be used on the 320 receiving node to reduce refresh processing requirements. 322 Message identification and acknowledgment is done on a hop-by-hop 323 basis. Acknowledgment is handled independent of SESSION or message 324 type. Both types of MESSAGE_ID objects contain a message identifier. 325 The identifier MUST be unique on a per source IP address basis across 326 messages sent by an RSVP node and received by a particular node. No 327 more than one MESSAGE_ID object may be included in an RSVP message. 328 Each message containing an MESSAGE_ID object may be acknowledged via 329 a MESSAGE_ID ACK object. MESSAGE_ID ACK objects may be sent piggy- 330 backed in unrelated RSVP messages or in RSVP ACK messages 332 Either type of MESSAGE_ID object may be included in an aggregate sub- 333 message. When included, the object is treated as if it were con- 334 tained in a standard, unaggregated, RSVP message. Only one MES- 335 SAGE_ID object MAY be included in a (sub)message and it MUST follow 336 any present MESSAGE_ID ACK objects. When no MESSAGE_ID ACK objects 337 are present, the MESSAGE_ID object MUST immediately follow the 338 INTEGRITY object. When no INTEGRITY object is present, the MES- 339 SAGE_ID object MUST immediately follow the (sub)message header. 341 When present, one or more MESSAGE_ID ACK objects MUST immediately 342 follow the INTEGRITY object. When no INTEGRITY object is present, 343 the MESSAGE_ID ACK objects MUST immediately follow the the (sub)mes- 344 sage header. An MESSAGE_ID ACK object may only be included in a mes- 345 sage when the message's IP destination address matches the unicast 346 address of the node that generated the message(s) being acknowledged. 348 3.1. MESSAGE_ID Object 350 MESSAGE_ID Class = 166 (Value to be assigned by IANA of form 351 10bbbbbb) 353 MESSAGE_ID object 355 Class = MESSAGE_ID Class, C_Type = 1 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Flags | Message ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Flags: 8 bits 365 0x80 = ACK_Desired flag 367 Indicates that the sender is willing to accept a message 368 acknowledgment. Acknowledgments MUST be silently ignored 369 when they are sent in response to messages whose 370 ACK_Desired flag is not set. This flag MUST be set when 371 the Last_Refresh flag is set. 373 0x40 = Last_Refresh flag 375 Used in Resv and Path refresh messages to indicate that the 376 sender will not be sending further refreshes. When set, 377 the ACK_Desired flag MUST also be set. This flag MUST NOT 378 be set when the HELLO messages are not being exchanged with 379 the neighboring RSVP node. 381 Message ID: 24 bits 383 a 24-bit identifier. When combined with the message 384 generator's IP address, uniquely identifies a message. 386 MESSAGE_ID ACK object 388 Class = MESSAGE_ID Class, C_Type = 2 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Reserved | Message ID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Reserved 397 This field is reserved. It MUST be set to zero on transmis- 398 sion and MUST be ignored on receipt. 400 Message ID: 24 bits 402 a 24-bit identifier. When combined with the message 403 generator's IP address, uniquely identifies a message. 405 3.2. Ack Message Format 407 Ack messages carry one or more MESSAGE_ID ACK objects. They MUST NOT 408 contain any MESSAGE_ID objects. Ack messages are sent hop-by-hop 409 between RSVP nodes. The IP destination address of an Ack message is 410 the unicast address of the node that generated the message(s) being 411 acknowledged. For Path, PathTear, Resv, and RervErr messages this is 412 taken from the RSVP_HOP Object. For PathErr and ResvErr messages 413 this is taken from the message's source address. The IP source 414 address is an address of the node that sends the Ack message. 416 The Ack message format is as follows: 418 ::= [ ] 419 420 [ ... ] 422 For Ack messages, the Msg Type field of the Common Header MUST be set 423 to 13 (Value to be assigned by IANA). 425 3.3. MESSAGE_ID Object Usage 427 The MESSAGE_ID object may be included in any RSVP message other than 428 the Ack message. The MESSAGE_ID object is always generated and pro- 429 cessed hop-by-hop. The IP address of the object generator is repre- 430 sented in a per RSVP message type specific fashion. For Path and 431 PathTear messages the generator's IP address is contained in the 432 RSVP_HOP. For Resv, ResvTear, PathErr, ResvErr, ResvConf and Aggre- 433 gate messages the generator's IP address is the source address in the 434 IP header. 436 The Message ID field contains a generator selected value. This 437 value, when combined with the generator's IP address, identifies a 438 particular RSVP message and the specific state information it repre- 439 sents. When a node is sending a refresh message with a MESSAGE_ID 440 object, it SHOULD use the same Message ID value that was used in the 441 RSVP message that first advertised the state being refreshed. When a 442 node is sending a message that represents new or changed state, the 443 Message ID value MUST have a value that is not otherwise in use. A 444 value is considered to be in use when it has been used in the most 445 recent advertisement or refresh of any state using the associated IP 446 address. Care must also be taken to avoid reuse of a previously used 447 value during times of network loss. At such times, the use of new 448 values may not be noticed by receivers. There is no requirement for 449 Message ID values to be increasing or 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 genera- 467 tion MUST continue until the message containing the Last_Refresh flag 468 is acknowledged. Although, messages removing state advertised in 469 such messages MUST be retransmit until acknowledged or a maximum 470 retry limit is reached in order to cover certain packet loss condi- 471 tions. Messages removing state include PathTear and ResvTear. 473 When sending MESSAGE_ID objects with the Last_Refresh flag set, spe- 474 cial care must be taken to properly advertise state. Specifically, 475 refresh processing MUST continue per standard RSVP processing until 476 after a acknowledgment is received. Suppression of refresh process- 477 ing MAY ONLY occur after an acknowledgment is received for a MES- 478 SAGE_ID object with the Last_Refresh flag set. Note that the 479 Last_Refresh flag MAY ONLY be set when the RSVP next hop is exchang- 480 ing Hello messages with the message generator. 482 When a Path message for a new session arrives, the RSVP next hop may 483 not always be known. When the RSVP next hop is not known, the 484 Last_Refresh flag MUST NOT be set. Once the next hop of a unicast 485 session is identified, only then may the Last_Refresh flag be set. 486 (Issues relate to multicast sessions are covered in a later section.) 487 There are several ways to identify the RSVP next hop of a new unicast 488 session. Some are more conservative than other, e.g., waiting for a 489 Resv message versus checking if the other end of a PPP link supports 490 Hello messages. Since there are no interoperability issues, the spe- 491 cific mechanism used to identify the RSVP next hop of a new session 492 is a specific implementation choice. In most implementations, it is 493 expected that an advertiser of Path state will do standard refresh 494 processing until either an ACK is received for a Path message adver- 495 tising a new session, or a corresponding Resv message is received. 497 Nodes receiving messages containing MESSAGE_ID objects SHOULD use the 498 information in the objects to aid in determining if a message repre- 499 sents new state or a state refresh. Note that state is only 500 refreshed in Path and Resv messages. If a Path or Resv message con- 501 tains the same Message_ID value that was used in the most recently 502 received message for the same session and, for Path messages, 503 SENDER_TEMPLATE then the receiver SHOULD treat the message as a state 504 refresh. If the Message ID value differs from the most recently 505 received value, the receiver MUST fully processes the message. 507 Nodes receiving a message containing a MESSAGE_ID object with the 508 ACK_Desired flag set, SHOULD respond with a MESSAGE_ID ACK object. 509 If a node supports the Hello extension it MUST also check the 510 Last_Refresh flag of received Resv and Path messages. If the flag is 511 set, the receiver MUST NOT timeout state associated with associated 512 message. The receiver MUST also be prepared to properly process 513 refresh messages. Messages containing a MESSAGE_ID ACK object with 514 the Last_Refresh flag set MUST NOT be acknowledged when either the 515 receiving node doesn't support the Hello extension or Hello messages 516 aren't being exchanged with the message generator. 518 3.4. MESSAGE_ID ACK Object Usage 520 The MESSAGE_ID ACK object is used to acknowledge receipt of messages 521 containing MESSAGE_ID objects that were sent with the ACK_Desired 522 flag set. The Message ID field of a MESSAGE_ID ACK object MUST have 523 the same value as was received. A MESSAGE_ID ACK object MUST NOT be 524 generated in response to a received MESSAGE_ID object when the 525 ACK_Desired flag is not set. 527 A MESSAGE_ID ACK object MAY be sent in any RSVP message that has an 528 IP destination address matching the generator of the associated MES- 529 SAGE_ID object. The MESSAGE_ID ACK object will not typically be 530 included in the non hop-by-hop Path, PathTear and ResvConf messages. 531 When no appropriate message is available, one or more MESSAGE_ID ACK 532 objects SHOULD be sent in an Ack message. Implementations SHOULD 533 include MESSAGE_ID ACK objects in standard RSVP messages when possi- 534 ble. 536 Upon receiving a MESSAGE_ID ACK object for a message generated with a 537 MESSAGE_ID object with the Last_Refresh flag set, normal refresh gen- 538 eration SHOULD be suppressed for the associated state. As previously 539 mentioned, special care must be taken to properly advertise state 540 when sending MESSAGE_ID objects with the Last_Refresh flag set, see 541 section 3.3. 543 3.5. Multicast Considerations 545 Path and PathTear messages may be sent to IP multicast destination 546 addresses. When the destination is a multicast address, it is possi- 547 ble that a single message containing a single MESSAGE_ID object will 548 be received by multiple RSVP next hops. When the ACK_Desired flag is 549 set in this case, acknowledgment processing is more complex. There 550 are a number of issues to be addressed including ACK implosion, num- 551 ber acknowledgments to be expected and handling of new receivers. 553 ACK implosion occurs when each receiver responds to the MESSAGE_ID 554 object at approximately the same time. This can lead to a poten- 555 tially large number of MESSAGE_ID ACK objects being simultaneously 556 delivered to the message generator. To address this case, the 557 receiver MUST wait a random interval prior to acknowledging a MES- 558 SAGE_ID object received in a message destined to a multicast address. 559 The random interval SHOULD be between zero (0) and a configured maxi- 560 mum time. The configured maximum SHOULD be set in proportion to the 561 refresh and "fast" retransmission interval. 563 A more fundamental issue is the number of acknowledgments that the 564 upstream node, i.e., the message generator, should expect. The 565 number of acknowledgments that should be expected is the same as the 566 number of RSVP next hops. In the router-to-router case, the number 567 of next hops can usually be obtained from routing. When hosts are 568 either the upstream node or the next hops, the number of next hops 569 will typically not be readily available. Another case where the num- 570 ber of RSVP next hops will typically not be known is when there are 571 non-RSVP routers between the message generator and the RSVP next 572 hops. 574 When the number of next hops is not known, the message generator 575 SHOULD only expect a single response and MUST NOT set the 576 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 577 will be special retransmission handling until the message is deliv- 578 ered to at least one next hop, then followed by standard RSVP 579 refreshes. Standard refresh messages will synchronize state with any 580 next hops that don't receive the original message. 582 Another issue is handling new receivers. It is possible that after 583 sending a Path message and handling of expected number of acknowledg- 584 ments that a new receiver joins the group. In this case a new Path 585 message must be sent to the new receiver. When normal refresh pro- 586 cessing is occurring, there is no issue. When normal refresh pro- 587 cessing is suppressed, a Path message must still be generated. In 588 the router-to-router case, the identification of new next hops can 589 usually be obtained from routing. When hosts are either the upstream 590 node or the next hops, the identification of new next hops will typi- 591 cally not be possible. Another case where the identification of new 592 RSVP next hops will typically not be possible is when there are non- 593 RSVP routers between the message generator and the RSVP next hops. 595 When identification of new next hops is not possible, the message 596 generator SHOULD only expect a single response and MUST NOT set the 597 Last_Refresh flag in MESSAGE_ID objects. The result of this behavior 598 will be special retransmission handling until the message is deliv- 599 ered to at least one next hop, then followed by standard RSVP 600 refreshes. Standard refresh messages will synchronize state with any 601 next hops that don't receive the original message either due to loss 602 or not yet being a group member. 604 There is one additional minor issue with multiple next hops. The 605 issue is handling a combination of standard-refresh and non-refresh 606 next hops, i.e., Hello messages are being exchanged with some neigh- 607 boring nodes but not with others. When this case occurs, refreshes 608 MUST be generated per standard RSVP and the Last_Refresh flag MUST 609 NOT be set. 611 3.5.1. Reference RSVP/Routing Interface 613 When using the MESSAGE_ID extension with multicast sessions it is 614 preferable for RSVP to obtain the number of next hops from routing 615 and to be notified when that number changes. The interface between 616 routing and RSVP is purely an implementation issue. Since RSVP 617 [RFC2205] describes a reference routing interface, we present a ver- 618 sion of the RSVP/routing interface updated to provide number of next 619 hop information. See [RFC2205] for previously defined parameters and 620 function description. 622 o Route Query 623 Mcast_Route_Query( [ SrcAddress, ] DestAddress, 624 Notify_flag ) 625 -> [ IncInterface, ] OutInterface_list, 626 NHops_list 628 o Route Change Notification 629 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, 630 [ IncInterface, ] OutInterface_list, 631 NHops_list 633 NHops_list provides the number of multicast group members 634 reachable via each OutInterface_list entry. 636 3.6. Compatibility 638 There are no backward compatibility issues raised by the MESSAGE_ID 639 Class. The MESSAGE_ID Class has an assigned value whose form is 640 10bbbbbb. Per RSVP [RFC2205], classes with values of this form must 641 be ignored and not forwarded by nodes not supporting the class. When 642 the receiver of a MESSAGE_ID object does not support the class, the 643 object will be silently ignored. The generator of the MESSAGE_ID 644 object will not see any acknowledgments and therefore refresh mes- 645 sages per standard RSVP. Lastly, since the MESSAGE_ID ACK object can 646 only be issued in response to the MESSAGE_ID object, there are no 647 possible issues with this object or Ack messages. 649 Implementations supporting Path and Resv state refresh suppression 650 via the MESSAGE_ID object's Last_Refresh flag MUST also support the 651 Hello extension. Such implementations SHOULD initiate Hello process- 652 ing and MUST be able to respond to Hello messages. 654 4. Hello Extension 656 The RSVP Hello extension enables RSVP nodes to detect a loss of a 657 neighboring node's state information. In standard RSVP, such detec- 658 tion occurs as a consequence of RSVP's soft state model. When 659 refresh message generation is suppressed via the previously discussed 660 Last_Refresh flag processing, the Hello extension is needed to 661 address this failure case. The Hello extensions is not intended to 662 provide a link failure detection mechanism, particularly in the case 663 of multiple parallel unnumbered links. 665 The Hello extension is specifically designed so that one side can use 666 the mechanism while the other side does not. Neighbor RSVP state 667 tracking may be initiated at any time. This includes when neighbors 668 first learn about each other, or just when neighbors are sharing Resv 669 or Path state. As previously stated, all implementations supporting 670 state refresh suppression are required to also support the Hello 671 Extension. 673 The Hello extension is composed of a Hello message, a HELLO REQUEST 674 object and a HELLO ACK object. Hello processing between two neigh- 675 bors supports independent selection of, typically configured, failure 676 detection intervals. Each neighbor can autonomously issue HELLO 677 REQUEST objects. Each request is answered by an acknowledgment. 678 Hello Messages also contain enough information so that one neighbor 679 can suppress issuing hello requests and still perform neighbor fail- 680 ure detection. A Hello message may be included as a sub-message 681 within an aggregate message. 683 Neighbor state tracking is accomplished by collecting and storing a 684 neighbor's state "instance" value. If a change in value is seen, 685 then the neighbor is presumed to have reset it's RSVP state. When a 686 neighbor's value is seen to change or when communication is lost with 687 a neighbor, then the instance value advertised to that neighbor is 688 also changed. The HELLO objects provide a mechanism for polling for 689 and providing an RSVP state instance value. A poll request also 690 includes the sender's instance value. This allows the receiver of a 691 poll to optionally treat the poll as an implicit poll response. This 692 optional handling is an optimization that can reduce the total number 693 of polls and responses processed by a pair of neighbors. In all 694 cases, when both sides support the optimization the result will be 695 only one set of polls and responses per failure detection interval. 696 Depending on selected intervals, the same benefit can occur even when 697 only one neighbor supports the optimization. 699 4.1. Hello Message Format 701 Hello Messages are always sent between two RSVP neighbors. The IP 702 source address is the IP address of the sending node. The IP desti- 703 nation address is the IP address of the neighbor node. 705 The Hello message format is as follows: 707 ::= [ ] 708 710 For Hello messages, the Msg Type field of the Common Header MUST be 711 set to 14 (Value to be assigned by IANA). 713 4.2. HELLO Object 715 HELLO Class = 22 (Value to be assigned by IANA of form 0bbbbbbb) 717 HELLO REQUEST object 719 Class = HELLO Class, C_Type = 1 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Instance | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 HELLO ACK object 728 Class = HELLO Class, C_Type = 2 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Instance | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Instance: 32 bits 738 a 32 bit value that represents the sender's RSVP agent's state. 739 The advertiser maintains a per neighbor representation/value. 740 This value MUST change when the agent is reset, when the node 741 reboots, or when a failure of the neighboring node is detected 742 and otherwise remains the same. This field MUST NOT be set to 743 zero (0). 745 4.3. Hello Message Usage 747 A Hello message containing a HELLO REQUEST object MUST be generated 748 for each neighbor who's state is being tracked. When generating a 749 message containing a HELLO REQUEST object, the sender fills in the 750 Instance field with a value representing it's per neighbor RSVP agent 751 state. This value MUST NOT change while the agent is maintaining any 752 RSVP state with the corresponding neighbor. The generation of a mes- 753 sage SHOULD be skipped when a HELLO REQUEST object was received from 754 the destination node within the failure detection interval. 756 On receipt of a message containing a HELLO REQUEST object, the 757 receiver MUST generate a Hello message containing a HELLO ACK object. 758 The receiver SHOULD also verify that the neighbor has not reset. 759 This is done by comparing the sender's Instance field value with the 760 previously received value. If the value differs, than the neighbor 761 has reset and all state associated with the neighbor MUST be 762 "expired" and cleaned up per standard RSVP processing. Additionally, 763 all Path state advertised to the neighbor MUST be refreshed. If any 764 state is removed or needs to be refreshed as a result of detecting a 765 change in a received Instance field value, then the value advertised 766 in the HELLO ACK object MUST be be different from the previously 767 advertised value. This new value MUST continue to be advertised to 768 the corresponding neighbor until a reset or reboot occurs, or until 769 another neighbor reset is detected. 771 On receipt of a message containing a HELLO ACK object, the receiver 772 MUST verify that the neighbor has not reset. This is done by compar- 773 ing the sender's Instance field value with the previously received 774 value. If the value differs, than the neighbor has reset and all 775 state associated with the neighbor MUST be "expired" and cleaned up 776 per standard RSVP processing. Additionally, all Path state adver- 777 tised to the neighbor MUST be refreshed. If any state is removed or 778 needs to be refreshed as a result of detecting a change in a received 779 Instance field value, then a new HELLO message MUST be immediately 780 issued with a value different then the one advertised in the previous 781 HELLO message. This new value MUST continue to be advertised to the 782 corresponding neighbor until a reset or reboot occurs, or until 783 another neighbor reset is detected. 785 If no Instance value is received, via either REQUEST or ACK objects, 786 from a neighbor within a configured number of failure detection 787 intervals, then a node MUST treat the neighbor as if it has reset. 788 Specifically, all state associated with the neighbor MUST be 789 "expired" and cleaned up per standard RSVP processing, and all Path 790 state advertised to the neighbor MUST be refreshed. If any state is 791 removed or needs to be refreshed as a result of this case, then a new 792 HELLO message MUST be immediately issued with a value different then 793 the one advertised in the previous HELLO message. This new value 794 MUST continue to be advertised to the corresponding neighbor until a 795 reset or reboot occurs, or until another neighbor reset is detected. 797 4.4. Multi-Link Considerations 799 As previously noted, the Hello extension is targeted at detecting 800 node failures not per link failures. When there is only one link 801 between neighboring nodes or when all links between a pair of nodes 802 fail, the distinction between node and link failures is not really 803 meaningful and handling of such failures has already been covered. 804 When there are multiple links shared between neighbors, there are 805 special considerations. When the links between neighbors are num- 806 bered, then Hellos MUST be run on each link and the previously 807 described mechanisms apply. 809 When the links are unnumbered, link failure detection MUST be pro- 810 vided by some means other than Hellos. Each node SHOULD use a single 811 Hello exchange with the neighbor. When a node removes state due to a 812 link failure, the node MUST advertise the removal of the state, via 813 appropriate Tear messages, over a non-failed link. The case where 814 all links have failed, is the same as the no received value case men- 815 tioned in the previous section. 817 4.5. Compatibility 819 The Hello extension is fully backwards compatible. The Hello class 820 is assigned a class value of the form 0bbbbbbb. Depending on the 821 implementation, implementations that don't support the extension will 822 either silently discard Hello messages or will respond with an 823 "Unknown Object Class" error. In either case the sender will fail to 824 see an acknowledgment for the issued Hello. When a Hello sender does 825 not receive an acknowledgment, it MUST NOT send MESSAGE_ID objects 826 with the Last_Refresh flag set. This restriction will preclude 827 neighbors from getting out of RSVP state synchronization. 829 Implementations supporting the Hello extension MUST also support the 830 MESSAGE_ID extension and refresh suppression. 832 5. Acknowledgments 834 This document represents ideas and comments from the MPLS-TE design 835 team. Thanks to Yoram Bernet, Fred Baker, Andreas Terzis and David 836 Mankins for the good feedback. 838 6. Security Considerations 840 No new security issues are raised in this document. See [RFC2205] 841 for a general discussion on RSVP security issues. 843 7. References 845 [Awduche] Awduche, D. et al. Requirements for Traffic Engineering 846 over MPLS, Internet Draft, 847 draft-awduche-mpls-traffic-eng-00.txt, April 1998. 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels," RFC 2119. 852 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol 853 -- Version 1 Functional Specification", RFC 2205, 854 September 1997. 856 8. Authors' Addresses 858 Lou Berger 859 LabN Consulting 860 Voice: +1 301 468 9228 861 Email: lberger@tidalwave.net 863 Der-Hwa Gan 864 Juniper Networks, Inc. 865 385 Ravendale Drive 866 Mountain View, CA 94043 867 Voice: +1 650 526 8074 868 Email: dhg@juniper.net 870 George Swallow 871 Cisco Systems, Inc. 872 250 Apollo Drive 873 Chelmsford, MA 01824 874 Voice: +1 978 244 8143 875 Email: swallow@cisco.com