[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
PPP Working Group                                   Vipin Rawat, Rene Tio
INTERNET DRAFT                                              Cisco Systems
Category: Internet Draft                                      Rohit Verma
Title: draft-ietf-pppext-l2tp-fr-01.txt                  3Com Corporation
Date: December 1998

          Layer Two Tunneling Protocol (L2TP) over Frame Relay

Status of this Memo

   This document is an Internet-Draft. 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-

   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.''

   To learn the current status of any Internet-Draft, please
   check the ``1id-abstracts.txt'' listing contained in the
   Internet-Drafts Shadow Directories on ftp.is.co.za
   (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
   Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
   West Coast). Distribution of this memo is unlimited.


   Layer Two Tunneling Protocol describes a mechanism to
   tunnel 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

Rawat, Verma, Tio          expires June 1999                    [Page 1]

INTERNET DRAFT                                             December 1998

   run over UDP and IP. This document describes how the Layer
   Two Tunneling Protocol MUST be implemented over Frame
   Relay PVCs and 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 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 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 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 -- This item is an
        absolute requirement of the specification.

        o  SHOULD or RECOMMEND -- This item should generally
        be followed for all but exceptional circumstances.

        o  MAY or OPTIONAL -- This item is truly optional and
        may be followed or ignored according to the needs of
        the implementor.

3.0 Problem Space Overview

In this section we describe in high level terms the scope of
the problem being addressed.

Rawat, Verma, Tio          expires June 1999                    [Page 2]

INTERNET DRAFT                                             December 1998

      +-------+           +---------------+          |
      | PSTN  |           |  Frame Relay  |          |
User--|       |----LAC ===|               |=== LNS --+ LANs
      | ISDN  |           |     Cloud     |          |
      +-------+           +---------------+          |

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
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 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.

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 the receiver to properly process the incoming

Rawat, Verma, Tio          expires June 1999                    [Page 3]

INTERNET DRAFT                                             December 1998

The frame format for L2TP is based on SNAP encapsulation as
defined in RFC 1490 [5] and FRF3.1 [2] . SNAP format uses
NLPID followed by Organizationally Unique Identifier and a


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.


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

FRF.12 [4] is the Frame Relay Fragmentation Implementation
Agreement. If fragmentation is not supported, the two Frame
Relay endpoints MUST support an MTU size of at least PPP

Rawat, Verma, Tio          expires June 1999                    [Page 4]

INTERNET DRAFT                                             December 1998

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).  1500 + 64 is RECOMMENDED for default PPP
default MRU of 1500 to avoid packet discards on the Frame
Relay interface. The means to ensure these MTU settings are
left to implementation.

6.0 QOS Issues

In general, QoS mechanisms can be roughly provided for with
proprietary mechanisms localized within the LAC or LNS.
Interworking issues with various QoS implementations is
therefore at this time left as a topic 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 be any change in Frame Relay SVC signaling due to L2TP.
The endpoints of 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 of the tunnel MUST be identified by DLCI, assigned
to 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 are stripped of
CRC, link framing, and transparency bytes, encapsulated in
L2TP, and forwarded over Frame Relay tunnel.

8.0 Security Considerations

Frame Relay, being a circuit-switched media, is typically
less pervious to security attacks [6].  If such attacks
become prevalent, it may be desirable to implement additional
security mechanisms.

Currently there is no standard specification for Frame Relay
security.  The Frame Relay Forum is working on a Frame Relay
Privacy Agreement [6] which specifies authentication,
encryption, and key exchange facilities.  In light of this
work, the issue of security will be re-examined at a later

Rawat, Verma, Tio          expires June 1999                    [Page 5]

INTERNET DRAFT                                             December 1998

date 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 for security is

9.0 Acknowledgments

Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com
Corporation) contributed to the editing of this document.

10.0 References

    [1]  Valencia et al., "Layer Two Tunneling Protocol -
    L2TP", Internet draft (work in progress), draft-ietf-
    pppext-l2tp-12.txt, Nov, 1998.

    [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 for Tunnel Protocol Support."  Internet draft
    (work in progress), draft-ietf-radius-tunnel-auth-05.txt,
    Microsoft, Ascend   Communications, Shiva Corporation,
    April 1998.

    [4]  Frame Relay Fragmentation Implemenation Agreement,
    FRF.12, Frame Relay Forum Technical Committee, December

    [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), draft-ietf-pppext-
    l2tp-security-02.txt, Intel, Microsoft, May 1998

    [7] Frame Relay Privacy Implementation Agreement, DRAFT,
    Frame Relay Forum Technical Committee, June 1998

11.0 Author's Addresses

Rawat, Verma, Tio          expires June 1999                    [Page 6]

INTERNET DRAFT                                             December 1998

Vipin Rawat, Rene Tio
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706

Rohit Verma
3Com Corporation
1800 W. Central Road
Mount Prospect
Illinois 60056

Rawat, Verma, Tio          expires June 1999                    [Page 7]