[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                           V. Jain
Internet-Draft                                                 R. Penno
Expires: January 2002                                        S. McGeown
                                                        Nortel Networks

                                                                 Ly Loi

                                                           August, 2001

                          L2TP Tunnel Switching

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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.


   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

Penno, et al.                                                  [Page 1]

Internet-Draft     draft-ietf-l2tpext-switching-00.txt     August, 2001

Specification of Requirements

   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 . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.      Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 8
   8.      Author's Addresses. . . . . . . . . . . . . . . . . . . .  8
           Full Copyright Statement. . . . . . . . . . . . . . . . .  9

Penno, et al.                                                  [Page 2]

Internet-Draft      draft-ietf-l2tpext-switching-00.txt     August 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 picure by LAC A. This is the
node which terminates layer2 circuit and initiates the first L2TP

Penno, et al.                                                  [Page 3]

Internet-Draft      draft-ietf-l2tpext-switching-00.txt     August 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.

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

 * 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

 * L2TP tunnel switching might reduce the total number of tunnels in a
   meshed environment. The advantage fewer tunnels would
   primarily be 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-00.txt     August 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-00.txt     August 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

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

   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-00.txt     August 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-00.txt     August 2001

      The Number of Nodes indicates the occurrences of the tuple (Host
      Name, IP Address). Each tuple identifies a node in the tunnel-

      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.

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 8]

Internet-Draft      draft-ietf-l2tpext-switching-00.txt     August 2001

   Ly Loi
   Tahoe Networks, Inc.
   3052 Orchard Drive
   San Jose, CA 95134
   Phone: +1 408.944.8630
   Email: lll@tahoenetworks.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

   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


   Funding for the RFC editor function is currently provided by the
   Internet Society.

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/