[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 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 (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 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
   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.

   - 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. It would be administratively easier to manage
   this 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 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.

   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.

      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.

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

      Proxy Authen Type (ICCN) - MUST NOT Be regenerated and can only be
      RELAYED or DROPPED.  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                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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.

      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)

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

      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.

8. Author's Addresses

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

   Steve McGeown
   Sandvine Inc.
   Phone: +1 519.880.2230
   Email: smcgeown@sandvine.com


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: 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
   Pipal Systems
   2903 Bunker Hill Ln #210
   Santa Clara, CA 95054
   Phone: +1 408.470.9700
   Email: vipinietf@yahoo.com

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

























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


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