idnits 2.17.1 draft-ietf-mpls-ldp-dod-restart-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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC3036], [RFC3478]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '... its control plane, the LSR MUST check...' RFC 2119 keyword, line 209: '...ue of that timer SHOULD be configurabl...' RFC 2119 keyword, line 211: '...ill marked as stale SHOULD be deleted....' RFC 2119 keyword, line 459: '...hbor, all the stale bindings SHOULD be...' RFC 2119 keyword, line 462: '...r Liveness timer SHOULD be configurabl...' (2 more instances...) 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 2003) is 7741 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: 'LDP' is mentioned on line 113, but not defined == Missing Reference: 'RFC3-36' is mentioned on line 179, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-03 == Outdated reference: A later version (-05) exists of draft-ietf-isis-restart-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-restart (ref. 'ISIS-RESTART') == Outdated reference: A later version (-08) exists of draft-ietf-ospf-hitless-restart-01 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Thomas 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: August 2003 4 Alex Raj 5 Cisco Systems, Inc. 7 February 2003 9 LDP DoD Graceful Restart 11 draft-ietf-mpls-ldp-dod-restart-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 LDP graceful restart is a mechanism that helps reduce the negative 37 effects on MPLS traffic caused by the restart of a Label Switching 38 Router's (LSR's) control plane, specifically by the restart of its 39 Label Distribution Protocol (LDP) component [RFC3036], on LSRs that 40 are capable of preserving MPLS forwarding state across the restart. 41 [RFC3478] defines procedures for LDP graceful restart for downstream 42 unsolicited label distribution but leaves procedures for downstream 43 on demand label distribution a subject for future study. This 44 document defines graceful restart procedures for downstream on demand 45 label distribution. 47 1. Introduction 49 LDP graceful restart is a mechanism that helps reduce the negative 50 effects on MPLS traffic caused by the restart of a Label Switching 51 Router's (LSR's) control plane, specifically by the restart of its 52 Label Distribution Protocol (LDP) component [RFC3036], on LSRs that 53 are capable of preserving MPLS forwarding state across the restart. 55 [RFC3478] defines procedures for LDP graceful restart for downstream 56 unsolicited label distribution but leaves procedures for downstream 57 on demand label distribution a subject for future study. This 58 document defines graceful restart procedures for downstream on demand 59 label distribution. 61 This document uses terminology introduced in [RFC3478] and, where 62 appropriate, uses procedures specified in [RFC3478]. In addition, in 63 places it borrows text from [RFC3478], indicating when it does so. 65 As in [RFC3478], for the sake of brevity: 67 - The phrase "the control plane" means the "the LDP component of the 68 control plane". 70 - The phrase "MPLS forwarding state (for an LSP)" or simply 71 "forwarding state (for an LSP)" means the mapping: 73 < FEC -> push outgoing_label, nexthop > 74 at an LSP ingress LSR, or 76 < incoming_label -> swap outgoing_label, nexthop > 77 at an LSP transit LSR, or 79 < incoming_label -> pop, nexthop > 80 at an LSP transit LSR, with penultimate hop popping or 81 at an LSP egress 83 The incoming_label in the forwarding state for an LSP may be a 84 platform-wide label or an interface-specific label. Similarly, the 85 outgoing_label learned from the nexthop may be a platform-wide label 86 or an interface-specific label. For the procedures below that search 87 MPLS forwarding state for an entry with a given incoming or outgoing 88 label when the search key is an interface-specific label the match 89 criteria includes an interface match. The procedures below also 90 search MPLS forwarding state for an LSP or LSPs which match a given 91 nexthop. Determining that a given LDP peer is an LSP nexthop may 92 require comparing the nexthop with addresses advertised in Address 93 messages from the peer. 95 For the sake of brevity, the phrase "LDP state (for an LSP)" means 96 the mapping: 98 < FEC -> { outgoing_label, nexthop, nexthop neighbor LDP ID } > 99 at an LSP ingress LSR, or 101 < FEC -> { incoming_label, upstream neighbor LDP ID }, 102 { outgoing_label, nexthop, nexthop neighbor LDP ID } > 103 at an LSP transit LSR, or 105 < FEC -> { incoming_label, upstream neighbor LDP ID } > 106 at an LSP egress LSR 108 The text in [RFC3478] applies here and is repeated verbatim for the 109 reader's convenience. 111 "In the case where a Label Switching Router (LSR) could preserve 112 its MPLS forwarding state across restart of its control plane, 113 specifically its LDP component [LDP], it is desirable not to 114 perturb the LSPs going through that LSR (specifically, the LSPs 115 established by LDP). In this document, we describe a mechanism, 116 termed "LDP Graceful Restart", that allows the accomplishment of 117 this goal". 119 This document extends the mechanisms defined in [RFC3478] to enable 120 an LSR using LDP downstream on demand label distribution to 121 accomplish the goal as well. 123 Continuing with the text from [RFC3478]: 125 "The mechanism described ... is applicable to all LSRs, both those 126 with the ability to preserve forwarding state during LDP restart 127 and those without (although the latter need to implement only a 128 subset of the mechanism described ...). Supporting (a subset of) 129 the mechanism described here by the LSRs that can not preserve 130 their MPLS forwarding state across the restart would not reduce the 131 negative impact on MPLS traffic caused by their control plane 132 restart, but it would minimize the impact if their neighbor(s) are 133 capable of preserving the forwarding state across the restart of 134 their control plane and implement the mechanism described here." 136 In specifying procedures this document distinguishes between: 138 - A "restarting LSR" which is one which has lost its LDP state but 139 has retained its forwarding state; and 141 - A "neighbor LSR" which is one which has retained its LDP state and 142 its forwarding state but has lost its LDP session with another LSR. 144 The goal of the mechanisms specified in [RFC3478] and this document 145 is to enable uninterrupted forwarding across a control plane restart. 146 The graceful restart mechanisms enable a restarting LSR to validate 147 its forwarding state and recover its LDP state and a neighbor LSR to 148 to validate its LDP state. 150 2. LDP Extensions 152 [RFC3478] specifies use of the Fault Tolerant (FT) Session TLV [LDP- 153 FT] in the LDP Initialization message. The specified use of the FT 154 Session TLV as described in [RFC3478] applies to the extensions for 155 downstream on demand graceful restart as well. 157 This document modifies the procedures for Label Request, Label 158 Mapping and Label Abort messages as follows for LSRs using graceful 159 restart for downstream on demand label distribution. 161 - An LSR may include a Label TLV (more specifically, a Generic 162 Label, ATM Label or Frame Relay Label TLV, as appropriate) in a 163 Label Request message to suggest the label a downstream neighbor 164 should use in its Label Mapping message response. 166 - If an LSR receives a Label Request message for which it has stale 167 LDP state it may use the message to validate the state and it may 168 reply with a Label Mapping message. Normal [RFC3036] procedure 169 is to consider such a (redundant) Label Request as a protocol 170 error and to ignore it. 172 - If an LSR which is not restarting receives a Label Mapping 173 message for which it has no LDP state it responds with a Label 174 Release message. 176 - If an LSR receives a Label Abort message which doesn't match a 177 previously received Label Request message it replies with a 178 Notification message with Label Request Aborted status code. 179 Normal [RFC3-36] procedure is to ignore such a Label Abort. 181 3. Operations 183 The text in [RFC3478] applies here and is repeated verbatim for the 184 reader's convenience. 186 "An LSR that supports functionality described in this document 187 advertises this to its LDP neighbors by carrying the FT Session TLV 188 in the LDP Initialization message. 190 "This document assumes that in certain situations, as specified in 191 section "[Restarting] Egress LSR", in addition to the MPLS 192 forwarding state, an LSR can also preserve its IP forwarding state 193 across the restart. Procedures for preserving IP forwarding state 194 across the restart are defined in [OSPF-RESTART], [ISIS-RESTART], 195 and [BGP-RESTART]." 197 3.1. Procedures for restarting LSR 199 The text in [RFC3478] applies here and is repeated verbatim for the 200 reader's convenience. 202 "After an LSR restarts its control plane, the LSR MUST check 203 whether it was able to preserve its MPLS forwarding state from 204 prior to the restart. If not, then the LSR sets the Recovery Time 205 to 0 in the FT Session TLV the LSR sends to its neighbors. 207 "If the forwarding state has been preserved, then the LSR starts 208 its internal timer, called MPLS Forwarding State Holding timer (the 209 value of that timer SHOULD be configurable), and marks all the MPLS 210 forwarding state entries as "stale". At the expiration of the 211 timer, all the entries still marked as stale SHOULD be deleted. 212 The value of the Recovery Time advertised in the FT Session TLV is 213 set to the (current) value of the timer at the point in which the 214 Initialization message carrying the FT Session TLV is sent. 216 "We say that an LSR is in the process of restarting when the MPLS 217 Forwarding State Holding timer is not expired. Once the timer 218 expires, we say that the LSR completed its restart." 220 The following procedures apply when an LSR using downstream on demand 221 label distribution is in the process of restarting. The graceful 222 restart procedures for downstream unsolicited described in [RFC3478] 223 distinquish between the behavior of (LSP) egress and non-egress LSRs. 224 The procedures for downstream on demand described here distinguish 225 between the behavior of (LSP) ingress, transit and egress LSRs. 227 In some situations described below a restarting LSR creates LDP state 228 which it marks as stale until it can be fully validated. When the 229 Forwarding State Holding timer expires the restarting LSR should 230 delete all LDP state marked as stale. 232 3.1.1. Restarting Ingress LSR 234 Reference diagram: 236 LSP --> 237 R ------ N --- ... 239 On receipt of a Label Mapping message from LSR N: 241 LabelMap(FEC, LabelTLV(outgoing_label)) 243 LSR R searches its forwarding state for an LSP for FEC with the 244 specified outgoing_label and nexthop N: 246 < FEC -> push outgoing_label, nexthop > or 247 < FEC -> pop, nexthop > 249 where an outgoing_label of Implicit Null matches a pop entry. If R 250 finds no such forwarding state it is not an ingress for the FEC. 252 If R finds finds the forwarding state it creates LDP state for the 253 FEC: 255 < FEC, { outgoing_label, nexthop, nexthop neighbor LDP ID } > 257 and marks it stale. Next it sends a Label Request message to N with 258 a Label TLV suggesting outgoing_label: 260 LabelReq(MsgId_R, FEC, LabelTLV(outgoing_label)) 262 On receipt of a matching Label Mapping message from N: 264 LabelMap(FEC, MsgIdTLV(MsgId_R), LabelTLV(neighbor_label)) 266 R updates its LDP state for the LSP and clears the stale mark: 268 < FEC, { neighbor_label, nexthop, nexthop neighbor LDP ID } > 270 If the received neighbor_label matches outgoing_label in the 271 forwarding state R clears the stale mark from the LSP forwarding 272 state. Otherwise, R replaces the LSP forwarding state, as 273 appropriate, with: 275 < FEC -> push neighbor_label, nexthop > or 276 < FEC -> pop, nexthop > 278 If R's Forwarding State Holding timer expires before it receives the 279 reply to its Label Request message it deletes its forwarding state 280 for the LSP as per [RFC3478], clears the stale mark from its LDP 281 state for the LSP, sends a Label Abort message to N, and follows the 282 [RFC3036] procedures for Label Abort. 284 3.1.2. Restarting Egress LSR 286 Reference diagram: 288 LSP --> 289 --- N ------ R 291 On receipt of a Label Request message from neighbor LSR N for a FEC 292 for which restarting LSR R is an egress and which includes a 293 suggested label: 295 LabelReq(MsgId_N, FEC, LabelTLV(incoming_label)) 297 LSR R checks whether the suggested label is compatible with its 298 configuration for generating labels for the FEC. (An LSR may be 299 configured to use a non-Null label, Explicit Null or Implicit Null 300 for a FEC for which it is an egress.) If the suggested label is not 301 compatible, R behaves as if the message had no Label TLV and treats 302 it as specifed by [RFC3036]. 304 If the suggested label is compatible with its configuration R 305 attempts to locate forwarding state for the LSP using the suggested 306 incoming_label. If incoming_label is non-Null R searches its MPLS 307 forwarding state for an entry: 309 < incoming_label -> pop, nexthop > 311 and if incoming_label is either Explicit or Implicit Null R searches 312 its IP forwarding state for an entry for the FEC. 314 If R cannot locate forwarding state corresponding to the Label 315 Request message, it behaves as if the message had no Label TLV and 316 treats it as specified by [RFC3036]. 318 If R succeeds in locating forwarding state for the FEC it: 320 1. Updates its LDP state for the LSP: 322 < FEC, { incoming_label, upstream neighbor LDP ID } > 324 2. Clears the stale mark from the LSP forwarding state if 325 incoming_label is non-NULL; 327 3. Replies to N with a Label Mapping message: 329 LabelMap(FEC, MSGIdTLV(MsgId_N), LabelTLV(incoming_label) 331 3.1.3. Restarting Transit LSR 333 Reference diagram: 335 --- LSP --> 336 ... --- Nu ------ R ------ Nd --- ... 338 Restarting LSR R must complete graceful restart procedures with 339 upstream neighbor LSR Nu and downstream neighbor LSR Nd to recover a 340 transit LSP. The order in which the procedures with Nu and Nd begin 341 depends upon when the respective LDP sessions are established and the 342 first LDP messages for the LSP are received by R. 344 The procedure with Nu begins with the receipt of a Label Request 345 message with a suggested incoming_label from Nu: 347 LabelReq(MsgId_Nu, FEC, LabelTLV(incoming_label)) 349 LSR R attempts to locate forwarding state for the LSP using the 350 suggested incoming_label: 352 < incoming_label -> swap outgoing_label, nexthop >, or 353 < incoming_label -> pop, nexthop > 355 If R cannot locate forwarding state corresponding to the Label 356 Request message, it behaves as if the message had no Label TLV and 357 treats it as specified by [RFC3036]. 359 If R succeeds in locating the forwarding state it updates its LDP 360 state for the LSP to include incoming_label and marks it stale: 362 < FEC, { incoming_label, neighbor Nu LDP ID } > 364 At this point R's interaction with Nu for the LSP is said to be in 365 the "waiting for downstream" state and its interaction with Nu must 366 wait until it has a session with Nd and it completes the following 367 procedure for clearing the stale mark on the LSP LDP state. 369 The procedure with nexthop LSR Nd begins with the receipt of a Label 370 Mapping from Nd for the LSP: 372 LabelMap(FEC, LabelTLV(outgoing_label)) 374 When it receives the message R searches its forwarding state for an 375 LSR with the specified outgoing_label and nexthop Nd: 377 < incoming_label -> swap outgoing_label, nexthop >, or 378 < incoming_label -> pop, nexthop > 380 If R cannot locate forwarding state corresponding to the Label 381 Mapping it ignores the message. 383 If R succeeds in locating the forwarding state it updates its LDP 384 state for the LSP to include: 386 < FEC, { outgoing_label, neighbor Nd LDP ID } > 388 and marks it stale. 390 At this point R's interaction with Nd must wait until it has a 391 session with Nu and the interaction with Nu for the LSP is in the 392 "waiting for downstream" state. 394 When the interaction with Nu is in "waiting for downstream" state R 395 sends Nd a Label Request message with a Label TLV suggesting 396 outgoing_label: 398 LabelReq(MsgId_R, FEC, LabelTLV(outgoing_label)) 400 On receipt of a Label Mapping message from Nd: 402 LabelMap(FEC, MsgIdTLV(MsgId_R), LabelTLV(neighbor_label)) 404 that matches the Label Request message R: 406 1. Checks if neighbor_label matches the outgoing_label in the LSP 407 forwarding state. If so, it clears the stale mark from the 408 forwarding state. Otherwise, it replaces the forwarding state, 409 as appropriate, with: 411 < incoming_label -> swap neighbor_label, nexthop >, or 412 < incoming_label -> pop, nexthop > 414 2. Updates its LDP state for the LSP and clears the stale mark: 416 < FEC, { incoming_label, neighbor Nu LDP ID } > 417 { neighbor_label, nexthop, neighbor Nd LDP ID } ] 419 At this point R may complete its interaction with Nu for the LSP by 420 replying to Nu's Label Request message with a Label Mapping message: 422 LabelMap(FEC, MsgIdTLV(MsgId_Nu), LabelTLV(incoming_label)) 424 If R's Forwarding State Holding timer expires before it receives the 425 reply from Nd to its Label Request message it deletes its forwarding 426 state for the LSP as per [RFC3478], sends a Label Abort message to 427 Nd, and deletes its LDP state for the LSP. 429 3.2. Restart of LDP communication with neighbor LSR 431 An LSP is said to be "fully established from the point of view of an 432 LSR" if the LSR has installed forwarding state for the LSP. 434 When an LSR detects that an LDP downstream on demand session with a 435 neighbor capable of preserving MPLS forwarding state across the 436 restart has gone down, the LSR handles the LDP state learned by the 437 session as follows: 439 - It marks the LDP state for LSPs that are fully established from its 440 point of view as "stale"; 442 - It handles the LDP state for LSPs not fully established as if the 443 neighbor was incapable of preserving MPLS forwarding state across 444 the restart; that is, it follows [RFC3036] procedures for session 445 loss for these LSPs. 447 The text in [RFC3478] regarding neighbor LSR behavior when an LDP 448 session with a neighbor is lost and later re-established applies here 449 and is repeated verbatim for the reader's convenience. 451 "After detecting that the LDP session with the neighbor went down, 452 the LSR tries to re-establish LDP communication with the neighbor 453 following the usual LDP procedures. 455 "The amount of time the LSR keeps its stale label-FEC bindings is 456 set to the lesser of the FT Reconnect Timeout, as was advertised by 457 the neighbor, and a local timer, called the Neighbor Liveness 458 Timer. If within that time the LSR still does not establish an LDP 459 session with the neighbor, all the stale bindings SHOULD be 460 deleted. The Neighbor Liveness Timer is started when the LSR 461 detects that its LDP session with the neighbor went down. The 462 value of the Neighbor Liveness timer SHOULD be configurable. 464 "If the LSR re-establishes an LDP session with the neighbor within 465 the lesser of the FT Reconnect Timeout and the Neighbor Liveness 466 Timer, and the LSR determines that the neighbor was not able to 467 preserve its MPLS forwarding state, the LSR SHOULD immediately 468 delete all the stale label-FEC bindings received from that 469 neighbor. If the LSR determines that the neighbor was able to 470 preserve its MPLS forwarding state (as was indicated by the non- 471 zero Recovery Time advertised by the neighbor), the LSR SHOULD 472 further keep the stale label-FEC bindings, received from the 473 neighbor, for as long as the lesser of the Recovery Time advertised 474 by the neighbor, and a local configurable value, called Maximum 475 Recovery Time, allows." 477 When the LSR determines that the neighbor has preserved its MPLS 478 forwarding state it starts an internal timer called the LDP Recovery 479 timer. 481 Other than to specify the procedure when the Neighbor Liveness Timer 482 expires [RFC3478] need not address LSR behavior following session 483 loss prior to re-establishment. The procedures for downstream on 484 demand specify neighbor LSR behavior for individual LSPs during this 485 period as well as following session re-establishment. 487 3.2.1. Neighbor Ingress LSR 489 Reference Diagram: 491 LSP --> 492 N ------ P --- ... 494 Prior to session re-establishment if the nexthop for an LSP FEC 495 changes from peer LSR P LSR N clears the stale mark from the LSP LDP 496 state and follows the [RFC3036] procedures for a nexthop change with 497 the following difference. Where the procedures require N to send a 498 Label Release message to Pd N omits the message. 500 Following session establishment with downstream peer LSR P, neighbor 501 LSR N scans its LDP state for LSPs for which it is the ingress LSR 502 and which use P as nexthop: 504 < FEC, { outgoing_label, nexthop, nexthop neighbor LDP ID } > 506 For each such LSP N sends P a Label Request message with a Label TLV 507 suggesting outgoing_label: 509 LabelReq(MsgId_N, FEC, LabelTLV(outgoing label)) 511 On receipt of a matching Label Mapping message from P: 513 LabelMap(FEC, MsgIdTLV(MsgId_N), LabelTLV(neighbor_label)) 515 N updates its LDP state for the LSP and clears the stale mark: 517 < FEC, { neighbor_label, nexthop, nexthop neighbor LDP ID } > 519 If the received neighbor_label matches outgoing_label in the LSP 520 forwarding state N takes no further action; otherwise, it replaces 521 the LSP forwarding state, as appropriate, with: 523 < FEC -> push neighbor_label, nexthop > or 524 < FEC -> pop, nexthop > 526 If N's LDP Recovery timer expires before it receives the reply to its 527 Label Request message it deletes its forwarding state for the LSP, 528 removes the outgoing_label from the LDP state for the LSP, clears the 529 stale mark from the LDP state, sends a Label Abort message to P, and 530 follows the [RFC3036] procedures for Label Abort. 532 3.2.2. Neighbor Egress LSR 534 Reference Diagram: 536 LSP --> 537 ... --- P ------ N 539 Prior to session re-establishment if the nexthop for the LSP FEC 540 (i.e., the FEC route) is lost N follows the [RFC3036] procedures for 541 a change in FEC nexthop with the following difference. Where the 542 procedures require N send a Label Withdraw message to upstream peer 543 LSR Pu it omits the message and behaves as if it had sent the message 544 and Pu had replied with a Label Release message. 546 Following session establishment with upstream LSR P neighbor LSR N 547 scans its LDP state for LSPs for which it is an egress and P is the 548 previous hop: 550 [ FEC, { incoming label, upstream neighbor LDP ID } ] 552 For each such LSP it sends a Label Mapping to P: 554 LabelMap(FEC, LabelTLV(incoming label) 556 On receipt of a Label Request message with a suggested label from P: 558 LabelReq(MsgId_P, FEC, LabelTLV(incoming_label); 560 neighbor LSR N attempts to locate LDP state using the FEC and 561 suggested incoming_label: 563 If N cannot locate the LDP state message, it behaves as if the 564 message had no Label TLV and treats it as specified by [RFC3036]. 566 If N succeeds in locating the LDP state, it clears the stale mark 567 from the LDP state and replies to P with a Label Mapping message: 569 LabelMap(FEC, MsgIdTLV(MsgId_P), LabelTLV(incoming label) 571 If N's LDP Recovery timer expires before it receives a Label Request 572 message from P for the LSP it deletes its LDP state for the LSP and 573 any MPLS forwarding state for the LSP. 575 3.2.3. Neighbor Transit LSR 577 There are 3 cases for a neighbor LSR acting as a transit LSR. 579 Case 1: LDP session with upstream peer LSR Pu is lost and recovered: 581 Reference Diagram: 583 -- LSP --> 584 ... --- Pu ------ N --- ... 586 Prior to session re-establishment the following could occur for an 587 LSP for which upstream LSR Pu is the previous hop: 589 - N receives a Label Withdraw message from the LSP nexthop LSR 590 (Pd). In this case N follows the procedures specified in 591 [RFC3036] for receipt of a Label Withdraw with the following 592 differences. Regardless of the control method used to 593 establish the LSP N behaves as if it had used ordered control. 594 Where the procedures require N send a Label Withdraw message to 595 upstream peer LSR Pu it omits the message and behaves as if it 596 had sent the message and Pu had replied with a Label Release 597 message. 599 - The nexthop for the LSP FEC changes. In this case N follows 600 the [RFC3036] procedures for a change in FEC nexthop with the 601 following difference. Where the procedures require N send a 602 Label Withdraw message to upstream peer LSR Pu it omits the 603 message and behaves as if it had sent the message and Pu had 604 replied with a Label Release message. 606 Following session establishment with upstream peer LSR Pu neighbor 607 LSR N scans its LDP state for LSPs for which LSR Pu is the previous 608 hop. For each such LSP N behaves as described in section "Neighbor 609 Egress LSR" with the following difference. 611 If N's LDP Recovery timer expires before it receives a Label 612 Request message from Pu for the LSP it clears the stale mark from 613 its LDP state for the LSP and behaves as if it had received a Label 614 Release message from Pu and follows the [RFC3036] Label Release 615 procedures. 617 Case 2: LDP session with downstream peer LR Pd is lost and recovered: 619 Reference Diagram: 621 --- LSP --> 622 ... --- N ------ Pd --- ... 624 Prior to session re-establishment the following could occur for an 625 LSP for which downstream LSR Pd is the nexthop: 627 - The LSP previous hop LSR (Pu) releases its label for the LSP. 628 In this case neighbor LSR N follows the [RFC3036] procedures 629 for Label Release with the following difference. Where the 630 procedures require N to send a Label Release message to Pd N 631 omits the message. 633 - The nexthop for an LSP FEC changes. In this case N clears the 634 stale mark from the LSP LDP state and follows the [RFC3036] 635 procedures for a nexthop change with the following difference. 636 Where the procedures require N to send a Label Release message 637 to Pd N omits the message. 639 Following session establishment with downstream peer LSR Pd, 640 neighbor LSR N scans its LDP state for LSPs for which Pd is 641 nexthop. For each such LSP N behaves as described in section 642 "Neighbor Ingress LSR" with the following difference. 644 If N's LDP Recovery timer expires before it receives the reply to 645 its Label Request message it behaves as follows: 647 1. It deletes its forwarding state for the LSP and clears the 648 stale mark from its LDP state for the LSP. 650 2. It sends a Label Abort message to Pd and follows the [RFC3036] 651 procedures for Label Abort. 653 3. With respect to its upstream neighbors it behaves as if it had 654 received a Label Withdraw message from Pd and sends Label 655 Withdraws to some or all of its upstream neighbors as 656 specified by [RFC3036]. 658 Case 3: LDP sessions with upstream peer LSR Pu and downstream peer 659 LSR Pd are lost and recovered. 661 Reference Diagram: 663 ---> LSP --> 664 ... --- Pu ------ N ------ Pd --- ... 666 Neighbor LSR N must complete graceful restart procedures with 667 upstream peer LSR Pu and downstream peer LSR Pd to recover a 668 transit LSP. The order in which the procedures with Pu and Pd 669 begin depends upon when the respective LDP sessions are established 670 and the first LDP messages for the LSP are received by N. 672 Prior to session re-establishment with Pd if the nexthop for an LSP 673 FEC changes from downstream peer LSR Pd, neighbor LSR N follows the 674 [RFC3036] procedures for a change in FEC nexthop with the following 675 differences. If the session with Pu has not been re-established 676 where the [RFC3036] procedures require N send a Label Withdraw 677 message to upstream peer LSR Pu N omits the message and behaves as 678 if it had sent the message and Pu had replied with a Label Release 679 message; and, where the procedures require N to send a Label 680 Release message to Pd N omits the message. 682 Following session establishment with upstream LSR Pu neighbor LSR N 683 scans its LDP state for LSPs for which Pu is the previous hop: 685 < FEC, { incoming label, upstream neighbor LDP ID } > 687 For each such LSP it sends a Label Mapping to Pu: 689 LabelMap(FEC, LabelTLV(incoming label) 691 On receipt of a Label Request message with a suggested label from 692 Pu: 694 LabelReq(MsgId_Pu, FEC, LabelTLV(incoming_label); 696 N attempts to locate LDP state using the FEC and suggested 697 incoming_label: 699 If N cannot locate the LDP state message, it behaves as if the 700 message had no Label TLV and treats it as specified by [RFC3036]. 702 If N succeeds in locating the LDP state its interaction with Pu for 703 the LSP is said to be in the "waiting for downstream" state and its 704 interaction with Pu for the LSP must wait until it has a session 705 with Pd and it completes the following procedure for clearing the 706 stale mark on the LSP LDP state. 708 Following session establishment with downstream peer LSR Pd, 709 neighbor LSR N scans its LDP state for LSPs which use Pd as 710 nexthop: 712 < FEC, { ... } > 713 { outgoing_label, nexthop, nexthop neighbor LDP ID } > 715 Each such LSP the interaction with Pd is considered to be in 716 "waiting for upstream" state. At this point for a given LSP N must 717 wait until the interaction with Pu is in "waiting for downstream" 718 state. 720 When the interaction with Pu is in "waiting for downstream" state 721 and the interaction with Pd is in "waiting for upstream" state N 722 sends Pd a Label Request message with a Label TLV suggesting 723 outgoing_label: 725 LabelReq(MsgId_N, FEC, LabelTLV(outgoing label)) 727 On receipt of a Label Mapping message from Pd: 729 LabelMap(FEC, MsgIdTLV(MsgId_N), LabelTLV(neighbor_label)) 731 that matches the Label Request message N: 733 1. Checks if the received neighbor_label from Pd matches the 734 outgoing_label in the LSP forwarding state. If not N replaces 735 the LSP forwarding state with: 737 neighbor_label, nexthop> 739 2. Updates its LDP state for the LSP and clears the stale mark: 741 < FEC, { neighbor_label, nexthop, nexthop Pd LDP ID } > 743 At this point, N may complete its interaction with Nu for the LSP 744 by replying to Pu's Label Request message with a Label Mapping 745 message: 747 LabelMap(FEC, MsgIdTLV(MsgId_Pu), LabelTLV(incoming label) 749 If N's LDP Recovery timer expires before it receives the reply from 750 Pd to its Label Request message it deletes its forwarding state for 751 the LSP as per [RFC3478], sends a Label Abort message to Pd, and 752 deletes its LDP state for the LSP. 754 3.3. Non-Merging LSRs 756 The forwarding state for a given FEC with N LSPs on a non-merging 757 restarting LSR is: 759 [ incoming_label_1 -> swap outgoing_label_1, nexthop ] 760 [ incoming_label_2 -> swap outgoing_label_2, nexthop ] 761 ... 762 [ incoming_label_N -> swap outgoing_label_N, nexthop ] 764 In some situations it may be important for a restarting transit LSR 765 to preserve the existing LSPs for a given FEC; that is, to ensure 766 that following completion of graceful restart each incoming label is 767 (re)connected to the same outgoing label for each LSP. 769 The procedures described in section "Restarting Transit LSR" ensure 770 that the LSR recovers each LSP for the FEC correctly. Label Request 771 messages from the upstream neighbor LSR identify the FEC LSPs by 772 incoming_label. This enables the LSR to determine the corresponding 773 outgoing_label for the LSP from the forwarding state. Similarly 774 Label Mapping messages from the downstream neighbor LSR identify the 775 FEC LSPs by outgoing_label. This enables the LSR to determining the 776 incoming_label for the LSP from the forwarding state. 778 3.4. Mixed DU / DoD operation 780 An LSR may use downstream unsolicited label distribution with some 781 neighbors and downstream on demand with others. A situation of 782 interest is where a restarting Transit LSR uses different methods 783 with its upstream and downstream neighbors for a given LSP. 785 The discussion below assumes all labels are Generic Labels. In 786 situations where the label types are different (e.g., the downstream 787 on demand session distributes ATM Labels and the downstream 788 unsolicited session distributes Generic Labels) the forwarding state 789 and the way LSR R manages it are implementation dependent and are 790 likely to be be different in detail, but are similar in kind, to 791 situations where all labels are Generic. 793 For this situation the LSP LDP state to be recovered is: 795 < FEC, { incoming_label, neighbor Nu LDP ID } > 796 { outgoing_label, nexthop, neighbor Nd LDP ID } > 798 and the LSP forwarding state to be validated is: 800 < incoming_label -> outgoing_label, nexthop >, or 801 < incoming_label -> pop, nexthop > 803 To fully recover the LSP R must establish sessions with Nu and Nd and 804 complete restart procedures with each. In general R will not know 805 until a session is established whether it is downstream on demand or 806 downstream unsolicited. 808 There are two cases to consider: 810 Case 1: Upstream session is downstream on demand; 811 downstream session is downstream unsolicited. 813 --- LSP --> 814 ... --- Nu ------ R ------ Nd --- ... 815 DoD DU 817 The graceful restart procedures for restarting LSR R's session with 818 Nu are those described above in section "Restarting Egress LSR" 819 without the configuration check. Successful completion of the 820 procedures with Nu results in the recovery of part of the LSP LDP 821 state: 823 < FEC, { incoming_label, upstream neighbor LDP ID } > 825 and validation of the incoming_label part of the forwarding state. 827 Completion of the [RFC3478] procedures with Nd results in recovery 828 of part of the LDP state for the LSP: 830 < FEC, { incoming_label }, 831 { outgoing_label, downstream neighbor LDP ID } > 833 and full validation of the LSP LDP state. 835 Case 2: Upstream session is downstream unsolicited; 836 downstream session is downstream on demand. 838 --- LSP --> 839 ... --- Nu ------ R ------ Nd --- ... 840 DU DoD 842 Following establishment of its session with DU upstream neighbor 843 Nu, restarting LSR R considers all LSPs that transit Nu-R-Nd (which 844 it has yet to identify from it preserved forwarding state and 845 interactions with Nd) to be in "waiting for downstream" state, and 846 it follows the [RFC3478] procedures for its session with Nu. 848 After establishment of R's session with DoD downstream neighbor Nd, 849 on reciept of a Label Mapping message from Nd: 851 LabelMap(FEC, LabelTLV(outgoing_label)) 853 LSR R searches its forwarding state for an LSR with the specified 854 outgoing_label and nexthop Nd: 856 < incoming_label -> swap outgoing_label, nexthop >, or 857 < incoming_label -> pop, nexthop > 859 If R cannot locate forwarding state corresponding to the Label 860 Mapping it ignores the message. If R succeeds in locating the 861 forwarding state it updates its LDP state for the LSP to include: 863 < FEC, { incoming_label, ... }, 864 { outgoing_label, neighbor Nd LDP ID } > 866 At this point R's interaction with Nd must wait until it has a 867 session with Nu and the interaction with Nu for the LSP is in the 868 "waiting for downstream" state. 870 When the interaction with Nu for the LSP is in "waiting for 871 downstream" state R: 873 1. Sends Nd a Label Request message with a Label TLV suggesting 874 outgoing_label: 876 LabelReq(MsgId_R, FEC, LabelTLV(outgoing_label)) 878 2. On receipt of a Label Mapping message from Nd: 880 LabelMap(FEC, MsgIdTLV(MsgId_R), LabelTLV(neighbor_label)) 882 that matches the Label Request message R sends Nu a Label 883 Mapping message: 885 LabelMap(FEC, LabelTLV(incoming_label)) 887 3. Clears the stale mark from the LSP forwarding state. 889 3.5. LSP attributes and loop detection 891 [RFC3036] procedures for handling Hop Count and Path Vector TLVs in 892 Label Mapping and Label Request messages apply following LDP session 893 re-establishment during the period while Forwarding State and LDP 894 Recovery timers are running. This includes the procedures for the 895 optional loop detection mechanism specified for use with downstrean 896 on demand label distribution. 898 4. Security Considerations 900 This document introduces no security issues beyond those previously 901 identified by [RFC3036] and [RFC3478]. 903 5. Acknowledgements 905 The authors would like to thank Bin Mo, Bibhuti Kar, Iftekhar 906 Hussain, Richard Lam and Bob Fish for their input. 908 6. References 910 [BGP-RESTART] "Graceful Restart Mechanism for BGP", draft-ietf-idr- 911 restart-03.txt, work in progress. 913 [ISIS-RESTART] "Restart signaling for ISIS", draft-ietf-isis- 914 restart-01.txt, work in progress. 916 [LDP-FT] Farrell A., et al, "Fault Tolerance for the Label 917 Distribution Protocol (LDP)", draft-ietf-mpls-ldp-ft- 918 06.txt, September 2002, work in progress. 920 [OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless- 921 restart-01.txt, work in progress. 923 [RFC3036] Andersson, L., et al, "LDP Specification, RFC3036", 924 January 2001. 926 [RFC3478] Leelanivas, M., et al, "Graceful Restart Mechanism for 927 LDP", draft-ietf-mpls-ldp-restart-06.txt, October 928 2002, work in progress. 930 7. Authors' Addresses 932 Alex Raj Bob Thomas 933 Cisco Systems, Inc Cisco Systems, Inc. 934 300 Apollo Dr. 300 Apollo Dr. 935 Chelmsford, MA 01824 Chelmsford, MA 01824 936 email: araj@cisco.com email: rhthomas@cisco.com