Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!bellcore!faline!ulysses!ucbvax!OPAL.BERKELEY.EDU!minshall From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks Message-ID: <8710190620.AA03531@opal.berkeley.edu> Date: Mon, 19-Oct-87 02:20:24 EDT Article-I.D.: opal.8710190620.AA03531 Posted: Mon Oct 19 02:20:24 1987 Date-Received: Tue, 20-Oct-87 01:46:18 EDT References: <8710150204.AA00254@bel.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 105 Hi. 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 Information). 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. Yours, 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.