Subject: RE: [L2tpext] Application Identifier AVP

From: [email-masked]
Date: Wed, 14 Aug 2002 16:43:46 +0300

Mistretta, Tom writes:

 > Perhaps you could explain some more about what applications you are thinking
 > of?  VPN is a broad term and clearly there are cases where VPNs are
 > implemented with PPP/L2TP.

i'm thinking about provider based vpns, for example, virtual private lan
service (vlps) as being standardized by the ppvpn wg.  these typically
don't use ppp, but carry, for example, ethernet frames directly over
l2tp as described in draft-so-pwe3-ethernet-01.txt.

-- juha

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

---

From: [email-masked]
Date: Wed, 14 Aug 2002 16:43:46 +0300

-- juha

---

From: "Mistretta, Tom" <[email-masked]>
Date: Wed, 14 Aug 2002 09:36:34 -0400

> may be so in the ppp case, but not, for example, in the vpn case.
[...]
> each RFC that describes an application that uses the AI AVP, would

Tom

---

From: [email-masked]
Date: Wed, 14 Aug 2002 22:13:20 +0300

Cheng-Yin Lee writes:

 > The VPN ID for VPN/VPL is useful but it is not necessary for a pseudo
 > X leased line to have a VPN ID. 

right.  in that case the end point id would just identify the leased
line.  the application ID would tell that the session if for a leased
line and not, for example, for a vpn.

 > Are we blurring the lines between the unique ID required for two
 > endpoints (the End Identifier required to determine if a session
 > request tie has occurred) and VPN identification?

the end point id would serve both purposes.

-- juha

---

From: [email-masked]
Date: Wed, 14 Aug 2002 22:13:20 +0300

-- juha

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 14 Aug 2002 16:23:50 -0400

Juha,

> the end point id would serve both purposes.

Is it possible for a device to be able to setup two different L2TP sessions
(e.g. via two different interfaces, but using the same source IP address) to
another device for the same VPN?

thanks
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 14 Aug 2002 16:23:50 -0400

Juha,

thanks
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 14 Aug 2002 16:49:21 -0400

I have been requested to repost this since the first attempt didn't make
it to the list...

Cheng-Yin Lee wrote:

> Juha,
> I agree that it is useful for PE-based VPNs/VPLs to have an
> application identification to tell apart say a FR pwe from an Ethernet
> pwe. For CE-based VPLs, a CE is installed for a certain application
> say VPL and so perhaps in practice it is not necessary for the CE to
> distinguish among different applications ( but I'm not objecting to
> having an application identification for the general case).
>
>> for example, there are many different VPN models that require different
>> actions at the receiver of the L2TP session setup.  without the AI AVP,
>> each of them would need to invent their own VPN ID AVP, even if its
>> contents would be exactly the same.  with the AI AVP, the End Identifier
>> AVP could carry the VPN ID.
>>
> X leased line to have a VPN ID. Are we blurring the lines between the
> unique ID required for two endpoints (the End Identifier required to
> determine if a session request tie has occurred) and VPN
> identification?
>
> regards,
> cheng-yin
>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 14 Aug 2002 16:49:21 -0400

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 15 Aug 2002 00:38:00 +0200

> another device for the same VPN?

I don't see why not. You would need to have a different End ID for each session, 
but the VPN membership (potentially determined offbox, but certainly outside the 
direct scope of the L2TP protocol itself) would resolve them into the same VPN.

The source IP address would only have relevance if the RFC for the associated 
Application ID said it did. I don't see why it would need to have relevance 
though. I would consider the L2TP Hostname AVP as a better identifier of an LCCE 
(e.g. a PE in PWE3 terms) than the source IP address. This is what we have most 
often used in L2TPv2.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 15 Aug 2002 00:38:00 +0200

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 15 Aug 2002 10:33:38 -0400

Mark, Juha,

> direct scope of the L2TP protocol itself) would resolve them into the same VPN.

Yes, that's exactly the point, the End ID may not be used for both L2TP session tie
determination and VPN identification then.

From http://search.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-03.txt
"End Identifier
.....
This AVP allows an LCCE to determine when a session request
   "tie" has occurred. ......

   Use of the End Identifier AVP implies that the session follows the
   "LAC-LAC" reference model.  The End Identifier MUST contain
   interface, circuit, or remote system information, depending on the
   circuit that is being tunneled.  For example, the field may be a
   simple 4-octet binary value, a VPN Identifier (as described in
   [RFC2764]), or an ASCII string."
I guess the l2tpv3 draft does seem to leave it open to application on how the End Id
is used.
(As an aside note, I think the End Id AVP may also be used for L2TP setup from
CE-CE, I'm not sure if "LAC-LAC" captures that).

> (e.g. a PE in PWE3 terms) than the source IP address. This is what we have most

Thanks for clarifying this. If the L2TP Hostname AVP is used, I think the End ID
should not be used to carry the VPN Id.

regards,
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 15 Aug 2002 10:33:38 -0400

Mark, Juha,

regards,
cheng-yin

---

From: Vipin Jain <[email-masked]>
Date: Fri, 16 Aug 2002 20:00:26 -0700 (PDT)

Please find the new revised L2TP Tunnel-Switching draft. It revises plenty of
nomenclature, simplifies the AVPs, etc. I think some AVPs proposed in this
draft could be useful in non tunnel switching environment as well.

Your comments are welcome!

thanks,
-- vipin

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, define the
   behavior of standard AVPs [L2TP] in tunnel switching deployment, and
   proposes protocol extensions for inter-operable tunnel switching
   implementations.

Authors: Vipin Jain, Reinaldo Penno, Ly Loi, Marc Eaton Brown, Steve McGeown

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

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
                                                   FrontRunner Solutions
                                                             August 2002

                         L2TP Tunnel Switching

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 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, define the
   behavior of standard AVPs [L2TP] in tunnel switching deployment, and
   proposes protocol extensions for inter-operable tunnel switching
   implementations.

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..................    6

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

   4. IANA Considerations.......................................    9

   5. Security Considerations...................................    9

   6. Author's Addresses........................................    9

   7. Acknowledgments...........................................   10

   8. References................................................   10

   Appendix A...................................................   10

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 layer2 circuit. L2TP tunnel switching facilitates
   moving the termination of a layer2 session further to another LNS
   that potentially is 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

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

   L2TP tunnel can be static or dynamic (for example when a PPP session
   is established).

     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
   to a LAC, which puts the layer2 session into a L2TP tunnel that
   terminates on TSA. TSA being LNS, based on local policies
   determines which tunnel to further tunnel the layer2 session.
   It puts the layer2 session on another L2TP tunnel originating
   on TSA and terminating on the LNS. If TSA decides to terminate
   the layer2 session it will not further tunnel the packet.

2. Purpose of tunnel switching

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

   - 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 the LNS that would be most appropriate to terminate a layer2
   session. 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 customer premises, where as in other situations
   a LAC might not 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, a
   Local Exchange Carrier (LEC) or Competitive Local Exchange
   Carrier (CLEC), is not the same as that of an LNS, typically the
   Internet Service Provider (ISP) terminating subscriber's layer2
   connection. In such situations,
   a tunnel switched multi tier deployment helps an LEC
   (ILEC or CLEC) hide its internal network connectivity from the

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

   ISPs. It eases the configuration/manageability across different
   administrative domains. For example, for every new LAC added in
   the LEC's network, ISPs do not need to reconfigure their LNSs. 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. It would be administratively easier to manage
   the flat configuration.

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 AVP is relayed only if it is 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.

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

      Message Type (All Messages) - MUST regenerate

      Random Vector (All Messages) - MUST regenerate

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

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

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

      Bearer Capabilities (SCCRP, SCCRQ) - On outbound tunnel, TSA SHOULD
      regenerate this AVP based on Bearer Capabilities of one or more inbound
      tunnels whose sessions could be switched to the outbound tunnel.
      Similarly, TSA SHOULD regenerate this AVP on inbound tunnel based on

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

      the Bearer Capabilities of the outbound tunnels.

      Tie Breaker (SCCRQ) - MUST regenerate

      Firmware Revision (SCCRP, SCCRQ) - MUST regenerate

      Host Name (SCCRP, SCCRQ) - MAY relay, regenerate, or drop.

      Vendor Name (SCCRP, SCCRQ) - SHOULD regenerate.

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

      Receive Window Size (SCCRQ, SCCRP) - MUST regenerate. It is recommended
      to choose this AVP based on Receive Window Sizes of various
      tunnels it is going to switching sessions to. Appendix A has
      more information on congestion control in L2TP tunnel switching
      environments.

      Challenge (SCCRP, SCCRQ) - MUST regenerate.

      Challenge Response (SCCCN, SCCRP) - MUST regenerate.

      Q.931 Cause Code (CDN) - MUST not regenerate i.e. either relay or drop.

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

      Call Serial Number (ICRQ, OCRQ) - SHOULD relay. It would be
      easier to debug and serve the intended purpose if this AVP is relayed.

      Minimum BPS (OCRQ) - MUST relay.

      Maximum BPS (OCRQ) - MUST relay.

      Bearer Type (ICRQ, OCRQ) - MUST relay.

      Framing Type (ICCN, OCCN, OCRQ) - MUST relay.

      Called Number (ICRQ, OCRQ) - SHOULD relay.

      Calling Number (ICRQ) - SHOULD relay.

      Sub-Address (ICRQ, OCRQ) - SHOULD relay.

      (Tx) Connect Speed (ICCN, OCCN) - MUST relay

      Rx Connect Speed (ICCN, OCCN) - MUST relay

      Physical Channel ID (ICRQ, OCRP) - MAY relay, regenerate, or drop.

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

      Private Group ID (ICCN) - MAY relay, regenerate, or drop

      Sequencing Required (ICCN, OCCN) - SHOULD regenerate.

      Initial Received LCP CONFREQ (ICCN) - MUST not regenerate. i.e. either
      relay or drop. 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 regenerate

      Last Received LCP CONFREQ (ICCN) - MUST NOT regenerate.

      Proxy Authen Type (ICCN) - MUST not regenerate. i.e. either relay or drop
      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 regenerate.

      Proxy Authen Challenge (ICCN) - MUST NOT regenerate.

      Proxy Authen ID (ICCN) - MUST NOT regenerate.

      Proxy Authen Response (ICCN) - MUST NOT regenerate.

      Call Errors (WEN) - MUST NOT regenerate.

      ACCM (SLI) - MUST NOT regenerate.

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

4. Proposed Extensions for tunnel switching

   In this section we present new AVPs that would allow an
   enhanced, inter-operable tunnel switching implementation. It
   also proposes to solve some trade-offs that arises by deploying
   tunnel switching.

   4.1 tunnel Capacity AVP (All Messages)

      The tunnel Capacity AVP, Attribute Type TBD, indicates the
      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,

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

      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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Service Profile Name is a configured (e.g. ISP name or domain
      name) unique name between 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 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 an opaque to TSA's
      peer. The value of this AVP indicates the relatively (relative to
      Maximum Capacity) how many more sessions 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
      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.

      TSA SHOULD check to see if its own host-name and IP addresses
      occur in one of the TSA ID AVP. If it does then it MUST respond
      with a CDN with Result Code AVP indicating Result Code to be
      'General Error', Error Code indicating 'Loop Detected' TBD, and

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

      optional description indicating a loop was detected.

      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                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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 TSA would always supersede how TSA
   should be interpreting or not interpreting the CDN/StopCCN messages
   generated by TSA's peer.

   However, the recommended behavior is that, if TSA receives a
   StopCCN/CDN message from a peer, it SHOULD convey the same on inbound
   or outbound tunnel. The Result Code AVP, which is an indicative of
   the type of error, should be relayed as well.  Following sections
   recommends the more specific situations 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 LAC with the Error Code-7.

   5.2 TSA reaching the aggregate session limit.

      In this situation TSA SHOULD generate 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

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

      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 Dependency Load 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 inherits all security issues from [L2TP] and
   does not introduce any new security issues.

6. 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]

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

   Marc Eaton-Brown
   FrontRunner Solutions, Ltd.
   131 Finsbury Pavement
   Moorgate
   London EC2A 1NT
   Phone: +44 7989 498337
   Email: [email-masked]

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

INTERNET DRAFT            L2TP Tunnel Switching              August 2002

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

7. Acknowledgments

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

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

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. It is
   because TSA terminates the control connection and initiates another
   one. For example, for 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. In order to deal
   with the situation it is recommended that TSA utilize the congestion
   information from outbound tunnel to provide feedback in following
   ways on to the inbound tunnel:

   - It could stop accepting new ICRQs with appropriate cause code
     in ICCNs - It could utilize Tunnel Capacity AVP to indicate that
   TSA might
     not have capacity to handle more sessions on the given incoming
     tunnel.

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

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

---

From: Vipin Jain <[email-masked]>
Date: Fri, 16 Aug 2002 20:00:26 -0700 (PDT)

thanks,
-- vipin

Abstract

                         L2TP Tunnel Switching

Status of this Memo

Copyright Notice

Abstract

   Contents

Terminology

1. Introduction

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

      0                   1                   2                   3

      0                   1                   2                   3

4. IANA Considerations

6. Author's Addresses

   Reinaldo Penno
   Nortel Networks

   Steve McGeown
   Sandvine Inc.
   Phone: +1 519.880.2230

   Ly Loi
   Tahoe Networks
   3052 Orchard Drive
   San Jose, CA 95134
   Phone: +1 408.944.8630

   Marc Eaton-Brown

   Vipin Jain
   Pipal Systems
   2903 Bunker Hill Ln #210
   Santa Clara, CA 95054
   Phone: +1 408.470.9700

7. Acknowledgments

8. References

Appendix A

---

From: Vipin Jain <[email-masked]>
Date: Sat, 17 Aug 2002 15:41:13 -0700 (PDT)

Forgor to change the subject line when I used an old email to pick the l2tpext
mailing list address.

thanks,
-- vipin

--- Vipin Jain <[email-masked]> wrote:
> http://www.hotjobs.com> Network Working Group                                
    Reinaldo Penno

---

From: Vipin Jain <[email-masked]>
Date: Sat, 17 Aug 2002 15:41:13 -0700 (PDT)

thanks,
-- vipin

    Reinaldo Penno

---

From: [email-masked]
Date: Mon, 19 Aug 2002 07:49:03 +0300

Cheng-Yin Lee writes:

 > Yes, that's exactly the point, the End ID may not be used for both
 > L2TP session tie determination and VPN identification then.

what can be used as the end identifier, depends on the application.  in
some vpn applications, it is fine to use vpn identifier as the end
identifier.  in some other vpn applications, vpn identifier alone is not
enough, but must be augmented, for example, by a ce identifier.

the possible use of the end identifier would be described in the
application rfc that defines a particular Application Identifier AVP
value.

 > Thanks for clarifying this. If the L2TP Hostname AVP is used, I think
 > the End ID should not be used to carry the VPN Id.

it is not the business of the l2tp rfc to say what an application is
using as the end identifier.

-- juha

---

From: [email-masked]
Date: Mon, 19 Aug 2002 07:49:03 +0300

-- juha

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 19 Aug 2002 10:31:44 +0200

> enough, but must be augmented, for example, by a ce identifier.

Right, I think the point is that the "End ID" is defined reasonably well for the 
purpose of tie-breaking, but not necessarily for all applications one might 
envision and deploy. The "Application ID" would simply be a pointer for 
interpretation of the End ID. Think of it as an additional attribute type, 
pointing to the Value of the End ID to provide additional structure. You are 
essentially saying, "I have this value, and I am going to use it for one or two 
purposes. At a minimum, I will use it for tie breaking at the most basic 
protocol level where I don't care what form the value is in as long as it does 
or does not match that sent by my peer. The secondary purpose is to give the 
arbitrary data meaning based on an application that is defined outside the scope 
of the L2TP protocol."

One of the underlying assumptions here is that the given application requires a 
matching identification to be sent from either side of the connection at 
startup, which may or may not be the case. Thus, not all applications may find 
the End ID necessary or sufficient. That is fine, new AVPs can be defined for 
these applications. I think the basis for including the "Application ID" with 
the "End ID" in the base RFC is that there are a sufficient number of 
applications that could utilize this basic model to make it worthwhile.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 19 Aug 2002 10:31:44 +0200