Ethernet II

Bonsoir,

(1) Can we say that today, Ethernet II, only for its MAC level, is completely specified by IEEE 802.3? (due to the length/type field specification)

(2) And, differently, can we say that Ethernet II is completely specified by IEEE? it would seem that there is no possibility of an empty LLC sub-layer in IEEE, is it correct?

Thanks, Michelot

No. 802.3 in not used, ethernet II is ( except for some more or less broken variants used by novell when using IPX)

First of all, *every layer* is optional. (see footnote) One can ignore any layer they choose, or multiple layers, as long as either: (1) the system doesn't require the functions performed by that layer, (2) the system is willing to be restricted to environments where that layer is not present, or (3) some higher layer entity implements the needed function from the omitted layer.

A common example of (1) is the fact that few systems need or use a Presentation layer; we simply don't need a machine-independent metaformat if we all agree in advance on a common data format to use.

Examples of (2) are LAT or NetBIOS; by omitting any Network Layer, these systems are restricted to use within a single LAN (i.e., they are "unroutable").

An example of (3) is NFS over UDP. UDP lacks the flow and error control of TCP, so those functions must be recreated within NFS (as they are).

Thus, there is never a need in a standard to say, "If you use such-and-such feature, you can eliminate Layer X," since you can eliminate Layer X anytime you like, whether you use some specific feature or not.

That said, there is nothing to stop anyone from using LLC *even with Type encapsulataion*. If for some reason you feel that LLC provides some useful function, you could get a Type field value assigned to LLC, and layer LLC over Ethernet in that manner. There may even be a type field assigned for this purpose; I haven't looked.

My opinion: LLC was useless to begin with, is useless today, and should never have been included in the IEEE standard. (Obviously, it was *not* included in the Ethernet Specification, of which I was a co-author.) The fact that Type fields without LLC are predominant today, and were predominantly used even before they were officially "accepted" by the IEEE, speaks volumes in itself.

(Footnote: Even the *physical* layer is optional. I can build an architecturally-proper network that provides communications between multiple virtual devices within a single machine, and interconnect those devices at any layer I please; e.g. the interstation "pipes" might exist between the Network Layer entities only, with no underlying Data Link or Physical Link at all. It's not a common scenario, but it is theoretically possible, and even useful for development and simulation of protocol behavior.)

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Bonsoir Peter,

(1) As Rich said us, IEEE 802.3 specifies both length and type encapsulation since 1997. So, Ethernet II is specified by IEEE 802.3.

(2) But, as Ethernet II doesn't need a LLC sublayer, IEEE 802.2 doesn't specify Ethernet II.

(3) In my humble opinion, only one thing is subject to discussion. It seems that IEEE has never written something like: "the IEEE 802.3 variant with the type field has no LLC sublayer". And if I am wrong, where can I read that in a IEEE standard?

In the section "Introduction to the IEEE Std 802.3" page iii, we can see

Regards, Michelot

I believe that VMware and Virtual PC both do something like this, allowing virtual machines to communicate via a virtual network using emulated AMD PCnet PCI-II Ethernet NICs in the case of VMware and DEC 21140As in the case of VirtualPC (at least the versions I have), along with an emulated bridge.

I'm not sure I agree totally with this. The reason the Type format is used almost universally today, over Ethernet, is that almost universally today the layer 3 and 4 protocols are IP and UDP or TCP. And any link layer only services provided by the very few DSAP and SSAP values have just never really materialized.

But what's still nice about the LLC layer is that it permits use of a SNAP SAP and a SNAP header. The SNAP header, with its 16-bit Protocol ID field, allows anyone with an OUI to invent protocols and assign Protocol ID fields independent of other entities, such as the IANA or the IEEE.

This can come in handy. I agree with what you said about assigning a Type code that would be followed by an LLC layer, however I don't think such a code exists. I checked at

One application of this, just an illustration, might be the new digital TV standard. In data transmission, it permits LLC/SNAP encapsulation as one of its options. Since the standard applies (primarily but not exclusively) to one-way broadcast, the IP header is not necessarily useful. So, for instance, if a manufacturer wants to broadcast updates for his equipment over the air, one option would be to transmit the updates using only the LLC/SNAP to identify the executable files, and have the appropriate equipment recognize these and run them. All other equipment would ignore these datacasts.

In principle, it would be nice to be able to preserve this scheme even if the digital TV datacast is then forwarded to an in-home Ethernet network. And the fact that such a datacast cannot be routed might even be seen as a "feature."

Bert

Digital tv, if ever coming to live, should be based on multicasting IP/UDP, this is one of the few scalable methods. Inventing new physical layers will only prevent digital tv from ever appearing.

Again, radio and tv is done very well with present unicast and multicast technologies. In fact if actually implemented in wide scale it would replace DAB and digital-encoded aerial TV and radio.

Type field usage was common (and preferred) even before TCP/IP dominated the protocol space. DECnet, IPX (in one incarnation), XNS, and lots of other systems all co-existed using Type encapsulation. The reason it was popular is that it was *simple*, and it worked. The only function required was multiplexing of higher-layer protocols. Type encapsulation performs that function well; LLC does not, absent SNAP.

Yes, and the only popular protocol suite that ever used this feature was AppleTalk. In practice, everyone used the 00-00-00 OUI, which is a signal to interpret the Protocol ID field as an Ethernet Type Field. Thus, all LLC/SNAP does is add 8 bytes to the frame with no added value.

Getting a new Type code assigned is easy, and free. Unlike OUIs, you don't need one for every company that designs Ethernet equipment; you only need one when you want to standardize on a new, interoperable Layer

There is also a "Playpen" Ethertype; that is, a Type field value that is specifically reserved for experimental protocol use.

There is a standard protocol for multicast load of code or updates, with assigned protocol values (see IEEE 802.1E; System Load Protocol). It is especially nice, since it allows simultaneous load of multiple devices through multicasting, with a mechanism for reliable delivery through selective retransmission of missed blocks from any of the multiple receivers.

The "Playpen" Type field allows the system to infer the higher-layer semantics any way it wants (including the fact that there is no Network Layer protocol present at all), as long as the system is "closed" (unrouted).

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Actually, it's OLD. The standard was published in 1990.

It died a quiet death, along with the company that promoted it (Protocol Engines). The idea was nice (i.e., implement a transport protocol in pure hardware), but it was ahead of its time. Because of the hardware limitations at the time, they were unable to implement TCP; thus, they designed a "lightweight" transport (eXpress Transport Protocol) that could fit in a chip. Unfortunately, the protocol was never accepted, the chip was never built, and Moore's Law took us to a time where we could implement TCP in silicon, which made the issue moot.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

"Popular," sure, but a protocol doesn't need to be popular to be useful. Popular protocols don't always work well in untraditional, non-office settings. I've done this twice now, with absolutely no fuss. I've also seen more than once where the application of normal office protocols in these untraditional settings has resulted in miserable failure.

The cost in overhead for the SNAP header is trivial, and there are frequently no layer 3 headers involved at all.

Interesting. This must be new. It's not yet listed in the free IEEE standards list.

For the digital TV firmware upgrade example I gave, the selective retransmission is probably not applicable, since we're talking one-way broadcast, but a carousel scheme and/or forward error correction like RFCs 3450-3453 should do the trick very nicely. Incidentally, the old XTP (Xpress Transfer Protocol) had that feature, where multicast recipients could selectively request retransmission of courrupted packets. Whatever happened to XTP?

Bert

Bonjour Rich,

I have very appreciated your detailed text, and I thanks you for the efforts.

Every context, domain has its own logic, and having the standard logic from a standard contributor is very interesting and invaluable. We keep these information in our achives.

That doesn't avoid other talking and we continue learning ang going into details with Albert, Peter and James.

Regards, Michelot