Network Working Group Nishit Vasavada
INTERNET DRAFT Amber Networks, Inc.
Jim Boyle
Level 3 Communications, LLC.
Chris Garner
Qwest Communications
Serge Maskalik
iVMG, Inc.
Vijay Gill
Metromedia Fiber Network, Inc.
February 2001
Frame Relay Service Type for L2TP
<draft-vasavada-l2tpext-fr-svctype-00.txt>
1. 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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
method for tunneling PPP [2] packets. In accordance with the L2TP
Service Type specification [3], this document provides a solution
for transporting Frame Relay (FR) [4] over a session in an L2TP
tunnel.
3. 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 RFC 2119 [5].
4. Introduction
The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
method for tunneling PPP [2] packets. The L2TP Service Type [3]
Vasavada, et al. [Page 1]
INTERNET DRAFT February 2001
allows layer 1 and layer 2 traffic to be tunneled through an L2TP
tunnel.
This document presents a solution to carry the ever popular Frame
Relay circuit traffic over the IP network through the features
offered by L2TP and the Service Type attribute.
It talks about the use of [3] for setting up an L2TP tunnel and
session containing FR traffic, and the signaling of some of the
Frame Relay parameters.
5. FR Service Type
A FR Service Type value of [TBD] MUST be used. The encoding of the
Service Type AVP remains as specified in [3].
6. Tunnel Establishment
The basic tunnel establishment procedures defined in [1] and [3] are
unchanged. The FR Service Type value [TBD] MUST be included in the
Service Capabilities List AVP.
7. Session Establishment
The basic call establishment procedures defined in [1] and [3] remain
unchanged. The FR Service Type value [TBD] MUST be used in the
Service Type AVP of an ICRQ or OCRQ.
7.1. Use of the Sub-Address AVP
As specified in [1], the Sub-Address AVP, Attribute Type 23, is
included in ICRQ or OCRQ and is used to encode additional dialing
information. For the purpose of this specification, the Sub-Address
AVP will be used to encode the source and destination DLCI numbers,
and interface information.
Additional non-addressing information is discussed in the following
sections.
The Sub-Address AVP is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The attribute value may be a simple ASCII string. For example, a
source interface serial 1/1 and DLCI 100, and a destination interface
serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI
100, serial 1/1 DLCI 200". The format of the information contained
Vasavada, et al. [Page 2]
INTERNET DRAFT February 2001
in this AVP should be agreed on by the administrators at the two L2TP
peers.
When employing the Sub-Address AVP for this purpose, the AVP is
mandatory (the M-bit MUST be set to 1). The AVP MAY be hidden (the
H-bit set to 0 or 1).
7.2. FR Payload Message Format
The L2TP payload header format defined in [1] remains unchanged while
carrying data for a Frame Relay circuit. Entire Frame Relay PDU
will be carried, subject to the following requirements:
When transporting FR frames over an L2TP session the following rules
MUST be followed:
o All the Frame Relay packets will be preceded by a four byte code
[TBD] in the L2TP payload packet. This code will allow L2TP to
de-multiplex if additional functionality has to be added in future
for signaling (please see the signaling and LMI sections).
o The beginning and ending FR 'Flag' fields (one octet each) MUST be
removed from the FR frame before it is encapsulated as L2TP
payload. The destination LAC/LNS MUST insert new flags when
reconstructing the FR frame for transmission to the FRAD.
o The FCS field MUST be removed from the FR frame before it is
carried in L2TP It MUST be recalculated at the other end. This
does create a potential problem since L2TP does not offer checksum,
and UDP checksum is optional. Work is needed in this area to
guarantee integrity of the packet on the remote side.
The encapsulated Frame Relay packet looks like this:
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Four byte code [TBD] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FR Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FR Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasavada, et al. [Page 3]
INTERNET DRAFT February 2001
As is true for the PPP traffic carried by L2TP, the frame size should
consider the MTU and the additional headers to avoid IP
fragmentation.
7.3. FR Local Management Interface (LMI)
This draft does not discuss the LMI implications. Future work is
necessary in this area.
8. Effects on Standard AVPs
If FR frames are being tunneled in accordance with this document,
then the following Call Management AVPs MAY be ignored:
Bearer Type
Framing Type
Called Number
Calling Number
Initial Received LCP CONFREQ
Last Sent LCP CONFREQ
Last Received LCP CONFREQ
Proxy Authen Type
Proxy Authen Name
Proxy Authen Challenge
Proxy Authen ID
Proxy Authen Response
ACCM
9. Future work
This section provides a list of things we need work on:
o Signaling: The interface and DLCI information is conveyed through
L2TP control packets. However, the frame parameters such as CIR,
Be, and Bc related information is not covered.
o LMI through the network
o Data integrity (as mentioned in FR Payload Message Format section,
currently there is no way to verify the data integrity due to
lack of FR FCS, L2TP checksum, and optional UDP checksum.
10. Security Considerations
All the underlying L2TP Security considerations remain, though no
'new' ones are introduced?
11. IANA Considerations
To be completed.
12. Acknowledgments
Many thanks to Danny McPherson, Chi Fai Ho and Himansu Sahu for
their help in reviewing this draft.
Vasavada, et al. [Page 4]
INTERNET DRAFT February 2001
13. References
[1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC
2661, February 1999.
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[3] McPherson D., Nanji S., "L2TP Service Type", "Work in
Progress", August 2000.
[4] Frame Relay, ANSI T1.618
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
14. Authors' Addresses
Nishit Vasavada
Amber Networks, Inc.
48664 Milmont Drive
Fremont, CA 94538
Phone: +1 510.683.8698
Email: nishit@ambernetworks.com
Jim Boyle
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO 80021
Phone: +1 720.888.1192
Email: jboyle@level3.net
Serge Maskalik
iVMG, Inc.
1020 Rincon Circle
San Jose, CA 95131
Phone: +1 408.468.0480
Email: serge@ivmg.net
Chris Garner
Qwest Communications
950 Seventeenth Street, 21 Floor
Denver, CO 80202
Email: cgarner@qwest.net
Vijay Gill
Metromedia Fiber Network, Inc.
8075 Leesburg Pike
Vienna, VA 22182
Phone: +1 410.262.0660
Email: vgill@mfnx.net
Vasavada, et al. [Page 5]