PPP Extensions Working Group                         Mike Davison, Cisco
INTERNET DRAFT                               Arthur Lin, Shasta Networks
April, 1999                                         Ajoy Singh, Motorola
Expires October 18, 1999                   John Stephens, Cayman Systems
                                                Rollins Turner, Paradyne
                                                 J. Senthilnathan , 3Com


                      L2TP Over AAL5 and FUNI

                 <draft-ietf-pppext-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 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

     The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
     method for transporting the link layer of PPP [2] 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. Both ATM UNI [3] with ATM Adaptation Layer 5 [4]
     (AAL5) and ATM with Frame based User-to-Network Interface (FUNI)
     [5] 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.


draft-ietf-pppext-l2tp-atm-02.txt                            [Page 1]


1. Introduction

The Point-to-Point Protocol, PPP, [2] 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) [1] 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 [1] 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" [1]. An ATM network, with either
AAL5 or FUNI, offers a suitable form of packet oriented connection.

This standard supplements [1] by providing details specific to the use
of AAL5 and FUNI for the point-to-point connection between LAC and LNS.


2. Conventions

2.1 Requirements Keywords

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document,
are to be interpreted as described in [6].

2.2 Terminology

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.


draft-ietf-pppext-l2tp-atm-02.txt                            [Page 2]


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.  (PPP refers to this as Maximum Receive
Unit, or MRU [2].  In the UNI 3.1 specification it is Forward and
Backward Maximum CPCS-SDU Size [3].)

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, and possibly different
qualities of service to different client connections, an implementation
MAY use more than one AAL5 connection between LAC and LNS.

A tunnel is initially created over an AAL5 connection.  A subsequent
call to the LAC may require that the LAC open a new AAL5 connection to
satisfy QoS requirements of that call. If an implementation determines
that multiple tunnels are required to a given peer, each tunnel SHALL be
based on a separate AAL5 connection.


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.

4. Multi-Protocol Encapsulation

This specification uses the principles, terminology, and frame structure
described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
[7] (RFC 1483).  The purpose of this specification is not to reiterate
what is already standardized in [7], but to specify how the mechanisms
described in [7] are to be used to map L2TP onto an AAL5-based ATM
network.  (There is a current internet draft [17] updating [7].)





draft-ietf-pppext-l2tp-atm-02.txt                            [Page 3]


As specified in [7], L2TP PDUs shall be carried in the Payload field of
Common Part Convergence Sublayer (CPCS) PDUs of ATM Adaptation Layer
type 5 (AAL5), and the Service Specific Convergence Sublayer (SSCS) of
AAL5 shall be empty.


Section 1 of [7] 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 switched VC connections, it MUST use the
Q.2931 [8] Annex C procedure to negotiate connection setup, encoding the
Broadband Lower Layer Interface (B-LLI) information element 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 [9]
service inter-working unit, then it MUST use LLC encapsulated L2TP.













draft-ietf-pppext-l2tp-atm-02.txt                            [Page 4]


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

     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 to be determined by IANA.

     3. The L2TP PDU.


          +-------------------------+ --------
          |  Destination SAP (0xAA) |     ^
          +-------------------------+     |
          |  Source SAP      (0xAA) |  LLC header
          +-------------------------+     |
          |  Frame Type = UI (0x03) |     V
          +-------------------------+ --------
          |  OUI        (0x00-00-5E)|     |
          +-+-+-+-+-+-+-+-+-+-+-+-+-|  SNAP Header
          |  PID        (2 octets)  |     |
          +-------------------------+ --------
          |                         |     ^
          |                         |     |
          |                         |  L2TP PDU
          |                         |     |
          |                         |     |
          |                         |     V
          +-------------------------+ --------


                             Figure 1.

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.
However, they MUST NOT send packets belonging to any protocol that has
an active NCP within a PPP session carried by the L2TP tunnel.





draft-ietf-pppext-l2tp-atm-02.txt                            [Page 5]


6. Virtual Circuit Multiplexed L2TP Over AAL5

VC-multiplexed L2TP over AAL5 is an alternative technique to LLC
encapsulated L2TP over AAL5 when both LAC and LNS use AAL5 as opposed to
FUNI.  In this case the L2TP PDU is the AAL5 Payload.  This is sometimes
called "Null encapsulation."

The AAL5 CPCS PDU format is shown in 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
               +-------------------------------+ -------

                                Figure 2.

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

draft-ietf-pppext-l2tp-atm-02.txt                            [Page 6]


7. Out-Of-Band Control Plane Signaling

7.1 Connection Setup

A switched VC 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.

When originating a switched virtual circuit AAL5 connection, the caller
MUST request in the SETUP message either VC-multiplexed L2TP, LLC
encapsulated L2TP, or else both VC-multiplexed and LLC-encapsulated
L2TP.  The Broadband Low Layer Information (B-LLI) information element
SHALL be used to specify the requested encapsulation method.  When a
caller is offering both techniques, the two B-LLI information elements
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
implementation MUST reject a call set up 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 ITU Q.2931 [8] B-LLI element user information layer 2
protocol field SHALL be encoded to select LAN Logical Link Control
(ISO/IEC8802-2) in octet 6.  See RFC 1755 [11] appendix A for an
example.

When originating a VC-multiplexed call that is to carry an L2TP payload,
the ITU Q.2931 [8] B-LLI element user information layer 3 protocol field
SHALL be encoded to select ISO/IEC TR 9577 [10] in octet 7.  The
extension octets specify an IPI value of L2TP (TBD).  The AAL5 frame's
payload field will always contain an L2TP 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 [1], both
ends MUST clear the connection.  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.

draft-ietf-pppext-l2tp-atm-02.txt                            [Page 7]


7.3   Connection Teardown

When there are no active sessions on an SVC tunnel, either end MAY
optionally clear the connection.

[Note:  There is a race condition when one end starts to clear the
connection at the same time the other end starts to establish a new
session.  Further work is needed here.]


8. Detection And Recovery From Unsolicited L2TP Encapsulation
Transitions

[This section requires futher work.]


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

If an AAL5 PVC enters the "Stopped" state, an implementation SHALL tear
down the tunnel and return the control connection to the Idle state.


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

The L2TP base protocol provides a mechanism for tunnel authentication
during the Establishment phase.  This authentication has the same
security attributes as CHAP [12, 13], and provides reasonable protection
against replay attacks.

Since L2TP encapsulates a PPP payload, the same PAP/CHAP authentication
protocols that are widely used for Internet dial up access can be used
at both LAC and LNS to authenticate tunnel users.  PPP encryption [14,
15] can also be used to encrypt the PPP payload through L2TP.  As a
consequence, L2TP Over AAL5 security is at parity with those practices already
established by the existing Internet infrastructure.

Those applications that require stronger security are encouraged to use
authentication headers, or encrypted payloads, and/or ATM-layer security
services [16], when such services become available.

Note:  When using LLC-encapsulated L2TP over a virtual connection, an
end point cannot assume that the PPP session authentication and related
security mechanisms also secure the other LLC encapsulated flows on that
same virtual connection.


draft-ietf-pppext-l2tp-atm-02.txt                            [Page 8]


11. Acknowledgments

This Internet Draft draws heavily on material in Internet Draft "PPP
Over ATM," <draft-ietf-pppext-aal5-06.txt>, April 30, 1998, 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,
and Rohit Verma; and an earlier internet draft on L2TP Over AAL5 and FUNI by
by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.

Rene Tio contributed to the development of this draft.

12. References

[1]  Rubens, A., et al., Layer Two Tunneling Protocol "L2TP",
     Internet Draft <draft-ietf-pppext-l2tp-14.txt> Feb. 1999.
     Work in Progress.

[2]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
     51, RFC 1661, July 1994.

[3]  The ATM Forum, "ATM User-Network Interface Specification V3.1",
     af-uni-0010.002, 1994.

[4]  International Telecommunication Union, "B-ISDN ATM Adaptation Layer
     (AAL) Specification", ITU-T Recommendation I.363, March, 1993.

[5]  The ATM Forum, "Frame based User-to-Network Interface (FUNI)
     Specification v2", af-saa-0088.000, May 1997.

[6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, Harvard University, March 1997.

[7]  Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
     Layer 5", RFC 1483, July 1993.

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

[9]  The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working
     Implementation Agreement", FRF.8, April 1995.

[10] ISO/IEC DTR 9577.2, "Information technology - Telecommunications
     and Information exchange between systems - Protocol Identification
     in the network layer", 1995-08-16.

[11] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
     "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.

[12] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 1334,
     Oct. 1992.

draft-ietf-pppext-l2tp-atm-02.txt                            [Page 9]


[13] W. Simpson, "The PPP Challenge Handshake Authentication Protocol
     (CHAP)", RFC 1994, August 1996.

[14] G. Meyer, "The PPP Encryption Control Protocol (ECP)", RFC 1968,
     June 1996.

[15] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol (DESE)",
     RFC 1969, June 1996.

[16] ATM Forum Technical Committee, "ATM Security Framework V1.0",
     Feb. 1998.

[17] J. Heinanen, D. Grossman, "Multiprotocol Encapsulation over
     ATM Adaptation Layer 5", Internet Draft <draft-ietf-ion-multiprotocol-
     atm-00.txt> Oct. 1998. Work in Progress.


Chair's Address

The PPP Extensions working group can be contacted via the current chair:

     Karl Fox
     Ascend Communications
     3518 Riverside Drive, Suite 101
     Columbus, Ohio 43221

     EMail: karl@ascend.com



Editor's Address

Questions about this memo can also be directed to:

    Rollins Turner
    Paradyne Corporation
    8545 126th Avenue North
    Largo, FL 33773
    Tel: +1.727.530.2629
    Email: rturner@eng.paradyne.com

    Ajoy Singh
    Motorola
    1421 West Shure Dr,
    Arlington Heights, IL 60004
    Tel: +1.847.632.6941
    Fax: +1.847.632.5181
    Email: asingh1@email.mot.com















draft-ietf-pppext-l2tp-atm-02.txt                            [Page 10]


Appendix A. Acronyms

AAL5    ATM Adaptation Layer Type 5

ATM     Asynchronous Transfer Mode

B-LLI   Broadband Low Layer Information

CPCS    Common Part Convergence Sublayer

FUNI    Frame based User-to-Network Interface

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 Protcol

SVC     Switched Virtual Circuit

VC      Virtual Circuit





draft-ietf-pppext-l2tp-atm-02.txt                            [Page 11]