QoS: Assigning Priority in IEEE 802-style Networks
Microsoft provides Quality of Service (QoS) support to the Microsoft Windows operating systems, including numerous mechanisms such as Differentiated Services, RSVP, and so on. This article describes support for a specific QoS mechanism that is referred to as "link layer prioritization." This support is targeted primarily at 802.1p (which is the mechanism by which link layer priority is provided in 802 networks); however, this support can be exploited by network drivers for any media capable of link layer prioritization.
On This Page
 | QoS Support in Windows Operating Systems |
| Interpreting the Priority Value |
| Miniport/NDIS Changes |
| NDIS Packet Changes |
| Clarifications of Frame Sizes |
QoS Support in Windows Operating Systems
High-layer QoS components in Windows operating systems use directory-based policies, negotiation, or both policies and negotiation with the network to determine the appropriate priorities and rates for various application traffic flows. (The policies and signaling mechanisms used are compliant with the QoS work ongoing in the IETF). Higher-layer QoS components indicate packet-by-packet priorities to kernel-mode network drivers by including a priority value in a field of the NDIS_PACKET structure. Any network driver can then use this priority value to mark transmitted packets with a priority in a manner appropriate for the media. Interpretation of the priority value is discussed in the following section.
Drivers that do not interpret the priority value generated by higher-layer QoS components must not mark traffic for any level other than best-effort (default priority). Otherwise, prioritized packets sent from these drivers (without the required network negotiation) might wreak havoc with traffic sent by other drivers and marked based on the priority value. It is in the best interest of the network adapter vendor to interpret the supplied priority value and mark packets accordingly.
Interpreting the Priority Value
The priority value is passed down the network stack in the NDIS_PACKET structure associated with transmitted packets. It is based on the "user_priority" as described in the article provided at http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-svc-mapping-04.txt 
(this reference is subject to change). Drivers that are 802.1p capable can include this value directly in the appropriate field of the MAC layer header of the transmitted packet. For other media, the driver writer should decide how to map the user_priority to the priority markings appropriate for the media. The following guidelines should be noted from the IETF reference:
| • | A priority value of 0 indicates that the packet should be marked as best-effort (default priority). |
| • | A priority value of 1 indicates that the packet should be marked for a value less than best-effort. |
| • | Priority values of 2-7 indicate increasing priority markings. |
For packets received from the network, drivers for 802.1p-capable media should extract the user_priority from the MAC layer header and include it directly in the appropriate field in the NDIS_PACKET structure (to be passed up the network stack with the received packet). Drivers for non-802.1p-capable media should use the guidelines listed in this section to decide which priority value to insert in the NDIS_PACKET structure.
Support for 802.3 priority was included in NDIS 4.0 in the existing Windows releases. When 802.3 priority was initially introduced to NDIS, it was used in the context of PACE and 100-VG. The fields in the OOB data portion of the NDIS packet descriptor used to designate this priority still exist today, but are not used for 802.1p priority. The mechanisms for supporting 802.1p priority in the NDIS 5.0 and Windows QoS infrastructure are defined in this article.
Miniport/NDIS Changes
OID_GEN_MAC_OPTIONS (Query to determine network adapter/miniport capabilities)The
OID_GEN_MAC_OPTIONS query returns a bit mask that defines optional properties of the underlying driver or its network adapter. A protocol that initiates this query can determine which flags are set by the underlying driver and can optionally take advantage of them. In addition to the flags currently defined in the Windows DDK, a miniport that uses priority values from the NDIS_PACKET must set the NDIS_MAC_OPTION_8021P_PRIORITY flag.
NDIS_MAC_OPTION_8021P_PRIORITYThe network adapter and miniport interpret priority information in the NDIS_PACKET and generate appropriate information in the MAC headers of transmitted packets. These drivers also extract appro-priate information from the MAC headers of received packets and indicate this information in the NDIS_PACKET to higher layers. Any driver that provides link layer prioritization by packet marking can indicate support for this capability. These drivers are not required to use 802.1p specifically.
NDIS Packet Changes
A new field is added to the NDIS_PACKET to keep IEEE 802.1p priority information in the NDIS_PER_PACKET_INFO structure. To access the priority information in the NDIS_PACKET, a driver uses one of the following macros:
| • | For an NDIS 5.0 miniport driver to insert the priority from a received network packet into the packet structure: NDIS_PER_PACKET_INFO_FROM_PACKET(_Packet, Ieee8021pPriority) = Priority |
| • | For an NDIS 5.0 miniport driver, to retrieve the priority from the packet structure: Priority = NDIS_PER_PACKET_INFO_FROM_PACKET(_Packet, Ieee8021pPriority) |
Note: The macros provided here make the NdisClass802_3Priority OOB information obsolete.
Clarifications of Frame Sizes
In most cases, the frame sizes seen by a protocol driver will be unaffected by the use of 802.1p priority values in frames on the wire. These priorities are passed as NDIS_PER_PACKET_INFO information in the NDIS_PACKET structure, and are added and removed from the on-the-wire packets by miniport/network adapters and intermediate systems.
There are currently no standardized mechanisms for determining end-to-end tag-ability. If such a mechanism becomes available, or if a vendor provides a vendor specific solution, tagged frames may have to traverse legacy network equipment that does not support the larger than standard frame sizes.
In these situations, constraints will be placed on the size of data packets that can be sent or will be received by protocol drivers. To prepare for this possibility, the following information clarifies the use of these NDIS OIDs (Object IDs). This should not effect existing miniport drivers that do not provide 802.1p support.
OID_GEN_MAXIMUM_FRAME_SIZEThis represents maximum network frame size in bytes the network adapter supports, not including the header. Miniports should indicate the maximum frame size that can be sent by a transport, minus the header, in response to this query. Miniports supporting network adapters that need to add additional fields to the frame, or emulating other medium types, must ensure that the size indicated in response to this query would not cause a protocol-supplied network frame of this size to be too large for the true network medium. One example might be a network adapter that supports 802.1p tags and expects through prior knowledge that these frames must traverse legacy networks before the tags are removed. Transports will query this value to determine MTU.
OID_GEN_MAXIMUM_TOTAL_SIZEThe maximum total frame length, in bytes, that the network adapter supports, including the header. This value is medium dependent. The returned length specifies the maximum, on the wire, total size for the underlying medium, including headers. Protocols might use this value as a gauge to determine the maximum size frame that could be passed in a receive indication, and then allocate buffers accordingly (if buffers are pre-allocated).
Call to action to support priority in IEEE 802-style shared network segments:
| • | Modify your network adapters and associated NDIS drivers to support user priority for IEEE 802-style networks. |
| • | For more information, see the Windows DDK. |
| • | If you have any questions or need further information, please e-mail your contact information to ndisfb@microsoft.com with the text QoS: Assigning Priority in IEEE 802-style Networks in the Subject of your message. Please include your name, title, company name, and phone and fax numbers. |