Network Working Group V. Jain
Internet-Draft R. Penno
Expires: March 2002 S. McGeown
Nortel Networks
Ly Loi
TahoeNetworks
Mark Rayson
BT Network and Systems
Marc Eaton-Brown
FrontRunner Solutions
September, 2001
L2TP Tunnel Switching
draft-ietf-l2tpext-tunnel-switching-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
For some time now several equipment manufactures have been
implementing what is called L2TP tunnel switching or L2TP multihop.
Although this technology has several applications and is quite
widespread, there has been no effort to standardize the nomenclature
and methods associated with it.
The goal of this document is to achieve a common denominator in what
is tunnel switching, its advantages and nomenclature associated with
it.
Penno, et al. [Page 1]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
Specification of Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [3].
Table of Contents
1. What is L2TP Tunnel Switching. . . . . . . . . . . . . . . 3
2. Tunnel Switching Nomenclature . . . . . . . . . . . . . . .3
3. Why L2TP Tunnel Switching. . . . . . . . . . . . . . . . . 4
4. Disadvantages of Tunnel Switching. . . . . . . . . . . . . 5
5. Extensions to enhance tunnel switching support. . . . . . .6
6. References . . . . . . . . . . . . . . . . . . . . . . . .11
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . .11
8. Author's Addresses. . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement. . . . . . . . . . . . . . . . . 12
Penno, et al. [Page 2]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
1. What is L2TP Tunnel Switching
L2TP tunneling allows processing of layer2 packets to be divorced
from the termination of layer2 circuit. L2TP tunnel switching
facilitates moving the termination of a layer2 session further to
another LNS potentially unknown to the first LAC. It does so by re-
tunneling the layer2 session over another L2TP tunnel to a different
LNS. The knowledge of whether to switch a layer2 session to another
L2TP tunnel can be static or dynamic (for example when a PPP session
is established).
_______ _______ _______ _______ _______
| L2 | | | | | | | |
| User | | LAC A | | LNS A | LAC B | | LNS B |
|_______| |_______| |_______|_______| |_______|
|------ L2- ------|
|---- L2/L2TP ----|
|-- L2 --|
|------ L2/L2TP -------|
|------- tunnel switching ------|
The figure above presents a typical tunnel switching scenario. The
user opens a layer2 (for example PPP) session to LAC A, which puts
the layer2 session into a L2TP tunnel that terminates on LNS A. If
LNS A decides to further tunnel the layer2 session, it puts the
layer2 session on another L2TP tunnel originating on LAC B and
terminating on LNS B. LNS A and LAC B reside on the same device.
The process of getting the layer2 session terminating on LNS A and
further tunneling it to another LNS, in the example above LNS B, is
called tunnel switching.
2. Tunnel Switching Nomenclature
Ingress Tunnel Aggregator (ITA): These devices are represented by
the first layer of LACs, represented in the picture by LAC A. This
is he node which terminates layer2 circuit and initiates the first
L2TP tunnel.
Penno, et al. [Page 3]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
Tunnel Switching Aggregator (TSA): These are the devices that act as
LNS as well as LAC for a particular layer2 session therefore it
typically re-tunnels layer2 session to another LNS. The TSA is
composed of two parts: the TSA-LAC and the TSA-LNS.
Egress Tunnel Aggregator (ETA): These are devices that terminate the
layer2 session. They are represented in the picture by LNS B.
3. Why L2TP Tunnel Switching
This section discusses the advantages of L2TP tunnel switching.
* Often, the administrative domain of a LAC, an ILEC or CLEC, is not
same as that of LNS, typically an ISP terminating subscriber's
Layer2 connection. In such situations, a multi tier deployment with
tunnel switching helps the LEC (ILEC or CLEC) mask its internal
network architecture from the ISPs. In particular, it eases the
configuration across different administrative domain. For example,
for every new ITA added in the system, ISP doesn't need to
reconfigure its LNSs - for them LACs are always same (TSAs).
* L2TP tunnel switching divorces the location of "decision-maker" LNS.
Certain deployments do not have decision-making capabilities on LAC
For example PC based LACs might not have mechanisms to be configured
with policies a service provider wants to adopt; On other hand, it
might not be desirable to expose such policies to every customer LAC
CPE. The decision to choose the right LNS, for load balancing or
other administrative purposes, when multiple LNSs are available,
might not be done best by the first LAC always. Not all LACs should
be expected to exhibit such rich functionality, features and
flexibility.
* L2TP tunnel switching allows using a common L2TP tunnel on LAC for
sessions that are actually destined to different LNSs. This enables
wholesaling layer2 sessions destined to any LNS go over a few
tunnels.
* L2TP tunnel switching might reduce the total number of tunnels in a
meshed environment. The advantage of fewer tunnels would primarily
be in a configuration and provisioning ease. The reduction of
tunnels can be seen from three different angles, from the entire
system, from the ITA and from the last ETA point of view.
* Entire System
In a traditional deployment, the total number of L2TP sessions
between N LACs (ITA) and M LNSs (ETA) is N*M, assuming there is
at least one layer2 session from every LAC that needs to be
terminated on each LNS. With tunnel switching, this number can be
reduced to (#ETA + #ITA) * (#TSA).
Penno, et al. [Page 4]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
Of course the advantage on the reduction of tunnels in the system
only holds when the (#TSA)is less than the number of LNS1s (see
picture below).
* ITA
From the first layer of LACs point of view, the reduction in the
number of tunnels holds whenever ITA*TSA < TSA*ETA, which is true
for most deployments.
* ETA
On the other hand, the advantage on the reduction of tunnels from
the last LNS (LNS2) point of view in comparison with LNS1 is
considerable, since the M*(#TSA) is usually much less than M*N.
____ ______ ______ ______ ______
| PC | | LAC1 |__________| LNS1 | LAC2 |______________| LNS2 |
|____| |______|\ ___|______|______| |______|
\ /
\__/
___/\
____ ______ / \ ______ ______ ______
| PC | | LAC1 |_______\__| LNS1 | LAC2 |______________| LNS2 |
|____| |______| |______|______| |______|
. . . .
. . .
. / \ . .
____ ______ / \ ______ ______ ______
| PC | | LAC1 |/ \_| LNS1 | LAC2 |______________| LNS2 |
|____| |______| |______|______| |______|
4. Disadvantages of L2TP tunnel switching:
* Focal point of failure: As TSA aggregates more and more tunnels,
it becomes a focal point for failure, as compared to if ITAs had
tunnels to ETAs directly.
* Multiple Negotiations: Subscriber might be authenticated/LCP
multiple times because each TSA might have its own criteria to
determine if subscriber should be authenticated or if LCP parameters
negotiated (proxy-LCP) are appropriate.
Penno, et al. [Page 5]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
* Session limit within an L2TP tunnel: Bundling sessions within a
single L2TP tunnel makes one deployment more likely to hit the 65k
limit inherent of the L2TP protocol faster than if you have unique
tunnels. Care should be taken while deploying L2TP tunnel switching
to not exceed this limit due to aggregation of various sessions in
limited number of tunnels.
5. Extensions to enhance tunnel switching support
In this section we present new AVPs (and motivation behind them)
that can enhance tunnel switching support beyond what is usually
deployed today. These extensions are only applicable for L2TP tunnel
switching.
5.1 Problem Statement
When an TSA <-> ETA tunnel collapses for one reason or another (link
failure, etc), the initial ITA<->TSA link continues to function
normally, even though there is nowhere for the layer2 traffic to go
once it gets to this TSA point. This causes a major disruption of
service impact, as several subscribers who were knocked off the
network will not be able to get back on the network. This creates a
"black hole" condition, which directs all new sessions to the TSA,
which has no path to the ETA. All new session attempts for this ETA
fail.
5.2 Tunnel Set Dependency
A new object L2TP Dependency should be defined to maintain a
relationship between the ITA to TSA tunnels and the TSA to ETA
tunnels.
This object can be utilized by ITA to route away L2TP sessions from
failures in the TSA to ETA connection. Information about failures
between TSA and ETA should be provided to ITA through a new set of
AVPs defined below.
5.3 Tunnel Dependency Load AVP (All Control Messages)
The Tunnel Dependency Load AVP, Attribute Type XS, indicates the
capacity to carry L2TP sessions from TSA to ETA for certain
"service profile" (e.g., a ISP or Domain Name)
Penno, et al. [Page 6]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Services Profiles |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPN Length | Service Profile Name ... (arbitrary length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Load |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Load |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Number of Services Profiles indicates the number of
occurrences of the tuple (Service Profile Name, Maximum Load,
Current Load).
The Service Profile Name is up to 256 bytes long, but MUST be at
least 1 octet. This name should be as broadly unique as possible,
because the tunnels between ITA to TSA can contain sessions for
different service profiles.
The Maximum Load indicates the Maximum reference capacity for a
service profile. It could be the number of maximum tunnels
supported by the system at a point in time, maximum amount of
bandwidth, or some other metric that reflects ratio
The Current Load indicated the current capacity of the system, it
could be the number of active tunnels at a point in time, amount
of utilized bandwidth, or some other metric that reflects ratio.
This AVP MAY be be hidden (the H-bit can be either 0 or 1). The
M-bit for this AVP MUST be set to 0.
5.4. Loop Prevention AVP
The Loop Prevention AVP, Attribute Type TBD, can be used to detect
the existence of loops in the TSA network.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Nodes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HN Length | HostName ... (arbitrary length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of the Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Penno, et al. [Page 7]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
The Number of Nodes indicates the occurrences of the tuple (Host
Name, IP Address). Each tuple identifies a node in the tunnel-
switched-path.
The Hostname is MUST be same as used on the Hostname AVP when the
tunnel was established.
The IP address field represents the IP address which was used to
establish the tunnel.
This AVP is updated by LAC when a new tunnel is being
established. It adds (Hostname, IP address) tuple to the existing
AVP and increments Number of Nodes.
5.5 CDN Messages and L2TP Tunnel Switching
The Call-Disconnect-Notify (CDN) message is an L2TP control message
sent either by the LAC or LNS to request disconnection of a specific
call within the L2TP tunnel. Its purpose is to inform the peer of
the disconnection and the reason why it occurred.
As an indication to its use, an Incoming-Call-Request message is
generated by the LAC when the subscriber's call is detected. The LAC
selects a Session ID and sends the Incoming-Call-Request to the LNS;
it then waits for a response from the LNS - keeping the subscribers
call waiting. It is at this point that the LNS may decline to accept
the call
It is also understood that if the call is terminated before the LNS
accepts it, a Call-Disconnect-Notify is sent by the Calling LAC to
indicate this condition, and is understood to be catered for within
current L2TP implementation. Any CDN messages originating from the
LAC are therefore omitted from the scope of this proposal, however
the Calling LAC must interpret the CDN messages received from the
LNS correctly, and must take the appropriate steps to ensure that
the intention of the CDN messages are carried out as expected.
In the case where an L2TP Tunnel Switch has successfully extended
the Control Connection to the ETA, and it returns general CDN
messages during session establishment, any such messages may be
passed transparently through to the ITA or may be interpreted by the
TSA; such scenarios are included.
Penno, et al. [Page 8]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
The following is proposed with regards of tunnel switching and CDN
messages:
o To define the circumstances that warrants the ETA to send general
protocol CDN messages to the LAC over and above all other
signaling mechanisms defined in RFC2661.
o To include decisions that may be undertaken by an TSA.
o To include assurances that multiple TSA peering is supported.
5.6 Scenarios for generating CDN messages
The proposed causes and recommended LNS generated CDN messages for
each scenario are documented here.
5.6.1 LNS specific CDN Message
Here the TSA-LNS or Peering LNS cannot accept another Session and
signals to the downstream LAC.
o The TSA-LNS or Peering LNS reaches a pre-determined threshold,
this may be administrative or it may be a system function. As a
result, CDN Code-7 is generated by the LNS and passed to the
downstream LAC.
The downstream LAC should change the state of the upstream peer to
'busy' and apply an administrative hold-down. Thereafter the TSA-LAC
or ITA should try all possible LNS peers - if there are no
available LNS peers the CDN Code should be passed to the downstream
LAC by the TSA-LNS only. The Calling LAC may choose to clear the
call.
5.6.2 TSA-LAC specific CDN Message
This scenario only affects the TSA-LAC, which cannot establish
another session due to it reaching the aggregate session limit.
o If the TSA-LAC exceeds max-sessions then it may signal to the
TSA-LNS to generate a CDN Code-4 for the downstream LAC.
The downstream LAC should change the state of the upstream peer to
'busy' and apply an administrative hold-down. Thereafter the TSA-LAC
or Calling LAC should try all possible LNS peers - if there are no
available LNS peers the CDN Code should be passed to the downstream
LAC by the TSA-LNS only. The Calling LAC may choose to clear the
call.
Penno, et al. [Page 9]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
5.6.3 Calling LAC Control Connection failures
If there is a problem for the LAC to establish an L2TP tunnel,
because the Control Connection to the LNS is down, then a general
CDN message may or may not be appropriate depending upon the LAC
type. Three scenarios are mentioned here.
o The Calling LAC cannot establish a Control Connection with the
Peering LNS.
If the Calling LAC cannot continue with a session because there is
no Control Channel then it should try another L2TP peer. The Calling
LAC should record the unavailability of the Peering LNS and mark it
as unavailable for a period of time that is determined by the
Administrator.
o The TSA-LAC cannot establish a Control Connection with the
upstream LNS
If the TSA-LAC cannot continue with a session because there is no
Control Channel then a CDN Code-1 message may be generated by the
TSA-LNS to signal to the upstream LAC to try another L2TP peer.
The TSA-LAC should change the state of the upstream peer to 'dead'
and apply an administrative hold-down. Thereafter the TSA-LAC should
try all possible LNS peers - if there are no available LNS peers the
CDN Code should be passed to the downstream LAC by the TSA-LNS only.
o Calling LAC receives CDN Code-1
If the Calling LAC receives CDN Code-1, then it should try another
L2TP peer. The Calling LAC should record the unavailability of the
upstream LNS and mark it as unavailable for a period of time that is
determined by the Administrator. The Calling LAC will thereafter
clear the call.
5.6.4 LNS Session Failure
Unable to accept the incoming call the peer LNS may return the
correct CDN message defined above or it may be unaware of these
requirements.
The following are therefore best provided by implementation since
there are a number of options that may be selected.
* The Administrator may choose to interpret all CDN messages
generated by the upstream LNS. This is typically because the LNS
employs the CDN Codes defined above (and may be implemented as the
default option).
Penno, et al. [Page 10]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
* The Administrator may choose to ignore the CDN messages generated
by the upstream LNS, and by so doing may alert the downstream LAC
to mark it as unavailable for a period of time. This is typically
due to the upstream LNS being unaware of the CDN Codes defined
above.
* The Administrator may choose to relay any CDN messages generated
by the upstream LNS transparently through to the downstream LAC.
This caters for the scenario where the TSA is not interpreting the
CDN Codes correctly or the topology does not lend itself to the
TSA intercepting CDN messages.
6. References
[RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661,
August 1999.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7. Acknowledgments
Thanks to W. Mark Townsley for his valuable comments
8. Author's Addresses
Vipin Jain
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9
Santa Clara, CA 95054
Email: vipin@nortelnetworks.com
Reinaldo Penno
Nortel Networks, Inc.
2305 Mission College Boulevard
Building SC9
Santa Clara, CA 95054
Email: rpenno@nortelnetworks.com
Penno, et al. [Page 11]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
Ly Loi
Tahoe Networks, Inc.
3052 Orchard Drive
San Jose, CA 95134
Phone: +1 408.944.8630
Email: lll@tahoenetworks.com
Mark Rayson
British Telecom, Inc.
B67 Room 106
BT Research Laboratories
Martlesham Heath
IPSWITCH, Suffolk IP5 3RE
Phone: (01473) 649770
Email: mark.rayson@bt.com
Marc Eaton-Brown
FrontRunner Solutions, Ltd.
131 Finsbury Pavement
Moorgate
London EC2A 1NT
Phone: +44 7989 498337
Email: mebrown@frontrunner.eu.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Penno, et al. [Page 12]
Internet-Draft draft-ietf-l2tpext-switching-01.txt September, 2001
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
