The IP quality-of-service (IPQoS) feature enables you to prioritize, control, and gather accounting statistics. Using IPQoS, you can provide consistent levels of service to users of your network, and manage traffic to avoid network congestion.
The following is a list of topics in this chapter:
IPQoS enables the Differentiated Services (diffserv) architecture that is defined by the Differentiated Services Working Group of the Internet Engineering Task Force (IETF). In the Solaris™ 9, 9/02 operating environment, IPQoS is implemented at the IP level of the TCP/IP protocol stack.
By enabling IPQoS, you can provide different levels of network service for selected customers and selected applications. These differentiated services can be based on a structure of service levels that your company offers to its customers. You can also provide differentiated services that are based on the priorities set for applications or users on your network.
Providing quality of service involves the following activities:
Delegating levels of service to different groups, such as customers or departments in an enterprise
Prioritizing network services that are given to particular groups or applications
Discovering and eliminating areas of network bottlenecks and other forms of congestion
Monitoring network performance and providing performance statistics
Regulating bandwidth to and from network resources
IPQoS has the following features:
Command-line tool for configuring the QoS policy
Classifier that selects actions, which are based on filters that configure the QoS policy of your organization
Metering module that measures network traffic, in compliance with the diffserv model
Service differentiation that is based on the ability to mark a packet's IP header with forwarding information
Flow-accounting module that gathers statistics for traffic flows
Statistics gathering for traffic classes, through the UNIX® kstat command
Support for SPARC™ architecture
Support for IPv4 and IPv6 addressing
Interoperability with IPsec
Support for 802.1 D user priority markings for virtual local area networks (VLANs)
You can find information on differentiated services and quality of service from print and online sources.
For more information on quality-of-service theory and practice, refer to the following books:
Ferguson, Paul and Geoff Huston. Quality of Service. John Wiley & Sons, Inc., 1998.
Kilkki, Kalevi. Differentiated Services for the Internet. Macmillan Technical Publishing, 1999.
IPQoS conforms to the specifications that are described in the following RFCs and Internet drafts:
RFC 2474, Definition of the Differentiated Services Field, which describes an enhancement to the ToS or DS fields of the IPv4 and IPv6 packet headers to support differentiated services.
RFC 2475, An Architecture for Differentiated Services, which provides a detailed description of the organization and modules of the diffserv architecture.
RFC 2597, Assured Forwarding PHB Group, which describes how the assured forwarding (AH) per-hop behavior works.
RFC 2598, An Expedited Forwarding PHB, which describes how the expedited forwarding (EF) per-hop behavior works.
Internet-Draft, An Informal Management Model for Diffserv Routers, which presents a model for implementing the diffserv architecture on routers.
The Differentiated Services Working Group of the IETF maintains a Web site with links to diffserv Internet drafts at http://www.ietf.org/html.charters/diffserv-charter.html.
Router manufacturers such as Cisco Systems and Juniper Networks provide information on their corporate Web sites that describes how differentiated services are implemented on their products.
The IPQoS distribution includes the following man pages.
ipqosconf(1m), which is the command for setting up the IPQoS configuration file
ipqos(7ipp), which describes the IPQoS implementation of the diffserv architectural model
ipgpc(7ipp), which describes the IPQoS implementation of a diffserv classifier
tokenmt(7ipp), which describes the IPQoS tokenmt meter module
tswtclmt(7ipp), which describes the IPQoS tswtclmt meter module
dscpmk(7ipp), which describes the DSCP marker module
dlcosmk(7ipp), which describes the IPQoS 802.1D user priority marker module
flowacct(7ipp), which describes the IPQoS flow-accounting module
acctadm(1m), which is the command that configures the Solaris extended accounting facilities and now includes IPQoS extensions
IPQoS features enable Internet service providers (ISPs) and application service providers (ASPs) to offer different levels of network service to customers. These same features enable individual companies and educational institutions to prioritize services for internal organizations or for major applications.
If your organization is an ISP or ASP, you can base your IPQoS configuration on the service-level agreement (SLA) that your company offers to its customers. In an SLA, a service provider guarantees to a customer a certain level of network service that is based on a price structure. For example, a premium-priced SLA might ensure that the customer receives highest priority for all types of network traffic 24 hours per day. Conversely, a medium-priced SLA might guarantee that the customer receives high priority for email only during business hours and medium priority for all other traffic 24 hours a day.
If your organization is an enterprise or an institution, you can also provide quality-of-service features for your network. You can guarantee that traffic from a particular group or from a certain application is assured a higher or lower degree of service.
You implement quality of service by defining a quality-of-service (QoS) policy. The QoS policy defines various network attributes, such as customers' or applications' priorities, and actions for handling different categories of traffic. You implement your organization's QoS policy in an IPQoS configuration file. This file configures the IPQoS modules that reside in the Solaris 9, 9/02 kernel. A host with an applied IPQoS policy is considered an IPQoS-enabled system.
Your QoS policy typically defines the following:
Discrete groups of network traffic that are called classes of service.
Metrics for regulating the amount of network traffic for each class. These metrics govern the traffic-measuring process that is called metering.
Actions that an IPQoS system and a diffserv router must apply to a packet flow. This action is called a per-hop behavior (PHB).
Any statistics gathering that your organization requires for a class of service, for example, traffic that is generated by a customer or particular application.
When packets pass to your network, the IPQoS-enabled system evaluates the packet headers. The action that the IPQoS system takes is determined by your QoS policy.
Tasks for designing the QoS policy are in Planning the Quality-of-Service Policy.
IPQoS contains features that can help you make network performance more efficient as you implement quality of service. When computer networks expand, the need also increases for managing network traffic that is generated by increasing numbers of users and more powerful processors. Some symptoms of an overused network include lost data and traffic congestion that results in slow response times.
In the past, system administrators handled network traffic problems by adding more bandwidth. Often the level of traffic on the links varied widely. With IPQoS, you can manage traffic on the existing network and help assess where, and whether, expansion is necessary.
For example, for an enterprise or institution, you must maintain an efficient network to avoid traffic bottlenecks. You must also assure that a group or application does not consume more than its allotted bandwidth. Moreover, for an ISP or ASP, you must manage network performance to ensure that customers receive the amount of network service for which they have paid.
You can use IPQoS to regulate network bandwidth, the maximum amount of data that a fully used network link or device can transfer. Your QoS policy should prioritize the use of bandwidth to provide quality of service to customers or users. The IPQoS metering modules enable you to measure and control bandwidth allocation among the various traffic classes on an IPQoS-enabled host.
Before you can effectively manage traffic on your network, you must answer these questions about bandwidth usage:
What are the traffic problem areas for your local network?
What must you do to achieve optimum use of available bandwidth?
What are your site's critical applications, which must be given highest priority?
Which applications are sensitive to congestion?
What are your less-critical applications, which can be given a lower priority?
To implement quality of service, you analyze network traffic to determine any broad groupings into which the traffic can be divided. Then you organize the various groupings into classes of service that have individual characteristics and priorities. These classes form the basic categories on which you base the QoS policy for your organization. The classes of service represent the traffic groups that you want to control.
For example, a provider might offer platinum, gold, silver, and bronze levels of service, available at a sliding price structure. A platinum SLA might guarantee top priority to incoming traffic that is destined for a web site that the ISP hosts for the customer. Thus, incoming traffic to the customer's web site could be one traffic class.
For an enterprise, you could create classes of service that are based on department requirements or based on the preponderance of a particular application in the network traffic. Here are a few examples of traffic classes for an enterprise:
Popular applications such as email and outgoing FTP to a particular server, each of which could constitute a class. Because employees constantly use these applications, your QoS policy might guarantee them a small amount of bandwidth and a lower priority.
An order-entry database that needs to run 24 hours a day. Depending on the importance of the database application to the enterprise, you might give the database a large amount of bandwidth and a high priority.
A department that performs critical or sensitive work, such as the payroll department. The importance of the department to the organization would determine the priority and amount of bandwidth you would give to such a department.
Incoming calls to a company's external Web site. You might give this class a moderate amount of bandwidth that runs at low priority.
IPQoS includes the following modules, which are part of the differentiated services (diffserv) architecture that is defined in RFC 2475.
Classifier
Meter
Marker
IPQoS adds the following enhancements to the diffserv model:
Flow-accounting module
802.1D datagram marker
This section introduces the diffserv modules as they are used by IPQoS. You need to know about these modules, their names, and their uses to set up the QoS policy. For detailed information about each module, refer to IPQoS Architecture and the diffserv Model.
In the diffserv model, the classifier selects packets from a network traffic flow—a group of packets with identical information in the following IP header fields.
Source address
Destination address
Source port
Destination port
Protocol number
The IPQoS classifier module is named ipgpc. ipgpc arranges traffic flows into classes that are based on characteristics you configure in the IPQoS configuration file.
For detailed information about ipgpc, refer to Classifier Module.
A class is a group of network flows that share similar characteristics. For example, an ISP might define classes to represent the different service levels that are offered to customers. An ASP might define SLAs that give different levels of service to various applications. For an ASP's QoS policy, a class might include outgoing FTP traffic that is bound for a particular destination IP address. Outgoing traffic from a company's external Web site might also be defined as a class.
Grouping traffic into classes is a major part of planning your QoS policy. When you create classes by using the ipqosconf utility, you are actually configuring the ipgpc classifier.
For information on how to define classes, see How to Define the Classes for Your QoS Policy.
Filters are sets of rules that contain parameters which are called selectors. Each filter must point to a class. IPQoS matches packets against the selectors of each filter to determine if the packet belongs to the filter's class. You can filter on a packet by using a variety of selectors, for example the IPQoS 5–tuple and other common parameters:
Source and destination addresses
Source and destination port numbers
Protocol numbers
User IDs
Project IDs
Differentiated services codepoint (DSCP)
Interface index
For example, a simple filter might include the destination port with the value of 80. The ipgpc classifier then selects all packets that are bound for destination port 80 (HTTP) and handles the packets as directed in the QoS policy.
For information on creating filters, see How to Define Filters in the QoS Policy.
In the diffserv model, the meter tracks the transmission rate of traffic flows on a per-class basis. The meter evaluates how much the actual rate of the flow conforms to the configured rates in order to determine the appropriate outcome. Based on the traffic flow's outcome, the meter selects a subsequent action. Subsequent actions might include to send the packet to another action or to return the packet to the network without further processing.
The IPQoS meters determine whether a network flow conforms to the transmission rate that is defined for its class in the QoS policy. IPQoS includes two metering modules:
Both metering modules recognize three outcomes: red, yellow, and green. You define the actions to be taken for each outcome in the parameters red action_name, yellow action_name, and green action_name.
In addition, you can configure tokenmt to be color aware. A color-aware metering instance uses the packet's size, DSCP, traffic rate, and configured parameters to determine the outcome. The meter uses the DSCP to map the packet to a green, yellow or red outcome.
For information on defining parameters for the meters, refer to How to Plan Flow Control.
In the diffserv model, the marker marks a packet with a value that reflects a forwarding behavior. Marking is the process of placing a value in the packet's header to indicate how to forward the packet to the network. IPQoS contains two marker modules:
dscpmk, which marks the DS field in an IP packet header with a numeric value called the DS codepoint, or DSCP. A diffserv-aware router can then use the DS codepoint to apply the appropriate forwarding behavior to the packet.
dlcosmk, which marks the virtual local area network (VLAN) tag of an Ethernet frame header with a numeric value called the user priority. The user priority indicates the class of service (CoS), which defines the appropriate forwarding behavior to be applied to the datagram.
dlcosmk is an IPQoS addition that is not part of the diffserv model, as designed.
For information on implementing a marker strategy for the QoS policy, see How to Plan Forwarding Behavior.
IPQoS adds the flowacct accounting module to the diffserv model. You can use flowacct to take statistics on traffic flows, and bill customers in agreement with their SLAs. Flow accounting is also useful for capacity planning and system monitoring.
flowacct works with the acctadm command to create an accounting log file. A basic log includes the IPQoS 5–tuple and two additional attributes, as shown in the following list:
Source address
Source port
Destination address
Destination port
Protocol number
Number of packets
Number of bytes
You can also gather statistics on other attributes, as described in Recording Information About Flows and the flowacct(7ipp) and acctadm(1m) man pages.
For information on planning a flow-accounting strategy, see How to Plan for Flow Accounting.
The next figure shows a path that incoming traffic might take as it traverses some of the IPQoS modules.
The figure illustrates a common traffic flow sequence¸ on an IPQoS-enabled machine:
The classifier selects from the packet stream all packets that match the filtering criteria in the system's QoS policy.
The selected packets are then evaluated for the next action to be taken on them.
The classifier sends to the marker any traffic that does not require flow control.
Traffic to be flow-controlled is sent to the meter.
The meter enforces the configured rate and assigns a traffic conformance value to the flow-controlled packets.
The flow-controlled packets are then evaluated to determine if any packets require accounting.
The meter sends to the marker any traffic that does not require flow accounting.
The flow-accounting module gathers statistics on received packets. The module then sends the packets to the marker.
The marker assigns a DS codepoint to the packet header. This DSCP indicates the per-hop behavior that a diffserv-aware system must apply to the packet.
This section introduces the elements that are involved in forwarding packets on an IPQoS-enabled network. An IPQoS-enabled system handles any packets on the network stream with the system's IP address as the destination. The IPQoS system then applies its QoS policy to the packet to establish differentiated services.
The DS codepoint defines in the packet header the action that any diffserv-aware system should take on a marked packet. The diffserv architecture defines a set of DS codepoints and corresponding actions, or forwarding behaviors, for the IPQoS-enabled system and router to use. The IPQoS-enabled system marks the precedence bits of the DS field in the packet header with the DSCP. When a router receives a packet with a DSCP value, the router applies the forwarding behavior associated with that DSCP as the packet is released onto the network.
The dlcosmk meter does not use the DSCP. Rather, dclosmk marks Ethernet frame headers with a CoS value. If you plan to configure IPQoS on a network that uses VLAN devices, refer to Marker Module.
In diffserv terminology, the forwarding behavior that is assigned to a DSCP is called the per-hop behavior (PHB).The PHB defines the forwarding precedence a marked packet receives in relation to other traffic on the diffserv-aware system. This precedence ultimately determines whether the IPQoS-enabled system or diffserv router forwards or drops the marked packet. For a forwarded packet, each diffserv router that the packet encounters en route to its destination applies the same PHB. The exception is if another diffserv system changes the DSCP. For more information on PHBs, refer to Using the dscpmk Marker for Forwarding Packets.
The goal of a PHB is to provide a specified amount of network resources to a class of traffic on the contiguous network. You can achieve this goal in the QoS policy by defining DS codepoints that indicate the precedence levels for traffic classes when they leave the IPQoS-enabled system. Precedences range from high-precedence/low-drop probability to low-precedence/high-drop probability.
For example, your QoS policy can assign to one class of traffic a DSCP that guarantees a low-drop PHB. This traffic class then receives a low-drop precedence PHB from any diffserv-aware router, which guarantees bandwidth to packets of this class. You can add to the QoS policy other DSCPs that assign varying levels of precedence to other traffic classes. The lower-precedence packets are given bandwidth by diffserv systems in agreement with the priorities that are indicated in the packets' DSCPs.
IPQoS supports two types of forwarding behaviors, which are defined in the diffserv architecture, expedited forwarding and assured forwarding.
The expedited forwarding (EF) per-hop behavior assures that any traffic class with EF's related DSCP is given highest priority and is not queued. EF provides low loss, latency, and jitter. The recommended DS codepoint for EF is 101110. A packet that is marked with 101110 receives guaranteed low-drop precedence as the packet traverses diffserv-aware networks en route to its destination. Use the EF DSCP when assigning priority to customers or applications with a premium SLA.
The assured forwarding (AF) per-hop behavior provides four different forwarding classes that you can assign to a packet. Each forwarding class provides three drop precedences, as shown in Table 6–2.
The various AF codepoints provide the ability to assign different levels of services to customers and applications. In the QoS policy you can prioritize traffic and services on your network when you plan the QoS policy. You can then assign different AF levels to the prioritized traffic.
The following figure shows part of an intranet at a company with a partially diffserv-enabled environment. In this scenario, all hosts on networks 10.10.0.0 and 10.14.0.0 are IPQoS-enabled, and the local routers on both networks are diffserv-aware. However, the interim networks are not configured for diffserv.
The next steps trace the flow of the packet that is shown in the previous figure. The steps begin with the progress of a packet that originates at host ipqos1 and continues through several hops to ipqos2.
The user on ipqos1 runs the ftp command to access host ipqos2, three hops away.
ipqos-1 applies its QoS policy to the resulting packet flow and successfully classifies the ftp traffic.
The system administrator has created a class for all outgoing ftp traffic that originates on the local network 10.10.0.0. Traffic for the ftp class is assigned the AF22 per-hop behavior: class two, medium-drop precedence. A traffic flow rate of 2Mbits per second is configured for the ftp class.
ipqos-1 meters the ftp flow to determine if it exceeds the committed rate of 2 Mbits per second.
The marker on ipqos1 marks the DS fields in the outgoing ftp packets with the 010100 DSCP, corresponding to the AF22 PHB.
The router diffrouter1 receives the ftp packets and checks the DSCP. If diffrouter1 is congested, it drops the packets that are marked with AF22.
ftp traffic is forwarded to the next hop in agreement with the per-hop behavior that is configured for AF22 in diffrouter1's files.
The ftp traffic traverses network 10.12.0.0 to genrouter, which is not diffserv-aware. As a result, the traffic receives “best-effort” forwarding behavior.
genrouter passes the ftp traffic to network 10.13.0.0, where the traffic is received by diffrouter2.
diffrouter2 is diffserv-aware. Therefore, the router forwards the ftp packets to the network in agreement with the PHB that is defined in the router policy for AF22 packets.
ipqos2 receives the ftp traffic and prompts the user on ipqos1 for a user name and password.