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 (C) The Internet Society (2001). All Rights Reserved.
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).
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.
L2TP  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.
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 . Issues related to L2TP over Frame Relay are addressed in later sections of this document.
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]
RFC 3070 L2TP over Frame Relay February 2001
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 packet.
The frame format for L2TP MUST be SNAP encapsulation as defined in RFC 1490  and FRF3.1 . SNAP format uses NLPID followed by Organizationally Unique Identifier and a PID.
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.
FRF.12  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 1526 which is based on adding the PPP Max-Receive-Unit size with the PPP header size with the Max L2TP Header Size with the 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 to implementation.
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 . 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 .
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.
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 be re- examined at a later date to see if L2TP over Frame Relay specific protection mechanisms are still required. In the interim, basic security issues are discussed in the base L2TP specification .
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.