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

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                         M. Kelkar
Internet Draft                                             T. Mistretta
Intended status: Standards Track                              P. Howard
Expires: September 2007                                Juniper Networks
                                                                 V. Jain
                                                     Riverstone Networks
                                                           March 1, 2007



                      PPP over L2TP Tunnel Switching
                draft-ietf-l2tpext-tunnel-switching-08.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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/ietf/1id-abstracts.txt

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

   Distribution of this document is unlimited.  Please send comments to
   the Layer Two Tunneling Protocol Extensions (l2tpext) working group
   at l2tpext@ietf.org.

Abstract

   PPP [7] over 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 layer 2
   characteristics or administrative policies, to different L2tp



Kelkar, et al.        Expires September 1, 2007                [Page 1]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   Endpoint.  This document introduces the L2TP tunnel switching
   nomenclature and defines the behavior of standard AVPs in tunnel
   switching deployment.  The scope of this document is limited to the
   discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels.

Table of Contents

   1. Introduction...................................................3
   2. L2TPv2 to L2TPv3 switch........................................4
   3. AVP Behavior...................................................4
      3.1. IETF Vendor AVPs..........................................5
   4. Loop Detection................................................11
   5. CDN Messages and L2TP tunnel Switching........................12
   6. IANA Considerations...........................................12
      6.1. Control Message Attribute Value Pairs (AVPs).............12
      6.2. Result Code AVP Values...................................13
   7. Security Considerations.......................................13
   8. Intellectual Property Statement...............................13
   9. Copyright Statement...........................................14
   10. Acknowledgments..............................................14
   11. References...................................................15
      11.1. Normative References....................................15
      11.2. Informative References..................................15
   Author's Addresses...............................................16

Terminology

   Tunnel Switching Aggregator (TSA): These are the devices that switch
   the layer 2 payload from a first L2TP session/tunnel on to second
   L2TP session/tunnel.

   First Tunnel: The first L2tp Tunnel to be established at the TSA.

   Second Tunnel: The second L2TP Tunnel to be established at the TSA.

   First Session: The first L2tp Session to be established at the TSA.

   Second Session: The second L2TP Session to be established at the TSA.

   L2TP Control Connection Endpoint (LCCE): An L2TP node that exists at
   either end of an L2TP control connection.  May also be referred to as
   an LAC or LNS, depending on whether tunneled frames are processed at
   the data link (LAC) or network layer (LNS).

   L2TP, as defined in [1], is now referred to as "L2TPv2," while the
   extended version defined in [2] is referred to as "L2TPv3". The
   remainder of this document will refer simply to L2TP in general,


Kelkar, et al.        Expires September 1, 2007                [Page 2]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   unless contrasting specific features of L2TPv2 or L2TPv3, which may
   differ in function.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [10].

1. Introduction

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

   At the TSA, First and Second sessions are two discrete entities.  The
   First session is established in the beginning and then TSA uses the
   negotiated parameters of the First session as a basis to negotiate
   the Second session.  If the Second session fails to negotiate then it
   should be terminated.  Same thing can be said for the tunnel.

     PPP         LAC                     TSA                      LNS
     User                           [LNS      LAC]
     |---- PPP----|                  |         |                    |
     |            |---- PPP/L2TP ----|         |                    |
     |            |                  |-- PPP --|                    |
     |            |                  |         |----- PPP/L2TP -----|
     |            |                  |<----- tunnel switching ----->|
     |            |                  |         |                    |
     |            |<--First tunnel-->|         |<--Second tunnel--->|

           Figure 1:   L2TP tunnel Switching for incoming calls

   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 protocol.  The TSA, based on
   the local policies, determines if the First session should be further
   tunneled.  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 to a corresponding outgoing tunnel.




Kelkar, et al.        Expires September 1, 2007                [Page 3]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


2. L2TPv2 to L2TPv3 switch

   If First and Second tunnels use different versions of L2TP protocol
   at TSA i.e. if it involves a 'version switch', then it must adapt the
   data encapsulation change.


      +------------------------+    +----------------------------+
      | PPP Tunneled Frame     |    | PPP Tunneled Frame         |
      |                        |    |                            |
      +------------------------+    +----------------------------+
      |                        |    | Default L2-Specific        |
      |                        |    | Sublayer                   |
      | L2TPv2 Data Header     |    | (Ref [6] section 4.1)      |
      | over UDP               |    +----------------------------+
      | (Ref [1] section 3.1)  |    | L2TPv3 Data Session        |
      |                        |    | Header over UDP or IP      |
      |                        |    | (Ref [2] section 4.1.1.1   |
      |                        |    |  and 4.1.2.1)              |
      +------------------------+    +----------------------------+
      | L2TPv2 Data Channel    |    | L2TPv3 Data Channel        |
      | (unreliable)           |    | (unreliable)               |
      +------------------------+----+----------------------------+
      | Packet-Switched Network (UDP, IP, FR, MPLS, etc.)        |
      +----------------------------------------------------------+


          Figure 2:   L2TPv2 to L2TPv3 data encapsulation switch

   When PPP frames, which are encapsulated in the L2TPv2 header, are
   received at the TSA and are switched to Second tunnel using L2TPv3,
   then L2TPv2 headers are stripped and PPP frame is encapsulated with
   the L2TPv3 data header followed by the optional Default L2-Specific
   Sublayer and Offset Padding (Ref [6] section 4.2) fields, and
   forwarded over the session.

   The version switch may involve a transport change i.e. L2TPv3-IP to
   L2TPv2-UDP. TSA MUST be able to adapt to such change.

3. AVP Behavior

   An AVP negotiated by the First tunnel/session MUST be handled in four
   ways - it could be relayed, dropped, regenerated, or stacked.  They
   are defined as follows.

   - RELAYED AVP: (also known as pass-through AVP) AVP is forwarded
   transparently if it was negotiated by the First tunnel/session.


Kelkar, et al.        Expires September 1, 2007                [Page 4]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   - DROPPED AVP: AVP is dropped if it was negotiated by the First
   tunnel/session.

   - REGENERATED AVP: AVP negotiated by the First tunnel/session is
   ignored upon receipt.  A new AVP is regenerated for the Second
   tunnel/session based on the local policy at the TSA.  The local
   policy may or may not use the received AVP to regenerate the new
   value.  The regenerated value MAY match with the received AVP value.

   - STACKABLE AVP: Multiple instances of this AVP exist in the incoming
   message, each representing a hop in the tunnel switched path in order
   from first to last.  When a TSA receives it, all the instances of AVP
   are copied as-is for the negotiation of the next hop.  A locally
   generated AVP is appended to the outgoing message.  If no value is
   appropriate then an AVP with a null value, as determined by the AVP
   definition, MUST be appended.  However, If TSA couldn't copy all of
   incoming AVPs then it MUST not copy any one of them and drop all of
   the instances.  If this is an AVP required to establish the tunnel or
   session and TSA cannot copy all of the stacked AVPS, then TSA MUST
   terminate the connection or session as appropriate.

3.1. IETF Vendor AVPs

   This section defines the behavior of AVPs according to the guidelines
   in section 3. It describes the behavior of AVPs defined in [1], [2],
   [3], [4], [5], [6], and [8].  All the future AVP extensions MUST
   define AVP behavior for tunnel switching.

   An optional AVP whose behavior is defined as RELAYED, MUST be RELAYED
   only if the AVP is negotiated by the First tunnel/session.  Hence the
   behavior for such AVP is stated as 'RELAYED if negotiated by the
   first tunnel/session'.

   An optional AVP whose behavior is defined as REGENERATED, could be
   DROPPED from the negotiation of the Second tunnel/session at the
   TSA's discretion.  Hence the behavior for such AVP is stated as
   'REGENERATED or DROPPED'

   In its default behavior TSA needs to be as transparent as possible.
   However, TSA shouldn't prevent local policies to override the default
   behavior and allow regeneration of the AVPs mentioned as
   'REGENERATED'.

   Message Type (All Messages) - MUST be REGENERATED

   Result Code (CDN, StopCCN) - MUST be either RELAYED or REGENERATED
   based on recommendations discussed in section 5.  In case of version


Kelkar, et al.        Expires September 1, 2007                [Page 5]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   switch, if L2TPv3 Result Codes and Error Codes are RELAYED then they
   MUST be translated into general error (Result Code 2, Error Code 0).

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

   Framing Capabilities (SCCRQ, SCCRP) - MUST be REGENERATED.

   Bearer Capabilities (SCCRQ, SCCRP) - MUST be either REGENERATED or
   DROPPED.

   Tie Breaker (SCCRQ) - MUST be either REGENERATED or DROPPED.

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

   Host Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.

   Vendor Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.

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

   Receive Window Size (SCCRQ, SCCRP) - MUST be either REGENERATED or
   DROPPED.

   Challenge (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED.

   Q.931 Cause Code (CDN) - MUST be either RELAYED if negotiated by the
   First session or DROPPED.

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

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

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

   Minimum BPS (OCRQ) - MUST be RELAYED if negotiated by the First
   session.  In case of version switch, TSA should relay it as a Tx
   Minimum Speed AVP (Ref [6])





Kelkar, et al.        Expires September 1, 2007                [Page 6]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   Maximum BPS (OCRQ) - MUST be RELAYED if negotiated by the First
   session.  In case of version switch, TSA should relay it as a Tx
   Maximum Speed AVP (Ref [6])

   Bearer Type (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First
   session.

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

   Called Number (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the
   First session.

   Calling Number (ICRQ) - MUST be RELAYED if negotiated by the First
   session.

   Sub-Address (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First
   session.

   Tx Connect Speed (ICCN, OCCN) - MUST be RELAYED. In case of version
   switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type
   74).

   Physical Channel ID (ICRQ, OCRP) - MUST be either RELAYED if
   negotiated by the First session, REGENERATED, or DROPPED.

   Proxy LCP AVPs (ICCN) - All the Proxy LCP AVPs (Initial Received LCP
   CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be
   either all RELAYED, all REGENERATED or all DROPPED.  If an AVP is
   REGENERATED then it would mean the LCP was renegotiated; whereas,
   RELAYED conveys the fact that it was passed along and was not
   renegotiated.

   Proxy Authentication AVPs (ICCN) - All the Proxy Authentication AVPs
   (Proxy Authen Type, Proxy Authen Name AVP, Proxy Authen Challenge
   Proxy Authen ID and Proxy Authen Response AVP) MUST be either all
   RELAYED, all REGENERATED, or all DROPPED.  If an AVP is REGENERATED
   then it would mean the Authentication was renegotiated; whereas,
   RELAYED conveys the fact that it was passed along and was not
   renegotiated.

   Call Errors (WEN) - MUST be RELAYED.

   ACCM (SLI) - MUST be RELAYED.

   Random Vector (All Messages) - MUST be either REGENERATED or DROPPED.




Kelkar, et al.        Expires September 1, 2007                [Page 7]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   Private Group ID (ICCN) - MUST be RELAYED if negotiated by the First
   session.

   Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED if negotiated by the
   First session.  In case of version switch, TSA should relay it as a
   Rx Connect Speed AVP (Attribute Type 75).

   Sequencing Required (ICCN, OCCN) - MUST be either REGENERATED or
   DROPPED. In case of version switch, TSA should regenerate it as a
   Data Sequencing AVP (Attribute Type 70).

   Rx Minimum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by
   the First session.  In case of version switch, TSA should relay it as
   a Rx Minimum Speed AVP (Ref [6]).

   Rx Maximum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by
   the First session.  In case of version switch, TSA should relay it as
   a Rx Maximum Speed AVP (Ref [6]).

   PPP Disconnect Cause AVP (CDN) (Ref [3])- MUST be either RELAYED if
   negotiated by the First tunnel/session or DROPPED if it's not
   supported.

   Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either
   RELAYED if negotiated by the First tunnel or DROPPED if it's not
   supported.  The value of this AVP could be chosen based on 'PHB Code'
   used (or to be used) on the tunnels, which the TSA is going to be
   switching tunnels to.  TSA need not use same PHB-to-DSCP mappings on
   a First tunnel and Second tunnel.

   Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either
   RELAYED if negotiated by the First session or DROPPED if it's not
   supported.  The value of this AVP could be chosen based on 'PHB Code'
   used (or to be used) on the sessions, which the TSA is going to be
   switching sessions to.  TSA need not use same PHB-to-DSCP mappings on
   a First session and Second session.

   LCP Want Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
   negotiated by the First session or DROPPED if it's not supported.

   LCP Allow Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
   negotiated by the First session or DROPPED if it's not supported.

   Extended Vendor ID AVP (Version 3) (All Messages) - MUST be either
   REGENERATED or DROPPED.




Kelkar, et al.        Expires September 1, 2007                [Page 8]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   Message Digest AVP (Version 3) (All Messages) - MUST be either
   REGENERATED or DROPPED.

   Router Id AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED
   or DROPPED.

   Assigned Control Connection Id AVP (Version 3) (SCCRQ, SCCRP,
   StopCCN) - MUST be either REGENERATED or DROPPED.

   Pseudowire Capabilities List AVP (Version 3) (SCCRQ, SCCRP) - MUST be
   either REGENERATED or DROPPED.

   Local Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN,
   CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED.

   Remote Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP,
   OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED.

   Assigned Cookie AVP (Version 3) (ICRQ, ICRP, OCRQ, OCRP) - MUST be
   either REGENERATED or DROPPED.

   Remote End Id AVP (Version 3) (ICRQ, OCRQ) - MUST be either
   REGENERATED or DROPPED.

   Session Tie Breaker AVP (Version 3) (ICRQ, OCRQ) - MUST be either
   REGENERATED or DROPPED.

   Pseudowire Type AVP (Version 3) (ICRQ, OCRQ) - MUST be either
   REGENERATED or DROPPED.

   L2-specific Sublayer AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP,
   OCCN) - MUST be either REGENERATED or DROPPED.

   Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
   - Data sequencing AVP (Attribute Type 70) is a L2TPV3 AVP equivalent
   to the Sequencing required AVP (Attribute Type 39) in L2TPv2. In
   L2TPv3, any endpoint (LAC or LNS i.e. LCCE) can send the Data
   Sequencing AVP with the value 0 (no sequencing), 1 (sequencing only
   for non-ip packets) or 2 (sequencing for all the packets). In L2TPv2,
   only LAC can send the Sequencing Required AVP that requests the
   sequencing for all the packets.  If data sequencing is enabled on the
   First session, then TSA should enable it on the Second session by
   sending the appropriate AVP (i.e. REGENERATED).  If data sequencing
   is enabled on the First session, then TSA MAY choose (as decided by
   the local policy) not to enable the sequencing on Second session i.e.
   DROPPED. TSA SHOULD not enforce the sequencing but should send the
   data sequencing AVP on the Second session, if it's enabled on the


Kelkar, et al.        Expires September 1, 2007                [Page 9]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   First session.  There is no requirement to have all hops use the
   consistent sequencing configuration.  As always TSA's local policy
   would take precedence over the default behavior of "REGENERATED or
   DROPPED"

   Circuit Status AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN,
   SLI) - MUST be either REGENERATED or DROPPED.

   Preferred Language AVP (Version 3) (SCCRQ, SCCRP) - MUST be either
   REGENERATED or DROPPED.

   Tx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
   - MUST be either RELAYED, REGENERATED or DROPPED.  In case of version
   switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type
   24).  If value is greater than 4 octets, it SHOULD be dropped.

   Rx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
   - MUST be either RELAYED if negotiated by the First session,
   REGENERATED or DROPPED.  In case of version switch, TSA should relay
   it as a Rx Connect Speed AVP (Attribute Type 38).  If value is
   greater than 4 octets, it SHOULD be dropped.

   Offset Size (Version 3) (ICRQ, ICRP, ORCQ, OCRP) (Ref [6]) - MUST be
   either REGENERATED or DROPPED.

   Tx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
   RELAYED, REGENERATED or DROPPED.  In case of version switch, TSA
   should relay it as a Minimum BPS AVP (Attribute Type 16).  If value
   is greater than 4 octets, it SHOULD be dropped.

   Tx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
   RELAYED, REGENERATED or DROPPED.  In case of version switch, TSA
   should relay it as a Maximum BPS AVP (Attribute Type 17).  If value
   is greater than 4 octets, it SHOULD be dropped.

   Rx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
   RELAYED, REGENERATED or DROPPED.  In case of version switch, TSA
   should relay it as a Rx Minimum BPS AVP (Attribute Type 40).  If
   value is greater than 4 octets, it SHOULD be dropped.

   Rx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either
   RELAYED, REGENERATED or DROPPED.  In case of version switch, TSA
   should relay it as a Rx Maximum BPS AVP (Attribute Type 41).  If
   value is greater than 4 octets, it SHOULD be dropped.

   Failover Capability AVP (SCCRQ, SCCRP) (Ref [9]) - MUST be
   REGENERATED based on the TSA's capabilities


Kelkar, et al.        Expires September 1, 2007               [Page 10]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   Tunnel Recovery AVP (SCCRQ) (Ref [9]) - MUST be REGENERATED based on
   failover negotiations with the peer on an individual tunnel.

   Suggested Control Sequence AVP (SCCRP) (Ref [9]) - MUST be
   REGENERATED based on failover negotiations with the peer on an
   individual tunnel.

   Failover Session State AVP (FSQ, FSR) (Ref [9]) - MUST be REGENERATED
   based on failover negotiations with the peer on an individual tunnel.

   TSA ID AVPs (defined in this document) - MUST be STACKED.  The local
   TSA ID AVP is stacked to the incoming set of TSA ID AVPs.

4. Loop Detection

   The Tunnel Switching Aggregator (TSA) ID AVP, Attribute Type 93,
   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 (ICRQ, OCRQ)
   then the TSA MUST check to see if it's 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' 26, and optionally a description
   indicating the loop condition.  A match comparison MUST only be
   performed if TSA has configured non-null TSA ID.

   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 ... (maximum 64 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   TSA ID is a configured value (human readable string) with a maximum
   length of 64 octets.  It is administratively controlled to ensure its
   uniqueness among all the inter-connected LACs, LNSs and TSAs.  If no
   value is configured then the AVP value MUST be of length 0.

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






Kelkar, et al.        Expires September 1, 2007               [Page 11]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


5. CDN Messages and L2TP tunnel Switching

   To identify error conditions explicitly in the multi-TSA environment,
   new error codes are defined.  Existing error codes are not used
   because they might trigger an unwarranted behavior depending upon why
   it was generated.  Error codes are defined as follows:

   Next hop unreachable (Result Code 2, Error Code 10) - TSA MUST
   disconnect the First tunnel/session with this Error Code, if next hop
   is unreachable and no other alternative paths are available as
   determined by the local policy.

   Next hop busy (Result Code 2, Error Code 11) - TSA MUST disconnect
   the First tunnel/session with this Error Code, if next hop
   disconnects the Second tunnel/session with an error code 'TSA Busy'
   or other indications from next hop indicate that it is too busy to
   take more tunnels/sessions and no other alternative paths are
   available as determined by the local policy

   TSA busy (Result Code 2, Error Code 12) - TSA MUST disconnect the
   first tunnel/session with this Error Code, if it is congested or
   temporarily running out of resources.

   In the case of multiple levels of TSAs, error code SHOULD be
   propagated back until it reaches either the original LCCE or an
   intermediate TSA, which has an alternate path.  On the receipt of
   error code, local policy on the LCCE or the intermediate TSA should
   handle the fallback and use it for the congestion recovery design.

6. IANA Considerations

6.1. Control Message Attribute Value Pairs (AVPs)

   This number space is managed by IANA as per section 2.1 of [11].

   A summary of the new AVPs follows:

   Control Message Attribute Value Pairs

         Attribute
         Type        Description
         ---------   ------------------
         93          Tunnel Switching Aggregator ID AVP




Kelkar, et al.        Expires September 1, 2007               [Page 12]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


6.2. Result Code AVP Values

   New L2TP Result Codes appear in section 4 and 5, which need
   assignment by IANA as described in section 2.3 of [11].

          Result Code AVP (Attribute Type 1) Values
          -----------------------------------------
          Defined Result Code values for the CDN message are:
          26 - Loop Detected

          General Error Codes
          10 - Next hop unreachable
          11 - Next hop busy
          12 - TSA busy

7. Security Considerations

   TSA ID AVP could reveal the set of nodes that a given L2TP session is
   traversing in the network.

   If the AVPs described in this document are of concern then AVP
   hiding, described in [1] MAY be used to help mitigate the security
   threat; though it is not widely regarded as cryptographically secure,
   [12] describes a more robust method for securing L2TP in general, and
   should be used to encrypt all L2TP messages.

8. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this



Kelkar, et al.        Expires September 1, 2007               [Page 13]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

9. Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

10. Acknowledgments

   Authors gratefully acknowledge the valuable contributions of: Mark W.
   Townsley, Reinaldo Penno, Ly Loi and Marc Eaton-Brown.  We would like
   to thank Carlos Pignataro for a thorough review.



















Kelkar, et al.        Expires September 1, 2007               [Page 14]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


11. References

11.1. Normative References

   [1]   RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G.
         Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999.

   [2]   RFC 3931, J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
         Protocol (Version 3)", March 2005.

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

   [4]   RFC 3308, P. Calhoun, W. Luo, D. McPherson, K. Peirce, "Layer
         Two Tunneling Protocol (L2TP) Differentiated Services
         Extension", November 2002.

   [5]   RFC 3437, W. Palter, W. Townsley, "Layer-Two Tunneling Protocol
         Extensions for PPP Link Control Protocol Negotiation", December
         2002.

   [6]   C. Pignataro, Ed, "PPP Tunneling Using Layer Two Tunneling
         Protocol Version 3" work in progress, draft-ietf-l2tpext-l2tp-
         ppp-05.txt, November 2006.

   [7]   RFC 1661, W. Simpson, "The Point-to-Point Protocol (PPP)", STD
         51, July 1994.

   [8]   RFC 3301, Y. T'Joens, B. Sales, P. Crivellari, "Layer Two
         Tunneling Protocol (L2TP): ATM access network extensions", June
         2002

   [9]   V. Jain, Ed, "Fail Over extensions for L2TP failover" work in
         progress, draft-ietf-l2tpext-failover-12.txt, February 2007.

   [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

11.2. Informative References

   [11]  BCP0068, Townsley, W., "Layer Two Tunneling Protocol (L2TP)
         Internet Assigned Numbers Authority (IANA) Considerations
         Update" RFC3438, BCP0068, December 2002

   [12]  RFC 3193, B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth,
         "Securing L2TP using IPsec", November 2001



Kelkar, et al.        Expires September 1, 2007               [Page 15]

Internet-Draft      PPP over L2TP Tunnel Switching           March 2007


Author's Addresses

   Mahesh Kelkar
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886
   Email: mkelkar@juniper.net

   Tom Mistretta
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886
   Email: tmistretta@juniper.net

   Paul Howard
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886
   Email: phoward@juniper.net

   Vipin Jain
   Riverstone Networks
   5200 Great America Parkway
   Santa Clara, CA 95054
   Email: vipinietf@yahoo.com
























Kelkar, et al.        Expires September 1, 2007               [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/