< draft-ietf-l2tpext-l2tp-atm-02.txt		draft-ietf-l2tpext-l2tp-atm-03.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group Mike Davison		RFC 3355
	INTERNET DRAFT Cisco
	Category: Standards Track Arthur Lin
	Title: draft-ietf-l2tpext-l2tp-atm-02.txt Tahoe Networks
	Date: August 2001 Ajoy Singh
	Motorola
	John Stephens
	Cayman Systems
	Rollins Turner
	Paradyne
	Rene Tio
	Suhail Nanji
	Redback Networks
	L2TP Over AAL5
	<draft-ietf-l2tpext-l2tp-atm-02.txt>
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.
	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
	To view the list Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.
	The distribution of this memo is unlimited. It is filed as <draft-
	ietf-l2tpext-l2tp-atm-02.txt>, and expires February, 2002. Please
	send comments to the authors.
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page1]
	Abstract
	The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard
	method for transporting the link layer of PPP [RFC1661] between a
	dial-up server and a Network Access Server, using a network
	connection in lieu of a physical point to point connection. This
	document describes the use of an ATM network for the underlying
	network connection. ATM User-Network Interface (UNI) Signalling
	Specification Version 4.0 [SIG40] or Version 3.1 [SIG31] with ATM
	Adaptation Layer 5 (AAL5) [ITU93] are supported as interfaces to the
	ATM network.
	Applicability
	This specification is intended for implementations of L2TP that use
	ATM to provide the communications link between the L2TP Access
	Concentrator and the L2TP Network Server.
	1. Introduction
	The Point-to-Point Protocol, PPP, [RFC1661] is frequently used on the
	link between a personal computer with a dial modem and a network
	service provider, or NSP. The Layer Two Tunneling Protocol (L2TP)
	[RFC2661] enables a dial-up server to provide access to a remote NSP
	by extending the PPP connection through a tunnel in a network to
	which both it and the NSP are directly connected. A "tunnel" is a
	network layer connection between two nodes, used in the role of a
	data link layer connection between those nodes, possibly as part of a
	different network. In [RFC2661] the dial-up server is called an L2TP
	Access Concentrator, or LAC. The remote device that provides access
	to a network is called an L2TP Network Server, or LNS. L2TP uses a
	packet delivery service to create a tunnel between the LAC and the
	LNS. "L2TP is designed to be largely insulated from the details of
	the media over which the tunnel is established; L2TP requires only
	that the tunnel media provide packet oriented point-to-point
	connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable
	form of packet oriented connection. This standard supplements
	[RFC2661] by providing details specific to the use of AAL5 for a
	point-to-point connection between LAC and LNS.
	2. Conventions
	Requirements keywords 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
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page2]
	[RFC2119].
	A list of acronyms used in this document is given at the end of the
	document as Appendix A.
	3. AAL5 Layer Service Interface
	L2TP treats the underlying ATM AAL5 layer service as a bit-
	synchronous point-to-point link. In this context, the L2TP link
	corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be
	full-duplex, point to point, and it MAY be either dedicated (i.e.,
	permanent, set up by provisioning) or switched (set up on demand.)
	The AAL5 message mode service, in the non-assured mode of operation,
	without the corrupted delivery option MUST be used.
	Interface Format - The L2TP/AAL5 layer boundary presents an octet
	service interface to the AAL5 layer. There is no provision for sub-
	octets to be supplied or accepted.
	3.1 Maximum Transfer Unit
	Each L2TP PDU MUST be transported within a single AAL5 PDU.
	Therefore the maximum transfer unit (MTU) of the AAL5 connection
	constrains the MTU of the L2TP tunnel that uses the connection and
	the MTU of all PPP connections that use the tunnel. ( [RFC1661]
	refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is the
	Forward and Backward Maximum CPCS-SDU Size.)
	An implementation MUST support a PPP MRU of at least 1500 bytes.
	An implementation SHOULD use a larger MTU than the minimum value
	specified above. It is RECOMMENDED that an implementation support an
	IP packet of at least 9180 bytes in the PPP PDU.
	3.2 Quality of Service
	In order to provide a desired Quality of Service (QoS), and possibly
	different qualities of service to different client connections, an
	implementation MAY use more than one AAL5 connection between LAC and
	LNS.
	QoS mechanisms, such as Differentiated UBR [DUBR], that could involve
	inverse multiplexing a tunnel across multiple VCs are for further
	study. QoS mechanisms applicable to a single tunnel corresponding to
	a single VC, are independent of the ATM transport and out of scope of
	this document.
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page3]
	3.3 ATM Connection Parameters
	The L2TP layer does not impose any restrictions regarding
	transmission rate or the underlying ATM layer traffic descriptor
	parameters.
	Specific traffic parameters MAY be set for a PVC connection by
	agreement between the communicating parties. The caller MAY request
	specific traffic parameters at the time an SVC connection is set up.
	Autoconfiguration of end-systems for PVCs can be faciliated by the
	use of the optional ILMI 4.0 extensions documented in [ILMIA]. This
	provides comparable information to the IEs used for control plane
	connection establishment.
	4. Multi-Protocol Encapsulation
	This specification uses the principles, terminology, and frame
	structure described in "Multiprotocol Encapsulation over ATM
	Adaptation Layer 5" [RFC2684]. The purpose of this specification is
	not to reiterate what is already standardized in [RFC2684], but to
	specify how the mechanisms described in [RFC2684] are to be used to
	map L2TP onto an AAL5-based ATM network.
	As specified in [RFC2684], L2TP PDUs shall be carried in the payload
	field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and
	the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be
	empty.
	Section 1 of [RFC2684] defines two mechanisms for identifying the
	protocol encapsulated in the AAL5 PDU's payload field:
	1. Virtual circuit (VC) based multiplexing.
	2. Logical Link Control (LLC) encapsulation.
	In the first mechanism, the payload's protocol type is implicitly
	agreed to by the end points for each virtual circuit using
	provisioning or control plane procedures. This mechanism will be
	referred to as "VC-multiplexed L2TP".
	In the second mechanism, the payload's protocol type is explicitly
	identified in each AAL5 PDU by an IEEE 802.2 LLC header. This
	mechanism will be referred to as "LLC encapsulated L2TP".
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page4]
	An L2TP implementation:
	1. MUST support LLC encapsulated L2TP on PVCs.
	2. MAY support LLC encapsulated L2TP on SVCs.
	3. MAY support VC-multiplexed L2TP on PVCs or SVCs.
	When a PVC is used, the endpoints must be configured to use one of
	the two encapsulation methods.
	If an implementation supports SVCs, it MUST use the [Q.2931] Annex C
	procedure to negotiate connection setup, encoding the Broadband Lower
	Layer Interface (B-LLI) information element (IE) to signal either VC-
	multiplexed L2TP or LLC encapsulated L2TP. The details of this
	control plane procedure are described in section 7.
	If an implementation is connecting through a Frame Relay/ATM FRF.8
	[FRF8] service inter-working unit, then it MUST use LLC encapsulated
	L2TP.
	5. LLC Encapsulated L2TP over AAL5
	When LLC encapsulation is used, the payload field of the AAL5 CPCS
	PDU SHALL be encoded as shown in Figure 1. The pertinent fields in
	that diagram are:
	1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA
	followed by a frame type of Un-numbered Information (value 0x03).
	This LLC header indicates that an IEEE 802.1a SNAP header follows
	[RFC2684].
	2. IEEE 802.1a SNAP Header: The three octet Organizationally
	Unique Identifier (OUI) value of 0x00-00-5E identifies IANA
	(Internet Assigned Numbers Authority.) The two octet Protocol
	Identifier (PID) identifies L2TP as the encapsulated protocol.
	The PID value is 0x0007.
	3. The L2TP PDU.
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page5]
	Figure 1 - LLC Encapsulated L2TP PDU
	+-------------------------+ --------
	| Destination SAP (0xAA) | ^
	+-------------------------+ |
	| Source SAP (0xAA) | LLC header
	+-------------------------+ |
	| Frame Type = UI (0x03) | V
	+-------------------------+ --------
	| OUI (0x00-00-5E)| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
	| PID (0x00-07) | |
	+-------------------------+ --------
	| | |
	| | L2TP PDU
	| | |
	+-------------------------+ --------
	Note: The format of the overall AAL5 CPCS PDU is shown in the next
	section.
	The end points MAY be bi-laterally provisioned to send other LLC-
	encapsulated protocols besides L2TP across the same virtual
	connection.
	6. Virtual Circuit Multiplexed L2TP over AAL5
	VC-multiplexed L2TP over AAL5 is an alternative technique to LLC
	encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5
	payload without an LLC header. This is sometimes called "Null
	encapsulation."
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page6]
	Figure 2 - AAL5 CPCS-PDU Format
	+-------------------------------+ -------
	| . | ^
	| . | |
	| CPCS-PDU payload | L2TP PDU
	| up to 2^16 - 1 octets) | |
	| . | V
	+-------------------------------+ -------
	| PAD ( 0 - 47 octets) |
	+-------------------------------+ -------
	| CPCS-UU (1 octet ) | ^
	+-------------------------------+ |
	| CPI (1 octet ) | |
	+-------------------------------+CPCS-PDU Trailer
	| Length (2 octets) | |
	+-------------------------------| |
	| CRC (4 octets) | V
	+-------------------------------+ -------
	The Common Part Convergence Sub-layer (CPCS) PDU payload field
	contains user information up to 2^16 - 1 octets.
	The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
	such that the last 48 octet cell payload created by the SAR sublayer
	will have the CPCS-PDU Trailer right justified in the cell.
	The CPCS-UU (User-to-User indication) field is used to transparently
	transfer CPCS user to user information. The field has no function
	under the multi-protocol ATM encapsulation and MAY be set to any
	value.
	The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
	64 bits. Possible additional functions are for further study in ITU-
	T. When only the 64 bit alignment function is used, this field SHALL
	be coded as 0x00.
	The Length field indicates the length, in octets, of the payload
	field. The maximum value for the Length field is 65535 octets. A
	Length field coded as 0x00 MAY be used for the abort function.
	The CRC field SHALL be computed over the entire CPCS-PDU except the
	CRC field itself.
	The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in
	[RFC2661].
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page7]
	7. Out-of-Band Control Plane Signalling
	7.1 Connection Setup
	An SVC connection can originate at either the LAC or the LNS. An
	implementation that supports the use of SVCs MUST be able to both
	originate and respond to SVC setup requests. Except for the B-LLI IE
	specified below, all other IEs required for ATM User-Network
	Interface (UNI) Signalling Specification Version 4.0 [SIG40] should
	be encoded as per [RFC2331].
	When originating an SVC AAL5 connection, the caller MUST request in
	the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP,
	or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL
	be used to specify the requested encapsulation method. When a caller
	is offering both encapsulations, the two B-LLI IEs SHALL be encoded
	within a Broadband Repeat Indicator information element in the order
	of the sender's preference.
	An implementation MUST be able to accept an incoming call that offers
	LLC encapsulated L2TP in the caller's request. The called peer's
	implementation MUST reject a call setup request that only offers an
	encapsulation that it does not support. Implementations originating
	a call offering both protocol encapsulation techniques MUST be able
	to accept the use of either encapsulation technique.
	When originating an LLC encapsulated call that is to carry an L2TP
	payload, the [Q.2931] B-LLI IE user information layer 2 protocol
	field SHALL be encoded to select LAN Logical Link Control
	(ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example.
	When originating a VC-multiplexed call that is to carry an L2TP
	payload, the [Q.2931] B-LLI IE user information layer 2 protocol
	field SHALL be encoded to select no layer 2 protocol in octet 6 and
	layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577
	[ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037
	[DSLF037], the extension octets specify VC-multiplexed L2TP by using
	the SNAP IPI, followed by an OUI owned by IANA, followed by the PID
	assigned by IANA for L2TP. Thus, the User Information layer 3
	protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's
	payload field will always contain an L2TP PDU. The SNAP IPI is
	employed only to use the IANA L2TP protocol value to specify the VC-
	multiplexed PDU.
	If the caller offers both encapsulation methods and the called peer
	accepts the call, the called peer SHALL specify the encapsulation
	method by including exactly one B-LLI IE in the Connect message.
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page8]
	If an SVC tunnel is reset in accordance with section 4.1 of
	[RFC2661], both ends MUST clear the SVC. Any user sessions on the
	tunnel will be terminated by the reset. Either end MAY attempt to
	re-establish the tunnel upon receipt of a new request from a client.
	7.2 Connection Setup Failure
	When a connection setup fails, the L2TP entity that attempted the
	connection setup MAY consider the called entity unreachable until
	notified that the unreachable entity is available. The conditions
	under which an entity determines that another is unreachable and how
	it determines that the other is available again are implementation
	decisions.
	7.3 Connection Teardown
	When there are no active sessions on an SVC tunnel, either end MAY
	optionally clear the connection.
	8. Connection Failure
	Upon notification that an AAL5 SVC connection has been cleared, an
	Implementation SHALL tear down the tunnel and return the control
	connection to the idle state.
	9. Security Considerations
	ATM networks, being virtual circuit based, are generally less
	vulnerable to security attacks than IP based networks. The
	probability of a security breach caused by misrouted ATM cells is
	considered to be negligible.
	Currently there is no standard specification for ATM security.
	However, the ATM Forum is working on an ATM Security Framework
	document. In light of this work, the issue of security will be re-
	examined at a later date to see if L2TP over ATM specific protection
	mechanisms are still required. In the interim, basic security issues
	are discussed in the base L2TP specification [RFC2661].
	10. Acknowledgments
	This Internet Draft draws heavily on material from: "PPP Over AAL5"
	(RFC 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis,
	and John Stephens; the current Internet Draft on L2TP over Frame
	Relay, by Vipin Rawat, Rene Tio, Suhail Nanji and Rohit Verma; and an
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page9]
	earlier Internet Draft on L2TP over AAL5 by by Nagraj Arunkumar, Manu
	Kaycee, Tim Kwok, and Arthur Lin.
	Special thanks to David Allan of Nortel for his invaluable review of
	this document.
	11. References
	[RFC2661] W. M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G.
	Zorn, B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661,
	August 1999
	[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
	STD 51, RFC 1661, July 1994.
	[SIG31] The ATM Forum, "ATM User-Network Interface Specification
	V3.1", af-uni-0010.002, 1994.
	[ITU93] International Telecommunication Union, "B-ISDN ATM Adaptation
	Layer(AAL) Specification", ITU-T Recommendation I.363, March 1993.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2684] D. Grossman, J. Heinanen, "Multiprotocol Encapsulation over
	ATM Adaptation Layer 5", RFC 2684, September 1999.
	[Q.2931] International Telecommunication Union, "Broadband Integrated
	Service Digital Network (B-ISDN) Digital Subscriber Signaling System
	No.2 (DSS2) User Network Interface Layer 3 Specification for Basic
	Call/Connection Control", ITU-T Recommendation Q.2931, Feb. 1995.
	[FRF8] The Frame Relay Forum, "Frame Relay/ATM PVC Service
	Interworking Implementation Agreement", FRF.8, April 1995.
	[ISO9577] ISO/IEC DTR 9577.2, "Information technology -
	Telecommunications and Information exchange between systems -
	Protocol Identification in the network layer", 1995-08-16.
	[RFC2331] M. Maher, "ATM Signalling Support for IP over ATM - UNI
	Signalling 4.0 Update", RFC 2331, April 1998.
	[DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for
	the Connection Between the DSL Broadband Network Termination (B-NT)
	and the Network using ATM", March 2001.
	[SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page10]
	Specification Version 4.0", af-sig-0061.000, finalized July 1996;
	available at ftp://ftp.atmforum.com/pub.
	[DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
	tm-0149.000, finalized July, 2000; available at
	ftp://ftp.atmforum.com/pub
	[ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration
	Extension", af-nm-00165.000, April 2001.
	Authors' Addresses:
	Rollins Turner
	Paradyne Corporation
	8545 126th Avenue North
	Largo, FL 33773
	Email: rturner@eng.paradyne.com
	Ajoy Singh
	Motorola
	1421 West Shure Dr,
	Arlington Heights, IL 60004
	Email: asingh1@motorola.com
	Suhail Nanji
	Redback Networks, Inc.
	300 Holger Way
	Sunnyvale, CA 95134
	Email: suhail@redback.com
	Rene Tio
	Redback Networks, Inc.
	300 Holger Way
	Sunnyvale, CA 95134
	Email: tor@redback.com
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page11]
	Appendix A. Acronyms
	AAL5 ATM Adaptation Layer Type 5
	ATM Asynchronous Transfer Mode
	B-LLI Broadband Low Layer Information
	CPCS Common Part Convergence Sublayer
	IANA Internet Assigned Numbers Authority
	IE Information Element
	L2TP Layer Two Tunneling Protocol
	LAC L2TP Access Concentrator
	LLC Logical Link Control
	LNS L2TP Network Server
	MTU Maximum Transfer Unit
	MRU Maximum Receive Unit		Title: Layer Two Tunnelling Protocol (L2TP) Over ATM
			Adaptation Layer 5 (AAL5)
			Author(s): A. Singh, R. Turner, R. Tio, S. Nanji
			Status: Standards Track
			Date: August 2002
			Mailbox: rturner@eng.paradyne.com, tor@redback.com,
			asingh1@motorola.com, suhail@redback.com
			Pages: 13
			Characters: 25114
			Updates/Obsoletes/SeeAlso: None
	NSP Network Service Provider		I-D Tag: draft-ietf-l2tpext-l2tp-atm-03.txt
	OUI Organizationally Unique Identifier		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3355.txt
	PDU Protocol Data Unit		The Layer Two Tunneling Protocol (L2TP) provides a standard method for
			transporting the link layer of the Point-to-Point Protocol (PPP)
			between a dial-up server and a Network Access Server, using a network
			connection in lieu of a physical point-to-point connection. This
			document describes the use of an Asynchronous Transfer Mode (ATM)
			network for the underlying network connection. ATM User-Network
			Interface (UNI) Signaling Specification Version 4.0 or Version 3.1
			with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the
			ATM network.
	PID Protocol Identifier		This document is a product of the Layer Two Tunneling Protocol
			Extensions Working Group of the IETF.
	PPP Point-to-Point Protocol		This is now a Proposed Standard Protocol.
	PVC Permanent Virtual Circuit		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.
	SAP Service Access Point		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	SNAP Subnetwork Address Protocol		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	SVC Switched Virtual Circuit		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	VC Virtual Circuit		help: ways_to_get_rfcs
	Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page12]		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.
	525 lines changed or deleted		43 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/