ROMKEY@XX.LCS.MIT.EDU.UUCP (02/05/87)
Here's a definition of a phrase I will use in this message. I just want to avoid any ambiguity at the onset: Here's a problem: Starlan is an 802.3 network; it looks like ethernet except it's cabled differently, it runs at 1Mbps instead of 10Mbps and (I think but I'm not certain) it's manchester encoding is slightly different. I need to bring up TCP/IP on Starlan, and I have a question: What ARP hardware type should I use? My immediate reaction is to go to the number czar and ask him to assign a starlan number and use that. But wait...there's a catch. Some vendors have or are developing MAC-level bridges which connect ethernets to starlans (as well as other ethernets). For this type of connection to work correctly, Starlan must have the same ARP hardware type as ethernet or else machines on one net connect to another via a MAC-level bridge will discard ARP requests because they will be for the wrong hardware type (I assume that we *do* check this field, after all...) and no communication will occur. Would the number czar care to comment? Also, does anyone know if any vendors are planning to develop an 802.3 to 802.5 MAC-level bridge? Different waveforms and different speeds, I know, but similar packet headers. If they are, then we've already lost because there is already an 802.5 ARP hardware type which is different from ethernet. Maybe there should be an 802.x ARP hardware type... John Romkey FTP Software, Inc. (617) 864-1711 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@xx.lcs.mit.edu Boston, MA, 02142 -------
jas@MONK.PROTEON.COM.UUCP (02/05/87)
Ah, the wonderful gifts we have received courtesy of 802.2. If Starlan is 802.3, then you really "should" use 802.2, the same as is used for 802.5. Pile SNAP on top of 802.2, and away you go. Of course, this nails the Ethernet 2.0 people, but that's a mess we have to face. What ARP hardware type is being used for 802.2/802.5? Maybe we indeed should have a 802.2 "hardware" type. U-B has announced an 802.3/802.5 MAC-level bridge. It poses a lot of interesting questions, if anyone from U-B wants to edify us it would help iron out how we should design 802.2/SNAP/ARP. Problems like this show the advantages of routers over bridges...
melohn@SUN.COM.UUCP (02/05/87)
> ...Maybe there should be an 802.x ARP hardware type... From the tcp-ip archives: Date: 12 Oct 1986 16:26:38 PDT From: POSTEL@B.ISI.EDU Subject: IP on 802 To: tcp-ip@SRI-NIC.ARPA Well, i haven't got an RFC out yet, but the procedure described in the following memo should be used anyway. There is a small and ever decreasing possibility that the values of K1 and K2 may be different than indicated below, so consider the possibility of having them changable in your implementation. In the mean time please go ahead and use this encapsulation format for doing IP and ARP (and other things) on 802 nets, using K1=170, and K2=0. The IEEE likes to talk about bytes in little endian order so they say K1 is 01010101. The ARPA protocols have everything in big endian order so that K1 becomes 10101010 binary or AA hex or 170 decimal. This value is pretty definite. The value of K2 is somewhat less certain, but no evidience to the contrary has surfaced yet. --jon. *** begin *** Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU Subject: How to IP & ARP on 802 Nets To: tcp-ip@SRI-NIC.ARPA Hello. At an ad hoc special session on "IEEE 802 Networks and ARP" held during the recent TCP Vendors Workshop, an approach to a consistent way to sent DOD-IP datagrams and other IP related protocols on 802 networks was developed. Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DOD-IP related protocols (such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the following new policy is being proposed, which will replace the current policy (see page 26 of RFC-960 and RFC-948). The proposal is for DDN and ARPA-Internet community to use IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of RFC-960). ...--------+--------+--------+ MAC Header| Length | 802.{3/4/5} MAC Header ...--------+--------+--------+ +--------+--------+--------+ | Dsap=K1| Ssap=K1| control| 802.2 SAP Header +--------+--------+--------+ +--------+--------+---------+--------+--------+ |protocol id or org code =K2| Ether Type | 802.2 SNAP Header +--------+--------+---------+--------+--------+ The values of K1 and K2 must be assigned by the IEEE. We believe there is already assigned a value of K1 that indicates that the 5-octet SNAP header follows. We can use this value. There may be a value of K2 that is already assigned that indicates that the last two octets of the SNAP header holds the EtherType. If so we may be able to use this value. This remains to be explored. The EtherTypes are assigned by Xerox (as always). The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice octet boundary. If we can not quickly resolve the issue of the values for K1 and K2, we will push for the assignment of a sap value (a K1 value) to indicate "IP related protocols" and do our own multiplexing (much like that proposed above). In any case, we will not create incompatible interpretations of headers already in use on 802 networks. *** end *** -------
DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP (02/06/87)
The intention of the hardware type field in ARP packets is to distinguish semantically different types of hardware. If your Starlan 802.3 network is "semantically the same" as Ethernet, then for the purposes of ARP it is Ethernet. "Semantically the same" roughly means "has the same number of hardware bytes in the address." Compare this with a 3Mbit Ethernet which has an 8 bit hardware address, or an MIT Chaos net which has a 16 bit hardware address.
ROMKEY@XX.LCS.MIT.EDU.UUCP (02/06/87)
Um. Yes, in fact, I've implemented an 802.5 IP driver according to that spec. I'd never read it well enough to notice that Jon Postel consistently said "802" instead of "802.5". Then I guess all 802.mumble networks should use the same ARP hardware type? - john -------
ROMKEY@XX.LCS.MIT.EDU.UUCP (02/06/87)
I hate to be nit picky (really, I do) but ARP has both a hardware type field and a hardware address length field. I suppose the address length field could be of use on networks where the hardware address was variable length? Yes, Starlan is semantically the same as ethernet, so I according to your argument they should have the same hardware type. I tend to agree... - john -------
melohn@SUN.COM.UUCP (02/06/87)
Technically the "SNAP" idea applies to 802.2, the LLC(2) layer, therefore it works on any of the MAC(1) layer media, include 802.3, .4, and .5.
DCP@QUABBIN.SCRC.Symbolics.COM.UUCP (02/06/87)
Date: Thu 5 Feb 87 21:53:09-EST
From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>
I hate to be nit picky (really, I do) but ARP has both a hardware type
field and a hardware address length field. I suppose the address length field
could be of use on networks where the hardware address was variable length?
That, and the ability for monitors to be able to parse the
request/responses without knowing the semantics of the hardware or
software types. (Though how it could not know the hardware type is
probably rhetorical.)
Yes, Starlan is semantically the same as ethernet, so I according to your
argument they should have the same hardware type. I tend to agree...
- john
-------