Murray.pa@XEROX.COM.UUCP (06/20/86)
Not really IP or TCP, but probably interesting to many people on this list... IEEE 803.? recently agreed on a whole bunch of fine print for the specs for Ethernet repeaters, including fiber extensions. (There were major problems with the repeater handwaving in the blue book. Basically, it wouldn't work right if you were unlucky and you tried to push all the length limits.) If you need more info and can't get it through IEEE, I think I can find a local contact. As of January 1, 1986, Ethernet host numbers are now being assigned by the IEEE rather than Xerox. Any requests mailed to the Xerox address in the back of the blue book will get forwarded to the IEEE. (and delayed or...) The person to contact is Vince Condello at (212) 705-7092.
DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP (06/22/86)
Date: Fri, 20 Jun 86 02:20:24 PDT
From: Murray.pa@Xerox.COM
Not really IP or TCP, but probably interesting to many people on this
list...
IEEE 803.? recently agreed on a whole bunch of fine print for the specs
for Ethernet repeaters, including fiber extensions. (There were major
problems with the repeater handwaving in the blue book. Basically, it
wouldn't work right if you were unlucky and you tried to push all the
length limits.) If you need more info and can't get it through IEEE, I
think I can find a local contact.
As of January 1, 1986, Ethernet host numbers are now being assigned by
the IEEE rather than Xerox. Any requests mailed to the Xerox address in
the back of the blue book will get forwarded to the IEEE. (and delayed
or...) The person to contact is Vince Condello at (212) 705-7092.
I assume this applies to the protocol field as well?JNC@XX.LCS.MIT.EDU.UUCP (06/23/86)
The IEEE has flushed the protocol field (at least inside the Ethernet header) completely. They don't manage it, since they don't believe in it. The IEEE guy said to call Xerox. Noel -------
Murray.pa@XEROX.COM.UUCP (06/24/86)
"I assume this applies to the protocol field as well?" The IEEE doesn't think anybody needs a protocol field. They use that word for the packet length. Thus I doubt very much if they are interested in assigning values. I don't know for sure though. Most of the existing protocol values were "grandfathered" in because they are invalid lengths. The official 802 position is that they don't care what consenting adults do with packets having invalid lengths. (There is probably a footnote along that line in the specs.) The only protocol field values that weren't big/lucky enough to get grandfathered this way are used for Pup. A pair of alternates have been assigned. The switchover is painful. Most places have ignored it. I think the Ethernet driver for the latest VMS now rejects old Pups. That doesn't make the switchover any easier, but it might make it happen sooner.
DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (06/25/86)
Date: Tue, 24 Jun 86 13:34:05 PDT
From: Murray.pa@Xerox.COM
"I assume this applies to the protocol field as well?"
The IEEE doesn't think anybody needs a protocol field. They use that
word for the packet length. Thus I doubt very much if they are
interested in assigning values. I don't know for sure though.
Most of the existing protocol values were "grandfathered" in because
they are invalid lengths. The official 802 position is that they don't
care what consenting adults do with packets having invalid lengths.
(There is probably a footnote along that line in the specs.)
The only protocol field values that weren't big/lucky enough to get
grandfathered this way are used for Pup. A pair of alternates have been
assigned. The switchover is painful. Most places have ignored it. I
think the Ethernet driver for the latest VMS now rejects old Pups. That
doesn't make the switchover any easier, but it might make it happen
sooner.
OK, my ignorance is showing. Given that what used to be the protocol
field is now the length, how does one determine what layer (protocol)
the packet is really for? I assume there is still a 16 bit field
SOMEPLACE. Who assigns those numbers?POSTEL@USC-ISIB.ARPA (06/26/86)
David: Opening another can of worms ... In IEEE 802 the thing most similar to the Ethernet type is called a "service access point" or SAP, but it is only 8 bits and two of those are wasted on some other general coding, so there are only 64 SAPs to assign. So after assigning one to identify ISO-IP and one to identify DOD-IP, the IEEE 802 committee decided that there weren't enough and refused to assign a SAP to identify ARP. There is some committee work in progress to come up with an extended SAP field. --jon. -------
jas@BRUBECK.PROTEON.COM (06/26/86)
The protocol numbers are in the 802.2 data link control header, which is standard for 802.3, 802.4, and 802.5. They are one byte, and are incredibly stricly regulated. Basically, they're only available to established international standards. There is a (they're called SAPs) for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP is not promulgated by an international standards body. The only allocated SAPs are: ISO IP and TCP/IP. Half of them are "unadministered", IBM has de-facto taken a group for SNA. You'll notice that ARP is not listed. A group of us are trying to work on this issue. (I can provide more gruesome details of the list, if desired.) -------
DCP@QUABBIN.SCRC.Symbolics.COM.UUCP (06/26/86)
Date: Thu, 26 Jun 86 13:29:40 EDT
From: jas@brubeck.proteon.com
The protocol numbers are in the 802.2 data link control header, which
is standard for 802.3, 802.4, and 802.5. They are one byte, and are
incredibly stricly regulated. Basically, they're only available
to established international standards. There is a (they're called SAPs)
for TCP/IP, but that was considered an EXCEPTION to the rule, as TCP/IP
is not promulgated by an international standards body.
The only allocated SAPs are: ISO IP and TCP/IP. Half of them are
"unadministered", IBM has de-facto taken a group for SNA.
You'll notice that ARP is not listed. A group of us are trying to
work on this issue.
(I can provide more gruesome details of the list, if desired.)
I seem to remember seeing some mention of this fly by in the past, but
took little notice. Oh well, if they want to be snob-headed and try to
surpress vendor protocols (what about people who want to run PUP,
CHAOS, XNS, DECnet) as well as supress research into protocols (i.e.,
how to avoid collision of an "unadministered" number between people
developing new protocols that would take 4 years to become ISO anyway),
I guess it's time to hope the aliens are coming and will put some sense
into them.
Sorry for the long, run-on sentence, flame. This might be a reasonable
thing for tightly controlled comercial products, but comercial products
don't pop up out of thin air, they need time for experimentation and
development.
Aren't they also snobbish enough not to need ARP? Don't you just "send
it" and it "magically" gets there?
I just realized what's ticking me off. This whole nonsense is a
parallel with puritanical religions. It does not have any room for
person freedom (e.g., elbow room for new protocols) and it doesn't have
any concept of social responsibility (e.g., maybe <insert favorite hot
topic> isn't such a good idea, but AT THIS TIME IN THIS SOCIETY it is a
necessary evil). Time to nail a grievance to somebody's door?louie@TRANTOR.UMD.EDU (Louis A. Mamakos) (06/28/86)
It is because of things like this that standardization bodies have bad reputations. You can definitly smell a standard written by committee, with each member's own hidden agenda slipped in somewhere. This will delay acceptance and conversion from the DEC-Intel-XEROX Ethernet standard quite a while, at least around here. If it works, why break it? Standards are great; everyone should have one of their own. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP (06/28/86)
Date: 26 Jun 1986 10:09:18 PDT
From: POSTEL@USC-ISIB.ARPA
David:
Opening another can of worms ...
In IEEE 802 the thing most similar to the Ethernet type is called a
"service access point" or SAP, but it is only 8 bits and two of those
are wasted on some other general coding, so there are only 64 SAPs to
assign. So after assigning one to identify ISO-IP and one to identify
DOD-IP, the IEEE 802 committee decided that there weren't enough and
refused to assign a SAP to identify ARP. There is some committee work
in progress to come up with an extended SAP field.
--jon.
-------
[I'm probably sounding like a big flamer...] It really amazes me that
people are trying to squeeze 300 options into 20 bits. This isn't the
1960s anymore. Just a few weeks ago a megabit ram chip costs $35.
That's the equivalent of TWO, count'em, TWO PDP-11 (non-memory mapped)
address spaces (2^16 bytes each). I recall hearing rumors about various
namespace/domain proposals (the X, Y and Z proposals?) that tried to do
similar bit cramming.
IT ISN'T WORTH IT, folks. Maybe somebody should seriously suggest that
IEEE 802 be scrapped and something more rational and less
wasn't-invented-here be made to put in its place.
Would Henry Nussbacher, if he is still out there, please resend the
article he sent on 31 March 1985. It is a great story about the Mericos
and the Eups on the planet Urth about trains with rubber-coatetd wheels.
I don't remember what the analogy was then (probably the TP4 debate),
but it is very fitting to the current situation.
PS, I am still having mail troubles. These might be problems on our
end. If so, tell me. If not, fix your end.
Unable to deliver letter to the following recipients:
POSTEL@USC-ISIB.ARPA: SMTP error from USC-ISIB: 501 Error in path -DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM
TCP-IP@SRI-NIC.ARPA: Unknown response from host SRI-NIC: (expecting 220).DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP (06/28/86)
Date: Fri, 27 Jun 86 17:58:28 EDT
From: Louis A. Mamakos <louie@trantor.UMD.EDU>
It is because of things like this that standardization bodies have bad
reputations. You can definitly smell a standard written by committee,
with each member's own hidden agenda slipped in somewhere.
A somewhat constructive question: Is it written down what the Charter
and Goals of the 802 standards committee is? Is "to allow flexibility
for experimentation" one of the goals? If not, then there are several
organizations that will not be able to use 802 because they need the
ability to experiment (and get work done, since non-ISO things are (by
their definition) experimental). If so, I think they need to be
informed they are not addressing this goal.
This will delay acceptance and conversion from the DEC-Intel-XEROX
Ethernet standard quite a while, at least around here. If it works,
why break it?
Standards are great; everyone should have one of their own.
Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems ProgrammingDCP@QUABBIN.SCRC.Symbolics.COM.UUCP (06/28/86)
Date: Fri, 27 Jun 86 17:58:28 EDT
From: Louis A. Mamakos <louie@trantor.UMD.EDU>
It is because of things like this that standardization bodies have bad
reputations. You can definitly smell a standard written by committee,
with each member's own hidden agenda slipped in somewhere.
A somewhat constructive question: Is it written down what the Charter
and Goals of the 802 standards committee is? Is "to allow flexibility
for experimentation" one of the goals? If not, then there are several
organizations that will not be able to use 802 because they need the
ability to experiment (and get work done, since non-ISO things are (by
their definition) experimental). If so, I think they need to be
informed they are not addressing this goal.
BTW, the reason I wrote ARP the way I did is because I KNEW there was
more than one protocol in the world, and that there would be more. (It
was a bit easy, because I was trying to solve the same problem for two
different protocols (CHAOS and IP).) I also knew the protocols had
different length addresses, and thus the protocol-address-length field.
I also knew that Ethernet was the only hardware medium. Thus the
hardware-type field. I knew that addresses on different hardwares had
different lengths, thus the hardware-address-length field. I knew that
this would solve the GENERAL problem stated in the first three
paragraphs (Introduction, The Problem, and Motivation). I know the real
world is more diverse and more interesting than a one track (collective)
mind.
This will delay acceptance and conversion from the DEC-Intel-XEROX
Ethernet standard quite a while, at least around here. If it works,
why break it?
Standards are great; everyone should have one of their own.
Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems ProgrammingMILLS@USC-ISID.ARPA (06/28/86)
In response to the message sent Fri, 27 Jun 86 19:46 EDT from DCP@QUABBIN.SCRC.Symbolics.COM David, Your recollection may be blamed on the Professor Finnegan Papers. Danny Cohen of ISI is curator of that museum. Dave -------
HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) (06/29/86)
Do anyone know if there are plans to do a real 803.x implementation of IP, i.e. one that uses the type field as a length? One would suppose that the first vendor to do this would lose big, since no other implementation would talk to it. I would think a more natural approach would be for IP, PUP, etc., to continue using the type field as a type. Then if we see a packet with a value that is in the range of legal 803 lengths, we treat it as if it specified a type of ISO. -------
leong@ANDREW.CMU.EDU (John Leong) (07/08/86)
Charles, Our implementation for IP running over the IBM token ring (802.5) uses the 802.2 LLC header. So far we have approximately 100 RT-PC stations running UNIX 4.2 and some 50 IBM PC's running a token ring version of the PCIP code on 4 rings. We have no problems such that some machines on the ring will use the LLC and some won't since only PC's and RT's can be inserted on the ring. We have not done any 802.2 LLC implementation on our Ethernet attached machines since the incompatibility problem you mention will then exist. The router that interconnect the Ethernet to the IBM token ring takes care of the encapsulation and stripping off the LLC header. John Leong leong@andrew.cmu.edu
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (07/08/86)
How do you do address translation? I.e. where does the code that creates the LLC header get the 48 bit address from to go with a 32 bit IP address? Noel -------
leong@ANDREW.CMU.EDU (John Leong) (07/09/86)
Noel, Re : >> How do you do address translation? >> I.e. where does the code that creates the LLC header >> get the 48 bit address from to go with a 32 bit IP address? The LLC header is encapsulated by the MAC layer (or "hardware" layer) header. The LLC header consists of a one-byte DSAP, one byte SSAP and a one byte control field. There is no 48 bit address in the LLC header. [The DSAP and SSAP has the value of 6 for the IP/TCP family of protocol. The control field has the value of 3 for UI : Un-numbered I-frame.] Encapsulated inside the LLC header is the IP or ARP packet. May be the 48 bit address you refered to is the 48 bit address in the MAC (802.3 Ethernet or 802.5 Token Ring) layer header. In which case, the IP (32 bits) to MAC (48 bits) layer address mapping is done by ARP is per Plummer's algorithm. Leong