IPQoS Administration Guide

Planning the Quality-of-Service Policy

When you plan the quality-of-service 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 that you need for the IPQoS configuration file. For example, you can use the following template to list the major information to be used in the IPQoS configuration file.

Table 2–2 QoS Organizational Template


Class	Priority	Filters	Selectors	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
		Filter 2	Selector 1 Selector 2
Class 2	2	Filter 1	Selector 1 Selector 2	Meter rates, depending on meter type	Marker drop precedence	Requires flow-accounting statistics
		Filter 2	Selector 1 Selector 2

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

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

Table 2–3 QoS Policy Planning (Task Map)


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 it leaves the IPQoS system.	Determine acceptable flow rates for each class of traffic.	How to Plan Flow Control
5. Define DS codepoints 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 router documentation and the router manufacturers' Web sites.

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 and 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 requirements.

Review and perform any planning tasks that are required by the diffserv router on your network.

Refer to the router documentation and 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 different QoS policies for each IPQoS-enabled system.

Note –

For an overview of classes, see 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 table for organizing the QoS policy.

For suggestions, refer to Table 2–2.

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. Moreover, one SLA might provide a premium web site as one service level, while another SLA offers 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 that offer popular applications that generate a lot of 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 to the QoS policy for a mail server.
- Does your network run certain applications that require highest-priority forwarding behaviors?
  
  Any critical applications that require the highest-priority forwarding behaviors must be given special treatment by the router. 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 they 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 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 it receives 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 add statistics taking to traffic flows that you are monitoring or to which you are restricting access for security purposes.

List the classes you have defined in the organizational table.

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 you assign is for organizational purposes only and is not actually used by IPQoS. Moreover, you can assign the same priority to more than one class, if appropriate for your QoS policy.

For information about the importance of prioritizing classes, refer to the next section.

When you finish defining classes, you next define filters for each class, as explained in How to Define Filters in the QoS Policy.

Prioritizing the Classes

As you create classes, it quickly becomes apparent which classes have highest priority, medium priority, and best-effort priority. Prioritizing the 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.

How to Define Filters in the QoS Policy

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 and associate them with a class. (For an introduction to filters, see Filters.)

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 organizational 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. Then you can define an appropriate direction selector in addition to the basic selectors.

Define at least one selector for each filter in a class.

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 6–1.

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 you define, the greater the impact on IPQoS performance.

Table 2–4 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 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 V4 or V6. V4 is the default.
`dsfield`	Contents of the DS field, that is, the DS codepoint. 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 Prioritizing the Classes.
`user`	Either the UNIX userID 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.

Use the template that was introduced in Table 2–2 to fill in filters for the classes you defined.

Class	Priority	Filters	Selectors
ftp-traffic	4	ftp-out	`saddr 10.190.17.44` `daddr 10.100.10.53` `sport 21` `direction LOCAL_OUT`

Class

Priority

Filters

Selectors

ftp-traffic

ftp-out

saddr 10.190.17.44

daddr 10.100.10.53

sport 21

direction LOCAL_OUT

Where to Go From Here

Task	For Information
Define a flow-control scheme	How to Plan Flow Control
Define forwarding behaviors for flows as they return to the network stream	How to Plan Forwarding Behavior
Plan for flow accounting of certain types of traffic	How to Plan for Flow Accounting
Add more classes to the QoS policy	How to Define the Classes for Your QoS Policy
Add more filters to the QoS policy	How to Define Filters in the QoS Policy

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 module. The meter determines the rate at which traffic is released onto the network. For an introduction to the meter, 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 to identify customers and the type of service that is guaranteed to each customer.

Because the SLA guarantees a certain level of service to a customer, 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 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.

Refine your list of classes to be metered by determining which filters in the class select traffic that needs flow control.

Classes that have more than one filter might require metering for only one filter. Suppose you define filters for incoming and outgoing traffic of a certain class. You might conclude that only traffic in one of the directions requires flow control.

Choose a meter module for each class to be flow controlled.

Add the module name to the meter column in your organizational 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 sufficient to meter a particular class, you can define only the committed rate and 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 this action is to mark the packet header with a per-hop behavior, but not always. 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.

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 Mbps, or 100000000 bits per second. The QoS policy assigns a low priority and best-effort forwarding behavior for the email class.

Table 2–5 Example QoS Policy With Meters Defined


Class	Priority	Filters	Selectors	Rate
`email`	8	`mail_in`	`daddr` 10.50.50.5 `dport imap` `direction LOCAL_IN`
		`mail_out`	`saddr` 10.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

Where to Go From Here

Task	For Information
Define forwarding behaviors for flows as they return to the network stream	How to Plan Forwarding Behavior
Plan for flow accounting of certain types of traffic	How to Plan for Flow Accounting
Add more classes to the QoS policy	How to Define the Classes for Your QoS Policy
Add more filters to the QoS policy	How to Define Filters in the QoS Policy
Define another flow-control scheme	How to Plan Flow Control
Create an IPQoS configuration file	How to Begin the IPQoS Configuration File and Define Traffic Classes

How to Plan Forwarding Behavior

Forwarding behavior determines the priority and drop precedence of traffic flows that are about to be forwarded onto the network. You can choose two major forwarding behaviors: prioritizing the flows of a class in relationship to other traffic classes or dropping 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, which you use to mark the DS field of an IP packet with a DS codepoint.
dlcosmk, which you use 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 DS codepoint to each packet. The dscpmk marker marks the DS field of the packet with the DS codepoint. You choose the DS codepoint 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 DS codepoints and forwarding, refer to Traffic Forwarding on an IPQoS-Enabled Network.

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 them.

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 DS codepoint 46 (101110) are released onto the network before packets that are marked 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.

Traffic is generally metered for the following reasons:

An SLA guarantees packets of this class greater 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 that defines a class for a popular games application that generates a high level of traffic.

Class	Priority	Filters	Selectors	Rate	Forwarding?
`games_app`	9	`games_in`	sport 6080
		`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

Class

Priority

Filters

Selectors

Rate

Forwarding?

games_app

games_in

sport 6080

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 DS codepoints to games_app traffic that conforms to its committed rate or is below the peak rate. When games_app traffic exceeds peak rate, the QoS policy indicates that packets from games_app are to be dropped. A list of all AF codepoints is in table Table 6–2.

Assign DS codepoints to the remaining classes in agreement with the priorities that you have assigned to them.

Where to Go From Here

Task	For Information
Plan for flow accounting of certain types of traffic	How to Plan for Flow Accounting
Add more classes to the QoS policy	How to Define the Classes for Your QoS Policy
Add more filters to the QoS policy	How to Define Filters in the QoS Policy
Define a flow-control scheme	How to Plan Flow Control
Define additional forwarding behaviors for flows as they return to the network stream	How to Plan Forwarding Behavior
Create an IPQoS configuration file	How to Begin the IPQoS Configuration File and Define Traffic Classes

How to Plan for Flow Accounting

You use the IPQoS flowacct module to keep track of 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 to use. 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 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 template.

Where to Go From Here?

Task	For Information
Add more classes to the QoS policy	How to Define the Classes for Your QoS Policy
Add more filters to the QoS policy	How to Define Filters in the QoS Policy
Define a flow-control scheme	How to Plan Flow Control
Define forwarding behaviors for flows as they return to the network stream	How to Plan Forwarding Behavior
Plan for additional flow accounting of certain types of traffic	How to Plan for Flow Accounting
Create the IPQoS configuration file	How to Begin the IPQoS Configuration File and Define Traffic Classes