Section 9.3. CoS

9.3. CoS

CoS, or Class of Service, systems work to prioritize traffic on a single data link. While QoS refers to the greater network, CoS refers to only a single data link. So, an Ethernet switch might provide a CoS packet prioritization to/from a single host, but a group of routers might participate in a more elaborate, end-to-end QoS solution. The key difference is this: CoS is a single-link approach, while QoS is an end-to-end approach.

Class of Service systems define per-hop behavior, so they cannot guarantee a service level in terms of capacity or speed. Instead they give their "best effort" to deliver priority traffic according to those per-hop behaviors, which are established by you, the administrator. Class of Service solutions are great on data links where less than 30% of the traffic is voice, which is probably a majority of enterprise networks today. But they tend not to be as effective when priority traffic like voice represents the lion's share of the packets on the data linkas is often the case when the data link is a slow one.

Two key standards support CoS:

• 802.1p/ToS

• DiffServ

9.3.1. 802.1p and ToS

802.1p uses a 3-bit portion of the Ethernet packet header to classify each packet into a particular level of precedence on the local data link. Each precedence level defines the per-hop behavior. 802.1p calls prioritization traffic class expediting . Type of Service (ToS) is the portion of the IP packet header that stores the same precedence information. Many vendors call ToS IP precedence . 802.1p and ToS tend to be used together when TCP/IP is the networking protocol.

If your VoIP network will be more than 70% data-to-voice and unlikely to reach capacity, packet prioritization techniques like LAN-oriented 802.1p and its WAN cousin DiffServ are adequate.

802.1p is a standard that benefits a single data link as opposed to a group of them using a single CoS policy. So it tends to be a feature of Ethernet switches, as opposed to IP routers, which instead support ToS. Since 3 bits are allocated for classification, 802.1p allows for eight classes of service. The names associated with these classes are arbitrary to the network they are used on, but Table 9-4 lists the suggested, generic names .

Table 9-4. Suggested 802.1p classes

Number	Name
	Routine
1	Priority
2	Immediate
3	Flash
4	Flash-override
5	Critical
6	Internet
7	Network

The eight classes' individual per-hop behaviors are administrator-defined, so you could define class 5 for voice traffic (which is the prevailing wisdom). This would give voice traffic higher precedence on the local data link. Each hop along the path of the traffic would have to support the same per-hop precedence behavior in order to make the QoS policy consistent across a routed WAN.

Like many low-layer standards, 802.1p is a product of the IEEE.

Project 9.1, later in the chapter, describes how to check all the routers along a certain call path to see if they support 802.1p.

9.3.2. DiffServ

DiffServ, defined in RFC 2474, is a CoS standard that uses ToS tags in a more elaborate manner than 802.1p. While 802.1p tends to be used in switched Ethernet environments, DiffServ is used to support routed point-to-point WANs. DiffServ is an abbreviation for Differentiated Services.

When a packet reaches the edge of the network, either from an endpoint or from a remote network, DiffServ tags that packet's ToS header based on the priority established for that packet by policy. Once admitted into a DiffServ-equipped WAN, however, all subsequent router hops must enforce the priority set by the edge router that admitted the packet.

So, while DiffServ is considered a per-hop behavior CoS system like 802.1p, all DiffServ routers in the network core must uphold the prioritization decision that occurs at the edge. That is to say, core routers don't reorder or prioritize the packets, but they do forward them using a precedence policy that was established at the edge.

Since a majority of bottlenecks occur on the edge of the network, on access links, rather than within the core network where there's usually tons of bandwidth, DiffServ may be the only Quality-of-Service standard necessary. Its policy decision points are always at the edge of the network.

In a nutshell , DiffServ furthers the concept of 802.1p so that priority policy can be established at the edgeonce for the entire networkrather than on each individual hop. What neither of these protocols does, though, is ensure that the network is never overrunthat's a key difference between CoS (what 802.1p and DiffServ are) and QoS.

9.3.2.1 Policy servers

Common Open Policy Service, or COPS, is a way of storing and querying centralized policy information on the network. DiffServ can use COPS to obtain its marching orders for how to handle traffic coming into the network. In a COPS scheme, a centralized server called the policy server contains a policy record of traffic shaping and prioritization preferences that DiffServ or another CoS/QoS mechanism can retrieve. COPS itself doesn't enforce the prioritizationthat's the job of DiffServ, which runs on routers; COPS just provides a way of maintaining a centralized record of the traffic policy. COPS is a product of the IETF Resource Allocation Protocol working group. Another IETF recommendation, LDAP (Lightweight Directory Access Protocol), can also be used as the basis of a policy server.

9.3.2.2 DSCP classes

DiffServ Code Points (DSCP) are IP packet headers DiffServ associates with different levels of importance. Since they're 6 bits in length, DSCPs can be used to define quite a wide scale of possible service levels. Most implementations support only 3 bits, replacing the 3 bits in IP's ToS header. The other 3 bits are earmarked for extensions to the DiffServ standard.

DSCP per-hop behaviors break down into three basic groups, interchangeably called PHB classes, traffic classes, or DSCP classes:

AF

Assured Forwarding , a highly expedient DSCP class, sometimes used to tag signaling packets such as H.245/H.225 and SIP packets.

EF

Expedited Forwarding , the most expedient DSCP class, used to tag packets carrying actual sound data.

BE

Best Effort , a nonexpedient DSCP class, used to tag non-voice packets. Many DiffServ decision points don't use BE.

When packets hit the edge of the network, the DiffServ-equipped edge router decides the PHB for each packet based on a judgment of which DSCP class the packet should fall into. High-priority packets get AF or EF, while the others get BE or no tag at all.

If you use DiffServ, configure your routers (or softPBX) to use Expedited Forwarding for all voice traffic. Project 9.1 describes how to set up a DiffServ edge router using Linux and iptables.

9.3.2.3 The DiffServ CoS process

DiffServ goes to work during call setup, when an RTP media session is being established. As the edge router handles the RTP session startup, while the calling party is transmitting its first packets of audio, a classification lookup is conducted against the COPS policy server in order to determine the priority of that RTP session.

In networks with no centralized policy servers, the DiffServ router admitting the traffic into the edge can have policy rules programmed into its onboard memory.

The COPS server informs the edge router which of the three DSCP classes each packet should carry. Once classified , the edge router tags the packet with the DSCP determined by policy. Furthermore, the edge router remembers a "policy rule" that applies to all subsequent packets in this particular RTP session. This way, they all get marked with the same priority. DSCP classes are backwardly compatible with ToS classes, so DiffServ doesn't preclude the continued use of 802.1p on local area data links (see Figure 9-3).

As the RTP traffic flows through the core of the network, it has already been classified and marked, so that core routers are spared the task of having to look up the policy repeatedly. Specific per-hop behaviors will always be the same as each packet

Figure 9-3. In DiffServ, edge routers determine the per-hop behavior as the packet enters the network

in the stream flows from one core router to the next . DiffServ has several advantageous qualities:

• As an IP-only solution, is usually managed with the same equipment used to manage an IP WAN: routers

• Can run transparently alongside other QoS solutionsincluding 802.1p and RSVP

• Is easy to set up on small- to mid- sized routed enterprise networks

• Can be optionally policy-based using COPS or LDAP

• Pushes QoS decisions to the edge of the network, resulting in less complexity

• Is compatible with IPv4 and IPv6

9.3.3. Project 9.1. Create a DiffServ Decision Point with Linux

9.3.3.1 What you need for this project:

• A Linux server capable of running the Netfilter firewall

• LAN

A Linux server that acts as a firewall or edge router can provide DiffServ policy enforcement just as a Cisco router can. It can also perform some packet-manipulationsay, to tag the priority of an 802.1p-tagged packet as it hits a locally connected Ethernet segment. Red Hat Linux 9 and Red Hat Enterprise Linux have DiffServ and 802.1p support precompiled. Other Linux kernels of Version 2.4 and above can have support for DiffServ and 802.1p compiled, as long as the kernel in question is compiled with these options enabled:

• Kernel/ user netlink socket CONFIG_NETLINK

• Packet filtering CONFIG_NETFILTER

• QoS and/or fair queuing CONFIG_NET_SCHED

All options organized under that last QoS option must be enabled. If not using Red Hat 9 or Enterprise, you may also need to obtain, compile, and install the iproute2 package. This package, and the kernel modifications introduced for QoS, together form the Linux Traffic Control system, a software library that you can control using a program called tc . Issuing the tc command is the quickest way to find our whether iproute2 is installed. If you get a "command not found," then you don't have iproute2 .

Since it was designed to handle the QoS issues related to all kinds of network communications, not just VoIP, the Linux Traffic Control framework can be an overwhelming topic. While this exercise will show you how to mark RTP packets for a DiffServ domain, there are more practical (albeit more expensive) options for DiffServ than LTC, such as commercial routers.

Before you go any further, you should know that Linux Traffic Control supports a vast array of buffering, prioritization, tagging, and other traffic-shaping tactics. In fact, using LTC and Linux's kernel-based firewall, iptables, about a dozen different QoS standards can be applied. Some use a technique called weighted or fair queuing , which may hold and forward packets based on size or by transmission rate controla technique sometimes called leaky bucket . LTC calls each technique for queuing or rate control a discipline . Other techniques use prioritization like 802.1p. Not all of LTC's capabilities are especially good for VoIP.

That said, configuring QoS enforcement points is more straightforward with brand-name routers because they offer well-documented, easy-to-administer QoS commands and integrate well with COPS. On Linux, a majority of QoS configurations are done using iptables, the command for altering the Linux kernel's built-in packet-filtering firewall, known as Netfilter.

Using iptables to support DiffServ can create a policy decision point on the edge of the network. Core routers must also support DiffServ if the measure is to be successful from end to end.

9.3.3.2 Configure an iptables edge router for DiffServ

iptables can be configured to match packets based on origin/destination, protocol, or port numbers and then perform edge-style DiffServ classification before forwarding them. In this example, iptables matches all incoming or outgoing UDP traffic on a standard RTP destination port (5004) and assigns a DSCP class of EF using the iptables DSCP target:

 iptables -A PREROUTING -p udp -D 0.0.0.0/0.0.0.0 --dport 5004 -j DSCP\     --set-dscp-class EF 

The -A PREROUTING option tells Netfilter to apply this rule before the kernel routes the packet to its next hop. -p udp tells Netfilter to apply this rule only to UDP datagrams, ignoring TCP packets. The dport 5004 option tells Netfilter that only packets destined for port 5004 (that is, RTP packets) should have this rule applied. Next, -j DSCP describes a target chain in which to modify the packet. Last, the - -set-dscp-class EF option, which works only when the DSCP target chain is specified, changes the DSCP class of the matched packets to Expedited Forwarding.

If your Linux firewall is a point of connectivity for more than one network, it's possible to define DSCP classes on the basis of the destination network. If certain networks are associated with a different service level, you can tag the traffic as such. In this example, the 10.2.0.0 network gets Expedited Forwarding, while the 10.3.0.0 network gets Assured Forwarding:

 iptables -A PREROUTING -p udp -D 10.2.0.0/255.255.0.0 --dport 5004 -j DSCP\     --set-dscp-class EF     iptables -A PREROUTING -p udp -D 10.3.0.0/255.255.0.0 --dport 5004 -j DSCP\     --set-dscp-class AF 

Likewise, if protocols other than RTP are to make use of DiffServ, you can have your decision point tag them appropriately. This example tags IAX and RTP traffic as EF, while tagging all other UDP traffic as AF:

 iptables -A PREROUTING -p udp -D 0.0.0.0/0.0.0.0 --dport 5004,5036,4569\     -j DSCP --set-dscp-class EF     iptables -A PREROUTING -p udp -j DSCP --set-dscp-class AF 

The DSCP target of iptables will work only if the kernel has been compiled with the CONFIG_IP_NF_TARGET_DSCP option enabled, as described earlier.

iptables provides DiffServ awareness for only IP Version 4.

Once a packet is marked with the appropriate DSCP class, it's up to the core routers to treat that mark with respect. If the DSCP class is EF, like the previous iptables example, then core routers need to expedite the traffic immediately.

9.3.3.3 LTC for DiffServ core routers

Indeed, if you intend to have your Linux firewall do something special with the packets depending on their DSCP class, then you can use iptables to tell Netfilter how to process them as a core router on a DiffServ domain would.

With a little bit of Linux Traffic Control diligence, iptables can be used to establish an even more extensive QoS enforcement point or a core router.

9.3.3.4 LTC on a softPBX

It can also be used, on a Linux-based softPBX, to tag traffic with the EF class. This way, the DiffServ decision point and the softPBX can reside on the same machine.

For more details, an excellent book on using Netfilter firewalls is Linux iptables Pocket Reference (O'Reilly). Another is Building Secure Servers with Linux (O'Reilly). LTC-specific resources are available at the Linux Advanced Routing and Traffic Control web site (http://www.lartc.org).