idnits 2.17.1 draft-ietf-mpls-ldp-ft-00.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 1 longer page, the longest (page 7) being 59 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 (October 2000) is 8591 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 1116 looks like a reference -- Missing reference section? '4' on line 1200 looks like a reference -- Missing reference section? '3' on line 127 looks like a reference -- Missing reference section? '5' on line 646 looks like a reference -- Missing reference section? '6' on line 217 looks like a reference -- Missing reference section? '7' on line 217 looks like a reference -- Missing reference section? '8' on line 217 looks like a reference -- Missing reference section? '9' on line 1119 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-00.txt Data Connection Ltd 4 Expiration Date: March 2001 5 Philip Matthews 6 Nortel 8 Eric Gray 9 Zaffire 10 October 2000 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 1. Conventions and Terminology used in this document...............3 59 2. Introduction....................................................3 60 2.1 Fault Tolerance for MPLS.......................................3 61 2.2 Issues with LDP and CR-LDP.....................................4 62 3. Overview of LDP FT Enhancements.................................5 63 3.1 Establishing an FT LDP Session.................................6 64 3.1.1 Interoperation with Non-FT LSRs.............................6 65 3.2 TCP Connection Failure.........................................6 66 3.3 Data Forwarding During TCP Connection Failure..................7 67 3.4 FT LDP Session Reconnection....................................7 68 3.5 Operations on FT Labels........................................8 69 4. FT Operations...................................................8 70 4.1 FT LDP Messages................................................8 71 4.1.1 FT Label Messages............................................8 72 4.1.1.1 Scope of FT Labels.........................................9 73 4.1.2 FT Address Messages.........................................9 74 4.2 FT Operation ACKs..............................................9 75 4.3 Preservation of FT State......................................10 76 4.4 FT Procedure After TCP Failure................................11 77 4.4.1 FT LDP Operations During TCP Failure........................12 78 4.5 FT Procedure After TCP Re-connection..........................12 79 4.5.1 Re-Issuing FT Messages......................................13 80 4.5.2 Interaction with CR-LDP LSP Modification....................14 81 5. Changes to Existing Messages...................................14 82 5.1 LDP Initialization Message....................................14 83 5.2 LDP Keepalive Message.........................................14 84 5.3 All Other LDP Session Messages................................15 85 6. New Fields and Values..........................................15 86 6.1 Status Codes..................................................15 87 6.2 FT Session TLV................................................16 88 6.3 FT Protection TLV.............................................17 89 6.4 FT ACK TLV....................................................18 90 7. Example Use....................................................19 91 8. Security Considerations........................................23 92 9. Implementation Notes...........................................23 93 9.1 FT Recovery Support on Non-FT LSRs............................23 94 9.2 ACK generation logic..........................................24 95 10. Acknowledgements..............................................24 96 11. Intellectual Property Consideration...........................24 97 12. Full Copyright Statement......................................25 98 13. IANA Considerations...........................................25 99 13.1 FT Session TLV...............................................25 100 13.2 FT Protection TLV............................................26 101 13.3 FT ACK TLV...................................................26 102 13.4 Status Codes.................................................26 103 14. Authors' Addresses............................................27 104 15. References....................................................27 106 1. Conventions and Terminology used in this document 108 Definitions of key words and terms applicable to LDP and CR-LDP are 109 inherited from [2] and [4]. 111 The term "FT label" is introduced in this document to 112 indicated a label for which fault tolerant operation is used. A 113 "non-FT label" is not fault tolerant and is handled as specified in 114 [2] and [4]. 116 The extensions to LDP specified in this document are collectively 117 referred to as the "LDP FT enhancements". 119 In the examples quoted, the following notation is used. 121 Ln : An LSP. For example L1. 122 Pn : An LDP peer. For example P1. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 126 this document are to be interpreted as described in RFC-2119 [3]. 128 2. Introduction 130 High Availability (HA) is typically claimed by equipment vendors 131 when their hardware achieves availability levels of at least 99.999% 132 (five 9s). To implement this, the equipment must be capable of 133 recovering from local hardware and software failures through a 134 process known as fault tolerance (FT). 136 The usual approach to FT involves provisioning backup copies of 137 hardware and software. When a primary copy fails, processing is 138 switched to the backup copy. This process, called failover, should 139 result in minimal disruption to the Data Plane. 141 In an FT system, backup resources are sometimes provisioned on a 142 one-to-one basis (1:1), sometimes as many-to-one (1:n), and 143 occasionally as many-to-many (m:n). Whatever backup provisioning is 144 made, the system must switch to the backup automatically on failure 145 of the primary, and the software and hardware state in the backup 146 must be set to replicate the state in the primary at the point 147 of failure. 149 2.1 Fault Tolerance for MPLS 151 MPLS will be used in core networks where system downtime must be kept 152 to an absolute minimum. Many MPLS LSRs may, therefore, exploit FT 153 hardware or software to provide high availability of core networks. 155 In order to provide HA, an MPLS system needs to be able to survive 156 a variety of faults with minimal disruption to the Data Plane, 157 including the following fault types: 158 - failure/hot-swap of a physical connection between LSRs 159 - failure/hot-swap of the switching fabric in the LSR 160 - failure of the TCP or LDP stack in an LSR 161 - software upgrade to the TCP or LDP stacks. 163 The first two examples of faults listed above are confined to the 164 Data Plane. Such faults can be handled by providing redundancy in 165 the Data Plane which is transparent to LDP operating in the Control 166 Plane. The last two example types of fault require action in 167 the Control Plane to recover from the fault without disrupting 168 traffic in the Data Plane. This is possible because many recent 169 router architectures separate the Control and Data Planes such that 170 forwarding can continue unaffected by recovery action in the Control 171 Plane. 173 2.2 Issues with LDP and CR-LDP 175 LDP and CR-LDP use TCP to provide reliable connections between LSRs 176 over which to exchange protocol messages to distribute labels and to 177 set up LSPs. A pair of LSRs that have such a connection are referred 178 to as LDP peers. 180 TCP enables LDP and CR-LDP to assume reliable transfer of protocol 181 messages. This means that some of the messages do not need to be 182 acknowledged (for example, Label Release). 184 LDP and CR-LDP are defined such that if the TCP connection fails, the 185 LSR should immediately tear down the LSPs associated with the session 186 between the LDP peers, and release any labels and resources assigned 187 to those LSPs. 189 It is notoriously hard to provide a Fault Tolerant implementation of 190 TCP. To do so might involve making copies of all data sent and 191 received. This is an issue familiar to implementers of other TCP 192 applications such as BGP. 194 During failover affecting the TCP or LDP stacks, therefore, the TCP 195 connection may be lost. Recovery from this position is made worse by 196 the fact that LDP or CR-LDP control messages may have been lost 197 during the connection failure. Since these messages are unconfirmed, 198 it is possible that LSP or label state information will be lost. 200 This draft describes a solution which involves 201 - negotiation between LDP peers of the intent to support extensions 202 to LDP that facilitate recovery from failover without loss of LSPs 203 - selection of FT survival on a per LSP/label basis 204 - acknowledgement of LDP messages to ensure that a full handshake is 205 performed on those messages 206 - re-issuing lost messages after failover to ensure that LSP/label 207 state is correctly recovered after reconnection of the LDP session. 209 Other objectives of this draft are to 210 - offer back-compatibility with LSRs that do not implement these 211 proposals 212 - preserve existing protocol rules described in [2] and [4] for 213 handling unexpected duplicate messages and for processing 214 unexpected messages referring to unknown LSPs/labels 215 - integrate with the LSP modification function described in [5] 216 - avoid full state refresh solutions (such as those present in RSVP: 217 see [6], [7] and [8]) whether they be full-time, or limited to 218 post-failover recovery. 220 Note that this draft concentrates on the preservation of label state 221 for labels exchanged between a pair of adjacent LSRs when the TCP 222 connection between those LSRs is lost. The is a requirement for 223 Fault Tolerant operation of LSPs, but a full implementation of end- 224 to-end protection for LSPs requires that this is combined with other 225 techniques that are outside the scope of this draft. 227 In particular, this draft does not attempt to describe how to modify 228 the routing of an LSP or the resources allocated to a label or LSP, 229 which is covered by [5]. This draft also does not address how to 230 provide automatic layer 2/3 protection switching for a label or LSP, 231 which is a separate area for study. 233 3. Overview of LDP FT Enhancements 235 The LDP FT enhancements consist of the following main elements, which 236 are described in more detail in the sections that follow. 238 - The presence of an FT Session TLV on the LDP Initialization 239 message indicates that an LSR supports the LDP FT enhancements on 240 this session. 242 - An FT Reconnect Flag in the FT Session TLV indicates whether an 243 LSR has preserved FT label state across a failure of the TCP 244 connection. 246 - An FT Reconnection Timeout, exchanged on the LDP Initialization 247 message, that indicates the maximum time peer LSRs will preserve 248 FT label state after a failure of the TCP connection. 250 - An FT Protection TLV used to identify operations that affect LDP 251 labels. All LDP messages carrying the FT Protection TLV need to 252 be secured (e.g. to NVRAM) and ACKed to the sending LDP peer in 253 order that the state for FT labels can be correctly recovered 254 after LDP session reconnection. 256 3.1 Establishing an FT LDP Session 258 In order that the extensions to LDP [4] and CR-LDP [2] described in 259 this draft can be used successfully on an LDP session between a pair 260 of LDP peers, they MUST negotiate that the LDP FT enhancements 261 are to be used on the LDP session. 263 This is done on the LDP Initialization message exchange using a new 264 FT Session TLV. Presence of this TLV indicates that the 265 peer wants to support the LDP FT enhancements on this LDP session. 267 The LDP FT enhancements MUST be supported on an LDP session if both 268 LDP peers include an FT Session TLV on the LDP Initialization 269 message. 271 If either LDP Peer does not include the FT Session TLV on the LDP 272 Initialization message, the LDP FT enhancements MUST NOT be 273 used on the LDP session. 275 An LSR MAY present different FT/non-FT behavior on different TCP 276 connections, even if those connections are successive instantiations 277 of the LDP session between the same LDP peers. 279 3.1.1 Interoperation with Non-FT LSRs 281 The FT Session TLV on the LDP Initialization message carries the 282 U-bit. If an LSR does not support the LDP FT enhancements, it will 283 ignore this TLV. Since such partners also do not include the FT 284 Session TLV, all LDP sessions to such LSRs will not use the LDP FT 285 enhancements. 287 The rest of this draft assumes that the LDP sessions under discussion 288 are between LSRs that do support the LDP FT enhancements, except 289 where explicitly stated otherwise. 291 3.2 TCP Connection Failure 293 If the LDP FT enhancements are not in use on an LDP session, the 294 action of the LDP peers on failure of the TCP connection is as 295 specified in [2] and [4]. 297 All state information and resources associated with non-FT labels 298 MUST be released on the failure of the TCP connection, including 299 deprogramming the non-FT label from the switching hardware. This is 300 equivalent to the behavior specified in [4]. 302 If the LDP FT enhancements are in use on an LDP session, both LDP 303 peers SHOULD preserve state information and resources associated with 304 FT labels exchanged on the LDP session. Both LDP peers SHOULD use a 305 timer to release the preserved state information and resources 306 associated with FT-labels if the TCP connection is not restored 307 within a reasonable period. The behavior when this timer expires is 308 equivalent to the LDP session failure behavior described in [4]. 310 The FT Reconnection Timeout each LDP peer intends to apply to the LDP 311 session is carried in the FT Session TLV on the LDP Initialization 312 messages. It is RECOMMENDED that both LDP peers use the lower 313 timeout value from the LDP Initialization exchange when setting their 314 reconnection timer after a TCP connection failure. 316 3.3 Data Forwarding During TCP Connection Failure 318 An LSR that implements the LDP FT enhancements SHOULD preserve the 319 programming of the switching hardware across a failover. This 320 ensures that data forwarding is unaffected by the state of the TCP 321 connection between LSRs. 323 It is an integral part of FT failover processing in some hardware 324 configurations that some data packets might be lost. If data loss is 325 not acceptable to the applications using the MPLS network, the LDP FT 326 enhancements described in this draft SHOULD NOT be used. 328 3.4 FT LDP Session Reconnection 330 When a new TCP connection is established, the LDP peers MUST exchange 331 LDP Initialization messages. When a new TCP connection is 332 established after failure, the LDP peers MUST re-exchange LDP 333 Initialization messages. 335 If an LDP peer includes the FT Session TLV in the LDP Initialization 336 message for the new instantiation of the LDP session, it MUST also 337 set the FT Reconnect Flag according to whether it has been able to 338 preserve label state. The FT Reconnect Flag is carried in the FT 339 Session TLV. 341 If an LDP peer has preserved all state information for previous 342 instantiations of the LDP session, then it SHOULD set the FT 343 Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the 344 FT Reconnect Flag to 0. 346 If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT 347 Session TLV, both LDP peers MUST release any state information and 348 resources associated with the previous instantiation of the LDP 349 session between the same LDP peers, including FT label state and 350 Addresses. This ensures that network resources are not permanently 351 lost by one LSR if its LDP peer is forced to undergo a cold start. 353 If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST 354 use the FT label operation procedures indicated in this draft to 355 complete any label operations on FT labels that were interrupted by 356 the LDP session failure. 358 3.5 Operations on FT Labels 360 Label operations on FT labels are made Fault Tolerant by providing 361 acknowledgement of all LDP messages that affect FT labels. 362 Acknowledgements are achieved by means of sequence numbers on these 363 LDP messages. 365 The message exchanges used to achieve acknowledgement of label 366 operations and the procedures used to complete interrupted label 367 operations are detailed in the section "FT Operations". 369 Using these acknowledgements and procedures, it is not necessary for 370 LDP peers to perform a complete re-synchronization of state for all 371 FT labels, either on re-connection of the LDP session between the LDP 372 peers or on a timed basis. 374 4. FT Operations 376 Once an FT LDP session has been established, using the procedures 377 described in the section "Establishing an FT LDP Session", both LDP 378 peers MUST apply the procedures described in this section for FT LDP 379 message exchanges. 381 If the LDP session has been negotiated to not use the LDP FT 382 enhancements, these procedures MUST NOT be used. 384 4.1 FT LDP Messages 386 4.1.1 FT Label Messages 388 A label is identified as being an FT label if the initial Label 389 Request or Label Mapping message relating to that label carries the 390 FT Protection TLV. 392 If a label is an FT label, all LDP messages affecting that label MUST 393 carry the FT Protection TLV in order that the state of the label can 394 be recovered after a failure of the LDP session. 396 4.1.1.1 Scope of FT Labels 398 The scope of the FT/non-FT status of a label is limited to the 399 LDP message exchanges between a pair of LDP peers. 401 In Ordered Control, when the message is forwarded downstream or 402 upstream, the TLV may be present or absent according to the 403 requirements of the LSR sending the message. 405 4.1.2 FT Address Messages 407 If an LDP session uses the LDP FT enhancements, both LDP peers 408 MUST secure Address and Address Withdraw messages using FT Operation 409 ACKs, as described below. This avoids any ambiguity over whether 410 an Address is still valid after the LDP session is reconnected. 412 If an LSR determines that an Address message that it sent on a 413 previous instantiation of a recovered LDP session is no longer valid, 414 it MUST explicitly issue an Address Withdraw for that address when 415 the session is reconnected. 417 If the FT Reconnect Flag is not set by both LDP peers on reconnection 418 of an LDP session (i.e. state has not been preserved), both LDP 419 peers MUST consider all Addresses to have been withdrawn. The LDP 420 peers SHOULD issue new Address messages for all their valid addresses 421 as specified in [4]. 423 4.2 FT Operation ACKs 425 Handshaking of FT LDP messages is achieved by use of ACKs. 426 Correlation between the original message and the ACK is by means of 427 the FT Sequence Number contained in the FT Protection TLV, and passed 428 back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP 429 message that is sent on the TCP connection between LDP peers. 431 An LDP peer maintains a separate FT sequence number for each LDP 432 session it participates in. The FT Sequence number is incremented by 433 one for each FT LDP message (i.e. containing the FT Protection TLV) 434 issued by this LSR on the FT LDP session with which the FT sequence 435 number is associated. 437 When an LDP Peer receives a message containing the FT Protection TLV, 438 it MUST take steps to secure this message (or the state information 439 derived from processing the message). Once the message is secured, 440 it MUST be ACKed. However, there is no requirement on the LSR to 441 send this ACK immediately. 443 ACKs may be accumulated to reduce the message flow between LDP peers. 444 For example, if an LSR received FT LDP messages with sequence numbers 445 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK 446 receipt and securing of all these messages. 448 ACKs MUST NOT be sent out of sequence, as this is incompatible with 449 the use of accumulated ACKs . 451 4.3 Preservation of FT State 453 If the LDP FT enhancements are in use on an LDP session, each LDP 454 peer SHOULD NOT release the state information and resources 455 associated with FT labels exchanged on that LDP session when the TCP 456 connection fails. This is contrary to [2] and [4], but allows label 457 operations on FT labels to be completed after re-connection of the 458 TCP connection. 460 Both LDP peers on an LDP session that is using the LDP FT 461 enhancements SHOULD preserve the state information and resources they 462 hold for that LDP session as described below. 464 - An upstream LDP peer SHOULD release the resources (in 465 particular bandwidth) associated with an FT label when it 466 initiates a Label Release or Label Abort message for the label. 467 The upstream LDP peer MUST preserve state information for 468 the label, even if it releases the resources associated with the 469 label, as it may need to reissue the label operation if the 470 TCP connection is interrupted. 472 - An upstream LDP peer MUST release the state information 473 and resources associated with an FT label when it receives an 474 acknowledgement to a Label Release or Label Abort message that it 475 sent for the label, or when it sends a Label Release 476 message in response to a Label Withdraw message received from the 477 downstream LDP peer. 479 - A downstream LDP peer SHOULD NOT release the resources 480 associated with an FT label when it sends a Label Withdraw message 481 for the label as it has not yet received confirmation that the 482 upstream LDP peer has ceased to send data using the label. The 483 downstream LDP peer MUST NOT release the state information it 484 holds for the label as it may yet have to reissue the label 485 operation if the TCP connection is interrupted. 487 - A downstream LDP peer MUST release the resources and state 488 information associated with an FT label when it receives an 489 acknowledgement to a Label Withdraw message for the label. 491 - When the FT Reconnection Timeout expires, an LSR SHOULD release 492 all state information and resources from previous instantiations 493 of the (permanently) failed LDP session. 495 - When an LSR receives a Status TLV with the E-bit set in 496 the status code, which causes it to close the TCP connection, the 497 LSR MUST release all state information and resources associated 498 with the session. This behavior is mandated because it is 499 impossible for the LSR to predict the precise state and future 500 behavior of the partner LSR that set the E-bit without knowledge 501 of the implementation of that partner LSR. 503 Note that the "Temporary Shutdown" status code does not have the 504 E-bit set, and MAY be used during maintenance or upgrade 505 operations to indicate that the LSR intends to preserve state 506 across a closure and re-establishment of the TCP session. 508 - If an LSR determines that it must release state for any single FT 509 label during a failure of the TCP connection on which that label 510 was exchanged, it MUST release all state for all labels on the LDP 511 session. 513 The release of state information and resources associated with non-FT 514 labels is as described in [2] and [4]. 516 Note that a Label Release and the acknowledgemet to a Label Withdraw 517 may be received by a downstream LSR in any order. The downstream LSR 518 MAY release its resources on receipt of the first message and MUST 519 release its resources on receipt of the second message. 521 4.4 FT Procedure After TCP Failure 523 When an LSR discovers or is notified of a TCP connection failure it 524 SHOULD start an FT Reconnection Timer to allow a period for 525 re-connection of the TCP connection between the LDP peers. 527 Once the TCP connection between LDP peers has failed, the active LSR 528 SHOULD attempt to re-establish the TCP connection. The mechanisms, 529 timers and retry counts to re-establish the TCP connection are an 530 implementation choice. It is RECOMMENDED that any attempt to 531 re-establish the connection take account of the failover processing 532 necessary on the peer LSR, the nature of the network between the 533 LDP peers, and the FT Reconnection Timeout chosen on the previous 534 instantiation of the TCP connection (if any). 536 If the TCP connection cannot be re-established within the FT 537 Reconnection Timeout period, the LSR detecting this timeout SHOULD 538 release all state preserved for the failed LDP session. If the TCP 539 connection is subsequently re-established (for example, after a 540 further Hello exchange to set up a new LDP session), the LSR MUST set 541 the FT Reconnect Flag to 0 if it released the preserved state 542 information on this timeout event. 544 If the TCP connection is successfully re-established within the FT 545 Reconnection Timeout, both peers MUST re-issue LDP operations that 546 were interrupted by (that is, un-acknowledged as a result of) the TCP 547 connection failure. This procedure is described in section "FT 548 Procedure After TCP Re-connection". 550 The Hold Timer for an FT LDP Session SHOULD be ignored while the FT 551 Reconnection Timer is running. The hold timer SHOULD be restarted 552 when the TCP connection is re-established. 554 4.4.1 FT LDP Operations During TCP Failure 556 When the LDP FT enhancements are in use for an LDP session, it is 557 possible that an LSR may determine that it needs to send an LDP 558 message to an LDP peer but that the TCP connection to that peer is 559 currently down. These label operations affect the state of FT labels 560 preserved for the failed TCP connection, so it is important that the 561 state changes are passed to the LDP peer when the TCP connection is 562 restored. 564 If an LSR determines that it needs to issue a new FT LDP operation to 565 an LDP peer to which the TCP connection is currently failed, it MUST 566 pend the operation (e.g. on a queue) and complete that operation 567 with the LDP peer when the TCP connection is restored, unless the 568 label operation is overridden by a subsequent additional operation 569 during the TCP connection failure (see section "FT Procedure After 570 TCP Re-connection") 572 In ordered operation, received FT LDP operations that cannot be 573 correctly forwarded because of a TCP connection failure MAY be 574 processed immediately (provided sufficient state is kept to forward 575 the label operation) or pended for processing when the onward TCP 576 connection is restored and the operation can be correctly forwarded 577 upstream or downstream. Operations on existing FT labels SHOULD NOT 578 be failed during TCP session failure. 580 It is RECOMMENDED that Label Request operations for new FT labels are 581 not pended awaiting the re-establishment of TCP connection that is 582 awaiting recovery at the time the LSR determines that it needs to 583 issue the Label Request message. Instead, such Label Request 584 operations SHOULD be failed and, if necessary, a notification message 585 containing the "No LDP Connection" status code sent upstream. 587 Label Requests for new non-FT labels MUST be rejected during TCP 588 connection failure, as specified in [2] and [4]. 590 4.5 FT Procedure After TCP Re-connection 592 The FT operation handshaking described above means that all state 593 changes for FT labels and Address messages are confirmed or 594 reproducible at each LSR. 596 If the TCP connection between LDP peers fails but is re-connected 597 within the FT Reconnection Timeout, both LDP peers on the connection 598 MUST complete any label operations for FT labels that were 599 interrupted by the failure and re-connection of the TCP connection. 600 Label operation are completed using the procedure described below. 602 4.5.1 Re-Issuing FT Messages 604 On restoration of the TCP connection between LDP peers, any FT 605 LDP messages that were lost because of the TCP connection 606 failure are re-issued. The LDP peer that receives a re-issued message 607 processes the message as if received for the first time. 609 "Net-zero" combinations of messages need not be re-issued after 610 re-establishment of the TCP connection between LDP peers. This leads 611 to the following rules for re-issuing messages that are not ACKed by 612 the LDP peer on the LDP Initialization message exchange after 613 re-connection of the TCP session. 615 - A Label Request message MUST be re-issued unless a Label Abort 616 would be re-issued for the same Label Request or the Label Request 617 or if the requested label is no longer required. 619 - A Label Mapping message MUST be re-issued unless a Label Withdraw 620 message would be re-issued for the same FT label. 622 - All other messages on the LDP session that carried the FT 623 Protection TLV MUST be re-issued if an acknowledgement had not 624 previously been received. 626 Any FT label operations that were pended (see section "FT Label 627 Operations During TCP Failure") during the TCP connection failure 628 MUST also be issued on re-establishment of the LDP session, except 629 where they form part of a "net-zero" combination of messages 630 according to the above rules. 632 The determination of "net-zero" FT label operations according to the 633 above rules MAY be performed on pended messages prior to the 634 re-establishment of the TCP connection in order to optimize the use 635 of queue resources. Messages that were sent to the LDP peer before 636 the TCP connection failure, or pended messages that are paired with 637 them, MUST NOT be subject to such optimization until an FT ACK TLV is 638 received from the LDP peer. This ACK allows the LSR to identify 639 which messages were received by the LDP peer prior to the TCP 640 connection failure. 642 4.5.2 Interaction with CR-LDP LSP Modification 644 Re-issuing LDP messages for FT operation is orthogonal to the use of 645 duplicate messages marked with the Modify ActFlg, as specified in 646 [5]. Each time an LSR uses the modification procedure for an FT LSP 647 to issue a new Label Request message, the FT label operation 648 procedures MUST be separately applied to the new Label Request 649 message. 651 5. Changes to Existing Messages 653 5.1 LDP Initialization Message 655 The LDP FT enhancements add the following optional parameters to a 656 LDP Initialization message 658 Optional Parameter Length Value 660 FT Session TLV 4 See below 661 FT ACK TLV 4 See below 663 The encoding for these TLVs is found in Section "New Fields and 664 Values". 666 FT Session 667 If present, specifies the FT behavior of the LDP session. 669 FT ACK TLV 670 If present, specifies the last FT message that the sending LDP 671 peer was able to secure prior to the failure of the previous 672 instantiation of the LDP session. This TLV is only present if 673 the FT Reconnect flag is set in the FT Session TLV, in which 674 case this TLV MUST be present. 676 5.2 LDP Keepalive Messages 678 The LDP FT enhancements add the following optional parameter to a 679 LDP Keepalive message 681 Optional Parameter Length Value 683 FT ACK TLV 4 See below 685 The encoding for FT ACK TLV is found in Section "FT ACK TLV". 687 FT ACK TLV 688 If present, specifies the most recent FT message that the 689 sending LDP peer has been able to secure. 691 5.3 All Other LDP Session Messages 693 The LDP FT enhancements add the following optional parameters to all 694 other message types that flow on an LDP session after the LDP 695 Initialization message 697 Optional Parameter Length Value 699 FT Protection TLV 4 See below 700 FT ACK TLV 4 See below 702 The encoding for these TLVs is found in the section "New Fields and 703 Values". 705 FT Protection 706 If present, specifies FT Sequence Number for the LDP message. 708 FT ACK 709 If present, identifies the most recent FT LDP message 710 ACKed by the sending LDP peer. 712 6. New Fields and Values 714 6.1 Status Codes 716 The following new status codes are defined to indicate various 717 conditions specific to the LDP FT enhancements. These status codes 718 are carried in the Status TLV of a Notification message. 720 The "E" column is the required setting of the Status Code E-bit; the 721 "Status Data" column is the value of the 30-bit Status Data field in 722 the Status Code TLV. 724 Note that the setting of the Status Code F-bit is at the discretion 725 of the LSR originating the Status TLV. However, it is RECOMMENDED 726 that the F-bit is not set on Notification messages containing 727 status codes except "No LDP Session" because the duplication of 728 messages SHOULD be restricted to being a per-hop behavior. 730 Status Code E Status Data 732 No LDP Session 0 0x000000xx 733 Zero FT seqnum 1 0x000000xx 734 Unexpected TLV / 1 0x000000xx 735 Session Not FT 736 Unexpected TLV / 1 0x000000xx 737 Label Not FT 738 Missing FT Protection TLV 1 0x000000xx 739 FT ACK sequence error 1 0x000000xx 740 Temporary Shutdown 0 0x000000xx 741 FT Seq Numbers Exhausted 1 0x000000xx 743 The Temporary Shutdown status code SHOULD be used in place of 744 the Shutdown status code (which has the E-bit set) if the LSR that is 745 shutting down wishes to inform its LDP peer that it expects to be 746 able to preserve FT label state and to return to service before the 747 FT Reconnection Timer expires. 749 6.2 FT Session TLV 751 LDP peers can negotiate whether the LDP session between them supports 752 FT extensions by using a new OPTIONAL parameter, the FT Session 753 TLV, on LDP Initialization Messages. 755 The FT Session TLV is encoded as follows. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |1|0| FT Session TLV (0x0503) | Length (= 4) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | FT Flags | FT Reconnection Timeout | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 FT Flags 766 FT Flags: A 16 bit field that indicates various attributes the 767 FT support on this LDP session. This fields is formatted as 768 follows: 770 0 1 771 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 |R| Reserved | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 R: FT Reconnect Flag. 777 Set to 1 if the sending LSR has preserved state and 778 resources for all FT-labels since the previous LDP 779 session between the same LDP peers, and set to 0 780 otherwise. See the section "FT LDP Session 781 Reconnection" for details of how this flag is used. 783 If the FT Reconnect Flag is set, the sending LSR must 784 include an FT ACK TLV on the LDP Initialization message. 786 All other bits in this field are currently reserved and SHOULD 787 be set to zero on transmission and ignored on receipt. 789 FT Reconnection Timeout 790 The period of time the sending LSR will preserve state and 791 resources for FT labels exchanged on the previous instantiation of 792 an FT LDP session that has currently failed. The timeout is 793 encoded as a 16-bit unsigned integer number of seconds. 795 The value of 0 for this field is reserved and MUST NOT be used. 797 See the section "LDP Session Failure" for details of how this field 798 is used. 800 6.3 FT Protection TLV 802 LDP peers use the FT Protection TLV to indicate that an LDP message 803 contains an FT label operation. 805 The FT Protection TLV MUST NOT be used in messages flowing on an LDP 806 session that does not support the LDP FT enhancements. 808 The FT Protection TLV MAY be carried on an LDP message transported on 809 the LDP session after the initial exchange of LDP Initialization 810 messages. In particular, this TLV MAY optionally be present on the 811 following messages: 813 - Label Request Messages in downstream on-demand distribution mode 814 - Label Mapping messages in downstream unsolicited mode. 816 If a label is to be an FT label, then the Protection TLV MUST be 817 present: 818 - on the Label Request message in DoD mode 819 - on the Label Mapping message in DU mode 820 - on all subsequent messages concerning this label. 822 Here 'subsequent messages concerning this label' means any message 823 whose Label TLV specifies this label or whose Label Request Message 824 ID TLV specifies the initial Label Request message. 826 If a label is not to be an FT label, then the Protection TLV 827 MUST NOT be present on any of these messages. 829 The FT Protection TLV is encoded as follows. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |0|0| FT Protection (0x0203) | Length (= 4) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | FT Sequence Number | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 FT Sequence Number 839 The sequence number for this FT label operation. The 840 sequence number is encoded as a 32-bit unsigned integer. The 841 initial value for this field on a new LDP session is x00000001 and 842 is incremented by one for each FT LDP message issued by the sending 843 LSR on this LDP session. This field may wrap from xFFFFFFFF to 844 x00000000. 846 This field MUST be reset to x00000001 if either LDP peer does not 847 set the FT Reconnect Flag on re-establishment of the TCP 848 connection. 850 See the section "FT Operation Acks" for details of how this field 851 is used. 853 If an LSR receives an FT Protection TLV on a session that does not 854 support the FT LFP enhancements, it SHOULD send a Notification 855 message to its LDP peer containing the "Unexpected TLV, Session Not 856 FT" status code. 858 If an LSR receives an FT Protection TLV on an operation affecting a 859 label that it believes is a non-FT label, it SHOULD send a 860 Notification message to its LDP peer containing the "Unexpected TLV, 861 Label Not FT" status code. 863 If an LSR receives a message without the FT Protection TLV affecting 864 a label that it believes is an FT label, it SHOULD send a 865 Notification message to its LDP peer containing the "Missing FT 866 Protection TLV" status code. 868 If an LSR receives an FT Protection TLV containing a zero FT 869 Sequence Number, it SHOULD send a Notification message to its LDP 870 peer containing the "Zero FT Seqnum" status code. 872 6.4 FT ACK TLV 874 LDP peers use the FT ACK TLV to acknowledge FT 875 label operations. 877 The FT ACK TLV MUST NOT be used in messages flowing on an 878 LDP session that does not support the LDP FT enhancements. 880 The FT ACK TLV MAY be present on any LDP message exchanged on an 881 LDP session after the initial LDP Initialization messages. It is 882 RECOMMENDED that the FT ACK TLV is included on all FT 883 Keepalive messages in order to ensure that the LDP peers do not 884 build up a large backlog of unacknowledged state information. 886 The FT ACK TLV is encoded as follows. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |0|0| FT ACK (0x0504) | Length (= 4) | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | FT ACK Sequence Number | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 FT ACK Sequence Number 897 The sequence number for this most recent FT label message 898 that the sending LDP peer has received from the receiving LDP 899 peer and secured against failure of the LDP session. It is not 900 necessary for the sending peer to have fully processed the message 901 before ACKing it. For example, an LSR MAY ACK a Label Request 902 message as soon as it has securely recorded the message, without 903 waiting until it can send the Label Mapping message in response. 905 ACKs are cumulative. Receipt of an LDP message containing an FT 906 ACK TLV with an FT ACK Sequence Number of 12 is treated as the 907 acknowledgement of all messages from 1 to 12 inclusive (assuming 908 the LDP session started with a sequence number of 1). 910 This field MUST be set to 0 if the LSR sending the FT ACK TLV has 911 not received any FT label operations on this LDP session. This 912 would apply to LDP sessions to new LDP peers or after an LSR 913 determines that it must drop all state for a failed TCP connection. 915 See the section "FT Operation Acks" for details of how this field 916 is used. 918 If an LSR receives a message affecting a label that it believes is an 919 FT label and that message does not contain the FT Protection TLV, it 920 SHOULD send a Notification message to its LDP peer containing the 921 "Missing FT Protection TLV" status code. 923 If an LSR receives an FT ACK TLV that contains an FT ACK Sequence 924 Number that is less than the previously received FT ACK Sequence 925 Number (remembering to take account of wrapping), it SHOULD send a 926 Notification message to its LDP peer containing the "FT ACK 927 Sequence Error" status code. 929 7. Example Use 931 Consider two LDP peers, P1 and P2, implementing LDP over a TCP 932 connection that connects them, and the message flow shown below. 934 The parameters shown on each message shown below are as follows: 936 message (label, senders FT sequence #, FT ACK #) 937 A "-" for FT ACK # means that the FT ACK TLV is not included on 938 that message. "n/a" means that the parameter in question is not 939 applicable to that type of message. 941 In the diagram below, time flows from top to bottom. The relative 942 position of each message shows when it is transmitted. See the notes 943 for a description of when each message is received, secured for FT or 944 processed. 946 notes P1 P2 947 ===== == == 948 (1) Label Request(L1,27,-) 949 ---------------------------> 950 Label Request(L2,28,-) 951 ---------------------------> 952 (2) Label Request(L3,93,27) 953 <--------------------------- 954 (3) Label Request(L1,123,-) 955 --------------------------> 956 Label Request(L2,124,-) 957 --------------------------> 958 (4) Label Mapping(L1,57,-) 959 <-------------------------- 960 Label Mapping(L1,94,28) 961 <--------------------------- 962 (5) Label Mapping(L2,58,-) 963 <-------------------------- 964 Label Mapping(L2,95,-) 965 <--------------------------- 966 (6) Address(n/a,29,-) 967 ---------------------------> 968 (7) Label Request(L4,30,-) 969 ---------------------------> 970 (8) Keepalive(n/a,na/,94) 971 ---------------------------> 972 (9) Label Abort(L3,96,-) 973 <--------------------------- 974 (10) ===== TCP Session lost ===== 976 (11) Label Withdraw(L1,59,-) 977 <-------------------------- 979 (12) === TCP Session restored === 981 LDP Init(n/a,n/a,95) 982 ---------------------------> 983 LDP Init(n/a,n/a,29) 984 <--------------------------- 985 (13) Label Request(L4,30,-) 986 ---------------------------> 987 (14) Label Mapping(L2,95,-) 988 <--------------------------- 989 Label Abort(L3,96,30) 990 <--------------------------- 991 (15) Label Withdraw(L1,97,-) 992 <--------------------------- 994 Notes: 995 ====== 997 (1) Assume that the LDP session has already been initialized. 998 P1 issues 2 new Label Requests using the next sequence numbers. 1000 (2) P2 issues a third Label request to P1. At the time of sending 1001 this request, P2 has secured the receipt of the label request 1002 for L1 from P1, so it includes an ACK for that message. 1004 (3) P2 Processes the Label Requests for L1 and L2 and forwards them 1005 downstream. Details of downstream processing are not shown in 1006 the diagram above. 1008 (4) P2 receives a Label Mapping from downstream for L1, which it 1009 forwards to P1. It includes an ACK to the Label Request for L2, 1010 as that message has now been secured and processed. 1012 (5) P2 receives the Label Mapping for L2, which it forwards to P1. 1013 This time it does not include an ACK as it has not received any 1014 further messages from P1. 1016 (6) Meanwhile, P1 sends a new Address Message to P2 . 1018 (7) P1 also sends a fourth Label Request to P2 1020 (8) P1 sends a Keepalive message to P2, on which it includes an ACK 1021 for the Label Mapping for L1, which is the latest message P1 has 1022 received and secured at the time the Keepalive is sent. 1024 (9) P2 issues a Label Abort for L3. 1026 (10) At this point, the TCP session goes down. 1028 (11) While the TCP session is down, P2 receives a Label Withdraw 1029 Message for L1, which it queues. 1031 (12) The TCP session is reconnected and P1 and P2 exchange LDP 1032 Initialization messages on the recovered session, which include 1033 ACKS for the last message each peer received and secured prior 1034 to the failure. 1036 (13) From the LDP Init exchange, P1 determines that it needs to 1037 re-issue the Label request for L4. 1039 (14) Similarly, P2 determines that it needs to re-issue the Label 1040 Mapping for L2 and the Label Abort. 1042 (15) P2 issues the queued Label Withdraw to P1. 1044 8. Security Considerations 1046 The LDP FT enhancements inherit similar security considerations to 1047 those discussed in [2] and [4]. 1049 The LDP FT enhancements allow the re-establishment of a TCP 1050 connection between LDP peers without a full re-exchange of the 1051 attributes of established labels, which renders LSRs that implement 1052 the extensions specified in this draft vulnerable to additional 1053 denial-of-service attacks as follows: 1055 - An intruder may impersonate an LDP peer in order to force a 1056 failure and reconnection of the TCP connection, but where the 1057 intruder does not set the FT Reconnect Flag on re-connection. 1058 This forces all FT labels to be released. 1060 - Similarly, an intruder could set the FT Reconnect Flag on 1061 re-establishment of the TCP session without preserving the state 1062 and resources for FT labels. 1064 - An intruder could intercept the traffic between LDP peers and 1065 override the setting of the FT Label Flag to be set to 0 for 1066 all labels. 1068 All of these attacks may be countered by use of an authentication 1069 scheme between LDP peers, such as the MD5-based scheme outlined in 1070 [4]. 1072 Alternative authentication schemes for LDP peers are outside the 1073 scope of this draft, but could be deployed to provide enhanced 1074 security to implementations of LDP, CR-LDP and the LDP FT 1075 enhancements. 1077 9. Implementation Notes 1079 9.1 FT Recovery Support on Non-FT LSRs 1081 In order to take full advantage of the FT capabilities of LSRs in the 1082 network, it may be that an LSR that does not itself contain the 1083 ability to recover from local hardware or software faults still needs 1084 to support the LDP FT enhancements described in this draft. 1086 Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant 1087 LSR, P2. If P2 experiences a fault in the hardware or software that 1088 serves an LDP session between P1 and P2, it may fail the TCP 1089 connection between the peers. When the connection is recovered, the 1090 LSPs/labels between P1 and P2 can only be recovered if both LSRs were 1091 applying the FT recovery procedures to the LDP session. 1093 9.2 ACK generation logic 1095 FT ACKs SHOULD be returned to the sending LSR as soon as is 1096 practicable in order to avoid building up a large quantity of 1097 unacknowledged state changes at the LSR. However, immediate 1098 one-for-one acknowledgements would waste bandwidth unnecessarily. 1100 A possible implementation strategy for sending ACKs to FT LDP 1101 messages is as follows: 1102 - An LSR secures received messages in order and tracks the sequence 1103 number of the most recently secured message, Sr. 1104 - On each LDP KeepAlive that the LSR sends, it attaches an FT ACK 1105 TLV listing Sr 1106 - Optionally, the LSR may attach an FT ACK TLV to any other LDP 1107 message sent between Keepalive messages if, for example, Sr has 1108 increased by more than a threshold value since the last ACK sent. 1110 This implementation combines the bandwidth benefits of accumulating 1111 ACKs while still providing timely ACKs. 1113 10. Acknowledgments 1115 The work in this draft is based on the LDP and CR-LDP ideas 1116 expressed by the authors of [2] and [4]. 1118 The ACK scheme used in this draft was inspired by the proposal by 1119 David Ward and John Scudder for restarting BGP sessions [9]. 1121 The authors would also like to acknowledge the careful review and 1122 comments of Nick Weeds, Piers Finlayson, Tim Harrison and Duncan 1123 Archer at Data Connection Ltd, Peter Ashwood-Smith of Nortel and 1124 Bon Thomas of Cisco. 1126 11. Intellectual Property Consideration 1128 The IETF has been notified of intellectual property rights claimed in 1129 regard to some or all of the specification contained in this 1130 document. For more information, consult the online list of claimed 1131 rights. 1133 12. Full Copyright Statement 1135 Copyright (c) The Internet Society (2000). All Rights Reserved. This 1136 document and translations of it may be copied and furnished to 1137 others, and derivative works that comment on or otherwise explain it 1138 or assist in its implementation may be prepared, copied, published 1139 and distributed, in whole or in part, without restriction of any 1140 kind, provided that the above copyright notice and this paragraph 1141 are included on all such copies and derivative works. However, this 1142 document itself may not be modified in any way, such as by removing 1143 the copyright notice or references to the Internet Society or other 1144 Internet organizations, except as needed for the purpose of 1145 developing Internet standards in which case the procedures for 1146 copyrights defined in the Internet Standards process must be 1147 followed, or as required to translate it into languages other than 1148 English. 1150 The limited permissions granted above are perpetual and will not be 1151 revoked by the Internet Society or its successors or assigns. 1153 This document and the information contained herein is provided on an 1154 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1155 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1156 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1157 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1158 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1160 13. IANA Considerations 1162 This draft requires the use of a number of new TLVs and status codes 1163 from the number spaces within the LDP protocol. This section 1164 explains the logic used by the authors to choose the most appropriate 1165 number space for each new entity, and is intended to assist in the 1166 determination of any final values assigned by IANA or the MPLS WG in 1167 the event that the MPLS WG chooses to advance this draft on the 1168 standards track. 1170 This section will be removed when the TLV and status code values have 1171 been agreed with IANA. 1173 13.1 FT Session TLV 1175 The FT Session TLV carries attributes that affect the entire LDP 1176 session between LDP peers. It is suggested that the type for this 1177 TLV should be chosen from the 0x05xx range for TLVs that is used in 1178 [4] by other TLVs carrying session-wide attributes. At the time of 1179 this writing, the next available number in this range is 0x0503. 1181 13.2 FT Protection TLV 1183 The FT Protection TLV carries attributes that affect a single label 1184 exchanged between LDP peers. It is suggested that the type for this 1185 TLV should be chosen from the 0x02xx range for TLVs that is used in 1186 [4] by other TLVs carrying label attributes. At the time of this 1187 writing, the next available number in this range is 0x0203. 1189 Consideration was given to using the message number field instead of 1190 a new FT Sequence Number field. However, the authors felt this 1191 placed unacceptable implementation constraints on the use of message 1192 number (e.g. it could no longer be used to reference a control 1193 block). 1195 13.3 FT ACK TLV 1197 The FT Protection TLV may ACK many label operations at once 1198 if cumulative ACKS are used. It is suggested that the type for this 1199 TLV should be chosen from the 0x05xx range for TLVs that is used in 1200 [4] by other TLVs carrying session-wide attributes. At the time of 1201 this writing, the next available number in this range is 0x0504. 1203 Consideration was given to carrying the FT ACK Number in the FT 1204 Protection TLV, but the authors felt this would be inappropriate as 1205 many implementations may wish to carry the ACKs on Keepalive 1206 messages. 1208 13.4 Status Codes 1210 The authors' current understanding is that MPLS status codes are not 1211 sub-divided into specific ranges for different types of error. 1212 Hence, the numeric status code values assigned for this draft should 1213 simply be the next available values at the time of writing and may be 1214 substituted for other numeric values. 1216 See section "Status Codes" for details of the status codes defined in 1217 this draft. 1219 14. Authors' Addresses 1221 Adrian Farrel (editor) Paul Brittain 1222 Data Connection Ltd. Data Connection Ltd. 1223 Windsor House Windsor House 1224 Pepper Street Pepper Street 1225 Chester Chester 1226 Cheshire Cheshire 1227 CH1 1DF CH1 1DF 1228 UK UK 1229 Phone: +44-(0)-1244-313440 Phone: +44-(0)-1244-313440 1230 Fax: +44-(0)-1244-312422 Fax: +44-(0)-1244-312422 1231 Email: af@dataconnection.com Email: pjb@dataconnection.com 1233 Philip Matthews Eric Gray 1234 Nortel Networks Corp. Zaffire, Inc. 1235 P.O. Box 3511 Station C, 2630 Orchard Parkway, 1236 Ottawa, ON K1Y 4H7 San Jose, CA - 95134-2020 1237 Canada Phone: (408) 894-7362 1238 Phone: +1 613-768-3262 egray@zaffire.com 1239 philipma@nortelnetworks.com 1241 15. References 1243 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1244 9, RFC 2026, October 1996. 1246 2 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 1247 draft-ietf-mpls-cr-ldp-04.txt, July 2000, (work in progress). 1249 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1250 Levels", BCP 14, RFC 2119, March 1997. 1252 4 Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp- 1253 11.txt, August 2000 (work in progress). 1255 5 Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls- 1256 crlsp-modify-01.txt, February 2000 (work in progress). 1258 6 Braden, R., et al., Resource ReSerVation Protocol (RSVP) -- 1259 Version 1, Functional Specification, RFC 2205, September 1997. 1261 7 Berger, L., et al., RSVP Refresh Reduction Extensions, draft- 1262 ietf-rsvp-refresh-reduct-05.txt, June 2000 (work in progress). 1264 8 Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft- 1265 ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000 (work in progress). 1267 9 Ward, D, et al., BGP Notification Cease: I'll Be Back, 1268 draft-ward-bgp4-ibb-00.txt, June 1999 (work in progress) 1270 10 Stewart, R, et al., Simple Control Transmission Protocol, 1271 draft-ietf-sigtran-sctp-07.txt, March 2000 (work in progress)