Chapter 2 Planning for an IPQoS-Enabled Network (Tasks)

You can configure IPQoS on any system that runs the Solaris 9, 9/02 operating environment. The IPQoS system then works along with diffserv-aware routers to provide differentiated services and traffic management on an intranet.

This chapter contains planning tasks for adding IPQoS-enabled systems onto a diffserv-aware network. The following topics are covered.

• General IPQoS Configuration Planning (Task Map)

• Planning the Diffserv Network Topology

• Planning the Quality-of-Service Policy

• Introducing the IPQoS Configuration Example

General IPQoS Configuration Planning (Task Map)

Implementing differentiated services, including IPQoS, on a network requires extensive planning. You must consider not only the position and function of each IPQoS-enabled system, but also the systems' relationship to the router on the local network. The following table lists the major planning tasks for implementing IPQoS on your network.

Table 2–1 IPQoS Configuration Planning (Task Map)

Task	Description	For Instructions
1. Plan a diffserv network topology that incorporates IPQoS-enabled systems.	Learn about the various diffserv network topologies and determine the best solution for your site.	Planning the Diffserv Network Topology.
2. Plan the different types of services to be offered by the IPQoS systems.	Organize the types of services that the network provides into service-level agreements.	Planning the Quality-of-Service Policy.
3. Plan the QoS policy for each IPQoS system.	Decide on the classes, metering, and accounting features that are needed to implement each SLA.	Planning the Quality-of-Service Policy.
4. If applicable, plan the policy for the diffserv router.	Decide any scheduling and queuing policies for the diffserv router that is used with the IPQoS systems.	Refer to router documentation for queuing and scheduling policies.

Planning the Diffserv Network Topology

To provide differentiated services for your network, you need at least one IPQoS-enabled system and a diffserv-aware router. You can expand this basic scenario in a variety of ways, as explained in this section.

Hardware Strategies for the Diffserv Network

Typically, customers run IPQoS on servers and server consolidations, such as the Sun Enterprise™ 10000 server. Conversely, you can also run IPQoS on desktop systems such as UltraSPARC systems, depending on the needs of your network. The following list describes possible systems for IPQoS configuration.

• Solaris systems that offer various services, such as Web servers and database servers

• Applications servers that offer email, FTP, or other popular network applications

• Web cache servers or proxy servers

• Network of IPQoS-enabled server farms that are managed by diffserv-aware load balancers

• Firewalls that manage traffic for a single heterogeneous network

• IPQoS systems that are part of a virtual LAN

You might introduce IPQoS systems into a network topology with already functioning diffserv-aware routers. If your router does not currently offer diffserv, consider the diffserv solutions that are offered by Cisco Systems, Juniper Networks, and other router manufacturers. If the local router does not implement diffserv, then the router passes marked packets on to the next hop without evaluating the marks.

IPQoS Network Topologies

This section contains diagrams that illustrate IPQoS strategies for various network needs.

IPQoS on Individual Hosts

The following figure shows a single network of IPQoS-enabled systems.

Figure 2–1 IPQoS Systems on a Network Segment

The network that is shown in the previous figure is but one segment of a corporate intranet. By enabling IPQoS on the application servers and web servers, you can control the rate at which each IPQoS system releases outgoing traffic onto the network stream. If you make the router diffserv-aware, you can further control incoming and outgoing traffic.

The examples in this guide use the IPQoS on an individual host scenario. For the example topology that is used throughout the guide, see Figure 2–4.

IPQoS on a Network of Server Farms

The following figure shows a network with several heterogeneous server farms.

In such a topology, the router is diffserv-aware, and therefore able to queue and rate both incoming and outgoing traffic. The load balancer is also diffserv-aware, and the server farms are IPQoS-enabled. The load balancer can provide additional filtering beyond the router by using selectors such as userID and projectID, which are included in the application data.

Figure 2–2 Network of IPQoS-Enabled Server Farms

This scenario provides flow control and traffic forwarding to manage congestion on the local network. The topology also prevents outgoing traffic from the server farms from overloading other portions of the intranet.

IPQoS on a Firewall

The following figure shows a segment of a corporate network that is secured from other segments by a firewall.

Figure 2–3 Network Protected by an IPQoS-Enabled Firewall

In this scenario, traffic flows into a diffserv-aware router where it is filtered and queued. All incoming traffic that is forwarded by the router then travels into the IPQoS-enabled firewall. In order to use IPQoS, the firewall must not bypass the IP forwarding stack.

The firewall's security policy determines whether incoming traffic is permitted to enter or depart the internal network. The QoS policy controls the service levels for incoming traffic that has passed the firewall. Depending on the QoS policy, outgoing traffic can also be marked with a forwarding behavior.

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.

1. Review your network topology and plan a strategy that uses IPQoS systems and diffserv routers.

   For topology examples, see Planning the Diffserv Network Topology.

2. Identify the hosts in the topology that require IPQoS or that might become good candidates for IPQoS service.

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

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

1. Create a table for organizing the QoS policy.

   For suggestions, refer to Table 2–2.

2. Perform the remaining steps for every QoS policy that is on your network.

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

4. List the classes you have defined in the organizational table.

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

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

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

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

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.

1. Determine the maximum bandwidth for your network.

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

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

   ---

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

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

   Add the module name to the meter column in your organizational table.

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

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

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

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

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

   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.

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

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

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

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

Introducing the IPQoS Configuration Example

Tasks in the remaining chapters of the guide use the example IPQoS configuration that is introduced in this section. The example shows the differentiated services solution that is implemented on the public intranet of a fictitious service provider, which is called BigISP. BigISP offers services to two types of users: large companies that reach BigISP through leased lines, and individuals who dial in from modems to BigISP.

Example—IPQoS Topology

The following figure shows the network topology that is used for BigISP's public intranet.

Figure 2–4 IPQoS Example Topology

BigISP has implemented four tiers in its public intranet, as shown in the previous figure.

• Tier 0 – Network 10.10.0.0 includes a large diffserv router that is called Bigrouter, which has both external and internal interfaces. Several companies, including a large organization called Goldco, have rented leased-line services that terminate at Bigrouter. Tier 0 also handles individual customers who call over telephone lines or ISDN.

• Tier 1 – Network 10.11.0.0 provides web services. The Goldweb server hosts the web site which was purchased by Goldco as part of the premium service that it has purchased from BigISP. The server Userweb hosts small web sites that were purchased by individual customers. Both Goldweb and Userweb are IPQoS enabled.

• Tier 2 – Network 10.12.0.0 provides applications for all customers to use. BigApps, one of the application servers, is IPQoS-enabled. BigApps provides SMTP, News, and FTP services.

• Tier 3 – Network 10.13.0.0 houses large database servers. Access to Tier 3 is controlled by datarouter, a diffserv router.