PPP Extension Group Nagraj Arunkumar, 3Com
INTERNET DRAFT Manu Kaycee, Paradyne
Expires September 25, 1997 Tim Kwok, Microsoft
Arthur Lin, Cisco Systems
March 25, 1997
Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI
<draft-ietf-pppext-l2tp-aal5-funi-00.txt>
Status of this Memo
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
Layer Two Tunneling Protocol describes a mechanism to tunnel PPP
sessions. The protocol has been designed to be independent of the
media it runs over. The base specification describes how it should
be implemented to run over UDP and IP. This document describes
how the Layer Two Tunneling Protocol MUST be implemented over
ATM (AAL5 and FUNI).
Applicability
This specification is intended for those implementations which desire
to use facilities which are defined for L2TP. These capabilities
require a point-to-point relationship between peers, and are not
Arunkumar, et. al. Expires September 25, 1997 [Page 1]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
designed for multi-point relationships which are available in ATM and
other multi-access environments.
1. Introduction
L2TP is a protocol that makes a PPP session appear at a location
other than the physical point at which it was received. The base
protocol specification illustrates how L2TP may be used in IP
environments. This document specifies how L2TP can be used in an
ATM environment, over AAL5 and/or FUNI.
The format of the AAL5 CPCS-PDU is given below:
AAL5 CPCS-PDU Format
+-------------------------------+
| . |
| . |
| CPCS-PDU Payload |
| up to 2^16 - 1 octets) |
| . |
| . |
+-------------------------------+
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------
The Payload field contains user information up to 2^16 - 1 octets.
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
such that the last 48 octet cell payload created by the SAR sublayer
will have the CPCS-PDU Trailer right justified in the cell.
The CPCS-UU (User-to-User indication) field is used to transparently
transfer CPCS user to user information. The field has no function
under the encapsulation described in this memo and can be set to any
value.
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
64 bits. The Length field indicates the length, in octets, of the
Payload field. The maximum value for the Length field is 65535
octets.
The CRC field protects the entire CPCS-PDU except the CRC field
itself.
Arunkumar, et. al. Expires September 25, 1997 [Page 2]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
The FUNI frame format [4] is as follows:
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
The FUNI Header includes a 10-bit Frame Address (a.k.a. VPI/VCI bits,
a Congestion Notification bit, a Congestion Loss Priority bit, and
four Reserved bits.
The User SDU field contains user information up to 4096 (optionally
up to 64K) octets.
The FCS field protects the entire FUNI PDU except for the FCS field
itself.
2. Encapsulation and Packet Formats
2.1 Encapsulation over AAL5
To run L2TP over AAL5, L2TP packets will be sent as the payload
of AAL5 PDUs. This is sometimes called "VC multiplexing" [2]
or NULL encapsulation.
It is assumed that the Virtual Connections used to transfer L2TP
packets are point-to-point and bidirectional. The Virtual
Circuits themselves may be Permanent Virtual Connections (PVCs) or
Switched Virtual Connections (SVCs).
Arunkumar, et. al. Expires September 25, 1997 [Page 3]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
The actual encapsulation of the L2TP packets will be done via NULL
encapsulation. i.e. the Virtual Connection will be used exclusively
for L2TP packets.
Format for L2TP PDUs
+-------------------------------+ -------
| L2TP header |
| (up to N octets, N < 19 ) |
+-------------------------------+
| . | L2TP packet
| L2TP Payload |
| (up to 2^16 - N octets) |
| . |
+-------------------------------+ -------
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) |
+-------------------------------+
| CPI (1 octet ) |
+-------------------------------+ CPCS-PDU Trailer
| Length (2 octets) |
+-------------------------------|
| CRC (4 octets) |
+-------------------------------+ -------
When using L2TP over PVCs it is assumed that the end stations have
been administratively configured to use the PVCs for L2TP. For
SVCs, a new code point (to be determined) will used as part of SVC
signalling to indicate that the VC will be used for L2TP with NULL
encapsulation. All L2TP packets will contain the I and C bit to
allow multiple tunnels per VC as well as multiple calls per
tunnel.
2.2 Encapsulation over FUNI
To run L2TP over FUNI, L2TP packets will be sent as the User SDU of
FUNI PDUs. This is termed as NULL encapsulation and is similar to
"VC multiplexing", as specified in [2].
Aside from syntactical framing differences between FUNI and AAL5,
all attributes that apply to AAL5 (as discussed in Section 2.1.)
also apply when running L2TP over FUNI.
Arunkumar, et. al. Expires September 25, 1997 [Page 4]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
The corresponding frame format is:
+-------------------------------+
| Flag |
+-------------------------------+---------
| FUNI Header | ^
+-------------------------------+ |
| | |
| | |
| User SDU (PPP Frame) | FUNI PDU
| | |
| | |
+-------------------------------+ |
| FUNI FCS (2 or 4 octets) | v
+-------------------------------+---------
| Flag |
+-------------------------------+
PPP SHALL use VC multiplexing over FUNI. As such, a PPP frame SHALL
constitute the User SDU field and is defined as:
+----------+-------------+---------+
| Protocol | Information | Padding |
| 8/16 bits| * | * |
+----------+-------------+---------+
Each of these fields are specifically defined in [5].
3. MTU Considerations
L2TP requires that the tunnel support a minimum payload of 1500
octets, along with 18 octets of L2TP headers. To carry a MAC frame
of 1518 bytes (such as Ethernet), with the PPP headers of up to 10
octets, and the L2TP header of up to 18 octets, L2TP implementations
over AAL5/FUNI must support a minimum of 1546 octets.
4. Quality of Service Considerations
To provide QoS an implementation MAY choose to open more than
one Virtual Connection between a LAC and LNS. An implementation
MAY also choose to open more than one Tunnel between a LAC and
LNS. If a new tunnel is required, as dictated by some higher layer
and policy, such a tunnel be set up and them mapped onto a new
SVC, or existing PVC (or SVC).
A tunnel is initially created over a VC. A subsequent call to the
LAC may require that the LAC open a new VC to satisfy QoS
requirements of that call. The additional VC is used purely for
data and does not need a second tunnel control channel to be
associated to that tunnel.
Arunkumar, et. al. Expires September 25, 1997 [Page 5]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
A LNS or LAC should be able to indicate the QoS parameters for a
particular call. To do this a new AVP is proposed.
%%% This AVP is to be included in the Call Setup messages? %%%
%%% AVP for QoS parameters here %%%
5. Security Considerations
Security may be administered using one or more of the following:
- PAP/CHAP and PPP encryption
- security attributes, if applicable and provided by the underlying
ATM signalling subsystem
- IP Security protocols between consenting end stations
7. References
[1] Kory Hamzeh, Tim Kolar, et al., "Layer 2 Tunneling Protocol",
Internet draft, December 1996.
[2] Juha Heinanan, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[3] M. Laubach, "Classical IP over ATM", RFC 1577, January '94.
[4] The ATM Forum, "Frame based User-to-Network Interface (FUNI)
Specification v1", September 1995
[5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
Chair's Address
The working group can be contacted via the current chair:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.com
Arunkumar, et. al. Expires September 25, 1997 [Page 6]
Internet Draft L2TP over AAL5 and FUNI March 13, 1997
Author's Address
Questions about this memo can also be directed to:
Nagaraj Arunkumar
3Com Corporation
5400 Bayfront Plaza
Santa Clara, CA 95052
Tel: +1.408.764.5104
Email: nak@3com.com
Manu Kaycee
Paradyne Corporation
100 Shultz Drive
Red Bank, NJ 07701
Tel: +1.908.345.7664
Email: mjk@nj.paradyne.com
Tim Kwok
One Microsoft Way
Microsoft Corporation
Redmond, WA 98052
Tel. +1.206.936.6755
Email: timkwok@microsoft.com
Arthur Lin
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Tel: +1.408.526.8260
Email: alin@cisco.com
Arunkumar, et. al. Expires September 25, 1997 [Page 7]
