idnits 2.17.1 draft-ietf-ccamp-rsvp-restart-ext-09.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1087. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1111. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2961, but the abstract doesn't seem to directly say this. It does mention RFC2961 though, so this could be OK. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to directly say this. It does mention RFC3473 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2961, updated by this document, for RFC5378 checks: 1999-10-27) -- 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 2007) is 6130 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Satyanarayana, Ed. 2 Internet-Draft R. Rahman, Ed. 3 Updates: 2961, 3473 (if approved) Cisco Systems 4 Intended status: Standards Track July 2007 5 Expires: January 2008 7 Extensions to GMPLS RSVP Graceful Restart 9 draft-ietf-ccamp-rsvp-restart-ext-09 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes extensions to the RSVP Graceful Restart 37 mechanisms defined in RFC 3473. The extensions enable the recovery 38 of RSVP signaling state based on the Path message last sent by the 39 node being restarted. 41 Previously defined Graceful Restart mechanisms, also called recovery 42 from nodal faults, permit recovery of signaling state from adjacent 43 nodes when the data plane has retained the associated forwarding 44 state across a restart. Those mechanisms do not fully support 45 signaling state recovery on ingress nodes or recovery of all RSVP 46 objects. 48 The extensions defined in this document build on the RSVP Hello 49 extensions defined in RFC 3209, and extensions for state recovery on 50 nodal faults defined in RFC 3473. Using these extensions the 51 restarting node can recover all previously transmitted Path state 52 including the Explicit Route Object and the downstream (outgoing) 53 interface identifiers. The extensions can also be used to recover 54 signaling state after the restart of an ingress node. 56 These extensions are not used to create or restore data plane state. 58 The extensions optionally support the use of Summary Refresh, defined 59 in RFC 2961, to reduce the number of messages exchanged during the 60 Recovery Phase when the restarting node has recovered signaling state 61 locally for one or more LSPs. 63 Table of Contents 65 1. Conventions used in this document . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Extensions to Nodal Fault Handling . . . . . . . . . . . 6 69 4.1. RecoveryPath Message Format . . . . . . . . . . . . . . 6 70 4.2. Capability Object . . . . . . . . . . . . . . . . . . . 6 71 4.2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Related Procedures . . . . . . . . . . . . . . . . . . . 8 73 4.4. Procedures for the Capability Object . . . . . . . . . . 8 74 4.4.1. Procedures for the Downstream Neighbor . . . . . . . . . 8 75 4.4.2. Procedures for the Restarting Node . . . . . . . . . . . 9 76 4.5. Procedures for the RecoveryPath message . . . . . . . . 9 77 4.5.1. Procedures for the Downstream Neighbor . . . . . . . . . 9 78 4.5.2. Procedures for the Restarting Node . . . . . . . . . . . 11 79 4.5.2.1. Path and RecoveryPath Message Procedures . . . . . . . . 11 80 4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12 81 4.5.2.3. Procedures on Expiration of Recovery Period . . . . . . 13 82 4.6. Compatibility . . . . . . . . . . . . . . . . . . . . . 13 83 5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . 14 84 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . 15 85 5.2. RecoveryPath Srefresh Capable bit . . . . . . . . . . . 16 86 5.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . . 17 88 5.3. RecoveryPath Summary Refresh Procedures . . . . . . . . 17 89 5.3.1. Generation of RecoveryPath-related Srefresh Messages . . 17 90 5.3.2. RecoveryPath-related Srefresh Receive Processing and 91 NACK Generation . . . . . . . . . . . . . . . . . . . . 19 92 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive 93 Processing . . . . . . . . . . . . . . . . . . . . . . . 19 94 6. Security Considerations . . . . . . . . . . . . . . . . 20 95 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . 21 97 9. Normative References . . . . . . . . . . . . . . . . . . 22 99 1. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Terminology 107 The reader is assumed to be familiar with the terminology defined in 108 [RFC3209] and [RFC3473]. 110 Throughout this document, the term "node" when used in the context of 111 a restarting or restarted node generally refers to the control plane 112 component which is the signaling controller for a data plane switch. 114 3. Introduction 116 RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms 117 defined in [RFC3209]. When data/forwarding plane state can be 118 retained across the restart of the RSVP agent that established such 119 state, RSVP Graceful Restart provides the ability for the RSVP agent 120 to resynchronize its state based on updates received from its 121 neighboring RSVP agents, and, reconcile such state with the retained 122 data/forwarding plane state. [RFC3209] describes a mechanism, using 123 RSVP Hello messages, to detect the state of an adjacent RSVP agent. 124 [RFC3473] extends this mechanism to advertise the capability of 125 retaining data/forwarding plane state across the restart of a node or 126 a "nodal fault". [RFC3473] also defines the Recovery Label object 127 for use in the Path message of the RSVP neighbor upstream of a 128 restarting node, to indicate that the Path message is for existing 129 data plane state. 131 This document presents extensions to address two aspects of graceful 132 restart not previously supported. The presented extensions enable a 133 restarting node to recover all objects in previously transmitted Path 134 messages including the Explicit Route Object (ERO), from its 135 downstream neighbors and so recover control plane state. The 136 extensions do not facilitate the recovery or creation of 137 data/forwarding plane state, and can only be used to re-establish 138 control plane state which matches in-place data/forwarding state. 139 The extensions also enable graceful restart of an ingress node that 140 does not preserve full RSVP state across restarts. The presented 141 extensions are equally applicable to LSPs of various switching types 142 as defined in [RFC3471]. 144 Per [RFC3473], a restarting node can distinguish Path messages 145 associated with LSPs being recovered by the presence of the Recovery 146 Label object. To determine the downstream (outgoing) interface and 147 associated label(s), the restarting node must consult the data plane. 148 This may not be possible for all types of nodes. Furthermore, data 149 plane information is not sufficient to reconstruct all previously 150 transmitted Path state. In these cases, the only source of RSVP 151 state is the downstream RSVP neighbor. 153 For example, when the restarting node is an ingress node, all 154 previously transmitted Path state may need to be recovered. Such 155 Path state may include (but is not restricted to) the Protection 156 object, the Admin Status object, the Session Attribute object, the 157 Notify Request object, the Sender Tspec object. A restarting transit 158 node may have modified received Path state in its previously 159 transmitted Path message, which cannot be reconstructed internally 160 during recovery. 162 Another example of state that cannot be completely recovered from the 163 data plane in some cases is the previously transmitted ERO. Recovery 164 of the previously transmitted ERO minimizes subsequent change of 165 downstream LSP state. On a restarting ingress node, the ERO may have 166 been based on configuration or the result of a previous path 167 computation. A restarting transit node may have previously performed 168 some form of path computation as a result of not receiving an ERO or 169 receiving a loose hop in the ERO. In addition to the ERO, the 170 restarting node may have modified other received Path state in its 171 previously transmitted Path state, which cannot be reconstructed 172 internally during recovery. 174 The defined extensions provide a restarting upstream node with all 175 information previously transmitted by the node in Path messages. 176 This is accomplished by the downstream RSVP neighbor sending a new 177 message for every Path message it has previously received from the 178 restarting node, after reestablishing RSVP communication with a 179 restarted node which supports the recovery procedures defined in 180 Section 4.5.2 of this document. 182 The new message is called the RecoveryPath message. The message 183 conveys the contents of the last received Path message back to the 184 restarting node. The restarting node can use the RecoveryPath 185 message along with the state in the received Path message to 186 associate control and data plane state and to validate the forwarding 187 state with the state presented by the neighboring RSVP nodes. 189 The restarting node indicates its desire to receive and process the 190 RecoveryPath message by including a new object called the Capability 191 object with the RecoveryPath Desired bit set, in its Hello messages 192 sent to the downstream RSVP neighbor. The downstream RSVP neighbor 193 can indicate its ability to send RecoveryPath messages by including 194 the Capability object with the RecoveryPath Transmit Enabled set in 195 its Hello messages to the restarting node. Thus, both the restarting 196 node and its RSVP neighbor, with the help of the Capability object, 197 can detect if the RecoveryPath message extensions defined in this 198 document can be used to recover signaling state after a restart. 200 If the restarting node is a transit node, it will receive a Path 201 message with a Recovery Label object from its upstream RSVP neighbor. 202 In addition, the RecoveryPath message allows such transit nodes to 203 reconstruct any state that was previously dynamically constructed by 204 the node, e.g., ERO sub-objects. If the restarting node is an 205 ingress node, all significant signaling state can be recovered based 206 on the RecoveryPath message. 208 Selective transmission of the RecoveryPath message is supported by 209 enhancing the Summary Refresh mechanisms defined in [RFC2961]. When 210 Recovery Summary Refresh is supported, the restarting node can select 211 the LSPs for which it would like to receive RecoveryPath messages. 212 This is useful when the restarting node is able to locally recover 213 the signaling state for a subset of the previously active LSPs. 215 Restarting egress nodes, and Resv message processing are not impacted 216 by the presented extensions, see [RFC3473] for details. 218 4. Extensions to Nodal Fault Handling 220 This section presents the protocol modifications to Section 9 of 221 [RFC3473]. 223 4.1. RecoveryPath Message Format 225 The format of a RecoveryPath message is the same as the format of a 226 Path message as defined in [RFC3473], but uses a new message number 227 so that it can be identified correctly. 229 ::= 231 The destination address used in the IP header of a RecoveryPath 232 message MUST be the same as the destination address used in the IP 233 header of the corresponding Resv message last generated by the 234 sending node. Except as specified below all objects in a 235 RecoveryPath message are identical to the objects in the 236 corresponding Path message last received by the sending node. 238 4.2. Capability Object 240 Capability objects are carried in RSVP Hello messages. The 241 Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type 242 of 1. 244 The message format of a Hello message is modified to be: 246 ::= [ ] 247 [ ] [ ] 249 The format of a Capability object is: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Length | Class-Num(TBA)| C-Type (1) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Reserved |T|R|S| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 RecoveryPath Transmit Enabled (T): 1 bit 261 When set (1), indicates that the sending node is enabled to 262 send RecoveryPath messages. Absence of the Capability object 263 MUST be treated as if the T-bit is cleared (0). 265 RecoveryPath Desired (R): 1 bit 267 When set (1), indicates that the sending node desires to 268 receive RecoveryPath messages. Absence of the Capability 269 object MUST be treated as if the R-bit is cleared (0). 271 RecoveryPath Srefresh Capable (S): 1 bit 273 When set (1) along with the R-bit, indicates that the sending 274 node is capable of receiving and processing Srefresh messages 275 with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST 276 object. Absence of the Capability object MUST be treated as if 277 the S-bit is cleared (0). Related procedures are defined in 278 Section 5.2.1. 280 Reserved bits 282 Reserved bits MUST be set to zero on transmission and MUST be 283 ignored on receipt. 285 4.2.1. Conformance 287 All nodes supporting the extensions defined in this document MUST be 288 able to transmit, and, properly receive and process RecoveryPath 289 messages. All nodes MUST be able to set both the T and R bits. Both 290 the T and R bits SHOULD be set (1) by default. A node MAY allow 291 RecoveryPath message transmission and reception to be independently 292 disabled based on local policy. When RecoveryPath message 293 transmission is disabled, the T-bit MUST be set to zero (0). When 294 RecoveryPath message reception is not desired, the R-bit MUST be set 295 to zero (0). 297 Any node that supports the extensions defined in this document and 298 sets the Refresh-Reduction-Capable bit [RFC2961], SHOULD support 299 setting of the S-bit and support the mechanisms defined in Section 5. 301 4.3. Related Procedures 303 This document does not modify existing procedures for sending and 304 receiving RSVP Hello messages as defined in [RFC3209] and the 305 Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. 306 The procedures for control channel faults are defined in [RFC3473] 307 and are not changed by this document. 309 The presented extensions require the use of RSVP Hellos as defined in 310 [RFC3209] and the use of the Restart_Cap object extension as defined 311 in [RFC3473]. The presented extensions address only "Nodal Faults" 312 as defined in [RFC3473]. Control channel faults are fully addressed 313 in [RFC3473]. 315 Note: There are no changes to the procedures defined in Section 9.5.3 316 in [RFC3473] (Procedures for the Neighbor of a Restarting node). 317 There are no changes to the procedures defined in Section 9.5.2 in 318 [RFC3473] if the restarting node is an egress node. 320 There are no changes to the procedures with respect of the 321 data/forwarding plane as described in [RFC3473]. In particular, a 322 restarting node MUST NOT create data/forwarding plane state as the 323 result of any of the extensions defined in this document. 325 The following sections assume previously defined procedures are 326 followed, except where explicitly modified. 328 4.4. Procedures for the Capability Object 330 4.4.1. Procedures for the Downstream Neighbor 332 If a node is capable of sending RecoveryPath messages, it MUST 333 include the Capability object with the RecoveryPath Transmit Enabled 334 (T) bit set (1) in all its Hello messages. 336 If the downstream RSVP neighbor receives Hello messages from a 337 restarting node, with the Restart_Cap object as defined in [RFC3473], 338 and, with the Capability object with the RecoveryPath Desired (R) bit 339 set (1), it MUST treat the restarting node as capable of receiving 340 and processing RecoveryPath messages as defined in this document. 342 If the downstream RSVP neighbor receives a Capability object in a 343 Hello message with the RecoveryPath Desired (R) bit set (1), but, 344 without the Restart_Cap object, it MUST process the Hello message as 345 if the RecoveryPath Receive Desired (R) bit is cleared (0) in the 346 Hello message. 348 If the downstream RSVP neighbor does not receive the Capability 349 object in Hello messages sent by the restarting node or the 350 RecoveryPath Desired (R) bit is cleared (0) in the Capability object, 351 it MUST treat the restarting node as not capable of supporting the 352 RecoveryPath message procedures defined in this document, and, MUST 353 revert to recovery procedures as defined in [RFC3473]. 355 4.4.2. Procedures for the Restarting Node 357 A node that expects to recover RSVP state by the receipt and 358 processing of RecoveryPath messages according to procedures defined 359 in this document, MUST include the Capability object with the 360 RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to 361 its neighbors. The node MUST also include the Restart_Cap object as 362 defined in [RFC3473], in all those Hello messages. 364 If the Recovery Time is zero (0) or the restarting node does not 365 support/desire the use of RecoveryPath messages, the RecoveryPath 366 Desired (R) bit MUST be cleared (0) in the Capability object included 367 in Hello messages, or the Capability object MAY be omitted from Hello 368 messages sent by the restarting node. 370 During the Recovery Period, if the restarting node receives Hello 371 messages from a downstream RSVP neighbor with the RecoveryPath 372 Transmit Enabled (T) bit set (1) in the Capability object and the 373 Restart_Cap object as defined in [RFC3473], it MUST treat the 374 downstream RSVP neighbor as capable of sending RecoveryPath messages 375 according to procedures defined in Section 4.5.1. If the restarting 376 node expects to recover RSVP state by the receipt and processing of 377 RecoveryPath messages, it MUST follow procedures defined in 378 Section 4.5.2, with the downstream RSVP neighbor. 380 During the Recovery Period, if the restarting node receives Hello 381 messages from a downstream RSVP neighbor with the RecoveryPath 382 Transmit Enabled (T) bit cleared (0) in the Capability object, or, 383 with the Capability object not present, it MUST treat the downstream 384 RSVP neighbor as not capable of the RecoveryPath message procedures 385 defined in this document, and, it MUST revert to the recovery 386 procedures defined in [RFC3473] immediately, with the downstream RSVP 387 neighbor. 389 4.5. Procedures for the RecoveryPath message 391 4.5.1. Procedures for the Downstream Neighbor 393 After a downstream RSVP neighbor has detected that its upstream node 394 has restarted, is capable of recovery as defined in [RFC3473], and, 395 is capable of receiving RecoveryPath messages as defined in 396 Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath 397 message for each LSP associated with the restarting node for which it 398 has sent a Resv message. During the Recovery Period, if the 399 downstream RSVP neighbor detects that the restarting node is not 400 capable of receiving RecoveryPath messages, by the absence of the 401 Capability object or the RecoveryPath Desired (R) bit cleared (0) in 402 the Capability object in the restarting node's Hello messages, the 403 downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to 404 the restarting node. 406 The RecoveryPath message is constructed by copying all objects from 407 the last received associated Path message, with the following 408 exceptions: 410 The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not 411 copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK 412 objects used in RecoveryPath messages are generated based on 413 procedures defined in [RFC2961]. 415 The Integrity object is not copied. Any Integrity objects used in 416 RecoveryPath messages are generated based on procedures defined in 417 [RFC2747]. 419 The RSVP Hop object is copied from the most recent associated Resv 420 message sent to the restarted node, for the LSP being recovered. 422 In the sender descriptor, the Recovery Label object MUST be 423 included, with the label value copied from the label value in the 424 Label object in the most recent associated Resv message sent to 425 the restarted node, for the LSP being recovered. 427 All other objects from the most recent received Path message MUST be 428 included in the RecoveryPath message. 430 All RecoveryPath messages SHOULD be sent at least once within 431 approximately 1/2 of the Recovery Time advertised by the restarted 432 neighbor. If there are many LSPs to be recovered by the restarted 433 node, the downstream RSVP neighbor should avoid sending RecoveryPath 434 messages in a short time interval, to avoid overloading the restarted 435 node's CPU. Instead it should spread the messages across 1/2 the 436 Recovery Time interval. The range of Recovery Time is dependent on 437 many factors including but not limited to the CPU processing power on 438 the restarting node as well as the upstream and downstream neighbors, 439 amount of CPU available for processing RSVP recovery procedures, 440 implementation specifics that affect the amount of time taken to 441 verify the received recovery state against existing forwarding plane 442 state. Such discussion is out of scope of this document. 444 After sending a RecoveryPath message and during the Recovery Period, 445 the node SHOULD periodically re-send the RecoveryPath message until 446 it receives a corresponding response. A corresponding response is a 447 Message ID acknowledgment or a Path message for the LSP the 448 RecoveryPath message represents. Each such re-send attempt is at the 449 end of any Message ID rapid retransmissions, if the Message ID 450 mechanism is used. If the Message ID mechanism is not in use, the 451 period between re-send attempts SHOULD be such that at least 3 452 attempts are completed before the expiry of 3/4 the Recovery Time 453 interval. Each such re-send attempt MUST treat the RecoveryPath 454 message as a new message, and update the MESSAGE_ID object according 455 to procedures defined in [RFC2961]. Note, per [RFC3473], Resv 456 messages are suppressed during this recovery period until a 457 corresponding Path message is received. 459 4.5.2. Procedures for the Restarting Node 461 These procedures apply during the "state recovery process" and 462 "Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any 463 RecoveryPath message received after the Recovery Period has expired 464 SHOULD be matched against local LSP state. If matching fully 465 resynchronized state is located, the node SHOULD send a Path message 466 downstream. If non-resynchronized or no LSP state matching the 467 RecoveryPath message is located, the restarted node MAY send a 468 PathTear message constructed from the RecoveryPath message, to 469 expedite the cleanup of unrecovered RSVP and associated forwarding 470 state downstream of the restarted node. The restarting node MUST 471 NOT create data plane or forwarding state to match the received 472 RecoveryPath message. 474 The remaining procedures are broken down into three sub-sections. 475 The term "resynchronized state", originally defined in [RFC3473], is 476 used and modified in these sections. This term refers to LSP state 477 that is fully recovered. 479 Signaling state may be recovered from sources other than the 480 mechanisms defined in this document. The restarting node SHOULD 481 consider signaling state as resynchronized for all such LSPs and 482 follow corresponding procedures defined below. Further, recovery 483 procedures defined below may be overridden by local policy. 485 Again, there are no changes to the procedures defined in Section 486 9.5.2 in [RFC3473] if the restarting node is an egress node. 488 4.5.2.1. Path and RecoveryPath Message Procedures 490 When a node receives a RecoveryPath message during the Recovery 491 Period, the node first checks if it has resynchronized RSVP state 492 associated with the message. If there is resynchronized state, and 493 when both reliable message delivery [RFC2961] is supported and a 494 MESSAGE_ID object is present in the RecoveryPath message, the node 495 MUST follow Message ID acknowledgment procedures as defined in 496 [RFC2961], and, consider the message as processed. If there is 497 resynchronized state, and, there is no MESSAGE_ID object or reliable 498 message delivery [RFC2961] is not supported, the node SHOULD send a 499 trigger Path message, and, consider the message as processed. 501 If non-resynchronized state is found or the node is the ingress, the 502 node saves the information contained in the RecoveryPath message and 503 continues with processing as defined in Section 4.5.2.2. 505 If no associated RSVP state is found and the node is not the ingress 506 node, the node saves the information contained in the RecoveryPath 507 message for later use. 509 Note the following modifies Section 9.5.2 of [RFC3473]: 511 When a node receives a Path message during the Recovery Period, the 512 node first locates any RSVP state associated with the message. If 513 resynchronized RSVP state is found, then the node handles this 514 message according to previously defined procedures. 516 If non-resynchronized state is found, the node saves the information 517 contained in the Path message including the Recovery_Label object and 518 continues with processing as defined in Section 4.5.2.2. 520 Per [RFC3473], if matching RSVP state is not found, and the message 521 does not carry a Recovery_Label object, the node treats this as a 522 setup for a new LSP, and handles it according to previously defined 523 procedures. 525 If matching RSVP state is not found, and the message carries a 526 Recovery_Label object, the node saves the information contained in 527 the Path message including the Recovery_Label object for later use. 529 4.5.2.2. Re-Synchronization Procedures 531 After receipt of the RecoveryPath message and, for non-ingress LSPs, 532 the corresponding Path message with a Recovery Label object, the 533 restarting node SHOULD locate and associate corresponding forwarding 534 state using the received information. The restarting node associates 535 the corresponding active forwarding plane state from the following 536 signaled information: 538 The upstream data interface is recovered from the RSVP HOP object 539 in the received Path message. 541 The label on the upstream data interface is recovered from the 542 Recovery Label object in the received Path message. If the LSP is 543 bidirectional, the label for the upstream direction is recovered 544 from the Upstream Label object in the received Path message. 546 The downstream data interface is recovered from the RSVP HOP 547 object in the received RecoveryPath message. 549 The label on the downstream data interface is recovered from the 550 Recovery Label object in the received RecoveryPath message. If 551 the LSP is bidirectional, the label for the upstream direction is 552 recovered from the Upstream Label object in the RecoveryPath 553 message. 555 If complete forwarding state is located, the restarted node MUST 556 treat the LSP as resynchronized and MUST send a trigger Path message 557 downstream. The Explicit Route object in the Path message SHOULD 558 match the Explicit Route object received in the RecoveryPath message. 559 In addition, the restarted node SHOULD recover state from the other 560 objects received in the RecoveryPath message. Optimally the 561 resulting Path message should not cause any redundant or unnecessary 562 re-processing of state along the remaining downstream nodes. 563 Ideally, except for MESSAGE_ID processing and recovery processing, 564 the transmitted Path message will be treated as a refresh by the 565 downstream RSVP neighbor (and hence should not trigger any generation 566 of Path messages with changed state further downstream). 568 If no forwarding state is located, the node treats the received Path 569 message as a setup request for a new LSP. The outgoing interface and 570 label(s) indicated in the RecoveryPath message SHOULD be reused, when 571 possible. All other information contained in the RecoveryPath 572 message MAY also be used. That is, forwarding state MUST NOT be 573 created except after receipt of a Path message from upstream or, at 574 an ingress node, the receipt of a command from the management plane. 575 Further, the forwarding state created is subject to local policy and 576 the information received from downstream in the RecoveryPath message 577 is treated only as advisory. 579 4.5.2.3. Procedures on Expiration of Recovery Period 581 There are several cleanup steps to follow at the end of the Recovery 582 Period. At the end of the Recovery Period, any state that was 583 installed as the result of a received RecoveryPath message that is 584 not resynchronized SHOULD be discarded. 586 Any Path messages that were received containing a Recovery_Label that 587 has not been resynchronized, MUST be treated as being received 588 during the Recovery Period and processed as per [RFC3473]. 590 Per [RFC3473], any other state that is not resynchronized during the 591 Recovery Period SHOULD be removed at the end of the Period. 593 4.6. Compatibility 595 This document introduces a new RSVP signaling message called the 596 RecoveryPath message to be generated by the downstream RSVP neighbor 597 of a restarting node. To advertise the capability of sending and 598 receiving RecoveryPath messages, this document introduces the 599 Capability object, to be included in Hello messages by a restarting 600 node and its downstream RSVP neighbors. 602 If a restarting node does not support the Capability object, it will 603 discard the object as the Class-Number is of the form 10bbbbbb and 604 revert to recovery processing as defined in [RFC3473]. The 605 restarting node will not include the Capability object in its Hello 606 messages. Hence, all downstream RSVP neighbors detect that the 607 restarting node is not capable of supporting the extensions defined 608 in this document, will not send the RecoveryPath messages to the 609 restarting node, and, will revert to recovery processing as defined 610 in [RFC3473]. 612 If a downstream RSVP neighbor does not support the Capability object, 613 it will discard the object received in Hello messages and revert to 614 recovery processing as defined in [RFC3473]. The downstream RSVP 615 neighbor will not include the Capability object in its Hello 616 messages. Hence, the restarting node will detect that the downstream 617 RSVP neighbor is not capable of supporting the extensions defined in 618 this document, and, will revert to recovery processing as defined in 619 [RFC3473]. 621 5. RecoveryPath Summary Refresh 623 This section describes a mechanism to control which LSP state is 624 communicated in RecoveryPath messages. This mechanism enhances the 625 Summary Refresh mechanism defined in [RFC2961], and uses the 626 RecoveryPath Srefresh Capable (S) bit in the Capability object as 627 defined in Section 4.2, carried in the Hello message defined in 628 [RFC3209] and [RFC3473]. The described mechanism is referred to as 629 RecoveryPath Summary Refresh. 631 Selective transmission of RecoveryPath messages is controlled much 632 the same way transmission of Path or Resv messages is controlled with 633 standard Summary Refresh, see [RFC2961]. In standard Summary 634 Refresh, an Srefresh message is sent by a node to identify to its 635 neighbor about Path and Resv state that is locally installed and 636 available. The receiver of the Srefresh message, can then attempt to 637 locate matching Path and Resv state. If no matching state is found, 638 the receiver can request that the missing state be sent to it, by 639 sending an Srefresh NACK to the sender of the Srefresh message. When 640 the Srefresh NACK is received, the corresponding Path or Resv message 641 is sent. MESSAGE_ID information is used to identify Path and Resv 642 state in this process. 644 The mechanism described in this section extends the Summary Refresh 645 process to the Path state that can be represented in RecoveryPath 646 messages. In this case, the Srefresh messages represent previously 647 received Path messages, rather than previously transmitted Path 648 messages. This is the primary difference between standard Summary 649 Refresh and RecoveryPath Summary Refresh described in this section. 651 When a node restarts, and is capable of supporting the mechanisms 652 described in this section, it includes the Capability object with the 653 RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh 654 Capable (S) bit set in Hello messages it sends to its RSVP neighbors. 656 When a neighbor of the restarting node detects a restart, see 657 [RFC3209], it detects that the restarted node is capable of receiving 658 RecoveryPath messages as defined in Section 4.4, and that the 659 restarted node is requesting RecoveryPath Srefresh messages by the 661 RecoveryPath Srefresh Capable (S) bit set in the Capability object. 662 When such an indication is found, the neighbor generates one or more 663 Srefresh messages. Each message indicates the Path state that can be 664 represented in a RecoveryPath message. Within such Srefresh 665 messages, Path state that can be represented in RecoveryPath messages 666 is represented using MESSAGE_ID information, and this information is 667 communicated within MESSAGE_ID LIST objects. To indicate that the 668 MESSAGE_ID LIST object is for recovery purposes, a new flag is set in 669 the MESSAGE_ID LIST object. This flag is called the RecoveryPath 670 Flag and is defined below. 672 The restarted node can then use the Srefresh message and the 673 MESSAGE_ID LIST object to try to identify matching transmitted Path 674 state. The node identifies local state by matching Epoch and Message 675 ID tuples against Path messages transmitted downstream prior to the 676 restart. 678 If matching state is located, then the restarted node operates as if 679 a RecoveryPath message has been received, per Section 4.5.2. If no 680 matching state can be located, the restarted node generates a 681 Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is 682 also marked with the new RecoveryPath Flag to indicate that the NACK 683 is related to RecoveryPath messages. 685 Upon receiving a Srefresh NACK, the downstream node generates a 686 RecoveryPath message for the Path state indicated by each entry in 687 the MESSAGE_ID LIST. The procedures defined above in Section 4 are 688 then followed by the restarted node and the downstream RSVP neighbor. 690 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects 692 The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, 693 defined in [RFC2961], are updated by this document. A new bit within 694 the existing Flags field of each object is defined. This bit 695 indicates that the object carries MESSAGE_ID information related to 696 Path state that can be recovered using RecoveryPath messages. The 697 same flag value is used in all the objects for consistency. 699 MESSAGE_ID_ACK object 700 MESSAGE_ID_NACK object 702 See Section 4.3 of [RFC2961] for definition of other fields. 704 MESSAGE_ID LIST object 706 See Section 5.1 of [RFC2961] for definition of other fields. 708 Flags: 8 bits 710 0x02: RecoveryPath Flag 712 Indicates that the associated object carries MESSAGE_ID 713 information related to one or more Path messages that can be 714 recovered using a RecoveryPath message. 716 5.2. RecoveryPath Srefresh Capable bit 718 The Capability object and the RecoveryPath Srefresh Capable (S) bit 719 are defined in Section 4.2. 721 5.2.1. Procedures 723 To support the selective receipt of RecoveryPath messages as defined 724 in this section, a restarting node MUST support the receipt and 725 processing of RecoveryPath messages as defined in Section 4.5.2 and 726 MUST indicate this capability by including the Capability object with 727 the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in 728 its Hello messages. 730 To indicate to an RSVP neighbor that selective transmission of 731 RecoveryPath messages is desired, a node MUST set (1) the S-bit in 732 the Capability object in all Hello messages it sends. When the 733 restarting node does not desire the receipt of RecoveryPath messages, 734 see Section 4.4.2, or, the selective transmission mechanism defined 735 in this section, it MUST clear (0) the S-bit in the Capability object 736 if included in Hello messages. 738 The downstream RSVP neighbor checks the R-bit and the S-bit upon 739 detecting a restart of a node that supports state recovery with 740 RecoveryPath messages. Detection of neighbor restarts with state 741 recovery using RecoveryPath messages is defined in Section 4. If 742 both the R-bit and the S-bit are set, then the procedures defined 743 below in Section 5.3.1 MUST be followed. If the S-bit is cleared, 744 the downstream RSVP neighbor MUST revert to normal procedures defined 745 in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the 746 downstream RSVP neighbor MUST treat as if the Capability object was 747 received with the S-bit cleared. See Section 4.4 for handling of 748 Hello messages without the Capability object. 750 5.2.2. Compatibility 752 There are no compatibility issues introduced in the procedures 753 defined in Section 5.2.1. 755 The restarting node will detect that its neighbor does not support 756 selective transmission of RecoveryPath messages when a RecoveryPath 757 message is received prior to the receipt of a Srefresh message 758 containing a MESSAGE_ID LIST object with the RecoveryPath Flag set 759 (1). When this occurs, any received RecoveryPath messages MUST be 760 processed as defined in Section 4. 762 5.3. RecoveryPath Summary Refresh Procedures 764 Related processing occurs in the following logical order: 766 o Generation of RecoveryPath-related Srefresh messages 768 o RecoveryPath-related Srefresh message receive processing and NACK 769 generation 771 o Message ID NACK receive processing and generation of RecoveryPath 772 messages 774 o Receive processing of RecoveryPath messages 776 Actual processing MAY result in the above occurring in an interlaced 777 fashion when multiple LSPs are being recovered. Both the restarted 778 node and the downstream RSVP neighbor MUST be able to process in this 779 fashion. 781 5.3.1. Generation of RecoveryPath-related Srefresh Messages 783 A neighbor of a restarting node generates one or more RecoveryPath- 784 related Srefresh messages when the S-bit is set in the restarted 785 node's Hello messages as described in Section 5.2.1. The procedures 786 for generating an Srefresh message are defined in [RFC2961]. Only 787 modifications to these procedures are described in this section. 788 Also, Srefresh message transmit and receive processing may occur 789 simultaneously during the Recovery Period and are not impacted by the 790 procedures defined in this section. 792 To generate RecoveryPath-related Srefresh messages, a node must 793 identify which Path state can be represented in RecoveryPath messages 794 and which Srefresh message or messages can be used to carry the 795 related information. As previously mentioned, the Path state that 796 can be represented in RecoveryPath messages is indicated in Srefresh 797 messages using the MESSAGE_ID information from the most recently 798 received Path message associated with the state. 800 After processing the S-bit as described in Section 5.2.1, the node 801 identifies all state associated with Path messages received from the 802 restarted neighbor. Only Path state that has not been updated since 803 the restart may be represented in the Srefresh messages. Received 804 Path state containing a MESSAGE_ID object whose Epoch value matches 805 the Epoch received in the most recent Hello message is considered as 806 updated after the upstream neighbor has restarted. Such Path state 807 MUST NOT be represented in the Srefresh messages. Each Srefresh 808 message contains one or more MESSAGE_ID LIST objects. Each such 809 MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1). 811 Multiple MESSAGE_ID LIST objects MAY be included in order to 812 accommodate multiple Epoch values. The MESSAGE_ID LIST objects 813 represent the identified, non-updated, Path state. A 814 Message_Identifier field created for each identified, non-updated 815 Path state MUST be included in an appropriate MESSAGE_ID LIST object. 816 The Message_Identifier field is created based on the MESSAGE_ID 817 object from the most recently received Path message associated with 818 identified Path state. If any identified Path state does not have an 819 associated MESSAGE_ID object, this state MUST be processed as defined 820 above in Section 4.5.1. 822 The source IP address for the Srefresh message SHOULD be the source 823 IP address in the IP header of the corresponding Resv messages 824 previously sent to the restarted node. The Srefresh message SHOULD 825 be destined to the IP address in the HOP object in the corresponding 826 Path messages. This may result in multiple Srefresh messages being 827 generated. Per [RFC2961], implementations may choose to limit each 828 Srefresh message to the MTU size of the outgoing link, and to not 829 bundle Srefresh messages. RecoveryPath-related Srefresh messages 830 SHOULD be sent using reliable delivery, as defined in [RFC2961]. 832 During the Recovery Period, unacknowledged RecoveryPath-related 833 Srefresh messages SHOULD be periodically transmitted. The 834 retransmission algorithm used can be same algorithm used for 835 retransmitting RecoveryPath messages during the Recovery Period (see 836 Section 4.5.1). Note that prior to each such periodic 837 retransmission, the Srefresh message SHOULD be updated to exclude the 838 Message ID's of Path state that has been updated by the receipt of a 839 Path message. 841 To allow sufficient processing time for the restarted node, the 842 downstream RSVP neighbor MAY choose to generate multiple 843 RecoveryPath-related Srefresh messages containing partial but 844 mutually exclusive sets of Message Identifiers spread across 1/4 of 845 the Recovery Time advertised by the restarted node. 847 5.3.2. RecoveryPath-related Srefresh Receive Processing and NACK 848 Generation 850 Upon receiving an Srefresh message containing a MESSAGE_ID LIST 851 object with the RecoveryPath Flag set), the restarted node attempts 852 to locate matching previously transmitted Path state. The Epoch in 853 the MESSAGE_ID LIST object along with each Message Identifier in the 854 object is used to match against the MESSAGE_ID object in Path 855 messages previously transmitted to the downstream RSVP neighbor. For 856 each Message Identifier in the MESSAGE_ID LIST: 858 If matching transmitted Path state is found, the restarting node 859 treats the corresponding LSP state as having received and 860 processed a RecoveryPath message, and, perform any further 861 processing necessary as defined in Section 4.5.2. Specifically, 862 it MUST generate a trigger Path message for the LSP as defined in 863 Section 4.5.2.2. The restarted node MAY spread the transmission 864 of such trigger Path messages across 1/2 of the remaining Recovery 865 Period to allow the downstream RSVP neighbor sufficient processing 866 time. 868 If matching transmitted Path state is not found, the restarting 869 node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. 870 Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set 871 (1). 873 It is recommended that the restarted node combine multiple such 874 MESSAGE_ID NACK's into a single ACK message, per [RFC2961]. 876 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive Processing 878 This section defines the procedures associated with the processing of 879 received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1). 880 Procedures for processing of MESSAGE_ID NACK's without the 881 RecoveryPath Flag present are defined in [RFC2961] and not modified 882 in this document. Processing of MESSAGE_ID NACK's with the 883 RecoveryPath Flag set (1) also follows procedures defined in 884 [RFC2961] unless explicitly modified in this section. 886 For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the 887 downstream RSVP neighbor must locate the matching received Path 888 message. If a matching Path message is found, the downstream RSVP 889 neighbor MUST generate a RecoveryPath message as defined in 890 Section 4.5.1. If a matching Path message is not found, the 891 MESSAGE_ID NACK is ignored. An example where this may occur is when 892 the restarted node has already generated an updated Path message 893 after its restart. 895 6. Security Considerations 897 This document introduces a new RSVP message that is restricted to one 898 RSVP hop. This document introduces no new security considerations 899 beyond those already addressed for existing RSVP hop-by-hop messages. 901 This document introduces a new RSVP object to be included in RSVP 902 Hello messages. This document introduces no new security 903 considerations beyond those already addressed for existing objects in 904 RSVP Hello messages. 906 This document introduces new procedures to be performed on RSVP 907 agents that neighbor a restarting RSVP agent. In situations where 908 the control plane in general, and the RSVP agent in particular, of a 909 node carrying one or more LSPs is restarted due to external attacks, 910 the procedures introduced in this document provide the ability for 911 the restarting RSVP agent to recover the RSVP state corresponding to 912 the LSPs with the least possible perturbation to the rest of the 913 network. Ideally, only the neighboring RSVP agents should notice the 914 restart and hence need to perform additional processing. This allows 915 for a network with active LSPs to recover LSP state gracefully from 916 an external attack, without perturbing the data/forwarding plane 917 state. 919 [RFC2747] provides mechanisms to protect against external agents 920 compromising the RSVP signaling state in an RSVP agent. These 921 mechanisms, when used with the new message and procedures introduced 922 in this document, provide the same degree of protection to the 923 restarting RSVP agent, against installing compromised signaling state 924 from an external agent during its RSVP signaling state recovery. 926 Note that the procedures assume a full trust model between RSVP 927 neighbors. That is, although the protocol exchanges before and after 928 restart can be secured, and although it is possible to authenticate 929 the identity of the neighbors, no mechanism is provided to verify 930 that the restart information is correctly mapped from the protocol 931 information exchanged before the restart. This is considered 932 acceptable because a similar trust model is required for normal 933 operation of the protocol. 935 The procedures defined in this document introduce additional 936 processing overhead for the RSVP agents that neighbor a restarting 937 RSVP agent. If an RSVP agent restarts due to external attacks, such 938 added processing on the neighboring RSVP agents may impact their 939 ability to perform other control plane tasks including any processing 940 for other LSPs that do not involve the restarting node. Such impact 941 can be minimalized by the restarting RSVP agent using a large enough 942 Recovery Time, so that its neighbors are provided sufficient time to 943 handle the additional processing involved while continuing to perform 944 their other control plane functions normally during the Recovery 945 Period. 947 Note that the procedures defined in this document cannot be used to 948 create false forwarding state. The restarting node that receives a 949 RecoveryPath message that does not match the existing forwarding 950 state MUST NOT create or modify its forwarding state to match. A 951 restarting node SHOULD log such an event or otherwise notify the 952 operator since it might represent an attack. 954 7. Acknowledgments 956 The authors would like to thank participants of the CCAMP WG for 957 comments and suggestions. Also thanks to Arthi Ayyangar, Adrian 958 Farrel, Nick Neate and Pavan Beeram for their helpful comments and 959 feedback. 961 Derek Atkins provided useful discussion during SecDir review. Sam 962 Hartman gave careful scrutiny of the security considerations and 963 the potential impact on the RSVP-TE security trust model. 965 Adrian Farrel edited the final revisions of this document as it 966 progressed through IESG review. 968 8. IANA Considerations 970 [RFC2205] defines the Class-Number name space for RSVP objects. The 971 name space is managed by IANA. 973 A new RSVP object using a Class-Number of form 10bbbbbb called the 974 Capability Object is defined in Section 4.2 in this document. The 975 Class-Number is TBA by IANA. A value of 132 is suggested. 977 A new RSVP message type called a RecoveryPath message is defined in 978 Section 4.1 of this document. The RSVP message type is TBA by IANA. 979 A value of 30 is suggested. 981 This document creates a new name space in the Capability object 982 defined in Section 4.2. The new name space is a 32 bit-wide field. 983 New registrations in this name space are to be allocated by IANA 984 through an IETF Consensus action, per [RFC2434]. IANA also serves as 985 the repository for this name space. 987 Section 4.2 defines the following bits in the 32-bit field of the 988 Capability Object, TBA by IANA: 990 RecoveryPath Transmit Enabled (T): 1 bit 991 RecoveryPath Desired (R): 1 bit 992 RecoveryPath Srefresh Capable (S): 1 bit 994 9. Normative References 996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 997 Requirement Levels", BCP 14, RFC 2119, March 1997. 999 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1000 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1001 Functional Specification", RFC 2205, September 1997. 1003 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1004 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1005 October 1998. 1007 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1008 Authentication", RFC 2747, January 2000. 1010 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1011 and S. Molendini, "RSVP Refresh Overhead Reduction 1012 Extensions", RFC 2961, April 2001. 1014 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1015 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1016 Tunnels", RFC 3209, December 2001. 1018 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1019 (GMPLS) Signaling Functional Description", RFC 3471, 1020 January 2003. 1022 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1023 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1024 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1026 Authors' Addresses 1028 Arun Satyanarayana (editor) 1029 Cisco Systems, Inc. 1030 170 West Tasman Dr. 1031 San Jose, CA 95134 1032 USA 1033 Phone: +1 408 853-3206 1034 EMail: asatyana@cisco.com 1036 Reshad Rahman (editor) 1037 Cisco Systems, Inc. 1038 2000 Innovation Dr. 1039 Kanata, Ontario K2K 3E8 1040 Canada 1041 Phone: 613 254-3519 1042 EMail: rrahman@cisco.com 1043 Dimitri Papadimitriou 1044 Alcatel 1045 Francis Wellesplein 1 1046 B-2018 Antwerpen 1047 Belgium 1048 Email: dimitri.Papadimitriou@alcatel-lucent.be 1050 Phone: +32 3 240-8491 1051 EMail: dimitri.papadimitriou@alcatel.be 1052 Lou Berger 1053 LabN Consulting, L.L.C. 1054 Phone: +1 301 468-9228 1055 EMail: lberger@labn.net 1057 Anca Zamfir 1058 Cisco Systems, Inc. 1059 2000 Innovation Dr. 1060 Kanata, Ontario K2K 3E8 1061 Canada 1062 Phone: 613 254-3484 1063 EMail: ancaz@cisco.com 1065 Junaid Israr 1066 Cisco Systems, Inc. 1067 2000 Innovation Dr. 1068 Kanata, Ontario K2K 3E8 1069 Canada 1070 Phone: 613 254-3693 1071 EMail: jisrar@cisco.com 1073 Full Copyright Statement 1075 Copyright (C) The IETF Trust (2007). 1077 This document is subject to the rights, licenses and restrictions 1078 contained in BCP 78, and except as set forth therein, the authors 1079 retain all their rights. 1081 This document and the information contained herein are provided on an 1082 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1083 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1084 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1085 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1086 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1087 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1089 Intellectual Property 1091 The IETF takes no position regarding the validity or scope of any 1092 Intellectual Property Rights or other rights that might be claimed to 1093 pertain to the implementation or use of the technology described in 1094 this document or the extent to which any license under such rights 1095 might or might not be available; nor does it represent that it has 1096 made any independent effort to identify any such rights. Information 1097 on the procedures with respect to rights in RFC documents can be 1098 found in BCP 78 and BCP 79. 1100 Copies of IPR disclosures made to the IETF Secretariat and any 1101 assurances of licenses to be made available, or the result of an 1102 attempt made to obtain a general license or permission for the use of 1103 such proprietary rights by implementers or users of this 1104 specification can be obtained from the IETF on-line IPR repository at 1105 http://www.ietf.org/ipr. 1107 The IETF invites any interested party to bring to its attention any 1108 copyrights, patents or patent applications, or other proprietary 1109 rights that may cover technology that may be required to implement 1110 this standard. Please address the information to the IETF at 1111 ietf-ipr@ietf.org. 1113 Acknowledgements 1115 Funding for the RFC Editor function is provided by the IETF 1116 Administrative Support Activity (IASA). This document was produced 1117 using xml2rfc v1.32pre3 (of http://xml.resource.org/) from a source 1118 in RFC-2629 XML format.