One document matched: draft-ietf-l2tpext-sesinfo-00.txt

                 L2TP Session Information (``SESINFO'')

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``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.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

Abstract

   The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for
   tunneling PPP sessions.  The current RFC is lacking mechanisms for
   the LAC to provide the LNS with data about the PPP session which can
   be useful for accounting and debugging purposes. This is especially a
   problem when the session transverse several L2TP tunnels before it is
   finally terminated. This draft provides additional AVPs that MAY BE
   used to provide port type and port identication information to the
   terminating LNS, for accounting and debugging use.

1. Introduction

   L2TP [1] defines a general purpose mechanism for tunneling PPP over
   various media.  By design, it insulates L2TP operation from the
   details of the media over which the PPP session originated.  There
   are uses where it may be desirable for this information to be
   provided to the LNS in a descriptive format. The current AVP that
   provide this type of information are designed to be used to allow the
   LNS to tailor the PPP options it uses for the media the session is
   running over.  This is especially a problem when the session
   transverses several L2TP tunnels before it is finally terminated.

Palter                     expires March 2000                    [Page 1]

INTERNET DRAFT                                              October 1999

   This draft provides additional AVPs that MAY BE used to provide port
   type and port  identification information to the terminating LNS, for
   accounting and debugging use.

    None of the following AVPs should have any effect on either the
   functioning of the tunnel or the functioning of the PPP session.

2. AVPs

   All of the AVPs are valid in the ICRQ message, and none of them
   should be marked Mandatory.

   2.1 Port Type List

      The Port Type List AVP is  encoded as Vendor ID 2352, and the
      Attribute is the 16-bit quantity 44 (the ID 2352 reflects RedBack
      Networks, the initial developer of this specification, and it
      SHOULD be changed to 0 and an official Attribute value chosen if
      this specification advances on a standards track).  The Value is
      a list of Port Types, using the same values that are used in
      RADIUS [2][3]. The first port type represent the channel defined
      in the Physical Channel ID AVP. All the other port types are
      optional and represent the channel defined in the corresponding
      position of the Virtual Channel ID AVP (defined below). The number
      of entries in this MUST BE one more than then the number of
      entries in the Virtual Channel ID AVP.

      Vendor ID = 2352
      Attribute = 44

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Port Type 0 ("Physical")     | Port Type 1 ("Virtual")       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             ....              | Port Type n ("Virtual")       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.2  Virtual Channel ID List

      The Virtual Channel ID List AVP  is  encoded as Vendor ID 2352,
      and the Attribute is the 16-bit quantity 42 (the ID 2352 reflects
      RedBack Networks, the initial developer of this specification, and
      it SHOULD be changed to 0 and an official Attribute value chosen
      if this specification advances on a standards track).  The Value
      is  a list of four octet values, representing the Channel IDs of
      all the virtual channels that the session has passed thru. Each
      time an LNS forwards a PPP session onto another LNS another value
      should be added to this list.

Palter                     expires March 2000                    [Page 2]

INTERNET DRAFT                                              October 1999

      Vendor ID = 2352
      Attribute = 42

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Virtual Channel ID 1                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            ....                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Virtual Channel ID n                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   2.3  First LAC Name

      The First LAC Name AVP  is  encoded as Vendor ID 2352, and the
      Attribute is the 16-bit quantity 46 (the ID 2352 reflects RedBack
      Networks, the initial developer of this specification, and it
      SHOULD be changed to 0 and an official Attribute value chosen if
      this specification advances on a standards track).  The Value is
      an arbitrary number of octets, and is the name of the LAC which
      the session originated. A device that is taking in a session on
      one tunnel, and then tunneling it again to another LNS should add
      this AVP, if it does not exist, with the name of its peer on the
      tunnel it is acting as an LNS on.

      Vendor ID = 2352
      Attribute = 46

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        LAC Name  (Arbitrary length)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Acknowledgments

   Thanks to W. Mark Townsley, of Cisco Systems and Suhail Nanji of
   Redback Networks for help in creating, and reviewing this draft.

Palter                     expires March 2000                    [Page 3]

INTERNET DRAFT                                              October 1999

5. Contacts

   William Palter
   RedBack Networks
   1389 Moffett Park Drive
   Sunnyvale, CA 94089
   palter.ietf@zev.net

6. References

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

   [2] C. Rigney, A. Rubens, W. Simpson, S. Willens
   ``Remote Authentication Dial In User Service(RADIUS)'', RFC2058, January
1997
   [3] C. Rigney, ``RADIUS Accounting'', RFC2059, January 1997

Palter                     expires March 2000                    [Page 4]