Network Working Group Internet Draft S. Galtzur Document: draft-galtzur-l2tpext-gr-02.txt Axerra Networks Expires: April 2005 October 2004 Layer Two Tunneling Protocol (Version 3) Graceful Restart draft-galtzur-l2tpext-gr-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a mechanism that helps to minimize the negative effects on L2TP traffic caused by L2TP Control Connection Endpoint (LCCE) control plane restart, specifically by the restart of its control protocol component, on LCCEs that are capable of preserving the L2TP forwarding component ( a.k.a. the L2TP data plane) across the restart. Galtzur Expires - April 2005 [Page 1]
Graceful Restart Mechanism for L2TP (v3) October 2004 The mechanism described in this document is applicable to all LCCEs, both those with the ability to preserve Forwarding State during the control plane (CP) restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LCCEs that can not preserve their L2TP Forwarding State across the restart would not reduce the negative impact on L2TP traffic caused by their control plane restart, but it would minimize the impact on the L2TP traffic if their peer(s) are capable of preserving the Forwarding State across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual L2TP Forwarding State has to be preserved; the mechanism does not require any of the control plane related states to be preserved across the restart. Conventions used in this document For the sake of brevity in the context of this document, by "the control plane" we mean "the L2TP component of the control plane". The L2TP control plane includes all the information associated with the L2TP Control Connection and the low-order reliable delivery protocol. For the sake of brevity in the context of this document, by "L2TP Forwarding State" we mean the dynamic information that is exchanged between two LCCEs peers during the establishment of L2TP tunnels and sessions, i.e. local and remote Session IDs and local and remote cookies. The Forwarding State of an L2TP session also includes its association with the specific end service or application. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2]. Table of Contents 1. Motivation.....................................................3 2. Changes from the Previous Version..............................4 3. L2TP Extension.................................................4 3.1 Graceful Restart AVP [SCCRQ, SCCRP]........................4 3.2 Graceful Restart Session AVP [ICRQ, OCRQ, ICRP, OCRP]......5 3.3 Stale state in the Session state machine...................5 3.4 A New Error Code value.....................................5 4. Operation......................................................6 4.1 Procedure for restarting LCCE..............................6 4.2 Restart of L2TP communication with a peer LCCE.............6 Galtzur Expires - April 2005 [Page 2]
Graceful Restart Mechanism for L2TP (v3) October 2004 4.3 Accepting request to start Control Connection before disconnect detection...........................................7 4.4 Recovering stale Sessions..................................8 4.5 Partial Graceful Restart...................................9 4.6 Multiple Control Connections between a pair of LCCEs.......9 5. Security Considerations........................................9 6. IANA Considerations............................................9 References.......................................................10 Acknowledgments..................................................10 AuthorsÆ Addresses...............................................11 1. Motivation The mechanism presented in this document extends the ideas first explored in [4] for LDP graceful restart to L2TPv3. L2TPv3 [3] is the protocol of choice for setup, teardown and maintenance of pseudo- wires over an IP PSN (see [6]) just as LDP is the protocol of choice for setup, teardown and maintenance of pseudo-wires over an MPLS PSN [7], with the PWE3 Provider Edge (PE) devices acting also as L2TPv3 Control Connection Endpoints (LCCEs). In the case where a LCCE could preserve its L2TP Forwarding State across restart of its control plane, it is desirable not to perturb the L2TP Session IDs going through that LCCE. In this document, we describe a mechanism, termed "L2TP Graceful Restart", that allows the accomplishment of this goal. The mechanism described in this document is applicable to all LCCEs, both those with the ability to preserve Forwarding State during control plane restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LCCEs that can not preserve their L2TP Forwarding State across the restart would not reduce the negative impact on L2TP traffic caused by their control plane restart, but it would minimize the impact if their peer(s) are capable of preserving the Forwarding State across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual L2TP Forwarding State has to be preserved. Clearly this is the minimum amount of state that has to be preserved across the restart in order not to perturb the L2TP Session IDs terminating in a restarting LCCE. The mechanism does not require any of the L2TP- related states to be preserved across the restart. Galtzur Expires - April 2005 [Page 3]
Graceful Restart Mechanism for L2TP (v3) October 2004 2. Changes from the Previous Version 1. Processing of non-established sessions by the peer of the restarting LCCE has been clarified. 2. The list of control messages that can use the Session Graceful Restart AVP has been updated. 3. Lack of additional security risks of the Graceful Restart mechanism has been explained. 3. L2TP Extension There is one new AVP for the Control Connection Messages and one new AVP for the Session Connection Messages. There is also one new state in the Session state machine and one new Error Code value. 3.1 Graceful Restart AVP [SCCRQ, SCCRP] An LCCE that supports (fully or partially) L2TP Graceful Restart as defined in this document MUST include the Graceful Restart (GR) AVP in the SCCRQ and SCCRP messages. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor Id [IETF] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type [TBD] | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GR Reconnect Timeout (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recovery Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 16. The GR Reconnect Timeout is the time (in milliseconds) the initiating LCCE asks its peer to wait after the next detection of communication failure for a Graceful Restart Reconnection. Value of zero indicates that the LCCE does not preserve its L2TP Forwarding State across the restart of the L2TP control plane, so that the peer should not wait for a graceful restart of this LCCE. The Recovery Time is the time (in milliseconds) the initiating LCCE asks its peer to wait after the establishment of this control connection for recovery of the Sessions that belong to this Control Galtzur Expires - April 2005 [Page 4]
Graceful Restart Mechanism for L2TP (v3) October 2004 Connection. Value of zero indicates that the sending LCCE was not able to preserve the Forwarding State and restart as described in [3] should be used. 3.2 Graceful Restart Session AVP [ICRQ, OCRQ, ICRP, OCRP] An LCCE that tries to open a session for which the L2TP Forwarding State has been preserved, MUST include the Graceful Restart Session AVP when trying to reopen the Session gracefully. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor Id [IETF] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type [TBD] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When this AVP is present in an ICRQ/OCRQ/ICRP/OCRP message the value of the Remote Session ID in the Remote Session ID AVP MUST be set to the preserved value of the Remote Session ID. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6. 3.3 Stale state in the Session state machine A Session enters the stale state if it has been in the established state and its associated Control Connection enters the Graceful Restart procedure as described in the following section. Forwarding of L2TP data packets for a Session in this state remains unperturbed. A Session transits from the stale state to either the established state or the idle state as described in the following section. 3.4 A New Error Code value One new Error Code value - Session Graceful Restart Mismatch (actual value to be assigned by IANA) will be used in the CDN messages with the Result Code 2 (Session disconnected for the reason indicated in Error Code) as defined in [3] in the following situations: o Attempt to re-establish a non-stale session with a Session initiation request that contains the Session Graceful Restart AVP o Attempt to re-establish a stale session with a Session initiation request that does not contains the Session Graceful Restart AVP. 4. Operation Galtzur Expires - April 2005 [Page 5]
Graceful Restart Mechanism for L2TP (v3) October 2004 An LCCE that support the Graceful Restart, as defined in this document, advertises it by including the GR AVP in the SCCRQ or SCCRP Messages. If one of the peers does not include this AVP both LCCEs MUST follow the Control Connection initiation procedure as described in [3]. 4.1 Procedure for restarting LCCE After an LCCE restarts its control plane, it MUST check whether it was able to preserve its L2TP Forwarding State across the restart. If not, then the LCCE sets the Recovery Time to 0 in the GR AVP it sends to its peer when the Control Connection is re-established. If the L2TP Forwarding State has been preserved, the LCCE starts its internal timer, called L2TP Forwarding State Holding timer (the value of that timer SHOULD be configurable and MUST NOT be greater then the GR Reconnect Timeout sent on the previous GR AVP), and all the established L2TP Sessions transit to the stale state. Note: all the sessions that are not in the established state MUST transit to the idle state since they will never be recovered by the Graceful Restart mechanism. While this procedure is performed the LCCE MUST ignore any incoming SCCRQ messages for the Control Connections being recovered. At the expiration of the timer, all the entries still in the stale state MUST transit to the idle state (see [3] for state machine details). The value of the Recovery Time advertised in the GR AVP is set to the (current) value of the timer at the point in which the Initiation message carrying the GR AVP is sent. We say that an LCCE is in the process of restarting when the L2TP Forwarding State Holding timer has not expired. Once the timer expires, we say that the LCCE has completed its restart. When the LCCE receives the GR AVP from its peer it MUST set its L2TP Forwarding State Holding timer to the smaller value of the its own current value and the Recovery Time as advertised by the peer. 4.2 Restart of L2TP communication with a peer LCCE When an LCCE detect that its L2TP Control Connection with its peer LCCE went down, and the LCCE knows that the peer is capable of preserving its L2TP Forwarding State across the restart (as was indicated by the presence of GR AVP with non-zero Reconnect Time in the last Control Connection initiation message from this peer), the LCCE retains the remote information for the sessions associated with this Control Connection (rather than discarding the information), but all these sessions transit to the stale state. The LCCE SHOULD start Galtzur Expires - April 2005 [Page 6]
Graceful Restart Mechanism for L2TP (v3) October 2004 its reconnecting procedures immediately. Failure to reconnect MUST NOT cause termination of the Graceful Restart procedure. The amount of time the LCCE keeps its stale sessions remote information is set to the lesser of the GR Reconnect Timeout, as was advertised by the peer, and a local timer, called the Peer Liveness Timer. If within that time the LCCE still does not establish an L2TP Control Connection with its peer, the remote information of all the stale sessions MUST be deleted and these sessions MUST transit to the idle state. The Peer Liveness Timer is started when the LCCE detects that its L2TP Control Connection with the peer went down. The value of the Peer Liveness timer SHOULD be configurable. If the LCCE re-establishes a L2TP Control Connection with its peer within the lesser of the GR Reconnect Timeout and the Peer Liveness Timer, and the LCCE determines (by receiving Recovery Time equal to zero) that the peer was not able to preserve its L2TP forwarding state, the remote information for all the stale sessions MUST be immediately deleted and all these sessions MUST transit to the idle state. If the LCCE determines that the peer was able to preserve its L2TP forwarding state (as was indicated by the non-zero Recovery Time sent by the peer), the LCCE SHOULD further keep the stale sessions, received from the peer, for as long as the lesser of the Recovery Time advertised by the peer, and a local configurable value, called Maximum Recovery Time, allows. This value is the one set in the Recovery Time sent to the peer when re-establishing the Control Connection. 4.3 Accepting request to start Control Connection before disconnect detection An LCCE may fully restart before its Peer LCCE detects the failure of the Control Connection. This will cause the Peer LCCE to receive a SCCRQ for a Control Connection that is still in the established state. (Handling of multiple Control Connections between a pair of LCCEs is discussed later.) If the SCCRQ contains the Graceful Restart AVP the LCCE SHOULD continue operation as described above. If the SCCRQ does not contain the Graceful Restart AVP it should handle the SCCRQ like described in [3] and tear down the control connection and all the associated sessions. 4.4 Recovering stale Sessions After the re-establishment of Control Connection both LCCEs have marked session in stale state. From this point on re-establishment of Sessions is symmetric. For the Sessions in the stale state (stale Sessions) reconnection is similar to the normal way with the following difference: Galtzur Expires - April 2005 [Page 7]
Graceful Restart Mechanism for L2TP (v3) October 2004 When an LCCE sends OCRQ or ICRQ for a stale Session it MUST add the Graceful Restart Session AVP, MUST send the preserved value of Local Session ID in the Local Session ID AVP and MUST supply the preserved Remote Session ID in the Remote Session ID AVP. If the preserved Forwarding State included a cookie, its preserved value MUST be sent in the Assigned Cookie AVP instead of using a new random value. When an LCCE sends OCRQ or ICRQ for a non-stale session it MUST NOT add the Graceful Restart Session AVP and MUST follow the normal procedures for the values of Local Session ID, Remote Session ID and the cookie. When an LCCE receives OCRQ or ICRQ with the Graceful Restart Session AVP it will search for the corresponding Session according to the value in the Remote Session ID AVP. If this value is found, the Session is in stale state and the Local Session ID value also matches then the Session is associated with the new control connection, transits to the established state and the preserved the Local session ID, Remote Session ID and the cookie are included in the corresponding AVPs. If the Session was not in the stale state or there was a mismatch in the Local Session ID value or the cookie value, the LCCE MUST tear down the Session with the CDN Message using the Result Code 2 and the Session Graceful Restart Mismatch Error Code, delete the Session remote information and put the Session in the idle state. The LCCE MAY compare other AVP values that arrive with the OCRQ or ICRQ to validate the Graceful Restart of the Session. When LCCE receives OCRQ or ICRQ without the Graceful Restart Session AVP it will treat it as described in [3] unless the Session is in the stale state. In that case the LCCE MUST tear down the session with CDN Message using the Result Code 2 and the Session Graceful Restart Mismatch Error Code, delete the Session remote information and transit to the idle state. 4.5 Partial Graceful Restart An LCCE MAY support partial Graceful Restart. By this we mean that it cannot preserve its own state across its own restart but it can preserve it across its peer restart. An LCCE that supports partial Graceful Restart indicates it by including the GR AVP with Reconnect Time set to zero. 4.6 Multiple Control Connections between a pair of LCCEs L2TP supports multiple Control Connections between a given pair of LCCEs (identified by their respective Router IDs). It is up to the LCCEs to be able to associate the correct end points of each Control Connection. This can be done according to different criteria such as Application ID AVP, Capability List AVP etc. E.g., the LCCE MAY Galtzur Expires - April 2005 [Page 8]
Graceful Restart Mechanism for L2TP (v3) October 2004 decide that it does not allow more than one Control Connection to its peer with the same Application ID and an overlap in the Capabilities' list. The same criteria MUST be applied when restarting the Control Connection. The LCCE MUST NOT use the Control Connection ID to identify the Control Connection across restart. 5. Security Considerations The mechanism described in this document does not add any new security considerations for L2TPv3. In particular: o All the checks required during a regular restart are performed between the restarting LCCE and its peer in the case of Graceful Restart o It is impossible to change any of the L2TPv3 forwarding state including source and destination IP address, Session ID and cookie values etc. The security considerations pertaining to the original L2TP protocol [3] remain relevant. 6. IANA Considerations This document requires assignment of the following numbers by IANA: o Two new AVP types (see Sections 2.1 and 2.2 above) o One new Error Code value (see Section 2.4 above). Copyright notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Galtzur Expires - April 2005 [Page 9]
Graceful Restart Mechanism for L2TP (v3) October 2004 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 J. Lau, M. Townsley, I. Goyret , ôLayer Two Tunneling Protocol (Version 3)ö, Work in Progress, draft-ietf-l2tpext-l2tp-base- 14.txt, June 2004. 4 Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003. 5 Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003. 6 S. Bryant, P. Pate, PWE3 Architecture, Work in Progress, draft- ietf-pwe3-arch-07.txt, March 2003 7 L. Martini et al, Pseudowire Setup and Maintenance Using LDP, Work in progress, draft-ietf-pwe3-control-protocol-11.txt, October 2004 Acknowledgments I would like to thank Sam Henderson and Sasha Vainshtein for their constructive comments on this memo. I would like to also thank Gonen Zilber for participating in the writing of the first draft of this memo. AuthorsÆ Addresses Sharon Galtzur Axerra Networks 24 Raoul Wallenberg Tel Aviv, Israel Email: Sharon@Axerra.com Galtzur Expires - April 2005 [Page 10]