Re: Fwd: IETF work on extended Ethernet frames
They have a workable system at the Russian/Chinese border in Manjouli: a machine
lifts the carriages (with sleeping passengers inside, or at least those who
aren't under interrogation by the Chinese authorities) off their wheels, swaps
out the bogies for narrower ones and puts the carriages back down again. The
process takes most of the night. I think they also have a more elegant system at
the French/Spanish border (in Biarritz is it?) that just slides the wheels along
their axles. If these were along competing routes from, say Africa to North
America then one would clearly have an advantage. Moral: products can be built
that work around the historical failings of the standards' committees (and peace
treaties) but these things will always remain unnatural acts (802.1H falls into
the same bucket of course) and the standards' committees ought to do as much as
they can to discourage, rather than endorse, such hacks (invasion, though, is
not really an option in this case).
BTW, it's hopeless talking to many customers (OK, my former employer's
customers), particularly in the ISP space, about perhaps not needing to support
jumbo frames in their gigabit+ cores: there is no hope, at least in the
short-term, of their deployment (or perception of the need for deployment)
dimishing. And they're not interested that the percentage of their traffic using
>1500 MTU is decreasing as the percentage of "Ethernet-like"-attached (i.e. including most forms of DSL, Cable and real-Ethernet) end stations increases: they often just want to be able to show high-throughput benchmarks across their core.
BTW, this really *is* a wedge tactic, despite IETF's official protestations that
this draft is just meant for carrying IS-IS routing protocol frames (the IS-IS
working group is the intended sponsor of this draft): the primary authors of the
draft and their employers (former-employers in some cases, so I guess PJ is off
the hook now) are mostly LAN switching people, not routing protocol people, so
it is quite disingenuous of them to pretend that this is anything other than
trying to play off Mum (IEEE) against Dad (IETF). The equipment vendors listed
on this draft are of course attempting to use the standards to endorse
capabilities of their own implementations (but that's what standards are for,
right? I guess nobody should really cast the first stone there ....).
This issue is one that Scott Bradner (sob@harvard.edu) ought to be interested
in, as a key person in IETF relations with other standards' bodies.
Andrew
(speaking for no-one but himself these days)
Geoff Thompson wrote:
>
> 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