idnits 2.17.1 draft-galtzur-l2tpext-gr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 446. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 161 has weird spacing: '...lso one new...' == Line 266 has weird spacing: '...essions trans...' == Line 286 has weird spacing: '...lue and the R...' == Line 333 has weird spacing: '.... This will ...' -- 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 2004) is 7123 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 20 looks like a reference -- Missing reference section? '2' on line 82 looks like a reference -- Missing reference section? '4' on line 112 looks like a reference -- Missing reference section? '3' on line 424 looks like a reference -- Missing reference section? '6' on line 114 looks like a reference -- Missing reference section? '7' on line 116 looks like a reference -- Missing reference section? 'SCCRQ' on line 164 looks like a reference -- Missing reference section? 'SCCRP' on line 164 looks like a reference -- Missing reference section? 'IETF' on line 212 looks like a reference -- Missing reference section? 'TBD' on line 214 looks like a reference -- Missing reference section? 'ICRQ' on line 203 looks like a reference -- Missing reference section? 'OCRQ' on line 203 looks like a reference -- Missing reference section? 'ICRP' on line 203 looks like a reference -- Missing reference section? 'OCRP' on line 203 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft S. Galtzur 3 Document: draft-galtzur-l2tpext-gr-02.txt Axerra Networks 5 Expires: April 2005 October 2004 7 Layer Two Tunneling Protocol (Version 3) Graceful Restart 9 draft-galtzur-l2tpext-gr-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [1]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes a mechanism that helps to minimize the 39 negative effects on L2TP traffic caused by L2TP Control Connection 40 Endpoint (LCCE) control plane restart, specifically by the restart of 41 its control protocol component, on LCCEs that are capable of 42 preserving the L2TP forwarding component ( a.k.a. the L2TP data 43 plane) across the restart. 45 Graceful Restart Mechanism for L2TP (v3) October 2004 47 The mechanism described in this document is applicable to all LCCEs, 48 both those with the ability to preserve Forwarding State during the 49 control plane (CP) restart and those without (although the latter 50 needs to implement only a subset of the mechanism described in this 51 document). 52 Supporting (a subset of) the mechanism described here by the LCCEs 53 that can not preserve their L2TP Forwarding State across the restart 54 would not reduce the negative impact on L2TP traffic caused by their 55 control plane restart, but it would minimize the impact on the L2TP 56 traffic if their peer(s) are capable of preserving the Forwarding 57 State across the restart of their control plane and implement the 58 mechanism described here. 60 The mechanism makes minimalistic assumptions on what has to be 61 preserved across restart - the mechanism assumes that only the actual 62 L2TP Forwarding State has to be preserved; the mechanism does not 63 require any of the control plane related states to be preserved 64 across the restart. 66 Conventions used in this document 68 For the sake of brevity in the context of this document, by "the 69 control plane" we mean "the L2TP component of the control plane". The 70 L2TP control plane includes all the information associated with the 71 L2TP Control Connection and the low-order reliable delivery protocol. 73 For the sake of brevity in the context of this document, by "L2TP 74 Forwarding State" we mean the dynamic information that is exchanged 75 between two LCCEs peers during the establishment of L2TP tunnels and 76 sessions, i.e. local and remote Session IDs and local and remote 77 cookies. The Forwarding State of an L2TP session also includes its 78 association with the specific end service or application. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC2119 [2]. 83 Table of Contents 85 1. Motivation.....................................................3 86 2. Changes from the Previous Version..............................4 87 3. L2TP Extension.................................................4 88 3.1 Graceful Restart AVP [SCCRQ, SCCRP]........................4 89 3.2 Graceful Restart Session AVP [ICRQ, OCRQ, ICRP, OCRP]......5 90 3.3 Stale state in the Session state machine...................5 91 3.4 A New Error Code value.....................................5 92 4. Operation......................................................6 93 4.1 Procedure for restarting LCCE..............................6 94 4.2 Restart of L2TP communication with a peer LCCE.............6 96 Graceful Restart Mechanism for L2TP (v3) October 2004 98 4.3 Accepting request to start Control Connection before 99 disconnect detection...........................................7 100 4.4 Recovering stale Sessions..................................8 101 4.5 Partial Graceful Restart...................................9 102 4.6 Multiple Control Connections between a pair of LCCEs.......9 103 5. Security Considerations........................................9 104 6. IANA Considerations............................................9 105 References.......................................................10 106 Acknowledgments..................................................10 107 Authors� Addresses...............................................11 109 1. Motivation 111 The mechanism presented in this document extends the ideas first 112 explored in [4] for LDP graceful restart to L2TPv3. L2TPv3 [3] is the 113 protocol of choice for setup, teardown and maintenance of pseudo- 114 wires over an IP PSN (see [6]) just as LDP is the protocol of choice 115 for setup, teardown and maintenance of pseudo-wires over an MPLS PSN 116 [7], with the PWE3 Provider Edge (PE) devices acting also as L2TPv3 117 Control Connection Endpoints (LCCEs). 119 In the case where a LCCE could preserve its L2TP Forwarding State 120 across restart of its control plane, it is desirable not to perturb 121 the L2TP Session IDs going through that LCCE. In this document, we 122 describe a mechanism, termed "L2TP Graceful Restart", that allows the 123 accomplishment of this goal. 125 The mechanism described in this document is applicable to all LCCEs, 126 both those with the ability to preserve Forwarding State during 127 control plane restart and those without (although the latter need to 128 implement only a subset of the mechanism described in this document). 129 Supporting (a subset of) the mechanism described here by the LCCEs 130 that can not preserve their L2TP Forwarding State across the restart 131 would not reduce the negative impact on L2TP traffic caused by their 132 control plane restart, but it would minimize the impact if their 133 peer(s) are capable of preserving the Forwarding State across the 134 restart of their control plane and implement the mechanism described 135 here. 137 The mechanism makes minimalistic assumptions on what has to be 138 preserved across restart - the mechanism assumes that only the actual 139 L2TP Forwarding State has to be preserved. Clearly this is the 140 minimum amount of state that has to be preserved across the restart 141 in order not to perturb the L2TP Session IDs terminating in a 142 restarting LCCE. The mechanism does not require any of the L2TP- 143 related states to be preserved across the restart. 145 Graceful Restart Mechanism for L2TP (v3) October 2004 147 2. Changes from the Previous Version 149 1. Processing of non-established sessions by the peer of the 150 restarting LCCE has been clarified. 152 2. The list of control messages that can use the Session Graceful 153 Restart AVP has been updated. 155 3. Lack of additional security risks of the Graceful Restart 156 mechanism has been explained. 158 3. L2TP Extension 160 There is one new AVP for the Control Connection Messages and one new 161 AVP for the Session Connection Messages. There is also one new 162 state in the Session state machine and one new Error Code value. 164 3.1 Graceful Restart AVP [SCCRQ, SCCRP] 166 An LCCE that supports (fully or partially) L2TP Graceful Restart as 167 defined in this document MUST include the Graceful Restart (GR) AVP 168 in the SCCRQ and SCCRP messages. 170 0 1 2 3 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |M|H| rsvd | Length | Vendor Id [IETF] | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Attribute Type [TBD] | Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | GR Reconnect Timeout (in milliseconds) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Recovery Time (in milliseconds) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 183 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 184 16. 186 The GR Reconnect Timeout is the time (in milliseconds) the initiating 187 LCCE asks its peer to wait after the next detection of communication 188 failure for a Graceful Restart Reconnection. Value of zero indicates 189 that the LCCE does not preserve its L2TP Forwarding State across the 190 restart of the L2TP control plane, so that the peer should not wait 191 for a graceful restart of this LCCE. 193 The Recovery Time is the time (in milliseconds) the initiating LCCE 194 asks its peer to wait after the establishment of this control 195 connection for recovery of the Sessions that belong to this Control 197 Graceful Restart Mechanism for L2TP (v3) October 2004 199 Connection. Value of zero indicates that the sending LCCE was not 200 able to preserve the Forwarding State and restart as described in [3] 201 should be used. 203 3.2 Graceful Restart Session AVP [ICRQ, OCRQ, ICRP, OCRP] 205 An LCCE that tries to open a session for which the L2TP Forwarding 206 State has been preserved, MUST include the Graceful Restart Session 207 AVP when trying to reopen the Session gracefully. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |M|H| rsvd | Length | Vendor Id [IETF] | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Attribute Type [TBD] | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 When this AVP is present in an ICRQ/OCRQ/ICRP/OCRP message the value 218 of the Remote Session ID in the Remote Session ID AVP MUST be set to 219 the preserved value of the Remote Session ID. 221 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 222 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6. 224 3.3 Stale state in the Session state machine 226 A Session enters the stale state if it has been in the established 227 state and its associated Control Connection enters the Graceful 228 Restart procedure as described in the following section. Forwarding 229 of L2TP data packets for a Session in this state remains unperturbed. 231 A Session transits from the stale state to either the established 232 state or the idle state as described in the following section. 234 3.4 A New Error Code value 236 One new Error Code value - Session Graceful Restart Mismatch (actual 237 value to be assigned by IANA) will be used in the CDN messages with 238 the Result Code 2 (Session disconnected for the reason indicated in 239 Error Code) as defined in [3] in the following situations: 241 o Attempt to re-establish a non-stale session with a Session 242 initiation request that contains the Session Graceful Restart AVP 244 o Attempt to re-establish a stale session with a Session initiation 245 request that does not contains the Session Graceful Restart AVP. 246 4. Operation 248 Graceful Restart Mechanism for L2TP (v3) October 2004 250 An LCCE that support the Graceful Restart, as defined in this 251 document, advertises it by including the GR AVP in the SCCRQ or SCCRP 252 Messages. If one of the peers does not include this AVP both LCCEs 253 MUST follow the Control Connection initiation procedure as described 254 in [3]. 256 4.1 Procedure for restarting LCCE 258 After an LCCE restarts its control plane, it MUST check whether it 259 was able to preserve its L2TP Forwarding State across the restart. 260 If not, then the LCCE sets the Recovery Time to 0 in the GR AVP it 261 sends to its peer when the Control Connection is re-established. 262 If the L2TP Forwarding State has been preserved, the LCCE starts its 263 internal timer, called L2TP Forwarding State Holding timer (the value 264 of that timer SHOULD be configurable and MUST NOT be greater then the 265 GR Reconnect Timeout sent on the previous GR AVP), and all the 266 established L2TP Sessions transit to the stale state. 268 Note: all the sessions that are not in the established state MUST 269 transit to the idle state since they will never be recovered by the 270 Graceful Restart mechanism. 272 While this procedure is performed the LCCE MUST ignore any incoming 273 SCCRQ messages for the Control Connections being recovered. At the 274 expiration of the timer, all the entries still in the stale state 275 MUST transit to the idle state (see [3] for state machine details). 276 The value of the Recovery Time advertised in the GR AVP is set to the 277 (current) value of the timer at the point in which the Initiation 278 message carrying the GR AVP is sent. 280 We say that an LCCE is in the process of restarting when the L2TP 281 Forwarding State Holding timer has not expired. Once the timer 282 expires, we say that the LCCE has completed its restart. 284 When the LCCE receives the GR AVP from its peer it MUST set its L2TP 285 Forwarding State Holding timer to the smaller value of the its own 286 current value and the Recovery Time as advertised by the peer. 288 4.2 Restart of L2TP communication with a peer LCCE 290 When an LCCE detect that its L2TP Control Connection with its peer 291 LCCE went down, and the LCCE knows that the peer is capable of 292 preserving its L2TP Forwarding State across the restart (as was 293 indicated by the presence of GR AVP with non-zero Reconnect Time in 294 the last Control Connection initiation message from this peer), the 295 LCCE retains the remote information for the sessions associated with 296 this Control Connection (rather than discarding the information), but 297 all these sessions transit to the stale state. The LCCE SHOULD start 299 Graceful Restart Mechanism for L2TP (v3) October 2004 301 its reconnecting procedures immediately. Failure to reconnect MUST 302 NOT cause termination of the Graceful Restart procedure. 304 The amount of time the LCCE keeps its stale sessions remote 305 information is set to the lesser of the GR Reconnect Timeout, as was 306 advertised by the peer, and a local timer, called the Peer Liveness 307 Timer. If within that time the LCCE still does not establish an L2TP 308 Control Connection with its peer, the remote information of all the 309 stale sessions MUST be deleted and these sessions MUST transit to the 310 idle state. The Peer Liveness Timer is started when the LCCE detects 311 that its L2TP Control Connection with the peer went down. The value 312 of the Peer Liveness timer SHOULD be configurable. 314 If the LCCE re-establishes a L2TP Control Connection with its peer 315 within the lesser of the GR Reconnect Timeout and the Peer Liveness 316 Timer, and the LCCE determines (by receiving Recovery Time equal to 317 zero) that the peer was not able to preserve its L2TP forwarding 318 state, the remote information for all the stale sessions MUST be 319 immediately deleted and all these sessions MUST transit to the idle 320 state. If the LCCE determines that the peer was able to preserve its 321 L2TP forwarding state (as was indicated by the non-zero Recovery Time 322 sent by the peer), the LCCE SHOULD further keep the stale sessions, 323 received from the peer, for as long as the lesser of the Recovery 324 Time advertised by the peer, and a local configurable value, called 325 Maximum Recovery Time, allows. This value is the one set in the 326 Recovery Time sent to the peer when re-establishing the Control 327 Connection. 329 4.3 Accepting request to start Control Connection before disconnect 330 detection 332 An LCCE may fully restart before its Peer LCCE detects the failure of 333 the Control Connection. This will cause the Peer LCCE to receive a 334 SCCRQ for a Control Connection that is still in the established 335 state. (Handling of multiple Control Connections between a pair of 336 LCCEs is discussed later.) If the SCCRQ contains the Graceful Restart 337 AVP the LCCE SHOULD continue operation as described above. If the 338 SCCRQ does not contain the Graceful Restart AVP it should handle the 339 SCCRQ like described in [3] and tear down the control connection and 340 all the associated sessions. 342 4.4 Recovering stale Sessions 344 After the re-establishment of Control Connection both LCCEs have 345 marked session in stale state. From this point on re-establishment 346 of Sessions is symmetric. For the Sessions in the stale state (stale 347 Sessions) reconnection is similar to the normal way with the 348 following difference: 350 Graceful Restart Mechanism for L2TP (v3) October 2004 352 When an LCCE sends OCRQ or ICRQ for a stale Session it MUST add the 353 Graceful Restart Session AVP, MUST send the preserved value of Local 354 Session ID in the Local Session ID AVP and MUST supply the preserved 355 Remote Session ID in the Remote Session ID AVP. If the preserved 356 Forwarding State included a cookie, its preserved value MUST be sent 357 in the Assigned Cookie AVP instead of using a new random value. When 358 an LCCE sends OCRQ or ICRQ for a non-stale session it MUST NOT add 359 the Graceful Restart Session AVP and MUST follow the normal 360 procedures for the values of Local Session ID, Remote Session ID and 361 the cookie. 363 When an LCCE receives OCRQ or ICRQ with the Graceful Restart Session 364 AVP it will search for the corresponding Session according to the 365 value in the Remote Session ID AVP. If this value is found, the 366 Session is in stale state and the Local Session ID value also matches 367 then the Session is associated with the new control connection, 368 transits to the established state and the preserved the Local session 369 ID, Remote Session ID and the cookie are included in the 370 corresponding AVPs. If the Session was not in the stale state or 371 there was a mismatch in the Local Session ID value or the cookie 372 value, the LCCE MUST tear down the Session with the CDN Message using 373 the Result Code 2 and the Session Graceful Restart Mismatch Error 374 Code, delete the Session remote information and put the Session in 375 the idle state. The LCCE MAY compare other AVP values that arrive 376 with the OCRQ or ICRQ to validate the Graceful Restart of the 377 Session. 379 When LCCE receives OCRQ or ICRQ without the Graceful Restart Session 380 AVP it will treat it as described in [3] unless the Session is in the 381 stale state. In that case the LCCE MUST tear down the session with 382 CDN Message using the Result Code 2 and the Session Graceful Restart 383 Mismatch Error Code, delete the Session remote information and 384 transit to the idle state. 386 4.5 Partial Graceful Restart 388 An LCCE MAY support partial Graceful Restart. By this we mean that 389 it cannot preserve its own state across its own restart but it can 390 preserve it across its peer restart. An LCCE that supports partial 391 Graceful Restart indicates it by including the GR AVP with Reconnect 392 Time set to zero. 394 4.6 Multiple Control Connections between a pair of LCCEs 396 L2TP supports multiple Control Connections between a given pair of 397 LCCEs (identified by their respective Router IDs). It is up to the 398 LCCEs to be able to associate the correct end points of each Control 399 Connection. This can be done according to different criteria such as 400 Application ID AVP, Capability List AVP etc. E.g., the LCCE MAY 402 Graceful Restart Mechanism for L2TP (v3) October 2004 404 decide that it does not allow more than one Control Connection to its 405 peer with the same Application ID and an overlap in the Capabilities' 406 list. The same criteria MUST be applied when restarting the Control 407 Connection. The LCCE MUST NOT use the Control Connection ID to 408 identify the Control Connection across restart. 410 5. Security Considerations 412 The mechanism described in this document does not add any new 413 security considerations for L2TPv3. In particular: 415 o All the checks required during a regular restart are performed 416 between the restarting LCCE and its peer in the case of Graceful 417 Restart 419 o It is impossible to change any of the L2TPv3 forwarding state 420 including source and destination IP address, Session ID and cookie 421 values etc. 423 The security considerations pertaining to the original L2TP protocol 424 [3] remain relevant. 426 6. IANA Considerations 428 This document requires assignment of the following numbers by IANA: 430 o Two new AVP types (see Sections 2.1 and 2.2 above) 432 o One new Error Code value (see Section 2.4 above). 434 Copyright notice 436 Copyright (C) The Internet Society (2004). This document is subject 437 to the rights, licenses and restrictions contained in BCP 78, and 438 except as set forth therein, the authors retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 Graceful Restart Mechanism for L2TP (v3) October 2004 450 References 452 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 453 9, RFC 2026, October 1996. 455 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", BCP 14, RFC 2119, March 1997 458 3 J. Lau, M. Townsley, I. Goyret , �Layer Two Tunneling Protocol 459 (Version 3)�, Work in Progress, draft-ietf-l2tpext-l2tp-base- 460 14.txt, June 2004. 462 4 Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful Restart 463 Mechanism for Label Distribution Protocol", RFC 3478, February 464 2003. 466 5 Farrel, A., "Fault Tolerance for the Label Distribution Protocol 467 (LDP)", RFC 3479, February 2003. 469 6 S. Bryant, P. Pate, PWE3 Architecture, Work in Progress, draft- 470 ietf-pwe3-arch-07.txt, March 2003 472 7 L. Martini et al, Pseudowire Setup and Maintenance Using LDP, Work 473 in progress, draft-ietf-pwe3-control-protocol-11.txt, October 2004 475 Acknowledgments 477 I would like to thank Sam Henderson and Sasha Vainshtein for their 478 constructive comments on this memo. I would like to also thank Gonen 479 Zilber for participating in the writing of the first draft of this 480 memo. 482 Authors� Addresses 484 Sharon Galtzur 485 Axerra Networks 486 24 Raoul Wallenberg 487 Tel Aviv, Israel 488 Email: Sharon@Axerra.com