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.
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. | |
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. | |
3. Plan the QoS policy for each IPQoS system. |
Decide on the classes, metering, and accounting features that are needed to implement each SLA. | |
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. |
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.
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.
This section contains diagrams that illustrate IPQoS strategies for various network needs.
The following figure shows a single network of IPQoS-enabled systems.
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.
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.
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.
The following figure shows a segment of a corporate network that is secured from other segments by a 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.
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.
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. | |
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. | |
3. Define filters for the classes. |
Determine the best ways of separating traffic of a particular class from the network traffic flow. | |
4. Define flow-control rates for measuring traffic as it leaves the IPQoS system. |
Determine acceptable flow rates for each class of traffic. | |
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. | |
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. |
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.
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.
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.
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.
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.
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.
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.
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 |
Task |
For Information |
---|---|
Define a flow-control scheme | |
Define forwarding behaviors for flows as they return to the network stream | |
Plan for flow accounting of certain types of traffic | |
Add more classes to the QoS policy | |
Add more filters to the QoS policy |
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.
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
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 |
---|---|---|---|---|
|
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 |
Task |
For Information |
---|---|
Define forwarding behaviors for flows as they return to the network stream | |
Plan for flow accounting of certain types of traffic | |
Add more classes to the QoS policy | |
Add more filters to the QoS policy | |
Define another flow-control scheme | |
Create an IPQoS configuration file |
How to Begin the IPQoS Configuration File and Define Traffic Classes |
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.
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 |
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.
Task |
For Information |
---|---|
Plan for flow accounting of certain types of traffic | |
Add more classes to the QoS policy | |
Add more filters to the QoS policy | |
Define a flow-control scheme | |
Define additional forwarding behaviors for flows as they return to the network stream | |
Create an IPQoS configuration file |
How to Begin the IPQoS Configuration File and Define Traffic Classes |
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.
Task |
For Information |
---|---|
Add more classes to the QoS policy | |
Add more filters to the QoS policy | |
Define a flow-control scheme | |
Define forwarding behaviors for flows as they return to the network stream | |
Plan for additional flow accounting of certain types of traffic | |
Create the IPQoS configuration file |
How to Begin the IPQoS Configuration File and Define Traffic Classes |
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.
The following figure shows the network topology that is used for BigISP's public intranet.
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.