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]
