Suhail Nanji INTERNET DRAFT Redback Networks, Inc. Category: Informational Title: draft-nanji-l2tp-eth-00.txt Date: June 2000 Ethernet Encapsulation Extensions to Layer Two Tunneling Protocol 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 , and expires December, 2000. Please send comments to the authors. Abstract The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for tunneling PPP [2] packets. This document describes an extension to L2TP which will allows for Ethernet frames to be transported over a session in an L2TP tunnel. These extensions provide added functionality, but are optional and preserve compatibility. Also, the same tunnel SHALL carry both PPP and Ethernet L2TP sessions if needed. Nanji [Page1] INTERNET DRAFT June 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. This extension to L2TP provides for this type of functionality to be provided to users accessing the network via Ethernet, including bridged Ethernet frames. 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 [3]. 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. Tunnel Establishment The basic tunnel establishment procedures defined in [1] are unchanged. The only addition is a new AVP for indicating if this tunnel will support Ethernet framing. 3.1 Ethernet Framing Capabilities AVP Ethernet Framing Capabilities 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| 10 | 2352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|E|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Redback Networks vendor specific Framing Capabilities AVP within a Start-Control-Connection-Request (SCCRQ) or Start-Control- Connection-Reply (SCCRP) indicates the sender of this message can provide Ethernet framing over L2TP. The vendor code is 2352 and the Nanji [Page2] INTERNET DRAFT June 2000 Attribute value is 3. The Value field is a 32-bit quantity, with one bit defined. If bit E is set, Ethernet framing is supported. This AVP provides the peer with an indication if Ethernet framing will be accepted or initiated by the sender. A peer should not initiate an incoming or outgoing call with a Framing Type AVP specifying a value not advertised in the Framing Capabilities AVP it received during control connection establishment. Attempts to do so will result in the call being rejected. 4. Session Establishment The basic call establishment procedures defined in [1] are unchanged. The only addition is a new AVP for indicating if this session will support Ethernet framing. Currently, Ethernet framing is only supported for incoming call requests (ICRQ). 4.1 Ethernet Bearer Type AVP Bearer Type 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| 10 | 2352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 E 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Redback Networks vendor specific Bearer Type AVP encodes if the bearer type for the incoming call is Ethernet. The vendor code is 2352 and the Attribute value is 18. This AVP is optional. The Value is a 32-bit field indicating if the bearer capability being used by the incoming call is Ethernet. If set, bit E indicates that the call is originating from an Ethernet client and the payload packets for this call will transport Ethernet frames. 5. Ethernet Payload Message Format The L2TP payload header will be unchanged and as described in [1]. However, instead of carrying a PPP packet, the payload will carry an Ethernet frame starting from the MAC addresses. Nanji [Page3] INTERNET DRAFT June 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 June 2000 6. Migration to Standard Attributes It is intended that the Redback Networks vendor specific attributes described above will be migrated to standard attributes. Specifically, the standard Framing Capabilities AVP (SCCRQ, SCCRP) and Bearer Type AVP (ICRQ) will be extended to use the bits reserved for future use and the vendor specific attributes will be deprecated. 7. Authentication Considerations All issues dealing with authenticating the incoming Ethernet client are beyond the scope of this document. 8. Acknowledgments Thanks to Bill Palter for his help in reviewing this draft. Copious amounts of text were stolen from the L2TP INTERNET DRAFT [1]. 9. References [1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", INTERNET DRAFT, February 1999 [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses: Suhail Nanji Redback Networks, Inc. 350 Holger Way San Jose, CA 95134-1362 United States of America Nanji [Page5]