NEW YORK—As broadcasters increasingly move toward IP-based systems within their facilities and for wide area network connections, the ability to prioritize some packets over others is becoming more desirable.
One popular method for doing this is called Differentiated Services or “DiffServ,” which uses a data field within the IPv4 (and IPv6) packet header. Several standards have been produced that take advantage of this functionality for video and audio applications, including the AES67 standard for high-performance IP audio streaming interoperability that was published in 2013.
Already, many systems can implement DiffServ, but effective network management may require some thought about which flows to prioritize and how to treat different forms of traffic. Since there are no hard and fast rules about which packet streams have to be given priority over other streams, only guidelines, broadcasters need to make an informed decision about how to configure their priority schemes to suit their particular needs.
Fig. 1: Comparison of ToS and DiffServ fields
LABELING THE PACKETS
In the original version of the IPv4 specification (IETF RFC 791), eight bits of the packet header were reserved for a function called “Type of Service” or ToS. Packets with a higher value in the first three bits of this field (see Fig. 1) were given precedence over other packets, allowing them to be given seven different levels of priority for congested resources such as a limited-capacity data path between two routers. The remaining five bits were originally designated for three flags that could be used to give more information about the flow, and the last two bits were reserved for future use in the original standard. Note that a fourth flag bit was added in the later RFC 1349 in place of one of the reserved bits.
DiffServ was defined in RFC 2474, which was published in 1998, and has been modified slightly since then. In place of the three-bit priority field and three one-bit flags defined in RFC 791, DiffServ uses six bits for defining up to 64 possible Differentiated Services Code Points, or DSCPs. Each of the codes can be used to define a specific priority level for a group of packet flows within the network.
All packets that are labeled with a given code point are given the same priority and treated the same by nodes in the network. This so-called “coarse-grained” mechanism provides a straightforward means to prioritize packets at each hop along a network, thereby creating a prioritized end-to-end system.
GIVING PRIORITY
DiffServ behavior within a network is based on classifying and labeling packets into groups (also known as Behavior Aggregates or “BA”), which can be treated as equals when they are sent between nodes along a network path. For each connection between a pair of network nodes, Per Hop Behaviors (PHB) are configured for each of the different BAs (priority groups). Different amounts of bandwidth, different queue sizes, different ways to deal with oversub-scription and other packet processing functions can be specified for each PHB.
Several different PHBs have been defined in the DiffServ standard:
The Default Forwarding (DF) or “Best Effort” code point is used for packets that do not require any specific level of priority, and are given a DSCP of 000000, which is a decimal value of 0. These packets will be given the lowest available priority.
Expedited Forwarding (EF) as defined in RFC 3246 code point should be reserved for packet streams that require very high performance, with low levels of loss, jitter and latency, along with assured bandwidth. In normal enterprise networks, this code point might be used for Voice over IP (VoIP), to minimize the latency and jitter of these signals that might occupy only a small fraction of the overall network bandwidth. However, in media facility networks, since most of the network bandwidth will be occupied by video and audio signals, AES67 recommends using the EF code point only for IEEE-1588 Precision Timing Protocol (PTP) messages. EF packets are given a DSCP of 101110, which is a decimal value of 46.
Fig. 2: DiffServ code points for assured forwarding
Assured Forwarding (AF) as defined in RFC 2597 provides a dozen different code points for assigning priority levels to various BAs. There are four classes (1 through 4), each of which has three drop precedence levels (Low (1), Medium (2) and High (3), where High Precedence packets are more likely to be dropped), and are shown in Fig. 2. Each of the four classes should be given a defined amount of buffer space and output interface bandwidth for each network hop. For audio packets, AES67 recommends using the AF41 DSCP of 100010, which is a decimal value of 34. This is the highest class of forwarding with the lowest probability of having packets dropped within AF.
Class Selectors(CS) of 1 through 7 are also defined in RFC 2474; these simply use the first three bits of the DSCP field to contain the binary values 1 through 7, with the remaining three bits in the DSCP set to 000.
This ability to configure how each hop through the network handles the different priority levels provides one of the largest benefits of DiffServ. This technology removes the need for endpoint devices to issue reservation requests for paths with specific amounts of bandwidth through a network and eliminates complex management systems and databases at each network node to track the priorities and bandwidth requirements of thousands of streams that pass through them.
The result is a priority mechanism that can scale up to cover a large, distributed network without requiring centralized control or complex communications between network nodes.
If you are wondering about the last two bits of the Differentiated Services field, those have now been designated for Explicit Congestion Notification, which will have to be a subject for a future column.
Wes Simpson wishes that all of his Internet traffic could be given the highest priority. He can be reached atwes.simpson@gmail.com.
