L2TP Working Group Vipin Jain
INTERNET DRAFT Reinaldo Penno
Expires February 2002 Nortel Networks
Keyur Parikh
Megisto Systems
Ly Loi
Tahoe Networks
Leo Huber
Extreme Networks
Mark Townsley
Cisco Systems
November 2001
Fail Over extensions for L2TP
draft-vipin-l2tpext-failover-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
L2TP is a connection-oriented protocol that has shared state between
active endpoints. Some of this shared state is vital for operation but
may be rather 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
just 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. expires May 2002 [Page 1]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
Table of Contents
Status of this Memo .............................................. 1
1.0 Introduction .............................................. 2
2.0 Failover Protocol ......................................... 3
2.1 Tunnel Establishement ..................................... 4
2.2 Session Establishement .................................... 4
2.3 Post Failure Behavior ..................................... 4
2.3.1 Failed Endpoint's Behavior ........................... 4
2.3.2 Failed Endpoint's Peer's Behavior .................... 5
2.3.3 Session State Inconsistency .......................... 5
2.3.4 Data Plane Behavior .................................. 5
3.0 Failover AVPs ............................................. 6
3.1 Failover Initiate Capability AVP .......................... 6
3.2 Failover Response Capability AVP .......................... 6
3.3 Old Tunnel Id AVP ......................................... 6
3.4 Old Local Tunnel Id AVP ................................... 7
4.0 Security Considerations ................................... 7
6.0 IANA Considerations ....................................... 7
7.0 References ................................................ 7
8.0 Author's Addresses ........................................ 8
Terminology
Endpoint: An L2TP control connection endpoint, either LAC or LNS.
Active Endpoint: An endpoint that is currently providing service.
Backup Endpoint: A redundant endpoint standing by for the active
endpoint.
Failover: A situation when an active endpoint fails and its backup take
over its role.
1.0 Introduction
The goal of this draft is to aid the overall resiliency of a L2TP
endpoint by introducing extensions to [L2TP] that will minimize the
recovery time of the L2TP layer after a failover, while minimizing the
impact on its performance. Therefore, the underlying assumption in this
draft is that, to take benefit of the new mechanism, the endpoints'
overall architecture, i.e. layers besides the L2TP, must also be
supportive in the resiliency effort.
Jain, et al. expires May 2002 [Page 2]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
To ensure proper operation of a L2TP endpoint after a failover, the
associated information of the tunnels 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 tunnels and sessions would
not have been setup in the first place. The dynamic information, which
is also referred to as stateful information, changes with the
processing of tunnel's control and data packets. Currently, the only
such information that is essential to the tunnel's operation is its
sequence numbers. For the tunnel control channel, the inconsistencies
in its sequence numbers can result in the termination of the entire
tunnel. For tunnel sessions, the inconsistency in its sequence, when
used, can cause massive data loss thus giving perception of "service
loss" to the user.
Thus, an optimal resilient architecture that aims to minimize "service
loss" after a failover must make provision for the tunnel's essential
stateful information - i.e. its sequence numbers. Currently, there are
two options available: the first option is to ensure that the backup
endpoint is in complete sync with the active with respect to the
control and data sessions sequence numbers. The other option is to
simply re-establish all the tunnels and its sessions after a failover.
The drawback of the first option is that it adds significant
performance and complexity impact to the endpoint's architecture,
especially as tunnel and session aggregation increases. The drawback of
the second option is that it increases the "service loss" time,
especially as the architecture scales.
To alleviate the above-mentioned drawbacks of the current options, this
draft introduces a mechanism to bring the dynamic stateful information
of a tunnel to correct and consistent state after a failure. Proposed
mechanism, currently, defines the recovery of sessions that were in
established state (as oppose to transient ones) prior to the failure.
2.0 Failover Protocol
The failover protocol allows an endpoint to specify its failover
capabilities when it establishes a tunnel. Based on failover
capabilities, two end points learn if a tunnel and its sessions require
recovery. Upon failure, the failed endpoint initiates a new tunnel for
every old tunnel that includes a new AVP, Old Tunnel ID AVP. This AVP
identifies the tunnel it had established with the peer and that needs
recovery. Upon getting this AVP, an endpoint learns that peer had
failed and would like to synchronize the tunnel. After a new tunnel is
established it assumes all active sessions and tunnel characteristics
that of a previous tunnel. Normal tunnel activity is resumed then.
Jain, et al. expires May 2002 [Page 3]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
2.1 Tunnel Establishment
Tunnel establishment procedures are same as defined by [L2TP], except
when establishing a tunnel, endpoints exchange their failover
capabilities using Failover Capability Initiate AVP and Failover
Capability Response AVP in SCCRQ and SCCRP control messagess.
2.2 Session Establishment
There is no change to how [L2TP] describes session establishment and
termination procedure.
2.3 Post Failure Operation
This section describes the behavior of a failed endpoint and its peer,
should there be failure. Peers must avoid sending any control packets
over the old tunnel that is being synchronized. Only those tunnels,
which exchanged failover capabilities are allowed to use failover protocol.
2.3.1. Failed Endpoint's Behavior
It establishes a new tunnel as specified in [L2TP] with following
considerations:
o SCCRQ and SCCCN messages contain the same AVPs that were originally
present in the old tunnel.
o It must include the Old Tunnel Id AVP and Old Local Tunnel Id AVP,
as defined in section 3.0, in the new SCCRQ.
o If the new tunnel is rejected then it MUST assume that recovery has
failed and should clear the tunnel on its end.
o Once failover is detected, control packets received prior to
synchronization of the tunnel should be ignored. The tunnel is said
to be in synchronized state once the establishment process is
complete.
Jain, et al. expires May 2002 [Page 4]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
2.3.2. Failed Endpoint's Peer's behavior
It accepts tunnel requests from the peer as specified in [L2TP] with
following considerations:
o It MUST use the Old Tunnel Id AVP, as described in section 3.3, to
determine whether peer is trying to recover an old tunnel and if
present which tunnel.
o It MUST validate Old Tunnel Id and Old Local Tunnel Id in an
incoming SCCRQ. If it doesn't find a match it MUST reject the SCCRQ.
o It may choose to reject the new tunnel request if it did not
advertise any failover capabilities on corresponding old tunnel.
o Upon establishment of the new tunnel, it assumes the sessions
belonging to old tunnel on the new tunnel and begin normal operation
on the tunnel.
2.3.3 Session State Inconsistency between peers
The assumption in the failover mechanism is that the backup endpoint
is kept in sync with the final state of the sessions when they are
established or terminated. However, it is possible that a failover may
occur while sessions are in transient state, in this case an endpoint
may retransmit unacknowledged control messages to bring the session
states to a consistent state once the tunnel is recovered. However, in
some cases, this may not be possible, for example if a LAC initiates a
session and fails prior to receiving its final ACK, then the session is
considered established at the LNS, however at the LAC it is still in
transient state and therefore not backed up. In this case, the LNS may
use other means to detect the "dangling" session and locally terminate
it.
2.3.4. Data Plane Behavior
If sequencing was used on data sessions, upon detecting peer's failure,
the non-failed endpoint MUST set the receive sequence number (Nr) based
on the incoming Ns value. It must also flush re-ordering buffers if
applicable.
Jain, et al. expires May 2002 [Page 5]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
3.0. Failover AVPs
The new AVPs that should be included in SCCRQ, SCCRP and SCCN messages
are as follows:
3.1. Failover Initiate Capability AVP [SCCRQ, SCCRP]
Failover Capability Initiate AVP, Attribute Type [TBD], describes if an
endpoint could initiate recovery on a given tunnel after failure.
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP is not mandatory (the M-bit MUST be set to 0) The AVP MAY be
hidden (the H-bit set to 0 or 1).
3.2. Failover Response Capability AVP [SCCRQ, SCCRP]
Failover Capability Response AVP, Attribute Type [TBD], describes if an
endpoint is capable of responding to failure on a given tunnel.
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP is not mandatory (the M-bit MUST be set to 0) The AVP MAY be
hidden (the H-bit set to 0 or 1).
3.3. Old Tunnel ID AVP
The Old Tunnel ID AVP, Attribute Type [TBD], encodes the Tunnel ID in
SCCRQ and SCCRP messages that was assigned by the receiver before
failure.
Jain, et al. expires May 2002 [Page 6]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
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] | Old Tunnel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is mandatory(the M-bit MUST be set to 1). The AVP may be
hidden (the H-bit set to 0 or 1).
3.4. Old Local Tunnel ID AVP
The Old Tunnel Local ID AVP, Attribute Type [TBD], encodes the Tunnel
Id in SCCRQ and SCCRP messages that was assigned by the sender before
failure.
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] | Old Local Tunnel Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP is not mandatory (the M-bit MUST be set to 1) The AVP may be
hidden (the H-bit set to 0 or 1).
4. Security considerations
The failover mechanism described here leaves a small (1 in 2^32) room
for an intruder to discover the old tunnel id of an existing tunnel by
trying out various possibilities in Old Tunnel Id and Old Local Tunnel
Id AVP.
6. IANA Considerations
To be completed.
7. References
[L2TP] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC2661
Jain, et al. expires May 2002 [Page 7]
Internet-Draft draft-vipin-l2tpext-failover-01.txt November 2001
8. Authors' Addresses
Vipin Jain
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054
Phone: +1 408.565.2636
Email: vipin@nortelnetworks.com
Reinaldo Penno
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054
Phone: +1 408.565.3023
Email: rpenno@nortelnetworks.com
Keyur Parikh
Megisto Systems
20251 Century Boulevard, Suite 120
Germantown, MD 20876
Phone: +1 301.444.1723
Email: kparikh@megisto.com
Leo Huber
Extreme Networks
3585 Monroe St.
Santa Clara CA 95051
Phone: +1 408.597.3037
Email: lhuber@extremenetworks.com
Ly Loi
Tahoe Networks
3052 Orchard Drive
San Jose, CA 95134
Phone: +1 408.944.8630
Email: lll@tahoenetworks.com
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: townsley@cisco.com
Jain, et al. expires May 2002 [Page 8]