IPX Ethernet and 802.3 Frame Format

In the original Ethernet specification,as defined by Xerox, the third field in the header of an Ethernet frame was the type field, and indicated to the upper layers which protocol was being carried in the data section. IPX was given the type code 8137 hex.

Fig 1 –Ethernet II frame

When the IEEE standards committee wrote the 802.3 CSMA/CD spec, they changed the third field in the 802.3 frame to represent the length of the frame. Of course, there was still a requirement to have some indication of what protocol was being carried in the frame, but the IEEE committees decided to utilise the 802.2 Logical Link Control protocol header – that was designed to be carried immediately behind the 802.3 frame header –to carry the demultiplexing information. In fact, they went one step further, designing LLC to carry both a source and destination ‘type’ field (although there is some debate about how useful that would be – can you imagine delivering an IP packet to an IPX protocol stack?). These type fields in the LLC are called ‘service access points’ or SAP’s1and when prepended by the –source or –destination, become the SSAP and DSAP accordingly. The SAP codes were to be administered by the IEEE in the same way that the Ethernet type codes had been administered by Xerox ie unique codes. The fact that the Ethernet type field was 16 bits long and the SAP field only 8 – of which, one bit was to be used for other purposes, leaving only 7 bits for coding – seems to have escaped somebody’s attention!

Fig 2 – Raw 802.3 Frame

This then caused a dilemma for Novell with IPX. They ‘redesigned’ their frame format for IPX on Novell networks, and put the data frame immediately after the length field. Of course, in an 802.3/802.2compliant system, the stack would expect a LLC header, complete with SAP’s at that point. Luckily, in an IPX packet, the first two bytes are the checksum, which for some unknown reason is not utilised (it appears Novell use the CRC trailer in the same way as everyone else.) Consequently, the checksum fields were set to
FF-FF.(hex) In 802.2 LLC parlance, that should indicate a broadcast SAP (whatever that might actually mean!), but since IPX was widely deployed, it came to mean, de facto, IPX.

This method seemed to work, and was utilised for some time. However, presumably because it didn’t meet the IEEE guidelines, there were moves to ‘adjust’ the anomaly. Novell then designed two other frame formats. The first incorporated a correct LLC 802.2 header immediately behind the 802.3 header, with its length field. This was given the SAP code E016 by the IEEE, so the first two fields past ‘length’ are E0-E0. The next field in LLC is a control field, and this contains the code 0316, which decodes as an ‘Unnumbered Information frame using a Type 1 Unacknowledged (or Connectionless) mode of operation’. (There are also Type 2 – Connection oriented – and Type 3 – Acknowledged Connectionless– specified in the 802.2 standard, but they are little used). The IPX packet header and data is then carried immediatelyafter this three-byte LLC header.

Figure 3 – 802.2 Frame

The fourth type of frame was designed to take account of a difficulty that wasrecognisedwhen using the SAP field in the LLC. Recall that only 7 bits were left for coding? It wasn’t enough, and so the type (or ‘Ethertype’ as it is sometimes called) was reintroduced. Problem – where to put it? It couldn’t go where it had been before, after the source MAC address field, because that was now the length field. Then there was the LLC header. The solution was to put it after the LLC header, and to define a new SAP code that indicated that the protocol type wouldn’tactually be indicated by the SAP – rather that the frame would have to be parsed a little more to read the protocol type from the next field. This field was allocated five bytes, and so there was plenty of room to ‘re-introduce’ the original type code of 8137 hex. Novell calls this field the Protocol ID or PID field.

Figure 4 – SNAP Frame

OK, if you have followed so far – good!The next problem was what to call these various frames? The first was easy – it was the original Ethernet and so was called an Ethernet II frame. The ‘II’ came from the fact that what we think of as original Ethernet is actually the second variation – the first has all disappeared and is merely relegated to the history books. The second frame – the one with the FF-FFwhere the SAP should be is called 802.3 or sometimes ‘Raw 802.3’. The third frame is strangely called 802.2. This causes some confusion, since thereis an 802.2 protocol and it does NOT include fields for MAC addressing etc! However, a reasonable assumption is that since this frame does actually include a ‘real’ 802.2 frame, the name is good enough! The fourth type of frame is called a Sub-Network Access Protocol format frame or SNAP frame, indicating that it uses a sub-network access code in its SAP fields ie the real type code is buried a little further into what should be the data portion of the frame.

Now life really gets difficult. If the frames are to be used on a system with Cisco routers, we must tell the routers via their configuration what type of frame to expect.The trouble is that Cisco decided they wanted different names to those given the frame formats by Novell!That means that what Novell calls an Ethernet II frame, Cisco calls an ARPA frame (after the original ARPARNET, which used the original Ethernet protocol for most of its LAN’s). The table below defines the different names – Novell vs Cisco. You ARE expected to know these!

Novell Frame name / Cisco Frame name / Comments
Ethernet II / ARPA / Ethertype 8137 after Source MAC
802.3 (Raw 802.3) / novell-ether / FF-FF after Source MAC – no length or type in header
802.2 / sap / Uses SAP’s = E0 to indicate IPX
SNAP / snap / Uses SAP’s = AA and type code in PID

Notes:

1. Service Access Points (SAPs)

Users access LLC services through service access points or SAP. In the OSI/RM, a SAP is a well defined location through which an entity at a particular layer can provide services to processes at the layer above. To be correct, since each layer in the OSI/RM can have SAPs, the first letter of the layer is normally used in conjunction with the acronym. The SAPs at the logical link level are known as LSAPs meaning Logical Link SAPs.

Each SAP will have a unique address, and the concept can be considered as a mailbox between the layers, or interlayer address selector. This address can also be used as an access point to the service’s user, which is the entity at the next higher layer. SAPs are assigned by the IEEE standards office.

The IEEE 802.2 specifications refer to SAPs through which network layer processes can request services from the logical-link-control (LLC) sublayer defined by the IEEE. The documents distinguish between source and destination access points. A DSAP (destination service access point) is the address to which the LLC passes information for a network-layer process. A SSAP (source service access point) is the address through which a network layer process requests LLC services.

The DSAP and SSAP values are included as fields in packets for the LAN architectures that conform to IEEE specifications. In practice, these addresses are usually the same, since the process requesting a service is almost always the one that wants the results of that service.

References:

1. Perlman, R.:Interconnections – Second Ed.; Reading, MA: Addison Wesley, 2000

2. Halsall, F: Data Communications, Computer Networks and Open Systems: Wokingham, England; Addison Wesley, 1993.

3. Black, U.: Data Link Protocols; Englewood Cliffs, New Jersey: Prentice Hall, 1993

Page 1 / Cisco Internetworking III– The IPX Frame FormatAuthor: Mike Weaver