Subject: [L2tpext] Comments on draft-ietf-l2tpext-tunnel-switching-03.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 27 Sep 2002 17:01:10 +0200

Getting better, but still needs work IMO. Comments inline by WMT.

Thanks,

- Mark

Network Working Group                                     Reinaldo Penno
Internet-Draft                                           Nortel Networks
Expires Feb 2003                                              Vipin Jain
                                                             Pipal Systems
                                                             Steve McGeown
                                                             Sandvine Inc.
                                                                    Ly Loi
                                                            Tahoe Networks
                                                          Marc Eaton-Brown
                                                      Devoteam FrontRunner
                                                               August 2002

                           L2TP Tunnel Switching
                 draft-ietf-l2tpext-tunnel-switching-03.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 distribution of this memo is unlimited.  It is filed as <draft-
     ietf-l2tpext-tunnel-switching-03.txt> and expires Feb 2003.  Please
     send comments to the L2TP mailing list ([email-masked]).

Copyright Notice

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

Abstract

     L2TP Tunnel Switching, also called L2TP Multihop, is the process of
     forwarding layer2 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 Feb 2003                    [Page 1]

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     Contents

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

     1. Introduction..............................................    2

     2. Purpose of tunnel switching...............................    3

     3. Handling standard AVPs....................................    4

     4. Proposed Extensions for tunnel switching..................    7

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

     6. IANA Considerations.......................................    9

     7. Security Considerations...................................    9

     8. Authors Addresses.........................................    9

     9. Acknowledgments...........................................    10

     10. References...............................................    10

     Appendix A...................................................    11

Terminology

     Tunnel Switching Aggregator (TSA): These are the devices that switch
     the layer2 data 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 Control Connection on TSA where TSA is acting as
     LNS.

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

1. Introduction

     [L2TP] allows processing of layer2 packets to be divorced from the
     termination of the layer2 circuit. L2TP tunnel switching facilitates
     moving the termination point of a layer2 session further on to
     another LNS that potentially is unknown to the first LAC. It does so
     by re-tunnelling the layer2 session within another L2TP tunnel to a
     different LNS. The knowledge of whether to switch a layer2 session to

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     another L2TP tunnel can be static or dynamic (for example during PPP
     session is establishment).

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

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

     The figure above presents a typical tunnel switching scenario for
     incoming calls. The user opens a layer2 (for example PPP) session

WMT Are we going to mayke this RFC2661-specific or not? If so, I think we can go
ahead and call this a "PPP" session vs. a "layer2" session. If we are going to
make it L2TPv3 based, we probably need more nomenclature changes than just this.
What we have here seems sort of in-between.

     to a LAC, which puts the layer2 session into a L2TP tunnel that
     terminates on a TSA. The TSA being LNS, based on local policies
     determines which tunnel should be used to further tunnel the
     layer2 session. The same layer2 session is switched onto another L2TP
     tunnel originating on the TSA and terminating on the LNS. If
     the TSA decides to terminate the layer2 session it will not
     re-tunnel the packet.

2. Purpose of tunnel switching

     Tunnel switching enables higher administrative control on how layer2
     sessions are engineered in L2TP deployments.

WMT "higher administrative control," "layer2 sessions are engineered" - this is 
a little broad and encompassing. I think we should come down to earth a bit here.

     - L2TP tunnel switching divorces the location of the LAC that
     implements administrative policies. A LAC may not always have the
     administrative control/capability to know whether the LNS that
     would be most appropriate to terminate a layer2 session handling.
     For example, PC based LACs might not be aware of the service
     provider's policies. In some cases it may not be desirable
     to expose such policies to a LAC that resides on the
     customer premises, whereas in other situations a LAC might not such
     exhibit rich functionality. Local policies could be based on
     traffic (to balance the traffic across multiple LNSs), class of
     service (to allow preferred sessions onto distinguished LNSs), or
     layer 2 parameters (to direct traffic for different ISPs to different
     LNS, for example based on PPP user information).

     - There are situations where the administrative domain of a LAC, such
     as a Local Exchange Carrier (LEC) or Competitive Local Exchange
     Carrier (CLEC), are not the same as that of an LNS, and often are the
     Internet Service Provider (ISP) terminating the subscriber's layer2
     connections. In such situations, a tunnel switched multi tier
     deployment helps the Carrier.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     (ILEC or CLEC) hide its internal network connectivity from the
     ISPs. It eases the configuration/manageability across different
     administrative domains. For example, for every new LAC added in
     the Carrier'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 control connection on the LAC for sessions that are
     eventually destined to different LNSs (ISPs).  This enables the
     wholesaler to bundle layer2 sessions belonging different ISPs on
     to a single tunnel.

WMT I am sometimes reading "control connection" and sometimes reading "tunnel" 
for what I think are the same things. I understand that in RFC2661 this can be 
ambiguous, but please try to be consistent in your new doc. At least in the same 
paragraph ;-)

     It would be administratively easier to manage
     this flat configuration.

WMT But if you go through a tunnel switch, it's not a flat configuration, its 
tiered. Some things may become easier to manage when you aggregate traffic at 
the TSA, but other things become more difficult. For example, debugging a single 
session problem may very well become more difficult as you have to trace a user 
with a problem through each TSA, rather than knowing immediately which LAC the 
user is connected to at the LNS.

3. Handling standard AVPs

     This section defines the behavior of AVPs defined in [L2TP]
     on TSA, as to whether they should be RELAYED, DROPPED or REGENERATED.

     RELAYED AVPs are forwarded transparently only if they are present in
     the incoming message.

     DROPPED AVPs are the dropped if present in the incoming message.

     REGENERATED AVPs are the AVPs that are dropped on an inbound tunnel
     and are regenerated as defined by [L2TP] for an outbound tunnel as
     if there was no tunnel switching, possibly resulting in the same
     value.

WMT I wonder if we need a special set of AVPs that may be "stacked" as is done 
in the sessinfo for nas-port and hostname tracing. Note that I am not suggesting 
that we try and allow stacking of existing AVPs, just defining the mechanism for 
other drafts, such as sessinfo, to utilize.

     For some AVPs, to get a value to be RELAYED, the TSA might be
     required to defer sending a reply to a message on an inbound
     (or outbound) tunnel until it gets the reply for a corresponding
     request on outbound (or inbound) tunnel.

        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

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

        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.
        For example 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.

        Challenge (SCCRP, SCCRQ) - MUST be REGENERATED.

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

        Q.931 Cause Code (CDN) - MUST NOT be REGENERATED and can only be
        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.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

        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.

WMT What is the difference between MAY RELAY and MAY REGENERATE? Since 
"REGENERATION" includes the ability to use the same value received, RELAY seems 
to just be a subset of REGENERATION.

WMT Nice first shot at the list here, not an easy process. I see a lot of MAYs 
and SHOULDs right now. Perhaps we should enforce a base mode of operation, 
applying a "MUST" category to all AVPs that we possibly can. Then, in a separate 
section, AVPs with SHOULDs or MAYs that we are indecisive on. In general, the 
more MUSTs (and not "MUST NOT"s) we have, the better. Having them grouped would 
make it a little easier, at least for me, to try and grasp.

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

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

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

        Last Sent LCP CONFREQ (ICCN) - MUST NOT be REGENERATED.

WMT If you don't REGENERATE it, what do you do to it? RELAY? DROP? In general, I 
think it would be more clear to say what to _do_ vs. what not to do whenever 
possible.

        Last Received LCP CONFREQ (ICCN) - MUST NOT be REGENERATED.

WMT Whenever we say "regenerate" we will have to be clear about what it is 
regenerated with. For example, I think this assumes that PPP is run again at 
each TSA, which may not be the case. PPP might operate over the tunnel switches 
end to end (if you base your new tunnel off information, say, in the ICRQ, 
control connection the ICRQ arrives on, etc. vs. PPP negotiation). We might have 
to identify this as two modes of operation, and account in the standard for each.

        Proxy Authen Type (ICCN) - MUST NOT Be regenerated and can only be
        RELAYED or DROPPED.

WMT Why not REGENERATED? What if, at my first TSA, I allow PPP without any auth 
(say, so that the user is not prompted for a password) and then renegotiate LCP 
with CHAP at the next hop where the real policy enforcement is?

WMT I am thinking that in order to get into what MUST be done for some of these 
AVPs, we need to define very clearly the assumed mode of operation with regard 
to PPP negotiation, what information is used to setup a new session and when, 
etc. Not necessarily easy stuff to pin down, I know.

        Proxy Authentication AVPs (Proxy Authen
        Name AVP, Proxy Authen Challenge Proxy Authen ID and Proxy
        Authen Response AVP) MUST be either all DROPPED or all RELAYED.

        Proxy Authen Name (ICCN) - MUST NOT be REGENERATED.

        Proxy Authen Challenge (ICCN) - MUST NOT be REGENERATED.

        Proxy Authen ID (ICCN) - MUST NOT be REGENERATED.

        Proxy Authen Response (ICCN) - MUST NOT be REGENERATED.

        Call Errors (WEN) - MUST NOT be REGENERATED.

        ACCM (SLI) - MUST NOT be REGENERATED.

        PPP Disconnect Cause AVP (defined by [RFC 3145]) - MUST NOT be
        REGENERATED.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

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)

        The tunnel Capacity AVP, Attribute Type TBD, indicates the
        sesion capacity of the sender over an L2TP control connection.
        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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | SPN Length    | Service Profile Name ... (arbitrary length)   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Maximum  Capacity                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Current Capacity                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

WMT If your Max and Current Capacity values are fixed, there is no need for an 
SPN length in this AVP. Further, I wonder why you wouldn't use separate AVPs here?

        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. It is assumed that a tunnel
        might carry sessions for multiple Service Profiles and this AVP
        allows specifying the capacity for a 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.

WMT This sounds like something that could be moderately useful to any LAC, LNS 
or TSA. Why can't we just put this in its own "Load Balancing" or "Service 
Profile Capacity" draft?

        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.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     4.2  TSA ID AVP (ICRQ, OCRQ)

WMT This is broken through a NAT, with L2TP over ATM, L2TP over FR, and assumes 
that Hostname is unique for a given management domain of IP addresses. The 
latter may be untrue in cases where, for example, a number of LACs need to 
connect to a given LNS using a common Hostname AVP to obtain a common policy 
profile on that LNS. If any of those LACs are behind NATs, this doesn't work.

        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
        would occur as many times as the number of TSAs in the network. It
        is inserted by TSA while generating an ICRQ or OCRQ when it
        switches a session. All incoming TSA ID AVPs MUST be copied
        unaltered to the REGENERATED ICRQ or OCRQ.

        The TSA SHOULD check to see if its own Hostname and IP Addresses
        is present in one of the TSA ID AVP.

WMT If the hostname and IP address in the TSA is checked only against "its own" 
Hostname and IP address as stated above, then loop detection only works if the 
loop traverses the starting point. Given that we are assuming one's topology may 
be so convoluted and broken that a loop is possible, then we would have to 
assume that the loop may actually start *after* the initial LAC. In fact, that 
is probably the case, considering the initial LAC would _probably_ not be 
configured as a TSA as well.

        If it does then it MUST
        respond with a CDN carrying a Result Code AVP indicating Result
        Code to be 'General Error', Error Code indicating 'Loop Detected'
        TBD, and optionally a description indicating the loop condition.

        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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | HN Length     |          HostName ... (arbitrary length)      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        IP address                             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

WMT Why do you need an HN Length? You know the length of the AVP, and last I 
checked IPv4 addresses were always 4 bytes ;-) As with the above new AVP, it 
would really make more sense in my code for these to be separate AVPs. Most 
other code I have seen it would be as well. Further, this way you could extend 
this to IPv6, FR, ATM, etc. without having to affect the Hostname value. In 
fact, you don't even need to copy the Hostname if you state that the existing 
Hostname value is either RELAYED as defined in this draft, or stacked as defined 
in the sessinfo draft.

        The Hostname MUST be the same as that used on the Hostname AVP
        when the tunnel was established.

        The IP address field represents the TSA's IPv4 address on a tunnel
        where a session is being switched to.

        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.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     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

        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.

6. IANA Considerations

     This document requires two new "AVP Attributes" to be assigned
     through IETF Consensus [RFC2434]:
        Tunnel Capacity AVP (section 4.1)
        TSA Id AVP (section 4.2)

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

7. Security Considerations

     L2TP tunnel switching inherits all security issues from [L2TP] and
     does not introduce any new security issues.

WMT Sure it does. What about carrying the IP address and Hostname of the 
originating LAC around through multiple Hops and administrative domains? What 
about the ability to obtain "Maximum Capacity" profiles and using this to 
optimize DoS attacks? I know, "use IPsec," but in the absence of IPsec, these 
are additional security issues.

8. Author's Addresses

     Reinaldo Penno
     Nortel Networks
     2305 Mission College Blvd
     Santa Clara, CA 95054
     Phone: +1 408.565.3023
     Email: [email-masked]

     Steve McGeown
     Sandvine Inc.
     Phone: +1 519.880.2230
     Email: [email-masked]

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

     Ly Loi
     Tahoe Networks
     3052 Orchard Drive
     San Jose, CA 95134
     Phone: +1 408.944.8630
     Email: [email-masked]

     Marc Eaton-Brown
     Devoteam FrontRunner Ltd.
     Union House
     182-194 Union Street
     London SE1 OLH
     Phone: +44 7989 498337
     Email: [email-masked]

     Vipin Jain
     Pipal Systems
     2903 Bunker Hill Ln #210
     Santa Clara, CA 95054
     Phone: +1 408.470.9700
     Email: [email-masked]

9. Acknowledgments

     Thanks to W. Mark Townsley of Cisco Systems and Mark Llacuna of
     Nortel Networks for their valuable comments.

10. 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 2119] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

Appendix A

Considerations for Congestion Avoidance

     [L2TP] recommends slow start and congestion avoidance techniques be
     used on the control connection. 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 and congestion
     avoidance procedures, the effectiveness of end to end (first LAC to
     last LNS in tunnel switched network) congestion control might not be
     achieved.

WMT The point of the congesting control, really, was to ensure that the 
intervening network is not overly utilized (like TCP). Yes, it also provides 
some congestion control of the peer for processing messages, which is probably 
the more useful effect in practice.

     In order to deal with the situation it is recommended that
     a TSA utilize the congestion information from the outbound tunnel to
     provide feedback information in following manner:

     - It could stop accepting new ICRQs with the issue of the
       appropriate cause code in ICCNs

WMT Don't you mean in a CDN?

WMT Another way is to ZLB ack (or piggyback ack) and ICRQ, and wait before 
sending the ICRP. A drastic measure if life is really bad, is to simply drop 
incoming messages so that the peer backs off exponentially.

     - It could utilize a Tunnel Capacity AVP to indicate that TSA might
       not have capacity to handle more sessions on the given incoming
       tunnel.

     This will ensure the TSA to be as transparent as possible to the
     congestion in the network and provide end to end congestion control.

WMT Well, I wouldn't call it end to end congestion control in the strict sense 
of the word. But, yes, these mechanisms could help bring the sessions up without 
thrashing. I think that we may need to be a little more specific here though.

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

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext