One document matched: draft-ietf-l2tpext-sesinfo-01.txt
Differences from draft-ietf-l2tpext-sesinfo-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 15:08:23 |