Re: Fwd: IETF work on extended Ethernet frames
All-
(Please note that Andrew is no longer with Extreme Networks so he probably
did not see earlier iterations of this message.)
This issue has come up several times in 802.3. It has significant problems
in terms of compatibility with the installed base. Ted Schroeder, one of
the authors of the RFC counseled with me at length before deciding not to
pursue it in 802.3.
The problem is that it is very easy to do in the standard and hard to do in
the world. It is just like changing the gauge on railroad tracks. All you
have to do is change one line in the standard, never mind all of the rails
you have to move.
Most of the gear produced that is compliant would be intolerant of greatly
longer frames. There is no way proposed to distinguish between frame types
in the network. Bridges and repeaters would drop or truncate (and cause
errors doing so) frames right and left for uncharacterized reasons. It
would be a mess.
It's all okay for small carefully characterized networks. It would be very
difficult to do across the standard.
In addition it would have to have a consensus in 802.3 and a waiver from
the 5 Criteria.
Geoff
At 11:17 AM 7/24/00 -0400, Floyd_Backes@3com.com wrote:
>From: Floyd_Backes@3com.com
>X-Lotus-FromDomain: 3COM
>To: Tony Jeffree <tony@jeffree.co.uk>
>cc: "Thompson, Geoff " <gthompso@americasm06.nt.com>, jcarlo@ti.com,
> mick_seaman@ieee.org, Andrew@extremenetworks.com
>Message-ID: <88256926.0054882D.00@hqoutbound.ops.3com.com>
>Date: Mon, 24 Jul 2000 11:17:42 -0400
>Subject: Re: Fwd: IETF work on extended Ethernet frames
>
>Not to seem too territorial here, but the people who have experience dealing
>with this sort of thing attend P802. It's easy to define a new ethertype, but
>it's not too easy to figure out what happens when these frames get (sometimes)
>forwarded by bridges. I would expect discussions of this type to take place
>there.
>
>floyd.
>
>Tony Jeffree <tony@jeffree.co.uk> on 07/24/2000 01:56:41 AM
>Sent by: Tony Jeffree <tony@jeffree.co.uk>
>
>To: stds-802-1@ieee.org
>cc: (Floyd Backes/HQ/3Com)
>Subject: Fwd: IETF work on extended Ethernet frames
>
>
> >Envelope-to: tony@jeffree.co.uk
> >From: "Jim Carlo" <jcarlo@ti.com>
> >To: "IEEE802" <stds-802-sec@ieee.org>
> >Cc: "Mick Seaman" <mick_seaman@ieee.org>,
> > "Andrew Smith" <Andrew@extremenetworks.com>
> >Subject: IETF work on extended Ethernet frames
> >Date: Sun, 23 Jul 2000 23:13:32 -0500
> >
> >
> >Geoff, has this item come up in 802.3? This affects mainly 802.3, somewhat
> >802.1, and other groups that use the Ethernet Frame. Should 802 have a
> >response here?
> >
> >Jim Carlo(jcarlo@ti.com) Cellular:1-214-693-1776 Voice&Fax:1-214-853-5274
> >TI Fellow, Networking Standards at Texas Instruments
> >Chair, ISO/IEC JTC1/SC6 Telecom and Info Exchange Between Systems
> >Chair, IEEE802 LAN/MAN Standards Committee
> >
> >
> >
> >Network Working Group Mike O'Dell
> >Internet Draft Jed Kaplan
> >Expiration Date: November 1999 UUNET
> >Technologies, Inc.
> >
> > John Hayes
> > Ted Schroeder
> > Alteon
> > WebSystems, Inc.
> >
> > P.J. Singh
> > Packet Engines,
> Inc.
> >
> > Daemon Morrell
> > Juniper Networks,
> > Inc.
> >
> > Jennifer Hsu
> >
> >
> >
> > Extended Ethernet Frame Size Support
> >
> > draft-kaplan-isis-ext-eth-02.txt
> >
> >
> >1. 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/lid-abstracts.txt
> >
> > The list of Internet-Draft Shadow Directories can be accessed at
> > http://www.ietf.org/shadow.html
> >
> >
> >2. Abstract
> >
> > This document presents an extension to current Ethernet Frame
> > standards to support payloads greater than 1500 Bytes for
> Ethernet_II
> > and 802.3 frames. This is useful for Gigabit Ethernet technology,
> > providing a means to carry large MTU packets without fragmentation
> > over a high-speed broadcast network.
> >
> >3. Overview
> >
> > There are two fundamental frame types defined for Ethernet:
> > Ethernet II [ETH] [RFC894] and 802.3 [IEEE802.3]. 802.3 headers
> > may be followed by a Logical Link Control header,
> > 802.2 [IEEE802.2]. Both types of encapsulations can co-exist on
> > the same media at the same time. Encodings for Ethernet II and
> 802.3
> > frames evolved such that, as long as payloads were less than 1500
> > bytes, Ethernet II frames could always be distinguished from
> > IEEE 802.3 frames.
> >
> > However, when the payload is greater than 1500 bytes frames may
> > not be uniquely distinguishable as conforming to Ethernet II or
> > 802.3 formats. This document extends the Ethernet frame format
> > to allow Ethernet_II or 802.3 frame payloads larger than 1500 bytes
> > to be uniquely distinguished.
> >
> >4. Ethernet Frame Formats
> >
> > A. Ethernet II
> >
> > +----+----+------+------+-----+
> > | DA | SA | Type | Data | FCS |
> > +----+----+------+------+-----+
> >
> > DA Destination MAC Address (6 bytes)
> > SA Source MAC Address (6 bytes)
> > Type Protocol Type (2 bytes)
> > Data Protocol Data (46 - 1500 bytes)
> > FCS Frame Checksum (4 bytes)
> >
> > B. IEEE 802.3 and derivatives
> >
> > +----+----+------+------+-----+
> > | DA | SA | Len | Data | FCS |
> > +----+----+------+------+-----+
> >
> > DA Destination MAC Address (6 bytes)
> > SA Source MAC Address (6 bytes)
> > Len Length of Data field (2 bytes)
> > Data Protocol Data (46 - 1500 bytes)
> > FCS Frame Checksum (4 bytes)
> >
> > The derivatives include LLC (802.2) and SNAP which prefix the
> > data field with an LLC header. In these instances the Len field
> > then corresponds to the combined size of both the data portion
> > of the frame and the LLC header.
> >
> > On reception, the two formats are differentiated based on the
> > magnitude of the Type/Length field, as follows:
> >
> > > 1500 bytes: value corresponds to a type field. The frame is an
> > Ethernet II frame, with type values starting
> > at 1536 (600 hex).
> >
> > <= 1500 bytes: value corresponds to a length field. The frame is
> > an IEEE 802.3 format (or derivative) with a maximum
> > data length of 1500 bytes.
> >
> >5. Problem with Large 802.3 Frames in the presence of Ethernet_II Frames
> >
> > Some protocols commonly used in the Internet have no reserved
> > Ethertype.
> > An example is the set of ISO Network layer protocols, of which
> > ISIS is a member. Such protocols are only defined to use the IEEE
> > 802.3/802.2 encoding, and so their packets are limited in length to
> > 1500 bytes.
> >
> > Ethernet_II frames have no length field. Protocols encapsulated in
> > Ethernet II frames, such as IP, are not limited in length to 1500
> > bytes by framing.
> >
> >6. Proposed Ethernet Frame Extension
> >
> > Large 802.3 and Ethernet_II frames can be supported by the
> following:
> >
> > + Define an Ethertype for 802.3, 0x8870, and encode large frames
> > (where the data field is greater than 1500 bytes),
> > exclusive of the Destination MAC address, Source MAC address,
> > and Data length fields, within Ethernet II.
> >
> > Large 802.3/802.2 frames would have the following fields:
> >
> > +----+----+------+------+------+------+------+-----+
> > | DA | SA | Type | DSAP | SSAP | Ctrl | Data | FCS |
> > +----+----+------+------+------+------+------+-----+
> > === 802.2 Header ===
> >
> > DA Destination MAC Address (6 bytes)
> > SA Source MAC Address (6 bytes)
> > Type 0x8870 (Ethertype) (2 bytes)
> > DSAP 802.2 Destination Service Access Point (1 byte)
> > SSAP 802.2 Source Service Access Point (1 byte)
> > Ctrl 802.2 Control Field (1 byte)
> > Data Protocol Data ( > 46
> bytes)
> > FCS Frame Checksum (4 bytes)
> >
> > + Allow Ethernet II frames to have payloads greater than 1500
> bytes.
> >
> > There is no loss of information from 802.3/802.2 frames. Although
> > the 802.3 length field is missing, the frame length is known by
> > virtue of the frame being accepted by the network interface.
> >
> > In this manner, all Ethernet II frames, including large 802.3
> > packets, can be longer than 1500 bytes, yet are uniquely
> identified.
> >
> >
> >7. References
> >
> >[ETH] "The Ethernet - A Local Area Network", version 1.0, Digital
> >Equipment Corporation, September 1980, and "The Ethernet, A Local
> >Area Network" Data Link Layer and Physical Layer Specifications",
> >Digital, Intel, and Xerox, November, 1982.
> >
> >[RFC894] IETF RFC 894
> >
> >[IEEE802.3] IEEE Std 802.3
> >
> >[IEEE802] IEEE Std 802
> >
> >[IEEE802.3Z] IEEE Std 802.3z
> >
> >[EXT.FRAME] "Use of Extended Frame Sizes in Ethernet Networks", draft
> >2.1, Alteon Networks, Inc.
> >
> >
> >8. Author's Addresses
> >
> >Mike O'Dell
> >UUNET an MCI WorldCom Company
> >3060 WIllaims Drive
> >Fairfax, Va. 22031-4648
> >703-206-5890
> >email: mo@uu.net
> >
> >Jed Kaplan
> >UUNET an MCI WorldCom Company
> >3060 WIllaims Drive
> >Fairfax, Va. 22031-4648
> >914-701-5309
> >email: jkaplan@uu.net
> >
> >John Hayes
> >Alteon WebSystems, Inc.
> >50 Great Oaks Blvd.
> >San Jose, CA 95119
> >408-360-5507
> >email: hayes@alteon.com
> >
> >Ted Schroeder
> >Alteon WebSystems, Inc.
> >50 Great Oaks Blvd.
> >San Jose, CA 95119
> >408-360-5500
> >email: ted@alteon.com
> >
> >P.J. Singh
> >Packet Engines, Inc.
> >11707 East Sprague #101
> >Spokane WA 99206
> >509-777-7000
> >email: pjsingh@packetengines.com
> >
> >Daemon Morrell
> >Juniper Networks, Inc.
> >12343-D Sunrise Valley Drive
> >Reston, VA 20191
> >email: dmorrell@juniper.net
> >
> >Jennifer Hsu
> >jhsu@mur.com