rfc3355.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

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.