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