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]
