Suhail Nanji
INTERNET DRAFT Redback Networks, Inc.
Category: Informational
Title: draft-nanji-l2tp-eth-00.txt
Date: June 2000
Ethernet Encapsulation Extensions to Layer Two Tunneling Protocol
<draft-nanji-l2tp-eth-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
nanji-l2tp-eth-00.txt>, and expires December, 2000. Please send
comments to the authors.
Abstract
The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
method for tunneling PPP [2] packets. This document describes an
extension to L2TP which will allows for Ethernet frames to be
transported over a session in an L2TP tunnel. These extensions
provide added functionality, but are optional and preserve
compatibility. Also, the same tunnel SHALL carry both PPP and
Ethernet L2TP sessions if needed.
Nanji [Page1]
INTERNET DRAFT June 2000
1. Introduction
With L2TP it is possible to divorce the location of the initial dial-
up server from the location at which the dial-up protocol connection
is terminated and access to the network provided. However, this is
only possible if PPP is used to access the network. This extension
to L2TP provides for this type of functionality to be provided to
users accessing the network via Ethernet, including bridged Ethernet
frames.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [3].
Ethernet in this document refers to both DIX Ethernet and IEEE 802.3.
It is assumed the receipient of an Ethernet frame has the
capabilities to distinguish between the two different Ethernet
encapsulations. Both Ethernet types MAY be used on the same L2TP
session.
3. Tunnel Establishment
The basic tunnel establishment procedures defined in [1] are
unchanged. The only addition is a new AVP for indicating if this
tunnel will support Ethernet framing.
3.1 Ethernet Framing Capabilities AVP
Ethernet Framing Capabilities
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0| 10 | 2352 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 0x00 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 |0|0|0|0|E|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Redback Networks vendor specific Framing Capabilities AVP within
a Start-Control-Connection-Request (SCCRQ) or Start-Control-
Connection-Reply (SCCRP) indicates the sender of this message can
provide Ethernet framing over L2TP. The vendor code is 2352 and the
Nanji [Page2]
INTERNET DRAFT June 2000
Attribute value is 3. The Value field is a 32-bit quantity, with one
bit defined. If bit E is set, Ethernet framing is supported.
This AVP provides the peer with an indication if Ethernet framing
will be accepted or initiated by the sender. A peer should not
initiate an incoming or outgoing call with a Framing Type AVP
specifying a value not advertised in the Framing Capabilities AVP it
received during control connection establishment. Attempts to do so
will result in the call being rejected.
4. Session Establishment
The basic call establishment procedures defined in [1] are unchanged.
The only addition is a new AVP for indicating if this session will
support Ethernet framing. Currently, Ethernet framing is only
supported for incoming call requests (ICRQ).
4.1 Ethernet Bearer Type AVP
Bearer Type
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0| 10 | 2352 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 E 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Redback Networks vendor specific Bearer Type AVP encodes if the
bearer type for the incoming call is Ethernet. The vendor code is
2352 and the Attribute value is 18. This AVP is optional. The Value
is a 32-bit field indicating if the bearer capability being used by
the incoming call is Ethernet. If set, bit E indicates that the call
is originating from an Ethernet client and the payload packets for
this call will transport Ethernet frames.
5. Ethernet Payload Message Format
The L2TP payload header will be unchanged and as described in [1].
However, instead of carrying a PPP packet, the payload will carry an
Ethernet frame starting from the MAC addresses.
Nanji [Page3]
INTERNET DRAFT June 2000
DIX Ethernet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IEEE 802.3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | DSAP | SSAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CTL | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nanji [Page4]
INTERNET DRAFT June 2000
6. Migration to Standard Attributes
It is intended that the Redback Networks vendor specific attributes
described above will be migrated to standard attributes.
Specifically, the standard Framing Capabilities AVP (SCCRQ, SCCRP)
and Bearer Type AVP (ICRQ) will be extended to use the bits reserved
for future use and the vendor specific attributes will be deprecated.
7. Authentication Considerations
All issues dealing with authenticating the incoming Ethernet client
are beyond the scope of this document.
8. Acknowledgments
Thanks to Bill Palter for his help in reviewing this draft. Copious
amounts of text were stolen from the L2TP INTERNET DRAFT [1].
9. References
[1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", INTERNET
DRAFT, February 1999
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses:
Suhail Nanji <suhail@redback.com>
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134-1362
United States of America
Nanji [Page5]