Internet-Draft Danny McPherson
Ravi Bail Bhat
Andy Koscinski
Chi Fai Ho
Amber Networks
draft-mcpherson-l2tp-es-01.txt June 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 Topology 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. Acknowledgements
9. References
10. 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) 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 Topology 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 packet structure is modified
to carry any protocol (Note: The current specification identifies
support only for PPP frames). An encapsulation protocol with both
data and control messages is carried over L2TP protocol.
+---------------------------------------+
| L2TP Payload |
| (Any Control/Data |
| Message Any Protocol) |
+---------------------------------------+ +-----------------------+
| L2TP Data Messages | | L2TP Control Messages |
+---------------------------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------------------------+
The protcols running on top of L2TP will use the services of L2TP
control protocol to open/close and manage L2TP tunnel and sessions.
4. Proposed Protocol Operation
Encapsulation Services (ES) enable an IP network to support emulation
of connection-oriented networks such as 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". For
Encapsulation Services, 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 between
a pair of L2TP peers. 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 an 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.
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
encapsulation potocol data between one another.
4.1. Service Type AVP Format
The Service Type AVP MUST be present in SCCRQ and SCCRP message.
If the tunnel is torn down due to unacceptable Service Type
information (including no information) from the peer, the Service
Type AVP MUST be present in the StopCCN as well. 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". The L2TP peer is indicating that
resources adequate for 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 originator. Such StopCCN message
MUST include the Service Type AVP as provided in the message that
caused the StopCCN.
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 Service Type string.
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 for Encapsulation Services 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 [RFC2661].
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. Acknowledgements
The authors would like to acknowledge Nishit Vasavada for providing
a considerable amount of valuable input to this document.
9. 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".
10. 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