L2TPEXT Working Group Vipin Rawat
INTERNET DRAFT Cisco Systems, Inc.
Category: Internet Draft Rene TioA new Request for Comments is now available in online RFC libraries.
RFC 3070
Title: draft-ietf-l2tpext-fr-00.txt Redback Networks, Inc.
Date: July 2000 Rohit Verma
Deloitte Consulting Layer Two Tunneling Protocol (L2TP) over Frame
Relay
<draft-ietf-l2tpext-fr-00.txt>
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
Author(s): V. Rawat, R. Tio, S. Nanji, R. Verma
Status: Standards Track
Date: February 2001
Mailbox: vrawat@oni.com, tor@redback.com, rverma@dc.com,
suhail@redback.com
Pages: 7
Characters: 12940
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-l2tpext-fr-01.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3070.txt
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel PPP
Point-to-Point (PPP) sessions. The protocol has been designed to be
independent of the media it runs over. The base
Rawat, Tio, Verma expires January 2001 [Page1] specification
describes how it should be implemented to run over UDP the User Datagram
Protocol (UDP) and IP. the Internet Protocol (IP). This document
describes how the Layer
Two Tunneling Protocol MUST be L2TP is implemented over Frame Relay PVCs Permanent Virtual
Circuits (PVCs) and SVCs.
Applicability Switched Virtual Circuits (SVCs).
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 designed for multi-point
relationships which document is available in Frame Relay and other
NBMA environments.
1.0 Introduction
L2TP [1] defines a general purpose mechanism for tunneling
PPP over various media. By design, it insulates L2TP
operation from the details product of the media over which it
operates. The base protocol specification illustrates how
L2TP may be used in IP environments. This draft specifies
the encapsulation Layer Two Tunneling Protocol
Extensions Working Group of L2TP over native Frame Relay and
addresses relevant issues.
2.0 Conventions
The following language conventions are used in the items
of specification in this document:
o MUST, SHALL, or MANDATORY -- IETF.
This item is an
absolute requirement of the specification.
o SHOULD or RECOMMEND -- now a Proposed Standard Protocol.
This item should generally
be followed document specifies an Internet standards track protocol for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional
the Internet community, and
may be followed or ignored according requests discussion and suggestions
for improvements. Please refer to the needs of
the implementor.
3.0 Problem Space Overview
In this section we describe in high level terms the scope current edition of the problem being addressed.
Rawat, Tio, Verma expires January 2001 [Page2]
Topology:
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+ LANs
| ISDN | | Cloud | |
+------+ +---------------+ |
L2TP Access Concentrator (LAC) is a device attached to
"Internet Official Protocol Standards" (STD 1) for the
switched network fabric (e.g. PSTN or ISDN) or co-located
with a PPP end system capable
standardization state and status of handling the L2TP this protocol. The LAC need only implement the media over
which L2TP is to operate to pass traffic to one or more
LNS's. It may tunnel any protocol carried within PPP.
L2TP Network Server (LNS) operates on any platform capable Distribution
of PPP termination. The LNS handles the server side of
the L2TP protocol. L2TP is connection-oriented. The LNS
and LAC maintain state for each user that is attached to
an LAC. A session this memo is created when an end-to-end PPP
connection unlimited.
This announcement is attempted between a user and the LNS. The
datagrams related to a session are sent over the tunnel
between the LAC and LNS. A tunnel is defined by an LNS-
LAC pair. The tunnel carries PPP datagrams between to the
LAC IETF list and the LNS.
L2TP protocol operates at a level above the particular
media over which it is carried. However, some details of
its connection RFC-DIST list.
Requests to media are required be added to permit
interoperable implementations. L2TP over IP/UDP is
described in or deleted from the base draft [1]. Issues related to L2TP
over Frame Relay are addressed in later sections of this
draft.
4.0 Encapsulation and Packet Format
L2TP MUST IETF distribution list
should be able sent to share a Frame Relay virtual circuit
(VC) with other protocols carried over the same VC. The
Frame Relay header format for data packet needs IETF-REQUEST@IETF.ORG. Requests to be
defined
added to identify the protocol being carried in the
packets. The Frame Relay network MAY NOT understand these
formats.
All protocols over this circuit MUST encapsulate their
packets within a Q.922 frame. Additionally, frames MUST
contain information necessary to identify the protocol
carried within the frame relay Protocol Data Unit (PDU),
thus allowing or deleted from the receiver RFC-DIST distribution list should
be sent to properly process the
Rawat, Tio, Verma expires January 2001 [Page3]
incoming packet.
The frame format for L2TP is based RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on SNAP encapsulation
as defined in RFC 1490 [5] and FRF3.1 [2] . SNAP format
uses NLPID followed obtaining RFCs via FTP or EMAIL may be obtained by Organizationally Unique Identifier
and a PID.
NLPID
The single octet identifier provides a mechanism to allow
easy protocol identification. For L2TP NLPID value 0x80 is
used which indicates the presence of SNAP header.
OUI & PID
The three-octet Organizationally Unique Identifier (OUI)
0x00-00-5E identifies IANA who administers the meaning of
the Protocol Identifier (PID) 0x0007. Together they
identify a distinct protocol.
Format of L2TP frames encapsulated in Frame Relay is given
in Figure 1.
Octet 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Q.922 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Control 0x03 | pad 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | NLPID 0x80 | OUI 0x00 |
+-+-+-+-+-+-+-+-+ +
7 | OUI 0x00-5E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | PID 0x0007 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| L2TP packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Format for L2TP frames encapsulated in
Frame Relay
5.0 MTU Considerations
Rawat, Tio, Verma expires January 2001 [Page4]
FRF.12 [4] is the Frame Relay Fragmentation Implementation
Agreement. If fragmentation is not supported, the two
Frame Relay endpoints MUST support sending
an MTU size of at least
PPP Max-Receive-Unit size + PPP header size + Max L2TP
Header Size + Frame Relay header size (PPP header size is
the protocol field size plus HDLC framing bytes, which is
required by L2TP). To avoid packet discards on the Frame
Relay interface, the RECOMMENDED default Frame Relay MTU
is 1564 based on a PPP default MRU of 1500. The means to
ensure these MTU settings are left EMAIL message to implementation.
6.0 QOS Issues
In general, QoS mechanisms can be roughly provided for rfc-info@RFC-EDITOR.ORG with proprietary mechanisms localized within the LAC or
LNS. Interworking issues with various QoS implementations
is therefore at this time left as a topic message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for future
study.
7.0 Frame Relay and L2TP Interaction
In case of Frame Relay SVCs, connection setup will be
triggered when L2TP tries to create a tunnel. Details of
triggering mechanism are left to implementation. There
SHALL NOT special distribution should be any change in Frame Relay SVC signaling due addressed to L2TP. The endpoints of either the L2TP tunnel MUST be
identified by X.121/E.164 addresses in case of Frame Relay
SVC. These addresses MAY be obtained as tunnel endpoints
for a user as defined in [3]. In case of PVCs, the Virtual
Circuit to carry L2TP traffic MAY be configured
administratively. The endpoints
author of the tunnel MUST be
identified by DLCI, assigned RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the PVC at configuration
time. This DLCI MAY be obtained as tunnel endpoints for a
user as defined in [3].
There SHALL be no framing issues between PPP and Frame
Relay. PPP frames received by LAC from remote user RFC itself, all RFCs are
stripped of CRC, link framing, and transparency bytes,
encapsulated in L2TP, and forwarded over Frame Relay
tunnel.
8.0 Security Considerations
Currently there is no standard specification for Frame
Relay security although the Frame Relay Forum is working
on a Frame Relay Privacy Agreement. In light of this
work, the issue of security will
unlimited distribution.echo
Submissions for Requests for Comments should be re-examined at a later
Rawat, Tio, Verma expires January 2001 [Page5]
date sent to see if L2TP over Frame Relay specific protection
mechanisms are still required. Meanwhile, if stronger
security mechanisms is required, the use of IP as an
intermediate transport layer with IPsec [6] for security
is RECOMMENDED.
9.0 Acknowledgments
Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com
Corporation) contributed
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to the editing of this document.
10.0 References
[1] Valencia et al., "Layer Two Tunneling Protocol
'L2TP'", RFC 2661, August 1999.
[2] Multiprotocol Encapsulation Implementation Agreement,
FRF.3.1 , Frame Relay Forum Technical Committee, June 1995
[3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS
Attributes
Authors, for Tunnel Protocol Support." Internet draft
(work in progress).
[4] Frame Relay Fragmentation Implemenation Agreement,
FRF.12, Frame Relay Forum Technical Committee, December
1997
[5] T. Bradley, C. Brown, A. Malis, "Multiprotocol
Interconnect over Frame Relay", RFC 1490, July 1993
[6] B. Patel, B. Aboda. "Securing L2TP using IPSEC."
Internet draft (work in progress).
Rawat, Tio, Verma expires January 2001 [Page6]
11.0 Author's Addresses
Vipin Rawat
Cisco Systems, Inc.
170 West Tasman Drive
San Jose CA 95134-1706
vrawat@cisco.com
Rene Tio
Redback Networks, Inc.
1195 Borregas Avenue
Sunnyvale, CA 94089
tor@redback.com
Rohit Verma
Deloitte Consulting
180 N. Stetson Avenue
Chicago Illinois 60601
rverma@dc.com
Suhail Nanji
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
suhail@redback.com
J. Senthilnathan
3Com Corporation
1800 West Central Road
Mount Prospect, IL 60056
janakiraman_senthilnathan@3com.com
Rawat, Tio, Verma expires January 2001 [Page7] further information.