|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Administration: IP Services Oracle Solaris 10 1/13 Information Library|
IPQoS includes the following modules, which are part of the Differentiated Services (Diffserv) architecture that is defined in RFC 2475:
IPQoS adds the following enhancements to the Diffserv model:
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 traffic flow consists of a group of packets with identical information in the following IP header fields:
In IPQoS, these fields are referred to as the 5-tuple.
The IPQoS classifier module is named ipgpc. The ipgpc classifier 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 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 address and destination addresses
Source port and destination port
Differentiated Services Codepoint (DSCP)
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 to determine the appropriate outcome. Based on the traffic flow's outcome, the meter selects a subsequent action. Subsequent actions might include sending the packet to another action or returning the packet to the network without further processing.
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's outcome to a green, yellow, or red.
For information on defining parameters for the IPQoS 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 – Marks the DS field in an IP packet header with a numeric value that is called the Differentiated Services codepoint, or DSCP. A Diffserv-aware router can then use the DS codepoint to apply the appropriate forwarding behavior to the packet.
dlcosmk – Marks the virtual local area network (VLAN) tag of an Ethernet frame header with a numeric value that is 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 by the IETF.
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 gather statistics on traffic flows, and bill customers in agreement with their SLAs. Flow accounting is also useful for capacity planning and system monitoring.
Number of packets
Number of bytes
For information on planning a flow-accounting strategy, see How to Plan for Flow Accounting.
Figure 29-1 Traffic Flow Through the IPQoS Implementation of the Diffserv Model
This 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.
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. Then, the meter 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.