Planning the Quality-of-Service Policy

When you plan the quality-of-service (QoS) policy, you must review, classify, and then prioritize the services that your network provides. You must also assess the amount of available bandwidth to determine the rate at which each traffic class is released onto the network.

QoS Policy Planning Aids

Gather information for planning the QoS policy in a format that includes the information needed for the IPQoS configuration file. For example, you can use the following template to list the major categories of information to be used in the IPQoS configuration file.

Table 33-1 QoS Planning Template

Class	Priority	Filter	Selector	Rate	Forwarding?	Accounting?
Class 1	1	Filter 1 Filter 3	Selector 1 Selector 2	Meter rates, depending on meter type	Marker drop precedence	Requires flow-accounting statistics
Class 1	1	Filter 2	Selector 1 Selector 2	N/A	N/A	N/A
Class 2	2	Filter 1	Selector 1 Selector 2	Meter rates, depending on meter type	Marker drop precedence	Requires flow-accounting statistics
Class 2	2	Filter 2	Selector 1 Selector 2	N/A	N/A	N/A

You can divide each major category to further define the QoS policy. Subsequent sections explain how to obtain information for the categories that are shown in the template.

QoS Policy Planning (Task Map)

This task map lists the major tasks for planning a QoS policy.

Task	Description	For Instructions
1. Design your network topology to support IPQoS.	Identify the hosts and routers on your network to provide differentiated services.	How to Prepare a Network for IPQoS
2. Define the classes into which services on your network must be divided.	Examine the types of services and SLAs that are offered by your site, and determine the discrete traffic classes into which these services fall.	How to Define the Classes for Your QoS Policy
3. Define filters for the classes.	Determine the best ways of separating traffic of a particular class from the network traffic flow.	How to Define Filters in the QoS Policy
4. Define flow-control rates for measuring traffic as packets leave the IPQoS system.	Determine acceptable flow rates for each class of traffic.	How to Plan Flow Control
5. Define DSCPs or user-priority values to be used in the QoS policy.	Plan a scheme to determine the forwarding behavior that is assigned to a traffic flow when the flow is handled by the router or switch.	How to Plan Forwarding Behavior
6. If applicable, set up a statistics-monitoring plan for traffic flows on the network.	Evaluate the traffic classes to determine which traffic flows must be monitored for accounting or statistical purposes.	How to Plan for Flow Accounting

Note - The rest of this section explains how to plan the QoS policy of an IPQoS-enabled system. To plan the QoS policy for the Diffserv router, refer to the router documentation and the router manufacturer's web site.

How to Prepare a Network for IPQoS

The following procedure lists general planning tasks to do before you create the QoS policy.

Review your network topology. Then, plan a strategy that uses IPQoS systems and Diffserv routers.
For topology examples, see Planning the Diffserv Network Topology.
Identify the hosts in the topology that require IPQoS or that might become good candidates for IPQoS service.
Determine which IPQoS-enabled systems could use the same QoS policy.
For example, if you plan to enable IPQoS on all hosts on the network, identify any hosts that could use the same QoS policy. Each IPQoS-enabled system must have a local QoS policy, which is implemented in its IPQoS configuration file. However, you can create one IPQoS configuration file to be used by a range of systems. You can then copy the configuration file to every system with the same QoS policy requirements.
Review and perform any planning tasks that are required by the Diffserv router on your network.
Refer to the router documentation and the router manufacturer's web site for details.

How to Define the Classes for Your QoS Policy

The first step in defining the QoS policy is organizing traffic flows into classes. You do not need to create classes for every type of traffic on a Diffserv network. Moreover, depending on your network topology, you might have to create a different QoS policy for each IPQoS-enabled system.

Note - For an overview of classes, see IPQoS Classes.

The next procedure assumes that you have determined which systems on your network are to be IPQoS-enabled, as identified in How to Prepare a Network for IPQoS.

Create a QoS planning table for organizing the QoS policy information.
For suggestions, refer to Table 33-1.
Perform the remaining steps for every QoS policy that is on your network.
Define the classes to be used in the QoS policy.
The following questions are a guideline for analyzing network traffic for possible class definitions.
- Does your company offer service-level agreements to customers?
  If yes, then evaluate the relative priority levels of the SLAs that your company offers to customers. The same applications might be offered to customers who are guaranteed different priority levels.
  For example, your company might offer web site hosting to each customer, which indicates that you need to define a class for each customer web site. One SLA might provide a premium web site as one service level. Another SLA might offer a “best-effort” personal web site to discount customers. This factor indicates not only different web site classes but also potentially different per-hop behaviors that are assigned to the web site classes.
- Does the IPQoS system offer popular applications that might need flow control?
  You can improve network performance by enabling IPQoS on servers offering popular applications that generate excessive traffic. Common examples are electronic mail, network news, and FTP. Consider creating separate classes for incoming and outgoing traffic for each service type, where applicable. For example, you might create a mail-in class and a mail-out class for the QoS policy for a mail server.
- Does your network run certain applications that require highest-priority forwarding behaviors?
  Any critical applications that require highest-priority forwarding behaviors must receive highest priority in the router's queue. Typical examples are streaming video and streaming audio.
  Define incoming classes and outgoing classes for these high-priority applications. Then, add the classes to the QoS policies of both the IPQoS-enabled system that serves the applications and the Diffserv router.
- Does your network experience traffic flows that must be controlled because the flows consume large amounts of bandwidth?
  Use netstat, snoop, and other network monitoring utilities to discover the types of traffic that are causing problems on the network. Review the classes that you have created thus far, and then create new classes for any undefined problem traffic category. If you have already defined classes for a category of problem traffic, then define rates for the meter to control the problem traffic.
  Create classes for the problem traffic on every IPQoS-enabled system on the network. Each IPQoS system can then handle any problem traffic by limiting the rate at which the traffic flow is released onto the network. Be sure also to define these problem classes in the QoS policy on the Diffserv router. The router can then queue and schedule the problem flows as configured in its QoS policy.
- Do you need to obtain statistics on certain types of traffic?
  A quick review of an SLA can indicate which types of customer traffic require accounting. If your site does offer SLAs, you probably have already created classes for traffic that requires accounting. You might also define classes to enable statistics gathering on traffic flows that you are monitoring. You could also create classes for traffic to which you restrict access for security reasons.
List the classes that you have defined in the QoS planning table you created in Step 1.
Assign a priority level to each class.
For example, have priority level 1 represent the highest-priority class, and assign descending-level priorities to the remaining classes. The priority level that you assign is for organizational purposes only. Priority levels that you set in the QoS policy template are not actually used by IPQoS. Moreover, you can assign the same priority to more than one class, if appropriate for your QoS policy.
When you finish defining classes, you next define filters for each class, as explained in How to Define Filters in the QoS Policy.

More Information

Prioritizing the Classes

As you create classes, you quickly realize which classes have highest priority, medium priority, and best-effort priority. A good scheme for prioritizing classes becomes particularly important when you assign per-hop behaviors to outgoing traffic, as explained in How to Plan Forwarding Behavior.

In addition to assigning a PHB to a class, you can also define a priority selector in a filter for the class. The priority selector is active on the IPQoS-enabled host only. Suppose several classes with equal rates and identical DSCPs sometimes compete for bandwidth as they leave the IPQoS system. The priority selector in each class can further order the level of service that is given to the otherwise identically valued classes.

Defining Filters

You create filters to identify packet flows as members of a particular class. Each filter contains selectors, which define the criteria for evaluating a packet flow. The IPQoS-enabled system then uses the criteria in the selectors to extract packets from a traffic flow. The IPQoS system then associates the packets with a class. For an introduction to filters, see IPQoS Filters.

The following table lists the most commonly used selectors. The first five selectors represent the IPQoS 5-tuple, which the IPQoS system uses to identify packets as members of a flow. For a complete list of selectors, see Table 37-1.

Table 33-2 Common IPQoS Selectors

Name	Definition
`saddr`	Source address.
`daddr`	Destination address.
`sport`	Source port number. You can use a well-known port number, as defined in `/etc/services`, or a user-defined port number.
`dport`	Destination port number.
`protocol`	IP protocol number or protocol name that is assigned to the traffic flow type in `/etc/protocols`.
`ip_version`	Addressing style to use. Use either IPv4 or IPv6. IPv4 is the default.
`dsfield`	Contents of the DS field, that is, the DSCP. Use this selector for extracting incoming packets that are already marked with a particular DSCP.
`priority`	Priority level that is assigned to the class. For more information, see How to Define the Classes for Your QoS Policy.
`user`	Either the UNIX user ID or user name that is used when the upper-level application is executed.
`projid`	Project ID that is used when the upper-level application is executed.
`direction`	Direction of traffic flow. Value is either `LOCAL_IN`, `LOCAL_OUT`, `FWD_IN`, or `FWD_OUT`.

Note - Be judicious in your choice of selectors. Use only as many selectors as you need to extract packets for a class. The more selectors that you define, the greater the impact on IPQoS performance.

How to Define Filters in the QoS Policy

Before You Begin

Before you can perform the next steps, you should have completed the procedure How to Define the Classes for Your QoS Policy.

Create at least one filter for each class in the QoS planning table that you created in How to Define the Classes for Your QoS Policy.
Consider creating separate filters for incoming and outgoing traffic for each class, where applicable. For example, add an ftp-in filter and an ftp-out filter to the QoS policy of an IPQoS-enabled FTP server. You then can define an appropriate direction selector in addition to the basic selectors.
Define at least one selector for each filter in a class.
Use the QoS planning table that was introduced in Table 33-1 to fill in filters for the classes you defined.

Example 33-1 Defining Filters for FTP Traffic

The next table shows how you would define a filter for outgoing FTP traffic.

Class

Priority

Filters

Selectors

ftp-traffic

ftp-out

saddr 10.190.17.44

daddr 10.100.10.53

sport 21

direction LOCAL_OUT

How to Plan Flow Control

Flow control involves measuring traffic flow for a class and then releasing packets onto the network at a defined rate. When you plan flow control, you define parameters to be used by the IPQoS metering modules. The meters determine the rate at which traffic is released onto the network. For an introduction to the metering modules, see Meter (tokenmt and tswtclmt) Overview.

The next procedure assumes that you have defined filters and selectors, as described in How to Define Filters in the QoS Policy.

Determine the maximum bandwidth for your network.
Review any SLAs that are supported on your network. Identify customers and the type of service that is guaranteed to each customer.
To guarantee a certain level of service, you might need to meter certain traffic classes that are generated by the customer.
Review the list of classes that you created in How to Define the Classes for Your QoS Policy.
Determine if any classes other than those classes that are associated with SLAs need to be metered.
Suppose the IPQoS system runs an application that generates a high level of traffic. After you classify the application's traffic, meter the flows to control the rate at which the packets of the flow return to the network.

Note - Not all classes need to be metered. Remember this guideline as you review your list of classes.
Determine which filters in each class select traffic that needs flow control. Then, refine your list of classes that require metering.
Classes that have more than one filter might require metering for only one filter. Suppose that you define filters for incoming and outgoing traffic of a certain class. You might conclude that only traffic in one direction requires flow control.
Choose a meter module for each class to be flow controlled.
Add the module name to the meter column in your QoS planning table.
Add the rates for each class to be metered to the organizational table.
If you use the tokenmt module, you need to define the following rates in bits per second:
- Committed rate
- Peak rate
If these rates are sufficient to meter a particular class, you can define only the committed rate and the committed burst for tokenmt.
If needed, you can also define the following rates:
- Committed burst
- Peak burst
For a complete definition of tokenmt rates, refer to Configuring tokenmt as a Two-Rate Meter. You can also find more detailed information in the tokenmt(7ipp) man page.
If you use the tswtclmt module, you need to define the following rates in bits per second.
- Committed rate
- Peak rate
You can also define the window size in milliseconds. These rates are defined in tswtclmt Metering Module and in the twstclmt(7ipp) man page.
Add traffic conformance outcomes for the metered traffic.
The outcomes for both metering modules are green, red, and yellow. Add to your QoS organizational table the traffic conformance outcomes that apply to the rates you define. Outcomes for the meters are fully explained in Meter Module.
You need to determine what action should be taken on traffic that conforms, or does not conform, to the committed rate. Often, but not always, this action is to mark the packet header with a per-hop behavior. One acceptable action for green-level traffic could be to continue processing while traffic flows do not exceed the committed rate. Another action could be to drop packets of the class if flows exceed peak rate.

Example 33-2 Defining Meters

The next table shows meter entries for a class of email traffic. The network on which the IPQoS system is located has a total bandwidth of 100 Mbits/sec, or 10000000 bits per second. The QoS policy assigns a low priority to the email class. This class also receives best-effort forwarding behavior.

Class

Priority

Filter

Selector

Rate

email

mail_in

daddr10.50.50.5

dport imap

direction LOCAL_IN

email

mail_out

saddr10.50.50.5

sport imap

direction LOCAL_OUT

meter=tokenmt

committed rate=5000000

committed burst =5000000

peak rate =10000000

peak burst=1000000

green precedence=continue processing

yellow precedence=mark yellow PHB

red precedence=drop

How to Plan Forwarding Behavior

Forwarding behavior determines the priority and drop precedence of traffic flows that are about to be forwarded to the network. You can choose two major forwarding behaviors: prioritize the flows of a class in relationship to other traffic classes or drop the flows entirely.

The Diffserv model uses the marker to assign the chosen forwarding behavior to traffic flows. IPQoS offers the following marker modules.

dscpmk – Used to mark the DS field of an IP packet with a DSCP
dlcosmk – Used to mark the VLAN tag of a datagram with a class-of-service (CoS) value

Note - The suggestions in this section refer specifically to IP packets. If your IPQoS system includes a VLAN device, you can use the dlcosmk marker to mark forwarding behaviors for datagrams. For more information, refer to Using the dlcosmk Marker With VLAN Devices.

To prioritize IP traffic, you need to assign a DSCP to each packet. The dscpmk marker marks the DS field of the packet with the DSCP. You choose the DSCP for a class from a group of well-known codepoints that are associated with the forwarding behavior type. These well-known codepoints are 46 (101110) for the EF PHB and a range of codepoints for the AF PHB. For overview information on DSCP and forwarding, refer to Traffic Forwarding on an IPQoS-Enabled Network.

Before You Begin

The next steps assume that you have defined classes and filters for the QoS policy. Though you often use the meter with the marker to control traffic, you can use the marker alone to define a forwarding behavior.

Review the classes that you have created thus far and the priorities that you have assigned to each class.
Not all traffic classes need to be marked.
Assign the EF per-hop behavior to the class with the highest priority.
The EF PHB guarantees that packets with the EF DSCP 46 (101110) are released onto the network before packets with any AF PHBs. Use the EF PHB for your highest-priority traffic. For more information about EF, refer to Expedited Forwarding (EF) PHB.
Assign forwarding behaviors to classes that have traffic to be metered.
Assign DS codepoints to the remaining classes in agreement with the priorities that you have assigned to the classes.

Example 33-3 QoS Policy for a Games Application

Traffic is generally metered for the following reasons:

An SLA guarantees packets of this class greater service or lesser service when the network is heavily used.
A class with a lower priority might have a tendency to flood the network.

You use the marker with the meter to provide differentiated services and bandwidth management to these classes. For example, the following table shows a portion of a QoS policy. This policy defines a class for a popular games application that generates a high level of traffic.

Class

Priority

Filter

Selector

Rate

Forwarding?

games_app

games_in

sport 6080

N/A

games_app

games_out

dport 6081

meter=tokenmt

committed rate=5000000

committed burst =5000000

peak rate =10000000

peak burst=15000000

green precedence=continue processing

yellow precedence=mark yellow PHB

red precedence=drop

green =AF31

yellow=AF42

red=drop

The forwarding behaviors assign low-priority DSCPs to games_app traffic that conforms to its committed rate or is under the peak rate. When games_app traffic exceeds peak rate, the QoS policy indicates that packets from games_app are to be dropped. All AF codepoints are listed in Table 37-2.

How to Plan for Flow Accounting

You use the IPQoS flowacct module to track traffic flows for billing or network management purposes. Use the following procedure to determine if your QoS policy should include flow accounting.

Does your company offer SLAs to customers?
If the answer is yes, then you should use flow accounting. Review the SLAs to determine what types of network traffic your company wants to bill customers for. Then, review your QoS policy to determine which classes select traffic to be billed.
Are there applications that might need monitoring or testing to avoid network problems?
If the answer is yes, consider using flow accounting to observe the behavior of these applications. Review your QoS policy to determine the classes that you have assigned to traffic that requires monitoring.
Mark Y in the flow-accounting column for each class that requires flow accounting in your QoS planning table.