PPP Working Group William Palter Request for Comments: DRAFT RedBack Networks Category: Internet Draft Title: draft-ietf-l2tpext-sesinfo-00.txt Date: October 1999 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]