idnits 2.17.1 draft-ietf-l2tpext-failover-12.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([L2TPv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When an endpoint receives an FSQ message, it MUST ensure that for each FSS AVP in FSQ message it includes an FSS AVP in Failover Session Response (FSR) message. An endpoint could respond to multiple FSQs using one FSR message, or it could respond one FSQ with multiple FSRs. FSSs aren't required to be responded in the same order in which they were received. For each FSS AVP received in FSQ, an endpoint MUST validate the Remote Session Id and determine if it is paired with the Session Id specified in the message. If FSS AVP is not valid (i.e. session is non-existing or it is paired with different remote session id), then the Session Id field in the FSS AVP in the FSR MUST be set to zero. When session is discovered to be pairing with mismatching session id, the local session MUST not be cleared, but rather marked stale, to be queried later using an FSQ message. Appendix C presents an example dialogue between two endpoints on mismatching session ids. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This AVP MUST not be hidden (the H-bit is set to 0). The AVP is mandatory (the M-bit is set to 1). -- 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 2007) is 6252 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Vipin Jain 3 Internet-Draft Riverstone Networks 4 Category: Standards Track Editor 5 Expires August 2007 February 2007 7 Fail Over extensions for L2TP "failover" 8 draft-ietf-l2tpext-failover-12.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 32 Copyright (C) The IETF Trust (2007). 34 Abstract 36 L2TP is a connection-oriented protocol that has shared state between 37 active endpoints. Some of this shared state is vital for operation 38 but may be rather volatile in nature, such as packet sequence numbers 39 used on the L2TP Control Connection. When failure of one side of a 40 control connection occurs, a new control connection is created and 41 associated with the old connection by exchanging information about 42 the old connection. Such a mechanism is not intended as a replacement 43 for an active fail over with some mirrored connection states, but as 44 an aid just for those parameters that are particularly difficult to 45 have immediately available. Protocol extensions to L2TP defined in 46 this document are intended to facilitate state recovery, providing 47 additional resiliency in an L2TP network and improving a remote 48 system's layer 2 connectivity. 50 Table of Contents 52 Status of this Memo.......................................... 1 53 1.0 Introduction............................................. 3 54 1.2 Specification of Requirements............................ 4 55 2.0 Overview................................................. 4 56 3.0 Failover Protocol........................................ 6 57 3.1 Failover Capability Negotiation.......................... 6 58 3.2 Failover Recovery Procedure.............................. 6 59 3.2.1 Recovery tunnel establishment.......................... 6 60 3.2.2 Control Channel Reset.................................. 8 61 3.2.3 Data Channel Reset..................................... 8 62 3.3 Session State Synchronization............................ 9 63 4.0 New Control Messages..................................... 10 64 4.1 Failover Session Query................................... 11 65 4.2 Failover Session Response................................ 11 66 5.0 New Attribute Value Pairs................................ 12 67 5.1 Failover Capability AVP.................................. 12 68 5.2 Tunnel Recovery AVP...................................... 13 69 5.3 Suggested Control Sequence AVP........................... 14 70 5.4 Failover Session State AVP............................... 15 71 6.0 Configuration Parameters................................ 16 72 7.0 IANA Considerations...................................... 16 73 8.0 Security Considerations.................................. 16 74 9.0 Acknowledgements......................................... 17 75 10.0 Author Information...................................... 17 76 11.0 References.............................................. 17 77 11.1 Normative References.................................... 17 78 11.2 Informative References.................................. 18 79 12.0 Intellectual Property Statement......................... 18 80 13.0 Disclaimer of Validity.................................. 19 81 14.0 Copyright Statement..................................... 19 82 Appendix A................................................... 19 83 Appendix B................................................... 20 84 Appendix C................................................... 21 86 Contributors 87 Paul Howard Juniper Networks 88 Vipin Jain Riverstone Networks 89 Sam Henderson Cisco Systems 90 Keyur Parikh Harris Communications 92 Terminology 94 Endpoint: L2TP control connection endpoint i.e. either LAC or LNS. 95 Also known as LCCE in [L2TPv3] 97 Active Endpoint: An endpoint that is currently providing service. 99 Backup Endpoint: A redundant endpoint standing by for the active 100 endpoint which has its database of active tunnels and sessions in 101 sync with its active endpoint. 103 Failed Endpoint: The endpoint that was the active endpoint at the 104 time of the failure. 106 Recovery endpoint: The endpoint that initiates the failover protocol 107 to recover from the failure of an active endpoint. 109 Remote endpoint: The endpoint that peers with active endpoint before 110 failure and with recovery endpoint after failure. 112 Failover: The action of a backup endpoint taking over the service of 113 an active endpoint. This could be due to administrative action or 114 failure of the active endpoint. 116 Old Tunnel: A control connection that existed before failure and is 117 subjected to recovery upon failover. 119 Recovery Tunnel: A new control connection established only to recover 120 an old tunnel. 122 Recovered tunnel: After old tunnel's control connection and sessions 123 are restored using the mechanism described in this document, it is 124 referred as Recovered Tunnel. 126 Control Channel Failure: Failure of the component responsible for 127 establishing/maintaining tunnels and sessions at an endpoint. 129 Data Channel Failure: Failure of the component responsible for 130 forwarding the L2TP encapsulated data. 132 1.0 Introduction 134 The goal of this draft is to aid the overall resiliency of an L2TP 135 endpoint by introducing extensions to RFC 2661 [L2TPv2] and RFC 3931 136 [L2TPv3] that will minimize the recovery time of the L2TP layer after 137 a failover, while minimizing the impact on its performance. Therefore 138 it is assumed that the endpoint's overall architecture is also 139 supportive in the resiliency effort. 141 To ensure proper operation of an L2TP endpoint after a failover, the 142 associated information of the control connection and sessions between 143 them must be correct and consistent. This includes both the 144 configured and dynamic information. The configured information is 145 assumed to be correct and consistent after a failover, otherwise the 146 tunnels and sessions would not have been setup in the first place. 148 The dynamic information, which is also referred to as stateful 149 information, changes with the processing of the tunnel's control and 150 data packets. Currently, the only such information that is essential 151 to the tunnel's operation is its sequence numbers. For the tunnel 152 control channel, the inconsistencies in its sequence numbers can 153 result in the termination of the entire tunnel. For tunnel sessions, 154 the inconsistency in its sequence numbers, when used, can cause 155 significant data loss thus giving the perception of "service loss" to 156 the end user. 158 Thus, an optimal resilient architecture that aims to minimize 159 "service loss" after a failover must make provision for the tunnel's 160 essential stateful information - i.e. its sequence numbers. 161 Currently, there are two options available: the first option is to 162 ensure that the backup endpoint is completely synchronized with the 163 active with respect to the control and data sessions sequence 164 numbers. The other option is to re-establish all the tunnels and its 165 sessions after a failover. The drawback of the first option is that 166 it adds significant performance and complexity impact to the 167 endpoint's architecture, especially as tunnel and session aggregation 168 increases. The drawback of the second option is that it increases the 169 "service loss" time, especially as the architecture scales. 171 To alleviate the above-mentioned drawbacks of the current options, 172 this draft introduces a mechanism to bring the dynamic stateful 173 information of a tunnel to correct and consistent state after a 174 failure. The proposed mechanism, defines the recovery of tunnels and 175 sessions that were in established state prior to the failure. 177 1.2 Specification of Requirements 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 2.0 Overview 185 Following diagram depicts the redundancy architecture and pertaining 186 entities used to describe the failover protocol: 187 +--------------+ 188 | L2TP active | 189 +----------+ ----| endpoint (A) | 190 | L2TP | / +--------------+ 191 | endpoint |----------------------/ 192 | (R) | \ +--------------+ 193 +----------+ \ | L2TP backup | 194 ----| endpoint (B) | 195 +--------------+ 197 Active and backup endpoints may reside on the same device, however 198 they are not required to be that way. On other hand, some devices may 199 not have a standby module altogether, in which case the failed 200 endpoint, after reset, can become the recovery endpoint to recover 201 from its prior failure. 203 Therefore in the above diagram, upon A's (active endpoint's) failure: 204 - Endpoint A would be called the failed endpoint. 205 - If B is present then it would become the recovery endpoint and 206 also an active endpoint. 207 - If B is not present then, after A resets, it could become the 208 recovery endpoint provided it saved the information about active 209 tunnels/sessions in some persistent storage. 210 - R does not initiate the failover protocol; rather it waits for a 211 failure indication from recovery endpoint. 213 A device could have three kind of failures: 214 i) Control Channel Failure 215 ii) Data Channel Failure 216 iii) Control and Data Channel Failure 218 The protocol described in this document specifies the recovery in 219 conditions i) and iii). It is perceived that not much (stateful 220 information) could be recovered via a control protocol exchange in 221 case of ii). 223 The failover protocol consists of three phases: 225 1) Failover Capability Negotiation: Active endpoint and remote 226 endpoint exchange failover capabilities and attributes to be used 227 during the recovery process. 229 2) Failover Recovery: Recovery endpoint establishes a new L2TP 230 control connection (called recovery tunnel), for every old tunnel 231 that it wishes to recover. The recovery tunnel serves three purposes: 232 - It identifies the old tunnel that is being recovered. 233 - It provides a means of authentication and a three-way handshake 234 to ensure both ends agree on the failover for the specified old 235 tunnel. 236 - It could exchange the Ns and Nr values to be used in the 237 recovered tunnel. 239 Upon establishing the recovery tunnel, two endpoints reset the 240 control and data channel(s) on the recovered tunnel using the 241 procedures described in section 3.2.2 and 3.2.3 respectively. 242 Recovery tunnel could be torn down after that, and sessions that were 243 established resume traffic. 245 3) Session State Synchronization: The session state synchronization 246 process occurs on the recovered or the old tunnel and allows the two 247 endpoints to agree on the state of the various sessions in the tunnel 248 after failover. The inconsistency, which could arise due to the 249 failure, is handled in following manner: First, the two endpoints 250 silently clear the sessions that were not in the established state. 251 Then, they utilize Failover Session Query (FSQ) and Failover Session 252 Response (FSR) on the recovered tunnel to obtain the state of 253 sessions as known to the peer endpoint and clear the sessions 254 accordingly. 256 3.0 Failover Protocol 258 The protocol consists of three steps describing specifications during 259 the life of a control connection - before and after failover. 261 3.1 Failover Capability Negotiation 263 Active and Remote endpoints exchange the Failover Capability AVP in 264 SCCRQ and SCCRP during control connection establishment as a part of 265 the normal (before failover) operation. Failover Capability AVP, 266 defined section 5.1, allows an endpoint to specify if it is control 267 and/or data channel failover capable and the time allowed for the 268 recovery for the tunnel. 270 3.2 Failover Recovery Procedure 272 Failover Recovery Procedure described in this section is performed 273 only if there was a control channel failure. The selection of the 274 tunnels to be recovered is implementation specific. 276 Failover Recovery Procedure consists of following three steps, which 277 are described in detail in the subsections below: 278 - Recovery tunnel establishment 279 - Control channel reset 280 - Data channel reset 282 3.2.1 Recovery tunnel establishment 284 The recovery endpoint establishes a new control connection, called 285 recovery tunnel, for every old tunnel it wishes to recover. The 286 purpose of the recovery tunnel is solely to recover the corresponding 287 old tunnel. There is a one to one relationship between recovery 288 tunnel and recovered/old tunnel 290 Recovery tunnel establishment considerations: 291 - It MUST follow the procedures described in [L2TPv2] or [L2TPv3] 292 to establish the recovery tunnel. 294 - Recovery tunnel MUST use the same L2TP version (and 295 establishment procedures) that was used for the old tunnel. 296 - SCCRQ for Recovery tunnel MUST include Tunnel Recovery AVP, 297 which is defined in section 5.2, to identify the old tunnel that 298 is being recovered. 299 - Recovery tunnel MUST NOT include Failover Capability AVP in its 300 SCCRQ or SCCRP messages. 301 - An endpoint SHOULD NOT send any message other than following 302 messages on the recovery tunnel: SCCRQ, SCCRP, SCCCN, StopCCN, 303 HELLO, ZLB, and ACK([L2TPv3] only). 304 - An endpoint MUST NOT use any old tunnel-id for recovery tunnel. 305 The old tunnels MUST be valid till (and if) recovery process 306 concludes a failure. 307 - An endpoint MUST use Tie Breaker AVP (section 4.4.3 [L2TPv2]) or 308 Control Connection Tie Breaker AVP (section 5.4.3 [L2TPv3]) in the 309 setup of the recovery tunnel to ensure that only a single recovery 310 tunnel (when both endpoints failover) is established to recover an 311 old tunnel. The tunnel that wins the tie is used to decide the 312 suggested Ns, Nr values on the recovered tunnel. Therefore, the 313 endpoint that looses the tie, should reset the Ns and Nr values 314 (section 3.2.2) as if it were a remote endpoint. Appendix B 315 illustrates double failover scenario. 316 - Tie Breaker AVP processing: Scope of a tiebreaker AVP's action 317 for recovery and non recovery tunnels must be disjoint, and is 318 defined as follows: 319 . When tie breaker AVP is used in non recovery tunnel, the scope 320 of tie breaker AVP's action MUST only be within non recovery 321 tunnels. Therefore, losing a tie against a non recovery tunnel 322 MUST NOT result in termination of any recovery tunnel. 323 . When a tie breaker AVP is used in a recovery tunnel, the scope 324 of tie breaker AVP's action is further restricted to the recovery 325 tunnel(s) for a single tunnel to be recovered. Thus an 326 implementation MUST apply the tiebreaker received in a recovery 327 tunnel only to those tunnels that are a) recovery tunnels, and b) 328 associated with the same tunnel to be recovered. It MUST NOT 329 impact the operation of non-recovery tunnels and recovery tunnels 330 associated with other old tunnels to be recovered. 332 Upon getting an SCCRQ with a Tunnel Recovery AVP, an endpoint 333 validates Recover Tunnel Id and Recover Remote Tunnel Id and responds 334 with an SCCRP. It MUST terminate the recovery tunnel if: 335 - Recover Tunnel Id or Remote Recover Tunnel Id is unknown. 336 - Active or remote endpoint (prior to failover) had not indicated 337 that it was failover capable. 338 - The L2TP version of recovery tunnel is different from the 339 version used in the old tunnel. 341 If remote endpoint accepts the SCCRQ, it SHOULD include Suggested 342 Control Sequence AVP, defined in section 5.3, in the SCCRP message. 344 Authentication considerations: 345 - To authenticate peer endpoint during recovery tunnel 346 establishment, an endpoint MUST follow the procedure described in 347 either [L2TPv2] section 5.1.1 or [L2TPv3] section 4.3. It MUST use 348 the same secret that was used to authenticate the old tunnel. 349 - Not being able to authenticate could be a reason to terminate 350 the recovery tunnel. 351 - For L2TPv3 tunnels, recovery tunnel MUST use the Control Message 352 authentication (i.e. exchange the nonce values), as described in 353 [L2TPv3] section 4.3, if the old tunnel was configured to do 354 control message authentication. An L2TPv3 recovered tunnel MUST 355 reset its nonce values (both endpoints) to the nonce values 356 exchanged in the recovery tunnel. 358 For any reason, if the recovery endpoint could not establish the 359 recovery tunnel, then it MUST silently clear the old tunnel and 360 sessions within, concluding that the recovery process has failed. 362 Any control packet received on the recovered tunnel before control 363 channel reset (section 3.2.2) MUST be silently discarded. 365 3.2.2 Control Channel Reset 367 Control channel reset allows new control messages to be sent and 368 received over the recovered tunnel. 370 Control channel reset procedure: 371 - An endpoint SHOULD flush the transmit/receive windows and reset 372 the control channel sequence numbers (i.e. Ns and Nr values) on 373 the recovered tunnel. The control channel on recovery endpoint is 374 reset upon getting a valid SCCRP on the recovery tunnel. Whereas 375 the control channel on remote endpoint is reset upon getting a 376 valid SCCCN on the recovery tunnel. If recovery endpoint did not 377 receive Suggested Control Sequence(SCS) AVP in SCCRP then it MUST 378 reset Ns and Nr values to zero. Similarly, if remote endpoint 379 opted to not send SCS AVP then it MUST reset Ns and Nr values to 380 zero. Either endpoint can tear down the recovery tunnel after 381 control channel reset. 382 - An endpoint MUST prevent establishment of new sessions until it 383 has cleared (or marked for clearance) the sessions that were not 384 in established state i.e. until after Step I, section 3.3 is 385 complete. 387 3.2.3 Data Channel Reset 389 Data channel reset procedure is applicable only for the sessions 390 using sequence numbers. For L2TPv3 data channel, terms Nr and Ns in 391 this document are used to mean 'expected sequence number' and 392 'sequence number' respectively. 394 Data channel reset procedure: 395 - Recovery endpoint sets the Ns value to zero 396 - Remote endpoint (recovery endpoint's peer) continues to use the 397 Ns values it was using previously. 398 - To reset Nr values during failover, if an endpoint receives 'n' 399 out of order but in sequence packets then it MUST set the Nr value 400 based on the Ns value of the incoming packets, as suggested in 401 Appendix C of [L2TPv3]. The value of 'n' SHOULD be configurable. 402 - If one of the endpoints doesn't exhibit the capability 403 (indicated in 'D' bit in Failover Capability AVP) to reset the Nr 404 value, then data channels using sequence numbers are considered 405 non recoverable. Those sessions SHOULD be torn down by the 406 recovery endpoint by sending a CDN. 407 - For data-channel-only failure, two endpoints MAY use session 408 state query/response mechanism on the control channel to 409 synchronize the state of sessions as described in section 3.3 410 below. 412 3.3 Session State Synchronization 414 If control channel failure happens when a session was being 415 established or torn down, then it is possible for an endpoint to 416 consider a session in established state while its peer considers the 417 same session non existent. Two such situations occur when failure on 418 an endpoint occurs immediately after sending: 419 - A CDN message that never made it to the peer. 420 - An ICCN message that never made it to the peer. 422 Following mechanism MUST be used to identify and clear the sessions 423 that exists on an endpoint but not on its peer: 425 Step I: For control channel failure, after the recovery tunnel is 426 established, the sessions that were not in established state MUST be 427 silently cleared (i.e. without sending a CDN message) by each 428 endpoint. 430 Step II: Both endpoints MAY identify the sessions that might have 431 been in inconsistent states, perhaps based on data channel 432 inactivity. FSQ and FSR messages have been introduced to synchronize 433 session state at any given point during the life of a session between 434 two endpoints. These messages are used when one endpoint determines 435 or suspects in an implementation specific manner that its session 436 state could be inconsistent with that of its peer's. 438 Step III: An endpoint sends Failover Session Query (FSQ) message to 439 query the state of sessions as known to its peer. FSQ message 440 contains one Failover Session State (FSS) AVP, defined in section 441 5.4, for each session it wishes to query. Multiple FSS AVPs could be 442 included in one FSQ message, however an FSQ message MUST include at 443 least one FSS AVP. An endpoint MAY send another FSQ message before 444 getting response for its previous FSQs. 446 An inconsistency about session's existence during failover could 447 result into an endpoint selecting the same session id for a new 448 session. In such situation it would send an ICRQ for an already 449 established session. Therefore before all sessions are synchronized 450 using FSQ/FSR mechanism, if endpoint receives an ICRQ for a session 451 in established state, then it MUST respond to such ICRQ with a CDN. 452 The CDN message must set Assigned/Local Session ID AVP ([L2TPv2] 453 section 4.4.4, [L2TPv3] section 5.4.4) to its local session id and 454 clear the session that it considered established. Use of least 455 recently used session id for the new sessions could help reduce this 456 symptom during failover. 458 When an endpoint receives an FSQ message, it MUST ensure that for 459 each FSS AVP in FSQ message it includes an FSS AVP in Failover 460 Session Response (FSR) message. An endpoint could respond to multiple 461 FSQs using one FSR message, or it could respond one FSQ with multiple 462 FSRs. FSSs aren't required to be responded in the same order in which 463 they were received. For each FSS AVP received in FSQ, an endpoint 464 MUST validate the Remote Session Id and determine if it is paired 465 with the Session Id specified in the message. If FSS AVP is not valid 466 (i.e. session is non-existing or it is paired with different remote 467 session id), then the Session Id field in the FSS AVP in the FSR MUST 468 be set to zero. When session is discovered to be pairing with 469 mismatching session id, the local session MUST not be cleared, but 470 rather marked stale, to be queried later using an FSQ message. 471 Appendix C presents an example dialogue between two endpoints on 472 mismatching session ids. 474 When responding to FSQ with an FSR message, Remote Session Id in FSS 475 AVP of FSR message is always set to the received value of Session ID 476 in the FSS AVP of FSQ message. 478 When an endpoint receives an FSR message, for each FSS AVP it MUST 479 use the Remote Session Id field to identify the local session and 480 silently (without sending a CDN) clear the session if Session Id in 481 the AVP was zero. Otherwise it MUST consider the session to be in 482 established state and recovered. 484 4.0 New Control Messages 485 This draft introduces two new messages that could be sent over an 486 established/recovered control connection. 488 4.1 Failover Session Query 490 Failover Session Query (FSQ) control message is used by an endpoint 491 during recovery process to query the state of various sessions. It 492 triggers a response from the peer which contains the requested state 493 of various sessions. 495 This control message is encoded as follows: 497 Vendor ID = 0 (IETF) 498 Attribute Type = 21 500 The following AVPs MUST be present in the FSQ control message: 501 Message Type 502 Failover Session State 504 The following AVPs MAY be present in the FSQ control message: 505 Random Vector 506 Message digest ([L2TPv3] tunnels only) 508 Other AVPs MUST NOT be sent in this control message and SHOULD be 509 ignored on receipt. 511 The M-bit on the Message Type AVP for this control message MUST be 512 set to 0. 514 4.2 Failover Session Response 516 Failover Session Response (FSR) control message is used by an 517 endpoint during recovery process to respond with the local state of 518 various sessions. It is sent as a response to an FSQ message. An 519 endpoint MAY choose to respond to an FSQ message with multiple FSR 520 messages. 522 This control message is encoded as follows: 524 Vendor ID = 0 (IETF) 525 Attribute Type = 22 527 The following AVPs MUST be present in the FSQ control message: 529 Message Type 530 Failover Session State 532 The following AVPs MAY be present in the FSQ control message: 534 Random Vector 535 Message digest ([L2TPv3] tunnels only) 537 Other AVPs MUST NOT be sent in this control message and SHOULD be 538 ignored on receipt. 540 The M-bit on the Message Type AVP for this control message MUST be 541 set to 0. 543 5.0 New Attribute Value Pairs 545 The following sections contain a list of new L2TP AVPs defined in 546 this document. 548 5.1 Failover Capability AVP 550 The Failover Capability AVP, Attribute Type 76, indicates the 551 capabilities of an endpoint required for the recovery process. The 552 AVP format is defined as follows: 554 Failover Capability AVP 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |M|H| rsvd | Length | 0 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Attribute Type 76 | Reserved |D|C| 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Recovery Time (in milliseconds) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 The AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not 566 mandatory (the M-bit MUST be set to 0). 568 The C bit governs the failover capability for control channel. When 569 the C bit is set, it indicates that the endpoint can recover from a 570 control channel failure using the procedure described in section 571 3.2.2. 573 When the C bit is not set, it indicates that the endpoint cannot 574 recover from a control channel failover. In this case, the D bit MUST 575 be set. Note that a control channel failover in this case would be 576 fatal for the tunnel and all associated data channels. 578 The D bit governs the failover capability for data channels that use 579 sequence numbers. Data channels that do not use sequence numbers do 580 not need help to recover from a data channel failure. 582 When the D bit is set, it indicates that the endpoint is capable of 583 resetting Nr value of data channels using the procedure described in 584 section 3.2.3 Data Channel reset procedure. 586 When the D bit is not set, it indicates that the endpoint cannot 587 recover data channels that use sequence numbers. In case of a failure 588 such data channels would be lost. 590 The Failover Capability AVP MUST NOT be sent with C bit and D bit 591 cleared. 593 Recovery Time, applicable only when C bit is set, is the time in 594 milliseconds an endpoint asks its peer to wait before assuming the 595 recovery process has failed. This timer starts when an endpoint's 596 control channel timeout ([L2TPv2] section 5.8, [L2TPv3] section 4.2) 597 is started, and is not stopped (before expiry) until an endpoint 598 successfully authenticate its peer during recovery. A value of zero 599 doesn't mean that no failover will occur, it means no additional time 600 is requested from the peer. The timer is also stopped if a control 601 channel message is acknowledged by the peer in the situation when 602 there was no failover but loss of control channel message was a 603 temporary phenomenon. 605 This AVP MUST NOT be included in any control message other than SCCRQ 606 and SCCRP messages. 608 5.2 Tunnel Recovery AVP 610 The Tunnel Recovery AVP, Attribute Type 77, indicates that sender 611 would like to recover the tunnel identified in this AVP due to a 612 failure. The AVP format is defined as follows: 614 Tunnel Recovery AVP for L2TPv3 tunnels: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |M|H| rsvd | Length | 0 | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Attribute Type 77 | Reserved | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Recover Tunnel Id | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Recover Remote Tunnel Id | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Tunnel Recovery AVP for L2TPv2 tunnels: 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |M|H| rsvd | Length | 0 | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Attribute Type 77 | Reserved | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Reserved | Recover Tunnel Id | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Reserved | Recover Remote Tunnel Id | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 This AVP MUST not be hidden (the H-bit is set to 0). The AVP is 643 mandatory (the M-bit is set to 1). 645 Recover Tunnel Id encodes the local tunnel id that an endpoint wants 646 recovered. Recover Remote Tunnel Id encodes the remote tunnel id 647 corresponding to the old tunnel. 649 This AVP MUST NOT be included in any control message other than SCCRQ 650 message when establishing recovery tunnel. 652 5.3 Suggested Control Sequence AVP 654 The Suggested Control Sequence (SCS) AVP, Attribute Type 78, 655 specifies the Ns and Nr values to for the recovered tunnel. This AVP 656 is included in SCCRP message of a recovery tunnel by remote endpoint. 657 The AVP format is defined as follows: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |M|H| rsvd | Length | 0 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Attribute Type 78 | Reserved | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Suggested Ns | Suggested Nr | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not 670 mandatory (the M-bit is set to 0). 672 This is an optional AVP, suggesting Ns and Nr values to be used by 673 the recovery endpoint. If this AVP is present in an SCCRP message 674 during recovery tunnel establishment, the recovery endpoint MUST set 675 the Ns and Nr values of the recovered tunnel to the respective 676 suggested values. When this AVP is not sent in SCCRP or not present 677 in an incoming SCCRP, the Ns and Nr values for the recovered tunnel 678 are set to zero. Use of this AVP helps avoid the interference in 679 recovered tunnel's control channel with old control packets. 681 This AVP MUST NOT be included in any control message other than SCCRP 682 message when establishing recovery tunnel. 684 5.4 Failover Session State AVP 686 The Failover Session State (FSS) AVP, Attribute Type 79, is used to 687 query the state of a session from the peer end to clear the sessions 688 that otherwise would remain in an undefined state after failover. The 689 AVP format is defined as follows: 691 FSS AVP format for L2TPv3 sessions: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |M|H| rsvd | Length | 0 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Attribute Type 79 | Reserved | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Session Id | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Remote Session Id | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 FSS AVP format for L2TPv2 sessions: 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |M|H| rsvd | Length | 0 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Attribute Type 79 | Reserved | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Reserved | Session Id | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Reserved | Remote Session Id | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is 720 mandatory (the M-bit is set to 1). 722 Session Id identifies the local session id sender had assigned, for 723 which it would like to query the state on its peer. Remote Session 724 Id is the remote session id for the same session. 726 FSS AVP MUST NOT be used in any message other than FSQ and FSR 727 messages. 729 6.0 Configuration Parameters 731 An L2TP endpoint MAY expose following configuration parameters to be 732 specified for control connections: 733 - Control Channel Failover Capability: Failover Capability AVP 734 (section 5.1), C bit 735 - Data Channel Failover Capability: Failover Capability AVP 736 (section 5.1), D bit 737 - Recovery Time: Failover Capability AVP (Section 5.1) 739 The L2TP MIB defined in [L2TPv2-MIB] and [L2TPv3-MIB], defines a 740 number of objects that may be used for monitoring the status L2TP 741 nodes, but is seldom used for configuration purposes. It is expected 742 that the above mentioned parameters will be configured by using 743 Command Line Interface (CLI) or other proprietary mechanism. 745 7.0 IANA Considerations 747 This document defines following values assigned by IANA. 749 - Four Control Message Attribute Value Pairs (Section 10.1 [L2TPv3]): 750 Failover Capability : 76 751 Tunnel Recovery : 77 752 Suggested Control Sequence : 78 753 Failover Session State : 79 755 - Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]): 756 Failover Session Query : 21 757 Failover Session Response : 22 759 8.0 Security Considerations 761 A spoofed failover request (SCCRQ with Tunnel Recovery AVP) on behalf 762 of an endpoint might cause a control channel termination if 763 authentication measures mentioned in section 3.2.1 are not used. 765 If an endpoint is not explicitly configured with the possible set of 766 recovery endpoints for a given tunnel, it would end up responding to 767 the spoofed failover requests even if the tunnel authentication would 768 not have succeeded assuming authentication measures (section 3.2.1) 769 were used. Therefore, in such situation even if it would not result 770 into a tunnel failure, it could result in the discovery of an 771 operational tunnel-id on the endpoint with the probability of 1 in 772 (2^16 - 1) for [L2TPv2] and 1 in (2^32 - 1) for [L2TPv3], for every 773 spoofed request. The discovered operational tunnel id could then be 774 misused to send control messages for a possible hindrance to the 775 control connection. Typically, control messages that are outside the 776 endpoint's receive window are discarded. However, if Suggested 777 Control Sequence AVP (section 5.3) is not used during the actual 778 failover process, the sequence numbers might be reset to zero thereby 779 making the receive window predictable. To improve security under 780 such circumstances, an endpoint may be configured with the possible 781 set of recovery endpoints that could recover a tunnel, and use of 782 Suggested Control Sequence AVP when recovering a tunnel. 784 9.0 Acknowledgements 786 Leo Huber provided suggestions to help define the failover concept. 787 Mark Townsley, Carlos Pignataro, and Ignacio Goyret reviewed the 788 document and provided valuable suggestions. 790 10.0 Author Information 792 Vipin Jain 793 Riverstone Networks 794 5200 Great America Parkway 795 Santa Clara, CA 95054 796 Email: vipinietf@yahoo.com 798 Paul W. Howard 799 Juniper Networks 800 10 Technology Park Drive 801 Westford, MA 01886 802 Email: phoward@juniper.net 804 Sam Henderson 805 Cisco Systems 806 7025 Kit Creek Rd. 807 PO Box 14987 808 Research Triangle Park, NC 27709 809 Email: samh@cisco.com 811 Keyur Parikh 812 Harris Broadcast Communication 813 4393 Digitalway 814 Mason, OH 45040 815 Email: kparikh@harris.com 817 11.0 References 819 11.1 Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 825 G., and B. Palter, "Layer Two Tunneling Protocol 826 "L2TP"", RFC 2661, August 1999. 828 [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two 829 Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 830 March 2005. 832 11.2 Informative References 834 [L2TPv2-MIB] Caves, E., Calhoun, P., and Wheeler, R., "Layer Two 835 Tunneling Protocol Management Information Base", 836 RFC 3371, August 2002. 838 [L2TPv3-MIB] Nadeau, Thomas D. and Koushik, Kiran A S., "Layer Two 839 Tunneling Protocol (version 3) Management Information 840 Base", draft-ietf-l2tpext-l2tpmib-base-02.txt, 841 August 2006. 843 12.0 Intellectual Property Statement 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at ietf- 865 ipr@ietf.org. 867 13.0 Disclaimer of Validity 869 This document and the information contained herein are provided on an 870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 872 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 873 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 874 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 877 14.0 Copyright Statement 879 Copyright (C) The IETF Trust (2007). 881 This document is subject to the rights, licenses and restrictions 882 contained in BCP 78, and except as set forth therein, the authors 883 retain all their rights. 885 Appendix A 887 Description below outlines the failover protocol operation for an 888 example tunnel. The failover protocol does not preclude an endpoint 889 from recovering multiple tunnels in parallel. It also allows an 890 endpoint to send multiple FSQs, each including multiple FSS AVPs, to 891 recover quickly. 893 Failover Capability Negotiation (section 3.1): 895 Endpoint Peer 896 (assigned tid = x, failover capable) 897 SCCRQ --------------------------------------> validate SCCRQ 899 (assigned tid = y, failover capable) 900 validate <-------------------------------------- send SCCRP 901 SCCRP, etc. 903 .... .... 905 < This Node fails > 907 Recovery endpoint establishes recovery tunnel (section 3.2.1). 908 Initiate recovery tunnel establishment for the old tunnel 'x': 910 Recovery Endpoint Peer 912 (assigned tid = z, Recovery AVP) 914 SCCRQ -----------------------------------> Detects failover 915 (recover tid = x, recover remote tid = y) validate SCCRQ 917 (Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100) 918 validate <----------------------------------- send SCCRP 919 SCCRP (recover tid = y, recover remote tid = x) 920 reset Ns = 3, Nr = 100 921 on the recovered tunnel 923 SCCCN -----------------------------------> validate and reset 924 Ns = 100, Nr = 3 on 925 the recovered tunnel 927 Terminate the recovery tunnel 929 tid = 'z' 930 StopCCN --------------------------------------> Cleanup 'w' 932 Session states are synchronized both endpoints may send FSQs and 933 cleanup stale sessions (section 3.3) 935 (FSS AVP for sessions s1, s2, s3..) 936 send FSQ -------------------------------------> compute the state 937 of sessions in FSQ 939 (FSS AVP for sessions s1, s2, s3...) 940 deletes <-------------------------------------- send FSR 941 stale sessions, if any 943 (FSS AVP for sessions s7, s8, s9...) 944 compute <-------------------------------------- send FSQ 945 the sate of 946 sessions in FSQ 948 (FSS AVP for sessions s7, s8, s9...) 949 send FSR --------------------------------------> delete stale 950 sessions, if any 952 Appendix B 954 This section shows an example dialogue to illustrate double failure 955 recovery. The notable difference, as described in section 3.2.1, in 956 the procedure from single failover scenario is the use of tie breaker 957 by one of the recovery endpoints to use the recovery tunnel 958 established by its peer (also a recovery endpoint) as recovery 959 tunnel. 961 Recovery endpoint Recovery endpoint 963 (assume old tid = A) (assume old tid = B) 965 Recovery AVP = (A, B) 966 SCCRQ -----------------------+ 967 (with tie (recovery tunnel 'C') | 968 breaker | 969 AVP) | 970 Recovery AVP = (B, A) | 971 +- valid <--------------------------- Send SCCRQ 972 | SCCRQ (recovery tunnel 'D') | (with tie breaker AVP) 973 | This endpoint | 974 | loses tie; | 975 | Discards tunnel 'C' +--> Valid SCCRQ 976 | This endpoint wins tie; 977 | Discards SCCRQ 978 | 979 | (may include SCS AVP) 980 +->Send SCCRP -------------------------> Validate SCCRP 981 Reset 'B'; 982 Set Ns, Nr values --+ 983 | 984 | 985 | 986 Validate SCCN <---------------------- Send SCCN -------+ 987 Reset 'A'; 988 Set Ns, Nr values 990 FSQs and FSRs for the old tunnel (A, B) are exchanged on 991 the recovered tunnel by both endpoints. 993 Appendix C 995 Session id mismatch could not be a result of failure on one of the 996 endpoints. However, failover session recovery procedure could 997 exacerbate the situation, resulting into a permanent mismatch in 998 session ids between two endpoints. Dialogue below outlines the 999 behavior described in section 3.3 Step III to handle such situations 1000 gracefully. 1002 Recovery endpoint Remote endpoint 1004 (assume a mismatch) (assume a mismatch) 1005 Sid = A, Remote Sid = B Sid = B, Remote Sid = C 1006 Sid = C, Remote Sid = D 1008 FSS AVP (A, B) 1009 send FSQ -------------------------> No (B, A) pair exist; 1010 rather (B, C) exist. 1011 If it clears B then peer doesn't 1012 know if C is stale on other end. 1014 Instead if it marks B stale 1015 and queries the session state 1016 via FSQ, C would be cleared on 1017 the other end. 1019 FSS AVP (0, A) 1020 Clears A <-------------------------- send FSR 1022 ... some time later ... 1024 FSS AVP (B, C) 1025 No (C,B) <-------------------------- send FSQ 1026 Mark C Stale 1028 FSS AVP (0, B) 1029 Send FSR --------------------------> Clears B