rfc3301.txt

RFC 的详细文档！

Network Working Group                                         Y. T'Joens
Request for Comments: 3301                                      B. Sales
Category: Standards Track                                        Alcatel
                                                           P. Crivellari
                                                                Belgacom
                                                               June 2002


                 Layer Two Tunnelling Protocol (L2TP):
                     ATM access network extensions

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

   This document augments the procedures described in RFC 2661 to
   further support ATM SVC (Switched Virtual Circuits) or PVC (Permanent
   Virtual Circuits) based access networks.  L2TP (Layer 2 Tunneling
   Protocol) specifies a protocol for tunnelling PPP packets over packet
   based networks and over IP networks in particular.  L2TP supports
   remote access by ISDN and PSTN networks.  The extensions defined
   within this document allow for asymmetric bi-directional call
   establishment and service selection in the ATM access network.

Table Of Contents

   1. Introduction ..................................................  2
   1.1 Conventions ..................................................  2
   2. Assumptions ...................................................  3
   2.1 Topology .....................................................  3
   2.2 Connection Establishment .....................................  3
   2.3 LCP Negotiation ..............................................  3
   3. ATM access enhanced procedures ................................  3
   3.1 ATM connectivity .............................................  4
   3.2 Tunnel establishment .........................................  4
   3.3 Call establishment ...........................................  5
   3.3.1 Incoming Call Establishment ................................  5
   3.3.2 Outgoing Call Establishment ................................  6



T'Joens, et al.             Standards Track                     [Page 1]

RFC 3301          L2TP: ATM access network extensions          June 2002


   3.4 Framing ......................................................  6
   4. Service model issues ..........................................  7
   4.1 Authentication ...............................................  7
   4.2 Authorization ................................................  7
   5. New and extended AVPs .........................................  7
   5.1 New AVP Summary ..............................................  7
   5.2 New AVP definition ...........................................  8
   5.3 Changed AVP Definition ....................................... 12
   6. IANA considerations ........................................... 16
   7. Security considerations ....................................... 17
   8. Acknowledgements .............................................. 17
   9. References .................................................... 17
   10. Authors Addresses ............................................ 18
   11. Full Copyright Statement ..................................... 19

1. Introduction

   L2TP [RFC2661] defines the procedures for tunneling PPP sessions
   between a so called L2TP Access Concentrator (LAC) and an L2TP
   Network Server (LNS).  The main focus of [RFC2661] is on supporting
   HDLC based ISDN/PSTN access networks.

   This document augments the procedures described in [RFC2661] to
   further support ATM SVC or PVC based access networks.  Support for
   ATM access networks requires extensions to the present L2TP
   procedures so as to cope with :

   (a) the traffic management aspects of ATM connections (e.g.
       asymmetric bandwidth allocation and service category selection
       capabilities),

   (b) the addressing format to be used in switched ATM networks [AESA]
       and

   (c) the limitations imposed on LCP negotiation by transporting PPP
       over AAL5 over the access network segment of the PPP connection
       [RFC2364].

   Within this document, the necessary extensions to [RFC2661] are
   defined to cope with issues (a) and (b), issue (c) which is not
   specific to ATM may be solved as described in [L2TP_link].

1.1 Conventions

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




T'Joens, et al.             Standards Track                     [Page 2]

RFC 3301          L2TP: ATM access network extensions          June 2002


2. Assumptions

   In this section we describe some assumptions that have lead to the
   extensions described in this document.

2.1 Topology

   The procedures as defined in [RFC2661] apply mainly to access network
   technology such as PSTN and ISDN, which may be respectively
   asynchronous HDLC and synchronous HDLC based.  The aim of this
   document is to extend L2TP support to allow for user / LAC
   communication based on ATM access network technology.

2.2 Connection Establishment

   Due to the wide variety of existing signalling protocols and ATM
   service categories, and their support or non-support within ATM based
   access networks, this document takes as approach to provide for a
   flexible identification of ATM connection characteristics while
   establishing outgoing and incoming L2TP calls.  The procedures as
   defined within this document allow the allocation of asymmetric
   bandwidth and service category selection in terms of real or non-real
   time requirements on the ATM portion of the access network.

   As such, the detailed signalling protocol specific information
   elements that are necessary for switched VC service, are explicitly
   not negotiated during call establishment over the L2TP tunnel.

   In order to identify the endpoint of the ATM connection within the
   ATM access network, SVCs can be established on the basis of the ATM
   end system addressing format [AESA].  For PVC based services, the PVC
   can either be referred to by using the ATM end system addressing
   procedure (Called/Calling Number), or by making use of a textual name
   (Service Name).  The latter is inspired by the procedures defined
   within [Auto_PVC].

2.3 LCP negotiation

   The procedures described within this document may be combined with
   the procedures described in [L2TP_link] to limit LCP negotiation
   between LNS and user, so as to enforce PPP over AAL5 specific LCP
   negotiation [RFC2364].

3. ATM access enhanced procedures

   In order to illustrate the procedures specified within this document,
   this section will provide an operational description of Virtual
   dial-up access through an ATM based access network (e.g., ADSL).



T'Joens, et al.             Standards Track                     [Page 3]

RFC 3301          L2TP: ATM access network extensions          June 2002


   Note that the emphasis is on the changes proposed within this
   document relative to [RFC2661].

3.1 ATM connectivity

   Prior to initiating the PPP protocol layer, a Virtual Connection (VC)
   MUST be established between the user and the Network Access Server
   (LAC).  This virtual connection MAY either be a preconfigured
   Permanent VC(PVC), where the access network provider, NAS and user
   agree beforehand on the characteristics of the PVC, or MAY be an on-
   demand switched VC(SVC), where the negotiation between user, network
   and NAS takes place by means of an ATM signalling protocol.  Note
   that for establishing PVCs, alternative use may be made of the
   procedures as described in [Auto_PVC].

   In both cases, the user is referred to as the virtual dial-in user.

   Prior to accepting the switched connection from the virtual dial-in
   user, the LAC MAY check with the LNS whether the call should be
   accepted.  In the latter situation, the LAC MAY determine based upon
   parameters available within the call establishment message that this
   concerns a virtual dial in user, or MAY undertake a partial
   authentication of the end system/user, in order to bind the end
   system/user with a specific LNS.

   For PVC based users, the LAC MAY be triggered by the arrival of an
   LCP Configure Request, or PPP Authentication request message from the
   virtual dial-in user to initiate conversation with the LNS.  Note
   that the exact timing of triggering communication between LAC and LNS
   is outside the scope of this document.

3.2 Tunnel establishment

   If no tunnel connection currently exists to the desired LNS, one is
   initiated.  During the tunnel establishment, LNS and LAC indicate
   bearer and framing capabilities to each other, according to normal
   procedures.

   The bearer capability is extended to allow the LAC to indicate its
   support of ATM bearer devices.  Positive receipt of this indication,
   allows both LAC and LNS to use the extensions as defined within this
   document to support ATM based incoming and outgoing calls.

   If no compatibility between LNS and LAC exists according to the
   extensions defined within this document, no tunnel establishment can
   take place.  This would be because the LAC does not support any
   bearer capability which is expected by the LNS (e.g., an ATM based
   LAC, that only signals the "Broadband" Bearer Capability), or vice



T'Joens, et al.             Standards Track                     [Page 4]

RFC 3301          L2TP: ATM access network extensions          June 2002


   versa.  It is however encouraged that LAC or LNS implementations
   would allow for seamless interworking with peer devices which do not
   implement the extensions defined within this document.  This could be
   implemented by allowing a graceful fallback to digital bearer
   capability.

3.3 call establishment

   During incoming and outgoing broadband call establishment, the
   following extensions are defined to existing procedures.

3.3.1 Incoming Call Establishment

   The ATM connection between the virtual Dial-in user and LAC MAY
   either be dynamically or statically established.  When the VC
   connection is dynamically established (Switched VC), the LAC will
   receive a SETUP message over the interface that connects it to the
   ATM network.  This specification does not assume any specific
   interface type (UNI or NNI).  Permanent VC connections MAY either be
   manually configured, or configured by use of the extensions to the
   ILMI procedures as defined by [Auto_PVC].

   For switched VC connections, the LAC MAY select the peer LNS on the
   basis of connection establishment information, or by allowing partial
   PPP authentication of the virtual Dial-in user.  The connection
   establishment information that can be used by the LAC include Called
   Party AESA, Called Party AESA Subaddress, Calling Party AESA or
   Calling Party AESA Subaddress.

   For Permanent VC connections, the LAC MAY be triggered by (a) the
   establishment of the PVC, (b) by an LCP configure request, (c) by
   partially authenticating the virtual Dial-in user, or (d) by means
   outside the scope of this specification.

   Within the ICRQ, the LAC MUST indicate a broadband bearer in the
   Bearer Type AVP (B bit set to 1), MAY include the Service Category
   AVP, and MAY include the Service Name AVP.  If the LNS would not
   support the B Bearer bit, it will return an error on the ICRQ
   message.  In such a case, the implementation MAY decide to fall back
   to digital bearer capability, and SHOULD refrain from using the
   extensions defined within this document.  Further, the ICRQ message
   MAY contain the VPI/VCI identifier AVP.  This identifier can further
   be used at the LNS for management purposes next to or alternative to
   the Physical Channel ID AVP.

   Within the ICCN, both Tx Connect Speed AVP and Rx Connect Speed
   SHOULD be used if an asymetric connection has been established.




T'Joens, et al.             Standards Track                     [Page 5]

RFC 3301          L2TP: ATM access network extensions          June 2002


3.3.2 Outgoing Call Establishment

   Within an OCRQ, the LNS MUST indicate to the LAC minimum and maximum
   speeds for receive and transmit traffic (from the LAC perspective).
   This is to allow for the bi-directional asymmetric nature of ATM
   traffic contracts.  Note that in order to support UBR connections
   between LAC and user, the Minimum BPS MUST be set to zero.

   Further during OCRQ, the LNS MAY include the required Service
   Category AVP, i.e., indicating real time (rt) or non-real time (nrt)
   transport services.  The combination of minimum and maximum receive
   and transmit speed, and the indication of the required service
   category allows the LAC to establish an ATM connection according to
   its own capabilities, and the ATM access network capabilities,
   however within the service requirement for the PPP layer.

   Real time connectivity can be provided by either CBR or rt-VBR ATM
   service categories, non-real time connectivity can be provided by
   UBR, nrt-VBR, ABR or GFR ATM service categories.

   Further the LNS MUST indicate to the LAC in OCRQ message the called
   number according to the format described in this document (NSAP
   format).  When the called number carries an all zero payload, the LAC
   SHOULD look at the Service Name AVP to bind the tunnel call to an ATM
   VC connection.

   Next to the normal AVPs, the OCRP message MAY contain the VPI/VCI
   identifier AVP.  This identifier can further be used at the LNS for
   management purposes next to or alternative to the Physical Channel ID
   AVP.

3.4 Framing

   Within this document the PPP PDU refers to the concatenation of PPP
   protocol ID, PPP Information and PPP padding fields.

   In the direction of user to LNS, the PPP PDU will be carried on top
   of an AAL5 connection between user and LAC.  The LAC MUST strip off
   the AAL5 specific fields based on the encapsulation mechanism in use
   on the ATM connection, i.e. VC multiplexed or LLC encapsulated
   [RFC2364], and MUST encapsulate the PPP PDU with address and control
   field, as per HDLC procedures, on the L2TP tunnel.

   In the direction of LNS to user, the PPP PDU will be carried on top
   of an AAL5 connection between LAC and user.  The LAC MUST strip the
   PPP PDU from the address and control field on the L2TP tunnel, and





T'Joens, et al.             Standards Track                     [Page 6]

RFC 3301          L2TP: ATM access network extensions          June 2002


   insert the AAL5 specific fields based on the encapsulation mechanism
   in use on the ATM connection, i.e. VC multiplexed or LLC
   encapsulated.

4. Service model issues

4.1 Authentication

   In case of ATM switched VC establishment, calling party number
   information may be used for first level authentication much in the
   same way as for PSTN or ISDN access.  In case of permanent VC
   establishment, authentication may not be an issue from the LAC side,
   because of the permanent character of the VC.  Bilateral agreement
   between LAC and LNS providers may eliminate the authentication phase