Re: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
Sun, 18 Oct 87 23:20:24 PDT


For a while I've thought that I should someday try to understand 802.x.

With the proposed RFC in hand, as well as the IEEE 802.2 and 802.5 and
the IBM Token Ring Network Architecture Reference, I thought this weekend
would be as good a time as any.

(Before beginning I should mention that I think that "token ring" is
what every campus should be installing. It is precisely for that reason
that I am picking on the token ring section not a little.)

802.2 -

First off, even if we are only supporting type 1 (connectionless) service,
we MUST to support XID (Exchange ID) and TEST in addition to UI (Unnumbered

Our goal is stated to be "all equipment using IP or ARP on 802.[345] networks
will interoperate". However, there are variables in each of these networks:
which speed they run at, and the size of the MAC-level address (16 bits or
48 bits). Probably we need to suggest that each 3-tuple (802.x, speed,
address size) should interoperate on the same wire.

There is a nice picture (page 3) of DSAP=K1 SSAP=K1. Unfortunately,
this doesn't account for the fact that the low order bit of the SSAP
distinguishes between "command" and "response". (It IS the low (ARPA)
order bit, isn't it? On page 9 we seem to say something else.)

On page 5, "Implementations are encouraged to support full-length
packets". I would like to see this stronger. Just because the IP packet
(plus MAC/LLC stuff) is N bytes is no reason to suppose that some
gateway/bridge/whatever won't pad out the packet to N+1 bytes (say because
N+1 is odd, and the DMA chip works on halfwords), where N+1 is still a
legal packet size. Anyway, I think that maximum length packets should
be mandatory.

802.5 -

There is a maximum packet size for 802.5 networks. Basically, there is
a timer with a DEFAULT value of 10ms (THT). "Default" means that the
degrees of freedom of 802.5 (or 802.X, I suppose) networks is worse than
one might naively think. 4E6*10E-3/8 = approx 5,000 bytes (with a little
more to be subtracted due to hardware delays, etc.).

Now, frame format. The MAC header is 2 bytes (SD and AC), 1 byte (FC),
2 addresses (4 bytes total or 12 bytes total), a CRC (4 bytes), and
2 bytes (ED and FS). If the packet is using source routing, then
there are 2 bytes of "routing control", plus up to 16 bytes (2 bytes
* 8 entries) of "segment numbers". Without source routing, the MAC
header is 13 or 21 bytes in length; with source routing the MAC header
is between 15 bytes and 39 bytes in length. (Aren't all these odd
numbers wonderful!)

Now I have a question. A year (or two) back, the issue of source routing
was very very controversial in the halls of IEEE 802.X. Is this still
the case? Unfortunately, the IEEE documents I have are demonstrably old
(eg, they don't mention SNAP at all, plus the covers have become discolored).

I'm not wild about embracing source routing if source routing is still
controversial within the 802 committee.

Note, by the way, that the PRESENCE of the Routing Information Field (RIF)
in an 802.5 packet is indicated by a bit in the Source Address field (what
we might think of as the ethernet source address). Sigh.

We say "IP broadcasts ... must be sent as 802.5 all ring broadcasts".
Again, we are up against the source routing wall: "all ring broadcasts"
are a feature of source routing.

(The whole idea that "source routing" is like a MAC-bridge is a bit dubious
to me. I'm used to thinking of the TransLan as a MAC-bridge. The analogy
is that to get the TransLan to propagate an ethernet broadcast packet,
I have to change the packet to include information that says "TransLan, please
forward this". And, to get the TransLan to forward a non-broadcast packet,
I need to change the packet by addressing it to the bridge, and include
in the packet the route the packet should take. Doesn't sound very "MAC-
level" to me.) (And then add to that the fact that, according to the
proposed RFC, certain of these MAC-level bridges (in quotes) constrain
the conversation to packet sizes smaller than either of the two bridged
networks or the two endpoints!)

Appendix on Numbers -

Gasp. My head hurts. However, I think (think) that the IEEE *bytes*
are transmitted/displayed just like ARPA bytes. So, IEEE 0x810100
would be ARPA 129.128.0. However, I think that the XID response should
be IEEE 0x818000 == ARPA 129.1.0.

To add to the fun, it appears that the IEEE 802.5 (5 5 5 5 5) bit ordering
is ARPA-like. So, and IEEE 802.5 0x80 is an ARPA 0x80 is an "IEEE" 0x01.

        Greg Minshall

ps - Someday, I'd like to see us look at Type 2 (connection-oriented) service.
IBM, which uses Type 2, gets fairly impressive numbers on performance of
their networks.

Also, someday, I'd like us to think about allowing one LLC packet carry > 1
IP/ARP packet. I even know the first place I'd put this to use: I need to
ARP on an ethernet/802.3 network; I'd like to use trailers. So, I need to
send out 4 separate packets. It would be nice to send one. Also, this
might be nice from (and to) gateways.

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:35 GMT