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 |
4 |
ftp-out |
saddr 10.190.17.44 daddr 10.100.10.53 sport 21 direction LOCAL_OUT |
See Also
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:
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.
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 |
8 |
mail_in |
daddr10.50.50.5 dport imap direction LOCAL_IN |
|
email
|
8 |
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 |
See Also
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.
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:
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 |
9 |
games_in |
sport 6080 |
N/A |
N/A |
games_app |
9 |
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.
See Also
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.
See Also
