Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
RFC 4951
Network Working Group V. Jain, Ed.
Request for Comments: 4951 Riverstone Networks
Category: Standards Track August 2007
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol
that has a shared state between active endpoints. Some of this
shared state is vital for operation, but may be volatile in nature,
such as packet sequence numbers used on the L2TP Control Connection.
When failure of one side of a control connection occurs, a new
control connection is created and associated with the old connection
by exchanging information about the old connection. Such a mechanism
is not intended as a replacement for an active fail over with some
mirrored connection states, but as an aid for those parameters that
are particularly difficult to have immediately available. Protocol
extensions to L2TP defined in this document are intended to
facilitate state recovery, providing additional resiliency in an L2TP
network, and improving a remote system's layer 2 connectivity.
Jain, et al. Standards Track [Page 1]
RFC 4951 FAILOVER August 2007
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................24
Jain, et al. Standards Track [Page 2]
RFC 4951 FAILOVER August 2007
1. Introduction
The goal of this document is to aid the overall resiliency of an L2TP
endpoint by introducing extensions to RFC 2661 [L2TPv2] and RFC 3931
[L2TPv3] that will minimize the recovery time of the L2TP layer after
a failover, while minimizing the impact on its performance.
Therefore, it is assumed that the endpoint's overall architecture is
also supportive in the resiliency effort.
To ensure proper operation of an L2TP endpoint after a failover, the
associated information of the control connection and sessions between
them must be correct and consistent. This includes both the
configured and dynamic information. The configured information is
assumed to be correct and consistent after a failover, otherwise the
Show full document text