IEEE 802.1p/Q at the Ethernet layer (Layer 2) and DSCP at the IP layer (Layer 3) are two standards-based CoS mechanisms that are used by Avaya products. These mechanisms are supported by the IP telephone, procr, G4xx media gateways, and Avaya Aura® Media Server. Although TCP/UDP source and destination ports are not CoS mechanisms, they can be used to identify specific traffic and can be used much like CoS tags. Another non-CoS methods to identify specific traffic is to key in on source and destination IP addresses and specific protocols, such as RTP. The Media Processor circuit pack and IP telephones use RTP to encapsulate audio.

Because of this format change, older switches had to be explicitly configured to accept 802.1Q tagged frames. Otherwise, the switches reject the tagged frames. However, this problem has not been significant during the last few years.

The two fields to be concerned with are the Priority and Vlan ID (VID) fields. The Priority field is the p in 802.1p/Q, and ranges from 0 to 7. 802.1p/Q is a common term used to indicate that the Priority field in the 802.1Q tag has significance. Prior to real-time applications, 802.1Q was used primarily for VLAN trunking, and the Priority field was not important. The VID field is used to indicate the VLAN to which the Ethernet frame belongs.

The IP header with its 8-bit Type of Service (ToS) field was originally used and is still used in some cases. This original scheme was not widely used, and the IETF developed a new Layer 3 CoS tagging method for IP called Differentiated Services (DiffServ, RFC 2474/2475). DiffServ uses the first 6 bits of the ToS field and ranges in value from 0 to 63. Comparison of DSCP with original ToS shows the original ToS scheme and DSCP in relation to the 8 bits of the ToS field.

Ideally, any DSCP value should map directly to a precedence and traffic parameter combination of the original scheme. However, this mapping does not exist in all cases and might cause problems on some older devices.

On any device, new or old, a nonzero value in the ToS field has no effect if the device is not configured to examine the ToS field. Problems arise on some legacy devices when the ToS field is examined, either by default or by enabling QoS. These legacy devices (network and endpoint) might contain code that implemented only the precedence portion of the original ToS scheme, with the remaining bits defaulted to zeros. This means that only DSCP values that are divisible by 8 (XXX000) can map to the original ToS scheme. For example, if an endpoint is tagging with DSCP 40, a legacy network device can be configured to look for precedence 5, because both values show up as 10100000 in the ToS field. However, a DSCP of 46 (101110) cannot be mapped to any precedence value alone. Another problem arises if the existing code implemented precedence with only one traffic parameter permitted to be set high. In this case, a DSCP of 46 still does not work, because it requires 2 traffic parameter bits to be set high. When these mismatches occur, an older device, about 10 years older, might reject the DSCP tagged IP packet or exhibit some other abnormal behavior. Most newer devices support both DSCP and the original ToS scheme.