Talk:SNAP header

Question: Is the IEEE 802.3 IP MTU 1500 or 1492?

IEEE Std 802.3-2002 says in 3.2.6 "Length/Type Field" that:

This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field.

a) If the value of this field is less than or equal to the value of maxValidFrame (as specified in 4.2.7.1), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent data field of the frame (Length interpretation).

b) If the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal), then the Length/Type field indicates the nature of the MAC client protocol (Type interpretation).

The Length and Type interpretations of this field are mutually exclusive.

When used as a Type field, it is the responsibility of the MAC client to ensure that the MAC client operates properly when the MAC sublayer pads the supplied data, as discussed in 3.2.7.

Any protocol that can use the length/type field as a type field - i.e., any protocol that has an Ethernet type assigned to it and that doesn't require a length field (i.e., that can "[operate] properly when the MAC sublayer pads the supplied data" - can do so, and can thus avoid adding an 802.2 LLC header or SNAP subheader, and thus has an MTU of 1500 octets. IP is such a protocol, so the 802.3 IP MTU is 1500 octets. Guy Harris 09:15, 21 November 2005 (UTC)[reply]

Why was SNAP created?

What is/was the motivation for creating LLC/SNAP? What problem(s) did SNAP solve? What are the competing solutions to the problems solved by LLC/SNAP?

E.g. given that Ethernet/DIX is more common than Ethernet/LLC/SNAP it follows that DIX either solves the same problems SNAP does or the problem solved by SNAP has become somewhat irrelevant Funkyj 02:05, 7 December 2005 (UTC)[reply]

See Ethernet Frame Types: Provan's Definitive Answer for at least some of the answer, in particular, the "Where did Ethernet_802.2 come from?" part explains were LLC comes from (although one might ask why other LAN types, e.g. Token Ring, don't have type fields like Ethernet, although the length field might be useful because Ethernet requires padding, other than other LAN types, so, if your protocol has no length field like IP's length field, you might want one in the Ethernet link layer so you can run atop Ethernet the same way you run atop Token Ring or FDDI or...), and the "Where did Ethernet_SNAP come from?" explains why, with 802.3+802.2, you might want SNAP in order to get back to where you were with regular Ethernet II.

So, yes, DIX solves most of the same problems 802.3+802.2+SNAP does, but 1) SNAP also supports "private" protocol spaces (it has an OUI to select a space of protocol IDs, and a type field to select a protocol within that space, with space 00:00:00 being for Ethernet types) and 2) these protocols also have to run atop protocols other than Ethernet, and 802.3+SNAP at least gives you what you have with Ethernet II, plus the "private" protocol spaces. Guy Harris 06:55, 7 December 2005 (UTC)[reply]

Thanks, that helps. The Provan link is very helpful too. Funkyj 19:22, 7 December 2005 (UTC)[reply]