Subject: L2TP Circuit Emulation Services Extension

From: Danny McPherson <[email-masked]>
Date: Wed, 3 May 2000 13:39:21 -0700

Comments welcome.

-danny

[]
L2TP Working Group                                       Danny McPherson
Internet Draft                                            Ravi Bail Bhat
                                                          Andy Koscinski
                                                              Chi Fai Ho
                                                          Amber Networks
draft-mcpherson-l2tpext-es-00.txt                               May 2000

               L2TP Circuit Emulation Services Extension

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 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism
   for tunneling PPP sessions.  This document proposes mechanisms by
   which the L2TP tunneling scheme can be used to provide circuit
   emulation support for layer 2 circuits (i.e. Frame Relay or ATM), as
   well as TDM circuits (i.e. DS1 or DS3).  L2TP is used to provide
   tunneling support and each circuit is encapsulated over a session
   inside the Tunnel.

   An Encapsulation Services Protocol [RefESP] is used on top of the
   individual L2TP sessions to support the circuit emulation of layer
   2 VCs or TDM circuits.  The purpose of this document is to explain
   the L2TP modifications done to facilitate support of circuit 
   emulation services, as well as to define the additional AVPs that can
   be used to provide the service.

Specification of Requirements

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

Table of Contents

      1. Introduction
      2. Topology Model
         2.1 Modified L2TP Topooofy Model
      3. Protocol Overview
      4. Proposed Protocol Operation
         4.1 Service Type AVP Format
         4.2 Proposed Sub-Address in ICRQ
      5. Quality of Service Considerations
      6. Security Considerations
      7. Intellectual Property Considerations
      8. References
      9. Authors' Addresses

1. Introduction

   The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism
   for tunneling PPP sessions.  This document describes mechanisms by
   which L2TP tunneling scheme can be used to provide circuit emulation
   support for layer 2 circuits (i.e. Frame Relay or ATM), as well as
   TDM circuits (i.e. DS1 or DS3).  L2TP is used to provide tunneling
   support and each circuit is encapsulated over a session inside the
   Tunnel.

   An Encapsulation Services Protocol [RefESP] is used on top of the
   individual L2TP sessions to support the circuit emulation of
   layer 2 Virtual Circuits or TDM circuits.  The purpose of this
   document is to explain the L2TP modifications done to facilitate
   support of circuit emulation services, as well as to define the
   additional AVPs required to provide the service.

2. Topology Model

   The current L2TP model assumes a client/server architecture between
   the LAC and LNS.  To support encapsulations services, a symmetric
   LAC-to-LAC model is proposed.  In this model, a tunnel (with one or
   more sessions sessions) can be established between two LACs.

   A tunnel is setup for a particular service or set of services (e.g.
   FR_GOLD) between a pair of LACs that support circuit emulation
   services.  The Service Type is sent to the peer LAC via a newly
   defined vendor- specific AVP.  Then for each connection within the
   service group (e.g. FR_GOLD), a session is initiated (possible from
   either side).  The connection identifiers for the two legs of the
   connection (e.g.  the Frame Relay interface and the Frame-Relay DLCI)
   are sent in the Sub-Address AVP.

2.1. Modified L2TP Topolgy Model (LAC/LAC)

   The following diagram depicts a typical L2TP LAC/LAC scenario.  The
   goal is to tunnel lower-layer (layer 1 or layer 2) frames from the
   one LAC to the another LAC.

       FR-------+             +-------------+            +---- FR
                |----         |             |        ----|
                      LAC1 ---| Internet    |--- LAC2
                |----         |             |        ----|
       TDM------+             +-------------+            +---- TDM
                                     |
                                     |
                                    LAC3
                                    |  |
                                 ---+  +---
                                 |        |
                                 |        |
                                FR       TDM

3. Protocol Overview

   As shown in the figure below, the L2TP protocol structure is modified
   to carry any protocol (Note: The current specification only
   identifies support for PPP frames). An encapsulation protocol with
   both data and control messages is carried over L2TP protocol.

                               +-----------------------+
      +-------------------+    | any protocol control  |
      | any payload       |    | messages              |
      +-------------------+    +-----------------------+
      | L2TP Data Messages|    | L2TP Control Messages |
      +-------------------+    +-----------------------+
      | L2TP Data Channel |    | L2TP Control Channel  |
      | (unreliable)      |    | (reliable)            |
      +------------------------------------------------+
      |      Packet Transport (UDP, FR, ATM, etc.)     |
      +------------------------------------------------+

4. Proposed Protocol Operation

   Encapsulation Services (ES) enable an IP network to support emulation
   of connection-oriented networks like FR and ATM, as well as TDM
   circuit emulation.  ES supports different Emulation Types and also
   supports multiple service profiles. The Emulation Type and the
   Service Type are represented by an optional AVP "Service Type". The
   AVP MUST be present in both SCCRQ and SCCRP messages and MUST match
   one another, otherwise the tunnel is dropped.

   At least one L2TP tunnel is opened for every Emulation Type. Multiple
   tunnels may be opened for each Emulation Type if different Service
   Types are needed.  Each circuit (e.g. DLCI in FR) is mapped into a
   L2TP session and carried transparently to the other end.  During the
   session request, the endpoint connection identifiers are transported
   in the Sub-Address AVP.

   Once the L2TP session is established, the upper layer encapsulation
   protocol MAY exchange additional information to complete the circuit
   emulation establishment.  After that, the LACs start to transmit data
   between one another.

4.1. Service Type AVP Format

   The Service Type AVP MUST be present in SCCRQ and SCCRP message.  This
   AVP is used to inform the tunnel peer that a specific Service Type
   (e.g. FR_GOLD) is used.

   Vendor ID = 4741 Attribute Type = 1

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|  Length           |            4741               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                1              |Service Type (arbitrary length)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP is encoded as a Vendor ID of 4741, which reflects Amber
   Networks, the initial developer of this specification. The Vendor ID
   SHOULD be changed to "0" and an official attribute value chosen, if
   this specification advances on the standard tracks. The Attribute
   Type is the 16 bit quantity "1". This AVP MAY be hidden and is
   mandatory (mandatory bit = 1). The L2TP peer is indicating that 
   resources adequate to the Service Type identified by the AVP are 
   required.

   In the event that the peer does not accept the requested Service
   Type, a stopCCN is returned to the peer. Such stopCCN message will
   include the Service Type AVP as provided in the message that caused
   the stopCCN.

4.2. Proposed Sub-Address in ICRQ

   The Sub-Address AVP, Attribute Type 23, encodes additional connection
   identifier information.

   The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-Address ... (arbitrary number of octets)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Sub-Address is an opaque sequence of octets transmitted
   transparently by the network. The tunnel end points MUST, a priori,
   understand the meaning of the value in this AVP.

   The general format of the information in this AVP is:

   1.  Calling party Sub-Address (iterations of: InfoType, Length,
       Connection Information, e.g. interface and DLCI for FR);

   2.  Called party Sub-Address (iterations of: InfoType, Length,
       Connection Information, e.g. interface and DLCI for FR);

   This AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 6
   octets plus the length of the Sub-Address.

5. Quality of Service Considerations

   Quality of Service (QoS) is a necessity for circuit emulation
   applications.  The QoS mechanisms such as those proposed for L2TP in
   [L2TP-DS] and [L2TP-MPLS] should be considered.  Additional
   discussion of this topic is beyond the scope of this document.

6. Security Considerations

   This document does not introduce security considerations beyond those
   listed in [RFC1661].

7. Intellectual Property Considerations

   Amber Networks may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Amber Networks, Amber
   intends to disclose those patents and license them on reasonable and
   non-discriminatory terms.

8. References

      [RFC2661]   W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall,
                  G. Zorn, B. Palter, "Layer Two Tunneling Protocol
                  (L2TP)", RFC 2661, August 1999.

      [RefESP]    McPherson, D., et al., "Encapsulation Services 
                  Protocol (ESP)", "Work in Progress".

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

      [L2TP-DS]   Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol
                  "L2TP" IP Diferentiated Services Extension", "Work in
                   Progress".

      [L2TP-MPLS] Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol 
                  "L2TP" Multi-Protocol Label Switching Extension", 
                  "Work in Progress".

9. Authors' Addresses

   Danny McPherson
   Amber Networks
   2465 Augustine Drive
   Santa Clara, CA  95054
   Phone: +1 408.486.6336
   Email: [email-masked]

   Ravi Bail Bhat
   Amber Networks
   2465 Augustine Drive
   Santa Clara, CA  95054
   Phone: +1 408.845.5597
   Email: [email-masked]

   Andy Koscinski
   Amber Networks
   2465 Augustine Drive
   Santa Clara, CA  95054
   Phone: +1 408.845.5536
   Email: [email-masked]

   Chi Fai Ho
   Amber Networks
   2465 Augustine Drive
   Santa Clara, CA  95054
   Phone: +1 408.845.5547
   Email: [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Fri, 26 May 2000 10:56:27 -0600

Folks,
I'm getting ready to post a revision to draft-mcpherson-l2tp-es-00.txt 
to the I-D directory and would like to solicit additional comments 
beforehand.

I'd also like to understand concerns of anyone with objections to 
adopting the draft as a working group item.  I've already asked the
chair to request expansion of the WG charter from the AD.

Thanks to everyone that's provided feedback so far, and thanks in 
advance to those who are planning to!

-danny

P.S.  The mailing list archives are still in need of attention ..
and the 'list subscribers' access should be disabled or restircted 
to avoid future spam incidents.