< draft-ietf-l2tpext-fr-00.txt		draft-ietf-l2tpext-fr-01.txt >
			A new Request for Comments is now available in online RFC libraries.
	L2TPEXT Working Group Vipin Rawat		RFC 3070
	INTERNET DRAFT Cisco Systems, Inc.
	Category: Internet Draft Rene Tio
	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
	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
	Rawat, Tio, Verma expires January 2001 [Page1]
	specification describes how it should be implemented to
	run over UDP and IP. This document describes how the Layer
	Two Tunneling Protocol MUST be implemented over Frame
	Relay PVCs and SVCs.
	Applicability
	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, 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 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
	Rawat, Tio, Verma expires January 2001 [Page3]
	incoming packet.
	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 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 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 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
	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
	Rawat, Tio, Verma expires January 2001 [Page5]
	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 [6] for security
	is RECOMMENDED.
	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'", RFC 2661, August 1999.
	[2] Multiprotocol Encapsulation Implementation Agreement,		Title: Layer Two Tunneling Protocol (L2TP) over Frame
	FRF.3.1 , Frame Relay Forum Technical Committee, June 1995		Relay
			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
	[3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS		I-D Tag: draft-ietf-l2tpext-fr-01.txt
	Attributes for Tunnel Protocol Support." Internet draft
	(work in progress).
	[4] Frame Relay Fragmentation Implemenation Agreement,		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3070.txt
	FRF.12, Frame Relay Forum Technical Committee, December
	1997
	[5] T. Bradley, C. Brown, A. Malis, "Multiprotocol		Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel
	Interconnect over Frame Relay", RFC 1490, July 1993		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).
	[6] B. Patel, B. Aboda. "Securing L2TP using IPSEC."		This document is a product of the Layer Two Tunneling Protocol
	Internet draft (work in progress).		Extensions Working Group of the IETF.
	Rawat, Tio, Verma expires January 2001 [Page6]		This is now a Proposed Standard Protocol.
	11.0 Author's Addresses
	Vipin Rawat		This document specifies an Internet standards track protocol for
	Cisco Systems, Inc.		the Internet community, and requests discussion and suggestions
	170 West Tasman Drive		for improvements. Please refer to the current edition of the
	San Jose CA 95134-1706		"Internet Official Protocol Standards" (STD 1) for the
	vrawat@cisco.com		standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	Rene Tio		This announcement is sent to the IETF list and the RFC-DIST list.
	Redback Networks, Inc.		Requests to be added to or deleted from the IETF distribution list
	1195 Borregas Avenue		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	Sunnyvale, CA 94089		added to or deleted from the RFC-DIST distribution list should
	tor@redback.com		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Rohit Verma		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Deloitte Consulting		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	180 N. Stetson Avenue		help: ways_to_get_rfcs. For example:
	Chicago Illinois 60601
	rverma@dc.com
	Suhail Nanji		To: rfc-info@RFC-EDITOR.ORG
	Redback Networks, Inc.		Subject: getting rfcs
	350 Holger Way
	San Jose, CA 95134
	suhail@redback.com
	J. Senthilnathan		help: ways_to_get_rfcs
	3Com Corporation
	1800 West Central Road
	Mount Prospect, IL 60056
	janakiraman_senthilnathan@3com.com
	Rawat, Tio, Verma expires January 2001 [Page7]		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	284 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/