Ethernet II

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <4197cc23$0$8275$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

> 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)
>

As of 1997, IEEE 802.3 fully specifies both Length (LLC) and Type
("Ethernet II") encapsulation.

> (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?
>

When using Type encapsulation ("Ethernet II"), there is no LLC sublayer
present.


--
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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Michelot <mhostettler@wanadoonospam.fr> wrote:
> 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)

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

> (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?

802.3 is not used. ( some providers, HP and AIX ) may be configured
to use it.

> Thanks,
> Michelot






--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonsoir Peter,

> > Can we say that today, Ethernet II, only for its MAC level, is
> > completely specified by IEEE 802.3?
>
> No. 802.3 in not used, ethernet II is ( except for some
> more or less broken variants used by novell when using IPX)

(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
802.2 LLC that covers entirely 802.3 MAC, without interruption.

Regards,
Michelot

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <419922d0$0$24032$8fcfb975@news.wanadoo.fr>,
"Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:

>
> (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
> 802.2 LLC that covers entirely 802.3 MAC, without interruption.
>

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

> In article <419922d0$0$24032$8fcfb975@news.wanadoo.fr>,
> "Michelot" <mhostettler@wanadooNOSPAM.fr> wrote:
>
>>
>> (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
>> 802.2 LLC that covers entirely 802.3 MAC, without interruption.
>>
>
> 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.)

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.

> --
> 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

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

> 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.

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
http://www.iana.org/assignments/ethernet-numbers and couldn't find one,
anyway. Failing that, unless one wants to use Ethernet exclusively with
existing upper layer protocols, or unless some enterprising soul wants
to go through the motions of having a new Type code assigned by the
IEEE, the easiest way to cook up your own protocol is to go with the
SNAP SAP and SNAP header.

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Albert Manfredi <albert.e.manfredi@nospam.com> wrote:
> Rich Seifert wrote:

>> 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.

> 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
> http://www.iana.org/assignments/ethernet-numbers and couldn't find one,
> anyway. Failing that, unless one wants to use Ethernet exclusively with
> existing upper layer protocols, or unless some enterprising soul wants
> to go through the motions of having a new Type code assigned by the
> IEEE, the easiest way to cook up your own protocol is to go with the
> SNAP SAP and SNAP header.

> 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.

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.

> 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."

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.

> Bert


--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <I7A223.E63@news.boeing.com>,
"Albert Manfredi" <albert.e.manfredi@nospam.com> wrote:

> Rich Seifert wrote:
>
> > 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.
>
> 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.
>

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.

> 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.
>

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.

> 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
> http://www.iana.org/assignments/ethernet-numbers and couldn't find one,
> anyway. Failing that, unless one wants to use Ethernet exclusively with
> existing upper layer protocols, or unless some enterprising soul wants
> to go through the motions of having a new Type code assigned by the
> IEEE, the easiest way to cook up your own protocol is to go with the
> SNAP SAP and SNAP header.
>

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
3 protocol. How many Network Layer protocols exist, or have ever
existed? While the answer is probably "More than were ever needed", the
number is also well below 64,000 (the number of possible Type field
values).

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

> 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.
>

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.

> 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."
>

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Rich Seifert" <usenet@richseifert.com.invalid> wrote:

> I had written:
>> 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.
>
> 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.

"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.

> 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.

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <I7BxLB.DxH@news.boeing.com>,
"Albert Manfredi" <albert.e.manfredi@nospam.com> wrote:

> "Rich Seifert" <usenet@richseifert.com.invalid> wrote:
>
>
> > 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.
>
> Interesting. This must be new. It's not yet listed in the free IEEE
> standards list.
>

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

> 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?
>

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Bonjour Rich,

> 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....

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