Internet Draft

L2TP Working Group                                         William Palter
Request for Comments: DRAFT                                RedBack Networks
Category: Internet Draft
Title: draft-ietf-l2tpext-sesinfo-01.txt
Date: Febuary 2000


                 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.


Abstract

   The Layer 2 Tunneling Protocol (``L2TP'') [1] defines a mechanism for
   tunneling PPP sessions.  The current RFC is lacking a way 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 transverses several L2TP tunnels before it
   is finally terminated (sometimes called "tunnel switching" or
   "Multihop"). 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 from which the PPP session originated.  It may
   be desirable for this information to be provided to the LNS in a
   descriptive format. The current AVPs that provide this type of
   information, such as Framing Type and Bearer Type, are designed 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



Palter                     expires August 2000                   [Page 1]





INTERNET DRAFT                                              Febuary 2000


   session transverses several L2TP tunnels before the PPP session is
   finally terminated (Tunnel Switching or MultiHop). 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 parameters used in negotiating the
   PPP session. They should only be used for logging and debugging
   purposes

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, 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 represents the channel defined in the
      Physical Channel ID AVP, which is defined in the base L2TP
      specification [1].  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  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



Palter                     expires August 2000                   [Page 2]





INTERNET DRAFT                                              Febuary 2000


      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. If there is no appropriate value the
      value 0 MUST be added, as a place holder, so that the ultimate
      terminating LNS can definitively determine the hop count from this
      list.


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

      The LAC Names 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 a list
      of counted strings, with the octet prior to each string indicating
      the length of the string that follows it.


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | length  0      | LAC Name 0 (1-255 octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | length  1      | LAC Name 1 (1-255 octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                        ....                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | length  n      | LAC Name n (1-255 octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Palter                     expires August 2000                   [Page 3]





INTERNET DRAFT                                              Febuary 2000


4. Acknowledgments

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

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 August 2000                   [Page 4]