idnits 2.17.1 draft-matthews-mpls-ldp-ibb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack 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 (February 2000) is 8830 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) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-05 -- Possible downref: Normative reference to a draft: ref. 'WARD' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Philip Matthews 2 INTERNET-DRAFT Nortel Networks 3 Expiration Date: August 2000 February 2000 5 LDP/CR-LDP Session Reestablishment -- I'll Be Back 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 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/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This contribution proposes modifications to the LDP and CR-LDP 33 protocols that allow an LDP or CR-LDP session to be reestablished 34 using a new TCP connection if the old TCP connection goes down 35 unexpectedly. It also proposes that, in certain situations, an LSR 36 continue to use the label bindings associated with a session for a 37 short time after the session goes down, to allow forwarding to 38 continue uninterrupted while the two peer LSRs attempt to 39 reestablish the session. These modifications allow an LSR to easily 40 implement hitless software upgrades and hitless activity switches. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC 2119. 48 1. Introduction 50 Many recent router architectures decouple the control plane from the 51 data plane, so that packet forwarding can continue even if the 52 control software gets interrupted. One source of interruptions 53 occurs during control switches; for example, when a router switches 54 to a new version of the control software, or switches to a backup 55 control processor in a control redundant system. It is possible to 56 design a router to make these interruptions very brief, however, the 57 nature of the TCP protocol is such that it is difficult to keep a 58 TCP connection up across a control switch. 60 The current specification of the LDP and CR-LDP protocols ([LDP] and 61 [CR-LDP]) state that if the TCP connection associated with an LDP or 62 CR-LDP session goes down, then the session itself is terminated and 63 all label bindings are discarded. For that reason, it is difficult 64 today to build an LSR which can keep its LDP and CR-LDP sessions up 65 across a control switch. 67 This contribution proposes modifications to the LDP and CR-LDP 68 protocols that allow an LDP or CR-LDP session to be reestablished 69 using a new TCP connection if the old TCP connection goes down. It 70 also proposes that, in certain situations, an LSR continue to use 71 the label bindings associated with a session for a short time after 72 the session goes down, to allow forwarding to continue uninterrupted 73 while the two peer LSRs attempt to reestablish the session. These 74 changes allow a router to undergo a control switch with minimal 75 disruption to the surrounding network. 77 This contribution proposes that the two peer LSRs negotiate at 78 session establishment time whether they wish to allow the session to 79 be restarted or not. If this capability is not agreed to, then the 80 session operates as specified in [LDP] and [CR-LDP], and the new 81 procedures described here are not used. The negotiation procedure is 82 such that an LSR which implements these modifications can establish 83 a session with a peer without any a priori knowledge of whether the 84 peer supports these new procedures or not. 86 2. Overview of the Method 88 Say X and Y are two peer LSRs. When X and Y first establish an LDP 89 or CR-LDP session, they include a new TLV, the Session 90 Reestablishment Capability TLV, in the Initialization messages they 91 exchange to negotiate the use of the procedures described in this 92 draft. 94 Once Session Reestablishment Capability has been negotiated, the two 95 peers use the message id field present in all LDP and CR-LDP 96 messages to track those messages that have been sent to their peer 97 LSR but not yet processed. To enable them to do this, the two LSRs 98 treat the message id field as a 32-bit unsigned sequence number, 99 incrementing it by one with each new message sent, and rolling it 100 over to 0 after 2**31 - 1 is reached. This form of message id 101 allocation is not required by the base LDP and CR-LDP specifications 102 [LDP] and [CR-LDP], but is required by the procedures described in 103 this draft. 105 Now say LSR X sends a message M to LSR Y. After it does so, X 106 remembers that it has sent message M against the eventuality that 107 TCP connection carrying M may be broken before Y receives the 108 message. 110 When Y receives M, then it first processes the message according to 111 the normal LDP or CR-LDP procedures. Y also records its new state in 112 some manner that allows the state to be remembered across a session 113 restart event. (For example, it may write the new state into non- 114 volatile memory). 116 LSR Y then acks message M by using a new TLV, the Message Ack TLV, 117 which contains the message id that X assigned to M. This Message Ack 118 TLV is piggybacked on some message that Y happens to be sending back 119 to X. 121 When X receives the ack, it knows that message M has been processed, 122 so it can now discard the record it kept of M. 124 Now say some event happens that causes the TCP connection to drop. 125 For example, Y might have control redundancy enabled and experience 126 an activity switch. In this case, neither X or Y have any prior 127 warning of the event. Alternatively, Y may be undergoing a software 128 upgrade. In this case, Y may be able to shutdown the LDP session 129 gracefully by sending a Notification message to X containing a new 130 status code, the I'll-Be-Back status code, which indicates that Y 131 hopes to reestablish the LDP or CR-LDP session shortly. In either 132 case, Y is able to continue forwarding labelled packets without 133 interruption (or with only a very brief interruption). 135 To reestablish the session, they first establish a new TCP 136 connection, and then exchange Initialization messages. These 137 Initialization messages contain a new TLV, the Want To Reestablish 138 TLV, which indicates the willingness of each peer to reestablish the 139 previous LDP or CR-LDP session. In the Initialization message sent 140 by X, the Want To Reestablish TLV contains the message id of the 141 last message that X managed to receive and process from Y before the 142 old TCP connection went down. Similarly, the Initialization message 143 from Y includes a Want To Reestablish TLV giving the message id of 144 the last message that Y had received and processed from X. 146 Once Initialization messages have been successfully exchanged, the 147 session has been reestablished. At this point, both peers know 148 precisely which messages were sent but not received, and can resend 149 the missed messages. However, an LSR is not forced to send the 150 missed messages in the precise way that they sent originally: it is 151 free to send whatever messages it wishes to in whatever order it 152 wishes to. 154 If the session is not reestablished, either because Y does not 155 recover from the event, or because X and Y decide not to reestablish 156 the session for some reason, then after a short interval X and Y 157 both discard the label bindings associated with the session. 159 3. New TLVs and Status Codes 161 The following subsections describe the new TLVs introduced by the 162 proposed method. 164 3.1 Session Reestablishment Capability TLV 166 The Session Restart Capability TLV can appear in the Initialization 167 message to indicate willingness to follow the procedures described 168 in this draft. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |1|0| Session Reestab Cap | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Max Session Down Interval | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Reserved 181 This field must be set to zeros on transmission, and ignored on 182 reception. (Future enhancements to this procedure might use this 183 field for flags or other purposes). 185 Max Session Down Interval 186 The maximum interval (in milliseconds) this LSR is willing to 187 allow between the time it determines the TCP connection is broken 188 and the time it determines the session has been successfully 189 reestablished. Note that both ends propose Max Session Down 190 Intervals -- the actual value is the minimum of the two proposed 191 values. 193 The Session Reestablishment Capability TLV is an "optional" TLV 194 according to the terminology of [LDP] and [CR-LDP]. It MUST appear 195 only in the Initialization message and only when the LSR wishes to 196 use the procedures described in this draft. 198 Because it is an optional TLV, the TLV has the U bit set to indicate 199 that it should be ignored if it is not understood. This allows an 200 LSR to propose the use of these procedures, but revert easily to 201 standard [LDP] or [CR-LDP] operation if its peer does not understand 202 the TLV. (See the procedures section below.) 204 3.2 Want To Reestablish TLV 206 The Want To Reestablish TLV can appear in the Initialization message 207 to indicate willingness to reestablish a previous an [LDP] or [CR- 208 LDP] session that had been prematurely terminated. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |1|0| Want To Reestablish | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Reserved | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Last Message ID Processed | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Reserved 221 This field must be set to zeros on transmission, and ignored on 222 reception. (Future enhancements to this procedure might use this 223 field for flags or other purposes). 225 Last Message ID Processed 226 The ID of the last message which the sending LSR received and 227 processed from the receiving LSR. The sending LSR may have 228 received later messages from the receiving LSR, but the sending 229 LSR did not complete processing of them and thus does not remember 230 them. 232 The Want To Reestablish TLV is an "optional" TLV according to the 233 terminology of [LDP] and [CR-LDP]. It MUST appear only in the 234 Initialization message and only when the LSR wishes to restart a 235 session using the procedures described in this draft. 237 Because it is an optional TLV, the TLV has the U bit set to indicate 238 that it should be ignored if it is not understood. This allows an 239 LSR to propose the restart of a session, but revert easily to 240 standard [LDP] or [CR-LDP] operation if its peer does not understand 241 the TLV. (See the procedures section below.) 242 3.3 Message Ack TLV 244 The Message Ack TLV can appear in any message to indicate 245 acknowledgement of a message which the sending LSR has received from 246 the receiving LSR. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |1|0| Message Ack | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Last Message ID Processed | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Last Message ID Processed 257 The ID of the last message which the sending LSR received and 258 processed from the receiving LSR. 260 Note that the ack is cumulative; that is, the use of this TLV acks 261 not only the message specified but all previous messages. The 262 receiving LSR MUST be able to accept gaps in the sequence of message 263 IDs acked using this TLV. For example, it is acceptable for an LSR 264 to include a Message Ack TLV with a value of 5, then not include any 265 Message Ack TLV for a period of time, and then include a Message Ack 266 TLV with a value of 12. This latter Message Ack TLV acks all 267 messages from 6 to 12 inclusive. 269 The Message Ack TLV is an "optional" TLV according to the 270 terminology of [LDP] and [CR-LDP]. It MAY appear in any message, but 271 SHOULD appear only if the use of the procedures described in this 272 draft has been agreed to by both peers. 274 Because it is an optional TLV, the TLV has the U bit set to indicate 275 that it should be ignored if it is not understood. It also has the F 276 bit cleared to indicate that it should not be forwarded to any other 277 LSRs. 279 3.4 Status codes 281 This draft defines the following new status codes. See the 282 procedures section for how they are used. 284 Status Code E Status Data 286 I'll Be Back 1 (tbd) 287 Session Rejected/ 1 (tbd) 288 Parameters Max Session 289 Down Interval 290 Session Rejected/ 1 (tbd) 291 No Previous Session 293 Session Rejected/ 1 (tbd) 294 Parameters Last Message 295 ID Processed 296 Session Rejected/ 1 (tbd) 297 Session Parameter 298 Changed 299 Bad Message ID 1 (tbd) 300 Bad Message Ack 1 (tbd) 301 Out of Message IDs 1 (tbd) 303 4. New Procedures 305 4.1 Session Establishment 307 The procedures for session initialization are as specified in 308 Section 2.5 of [LDP] with the following modifications. 310 a) An LSR which wishes to follow the procedures described in this 311 draft includes a Session Reestablishment Capability TLV in the 312 Initialization message it sends to its peer. An LSR which does 313 not wish to follow the procedures described here does not include 314 this TLV. 316 b) An LSR which receives an Initialization message containing a 317 Session Reestablishment Capability TLV and which recognizes this 318 TLV, but does not wish to follow the procedures described here 319 ignores the TLV when processing the Initialization message. In 320 particular, it SHOULD NOT send an "Unknown TLV" Status Code in 321 reply. 323 c) An LSR which receives an Initialization message containing a 324 Session Reestablishment Capability, and which wishes to follow 325 the procedures described here, computes the minimum of the Max 326 Session Down Interval specified in the message and its own Max 327 Session Down Interval. If this value is acceptable, then it 328 considers the TLV acceptable when processing the Initialization 329 message, and it MUST use this computed value as the actual Max 330 Session Down Interval for the duration of the session. If this 331 value is not acceptable, then it SHOULD send an error 332 Notification with a status code of "Session Rejected/Parameters 333 Max Session Down Interval". 335 d) An LSR MUST both send a Session Reestablishment Capability TLV 336 which is acceptable to its peer, and receive a Session 337 Reestablishment Capability which is acceptable to it in order to 338 use the procedures defined here for the remainder of the session. 339 If it does not either send or receive a Session Reestablishment 340 Capability TLV, then it SHOULD follow the procedures described in 341 [LDP] and [CR-LDP]. If both peers include Session Reestablishment 342 Capability TLVs in their Initialization messages, but the 343 computed Max Session Down Interval is not acceptable to one or 344 both peers, then the session is torn down as specified in [LDP]. 346 4.2 Message IDs 348 The procedures for using Message IDs are as specified in [LDP] or 349 [CR-LDP] with the following modifications. 351 a) Each LSR treats the Message ID field as an unsigned 32-bit 352 sequence number. 354 b) An LSR MAY use any value it wishes for the Message ID of the 355 Initialization message. The value it uses becomes the initial 356 sequence number. Subsequent messages are sent with consecutive 357 increasing sequence numbers, continuing with 0 after 2**32 - 1 is 358 used. 360 c) When a session is reestablished, the old sequence of message IDs 361 is broken and a new sequence is established with the message ID 362 of the reestablishing Initialization message. For example, some 363 implementations MAY elect to use the next number in the old 364 sequence as the message ID of the Initialization message, while 365 others MAY elect to restart the sequence at some fixed value. 367 d) An LSR which receives a message with a message ID that is not one 368 greater than the message ID of the previous message (module 369 2**32), MUST terminate the session with a status code of "Bad 370 Message ID". 372 e) An LSR MUST NOT reuse a Message ID until it has received an ack 373 for its previous use. This ensures that the LSR can uniquely 374 match message acks to messages. If an LSR is getting close to 375 exhausting this interval, then it MAY elect to stop sending 376 messages for a while to allow its peer a chance to ack some 377 messages. Regardless of whether it pauses or not, an LSR must 378 reserve the Message ID for a Notification message (with status 379 code "Out of Message IDs") which it can use to terminate the 380 session. 382 4.3 Message Acks 384 The procedures for processing received messages are as specified in 385 [LDP] or [CR-LDP] with the following additions. 387 a) When processing a message, each LSR arranges to record in some 388 way its new local state. Note that this does not require the LSR 389 to remember the message or even remember the transition it 390 underwent from its old local state to its new local state. 392 However, the processing SHOULD be done in a manner that is as 393 atomic as possible, so that if a fault occurs during processing, 394 the LSR restarts the session with the old state. 396 b) As part of the local state, each LSR keeps the message ID of the 397 last message it processed. 398 c) Whenever an LSR sends a message to its peer, the LSR MAY elect to 399 include a Message Ack TLV. The value of the Message Ack TLV 400 SHOULD be the value of the last Message ID processed. In certain 401 implementations, the routine filling in the Message Ack TLV may 402 not learn of messages that have been newly processed for some 403 time; in these implementations, the routine SHOULD use the most 404 accurate value it knows. In all cases, an LSR MUST NOT ack a 405 message that has not yet been processed. 407 d) An LSR MUST ack messages within a relatively short time after 408 processing them. 410 e) The sequence of Message Ack values MUST be monotonically 411 increasing (modulo 2**32). The value may repeat, but it may not 412 go backwards, nor can it jump ahead to a message that has not 413 been sent yet. If an LSR receives a Message Ack TLV which does 414 not obey these rules, then it MUST terminate the session with a 415 Notification message with a status code of "Bad Message Ack". 417 4.4 Session Termination 419 A sessions between peers who have negotiated the use of the Session 420 Restart capability can be terminated in the following ways. 422 a) One or both peers can experience an event that causes the TCP 423 connection to be terminated without warning. Events of this 424 nature might include activity switches in a control redundant 425 system. 427 b) One or both peers can terminate the session using a Notification 428 message with a status code of "I'll Be Back". 430 c) One or both peers can terminate the session because their local 431 TCP gave up, or because their local keepalive timer expired. 433 d) One or both peers can terminate the session using a Notification 434 message with a status code OTHER than "I'll Be Back". 436 Sessions terminated in the fourth way SHOULD NOT restarted, and an 437 LSR SHOULD reject any attempts to restart such sessions. 439 Sessions terminated in one of the first three ways are candidates 440 for restarting. An LSR SHOULD continue to use the labels received 441 from its peer and honor the labels which it has distributed to its 442 peer until it determines that either the session has been restarted 443 or it determines that the session cannot be successfully restarted. 444 If an LSR determines that an session cannot be successfully 445 restarted, it SHOULD discard any label bindings associated with the 446 session. 448 An LSR determines that a session cannot be successfully restarted 449 when one of the following occurs: 451 a) An interval longer than the computed max session down interval 452 has elapsed since the LSR detected that the old TCP connection 453 was broken. 455 b) A new session has been established, but the peers did not agree 456 to make this session a continuation of the old session. 458 4.5 Session Reestablishment 460 The procedures for reestablishing a session are an modification of 461 the procedures for establishing the session originally (as described 462 in the section "Session Establishment" above). 464 a) The two LSR peers use the LDP Identifier and Receiver LDP 465 Identifier fields of the Initialization message to uniquely 466 identify the session being reestablished. 468 b) An LSR indicates its willingness to reestablish the previous 469 session by including the Want To Reestablish TLV in its 470 Initialization message. 472 c) A previous session can only be reestablished if both peers 473 include the Want To Reestablish TLV in their Initialization 474 messages, and each peer accept the value of the Want To 475 Reestablish TLV that its receives. 477 d) If an LSR receives an Initialization message containing Want To 478 Reestablish TLV, but it has no record of a previous session 479 (perhaps because an interval greater than the computed max 480 session down interval has elapsed since the previous session was 481 terminated), then it rejects the Initialization message with a 482 "Session Rejected/No Previous Session" status code. 484 e) If an LSR receives an Initialization message containing Want To 485 Reestablish TLV, but it cannot reestablish the previous session 486 at that point for some reason, then it rejects the Initialization 487 message with a "Session Rejected/Parameters Last Message ID 488 Processed" status code. (This could happen if the peer proposed a 489 value which was out-of-range, or if, despite the peer proposing a 490 reasonable value, the local LSR simply cannot reestablish the 491 session at that point, due to some internal restriction). 493 f) The reestablished session must have the same session parameters 494 as the original session. Note that this does not mean that the 495 Initialization messages used to reestablish the session must have 496 exactly the same parameters as in the original exchange. Rather, 497 it is the parameters that result from comparing the received 498 Initialization message and the local configuration must be the 499 same. A simple way to implement this is to send the computed 500 session parameters from the original session in the 501 reestablishing Initialization message. 503 g) If a peer detects that a session will be established with changed 504 session parameters, then it SHOULD reject the session with a 505 status code of "Session Rejected/Session Parameter Changed". 507 5. Security Considerations 509 There seems to be no difficulty in using these procedures with LDP 510 or CR-LDP sessions that are protected using the MD5 signature 511 option. 513 6. Areas for Further Study 515 This section discusses some possible areas for further study. 517 a) It might be useful to allow the session to be reestablished with 518 new value for one or more session parameters. This would serve 519 two purposes: one, it would provide a simple way to renegotiate 520 session parameters, and two, it would provide a simple way of 521 taking advantage of the new capabilities of upgraded control 522 software. The main question to be answered here is: which session 523 parameter changes can be reasonable supported? It is easy to see 524 how a change in the KeepAlive interval can be accommodated, but 525 what about changes to the label advertisement discipline or a 526 decrease in the ATM label range? 528 b) It might also be useful to formalize methods of changing the 529 transport addresses associated with the session. This would be 530 particularly useful in control redundancy situations where the 531 primary and backup LDP/CR-LDP entities have different IP 532 addresses. 534 c) If the LSR which causes the TCP connection to drop plays the 535 passive role in restarting the new session, then it must wait 536 until its peer LSR initiates the session restart. If the 537 underlying cause was an activity switch on the passive LSR, then 538 the active LSR will not notice a problem until either the 539 KeepAlive timer expires or the local TCP times out. This may take 540 a while. It would be nice if the passive LSR could somehow kick 541 the active LSR into action sooner. Unfortunately, there are 542 security implications in providing such a mechanism. One solution 543 might be to add an "I've Come Back" flag to the Hello message and 544 then extend MD5 protection to these messages. 546 7. Acknowledgements 548 The original inspiration for this draft was the proposal by David 549 Ward and John Scudder for restarting BGP sessions [WARD]. I have 550 borrowed some of their terms, but the nature of LDP and CR-LDP 551 (specifically DoD mode) forced me to adopt a different approach. 553 Thanks also to Peter Ashwood-Smith for helpful comments when I was 554 working out the technical details behind this proposal. 556 8. References 558 [CR-LDP] Constraint-Based LSP Setup using LDP, 559 draft-ietf-mpls-cr-ldp-04.txt 561 [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt 563 [WARD] BGP Notification Cease: I'll Be Back, draft-ward-bgp4-ibb- 564 00.txt 566 9. Author's Address 568 Philip Matthews 569 Nortel Networks Corp. 570 P.O. Box 3511 Station C, 571 Ottawa, ON K1Y 4H7 572 Canada 573 Phone: +1 613-768-3262 574 philipma@nortelnetworks.com