You can configure IPQoS on any system that runs the Solaris OS. The IPQoS system then works 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 QoS Policy Planning (Task Map) Introducing the IPQoS Configuration Example 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 each system's relationship to the router on the local network. The following task map lists the major planning tasks for implementing IPQoS on your network.Task Description For Instructions 1. Plan a Diffserv network topology that incorporates IPQoS-enabled systems. Learn about the various Diffserv network topologies to 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 (SLAs). 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. 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™ 0000 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 an IPQoS configuration:Solaris systems that offer various services, such as web servers and database servers Application 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 local area network (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 illustrates IPQoS strategies for various network needs.The following figure shows a single network of IPQoS-enabled systems.

Topology diagram shows a local network with a Diffserv router, and three IPQoS-enabled systems: FTP server, database server, and a web server.

This network 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. 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 33–4. The following figure shows a network with several heterogeneous server farms.

Topology diagram shows a network with a Diffserv router, an IPQoS-enabled load balancer, and three 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 user ID and project ID. These selectors are included in the application data.This scenario provides flow control and traffic forwarding to manage congestion on the local network. This scenario 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.

Topology diagram shows a network consisting of a Diffserv router, an IPQoS-enabled firewall, a Solaris system, and other hosts.

In this scenario, traffic flows into a Diffserv-aware router where the packets are filtered and queued. All incoming traffic that is forwarded by the router then travels into the IPQoS-enabled firewall. 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 (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. 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.Class Priority Filter Selector Rate Forwarding? Accounting? Class 1 1 Filter 1Filter 3 Selector 1Selector 2 Meter rates, depending on meter type Marker drop precedence Requires flow-accounting statistics Class 1 1 Filter 2 Selector 1Selector 2 N/A N/A N/A Class 2 2 Filter 1 Selector 1Selector 2 Meter rates, depending on meter type Marker drop precedence Requires flow-accounting statistics Class 2 2 Filter 2 Selector 1Selector 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. 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 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. 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. 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.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. 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. 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.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. 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. 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. 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.44daddr 10.100.10.53sport 21direction LOCAL_OUT To define a flow-control scheme, refer to How to Plan Flow Control. To define forwarding behaviors for flows as the flows return to the network stream, refer to How to Plan Forwarding Behavior. To plan for flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting. To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy. To add more filters to the QoS policy, refer to How to Define Filters in 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 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.Not all classes need to be metered. Remember this guideline as you review your list of classes. Determine which filters in each class select traffic that needs flow control. Then, refine your list of classes that require metering.Classes that have more than one filter might require metering for only one filter. Suppose that you define filters for incoming and outgoing traffic of a certain class. You might conclude that only traffic in one direction requires flow control. Choose a meter module for each class to be flow controlled.Add the module name to the meter column in your QoS planning table. Add the rates for each class to be metered to the organizational table.If you use the tokenmt module, you need to define the following rates in bits per second:Committed rate Peak rate If these rates are sufficient to meter a particular class, you can define only the committed rate and the committed burst for tokenmt. If needed, you can also define the following rates:Committed burst Peak burst For a complete definition of tokenmt rates, refer to Configuring tokenmt as a Two-Rate Meter. You can also find more detailed information in the tokenmt(7ipp) man page.If you use the tswtclmt module, you need to define the following rates in bits per second.Committed rate Peak rate You can also define the window size in milliseconds. These rates are defined in tswtclmt Metering Module and in the twstclmt(7ipp) man page. Add traffic conformance outcomes for the metered traffic.The outcomes for both metering modules are green, red, and yellow. Add to your QoS organizational table the traffic conformance outcomes that apply to the rates you define. Outcomes for the meters are fully explained in Meter Module.You need to determine what action should be taken on traffic that conforms, or does not conform, to the committed rate. Often, but not always, this action is to mark the packet header with a per-hop behavior. One acceptable action for green-level traffic could be to continue processing while traffic flows do not exceed the committed rate. Another action could be to drop packets of the class if flows exceed peak rate. 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.5dport imapdirection LOCAL_IN email 8 mail_out saddr10.50.50.5sport imapdirection LOCAL_OUT meter=tokenmtcommitted rate=5000000committed burst =5000000peak rate =10000000peak burst=1000000green precedence=continue processingyellow precedence=mark yellow PHBred precedence=drop To define forwarding behaviors for flows as the packets return to the network stream, refer to How to Plan Forwarding Behavior. To plan for flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting. To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy. To add more filters to the QoS policy, refer to How to Define Filters in the QoS Policy. To define another flow-control scheme, refer to How to Plan Flow Control. To create an IPQoS configuration file, refer to How to Create 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 to the network. You can choose two major forwarding behaviors: prioritize the flows of a class in relationship to other traffic classes or drop the flows entirely. The Diffserv model uses the marker to assign the chosen forwarding behavior to traffic flows. IPQoS offers the following marker modules.dscpmk – Used to mark the DS field of an IP packet with a DSCP dlcosmk – Used to mark the VLAN tag of a datagram with a class-of-service (CoS) value 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. 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. Traffic is generally metered for the following reasons:An SLA guarantees packets of this class greater service or lesser service when the network is heavily used. A class with a lower priority might have a tendency to flood the network. You use the marker with the meter to provide differentiated services and bandwidth management to these classes. For example, the following table shows a portion of a QoS policy. This policy defines a class for a popular games application that generates a high level of traffic.Class Priority Filter Selector Rate Forwarding? games_app 9 games_in sport 6080 N/A N/A games_app 9 games_out dport 6081 meter=tokenmtcommitted rate=5000000committed burst =5000000peak rate =10000000peak burst=15000000green precedence=continue processingyellow precedence=mark yellow PHBred precedence=drop green =AF31yellow=AF42red=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. To plan for flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting. To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy. To add more filters to the QoS policy, refer to How to Define Filters in the QoS Policy. To define a flow-control scheme, refer to How to Plan Flow Control. To define additional forwarding behaviors for flows as the packets return to the network stream, refer to How to Plan Forwarding Behavior. To create an IPQoS configuration file, refer to How to Create the IPQoS Configuration File and Define Traffic Classes. 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. To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy. To add more filters to the QoS policy, refer to How to Define Filters in the QoS Policy. To define a flow-control scheme, refer to How to Plan Flow Control. To define forwarding behaviors for flows as the packets return to the network stream, refer to How to Plan Forwarding Behavior. To plan for additional flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting. To create the IPQoS configuration file, refer to How to Create 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 on the public intranet of BigISP, a fictitious service provider. BigISP offers services to large companies that reach BigISP through leased lines. Individuals who dial in from modems can also buy services from BigISP.The following figure shows the network topology that is used for BigISP's public intranet.

Topology diagram shows two user types, corporate and individual, who access an ISP network that is defined in the next context.

BigISP has implemented these four tiers in its public intranet: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 that is 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 Goldco 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.