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:
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.
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
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.
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.
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.
18.104.22.168 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.
22.214.171.124 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:
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.
126.96.36.199 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.
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:
9.3.3. Project 9.1. Create a DiffServ Decision Point with Linux
188.8.131.52 What you need for this project:
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:
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 .
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.
184.108.40.206 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.
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.
220.127.116.11 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.
18.104.22.168 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).