GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3355

Network Working Group A. Singh Request for Comments: 3355 Motorola Category: Standards Track R. Turner

                                                              Paradyne
                                                                R. Tio
                                                              S. Nanji
                                                      Redback Networks
                                                           August 2002
                Layer Two Tunnelling Protocol (L2TP)
                 Over ATM Adaptation Layer 5 (AAL5)

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 (2002).  All Rights Reserved.

Abstract

 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.

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.

Singh, et. al. Standards Track [Page 1] RFC 3355 L2TP Over AAL5 August 2002

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

Singh, et. al. Standards Track [Page 2] RFC 3355 L2TP Over AAL5 August 2002

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.

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

Singh, et. al. Standards Track [Page 3] RFC 3355 L2TP Over AAL5 August 2002

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

Singh, et. al. Standards Track [Page 4] RFC 3355 L2TP Over AAL5 August 2002

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 octets Protocol
       Identifier (PID) identifies L2TP as the encapsulated protocol.
       The PID value is 0x0007.
    3. The L2TP PDU:
                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.

Singh, et. al. Standards Track [Page 5] RFC 3355 L2TP Over AAL5 August 2002

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

Singh, et. al. Standards Track [Page 6] RFC 3355 L2TP Over AAL5 August 2002

 The CRC field is 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].

7. Out-of-Band Control Plane Signaling

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) Signaling 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 techniques.
 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

Singh, et. al. Standards Track [Page 7] RFC 3355 L2TP Over AAL5 August 2002

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

 The Layer Two Tunneling Protocol base specification [RFC2661]
 discusses basic security issues regarding L2TP tunneling.  It is
 possible that the L2TP over AAL5 tunnel security may be compromised
 by the attack of ATM transport network itself.  The ATM Forum has
 published a security framework [AFSEC1] and a security specification
 [AFSEC2] that define procedures to guard against common threats to an
 ATM transport network.  Applications that require protection against
 threats to an ATM switching network are encouraged to use
 authentication headers, or encrypted payloads, and/or the ATM-layer
 security services described in [AFSEC2].

Singh, et. al. Standards Track [Page 8] RFC 3355 L2TP Over AAL5 August 2002

10. Acknowledgments

 This document draws heavily on material from: "PPP Over AAL5" (RFC
 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and
 John Stephens and an earlier document of L2TP over AAL5 by Nagraj
 Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.
 Special thanks to Mike Davison, Arthur Lin, John Stevens for making
 significant contributions to the initial version of this document.
 Special thanks to David Allan of Nortel for his invaluable review of
 this document.
 The security section of this document is based upon RFC 3337, "Class
 Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2
 (AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren.

11. References

 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
           Zorn, G. and B. Palter, "Layer Two Tunneling 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] Grossman, D. and 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.

Singh, et. al. Standards Track [Page 9] RFC 3355 L2TP Over AAL5 August 2002

 [ISO9577] ISO/IEC DTR 9577.2, "Information technology -
           Telecommunications and Information exchange between systems
           - Protocol Identification in the network layer", 1995-08-
           16.
 [RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI
           Signaling 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) Signaling
           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.
 [AFSEC1]  The ATM Forum, "ATM Security Framework Version 1.0", af-
           sec-0096.000, February 1998
 [AFSEC2]  The ATM Forum, "ATM Security Specification v1.1", af-sec-
           0100.002, March 2001

Singh, et. al. Standards Track [Page 10] RFC 3355 L2TP Over AAL5 August 2002

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
 NSP     Network Service Provider
 OUI     Organizationally Unique Identifier
 PDU     Protocol Data Unit
 PID     Protocol Identifier
 PPP     Point-to-Point Protocol
 PVC     Permanent Virtual Circuit
 SAP     Service Access Point
 SNAP    Subnetwork Address Protocol
 SVC     Switched Virtual Circuit
 VC      Virtual Circuit

Singh, et. al. Standards Track [Page 11] RFC 3355 L2TP Over AAL5 August 2002

Authors' Addresses

 Rollins Turner
 Paradyne Corporation
 8545 126th Avenue North
 Largo, FL 33773
 EMail: rturner@eng.paradyne.com
 Rene Tio
 Redback Networks, Inc.
 300 Holger Way
 San Jose, CA 95134
 EMail: tor@redback.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

Singh, et. al. Standards Track [Page 12] RFC 3355 L2TP Over AAL5 August 2002

Full Copyright Statement

 Copyright (C) The Internet Society (2002).  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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Singh, et. al. Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3355.txt · Last modified: 2002/08/06 20:51 (external edit)