idnits 2.17.1 draft-ietf-ccamp-rsvp-restart-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 828. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2005) is 6981 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: 'RFC2205' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RESTART' is defined on line 756, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Satyanarayana (Cisco Systems) 2 Internet Draft R. Rahman (Cisco Systems) 3 Expiration Date: September 2005 Editors 5 March 2005 7 Extensions to GMPLS RSVP Graceful Restart 9 draft-ietf-ccamp-rsvp-restart-ext-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes extensions to the RSVP Graceful Restart 36 mechanisms defined in RFC 3473. The extensions enable the recovery 37 of RSVP signaling state based on the Path message last sent by the 38 node being restarted. Previously defined Graceful Restart 39 mechanisms, also called recovery from nodal faults, permit recovery 40 of signaling state from adjacent nodes when the data plane has 41 retained the associated forwarding state across a restart. These 42 mechanisms do not fully support signaling state recovery on ingress 43 nodes or recovery of all RSVP objects. The presented extensions use 44 the RSVP Hello extensions defined in RFC 3209, and extensions for 45 state recovery on nodal faults defined in RFC 3473. With the 46 presented extensions the restarting node can recover all previously 47 transmitted Path state including the ERO and the downstream 48 (outgoing) interface identifiers. The extensions can also be used to 49 recover signaling state after the restart of an ingress node. The 50 extensions optionally support the use of Summary Refresh, defined in 51 RFC 2961, to reduce the number of messages exchanged during the 52 Recovery Phase when the restarting node has recovered signaling state 53 locally for one or more LSP's. 55 Contents 57 1 Introduction .............................................. 3 58 2 Extensions to Nodal Fault Handling ........................ 5 59 2.1 RecoveryPath Message Format ............................... 5 60 2.2 Related Procedures ........................................ 5 61 2.3 Procedures For The Downstream Neighbor .................... 6 62 2.4 Procedures for the Restarting Node ........................ 7 63 2.4.1 Path and RecoveryPath Message Procedures .................. 7 64 2.4.2 Re-Synchronization Procedures ............................. 8 65 2.4.3 Procedures on Expiration of Recovery Period ............... 9 66 2.5 Compatibility ............................................. 9 67 3 RecoveryPath Summary Refresh .............................. 10 68 3.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ........... 11 69 3.2 Capability Object ......................................... 12 70 3.2.1 Procedures ................................................ 13 71 3.2.2 Compatibility ............................................. 13 72 3.3 RecoveryPath Summary Refresh Procedures ................... 14 73 3.3.1 Generation of RecoveryPath-related Srefresh Messages ...... 14 74 3.3.2 RecoveryPath-related Srefresh Receive Processing and NACK 75 Generation ................................................ 15 76 3.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing ... 16 77 4 Acknowledgments ........................................... 17 78 5 Security Considerations ................................... 17 79 6 IANA Considerations ....................................... 17 80 7 References ................................................ 17 81 7.1 Normative References ...................................... 17 82 7.2 Informative References .................................... 18 83 8 Authors' Addresses ........................................ 18 84 9 Intellectual Property Considerations ...................... 19 85 10 Disclaimer of Validity .................................... 20 86 11 Full Copyright Statement .................................. 20 87 Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 1. Introduction 95 RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms 96 defined in [RFC3209]. [RFC3209] describes a mechanism, using RSVP 97 Hello messages, to detect the state of an adjacent RSVP agent. 98 [RFC3473] extends this mechanism to advertise the capability of 99 retaining data / forwarding plane state across the restart of a node 100 or a "nodal fault". [RFC3473] also defines the Recovery Label object 101 for use in the Path message of the RSVP neighbor upstream of a 102 restarting node, to indicate that the Path message is for existing 103 data plane state. 105 This document presents extensions to address two aspects of graceful 106 restart not previously supported. The presented extensions enable a 107 restarting node to recover all objects in previously transmitted Path 108 messages including the ERO, from its downstream neighbors. The 109 extensions also enable graceful restart of an ingress node that does 110 not preserve full RSVP state across restarts. 112 Per [RFC3473], a restarting node can distinguish Path messages 113 associated with LSPs being recovered by the presence of the Recovery 114 Label object. To determine the downstream (outgoing) interface and 115 associated label(s), the restarting node must consult the data plane. 116 This may not be possible for all types of nodes. Furthermore, data 117 plane information is not sufficient to reconstruct all previously 118 transmitted Path state. In these cases, the only source of RSVP 119 state is the downstream RSVP neighbor. 121 For example, when the restarting node is an ingress node, all 122 previously transmitted Path state may need to be recovered. Such 123 Path state may include (but is not restricted to) the Protection 124 object, the Admin Status object, the Session Attribute object, the 125 Notify Request object, the Sender Tspec object. A restarting transit 126 node may have modified received Path state in its previously 127 transmitted Path message, which cannot be reconstructed internally 128 during recovery. 130 Another example of state that cannot be completely recovered from the 131 data plane in some cases is the previously transmitted ERO. Recovery 132 of the previously transmitted ERO minimizes subsequent change of 133 downstream LSP state. On a restarting ingress node, the ERO may have 134 been based on configuration or the result of a previous path 135 computation. A restarting transit node may have previously performed 136 some form of path computation as a result of not receiving an ERO or 137 receiving a loose hop in the ERO. In addition to the ERO, the 138 restarting node may have modified other received Path state in its 139 previously transmitted Path state, which cannot be reconstructed 140 internally during recovery. 142 The defined extensions provide a restarting upstream node with all 143 information previously transmitted by the node in Path messages. 144 This is accomplished by the downstream RSVP neighbor, after 145 reestablishing RSVP communication with the restarted node, sending a 146 new message for every Path message it has previously received from 147 the restarting node. 149 The new message is called the RecoveryPath message. The message 150 conveys the contents of the last received Path message back to the 151 restarting node. The restarting node can use the RecoveryPath 152 message along with the state in the received Path message to 153 associate control and data plane state and to validate the forwarding 154 state with the state presented by the neighboring RSVP nodes. 156 If the restarting node is a transit node, it will receive a Path 157 message with a Recovery Label object from its upstream RSVP neighbor. 158 In addition, the RecoveryPath message allows such transit nodes to 159 reconstruct any state that was previously dynamically constructed by 160 the node, e.g., ERO sub-objects. If the restarting node is an 161 ingress node, all significant signaling state can be recovered based 162 on the RecoveryPath message. 164 Selective transmission of the RecoveryPath message is supported by 165 enhancing the Summary Refresh mechanisms defined in [RFC2961]. When 166 Recovery Summary Refresh is supported, the restarting node can select 167 the LSP's for which it would like to receive RecoveryPath messages. 168 This is useful when the restarting node is able to locally recover 169 the signaling state for a subset of the previously active LSP's. 171 Restarting egress nodes, and Resv message processing are not impacted 172 by the presented extensions, see [RFC3473] for details. 174 2. Extensions to Nodal Fault Handling 176 This section presents the protocol modifications to Section 9 of 177 [RFC3473]. 179 2.1. RecoveryPath Message Format 181 The format of a RecoveryPath message is the same as the format of a 182 Path message as defined in [RFC3473]: 184 ::= 186 The destination address used in the IP header of a RecoveryPath 187 message MUST be the same as the destination address used in the IP 188 header of the corresponding Resv message last generated by the 189 sending node. Except as specified below all objects in a 190 RecoveryPath message are identical to the objects in the 191 corresponding Path message last received by the sending node. 193 2.2. Related Procedures 195 This document does not modify existing procedures for sending and 196 receiving RSVP Hello messages as defined in [RFC3209] and the 197 Restart_Caps object in RSVP Hello messages as defined in [RFC3473]. 198 The procedures for control channel faults are defined in [RFC3473] 199 and are not changed by this document. 201 The presented extensions require the use of RSVP Hellos as defined in 202 [RFC3209] and the use of the Restart_Caps object extension as defined 203 in [RFC3473]. The presented extensions address only "Nodal Faults" 204 as defined in [RFC3473]. Control channel faults are fully addressed 205 in [RFC3473]. 207 Note: There are no changes to the procedures defined in Section 9.5.3 208 in [RFC3473] (Procedures for the Neighbor of a Restarting node). 209 There are no changes to the procedures defined in Section 9.5.2 in 210 [RFC3473] if the restarting node is an egress node. 212 The following sections assume previously defined procedures are 213 followed, except where explicitly modified. 215 2.3. Procedures For The Downstream Neighbor 217 After a downstream RSVP neighbor has detected that its upstream node 218 has restarted and is capable of recovery as defined in [RFC3473], the 219 downstream RSVP neighbor MUST send a RecoveryPath message for each 220 LSP associated with the restarting node for which it has sent a Resv 221 message. 223 The RecoveryPath message is constructed by copying all objects from 224 the last received associated Path message, with the following 225 exceptions: 227 The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not 228 copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK 229 objects used in RecoveryPath messages are generated based on 230 procedures defined in [RFC2961]. 232 The Integrity object is not copied. Any Integrity objects used in 233 RecoveryPath messages are generated based on procedures defined in 234 [RFC2747]. 236 The RSVP Hop object is copied from the most recent associated Resv 237 message sent to the restarted node, for the LSP being recovered. 239 In the sender descriptor, the Recovery Label object MUST be 240 included, with the label value copied from the label value in the 241 Label object in the most recent associated Resv message sent to 242 the restarted node, for the LSP being recovered. 244 All other objects from the most recent received Path message MUST be 245 included in the RecoveryPath message. 247 All RecoveryPath messages SHOULD be sent within approximately 1/2 of 248 the Recovery Time advertised by the restarted neighbor. If there are 249 many LSP's to be recovered by the restarted node, the downstream RSVP 250 neighbor should avoid sending RecoveryPath messages in a short time 251 interval, to avoid overloading the restarted node's CPU. Instead it 252 should spread the messages across 1/2 the Recovery Time interval. 254 After sending a RecoveryPath message and during the Recovery Period, 255 the node SHOULD periodically re-send the RecoveryPath message until 256 it receives a corresponding response. A corresponding response is a 257 Message ID acknowledgment or a Path message for the LSP the 258 RecoveryPath message represents. Each such re-send attempt is at the 259 end of any Message ID rapid retransmissions, if the Message ID 260 mechanism is used. If the Message ID mechanim is not in use, the 261 period between re-send attempts SHOULD be such that at least 3 262 attempts are completed before the expiry of 1/2 the Recovery Time 263 interval. Each such re-send attempt MUST treat the RecoveryPath 264 message as a new message, and update the MESSAGE_ID object according 265 to procedures defined in [RFC2961]. Note, per [RFC3473], Resv 266 messages are suppressed during this recovery period until a 267 corresponding Path message is received. 269 2.4. Procedures for the Restarting Node 271 These procedures apply during the "state recovery process" and 272 "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any 273 RecoveryPath message received after the Recovery Period has expired 274 MUST be discarded. If no LSP state matching the RecoveryPath message 275 is located, the restarted node MAY send a PathTear message 276 constructed from the RecoveryPath message, to expedite the cleanup of 277 unrecovered RSVP and associated forwarding state downstream of the 278 restarted node. 280 The remaining procedures are broken down into three sub-sections. 281 The term "resynchronized state", originally defined in [RFC3473], is 282 used and modified in these sections. This term refers to LSP state 283 that is fully recovered. 285 Signaling state may be recovered from sources other than the 286 mechanisms defined in this document. The restarting node SHOULD 287 consider signaling state as resynchronized for all such LSPs and 288 follow corresponding procedures defined below. Further, recovery 289 procedures defined below may be overridden by local policy. 291 Again, there are no changes to the procedures defined in Section 292 9.5.2 in [RFC3473] if the restarting node is an egress node. 294 2.4.1. Path and RecoveryPath Message Procedures 296 When a node receives a RecoveryPath message during the Recovery 297 Period, the node first checks if it has resynchronized RSVP state 298 associated with the message. If there is resynchronized state, and 299 when both reliable message delivery [RFC2961] is supported and a 300 MESSAGE_ID object is present in the RecoveryPath message, the node 301 MUST follow Message ID acknowledgment procedures as defined in 302 [RFC2961], and, consider the message as processed. If there is 303 resynchronized state, and, there is no MESSAGE_ID object or reliable 304 message delivery [RFC2961] is not supported, the node SHOULD send a 305 triggered Path message, and, consider the message as processed. 307 If non-resynchronized state is found or the node is the ingress, the 308 node saves the information contained in the RecoveryPath message and 309 continues with processing as defined in Section 2.4.2. 311 If no associated RSVP state is found and the node is not the ingress 312 node, the node saves the information contained in the RecoveryPath 313 message for later use. 315 Note the following modifies Section 9.5.2 of [RFC3473]: 317 When a node receives a Path message during the Recovery Period, the 318 node first locates any RSVP state associated with the message. If 319 resynchronized RSVP state is found, then the node handles this 320 message according to previously defined procedures. 322 If non-resynchronized state is found, the node saves the information 323 contained in the Path message including the Recovery_Label object and 324 continues with processing as defined in Section 2.4.2. 326 Per [RFC3473], if matching RSVP state is not found, and the message 327 does not carry a Recovery_Label object, the node treats this as a 328 setup for a new LSP, and handles it according to previously defined 329 procedures. 331 If matching RSVP state is not found, and the message carries a 332 Recovery_Label object, the node saves the information contained in 333 the Path message including the Recovery_Label object for later use. 335 2.4.2. Re-Synchronization Procedures 337 After receipt of the RecoveryPath message and, for non-ingress LSPs, 338 the corresponding Path message with a Recovery Label object, the 339 restarting node SHOULD locate and associate corresponding forwarding 340 state using the received information. The restarting node associates 341 the corresponding active forwarding plane state from the following 342 signaled information: 344 The upstream data interface is recovered from the RSVP HOP object 345 in the received Path message. 347 The label on the upstream data interface is recovered from the 348 Recovery Label object in the received Path message. If the LSP is 349 bidirectional, the label for the upstream direction is recovered 350 from the Upstream Label object in the received Path message. 352 The downstream data interface is recovered from the RSVP HOP 353 object in the received RecoveryPath message. 355 The label on the downstream data interface is recovered from the 356 Recovery Label object in the received RecoveryPath message. If 357 the LSP is bidirectional, the label for the upstream direction is 358 recovered from the Upstream Label object in the RecoveryPath 359 message. 361 If complete forwarding state is located, the restarted node MUST 362 treat the LSP as resynchronized and MUST send a triggered Path 363 message downstream. The Explicit Route object in the Path message 364 SHOULD match the Explicit Route object received in the RecoveryPath 365 message. In addition, the restarted node SHOULD recover state from 366 the other objects received in the RecoveryPath message. Optimally 367 the resulting Path message should not cause any redundant or 368 unnecessary re-processing of state along the remaining downstream 369 nodes. Ideally, except for MESSAGE_ID processing and recovery 370 processing, the transmitted Path message will be treated as a refresh 371 by the downstream RSVP neighbor (and hence should not trigger any 372 generation of Path messages with changed state further downstream). 374 If no forwarding state is located, the node treats the path message 375 as a setup for a new LSP. The outgoing interface and label(s) 376 indicated in the RecoveryPath message SHOULD be reused, when 377 possible. All other information contained in the RecoveryPath 378 message MAY also be used. 380 2.4.3. Procedures on Expiration of Recovery Period 382 There are several cleanup steps to follow at the end of the Recovery 383 Period. At the end of the Recovery Period, any state that was 384 installed as the result of a received RecoveryPath message that is 385 not resynchronized SHOULD be discarded. 387 Any Path messages that were received containing a Recovery_Label that 388 have not been resynchronized, SHOULD be treated as being received 389 during the Recovery Period and processed as per [RFC3473]. 391 Per [RFC3473], any other state that is not resynchronized during the 392 Recovery Period SHOULD be removed at the end of the Period. 394 2.5. Compatibility 396 This document introduces a new RSVP signaling message to be generated 397 by the downstream RSVP neighbor of a restarting node. 399 If the restarting node does not support the RecoveryPath message and 400 associated procedures, it will discard all received RecoveryPath 401 messages, and revert to recovery processing as defined in [RFC3473]. 403 If the downstream RSVP neighbor does not support the RecoveryPath 404 message and associated procedures, the restarting node processes 405 received Path messages as defined in Section 2.4.3, which essentially 406 reverts to the processing defined in [RFC3473]. 408 3. RecoveryPath Summary Refresh 410 This section describes a mechanism to control which LSP state is 411 communicated in RecoveryPath messages. This mechanism enhances the 412 Summary Refresh mechanism defined in [RFC2961], and uses a new object 413 carried in the Hello message defined in [RFC3209] and [RFC3473]. The 414 described mechanism is referred to as RecoveryPath Summary Refresh. 416 Selective transmission of RecoveryPath messages is controlled much 417 the same way transmission of Path or Resv messages is controlled with 418 standard Summary Refresh, see [RFC2961]. In standard Summary 419 Refresh, an Srefresh message is sent by a node to identify to its 420 neighbor about Path and Resv state that is locally installed and 421 available. The receiver of the Srefresh message, can then attempt to 422 locate matching Path and Resv state. If no matching state is found, 423 the receiver can request that the missing state be sent to it, by 424 sending an Srefresh NACK to the sender of the Srefresh message. When 425 the Srefresh NACK is received, the corresponding Path or Resv message 426 is sent. MESSAGE_ID information is used to identify Path and Resv 427 state in this process. 429 The mechanism described in this section extends the Summary Refresh 430 process to the Path state that can be represented in RecoveryPath 431 messages. In this case, the Srefresh messages represent previously 432 received Path messages, rather than previously transmitted Path 433 messages. This is the primary difference between standard Summary 434 Refresh and RecoveryPath Summary Refresh described in this section. 436 When a node restarts, and is capable of supporting the mechanisms 437 described in this section, it includes a new object in Hello messages 438 it sends to its RSVP neighbors. The new object is defined below in 439 Section 3.2 and is called the Capability object. A bit carried 440 within the Capability object indicates when a restarting node desires 441 its downstream neighbor to use the mechanisms described in this 442 section. This bit is called the RecoveryPath Srefresh Capable bit. 444 When a neighbor of the restarting node detects a restart, see 445 [RFC3209], it detects that the restarted node is requesting 446 RecoveryPath Srefresh messages by the presence of the Capability 447 object with the RecoveryPath Srefresh Capable bit set. When such an 448 indication is found, the neighbor generates one or more Srefresh 449 messages. Each message indicates the Path state that can be 450 represented in a RecoveryPath message. Within such Srefresh 451 messages, Path state that can be represented in RecoveryPath messages 452 is represented using MESSAGE_ID information, and this information is 453 communicated within MESSAGE_ID LIST objects. To indicate that the 454 MESSAGE_ID LIST object is for recovery purposes, a new flag is set in 455 the MESSAGE_ID LIST object. This flag is called the RecoveryPath 456 Flag and is defined below. 458 The restarted node can then use the Srefresh message and the 459 MESSAGE_ID LIST object to try to identify matching transmitted Path 460 state. The node identifies local state by matching Epoch and Message 461 ID tuples against Path messages transmitted downstream prior to the 462 restart. 464 If matching state is located, then the restarted node operates as if 465 a RecoveryPath message has been received, per Section 2.4. If no 466 matching state can be located, the restarted node generates a 467 Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is 468 also marked with the new RecoveryPath Flag to indicate that the NACK 469 is related to RecoveryPath messages. 471 Upon receiving a Srefresh NACK, the downstream node generates a 472 RecoveryPath message for the Path state indicated by each entry in 473 the MESSAGE_ID LIST. The procedures defined above in Section 2 are 474 then followed by the restarted node and the downstream RSVP neighbor. 476 3.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects 478 The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, 479 defined in [RFC2961], are updated by this document. A new bit within 480 the existing Flags field of each object is defined. This bit 481 indicates that the object carries MESSAGE_ID information related to 482 Path state that can be recovered using RecoveryPath messages. The 483 same flag value is used in all the objects for consistency. 485 MESSAGE_ID_ACK object 486 MESSAGE_ID_NACK object 488 See Section 4.3 of [RFC2961] for definition of other fields. 490 MESSAGE_ID LIST object 492 See Section 5.1 of [RFC2961] for definition of other fields. 494 Flags: 8 bits 496 0x02: RecoveryPath Flag 498 Indicates that the associated object carries MESSAGE_ID 499 information related to one or more Path messages that can be 500 recovered using a RecoveryPath message. 502 3.2. Capability Object 504 Capability objects are carried in RSVP Hello messages. The 505 Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type 506 of 1. 508 The message format of a Hello message is modified to be: 510 ::= [ ] 511 [ ] [ ] 513 The format of a Capability object is: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Length | Class-Num(TBA)| C-Type (1) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Reserved |R| 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 RecoveryPath Srefresh Capable (R): 1 bit 524 When set (1), indicates that the sending node is capable of 525 receiving and processing Srefresh messages with the 526 RecoveryPath Flag set (1) in the MESSAGE_ID LIST object. 527 Absence of the Capability object MUST be treated as if the 528 R-bit is cleared (0). 530 Reserved bits 532 Reserved bits MUST be set to zero on transmission and MUST be 533 ignored on receipt. 535 3.2.1. Procedures 537 The Capability object is sent within a Hello message to indicate that 538 a node supports selective transmission of RecoveryPath messages. To 539 indicate to a neighbor that selective transmission of RecoveryPath 540 messages is desired, a restarting node MUST include the Capability 541 object with the R-bit set (1) in all Hello messages it sends during 542 the Recovery Period to the neighbor. When either the Restart_Cap 543 Object is not present in a Hello message or when the Recovery Time is 544 zero (0), the Capability object MUST be omitted or the R-bit MUST be 545 cleared (0). 547 On the downstream neighbor, the R-bit is checked upon detecting a 548 restart of a neighbor that supports state recovery. Detection of 549 neighbor restarts with state recovery is defined in [RFC3473]. When 550 a node supports RecoveryPath Summary Refresh, and it detects a 551 restart of a neighbor that supports state recovery, it MUST check to 552 see if the received Hello message contains a Capability object with 553 the R-bit set. If the R-bit is set, then the procedures defined 554 below in Section 3.3.1 MUST be followed. If the Capability object is 555 not found or the R-bit not set, then the node MUST revert to normal 556 recovery procedures as defined above in Section 2.3. 558 3.2.2. Compatibility 560 There are no compatibility issues introduced in this section. The 561 use of the Capability object will not cause any issues on a 562 non-supporting receiver as it uses a Class-Number of form 10bbbbbb. 563 The object will simply be ignored, and normal processing will 564 continue. Normal processing includes procedures defined above in 565 Section 2, in [RFC3473] and in [RFC3209]. 567 The sender of the Capability object will detect that its neighbor 568 does not support selective transmission of RecoveryPath messages when 569 a RecoveryPath message is received prior to the receipt of a Srefresh 570 message containing a MESSAGE_ID LIST object with the RecoveryPath 571 Flag set (1). When this occurs, any received RecoveryPath messages 572 MUST be processed as defined above in Section 2. 574 3.3. RecoveryPath Summary Refresh Procedures 576 Related processing occurs in the following logical order: 578 o Generation of RecoveryPath-related Srefresh messages 579 o RecoveryPath-related Srefresh message receive processing and 580 NACK generation 581 o Message ID NACK receive processing and generation of 582 RecoveryPath messages 583 o Receive processing of RecoveryPath messages 585 Actual processing MAY result in the above occurring in an interlaced 586 fashion when multiple LSP's are being recovered. Both the restarted 587 node and the downstream RSVP neighbor MUST be able to process in this 588 fashion. 590 3.3.1. Generation of RecoveryPath-related Srefresh Messages 592 A neighbor of a restarting node generates one or more 593 RecoveryPath-related Srefresh messages when the R-bit is set in the 594 restarted node's Hello messages as described above in Section 3.2.1. 595 The procedures for generating an Srefresh message are defined in 596 [RFC2961]. Only modifications to these procedures are described in 597 this section. 599 To generate RecoveryPath-related Srefresh messages, a node must 600 identify which Path state can be represented in RecoveryPath messages 601 and which Srefresh message or messages can be used to carry the 602 related information. As previously mentioned, the Path state that 603 can be represented in RecoveryPath messages is indicated in Srefresh 604 messages using the MESSAGE_ID information from the most recently 605 received Path message associated with the state. 607 After processing the R-bit as described in Section 3.2.1, the node 608 identifies all state associated with Path messages received from the 609 restarted neighbor. Only Path state that has not been updated since 610 the restart may be represented in the Srefresh messages. Received 611 Path state containing a MESSAGE_ID object whose Epoch value matches 612 the Epoch received in the most recent Hello message is considered as 613 updated after the upstream neighbor has restarted. Such Path state 614 MUST NOT be represented in the Srefresh messages. 616 Each Srefresh message contains one or more MESSAGE_ID LIST objects. 617 Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set 618 (1). Multiple MESSAGE_ID LIST objects MAY be included in order to 619 accommodate multiple Epoch values. The MESSAGE_ID LIST objects 620 represent the identified, non-updated, Path state. A 621 Message_Identifier field created for each identified, non-updated 622 Path state MUST be included in an appropriate MESSAGE_ID LIST object. 623 The Message_Identifier field is created based on the MESSAGE_ID 624 object from the most recently received Path message associated with 625 identified Path state. If any identified Path state does not have an 626 associated MESSAGE_ID object, this state MUST be processed as defined 627 above in Section 2.3. 629 The source IP address for the Srefresh message SHOULD be the source 630 IP address in the IP header of the corresponding Resv messages 631 previously sent to the restarted node. The Srefresh message SHOULD 632 be destined to the IP address in the HOP object in the corresponding 633 Path messages. This may result in multiple Srefresh messages being 634 generated. Per [RFC2961], implementations may choose to limit each 635 Srefresh message to the MTU size of the outgoing link, and to not 636 bundle Srefresh messages. RecoveryPath-related Srefresh messages 637 SHOULD be sent using reliable delivery, as defined in [RFC2961]. 639 During the Recovery Period, unacknowledged RecoveryPath-related 640 Srefresh messages SHOULD be periodically transmitted. The 641 retransmission algorithm used can be same algorithm used for 642 retransmitting RecoveryPath messages during the Recovery Period (see 643 section 2.3). Note that prior to each such periodic retransmission, 644 the Srefresh message SHOULD be updated to exclude the Message ID's of 645 Path state that has been updated by the receipt of a Path message. 647 To allow sufficient processing time for the restarted node, the 648 downstream RSVP neighbor MAY choose to generate multiple 649 RecoveryPath-related Srefresh messages containing partial but 650 mutually exclusive sets of Message Identifiers spread across 1/4 of 651 the Recovery Time advertised by the restarted node. 653 3.3.2. RecoveryPath-related Srefresh Receive Processing and NACK 654 Generation 656 Upon receiving an Srefresh message containing a MESSAGE_ID LIST 657 object with the RecoveryPath Flag set), the restarted node attempts 658 to locate matching previously transmitted Path state. The Epoch in 659 the MESSAGE_ID LIST object along with each Message Identifier in the 660 object is used to match against the MESSAGE_ID object in Path 661 messages previously transmitted to the downstream RSVP neighbor. For 662 each Message Identifier in the MESSAGE_ID LIST: 664 If matching transmitted Path state is found, the restarting node 665 treats the corresponding LSP state as having received and 666 processed a RecoveryPath message, and, perform any further 667 processing necessary as defined in Section 2.4. Specifically, it 668 MUST generate a triggered Path message for the LSP as defined in 669 Section 2.4.2. The restarted node MAY spread the transmission of 670 such triggered Path messages across 1/2 of the remaining Recovery 671 Period to allow the downstream RSVP neighbor sufficient processing 672 time. 674 If matching transmitted Path state is not found, the restarting 675 node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. 676 Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set 677 (1). 679 It is recommended that the restarted node combine multiple such 680 MESSAGE_ID NACK's into a single ACK message, per [RFC2961]. 682 3.3.3. RecoveryPath-related MESSAGE_ID NACK Receive Processing 684 This section defines the procedures associated with the processing of 685 received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1). 686 Procedures for processing of MESSAGE_ID NACK's without the 687 RecoveryPath Flag present are defined in [RFC2961] and not modified 688 in this document. Processing of MESSAGE_ID NACK's with the 689 RecoveryPath Flag set (1) also follows procedures defined in 690 [RFC2961] unless explicitly modified in this section. 692 For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the 693 downstream RSVP neighbor must locate the matching received Path 694 message. If a matching Path message is found, the downstream RSVP 695 neighbor MUST generate a RecoveryPath message as defined in Section 696 2.3. If a matching Path message is not found, the MESSAGE_ID NACK is 697 ignored. An example where this may occur is when the restarted node 698 has already generated an updated Path message after its restart. 700 4. Acknowledgments 702 The authors would like to thank participants of the CCAMP WG for 703 comments and suggestions. Also thanks to Arthi Ayyangar, Adrian 704 Farrel and Nick Neate for their helpful comments and feedback. 706 5. Security Considerations 708 This document introduces a new RSVP message that is restricted to one 709 RSVP hop. This document introduces no new security considerations 710 beyond those already addressed for existing RSVP hop-by-hop messages. 712 This document introduces a new RSVP object to be included in RSVP 713 Hello messages. This document introduces no new security 714 considerations beyond those already addressed for existing objects in 715 RSVP Hello messages. 717 6. IANA Considerations 719 A new RSVP message type is defined in this document. The RSVP 720 message type is TBA by IANA. 722 A new RSVP object of form 10bbbbbb is defined in this document. The 723 Class-Num is TBA by IANA. 725 7. References 727 7.1. Normative References 729 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 730 RFC 2119, S. Bradner, March 1997. 732 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 733 Functional Specification", 734 RFC 2205, Braden, et al, September 1997. 736 [RFC2747] "RSVP Cryptographic Authentication", 737 RFC 2747, F. Baker, et al, January 2000. 739 [RFC2961] "RSVP Refresh Overhead Reduction Extensions", 740 RFC 2961, L. Berger, et al, April 2001. 742 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 743 RFC 3209, December 2001. 745 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 746 Signaling Functional Description", 747 RFC 3471, L. Berger, et al, January 2003. 749 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 750 Signaling Resource ReserVation Protocol-Traffic 751 Engineering (RSVP-TE) Extensions", 752 RFC 3473, L. Berger, et al, January 2003. 754 7.2. Informative References 756 [RESTART] "RSVP Graceful Restart Extensions", 757 draft-rahman-rsvp-restart-extensions-00, 758 R. Rahman, et al, October 2003 760 8. Authors' Addresses 762 Arun Satyanarayana 763 Cisco Systems, Inc. 764 170 West Tasman Dr. 765 San Jose, CA 95134 766 Phone: +1 408 853-3206 767 Email: asatyana@cisco.com 769 Lou Berger 770 Movaz Networks, Inc. 771 7926 Jones Branch Drive 772 Suite 615 773 McLean VA, 22102 774 Phone: +1 703 847-1801 775 Email: lberger@movaz.com 777 Dimitri Papadimitriou (Alcatel) 778 Francis Wellesplein 1 779 B-2018 Antwerpen, Belgium 780 Phone: +32 3 240-8491 781 Email: dimitri.papadimitriou@alcatel.be 783 Reshad Rahman 784 Cisco Systems Inc. 785 2000 Innovation Dr., 786 Kanata, Ontario, K2K 3E8 787 Canada. 788 Phone: (613)-254-3519 789 Email: rrahman@cisco.com 790 Anca Zamfir 791 Cisco Systems Inc. 792 2000 Innovation Dr., 793 Kanata, Ontario, K2K 3E8 794 Canada. 795 Phone: (613)-254-3484 796 Email: ancaz@cisco.com 798 Junaid Israr 799 Cisco Systems Inc. 800 2000 Innovation Dr., 801 Kanata, Ontario, K2K 3E8 802 Canada. 803 Phone: (613)-254-3693 804 Email: jisrar@cisco.com 806 9. Intellectual Property Considerations 808 The IETF takes no position regarding the validity or scope of any 809 Intellectual Property Rights or other rights that might be claimed to 810 pertain to the implementation or use of the technology described in 811 this document or the extent to which any license under such rights 812 might or might not be available; nor does it represent that it has 813 made any independent effort to identify any such rights. Information 814 on the procedures with respect to rights in RFC documents can be 815 found in BCP 78 and BCP 79. 817 Copies of IPR disclosures made to the IETF Secretariat and any 818 assurances of licenses to be made available, or the result of an 819 attempt made to obtain a general license or permission for the use of 820 such proprietary rights by implementers or users of this 821 specification can be obtained from the IETF on-line IPR repository at 822 http://www.ietf.org/ipr. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights that may cover technology that may be required to implement 827 this standard. Please address the information to the IETF at 828 ietf-ipr@ietf.org. 830 10. Disclaimer of Validity 832 This document and the information contained herein are provided on an 833 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 834 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 835 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 836 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 837 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 838 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 840 11. Full Copyright Statement 842 Copyright (C) The Internet Society (2004). This document is subject 843 to the rights, licenses and restrictions contained in BCP 78, and 844 except as set forth therein, the authors retain all their rights.