This functionality is achieved through the use of a 3-bit, topology-independent "user priority." Incoming frames can be examined for a pre-existing priority value, which is then mapped to the 802.1p-specific priority value (according to a matrix provided in the 802.1p specification). The 802.1p priority value can then be assigned to an outbound frame on another medium using this same matrix, providing a standard and topology-independent priority-mapping service.

The use of 3 bits provides eight distinct priority levels ("0" through "7"), which map evenly to some topologies' native prioritization services. For example, all eight values map directly to the eight priority values used with 802.4 and 802.6. However, they do not map evenly to 802.5 or FDDI, even though they use eight priorities, since the highest value ("7") is reserved on token ring and FDDI. Furthermore, 802.9 does not use numeric priorities, and 802.12 uses only a couple of numeric values.

Most noticeably missing from the above is Ethernet, which has never had a native prioritization service, due to its legacy as a shared-media architecture. This shortcoming has been addressed with 802.1Q, a proposal for a general-purpose VLAN implementation that also provides prioritization capabilities to those topologies that do not already support them (such as Ethernet).

Implementation of 802.1Q is through an additional 4 bytes of data inserted into a frame's header. These 4 bytes contain a variety of fields, most of which are specific to VLAN data, although one field also provides a 3-bit priority flag. These 3 bits provide eight possible values, the same as those used in the 802.1p priority-mapping scheme. On Ethernet networks, the 802.1Q header fields are inserted into a frame's header immediately following the source and destination address fields and before the 802.3 "length" (or the Ethernet II "ethertype") field. See "Ethernet Frame Before and After the Addition of 802.1Q Fields" at right.

Implementation and Compatibility The 802.1p addendum to the 802.1D standard should be finalized by the time you read this, and the 802.1Q specification is expected to be ratified this fall (we were unable to obtain exact dates from the IEEE). Vendors are preparing first-generation releases of their products that support these standards.

Since many Ethernet switch vendors already implement proprietary prioritization services, it is a relatively minor task for them to incorporate 802.1p support into their existing products. However, adding support for 802.1Q's additional header fields is proving to be a significant amount of work.

Furthermore, vendors are having to find ways to provide for backward compatibility with existing equipment. Obviously, changing the Ethernet frame is not something that can be done trivially. With the addition of 4 bytes to the frame's header, the frame is made incompatible with all of the legacy Ethernet devices that are trying to use the older frame format.

In particular, since the data is inserted before the 802.3 length field (or Ethernet II's ethertype field), any product that expects to see length or ethertype data at that location will not find it. Instead, it will see "8100," the new Tag Protocol Identifier field's default value for 802.1Q frames. Packet captures from Shomiti Systems' Surveyor network analyzer were able to decode 802.1Q data, but all the other decoders we tried displayed the frames as either "unknown ethertype" or "Wellfleet" (the latter used the 8100 ethertype at one time).

The change in field placement is not the only issue; overall packet length is a problem as well. Many devices cannot deal with a frame that is longer than 1,518 bytes. A debate has raged over whether the Ethernet frame should be lengthened by 4 bytes or the payload segment should be shortened by 4 bytes to accommodate the larger header. The result is that the 802.1Q specification allows for either implementation, with vendors left to ensure interoperability.

In actuality, getting legacy equipment to interoperate with 802.1Q-aware devices may not be that big of a deal, as most vendors will be providing support for legacy equipment on a per-port basis for years to come. If you need to support an older switch or NIC, you'll simply disable 802.1Q on that specific port, and all traffic will be sent in regular form.