by William Stallings

A typical organization's on-premise network configuration has multiple Local-Area Networks (LANs) connected by bridges or Layer 2 switches. The LANs may all be of one type (for example, Ethernet) or may be of mixed types (for example Ethernet, Token Ring, wireless). In either case, the issue of Quality of Service (QoS) arises.

User Priority and Access Priority
The first attempt to deal with LAN QoS in a standardized fashion appears in the original version of IEEE 802.1D, which is a specification that defines the protocol architecture for bridges and Layer 2 switches, which operate at the Media Access Control (MAC) level. IEEE 802.1D deals with the interconnection of LANs with the same MAC protocol and with LANs with different MAC protocols. In addition to passing MAC frames from one LAN to another across the bridge, the bridge is able to pass parameters from software that controls the incoming port to the software that controls the outgoing port. Two of these parameters are user_priority and access_priority .

The user_priority and access_priority parameters relate to the problem of how to handle priorities. In the case of IEEE 802.3 (Ethernet) and 802.11 (wireless LAN), priority is not supported. Other 802 LAN types support up to eight levels of priority. The user_priority value provided to the MAC- layer entity at the incoming port is derived from the incoming MAC frame; in the case of an incoming frame with no priority value, a value of unspecified is used. The user_priority value issued to the MAC entity at the outgoing port is to be placed in the outbound MAC frame for LAN types that provide a priority field. The access_priority refers to the priority used by a bridge MAC entity to access a LAN for frame transmission. We may not want the access_priority to be equal to the user_priority for several reasons:

	A frame that must go through a bridge has already suffered more delay than a frame that does not have to go through a bridge; therefore, we may wish to give such a frame a higher access priority than the requested user priority.
	It is important that the bridge not become a bottleneck. Therefore, we may wish to give all frames being transmitted by a bridge a relatively high priority.

The rules for handling priorities can now be summarized. The user_priority is determined from the priority field of the incoming frame and placed in the priority field of the outbound frame. Priorities are not used to transmit 802.3 and 802.11 MAC frames, and the frames themselves have no priority field. Therefore, if the outbound frame is 802.3 or 802.11, any incoming priority field (from a frame that has such a field) is ignored. If the incoming frame is 802.3 or 802.11 and the outbound frame requires a priority field, then the priority field in the outbound frame is set to a default user_priority value. If both incoming and outbound frames carry a priority field, then the priority field in the outbound MAC frame is set equal to the priority field in the inbound MAC frame.

The access_priority is also determined from the priority field of the in-coming frame. For incoming 802.3 and 802.11 frames, a user_priority of 0 (lowest priority) is assumed. Table 1 shows the access priorities assigned to outgoing MAC frames for each of the LAN types, as a function of incoming user priority value. For 802.3 and 802.11, there is no access priority mechanism and, therefore, a priority of 0 is used. For 802.4 and 802.6, there are eight available access priorities, so the incoming user priority is mapped to the outgoing access priority using equality. IEEE 802.12 permits only two priority levels; half of the possible user priority values are mapped into each of these levels. For the two Token Ring types (802.5 and Fiber Distributed Data Interface [FDDI]), although eight priority levels are available, the highest priority (level 7) is not used in bridge forwarding. The reason for this restriction is that the token-passing protocol reserves priority 7 for its use in transmitting frames needed to manage the token-passing process, such as recovering from a frame loss.

Table 1: Outbound Access Priorities

802.3 = CSMA/CD	802.11 = Wireless LAN
802.4 = Token bus	802.12 = Demand priority (100VG-AnyLAN)
802.5 = Token ring	FDDI = Fiber Distributed Data Interface (token ring)
802.6 = DQDB (Distributed Queue, Dual Bus) MAN

Traffic Classes
These rules, summarized in Table 1, are effective in communicating a priority requested by a user and in obtaining access to a LAN in competition with other devices also attempting to transmit on that LAN. However, the rules do not directly provide guidance concerning the relative priority with which frames are to be handled by a bridge. For example, consider a bridge connected to a Token Ring on one side and an Ethernet on the other, and suppose that the bridge receives a large volume of traffic from the Token Ring so that a number of frames are buffered waiting to be transmitted onto the Ethernet. Should the bridge transmit these frames in the order in which they were received, or should the bridge account for the user priority of all waiting frames in determining which frame to transmit next? Consideration of this issue led to the development of a new concept, traffic class, which is incorporated in the 1998 version of IEEE 802.1D. This new material is sometimes referred to as 802.1p in the literature. This was the designation when the traffic-class standard was in draft form. In the 802 scheme, a lowercase letter refers to a supplement to an existing standard and an uppercase letter refers to a base standard. Thus 802.1D is a base standard defining bridge operation, and 802.1p is a supplement to the earlier version of 802.1D. With the publication of the 1998 version, the traffic-class supplement was incorporated into 802.1D, and the designation 802.1p is no longer used.

The goal of the traffic-class addition to 802.1D is to enable Layer 2 switches and bridges to support time-critical traffic, such as voice and video, effectively. In the remainder of this article, we begin with an overview of the use of traffic classes in bridges. Next, we examine the mapping of user priorities into traffic classes. Finally, we look at the larger issue of QoS in an internet that includes bridges as well as routers and other Layer 3 switches.

The 1998 version of IEEE 802.1D distinguishes three concepts:

	User priority : The user priority is a label carried with the frame that communicates the requested priority to downstream nodes (bridges and end systems). Typically, the user priority is not modified in transit through bridges, unless a mapping is needed for the use of a different number of priority levels by different MAC types. Thus, the user priority has end-to-end significance across bridged LANs.
	Access priority : The access priority is used, on LANs that support priority, to compete for access to the shared LAN with frames from other devices (end systems and other bridges) attached to the same LAN. For example, the token-passing discipline in a Token Ring network enables higher-priority frames to gain access to the ring ahead of lower-priority frames when frames from multiple stations are waiting to gain access. When both the incoming and outbound LAN are of the same MAC type, the bridge assigns an access priority equal to the incoming user priority. Otherwise, the bridge must perform a mapping as defined in Table 1.
	Traffic class : A bridge can be configured so that multiple queues are used to hold frames waiting to be transmitted on a given outbound port, in which case the traffic class is used to determine the relative priority of the queues. All waiting frames at a higher traffic class are transmitted before any waiting frames of a lower traffic class. As with access priority, traffic class is assigned by the bridge on the ba-sis of incoming user priority.

The significance of traffic classes can be seen by recognizing that a frame experiences two types of delay at a bridge:

	Queuing delay : The time that a frame waits until it becomes first in line for transmission on the outbound port. This delay is determined by the queuing discipline used by the bridge. The simplest scheme is first-in, first-out (FIFO). Traffic classes permit more sophisticated schemes.
	Access delay : The delay that a frame experiences waiting for permission to transmit on the LAN, in competition with frames from other stations attached to the same LAN. This delay is determined by the MAC protocol used (for example Token Ring, Carrier Sense Multiple Access Collision Detect [CSMA/CD]).

The total delay experienced by a frame at a bridge is the sum of its queuing delay and its access delay.

Figure 1 illustrates the mechanism used to support traffic classes at a bridge. A bridge may support up to eight different traffic classes on any outbound port by implementing up to eight distinct queues, or buffers, for that port. A traffic-class value is associated with each queue, ranging from a low of 0 to a high of N – 1, where N is the number of traffic classes associated with a given outbound port (N ≤ 8).

Figure 1: IEEE 802.1 D Traffic Class Operation



On a given output port with multiple queues, the rules for transmission follow:

1.	A frame may be transmitted from a queue only if all queues corresponding to numerically higher values of traffic class are empty. For example, if there is a frame in queue 0, it can be transmitted only if all the other queues at that port are currently empty.
2.	Within a given queue, the order of frame transmission must satisfy the following: The order of frames received by this bridge and assigned to this outbound port shall be preserved for: Unicast frames with a given combination of destination address and source address Multicast frames for a given destination address

In practice, a FIFO discipline is typically used. Thus, a strict priority mechanism is used. It follows that during times of congestion, lower-priority frames may be stuck indefinitely at a bridge that devotes its resources to moving out the higher-priority frames.

Mapping of User Priority to Traffic Class
IEEE 802.1D provides guidance on the mapping of user priorities into traffic classes. Table 2 shows the recommended mapping. We can make two comments immediately:

1.

The mapping is based on the user priority associated with the frame, which, as was mentioned earlier, has end-to-end significance. However, the 802.3 and 802.11 frame formats do not include a priority field, meaning that this end-to-end information could be lost. To address this issue, the bridge is able to reference the priority field contained in a tag header defined in IEEE 802.1Q, which deals with virtual LANs. The 802.1Q specification defines a tag header of 32 bits that is inserted after the source and destination address fields of the frame header. This tag header includes a 3-bit priority field. Thus, if 802.1Q is in use by Ethernet and wireless LAN sources, a user priority can be defined that stays with the frame from source to destination.

2.

Outbound ports associated with MAC methods that support only a single access priority, such as 802.3 and 802.11, can support multiple traffic classes. Recall that the traffic class deals with queuing delay, while the access priority deals with access delay.

To understand the reason for the mappings recommended in Table 2, we need to consider the types of traffic that are associated with each traffic class. IEEE 802.1D provides a list of traffic types, each of which can benefit from simple segregation from the others. In descending importance, these types include:

	Network control (7): Both time critical and safety critical, consisting of traffic needed to maintain and support the network infrastructure, such as routing protocol frames. Voice (6): Time critical, characterized by than 10-ms delay, such as interactive voice.
	Voice (6): Time critical, characterized by than 10-ms delay, such as interactive voice.
	Video (5): Time critical, characterized by less than 100-ms delay, such as interactive video.
	Controlled load (4): Non-time-critical but loss sensitive, such as streaming multimedia and business-critical traffic. A typical use is for business applications subject to some form of reservation or admission control, such as capacity reservation per flow.
	Excellent effort (3): Also non-time-critical but loss sensitive, but of lower priority than controlled load. This is a best-effort type of service that an information services organization would deliver to its most important customers.
	Best effort (2): Non-time-critical and loss insensitive. This is LAN traffic handled in the traditional fashion.
	Background (0): Non-time-critical and loss insensitive, but of lower priority than best effort. This type includes bulk transfers and other activities that are permitted on the network but that should not impact the use of the network by other users and applications.

Only seven traffic types are are defined in IEEE 802.1D. The standard leaves as spare an eighth type, which could be used for traffic of more importance than background but less importance than best effort. The numbers in parentheses in the preceding list are the traffic-class values corresponding to each traffic type if there are eight queues and hence eight traffic classes available at a given output port.

Table 2: Recommended User Priority to Traffic Class Mapping



We can now address the issue of the mapping between user-priority and traffic-class value. If eight traffic class values are available (eight queues at this output port), the obvious mapping would be equality; that is, a user priority of K would map into traffic class K for 0 ≤ K < 7. This obvious mapping is not desirable because of the treatment of default priorities. For 802.3 and 802.11, which do not use priorities, the default user priority is 0. For other MAC types, such as 802.5, if the user does not specify a priority, the MAC level assigns a default value of 0. The 802.1D standard points out that using a different default value would result in some confusion and probably a lack of interoperability. However, the logical default traffic type is best effort. The solution proposed by 802.1D is to map a user priority of 0 to traffic-class value 2. When there are eight traffic class values available, then user-priority values 1 and 2 map to traffic-class values 0 (background) and 1 (spare value), respectively.

This solution is reflected in Table 2, which shows the mapping of user priority to traffic class when there are eight available traffic classes. The table also shows the mapping when there are fewer traffic classes. To understand the entries in this table, we need to consider the way in which 802.1D recommends grouping traffic types when fewer than eight queues are configured at a given output port. Table 3 shows this grouping. The first row in the table shows that if there is only one queue, then all traffic classes are carried on that queue. This is obvious. If there are two queues (second row), 802.1D recommends assigning network control, voice, video, and controlled load to the higher-priority queue, and excellent effort, best effort, and background to the lower-priority queue. The reasoning supplied by the standard follows: To support a variety of services in the presence of bursty best-effort traffic, it is necessary to segregate time-critical traffic from other traffic. In addition, further taffic that is to receive superior service and that is operating under admission control also needs to be separated from the uncontrolled traffic. The allocation of traffic types to queues for the remaining rows of the table can be explained similarly.

Table 3: Suggested Traffic Types

Note: In each entry, the boldface type is the traffic type that has driven the allocation of types to classes.
BK = Background	VI = Video (<100 ms latency and jitter)
BE = Best Effort	VO = Voice (<10 ms latency and jitter)
EE = Excellent Effort	NC = Network Control
CL = Controlled Load

Internet Traffic Quality of Service
The user-priority and traffic-class concepts enable MAC-level bridges and Layer 2 switches to implement a traffic-handling policy within a bridged collection of LANs that gives preference to certain types of traffic. These concepts are needed because these bridges and switches cannot see "above" the MAC layer and hence cannot recognize or utilize QoS indications in higher layers such as IP. However, it is often the case that traffic from a bridged set of LANs must cross Wide-Area Networks (WANs) that make use of QoS functionality. An example of this is an ATM network, which provides for user-specified QoS. Another example is an IP-based internet, which can provide IP-level QoS. Some means is needed for mapping between traffic classes and QoS for such configurations. This is an evolving area of technology and standardization, but a general picture can be provided.

In the case of IP-based internets, the IP Type-of-Service (ToS) field provides a way to label traffic with different QoS demands. The ToS field is preserved along the entire path from source to destination through, potentially, multiple routers. Fortunately, the mapping from traffic class to ToS is straightforward. The ToS field includes a 3-bit Precedence subfield. A router connecting a LAN to an internet can be configured to read the Layer 2 Traffic-Class field and copy that into the ToS Precedence field in one direction, and copy the 3-bit Precedence field into the User Priority field in the other direction.

In the case of an ATM connection, a bridge or Layer 2 switch might be connected to a LAN on one side and an ATM network on the other, using the ATM network to link to other remote LANs. For local LAN traffic arriving at the bridge, the bridge must match the user priority level with the appropriate ATM service class and other ATM parameters. For this purpose, the bridge can consult a mapping table whose settings have been predefined through the policy controls of network management software. An appropriate virtual connection is used to carry the traffic. If the traffic exits the ATM network at another LAN, the bridge on that end can map incoming traffic from each virtual connection into the appropriate traffic class and user priority.

References
A more detailed discussion of bridges, Layer 2 switches, and IEEE 802.1D is contained in [1]. The IEEE 802.1 working group is at http://grouper.ieee.org/groups/802/1/index.html.

[1] Stallings, W., Local and Metropolitan Area Networks, Sixth Edition, Prentice Hall, 2000.

WILLIAM STALLINGS is a consultant, lecturer, and author of over a dozen books on data communications and computer networking. He has a PhD in computer science from M.I.T. His latest book is Local and Metropolitan Area Networks, Sixth Edition (Prentice Hall, 2000). His home in cyberspace is WilliamStallings.com and he can be reached at ws@shore.net