[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
Expires: September 2005                                       P. Howard
                                                        Juniper Networks
                                                                 V. Jain
                                                     Riverstone Networks
                                                          March 17, 2005



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


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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.

Copyright Notice

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




Kelkar, et al.        Expires September 17, 2005               [Page 1]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


Abstract

   PPP 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 LNS. 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........................................3
   3. AVP Behavior...................................................4
      3.1. IETF Vendor AVPs..........................................5
   4. Loop Detection.................................................9
   5. CDN Messages and L2TP tunnel Switching........................10
   6. IANA Considerations...........................................10
   7. Security Considerations.......................................11
   8. Acknowledgments...............................................11
   9. References....................................................12
      9.1. Normative References.....................................12
      9.2. Informative References...................................12
   Author's Addresses...............................................13
   Intellectual Property Statement..................................13
   Disclaimer of Validity...........................................14
   Copyright Statement..............................................14
   Acknowledgment...................................................14

Terminology

   Tunnel Switching Aggregator (TSA): These are the devices that switch
   the layer 2 payload on an incoming L2TP session/tunnel on to another
   L2TP session/tunnel. TSA functions as an LNS for the inbound tunnel
   and as a LAC for the outbound tunnel.

   Inbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LNS.

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

   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 17, 2005               [Page 2]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   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 [RFC 2119].

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
   LNS that is possibly unknown to the first LAC. It does so by re-
   tunneling the PPP session within another L2TP tunnel to a different
   LNS. The knowledge of whether to switch a PPP session to another L2TP
   tunnel can be static or dynamic (for example, during PPP session
   establishment).

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

                     Figure 1:   L2TP tunnel Switching

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

2. L2TPv2 to L2TPv3 switch

   If inbound and outbound 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.






Kelkar, et al.        Expires September 17, 2005               [Page 3]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005



      +------------------------+    +----------------------------+
      | PPP Tunneled Frame     |    | PPP Tunneled Frame         |
      |                        |    |                            |
      +------------------------+    +----------------------------+
      |                        |    | PPP 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 outbound tunnel using L2TPv3,
   then L2TPv2 headers are stripped and PPP frame is encapsulated with
   the PPP sublayer followed by the L2TPv3 data header 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 incoming AVP MUST be either 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 present in the incoming message.

   - DROPPED AVP: AVP is dropped if it was present in the incoming
   message. All the L2TPv3 only AVPs are dropped when switched onto
   L2TPv2 tunnel.

   - REGENERATED AVP: AVP in the inbound message is ignored upon
   receipt. A new AVP is regenerated for the outbound message based on
   the local policy at the TSA. The local policy may or may not use the


Kelkar, et al.        Expires September 17, 2005               [Page 4]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   received AVP to regenerate the new value. The regenerated value may
   or may not 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 to the next hop. A locally generated AVP is appended
   to the outbound 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.

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], and [5]. 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 exists in the inbound message. Hence the behavior for
   such AVP is stated as 'RELAYED if present in the inbound message'.

   An optional AVP whose behavior is defined as REGENERATED, could be
   DROPPED from the outbound message at the TSA's discretion. Hence the
   behavior for such AVP is stated as 'REGENERATED or DROPPED'

   Message Type (All Messages) - MUST be REGENERATED

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

   Result Code (CDN, StopCCN) - MUST be either RELAYED or REGENERATED
   based on recommendations discussed in section 5. In case of version
   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 inbound and outbound 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.



Kelkar, et al.        Expires September 17, 2005               [Page 5]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


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

   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.

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

   Q.931 Cause Code (CDN) - MUST be either RELAYED if present in the
   inbound message 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.

   Maximum BPS (OCRQ) - MUST be RELAYED.

   Bearer Type (ICRQ, OCRQ) - MUST be RELAYED if present in the inbound
   message.

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

   Called Number (ICRQ, OCRQ) - MUST be RELAYED if present in the
   inbound message.

   Calling Number (ICRQ) - MUST be RELAYED if present in the inbound
   message.

   Sub-Address (ICRQ, OCRQ) - MUST be RELAYED if present in the inbound
   message.



Kelkar, et al.        Expires September 17, 2005               [Page 6]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


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

   Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED if present in the
   inbound message. In case of version switch, TSA should relay it as a
   Rx Connect Speed AVP (Attribute Type 75).

   Physical Channel ID (ICRQ, OCRP) - MUST be either RELAYED if present
   in the inbound message, REGENERATED, or DROPPED.

   Private Group ID (ICCN) - MUST be RELAYED if present in the inbound
   message.

   Sequencing Required (ICCN, OCCN) - MUST be either 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.

   PPP Disconnect Cause AVP (CDN) (Ref [3])- MUST be either RELAYED if
   present in the inbound message or DROPPED if it's not supported.

   LCP Want Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
   present in the inbound message or DROPPED if it's not supported.

   LCP Allow Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if
   present in the inbound message or DROPPED if it's not supported.

   Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either
   RELAYED if present in the inbound message or DROPPED if it's not


Kelkar, et al.        Expires September 17, 2005               [Page 7]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   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 sessions to. TSA need not use same PHB-to-DSCP mappings on
   an incoming tunnel and outgoing tunnel.

   Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either
   RELAYED if present in the inbound message 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 sessions to. TSA need not use same PHB-to-DSCP mappings on
   an incoming tunnel and outgoing tunnel.

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

   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.


Kelkar, et al.        Expires September 17, 2005               [Page 8]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
   - MUST be either 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 present in the inbound message, 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.

   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 TSA ID AVP, Attribute Type TBD, could be used to detect if a
   session is looping in an L2TP tunnel switched network. This AVP MUST
   be STACKED.

   If this AVP was received in an incoming control packet (ICRQ, OCRQ)
   then the TSA MUST check to see if its own TSA Id (a configured value)
   is present in the stack of incoming TSA ID AVPs. Upon finding a
   match, the TSA MUST respond with a CDN carrying a Result Code
   indicating 'Loop Detected' TBD, and optionally a description
   indicating the loop condition.

   The Attribute Value field for this AVP has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   TSA Id ... (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


Kelkar, et al.        Expires September 17, 2005               [Page 9]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   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.

5. CDN Messages and L2TP tunnel Switching

   To identify the error conditions explicitly in tunnel switching
   setup, new set 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:

   Upstream unreachable (Result Code 2, Error Code TBD) - TSA MUST
   generate a CDN message with this Error Code for the LAC, if upstream
   LNS is unreachable and no other alternative paths are available as
   determined by the local policy.

   Upstream busy (Result Code 2, Error Code TBD) - TSA MUST generate a
   CDN message with this Error Code for the LAC, if upstream LNS
   disconnects the outgoing call with an error code 'TSA Busy' or other
   indications from upstream indicates the upstream is too busy to take
   more sessions and no other alternative paths are available as
   determined by the local policy

   TSA busy (Result Code 2, Error Code TBD) - TSA MUST generate a CDN
   message with this Error Code for the LAC, if it is congested or
   temporarily running out of resources.

   The TSA MUST generate a CDN with an error code for the LAC,
   indicating the failure to establish the call. In the case of multiple
   levels of TSAs, this error code needs to be propagated back until it
   reaches either the original LAC or an intermediate TSA, which has an
   alternate path. On the receipt of these error codes, local policy on
   the LAC or the intermediate TSA should handle the fallback and use it
   for the congestion recovery design.

6. IANA Considerations

   This document requires following parameters to be assigned through
   IETF Consensus [RFC 2434] as indicated in Section 5 of [1]. These
   are:

   AVP - Loop Detection AVP (Section 4)

   Result Code - Loop Detection (Section 4)



Kelkar, et al.        Expires September 17, 2005              [Page 10]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   Error Codes - Upstream unreachable, Upstream busy and TSA busy
   (Section 5).

7. Security Considerations

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

   AVP hiding, described in [1] MUST be either used to help mitigate
   this, though it is not widely regarded as cryptographically secure.
   [RFC 3193] describes a more robust method for securing L2TP in
   general, and should be used to encrypt all L2TP messages if access to
   the information sent within the AVPs described in this document is of
   concern.

8. Acknowledgments

   Authors gratefully acknowledge the valuable contributions of: Mark W.
   Townsley, Reinaldo Penno, Ly Loi and Marc Eaton-Brown.






























Kelkar, et al.        Expires September 17, 2005              [Page 11]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


9. References

9.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]   J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol
         (Version 3)", draft-ietf-l2tpext-l2tp-base-15.txt, December
         2004.

   [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]   J. Lau, M. Townsley, A. Valencia, G. Zorn, M. Verma, I. Goyret,
         G. Pall, A. Rubens, B. Palter, "PPP Tunneling Using Layer Two
         Tunneling Protocol" work in progress, draft-ietf-l2tpext-l2tp-
         ppp-01.txt, November 2001.

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

9.2. Informative References

   [8]   L. Martini, M. Townsley, C. Metz, T. Nadeau, M. Duckett, V.
         Radoaca, "Pseudo Wire Switching" work in progress, draft-
         martini-pwe3-pw-switching-01.txt, October 2004.














Kelkar, et al.        Expires September 17, 2005              [Page 12]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


Author's Addresses

   Mahesh Kelkar
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886

   Phone: +1 978 589 0535
   Email: mkelkar@juniper.net

   Tom Mistretta
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886

   Phone: +1 978 589 0290
   Email: tmistretta@juniper.net

   Paul Howard
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886

   Phone: +1 978 589 0368
   Email: phoward@juniper.net

   Vipin Jain
   Riverstone Networks
   5200 Great America Parkway
   Santa Clara, CA 95054

   Phone: +1 408 878 0464
   Email: vipin@riverstonenet.com

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


Kelkar, et al.        Expires September 17, 2005              [Page 13]


Internet-Draft      PPP over L2TP Tunnel Switching           March 2005


   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   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 MUST be either required to
   implement this standard.  Please address the information to the IETF
   at ietf-ipr@ietf.org.  By submitting this Internet-Draft, I certify
   that any applicable patent or other IPR claims of which I am aware
   have been disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















Kelkar, et al.        Expires September 17, 2005              [Page 14]


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