[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                       Suhail Nanji
INTERNET DRAFT                                    Redback Networks, Inc.
Category: Standards Track
Title: draft-ietf-l2tpext-eth-00.txt
Date: November 2000



         Ethernet Service Type for Layer Two Tunneling Protocol
                    <draft-ietf-l2tpext-eth-00.txt>


                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   ietf-l2tpext-eth-00.txt>, and expires May, 2001.  Please send
   comments to the authors.


Abstract

   The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard
   method for tunneling PPP [RFC1661] packets.  In accordance with the
   Layer Two Tunneling Protocol (L2TP) Service Type draft
   [L2TP_svctype], this document describes the details for transporting
   Ethernet frames over a session in an L2TP tunnel.  That is, the
   details of an Ethernet service type for L2TP sessions.





Nanji                                                           [Page1]

INTERNET DRAFT                                             November 2000


1. Introduction

   With L2TP it is possible to divorce the location of the initial dial-
   up server from the location at which the dial-up protocol connection
   is terminated and access to the network provided.  However, this is
   only possible if PPP is used to access the network.  The L2TP Service
   Type draft describes how other payload types may be tunneled on a
   session by session basis over L2TP.  This document describes how
   Ethernet frames may be tunneled over an L2TP session as a new service
   type as described by the L2TP Service Type draft.

   It is possible to use PPP Bridging Control Protocol (BCP) as
   specified in [RFC2878] to transport the Ethernet frame over L2TP
   without employing a new service type.  However, using BCP might not
   be feasible since the Ethernet client may not support BCP.
   Furthermore, the service type approach has less protocol overhead
   than using BCP.


2. Conventions

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

   Ethernet in this document refers to both DIX Ethernet and IEEE 802.3.
   It is assumed the receipient of an Ethernet frame has the
   capabilities to distinguish between the two different Ethernet
   encapsulations.  Both Ethernet types MAY be used on the same L2TP
   session.


3. Ethernet Service Type

   A Ethernet srvice type value of 3 MUST be used for the L2TP Service
   Type draft to identify an Ethernet payload.


4. Tunnel Establishment

   The basic tunnel establishment procedures defined in [RFC2661] and
   [L2TP_svctype] draft are unchanged.  The Ethernet service type value
   MUST be included in the Service Capabilities List AVP.








Nanji                                                           [Page2]

INTERNET DRAFT                                             November 2000


5. Session Establishment

   The basic call establishment procedures defined in [RFC2661] and
   [L2TP_svctype] are unchanged.   Currently, Ethernet framing is only
   supported for incoming call requests (ICRQ).  The Ethernet service
   type value MUST be used in the Service Type AVP of an ICRQ. The
   Ethernet service type value MUST NOT be used in the Service Type AVP
   of an OCRQ.  Also, a new AVP MUST be included in the ICRQ which
   contains an Ethernet MAC address from the LAC.

5.1 Ethernet MAC Address AVP

   Ethernet MAC Address

       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|          12       |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              TBD              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Ethernet MAC Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Ethernet MAC Address AVP contains an Ethernet MAC address from
   the LAC in canonical form as specified in [RFC2469].  This value MUST
   be used as the source address for Ethernet frames sent to tunneled
   end stations from the LNS.  The vendor code is 0 and the Attribute
   value is TBD.  This AVP MUST NOT have the manditory bit set.  The
   Value is a 48-bit Ethernet MAC address.


6. Ethernet Payload Message Format

   The L2TP payload header will be unchanged and as described in
   [RFC2661].  However, instead of carrying a PPP packet, the payload
   will carry an Ethernet frame starting from the MAC addresses, which
   MUST be in canonical form as specified in [RFC2469].  In both types
   of Ethernet frames, the CRC is preserved end-to-end.












Nanji                                                           [Page3]

INTERNET DRAFT                                             November 2000


   DIX Ethernet
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |           Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |             Nr (opt)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination MAC Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Source MAC Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Protocol            |             Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IEEE 802.3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |           Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |             Nr (opt)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination MAC Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Source MAC Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |      DSAP     |      SSAP     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       CTL     |           Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Nanji                                                           [Page4]

INTERNET DRAFT                                             November 2000


7. Effects on Standard AVPs

   If Ethernet frames are being tunneled in accordance with this
   document, then the following Call Management AVPs MAY be ignored:

      Bearer Type
      Framing Type
      Called Number
      Calling Number
      Initial Received LCP CONFREQ
      Last Sent LCP CONFREQ
      Last Received LCP CONFREQ
      Proxy Authen Type
      Proxy Authen Name
      Proxy Authen Challenge
      Proxy Authen ID
      Proxy Authen Response
      ACCM


8. Authentication Considerations

   All issues dealing with authenticating the incoming Ethernet client
   are beyond the scope of this document.


9. Security Considerations

   All security considerations with tunneling Ethernet frames over L2TP
   are beyond the scope of this document.


10. Acknowledgments

   Thanks to Bill Palter, Danny McPherson, Mark Townsley and Wei Luo for
   their help in reviewing this draft.  Copious amounts of text were
   stolen from [RFC2661].














Nanji                                                           [Page5]

INTERNET DRAFT                                             November 2000


11. References

   [RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC
   2661, February 1999.

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

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

   [L2TP_svctype] McPherson D., Nanji S., "L2TP Service Type", August
   2000.

   [RFC2469] T. Narten, C. Burton, "A Caution On The Canonical Ordering
   Of Link-Layer Addresses", RFC 2469, December 1998.

   [RFC2878] M. Higashiyama, F. Baker, "PPP Bridging Control Protocol
   (BCP)", RFC 2878, July 2000.


Authors' Addresses:

   Suhail Nanji <suhail@redback.com>
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA  95134-1362
   United States of America























Nanji                                                           [Page6]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/