Network Working Group V. Rawat
Request for Comments: 3070 ONI Systems, Inc.
Category: Standards Track R. Tio
S. Nanji
Redback Networks, Inc.
R. Verma
Deloitte Consulting
February 2001
Layer Two Tunneling Protocol (L2TP) over Frame Relay
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel
Point-to-Point (PPP) sessions. The protocol has been designed to be
independent of the media it runs over. The base specification
describes how it should be implemented to run over the User Datagram
Protocol (UDP) and the Internet Protocol (IP). This document
describes how L2TP is implemented over Frame Relay Permanent Virtual
Circuits (PVCs) and Switched Virtual Circuits (SVCs).
Applicability
This specification is intended for those implementations which desire
to use facilities which are defined for L2TP and applies only to the
use of Frame Relay pont-to-point circuits.
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 of the media over which it operates. The base protocol
specification illustrates how L2TP may be used in IP environments.
This document specifies the encapsulation of L2TP over native Frame
Relay and addresses relevant issues.
Rawat, et al. Standards Track [Page 1]
RFC 3070 L2TP over Frame Relay February 2001
2.0 Conventions
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 [2].
3.0 Problem Space Overview
In this section we describe in high level terms the scope of the
problem being addressed. Topology:
+------+ +---------------+ |
| PSTN | | Frame Relay | |
User--| |----LAC ===| |=== LNS --+ LANs
| ISDN | | Cloud | |
+------+ +---------------+ |
An L2TP Access Concentrator (LAC) is a device attached to the
switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP
end system capable of handling the L2TP 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 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 is created when an end-
to-end PPP connection 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 the LAC and the LNS.
L2TP protocol operates at a level above the particular media over
which it is carried. However, some details of its connection to
media are required to permit interoperable implementations. L2TP
over IP/UDP is described in the base L2TP specification [1]. Issues
related to L2TP over Frame Relay are addressed in later sections of
this document.
4.0 Encapsulation and Packet Format
L2TP MUST be able 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 to be defined to identify the protocol
being carried in the packets. The Frame Relay network may not
understand these formats.
Rawat, et al. Standards Track [Page 2]
datatracker.ietf.org