POSTEL@B.ISI.EDU (08/30/86)
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.
--jon.
-------DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (09/02/86)
Date: 29 Aug 1986 19:27:12 PDT
From: POSTEL@B.ISI.EDU
Hello.
Hi.
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.
[...]
A very quick reading of this and a small amount of knowledge about 802.x
leads me to believe this looks reasonable. The problem I see is "What
happens if ISO blesses DoD IP and then there are two different ways to
talk it?"
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.
Good.
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).
Please don't say "IP related protocols." Only one protocol is IP
related and that is IP. Instead say "Ethernet'1980 related protocols"
which includes Chaos, PUP, XNS, DECnet, etc.jas@BRUBECK.PROTEON.COM (09/02/86)
Your K1 (the SNAP SAP) is '01010101' when presented least signifigant bit first. (First bit to the MAC layer first.) For those of us who think in a forward direction, this is '10101010', or 'AA'hex. While SNAP is only a proposal, I beleive it is de-facto real. I understand that certain proprietary network vendors already plan to use it. By the way, "ethernet types" were handed over by Xerox to the IEEE along with the 24-bit address blocks. There is no list available from IEEE of the allocation of either type of block, they consider that proprietary. I have heard rumors that K2 is '0', and that this 24-bit block belongs to Xerox. Are the Xerox people out there who can confirm this? john shriver proteon -------
jas@BRUBECK.PROTEON.COM (09/02/86)
There already was a blessed way to send IP packets over 802.2. The problem was that the powers that be were NEVER going to provide a SAP for ARP, so the IP SAP was useless. Once we had this scheme for ARP, we decided to do IP that way to provide an even-length data-link header, and one the same size as ARP. (DoD Internet is SAP '06'hex.) -------
Provan@LLL-MFE.ARPA (09/04/86)
I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa
jas@BRUBECK.PROTEON.COM.UUCP (09/08/86)
SNAP is not 'our' protocol, any more than 802.2 is ours. We don't have any contorl over it. If we had wanted to avoid this mess, we (sigh) should have been on 802.2. AS I noted, vendors are already using SNAP. The reason that the code is 3 bytes of owner, and two of protocol number, is that they can then use the already-allocated 24-bit prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly long, also. I think that running a datagram network protocol like IP over class 2 802.2 is a non-sequitor, so we don't need to worry about it. I will admit that I can't see how SNAP would work with class 2 at all. In the ISO world, class 1 is used with connectionless internet at the network level, and class 2 with a null network layer. john shriver proteon -------