Internet-Draft Danny McPherson
Ravi Bail Bhat
Andy Koscinski
Chi Fai Ho
Amber Networks
draft-mcpherson-l2tp-es-00.txt May 2000
L2TP Circuit Emulation Services Extension
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism
for tunneling PPP sessions. This document proposes mechanisms by
which the L2TP tunneling scheme can be used to provide circuit
emulation support for layer 2 circuits (i.e. Frame Relay or ATM), as
well as TDM circuits (i.e. DS1 or DS3). L2TP is used to provide
tunneling support and each circuit is encapsulated over a session
inside the Tunnel.
An Encapsulation Services Protocol [RefESP] is used on top of the
individual L2TP sessions to support the circuit emulation of layer
2 VCs or TDM circuits. The purpose of this document is to explain
the L2TP modifications done to facilitate support of circuit
emulation services, as well as to define the additional AVPs that can
be used to provide the service.
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction
2. Topology Model
2.1 Modified L2TP Topooofy Model
3. Protocol Overview
4. Proposed Protocol Operation
4.1 Service Type AVP Format
4.2 Proposed Sub-Address in ICRQ
5. Quality of Service Considerations
6. Security Considerations
7. Intellectual Property Considerations
8. References
9. Authors' Addresses
1. Introduction
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism
for tunneling PPP sessions. This document describes mechanisms by
which L2TP tunneling scheme can be used to provide circuit emulation
support for layer 2 circuits (i.e. Frame Relay or ATM), as well as
TDM circuits (i.e. DS1 or DS3). L2TP is used to provide tunneling
support and each circuit is encapsulated over a session inside the
Tunnel.
An Encapsulation Services Protocol [RefESP] is used on top of the
individual L2TP sessions to support the circuit emulation of
layer 2 Virtual Circuits or TDM circuits. The purpose of this
document is to explain the L2TP modifications done to facilitate
support of circuit emulation services, as well as to define the
additional AVPs required to provide the service.
2. Topology Model
The current L2TP model assumes a client/server architecture between
the LAC and LNS. To support encapsulations services, a symmetric
LAC-to-LAC model is proposed. In this model, a tunnel (with one or
more sessions sessions) can be established between two LACs.
A tunnel is setup for a particular service or set of services (e.g.
FR_GOLD) between a pair of LACs that support circuit emulation
services. The Service Type is sent to the peer LAC via a newly
defined vendor- specific AVP. Then for each connection within the
service group (e.g. FR_GOLD), a session is initiated (possible from
either side). The connection identifiers for the two legs of the
connection (e.g. the Frame Relay interface and the Frame-Relay DLCI)
are sent in the Sub-Address AVP.
2.1. Modified L2TP Topolgy Model (LAC/LAC)
The following diagram depicts a typical L2TP LAC/LAC scenario. The
goal is to tunnel lower-layer (layer 1 or layer 2) frames from the
one LAC to the another LAC.
FR-------+ +-------------+ +---- FR
|---- | | ----|
LAC1 ---| Internet |--- LAC2
|---- | | ----|
TDM------+ +-------------+ +---- TDM
|
|
LAC3
| |
---+ +---
| |
| |
FR TDM
3. Protocol Overview
As shown in the figure below, the L2TP protocol structure is modified
to carry any protocol (Note: The current specification only
identifies support for PPP frames). An encapsulation protocol with
both data and control messages is carried over L2TP protocol.
+-----------------------+
+-------------------+ | any protocol control |
| any payload | | messages |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
4. Proposed Protocol Operation
Encapsulation Services (ES) enable an IP network to support emulation
of connection-oriented networks like FR and ATM, as well as TDM
circuit emulation. ES supports different Emulation Types and also
supports multiple service profiles. The Emulation Type and the
Service Type are represented by an optional AVP "Service Type". The
AVP MUST be present in both SCCRQ and SCCRP messages and MUST match
one another, otherwise the tunnel is dropped.
At least one L2TP tunnel is opened for every Emulation Type. Multiple
tunnels may be opened for each Emulation Type if different Service
Types are needed. Each circuit (e.g. DLCI in FR) is mapped into a
L2TP session and carried transparently to the other end. During the
session request, the endpoint connection identifiers are transported
in the Sub-Address AVP.
Once the L2TP session is established, the upper layer encapsulation
protocol MAY exchange additional information to complete the circuit
emulation establishment. After that, the LACs start to transmit data
between one another.
4.1. Service Type AVP Format
The Service Type AVP MUST be present in SCCRQ and SCCRP message. This
AVP is used to inform the tunnel peer that a specific Service Type
(e.g. FR_GOLD) is used.
Vendor ID = 4741 Attribute Type = 1
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| Length | 4741 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |Service Type (arbitrary length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is encoded as a Vendor ID of 4741, which reflects Amber
Networks, the initial developer of this specification. The Vendor ID
SHOULD be changed to "0" and an official attribute value chosen, if
this specification advances on the standard tracks. The Attribute
Type is the 16 bit quantity "1". This AVP MAY be hidden and is
mandatory (mandatory bit = 1). The L2TP peer is indicating that
resources adequate to the Service Type identified by the AVP are
required.
In the event that the peer does not accept the requested Service
Type, a stopCCN is returned to the peer. Such stopCCN message will
include the Service Type AVP as provided in the message that caused
the stopCCN.
4.2. Proposed Sub-Address in ICRQ
The Sub-Address AVP, Attribute Type 23, encodes additional connection
identifier information.
The Attribute Value field for this AVP has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address is an opaque sequence of octets transmitted
transparently by the network. The tunnel end points MUST, a priori,
understand the meaning of the value in this AVP.
The general format of the information in this AVP is:
1. Calling party Sub-Address (iterations of: InfoType, Length,
Connection Information, e.g. interface and DLCI for FR);
2. Called party Sub-Address (iterations of: InfoType, Length,
Connection Information, e.g. interface and DLCI for FR);
This AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this
AVP MUST be set to 1. The Length (before hiding) of this AVP is 6
octets plus the length of the Sub-Address.
5. Quality of Service Considerations
Quality of Service (QoS) is a necessity for circuit emulation
applications. The QoS mechanisms such as those proposed for L2TP in
[L2TP-DS] and [L2TP-MPLS] should be considered. Additional
discussion of this topic is beyond the scope of this document.
6. Security Considerations
This document does not introduce security considerations beyond those
listed in [RFC1661].
7. Intellectual Property Considerations
Amber Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Amber Networks, Amber
intends to disclose those patents and license them on reasonable and
non-discriminatory terms.
8. References
[RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall,
G. Zorn, B. Palter, "Layer Two Tunneling Protocol
(L2TP)", RFC 2661, August 1999.
[RefESP] McPherson, D., et al., "Encapsulation Services
Protocol (ESP)", "Work in Progress".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[L2TP-DS] Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol
"L2TP" IP Diferentiated Services Extension", "Work in
Progress".
[L2TP-MPLS] Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol
"L2TP" Multi-Protocol Label Switching Extension",
"Work in Progress".
9. Authors' Addresses
Danny McPherson
Amber Networks
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.486.6336
Email: danny@ambernetworks.com
Ravi Bail Bhat
Amber Networks
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.845.5597
Email: rbhat@ambernetworks.com
Andy Koscinski
Amber Networks
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.845.5536
Email: andyk@ambernetworks.com
Chi Fai Ho
Amber Networks
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.845.5547
Email: ho@ambernetworks.com