idnits 2.17.1 draft-ietf-mpls-ldp-ft-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [4]), 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 (February 2001) is 8464 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) -- Missing reference section? '1' on line 18 looks like a reference -- Missing reference section? '2' on line 1347 looks like a reference -- Missing reference section? '4' on line 1431 looks like a reference -- Missing reference section? '3' on line 168 looks like a reference -- Missing reference section? '5' on line 779 looks like a reference -- Missing reference section? '6' on line 258 looks like a reference -- Missing reference section? '7' on line 258 looks like a reference -- Missing reference section? '8' on line 258 looks like a reference -- Missing reference section? '9' on line 1350 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS WG Adrian Farrel 2 Internet Draft Paul Brittain 3 Document: draft-ietf-mpls-ldp-ft-01.txt Data Connection Ltd 4 Expiration Date: August 2001 5 Philip Matthews 6 Nortel 8 Eric Gray 9 Sandburst 10 February 2001 12 Fault Tolerance for LDP and CR-LDP 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 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 NOTE: The new TLV type numbers, bit values for flags specified in 35 this draft, and new LDP status code values are preliminary suggested 36 values and have yet to be approved by IANA or the MPLS WG. See the 37 section "IANA Considerations" for further details. 39 Abstract 41 MPLS systems will be used in core networks where system downtime 42 must be kept to an absolute minimum. Many MPLS LSRs may, therefore, 43 exploit Fault Tolerant (FT) hardware or software to provide 44 high availability of the core networks. 46 The details of how FT is achieved for the various components of an FT 47 LSR, including LDP, CR-LDP, the switching hardware and TCP, are 48 implementation specific. This document identifies issues in the 49 CR-LDP specification [2] and the LDP specification [4] that make it 50 difficult to implement an FT LSR using the current LDP and CR-LDP 51 protocols, and proposes enhancements to the LDP specification to ease 52 such FT LSR implementations. 54 The extensions described here are equally applicable to CR-LDP. 56 Contents 58 0. Changes from Previous Version...................................3 59 1. Conventions and Terminology used in this document...............3 60 2. Introduction....................................................4 61 2.1 Fault Tolerance for MPLS.......................................4 62 2.2 Issues with LDP and CR-LDP.....................................5 63 3. Overview of LDP FT Enhancements.................................6 64 3.1 Establishing an FT LDP Session.................................6 65 3.1.1 Interoperation with Non-FT LSRs.............................7 66 3.2 TCP Connection Failure.........................................7 67 3.2.1 Detecting TCP Connection Failures............................7 68 3.2.2 LDP Processing after Connection Failure......................7 69 3.3 Data Forwarding During TCP Connection Failure..................8 70 3.4 FT LDP Session Reconnection....................................8 71 3.5 Operations on FT Labels........................................9 72 3.6 Label Space Depletion and Replenishment........................9 73 4. FT Operations..................................................10 74 4.1 FT LDP Messages...............................................10 75 4.1.1 FT Label Messages...........................................10 76 4.1.1.1 Scope of FT Labels........................................10 77 4.1.2 FT Address Messages........................................10 78 4.1.3 FT Label Resources Available Notification Messages..........11 79 4.2 FT Operation ACKs.............................................11 80 4.3 Preservation of FT State......................................12 81 4.4 FT Procedure After TCP Failure................................13 82 4.4.1 FT LDP Operations During TCP Failure........................14 83 4.5 FT Procedure After TCP Re-connection..........................15 84 4.5.1 Re-Issuing FT Messages......................................15 85 4.5.2 Interaction with CR-LDP LSP Modification....................16 86 5. Changes to Existing Messages...................................16 87 5.1 LDP Initialization Message....................................16 88 5.2 LDP Keepalive Message.........................................16 89 5.3 All Other LDP Session Messages................................17 90 6. New Fields and Values..........................................17 91 6.1 Status Codes..................................................17 92 6.2 FT Session TLV................................................18 93 6.3 FT Protection TLV.............................................19 94 6.4 FT ACK TLV....................................................21 95 7. Example Use....................................................22 96 7.1 Session Failure and Recovery..................................23 97 7.2 Temporary Shutdown............................................25 98 8. Security Considerations........................................26 99 9. Implementation Notes...........................................27 100 9.1 FT Recovery Support on Non-FT LSRs............................27 101 9.2 ACK generation logic..........................................27 102 10. Acknowledgements..............................................27 103 11. Intellectual Property Consideration...........................28 104 12. Full Copyright Statement......................................28 105 13. IANA Considerations...........................................28 106 13.1 FT Session TLV...............................................29 107 13.2 FT Protection TLV............................................29 108 13.3 FT ACK TLV...................................................29 109 13.4 Status Codes.................................................29 110 14. Authors' Addresses............................................29 111 15. References....................................................30 113 0.Changes From Version 0 to Version 1 115 This section will be removed from the final version of the draft. 117 The following substantive changes have been made since version 0. 118 Referenced section numbers apply to version 1 of the draft. 120 3.2.1 Add brief note on processes for detecting TCP connection 121 Failures 123 3.4 Session reconnection must use the same session parameters as were 124 in use on the failed session. 126 3.6 Add a section on label space depletion and replenishment. 128 4.1.3 Describe FT procedures for Label Resources Available 129 Notification Messages 131 4.2 Explain use of "FT Seq Numbers Exhausted" status code. 133 4.4 Recommend default value for FT Reconnection Timeout. 135 6.2 Define meaning of FT Reconnection Timeout with value 0. 137 6.3 Describe how to handle a message that describes a FEC that may 138 have wider coverage than a single label. 140 6.3 The sequence number 0x00000000 is invalid under all 141 circumstances. Sequence numbers wrap from 0xFFFFFFFF to 0x00000001. 143 7.1 Correct sequence numbers in example. 145 7.2 Add example for Temporary Shutdown. 147 1. Conventions and Terminology used in this document 149 Definitions of key words and terms applicable to LDP and CR-LDP are 150 inherited from [2] and [4]. 152 The term "FT label" is introduced in this document to 153 indicated a label for which fault tolerant operation is used. A 154 "non-FT label" is not fault tolerant and is handled as specified in 155 [2] and [4]. 157 The extensions to LDP specified in this document are collectively 158 referred to as the "LDP FT enhancements". 160 In the examples quoted, the following notation is used. 162 Ln : An LSP. For example L1. 163 Pn : An LDP peer. For example P1. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 167 this document are to be interpreted as described in RFC-2119 [3]. 169 2. Introduction 171 High Availability (HA) is typically claimed by equipment vendors 172 when their hardware achieves availability levels of at least 99.999% 173 (five 9s). To implement this, the equipment must be capable of 174 recovering from local hardware and software failures through a 175 process known as fault tolerance (FT). 177 The usual approach to FT involves provisioning backup copies of 178 hardware and software. When a primary copy fails, processing is 179 switched to the backup copy. This process, called failover, should 180 result in minimal disruption to the Data Plane. 182 In an FT system, backup resources are sometimes provisioned on a 183 one-to-one basis (1:1), sometimes as many-to-one (1:n), and 184 occasionally as many-to-many (m:n). Whatever backup provisioning is 185 made, the system must switch to the backup automatically on failure 186 of the primary, and the software and hardware state in the backup 187 must be set to replicate the state in the primary at the point 188 of failure. 190 2.1 Fault Tolerance for MPLS 192 MPLS will be used in core networks where system downtime must be kept 193 to an absolute minimum. Many MPLS LSRs may, therefore, exploit FT 194 hardware or software to provide high availability of core networks. 196 In order to provide HA, an MPLS system needs to be able to survive 197 a variety of faults with minimal disruption to the Data Plane, 198 including the following fault types: 199 - failure/hot-swap of a physical connection between LSRs 200 - failure/hot-swap of the switching fabric in the LSR 201 - failure of the TCP or LDP stack in an LSR 202 - software upgrade to the TCP or LDP stacks. 204 The first two examples of faults listed above are confined to the 205 Data Plane. Such faults can be handled by providing redundancy in 206 the Data Plane which is transparent to LDP operating in the Control 207 Plane. The last two example types of fault require action in 208 the Control Plane to recover from the fault without disrupting 209 traffic in the Data Plane. This is possible because many recent 210 router architectures separate the Control and Data Planes such that 211 forwarding can continue unaffected by recovery action in the Control 212 Plane. 214 2.2 Issues with LDP and CR-LDP 216 LDP and CR-LDP use TCP to provide reliable connections between LSRs 217 over which to exchange protocol messages to distribute labels and to 218 set up LSPs. A pair of LSRs that have such a connection are referred 219 to as LDP peers. 221 TCP enables LDP and CR-LDP to assume reliable transfer of protocol 222 messages. This means that some of the messages do not need to be 223 acknowledged (for example, Label Release). 225 LDP and CR-LDP are defined such that if the TCP connection fails, the 226 LSR should immediately tear down the LSPs associated with the session 227 between the LDP peers, and release any labels and resources assigned 228 to those LSPs. 230 It is notoriously hard to provide a Fault Tolerant implementation of 231 TCP. To do so might involve making copies of all data sent and 232 received. This is an issue familiar to implementers of other TCP 233 applications such as BGP. 235 During failover affecting the TCP or LDP stacks, therefore, the TCP 236 connection may be lost. Recovery from this position is made worse by 237 the fact that LDP or CR-LDP control messages may have been lost 238 during the connection failure. Since these messages are unconfirmed, 239 it is possible that LSP or label state information will be lost. 241 This draft describes a solution which involves 242 - negotiation between LDP peers of the intent to support extensions 243 to LDP that facilitate recovery from failover without loss of LSPs 244 - selection of FT survival on a per LSP/label basis 245 - acknowledgement of LDP messages to ensure that a full handshake is 246 performed on those messages 247 - re-issuing lost messages after failover to ensure that LSP/label 248 state is correctly recovered after reconnection of the LDP session. 250 Other objectives of this draft are to 251 - offer back-compatibility with LSRs that do not implement these 252 proposals 253 - preserve existing protocol rules described in [2] and [4] for 254 handling unexpected duplicate messages and for processing 255 unexpected messages referring to unknown LSPs/labels 256 - integrate with the LSP modification function described in [5] 257 - avoid full state refresh solutions (such as those present in RSVP: 258 see [6], [7] and [8]) whether they be full-time, or limited to 259 post-failover recovery. 261 Note that this draft concentrates on the preservation of label state 262 for labels exchanged between a pair of adjacent LSRs when the TCP 263 connection between those LSRs is lost. The is a requirement for 264 Fault Tolerant operation of LSPs, but a full implementation of end- 265 to-end protection for LSPs requires that this is combined with other 266 techniques that are outside the scope of this draft. 268 In particular, this draft does not attempt to describe how to modify 269 the routing of an LSP or the resources allocated to a label or LSP, 270 which is covered by [5]. This draft also does not address how to 271 provide automatic layer 2/3 protection switching for a label or LSP, 272 which is a separate area for study. 274 3. Overview of LDP FT Enhancements 276 The LDP FT enhancements consist of the following main elements, which 277 are described in more detail in the sections that follow. 279 - The presence of an FT Session TLV on the LDP Initialization 280 message indicates that an LSR supports the LDP FT enhancements on 281 this session. 283 - An FT Reconnect Flag in the FT Session TLV indicates whether an 284 LSR has preserved FT label state across a failure of the TCP 285 connection. 287 - An FT Reconnection Timeout, exchanged on the LDP Initialization 288 message, that indicates the maximum time peer LSRs will preserve 289 FT label state after a failure of the TCP connection. 291 - An FT Protection TLV used to identify operations that affect LDP 292 labels. All LDP messages carrying the FT Protection TLV need to 293 be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in 294 order that the state for FT labels can be correctly recovered 295 after LDP session reconnection. 297 Note that the implementation within an FT system is left open by 298 this draft. An implementation could choose to secure entire 299 messages relating to FT labels, or it could secure only the 300 relevant state information. 302 - Address advertisement is also secured by use of the FT Protection 303 TLV. This enables recovery after LDP session reconnection without 304 the need to re-advertise what may be a very large number of 305 addresses. 307 3.1 Establishing an FT LDP Session 309 In order that the extensions to LDP [4] and CR-LDP [2] described in 310 this draft can be used successfully on an LDP session between a pair 311 of LDP peers, they MUST negotiate that the LDP FT enhancements 312 are to be used on the LDP session. 314 This is done on the LDP Initialization message exchange using a new 315 FT Session TLV. Presence of this TLV indicates that the peer wants 316 to support the LDP FT enhancements on this LDP session. 318 The LDP FT enhancements MUST be supported on an LDP session if both 319 LDP peers include an FT Session TLV on the LDP Initialization 320 message. 322 If either LDP Peer does not include the FT Session TLV on the LDP 323 Initialization message, the LDP FT enhancements MUST NOT be 324 the receiving LDP peer as a serious protocol error causing the 325 session to be torn down. 327 An LSR MAY present different FT/non-FT behavior on different TCP 328 connections, even if those connections are successive instantiations 329 of the LDP session between the same LDP peers. 331 3.1.1 Interoperation with Non-FT LSRs 333 The FT Session TLV on the LDP Initialization message carries the 334 U-bit. If an LSR does not support the LDP FT enhancements, it will 335 ignore this TLV. Since such partners also do not include the FT 336 Session TLV, all LDP sessions to such LSRs will not use the LDP FT 337 enhancements. 339 The rest of this draft assumes that the LDP sessions under discussion 340 are between LSRs that do support the LDP FT enhancements, except 341 where explicitly stated otherwise. 343 3.2 TCP Connection Failure 345 3.2.1 Detecting TCP Connection Failures 347 TCP connection failures may be detected and reported to the LDP 348 component in a variety of ways. These should all be treated in the 349 same way by the LDP component. 351 - Indication from the management component that a TCP connection or 352 underlying resource is no longer active. 353 - Notification from a hardware management component of an interface 354 failure. 355 - Sockets keepalive timeout. 356 - Sockets send failure. 357 - New (incoming) Socket opened. 358 - LDP protocol timeout. 360 3.2.2 LDP Processing after Connection Failure 362 If the LDP FT enhancements are not in use on an LDP session, the 363 action of the LDP peers on failure of the TCP connection is as 364 specified in [2] and [4]. 366 All state information and resources associated with non-FT labels 367 MUST be released on the failure of the TCP connection, including 368 deprogramming the non-FT label from the switching hardware. This is 369 equivalent to the behavior specified in [4]. 371 If the LDP FT enhancements are in use on an LDP session, both LDP 372 peers SHOULD preserve state information and resources associated with 373 FT labels exchanged on the LDP session. Both LDP peers SHOULD use a 374 timer to release the preserved state information and resources 375 associated with FT-labels if the TCP connection is not restored 376 within a reasonable period. The behavior when this timer expires is 377 equivalent to the LDP session failure behavior described in [4]. 379 The FT Reconnection Timeout each LDP peer intends to apply to the LDP 380 session is carried in the FT Session TLV on the LDP Initialization 381 messages. It is RECOMMENDED that both LDP peers use the lower 382 timeout value from the LDP Initialization exchange when setting their 383 reconnection timer after a TCP connection failure. 385 3.3 Data Forwarding During TCP Connection Failure 387 An LSR that implements the LDP FT enhancements SHOULD preserve the 388 programming of the switching hardware across a failover. This 389 ensures that data forwarding is unaffected by the state of the TCP 390 connection between LSRs. 392 It is an integral part of FT failover processing in some hardware 393 configurations that some data packets might be lost. If data loss is 394 not acceptable to the applications using the MPLS network, the LDP FT 395 enhancements described in this draft SHOULD NOT be used. 397 3.4 FT LDP Session Reconnection 399 When a new TCP connection is established, the LDP peers MUST exchange 400 LDP Initialization messages. When a new TCP connection is 401 established after failure, the LDP peers MUST re-exchange LDP 402 Initialization messages. 404 If an LDP peer includes the FT Session TLV in the LDP Initialization 405 message for the new instantiation of the LDP session, it MUST also 406 set the FT Reconnect Flag according to whether it has been able to 407 preserve label state. The FT Reconnect Flag is carried in the FT 408 Session TLV. 410 If an LDP peer has preserved all state information for previous 411 instantiations of the LDP session, then it SHOULD set the FT 412 Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the 413 FT Reconnect Flag to 0. 415 If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT 416 Session TLV, both LDP peers MUST release any state information and 417 resources associated with the previous instantiation of the LDP 418 session between the same LDP peers, including FT label state and 419 Addresses. This ensures that network resources are not permanently 420 lost by one LSR if its LDP peer is forced to undergo a cold start. 422 If an LDP peer changes any session parameters (for example, the label 423 space bounds) from the previous instantiation the nature of any 424 preserved labels may have changed. In particular, previously 425 allocated labels may now be out of range. For this reason, session 426 reconnection MUST use the same parameters as were in use on the 427 session before the failure. If an LDP peer notices that the 428 parameters have been changed by the other peer it SHOULD send a 429 Notification message with the 'FT Session parameters changed' status 430 code. 432 If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST 433 use the FT label operation procedures indicated in this draft to 434 complete any label operations on FT labels that were interrupted by 435 the LDP session failure. 437 3.5 Operations on FT Labels 439 Label operations on FT labels are made Fault Tolerant by providing 440 acknowledgement of all LDP messages that affect FT labels. 441 Acknowledgements are achieved by means of sequence numbers on these 442 LDP messages. 444 The message exchanges used to achieve acknowledgement of label 445 operations and the procedures used to complete interrupted label 446 operations are detailed in the section "FT Operations". 448 Using these acknowledgements and procedures, it is not necessary for 449 LDP peers to perform a complete re-synchronization of state for all 450 FT labels, either on re-connection of the LDP session between the LDP 451 peers or on a timed basis. 453 3.6 Label Space Depletion and Replenishment 455 When an LDP peer is unable to satisfy a Label Request message because 456 it has no more available labels, it sends a Notification message 457 carrying the status code 'No label resources'. This warns the 458 requesting LDP peer that subsequent Label Request messages are also 459 likely to fail for the same reason. This message does not need to be 460 acknowledged for FT purposes since Label Request messages sent after 461 session recovery will receive the same response. 463 However, the LDP peer that receives a 'No label resources' 464 Notification stops sending Label Request messages until it receives a 465 'Label resources available' Notification message. Since this 466 unsolicited Notification might get lost during session failure, it 467 must be protected using the procedures described in this draft. 469 4. FT Operations 471 Once an FT LDP session has been established, using the procedures 472 described in the section "Establishing an FT LDP Session", both LDP 473 peers MUST apply the procedures described in this section for FT LDP 474 message exchanges. 476 If the LDP session has been negotiated to not use the LDP FT 477 enhancements, these procedures MUST NOT be used. 479 4.1 FT LDP Messages 481 4.1.1 FT Label Messages 483 A label is identified as being an FT label if the initial Label 484 Request or Label Mapping message relating to that label carries the 485 FT Protection TLV. 487 If a label is an FT label, all LDP messages affecting that label MUST 488 carry the FT Protection TLV in order that the state of the label can 489 be recovered after a failure of the LDP session. 491 4.1.1.1 Scope of FT Labels 493 The scope of the FT/non-FT status of a label is limited to the 494 LDP message exchanges between a pair of LDP peers. 496 In Ordered Control, when the message is forwarded downstream or 497 upstream, the TLV may be present or absent according to the 498 requirements of the LSR sending the message. 500 4.1.2 FT Address Messages 502 If an LDP session uses the LDP FT enhancements, both LDP peers 503 MUST secure Address and Address Withdraw messages using FT Operation 504 ACKs, as described below. This avoids any ambiguity over whether 505 an Address is still valid after the LDP session is reconnected. 507 If an LSR determines that an Address message that it sent on a 508 previous instantiation of a recovered LDP session is no longer valid, 509 it MUST explicitly issue an Address Withdraw for that address when 510 the session is reconnected. 512 If the FT Reconnect Flag is not set by both LDP peers on reconnection 513 of an LDP session (i.e. state has not been preserved), both LDP 514 peers MUST consider all Addresses to have been withdrawn. The LDP 515 peers SHOULD issue new Address messages for all their valid addresses 516 as specified in [4]. 518 4.1.3 FT Label Resources Available Notification Messages 520 In LDP, it is possible that a downstream LSR may not have labels 521 available to respond to a Label Request. In this case, as specified 522 in RFC3036, the downstream LSR must respond with a Notification - No 523 Label Resources message. The upstream LSR then suspends asking for 524 new labels until it receives a Notification - Label Resources 525 Available message from the downstream LSR. 527 When the FT extensions are used on a sesssion: 528 1. The downstream LSR must preserve the label availability state 529 across a failover so that it remembers to send Notification - 530 Label Resources Available when the resources become available. 531 2. The upstream LSR must recall the label availability state across 532 failover so that it can optimize not sending Label Requests when 533 it recovers. 534 3. The downstream LSR must use sequence numbers on Notification - 535 Label Resources Available so that it can check that LSR A has 536 received the message and clear its secured state, or resend the 537 message if LSR A recovers without having received it. 539 If the FT Reconnect Flag is not set by both LDP peers on reconnection 540 of an LDP session (i.e. state has not been preserved), both LDP 541 peers MUST consider the label availability state to have been reset 542 as if the session had been set up for the first time. 544 4.2 FT Operation ACKs 546 Handshaking of FT LDP messages is achieved by use of ACKs. 547 Correlation between the original message and the ACK is by means of 548 the FT Sequence Number contained in the FT Protection TLV, and passed 549 back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP 550 message that is sent on the TCP connection between LDP peers. 552 An LDP peer maintains a separate FT sequence number for each LDP 553 session it participates in. The FT Sequence number is incremented by 554 one for each FT LDP message (i.e. containing the FT Protection TLV) 555 issued by this LSR on the FT LDP session with which the FT sequence 556 number is associated. 558 When an LDP peer receives a message containing the FT Protection TLV, 559 it MUST take steps to secure this message (or the state information 560 derived from processing the message). Once the message is secured, 561 it MUST be ACKed. However, there is no requirement on the LSR to 562 send this ACK immediately. 564 ACKs may be accumulated to reduce the message flow between LDP peers. 565 For example, if an LSR received FT LDP messages with sequence numbers 566 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK 567 receipt and securing of all these messages. 569 ACKs MUST NOT be sent out of sequence, as this is incompatible with 570 the use of accumulated ACKs. Duplicate ACKs (that is two successive 571 messages that acknowledge the same sequence number) are acceptable. 573 If an LDP peer discovers that its sequence number space for a 574 specific session is full of un-acknowledged sequence numbers (because 575 its partner on the session has not acknowledged them in a timely way) 576 it cannot allocate a new sequence number for any further FT LPD 577 message. It SHOULD send a Notification message with the status code 578 "FT Seq Numbers Exhausted". 580 4.3 Preservation of FT State 582 If the LDP FT enhancements are in use on an LDP session, each LDP 583 peer SHOULD NOT release the state information and resources 584 associated with FT labels exchanged on that LDP session when the TCP 585 connection fails. This is contrary to [2] and [4], but allows label 586 operations on FT labels to be completed after re-connection of the 587 TCP connection. 589 Both LDP peers on an LDP session that is using the LDP FT 590 enhancements SHOULD preserve the state information and resources they 591 hold for that LDP session as described below. 593 - An upstream LDP peer SHOULD release the resources (in 594 particular bandwidth) associated with an FT label when it 595 initiates a Label Release or Label Abort message for the label. 596 The upstream LDP peer MUST preserve state information for 597 the label, even if it releases the resources associated with the 598 label, as it may need to reissue the label operation if the 599 TCP connection is interrupted. 601 - An upstream LDP peer MUST release the state information 602 and resources associated with an FT label when it receives an 603 acknowledgement to a Label Release or Label Abort message that it 604 sent for the label, or when it sends a Label Release 605 message in response to a Label Withdraw message received from the 606 downstream LDP peer. 608 - A downstream LDP peer SHOULD NOT release the resources 609 associated with an FT label when it sends a Label Withdraw message 610 for the label as it has not yet received confirmation that the 611 upstream LDP peer has ceased to send data using the label. The 612 downstream LDP peer MUST NOT release the state information it 613 holds for the label as it may yet have to reissue the label 614 operation if the TCP connection is interrupted. 616 - A downstream LDP peer MUST release the resources and state 617 information associated with an FT label when it receives an 618 acknowledgement to a Label Withdraw message for the label. 620 - When the FT Reconnection Timeout expires, an LSR SHOULD release 621 all state information and resources from previous instantiations 622 of the (permanently) failed LDP session. 624 - When an LSR receives a Status TLV with the E-bit set in 625 the status code, which causes it to close the TCP connection, the 626 LSR MUST release all state information and resources associated 627 with the session. This behavior is mandated because it is 628 impossible for the LSR to predict the precise state and future 629 behavior of the partner LSR that set the E-bit without knowledge 630 of the implementation of that partner LSR. 632 Note that the "Temporary Shutdown" status code does not have the 633 E-bit set, and MAY be used during maintenance or upgrade 634 operations to indicate that the LSR intends to preserve state 635 across a closure and re-establishment of the TCP session. 637 - If an LSR determines that it must release state for any single FT 638 label during a failure of the TCP connection on which that label 639 was exchanged, it MUST release all state for all labels on the LDP 640 session. 642 The release of state information and resources associated with non-FT 643 labels is as described in [2] and [4]. 645 Note that a Label Release and the acknowledgement to a Label Withdraw 646 may be received by a downstream LSR in any order. The downstream LSR 647 MAY release its resources on receipt of the first message and MUST 648 release its resources on receipt of the second message. 650 4.4 FT Procedure After TCP Failure 652 When an LSR discovers or is notified of a TCP connection failure it 653 SHOULD start an FT Reconnection Timer to allow a period for 654 re-connection of the TCP connection between the LDP peers. 656 The RECOMMENDED default value for this timer is 5 seconds. During 657 this time, failure must be detected and reported, new hardware may 658 need to be activated, software state must be audited, and a new TCP 659 session must be set up. 661 Once the TCP connection between LDP peers has failed, the active LSR 662 SHOULD attempt to re-establish the TCP connection. The mechanisms, 663 timers and retry counts to re-establish the TCP connection are an 664 implementation choice. It is RECOMMENDED that any attempt to 665 re-establish the connection take account of the failover processing 666 necessary on the peer LSR, the nature of the network between the 667 LDP peers, and the FT Reconnection Timeout chosen on the previous 668 instantiation of the TCP connection (if any). 670 If the TCP connection cannot be re-established within the FT 671 Reconnection Timeout period, the LSR detecting this timeout SHOULD 672 release all state preserved for the failed LDP session. If the TCP 673 connection is subsequently re-established (for example, after a 674 further Hello exchange to set up a new LDP session), the LSR MUST set 675 the FT Reconnect Flag to 0 if it released the preserved state 676 information on this timeout event. 678 If the TCP connection is successfully re-established within the FT 679 Reconnection Timeout, both peers MUST re-issue LDP operations that 680 were interrupted by (that is, un-acknowledged as a result of) the TCP 681 connection failure. This procedure is described in section "FT 682 Procedure After TCP Re-connection". 684 The Hold Timer for an FT LDP Session (see [4] section 2.5.5) SHOULD 685 be ignored while the FT Reconnection Timer is running. The hold 686 timer SHOULD be restarted when the TCP connection is re-established. 688 4.4.1 FT LDP Operations During TCP Failure 690 When the LDP FT enhancements are in use for an LDP session, it is 691 possible that an LSR may determine that it needs to send an LDP 692 message to an LDP peer but that the TCP connection to that peer is 693 currently down. These label operations affect the state of FT labels 694 preserved for the failed TCP connection, so it is important that the 695 state changes are passed to the LDP peer when the TCP connection is 696 restored. 698 If an LSR determines that it needs to issue a new FT LDP operation to 699 an LDP peer to which the TCP connection is currently failed, it MUST 700 pend the operation (e.g. on a queue) and complete that operation 701 with the LDP peer when the TCP connection is restored, unless the 702 label operation is overridden by a subsequent additional operation 703 during the TCP connection failure (see section "FT Procedure After 704 TCP Re-connection") 706 In ordered operation, received FT LDP operations that cannot be 707 correctly forwarded because of a TCP connection failure MAY be 708 processed immediately (provided sufficient state is kept to forward 709 the label operation) or pended for processing when the onward TCP 710 connection is restored and the operation can be correctly forwarded 711 upstream or downstream. Operations on existing FT labels SHOULD NOT 712 be failed during TCP session failure. 714 It is RECOMMENDED that Label Request operations for new FT labels are 715 not pended awaiting the re-establishment of TCP connection that is 716 awaiting recovery at the time the LSR determines that it needs to 717 issue the Label Request message. Instead, such Label Request 718 operations SHOULD be failed and, if necessary, a notification message 719 containing the "No LDP Session" status code sent upstream. 721 Label Requests for new non-FT labels MUST be rejected during TCP 722 connection failure, as specified in [2] and [4]. 724 4.5 FT Procedure After TCP Re-connection 726 The FT operation handshaking described above means that all state 727 changes for FT labels and Address messages are confirmed or 728 reproducible at each LSR. 730 If the TCP connection between LDP peers fails but is re-connected 731 within the FT Reconnection Timeout, both LDP peers on the connection 732 MUST complete any label operations for FT labels that were 733 interrupted by the failure and re-connection of the TCP connection. 734 Label operation are completed using the procedure described below. 736 4.5.1 Re-Issuing FT Messages 738 On restoration of the TCP connection between LDP peers, any FT 739 LDP messages that were lost because of the TCP connection 740 failure are re-issued. The LDP peer that receives a re-issued message 741 processes the message as if received for the first time. 743 "Net-zero" combinations of messages need not be re-issued after 744 re-establishment of the TCP connection between LDP peers. This leads 745 to the following rules for re-issuing messages that are not ACKed by 746 the LDP peer on the LDP Initialization message exchange after 747 re-connection of the TCP session. 749 - A Label Request message MUST be re-issued unless a Label Abort 750 would be re-issued for the same FT label. 752 - A Label Mapping message MUST be re-issued unless a Label Withdraw 753 message would be re-issued for the same FT label. 755 - All other messages on the LDP session that carried the FT 756 Protection TLV MUST be re-issued if an acknowledgement had not 757 previously been received. 759 Any FT label operations that were pended (see section "FT Label 760 Operations During TCP Failure") during the TCP connection failure 761 MUST also be issued on re-establishment of the LDP session, except 762 where they form part of a "net-zero" combination of messages 763 according to the above rules. 765 The determination of "net-zero" FT label operations according to the 766 above rules MAY be performed on pended messages prior to the 767 re-establishment of the TCP connection in order to optimize the use 768 of queue resources. Messages that were sent to the LDP peer before 769 the TCP connection failure, or pended messages that are paired with 770 them, MUST NOT be subject to such optimization until an FT ACK TLV is 771 received from the LDP peer. This ACK allows the LSR to identify 772 which messages were received by the LDP peer prior to the TCP 773 connection failure. 775 4.5.2 Interaction with CR-LDP LSP Modification 777 Re-issuing LDP messages for FT operation is orthogonal to the use of 778 duplicate messages marked with the Modify ActFlg, as specified in 779 [5]. Each time an LSR uses the modification procedure for an FT LSP 780 to issue a new Label Request message, the FT label operation 781 procedures MUST be separately applied to the new Label Request 782 message. 784 5. Changes to Existing Messages 786 5.1 LDP Initialization Message 788 The LDP FT enhancements add the following optional parameters to a 789 LDP Initialization message 791 Optional Parameter Length Value 793 FT Session TLV 4 See below 794 FT ACK TLV 4 See below 796 The encoding for these TLVs is found in Section "New Fields and 797 Values". 799 FT Session 800 If present, specifies the FT behavior of the LDP session. 802 FT ACK TLV 803 If present, specifies the last FT message that the sending LDP 804 peer was able to secure prior to the failure of the previous 805 instantiation of the LDP session. This TLV is only present if 806 the FT Reconnect flag is set in the FT Session TLV, in which 807 case this TLV MUST be present. 809 5.2 LDP Keepalive Messages 811 The LDP FT enhancements add the following optional parameter to a 812 LDP Keepalive message 814 Optional Parameter Length Value 816 FT ACK TLV 4 See below 818 The encoding for FT ACK TLV is found in Section "FT ACK TLV". 820 FT ACK TLV 821 If present, specifies the most recent FT message that the 822 sending LDP peer has been able to secure. 824 5.3 All Other LDP Session Messages 826 The LDP FT enhancements add the following optional parameters to all 827 other message types that flow on an LDP session after the LDP 828 Initialization message 830 Optional Parameter Length Value 832 FT Protection TLV 4 See below 833 FT ACK TLV 4 See below 835 The encoding for these TLVs is found in the section "New Fields and 836 Values". 838 FT Protection 839 If present, specifies FT Sequence Number for the LDP message. 841 FT ACK 842 If present, identifies the most recent FT LDP message 843 ACKed by the sending LDP peer. 845 6. New Fields and Values 847 6.1 Status Codes 849 The following new status codes are defined to indicate various 850 conditions specific to the LDP FT enhancements. These status codes 851 are carried in the Status TLV of a Notification message. 853 The "E" column is the required setting of the Status Code E-bit; the 854 "Status Data" column is the value of the 30-bit Status Data field in 855 the Status Code TLV. 857 Note that the setting of the Status Code F-bit is at the discretion 858 of the LSR originating the Status TLV. However, it is RECOMMENDED 859 that the F-bit is not set on Notification messages containing 860 status codes except "No LDP Session" because the duplication of 861 messages SHOULD be restricted to being a per-hop behavior. 863 Status Code E Status Data 865 No LDP Session 0 0x000000xx 866 Zero FT seqnum 1 0x000000xx 867 Unexpected TLV / 1 0x000000xx 868 Session Not FT 869 Unexpected TLV / 1 0x000000xx 870 Label Not FT 871 Missing FT Protection TLV 1 0x000000xx 872 FT ACK sequence error 1 0x000000xx 873 Temporary Shutdown 0 0x000000xx 874 FT Seq Numbers Exhausted 1 0x000000xx 875 FT Session parameters / 1 0x000000xx 876 changed 878 The Temporary Shutdown status code SHOULD be used in place of 879 the Shutdown status code (which has the E-bit set) if the LSR that is 880 shutting down wishes to inform its LDP peer that it expects to be 881 able to preserve FT label state and to return to service before the 882 FT Reconnection Timer expires. 884 6.2 FT Session TLV 886 LDP peers can negotiate whether the LDP session between them supports 887 FT extensions by using a new OPTIONAL parameter, the FT Session 888 TLV, on LDP Initialization Messages. 890 The FT Session TLV is encoded as follows. 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |1|0| FT Session TLV (0x0503) | Length (= 4) | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | FT Flags | FT Reconnection Timeout | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 FT Flags 901 FT Flags: A 16 bit field that indicates various attributes the 902 FT support on this LDP session. This fields is formatted as 903 follows: 905 0 1 906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |R| Reserved | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 R: FT Reconnect Flag. 912 Set to 1 if the sending LSR has preserved state and 913 resources for all FT-labels since the previous LDP 914 session between the same LDP peers, and set to 0 915 otherwise. See the section "FT LDP Session 916 Reconnection" for details of how this flag is used. 918 If the FT Reconnect Flag is set, the sending LSR must 919 include an FT ACK TLV on the LDP Initialization message. 921 All other bits in this field are currently reserved and SHOULD 922 be set to zero on transmission and ignored on receipt. 924 FT Reconnection Timeout 925 The period of time the sending LSR will preserve state and 926 resources for FT labels exchanged on the previous instantiation of 927 an FT LDP session that has currently failed. The timeout is 928 encoded as a 16-bit unsigned integer number of seconds. 930 A value of zero in this field means that the sending LSR will 931 preserve state and resources indefinitely. 933 See the section "FT Procedure After TCP Failure" for details of how 934 this field is used. 936 6.3 FT Protection TLV 938 LDP peers use the FT Protection TLV to indicate that an LDP message 939 contains an FT label operation. 941 The FT Protection TLV MUST NOT be used in messages flowing on an LDP 942 session that does not support the LDP FT enhancements. Its presence 943 in such messages SHALL be treated as a protocol error by the 944 receiving LDP peer which SHOULD send a Notification message with the 945 'Unexpected TLV Session Not FT' status code. 947 The FT Protection TLV MAY be carried on an LDP message transported on 948 the LDP session after the initial exchange of LDP Initialization 949 messages. In particular, this TLV MAY optionally be present on the 950 following messages: 952 - Label Request Messages in downstream on-demand distribution mode 953 - Label Mapping messages in downstream unsolicited mode. 955 If a label is to be an FT label, then the Protection TLV MUST be 956 present: 957 - on the Label Request message in DoD mode 958 - on the Label Mapping message in DU mode 959 - on all subsequent messages concerning this label. 961 Here 'subsequent messages concerning this label' means any message 962 whose Label TLV specifies this label or whose Label Request Message 963 ID TLV specifies the initial Label Request message. 965 If a label is not to be an FT label, then the Protection TLV 966 MUST NOT be present on any of these messages. The presence of the FT 967 TLV on a message relating to a non-FT label SHALL be treated as a 968 protocol error by the receiving LDP peer which SHOULD send a 969 notification message with the 'Unexpected TLV Label Not FT' status 970 code. 972 Where a Label Withdraw or Label Release message contains only a FEC 973 TLV and does not identify a single specific label, the FT TLV should 974 be included in the message if any label affected by the message is an 975 FT label. If there is any doubt as to whether an FT TLV should be 976 present, it is RECOMMENDED that the sender add the TLV. 978 When an LDP peer receives a Label Withdraw Message or Label Release 979 message that contains only a FEC, it SHALL accept the FT TLV if it is 980 present regardless of the FT status of the labels which it affects. 982 If an LDP session is an FT session as determined by the presence of 983 the FT Session TLV on the LDP Initialization messages, the FT 984 Protection TLV MUST be present: 985 - on all Address messages on the session 986 - on all Notification messages on the session that have the status 987 code 'Label Resources Available'. 989 The FT Protection TLV is encoded as follows. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |0|0| FT Protection (0x0203) | Length (= 4) | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | FT Sequence Number | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 FT Sequence Number 1000 The sequence number for this FT label operation. The 1001 sequence number is encoded as a 32-bit unsigned integer. The 1002 initial value for this field on a new LDP session is 0x00000001 and 1003 is incremented by one for each FT LDP message issued by the sending 1004 LSR on this LDP session. This field may wrap from 0xFFFFFFFF to 1005 0x00000001. 1007 This field MUST be reset to 0x00000001 if either LDP peer does not 1008 set the FT Reconnect Flag on re-establishment of the TCP 1009 connection. 1011 See the section "FT Operation Acks" for details of how this field 1012 is used. 1014 The special use of 0x00000000 is discussed in the section "FT ACK 1015 TLV" below. 1017 If an LSR receives an FT Protection TLV on a session that does not 1018 support the FT LDP enhancements, it SHOULD send a Notification 1019 message to its LDP peer containing the "Unexpected TLV, Session Not 1020 FT" status code. 1022 If an LSR receives an FT Protection TLV on an operation affecting a 1023 label that it believes is a non-FT label, it SHOULD send a 1024 Notification message to its LDP peer containing the "Unexpected TLV, 1025 Label Not FT" status code. 1027 If an LSR receives a message without the FT Protection TLV affecting 1028 a label that it believes is an FT label, it SHOULD send a 1029 Notification message to its LDP peer containing the "Missing FT 1030 Protection TLV" status code. 1032 If an LSR receives an FT Protection TLV containing a zero FT 1033 Sequence Number, it SHOULD send a Notification message to its LDP 1034 peer containing the "Zero FT Seqnum" status code. 1036 6.4 FT ACK TLV 1038 LDP peers use the FT ACK TLV to acknowledge FT label operations. 1040 The FT ACK TLV MUST NOT be used in messages flowing on an LDP session 1041 that does not support the LDP FT enhancements. Its presence on such 1042 messages SHALL be treated as a protocol error by the receiving LDP 1043 peer. 1045 The FT ACK TLV MAY be present on any LDP message exchanged on an 1046 LDP session after the initial LDP Initialization messages. It is 1047 RECOMMENDED that the FT ACK TLV is included on all FT 1048 Keepalive messages in order to ensure that the LDP peers do not 1049 build up a large backlog of unacknowledged state information. 1051 The FT ACK TLV is encoded as follows. 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 |0|0| FT ACK (0x0504) | Length (= 4) | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | FT ACK Sequence Number | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 FT ACK Sequence Number 1062 The sequence number for this most recent FT label message 1063 that the sending LDP peer has received from the receiving LDP 1064 peer and secured against failure of the LDP session. It is not 1065 necessary for the sending peer to have fully processed the message 1066 before ACKing it. For example, an LSR MAY ACK a Label Request 1067 message as soon as it has securely recorded the message, without 1068 waiting until it can send the Label Mapping message in response. 1070 ACKs are cumulative. Receipt of an LDP message containing an FT 1071 ACK TLV with an FT ACK Sequence Number of 12 is treated as the 1072 acknowledgement of all messages from 1 to 12 inclusive (assuming 1073 the LDP session started with a sequence number of 1). 1075 This field MUST be set to 0 if the LSR sending the FT ACK TLV has 1076 not received any FT label operations on this LDP session. This 1077 would apply to LDP sessions to new LDP peers or after an LSR 1078 determines that it must drop all state for a failed TCP connection. 1080 See the section "FT Operation Acks" for details of how this field 1081 is used. 1083 If an LSR receives a message affecting a label that it believes is an 1084 FT label and that message does not contain the FT Protection TLV, it 1085 SHOULD send a Notification message to its LDP peer containing the 1086 "Missing FT Protection TLV" status code. 1088 If an LSR receives an FT ACK TLV that contains an FT ACK Sequence 1089 Number that is less than the previously received FT ACK Sequence 1090 Number (remembering to take account of wrapping), it SHOULD send a 1091 Notification message to its LDP peer containing the "FT ACK 1092 Sequence Error" status code. 1094 7. Example Use 1096 Consider two LDP peers, P1 and P2, implementing LDP over a TCP 1097 connection that connects them, and the message flow shown below. 1099 The parameters shown on each message shown below are as follows: 1101 message (label, senders FT sequence number, FT ACK number) 1103 A "-" for FT ACK number means that the FT ACK TLV is not included 1104 on that message. "n/a" means that the parameter in question is not 1105 applicable to that type of message. 1107 In the diagrams below, time flows from top to bottom. The relative 1108 position of each message shows when it is transmitted. See the notes 1109 for a description of when each message is received, secured for FT or 1110 processed. 1112 7.1 Session Failure and Recovery 1114 notes P1 P2 1115 ===== == == 1116 (1) Label Request(L1,27,-) 1117 ---------------------------> 1118 Label Request(L2,28,-) 1119 ---------------------------> 1120 (2) Label Request(L3,93,27) 1121 <--------------------------- 1122 (3) Label Request(L1,123,-) 1123 --------------------------> 1124 Label Request(L2,124,-) 1125 --------------------------> 1126 (4) Label Mapping(L1,57,-) 1127 <-------------------------- 1128 Label Mapping(L1,94,28) 1129 <--------------------------- 1130 (5) Label Mapping(L2,58,-) 1131 <-------------------------- 1132 Label Mapping(L2,95,-) 1133 <--------------------------- 1134 (6) Address(n/a,29,-) 1135 ---------------------------> 1136 (7) Label Request(L4,30,-) 1137 ---------------------------> 1138 (8) Keepalive(n/a,na/,94) 1139 ---------------------------> 1140 (9) Label Abort(L3,96,-) 1141 <--------------------------- 1142 (10) ===== TCP Session lost ===== 1143 : 1144 (11) : Label Withdraw(L1,59,-) 1145 : <-------------------------- 1146 : 1147 (12) === TCP Session restored === 1149 LDP Init(n/a,n/a,94) 1150 ---------------------------> 1151 LDP Init(n/a,n/a,29) 1152 <--------------------------- 1153 (13) Label Request(L4,30,-) 1154 ---------------------------> 1155 (14) Label Mapping(L2,95,-) 1156 <--------------------------- 1157 Label Abort(L3,96,30) 1158 <--------------------------- 1159 (15) Label Withdraw(L1,97,-) 1160 <--------------------------- 1162 Notes: 1163 ====== 1165 (1) Assume that the LDP session has already been initialized. 1166 P1 issues 2 new Label Requests using the next sequence numbers. 1168 (2) P2 issues a third Label request to P1. At the time of sending 1169 this request, P2 has secured the receipt of the label request 1170 for L1 from P1, so it includes an ACK for that message. 1172 (3) P2 Processes the Label Requests for L1 and L2 and forwards them 1173 downstream. Details of downstream processing are not shown in 1174 the diagram above. 1176 (4) P2 receives a Label Mapping from downstream for L1, which it 1177 forwards to P1. It includes an ACK to the Label Request for L2, 1178 as that message has now been secured and processed. 1180 (5) P2 receives the Label Mapping for L2, which it forwards to P1. 1181 This time it does not include an ACK as it has not received any 1182 further messages from P1. 1184 (6) Meanwhile, P1 sends a new Address Message to P2 . 1186 (7) P1 also sends a fourth Label Request to P2 1188 (8) P1 sends a Keepalive message to P2, on which it includes an ACK 1189 for the Label Mapping for L1, which is the latest message P1 has 1190 received and secured at the time the Keepalive is sent. 1192 (9) P2 issues a Label Abort for L3. 1194 (10) At this point, the TCP session goes down. 1196 (11) While the TCP session is down, P2 receives a Label Withdraw 1197 Message for L1, which it queues. 1199 (12) The TCP session is reconnected and P1 and P2 exchange LDP 1200 Initialization messages on the recovered session, which include 1201 ACKS for the last message each peer received and secured prior 1202 to the failure. 1204 (13) From the LDP Init exchange, P1 determines that it needs to 1205 re-issue the Label request for L4. 1207 (14) Similarly, P2 determines that it needs to re-issue the Label 1208 Mapping for L2 and the Label Abort. 1210 (15) P2 issues the queued Label Withdraw to P1. 1212 7.2 Temporary Shutdown 1214 notes P1 P2 1215 ===== == == 1216 (1) Label Request(L1,27,-) 1217 ---------------------------> 1218 Label Request(L2,28,-) 1219 ---------------------------> 1220 (2) Label Request(L3,93,27) 1221 <--------------------------- 1222 (3) Label Request(L1,123,-) 1223 --------------------------> 1224 Label Request(L2,124,-) 1225 --------------------------> 1226 (4) Label Mapping(L1,57,-) 1227 <-------------------------- 1228 Label Mapping(L1,94,28) 1229 <--------------------------- 1230 (5) Label Mapping(L2,58,-) 1231 <-------------------------- 1232 Label Mapping(L2,95,-) 1233 <--------------------------- 1234 (6) Address(n/a,29,-) 1235 ---------------------------> 1236 (7) Label Request(L4,30,-) 1237 ---------------------------> 1238 (8) Keepalive(n/a,na/,94) 1239 ---------------------------> 1240 (9) Label Abort(L3,96,-) 1241 <--------------------------- 1242 (10) Notification(Temporary shutdown) 1243 ---------------------------> 1244 : 1245 (11) : Label Withdraw(L1,59,-) 1246 : <-------------------------- 1247 : 1248 (12) LDP Init(n/a,n/a,94) 1249 ---------------------------> 1250 LDP Init(n/a,n/a,29) 1251 <--------------------------- 1252 (13) Label Request(L4,30,-) 1253 ---------------------------> 1254 (14) Label Mapping(L2,95,-) 1255 <--------------------------- 1256 Label Abort(L3,96,30) 1257 <--------------------------- 1258 (15) Label Withdraw(L1,97,-) 1259 <--------------------------- 1261 Notes: 1262 ====== 1264 Notes are as in the previous example except as follows. 1266 (10) P1 needs to upgrade the software or hardware that it is running. 1267 It issues a Notification message to terminate the LDP session, 1268 but sets the status code as 'Temporary shutdown' to inform P2 1269 that this is not a fatal error, and P2 should maintain FT state. 1270 The TCP connection may also fail during the period that the LDP 1271 session is down (in which case it will need to be 1272 re-established), but it is also possible that the TCP connection 1273 will be preserved. 1275 8. Security Considerations 1277 The LDP FT enhancements inherit similar security considerations to 1278 those discussed in [2] and [4]. 1280 The LDP FT enhancements allow the re-establishment of a TCP 1281 connection between LDP peers without a full re-exchange of the 1282 attributes of established labels, which renders LSRs that implement 1283 the extensions specified in this draft vulnerable to additional 1284 denial-of-service attacks as follows: 1286 - An intruder may impersonate an LDP peer in order to force a 1287 failure and reconnection of the TCP connection, but where the 1288 intruder does not set the FT Reconnect Flag on re-connection. 1289 This forces all FT labels to be released. 1291 - Similarly, an intruder could set the FT Reconnect Flag on 1292 re-establishment of the TCP session without preserving the state 1293 and resources for FT labels. 1295 - An intruder could intercept the traffic between LDP peers and 1296 override the setting of the FT Label Flag to be set to 0 for 1297 all labels. 1299 All of these attacks may be countered by use of an authentication 1300 scheme between LDP peers, such as the MD5-based scheme outlined in 1301 [4]. 1303 Alternative authentication schemes for LDP peers are outside the 1304 scope of this draft, but could be deployed to provide enhanced 1305 security to implementations of LDP, CR-LDP and the LDP FT 1306 enhancements. 1308 9. Implementation Notes 1310 9.1 FT Recovery Support on Non-FT LSRs 1312 In order to take full advantage of the FT capabilities of LSRs in the 1313 network, it may be that an LSR that does not itself contain the 1314 ability to recover from local hardware or software faults still needs 1315 to support the LDP FT enhancements described in this draft. 1317 Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant 1318 LSR, P2. If P2 experiences a fault in the hardware or software that 1319 serves an LDP session between P1 and P2, it may fail the TCP 1320 connection between the peers. When the connection is recovered, the 1321 LSPs/labels between P1 and P2 can only be recovered if both LSRs were 1322 applying the FT recovery procedures to the LDP session. 1324 9.2 ACK generation logic 1326 FT ACKs SHOULD be returned to the sending LSR as soon as is 1327 practicable in order to avoid building up a large quantity of 1328 unacknowledged state changes at the LSR. However, immediate 1329 one-for-one acknowledgements would waste bandwidth unnecessarily. 1331 A possible implementation strategy for sending ACKs to FT LDP 1332 messages is as follows: 1333 - An LSR secures received messages in order and tracks the sequence 1334 number of the most recently secured message, Sr. 1335 - On each LDP KeepAlive that the LSR sends, it attaches an FT ACK 1336 TLV listing Sr 1337 - Optionally, the LSR may attach an FT ACK TLV to any other LDP 1338 message sent between Keepalive messages if, for example, Sr has 1339 increased by more than a threshold value since the last ACK sent. 1341 This implementation combines the bandwidth benefits of accumulating 1342 ACKs while still providing timely ACKs. 1344 10. Acknowledgments 1346 The work in this draft is based on the LDP and CR-LDP ideas 1347 expressed by the authors of [2] and [4]. 1349 The ACK scheme used in this draft was inspired by the proposal by 1350 David Ward and John Scudder for restarting BGP sessions [9]. 1352 The authors would also like to acknowledge the careful review and 1353 comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer, 1354 Peter Ashwood-Smith, Bob Thomas, S.Manikantan, Adam Sheppard and 1355 Alan Davey. 1357 11. Intellectual Property Consideration 1359 The IETF has been notified of intellectual property rights claimed in 1360 regard to some or all of the specification contained in this 1361 document. For more information, consult the online list of claimed 1362 rights. 1364 12. Full Copyright Statement 1366 Copyright (c) The Internet Society (2000, 2001). All Rights Reserved. 1367 This document and translations of it may be copied and furnished to 1368 others, and derivative works that comment on or otherwise explain it 1369 or assist in its implementation may be prepared, copied, published 1370 and distributed, in whole or in part, without restriction of any 1371 kind, provided that the above copyright notice and this paragraph 1372 are included on all such copies and derivative works. However, this 1373 document itself may not be modified in any way, such as by removing 1374 the copyright notice or references to the Internet Society or other 1375 Internet organizations, except as needed for the purpose of 1376 developing Internet standards in which case the procedures for 1377 copyrights defined in the Internet Standards process must be 1378 followed, or as required to translate it into languages other than 1379 English. 1381 The limited permissions granted above are perpetual and will not be 1382 revoked by the Internet Society or its successors or assigns. 1384 This document and the information contained herein is provided on an 1385 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1386 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1387 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1388 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1389 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1391 13. IANA Considerations 1393 This draft requires the use of a number of new TLVs and status codes 1394 from the number spaces within the LDP protocol. This section 1395 explains the logic used by the authors to choose the most appropriate 1396 number space for each new entity, and is intended to assist in the 1397 determination of any final values assigned by IANA or the MPLS WG in 1398 the event that the MPLS WG chooses to advance this draft on the 1399 standards track. 1401 This section will be removed when the TLV and status code values have 1402 been agreed with IANA. 1404 13.1 FT Session TLV 1406 The FT Session TLV carries attributes that affect the entire LDP 1407 session between LDP peers. It is suggested that the type for this 1408 TLV should be chosen from the 0x05xx range for TLVs that is used in 1409 [4] by other TLVs carrying session-wide attributes. At the time of 1410 this writing, the next available number in this range is 0x0503. 1412 13.2 FT Protection TLV 1414 The FT Protection TLV carries attributes that affect a single label 1415 exchanged between LDP peers. It is suggested that the type for this 1416 TLV should be chosen from the 0x02xx range for TLVs that is used in 1417 [4] by other TLVs carrying label attributes. At the time of this 1418 writing, the next available number in this range is 0x0203. 1420 Consideration was given to using the message number field instead of 1421 a new FT Sequence Number field. However, the authors felt this 1422 placed unacceptable implementation constraints on the use of message 1423 number (e.g. it could no longer be used to reference a control 1424 block). 1426 13.3 FT ACK TLV 1428 The FT Protection TLV may ACK many label operations at once 1429 if cumulative ACKS are used. It is suggested that the type for this 1430 TLV should be chosen from the 0x05xx range for TLVs that is used in 1431 [4] by other TLVs carrying session-wide attributes. At the time of 1432 this writing, the next available number in this range is 0x0504. 1434 Consideration was given to carrying the FT ACK Number in the FT 1435 Protection TLV, but the authors felt this would be inappropriate as 1436 many implementations may wish to carry the ACKs on Keepalive 1437 messages. 1439 13.4 Status Codes 1441 The authors' current understanding is that MPLS status codes are not 1442 sub-divided into specific ranges for different types of error. 1443 Hence, the numeric status code values assigned for this draft should 1444 simply be the next available values at the time of writing and may be 1445 substituted for other numeric values. 1447 See section "Status Codes" for details of the status codes defined in 1448 this draft. 1450 14. Authors' Addresses 1452 Adrian Farrel (editor) Paul Brittain 1453 Data Connection Ltd. Data Connection Ltd. 1454 Windsor House Windsor House 1455 Pepper Street Pepper Street 1456 Chester Chester 1457 Cheshire Cheshire 1458 CH1 1DF CH1 1DF 1459 UK UK 1460 Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440 1461 Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422 1462 Email: af@dataconnection.com Email: pjb@dataconnection.com 1464 Philip Matthews Eric Gray 1465 Nortel Networks Corp. Sandburst Corporation 1466 P.O. Box 3511 Station C, 600 Federal Street 1467 Ottawa, ON K1Y 4H7 Andover, MA 01810 1468 Canada Phone: +1 978-689-1600 1469 Phone: +1 613-768-3262 eric.gray@sandburst.com 1470 philipma@nortelnetworks.com 1472 15. References 1474 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1475 9, RFC 2026, October 1996. 1477 2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 1478 draft-ietf-mpls-cr-ldp-04.txt, July 2000, (work in progress). 1480 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1481 Levels", BCP 14, RFC 2119, March 1997. 1483 4 Andersson, L., et. al., LDP Specification, RFC 3036, January 2001. 1485 5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls- 1486 crlsp-modify-02.txt, October 2000 (work in progress). 1488 6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- 1489 Version 1, Functional Specification, RFC 2205, September 1997. 1491 7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft- 1492 ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress). 1494 8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft- 1495 ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000 (work in progress). 1497 9 Ward, D, et al., BGP Notification Cease: I'll Be Back, 1498 draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress) 1500 10 Stewart, R, et al., Stream Control Transmission Protocol, 1501 RFC 2906, October 2000.