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

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                     Reinaldo Penno
Internet-Draft                                           Nortel Networks
Expires Dec 2003                                              Vipin Jain
                                                     Riverstone Networks
                                                                  Ly Loi
                                                          Tahoe Networks
                                                        Marc Eaton-Brown
                                                    Devoteam FrontRunner
                                                               June 2003


                         L2TP Tunnel Switching
                 draft-ietf-l2tpext-tunnel-switching-04.txt

Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The distribution of this memo is unlimited.  It is filed as <draft-
   ietf-l2tpext-tunnel-switching-03.txt> and expires Dec 2003.  Please
   send comments to the L2TP mailing list (l2tpext@ietf.org).

Copyright Notice

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


Abstract

   L2TP Tunnel Switching, also called L2TP Multihop, is the process of
   forwarding PPP payload from an L2TP session to another L2TP session
   over a different tunnel. It facilitates moving the logical
   termination point of an L2TP session, based on layer2 characteristics
   or administrative policies, to a different LNS.  This document
   introduces the L2TP tunnel switching nomenclature, defines the
   behavior of standard AVPs [L2TP] in tunnel switching deployment, and
   proposes protocol extensions for inter-operable tunnel switching
   implementation.


Jain, et al.                expires Dec 2003                    [Page 1]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


   Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    1

   2. Purpose of tunnel switching...............................    1
      3.0 AVP Behavior..........................................    1

   4. Proposed Extensions for tunnel switching..................    1

   5. StopCCN/CDN Messages and L2TP tunnel Switching............    1

   4. IANA Considerations.......................................    1

   5. Security Considerations...................................    1

   6. Author's Addresses........................................    1

   7. Acknowledgments...........................................    1

   8. References................................................    1

   Appendix A...................................................    1

Terminology

   Tunnel Switching Aggregator (TSA): These are the devices that switch
   the PPP packets on an incoming L2TP session/tunnel on to another L2TP
   session/tunnel. TSA functions as an LNS for the inbound tunnel and as
   a LAC for the outbound tunnel.

   Inbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LNS.

   Outbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LAC.



1. Introduction

   [L2TP] allows processing of PPP packets to be divorced from the
   termination of the layer2 circuit. L2TP tunnel switching facilitates
   moving the termination point of a PPP session further on to another
   LNS that is possibly unknown to the first LAC. It does so by re-
   tunnelling the PPP session within another L2TP tunnel to a different
   LNS. The knowledge of whether to switch a PPP session to another L2TP
   tunnel can be static or dynamic (for example, during PPP session is
   establishment).


     PPP User     LAC                   TSA                       LNS
                                    [LNS      LAC]
     |---- PPP----|
                  |---- PPP/L2TP ----|
                                     |-- PPP --|
                                               |----- PPP/L2TP -----|

                                     |------ tunnel switching ------|


Jain, et al.                expires Dec 2003                    [Page 2]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002



   The figure above presents a typical tunnel switching scenario for
   incoming calls. The user opens a PPP session to a LAC, which
   tunnels the session to TSA as defined by [L2TP]. The TSA,
   based on the local policies, determines if the incoming session
   should be further tunnelled. If the TSA decides to tunnel the
   session further, then, for every such session it initiates another
   session onto another L2TP tunnel originating on the TSA terminating
   on a different LNS. Once the session is established, the data packets
   are switched from an incoming (Tunnel Id, Session Id) pair to a
   corresponding outgoing (Tunnel Id, Session Id).


2. Purpose of tunnel switching

   Tunnel switching enables redirection of PPP sessions in an L2TP network
   based on administrative policies as described below.

   - L2TP tunnel switching divorces the location of the LAC that
   implements administrative policies. LAC may not always have
   the administrative control/capability to know the LNS that
   would be most appropriate to terminate a PPP session.
   For example, PC based LACs might not be aware of the service
   provider's policies. It may not be desirable to expose such
   policies to the LAC that resides on the customer premises, or
   a LAC might not such exhibit such a rich functionality.

   Administrative policies could be based on traffic (for example,
   to balance the traffic across multiple LNSs), class of service
   (for example, to allow preferred sessions onto distinguished
   LNSs), or PPP parameters (for example, to direct traffic for
   different ISPs to different LNS based on PPP user information).

   - Some deployments, where the administrative domain of a LAC
   are not the same as that of an LNS, tunnel switching helps
   hide the internal network connectivity from one another.
   For example, if a PPP connection provider, an ILEC or a CLEC
   would like to expose only a set of LACs (that are actually
   TSA devices) to the ISP (that terminates PPP connections).
   It also eases the configuration/manageability across different



Jain, et al.                expires Dec 2003                    [Page 3]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


   administrative domains. For example, for every new LAC added in
   the ILEC's network, an ISPs do not need to reconfigure their LNSs.
   Since for them the LAC could always be the TSA.

   - Layer2 sessions wholesaling: L2TP tunnel switching allows using a
   common L2TP Tunnel on the LAC for sessions that are eventually
   destined to different LNSs (ISPs). This enables the PPP connection
   provider to bundle PPP sessions belonging different ISPs on to a
   single L2TP tunnel.


3.0 AVP Behavior

   An incoming AVP may be handled in four ways - it could be relayed,
   dropped, regenerated, or stacked. They are defined as follows.

      - RELAYED AVP: AVP value is forwarded transparently if it was
      present in the incoming message.
      To respond with an accurate value to be RELAYED, TSA MAY defer
      defer the reply to an incoming message (inbound side) until it
      gets the response for a corresponding reuqest on the outbound
      side. For example, Bearer Capabilities in SCCRP message sent
      on inbound tunnel could be derived from what was obtained in
      SCCRP from outbound tunnels.

      - DROPPED AVP: AVP is dropped if it was present in the incoming
      message.

      - REGENERATED AVP: AVP value is ignored upon receipt and a new vlaue
      is regenerated as defined by [L2TP] for the outbound message.
      Though the value of an AVP in the outbound message could result
      in the same value that arrived in, it happens with TSA knowing it.

      - STACKED AVP: In a tunnel switched environment, TSAs makes it
      transparent for the LNS to know if a session was tunnel switched.
      However, some situations might require the participating nodes
      to know the AVP Values that were encoded by nodes along the tunnel
      switched path. Under such circumstances TSA might append a new
      value of an existing AVP thereby creating multiple instances of
      a given AVP. When stacking its own AVP, typically all incoming
      AVPs in the stack are copied, however if TSA couldn't copy all
      AVPs then it SHOULD not copy any one of them.

      As an example, TSA Id AVP, a new AVP defined later in this document,
      helps prevent loops in L2TP Tunnel Switched Network. To detect a loop
      it must know TSA Id AVPs generated by nodes in the tunnel switched
      path. And so while regenerating this AVP, TSA preserves the incoming
      set of AVPs and stack its own value in it when transmitting a control



Jain, et al.                expires Dec 2003                    [Page 4]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      messsage (ICRQ, OCRQ) out.


   3.1 IETF Vendor AVPs

   This section defines the behavior of AVPs according to the guidelines
   in section 3.0. It describes the behavior of AVPs defined in [L2TP],
   [RFC3437], [RFC3308], and [RFC3145].

      Message Type (All Messages) - MUST be REGENERATED

      Random Vector (All Messages) - MUST be REGENERATED

      Result Code (CDN, StopCCN) - SHOULD be REGENERATED based on
      recommendations discussed in section 5.

      Protocol Version (SCCRQ, SCCRP) - MUST be REGENERATED. This would allow
      TSA to switch sessions when inbound and outbound tunnels use different
      versions of the L2TP protocol.

      Framing Capabilities (SCCRQ, SCCRP) - On outbound tunnels, the TSA SHOULD
      REGENERATE this AVP based upon Framing Capabilities of one or more
      inbound tunnels whose sessions could be switched to the outbound tunnel.
      Similarly, the inbound tunnel AVP SHOULD be REGENERATED by the TSA based
      upon the Framing Capabilities of the outbound tunnel.

      Bearer Capabilities (SCCRQ, SCCRP) - For the outbound tunnel, the AVP
      SHOULD be REGENERATED based upon Bearer Capabilities of one or more
      inbound tunnels whose sessions may be switched to the outbound tunnel.
      Similarly, the inbound tunnel AVP SHOULD be REGENERATED by the TSA based
      upon the Bearer Capabilities of the outbound tunnel.

      Tie Breaker (SCCRQ) - MUST be REGENERATED

      Firmware Revision (SCCRP, SCCRQ) - MUST be REGENERATED.

      Host Name (SCCRP, SCCRQ) - MAY be RELAYED, REGENERATED, or DROPPED.

      Vendor Name (SCCRP, SCCRQ) - SHOULD be REGENERATED.

      Assigned tunnel ID (SCCRP, SCCRQ, StopCCN) - MUST be REGENERATED.

      Receive Window Size (SCCRQ, SCCRP) - MUST be REGENERATED. The value
      of this AVP could be choosen based on Receive Window Sizes of the
      tunnels the TSA is going to be switching sessions to. Appendix A has
      more information on congestion control in L2TP tunnel switching
      environments.




Jain, et al.                expires Dec 2003                    [Page 5]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      Challenge (SCCRP, SCCRQ) - MUST be REGENERATED.

      Challenge Response (SCCCN, SCCRP) - MUST be REGENERATED.

      Q.931 Cause Code (CDN) - MUST be either RELAYED or DROPPED.

      Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) - MUST be REGENERATED.

      Call Serial Number (ICRQ, OCRQ) - SHOULD be RELAYED. It would best serve
      the intended purpose of this AVP and facilitate easier debugging.

      Minimum BPS (OCRQ) - MUST be RELAYED.

      Maximum BPS (OCRQ) - MUST be RELAYED.

      Bearer Type (ICRQ, OCRQ) - MUST be RELAYED.

      Framing Type (ICCN, OCCN, OCRQ) - MUST be RELAYED.

      Called Number (ICRQ, OCRQ) - SHOULD be RELAYED.

      Calling Number (ICRQ) - SHOULD be RELAYED.

      Sub-Address (ICRQ, OCRQ) - SHOULD be RELAYED.

      (Tx) Connect Speed (ICCN, OCCN) - MUST be RELAYED

      Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED

      Physical Channel ID (ICRQ, OCRP) - MAY be RELAYED, REGENERATED, or DROPPED.

      Private Group ID (ICCN) - MAY  be RELAYED, REGENERATED, or DROPPED.

      Sequencing Required (ICCN, OCCN) - SHOULD be REGENERATED.

      Initial Received LCP CONFREQ (ICCN) - MAY be RELAYED, REGENERATED,
      or DROPPED.  Proxy LCP AVPs (Initial Received LCP CONFREQ, Last
      Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be all
      RELAYED, all REGENERATED or all DROPPED.

      Last Sent LCP CONFREQ (ICCN) - MUST be either RELAYED or DROPPED.


      Last Received LCP CONFREQ (ICCN) - MUST be either RELAYED or DROPPED.

      Proxy Authen Type (ICCN) - MAY be RELAYED, REGENERATED, or DROPPED.
      Proxy Authentication AVPs (Proxy Authen Name AVP, Proxy Authen
      Challenge Proxy Authen ID and Proxy Authen Response AVP)



Jain, et al.                expires Dec 2003                    [Page 6]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      MUST be all RELAYED, all REGENERATED, or all DROPPED.

      Proxy Authen Name (ICCN) - MUST be either RELAYED or DROPPED.

      Proxy Authen Challenge (ICCN) - MUST be either RELAYED or DROPPED.

      Proxy Authen ID (ICCN) - MUST be either RELAYED or DROPPED.

      Proxy Authen Response (ICCN) - MUST be either RELAYED or DROPPED.

      Call Errors (WEN) - MUST be either RELAYED or DROPPED.

      ACCM (SLI) - MUST be either RELAYED or DROPPED.

      PPP Disconnect Cause AVP (defined by [RFC 3145]) - MUST be either
      RELAYED or DROPPED.

      LCP Want Options (defined by [RFC 3437]) - MUST be either
      RELAYED or DROPPED

      LCP Allow Options (defined by [RFC 3437] - MUST be either
      RELAYED or DROPPED

      Control Connection DS AVP (defined by [RFC 3308]) - MUST be REGENERATED.
      The value of this AVP could be chosen based on 'PHB Code' (section 6.0
      [RFC 3308]) used (or to be used) on the tunnels the TSA is going to be
      switching sessions to. TSA need not use same PHB-to-DSCP mappings on
      an incoming tunnel and outgoing tunnel.

      Session DS AVP (defined by [RFC 3308]) - MUST be REGENERATED.
      The value of this AVP could be chosen based on 'PHB Code' (section 6.0
      [RFC 3308]) used (or to be used) on the tunnels the TSA is going to be
      switching sessions to. TSA need not use same PHB-to-DSCP mappings on
      an incoming tunnel and outgoing tunnel.

      TSA Id AVPs (defined in this document) - MUST be REGENERATED.
      The value of this AVP is regenerated by stacking the local TSA Id AVP
      to the incoming set of TSA Id AVPs.

4. Proposed Extensions for tunnel switching

   In this section we present new AVPs that simply permits
   enhanced and interoperable tunnel switching support. Additionally
   proposing to solve some trade-offs that arise by deploying
   L2TP tunnel switching.

   4.1 Tunnel Capacity AVP (All Messages)




Jain, et al.                expires Dec 2003                    [Page 7]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      The tunnel Capacity AVP, Attribute Type TBD, indicates the
      sesion capacity of the sender over an L2TP tunnel.
      LAC/LNS could interpret this AVP to know if the peer it is
      connected to has capacity of receive any more sessions.
      The absolute value in this AVP is opaque to the peer,
      however relative (current to maximum) could be interpreted
      as a measure of peer's capacity.  It could be an indicative
      of bandwidth, session capacity, administrative limit, etc.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Maximum  Capacity                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Current Capacity                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Service Profile Name ... (arbitrary length)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Service Profile Name is a configured (e.g. ISP or Domain name)
      unique name between the TSA and its peer. It is up to 256 bytes
      long, but MUST be at least 1 octet. Assuming that a tunnel might
      carry sessions for multiple Service Profiles, this AVP allows
      specifying the capacity for an individual Service Profile.

      The Maximum Capacity indicates the maximum (reference) capacity of
      the TSA for a service profile. Its value is opaque to the TSA's
      peer. For example, an implementation could choose to use this to
      be an indicative of maximum number of sessions, maximum bandwidth,
      etc.

      The Current Capacity indicates the current capacity of the TSA.
      Like Maximum Capacity AVP its value is also opaque to the TSA's
      peer. The value of this AVP indicates the relatively (relative to
      Maximum Capacity) how many more sessions the TSA could handle.

      This AVP MAY be hidden (the H-bit can be either 0 or 1). The M-bit
      for this AVP MUST be set to 0.

   4.2  TSA ID AVP (ICRQ, OCRQ)

      The TSA ID AVP, Attribute Type TBD, could be used to detect if a
      session is looping in an L2TP tunnel switched network. This AVP
      MUST be STACKED.

      If this AVP was received in an incoming control packet then the



Jain, et al.                expires Dec 2003                    [Page 8]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      TSA MUST check to see if its own TSA Id (a configured value) is
      present in the stack of incoming TSA ID AVPs. Upon finding a
      match, the TSA MUST respond with a CDN carrying a Result Code
      indicating 'Loop Detected' TBD, and optinally a description
      indicating the loop condition.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   TSA Id ... (arbitrary length)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      TSA Id is a configured value (human readable string) that is
      administratively controlled to ensure its uniqueness (for every
      TSA) in an L2TP network.

      This AVP MAY be hidden (the H-bit can be either 0 or 1). The M-bit
      for this AVP MUST be set to 0.



5. StopCCN/CDN Messages and L2TP tunnel Switching

   The administrative policies on the TSA would always supersede how a
   TSA should be interpreting or not interpreting the CDN/StopCCN
   messages generated by it's peer.

   However, the recommended behavior is that, if a TSA receives a
   StopCCN/CDN message from a peer, it SHOULD convey the same message
   received on inbound or outbound tunnel. The Result Code AVP, which is
   an indicative of the type of error, should be relayed as well.  The
   following sections recommends the more specific situations and on how
   the StopCCN/CDN Error Codes are to be interpreted.

   5.1 TSA receiving CDN Error Code-7 from an LNS

      The TSA should try to establish the session on one of the
      remaining LNS peers as determined by the configured policies on
      the TSA - if there are none available it should generate a CDN
      message for the LAC with the Error Code-7.

   5.2 TSA reaching the aggregate session limit.

      In this situation the TSA SHOULD generate a CDN message with Error
      Code-4 for the LAC.

   5.3 TSA failing to establish an outbound tunnel



Jain, et al.                expires Dec 2003                   [Page  9]

INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      The TSA should try to establish the session on one of the
      remaining LNS peers as determined by the configured policies on
      the TSA - if there are none available it should generate a CDN
      message for LAC with the Error Code-1.


4. IANA Considerations

   This document requires two new "AVP Attributes" to be assigned
    through IETF Consensus [RFC2434] as indicated in Section 5 of
   [RFC2661]. These are:
      Tunnel Capacity AVP (section 4.1) Loop Prevention AVP (section
      4.2)

   This document defines no additional number spaces for IANA to manage.


5. Security Considerations

   L2TP tunnel switching introduces following security issues: - Tunnel
   Capacity AVP could reveal the capacity of various nodes
     in the network. Someone can abuse this AVP to give false
     impressions regarding current capacity to the neighboring nodes
     there by launching denial of service attack.  - TSA Id AVP could
   reveal the set of nodes a given L2TP session
     is traversing in the network.

   AVP hiding, described in [L2TP] MAY be used to help mitigate this,
   though it is not widely regarded as cryptographically secure.
   [RFC3193] describes a more robust method for securing L2TP in
   general, and should be used to encrypt all L2TP messages if access to
   the information sent within the AVPs described in this document is of
   concern.


6. Author's Addresses

   Reinaldo Penno
   Nortel Networks
   2305 Mission College Blvd
   Santa Clara, CA 95054
   Phone: +1 408.565.3023
   Email: rpenno@nortelnetworks.com

   Ly Loi
   Tahoe Networks
   3052 Orchard Drive
   San Jose, CA 95134



Jain, et al.                expires Dec 2003                   [Page 10]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


   Phone: +1 408.944.8630
   Email: lll@tahoenetworks.com

   Marc Eaton-Brown
   Devoteam FrontRunner Ltd.
   Union House
   182-194 Union Street
   London SE1 OLH
   Phone: +44 7989 498337
   Email: mebrown@devoteam-frontrunner.com

   Vipin Jain
   Riverstone Netowrks
   2903 Bunker Hill Ln #210
   Santa Clara, CA 95054
   Phone: +1 408.878.0464
   Email: vipin@riverstonenet.com

7. Acknowledgments

   Thanks to W. Mark Townsley of Cisco Systems for guiding and and
   providing useful feedback. Tom Mistretta, Mark Townsley, and Neil
   McGill suggested providing support to stack AVPs.  Mark Llacuna of
   Nortel Networks provided input to handle congestion in Tunnel Swiched
   environment.

8. References

   [L2TP] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
          B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661,
          August 1999.
   [PPP]  RFC 1661, Simpson, W., "The Point-to-Point Protocol (PPP)", STD
          51, RFC 1661, July 1994.

   [RFC 3145] RFC 3145, Verma, et. al. "L2TP Disconnect Cause Information",
              July 2001

Appendix A

Considerations for Congestion Avoidance

   [L2TP] recommends slow start and congestion avoidance techniques be
   used on the control connection. However, that alone may not be
   sufficient to deal with congestion problems in tunnel switched
   deployments. Primarily because a TSA terminates the control
   connection and initiates another one. For example, while switching
   incoming calls, outbound tunnel might be more congested than inbound
   tunnel, in which case even if two tunnels are implementing slow start



Jain, et al.                expires Dec 2003                   [Page 11]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


   and congestion avoidance procedures, the effectiveness of congestion
   control in L2TP Tunnel Switched path (first LAC to last LNS) might
   not be achieved. For example if an outbound tunnel (for outgoing
   calls) is not able to accept any more sessions, then TSA should stop
   accepting new sessions that would be tunnel switched to that outbound
   tunnel. Because if it does not do so, it might waste its resources
   processing the session connects and disconnects (due to timeouts). If
   those sessions are switched then it could be worsening the congestion
   (and tunnel's reliable delivery mechanism for control packets), by
   queueing unwanted ICRQs and CDNs to the outbound tunnel.  To avoid
   congestion, if a tunnel stops accpeting any more calls
   (incoming/outgoing) or if a particular LNS is experiencing
   congestion, then TSA could limit the rate of incoming connections on
   the inbound tunnel.  It is recommended that a TSA utilize following
   mechanisms to mitigate the congestion in the network and have
   acceptable rate of L2TP session establishment in the tunnel switched
   environment:

      - It could stop accepting new ICRQs and issue the CDNs with Result
      Code 2 with Error Code 4, indicating it is temporarily running out
      of resources. This would relieve the TSA from accepting more
      sessions till the tunnel could accept more sessions up.

      - A better way to avoid congestion would be to detect the problem
      before it becomes worse. Tunnel Capacity AVP, defined in section
      4.1 allows TSA, LAC or LNS to indicate its current capacity, which
      could be utilized by TSA to reconstruct the same AVP to pass on to
      its neighbors so they can control the rate at which sessions get
      established. For example, consider following setup:

             [ LAC-1 ] <------> [     ]
             [ LAC-2 ] <------> | TSA | <------> [ LNS-1 ]
                                [     ] <------> [ LNS-2 ]

      During tunnel establshment LNS-1, LNS-2, and TSA advertises their
      current capacity (via Tunnel Capacity AVP) to be 100 out of a
      Maximum Capacity of 100. Say, over the period some sessions get
      established and TSA switches them to LNS-1 or LNS-2 and TSA
      reaches its 50% of total capacity. LNS-1 and LNS-2 starts current
      capacity as 50 to the TSA. And TSA starts advertising its Currnet
      Capacity as 50% to LAC-1 and LAC-2.  Assume, now LNS-2 experiences
      resource crunch (cpu, memory, etc.)  and it concludes it will be
      in its best interest to not accept any more L2TP sessions. Or
      assume, TSA experiences congestion which it deduces based on
      number of control packets retransmitted in a given time or
      transmit control queues building up beyond high water mark. In
      such situations LNS-2 could advertise its current capacity to be
      0%, which TSA can interpret as to not switch any more sessions to



Jain, et al.                expires Dec 2003                   [Page 12]


INTERNET DRAFT            L2TP Tunnel Switching              August 2002


      LNS-2.  Further, the TSA could advertise its 'Currnet Capacity' to
      be 75 (based on the fact that it can switch sessions to only two
      LNSs and they are at 0% capacity and 50% capacity) to LAC-1 and
      LAC-2.  This could result into following improvements:

       + LAC-1 and/or LAC-2, if they interpret Tunnel Capacity AVP, can
       defer establishing sessions to the TSA, till TSA has more
       capacityi, i.e.  as soon as the congested LNSs' network opens up.

       + TSA itself can start switching sessions to LNS-1 instead of
       LNS-2 knowing LNS-2 has reached its maximum capacity. If LNS-1 is
       also experiencing the congestion, then TSA might stop accpeting
       new sessions till all of the outbound tunnels opens up.






































Jain, et al.                expires Dec 2003                   [Page 13]


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