Quality of Service (QoS) is a family of evolving Internet standards that provides ways to give preferential treatment to certain types of IP traffic. With the proper support for QoS along a route, this can ameliorate the effects of variable queueing delays and congestion that contribute to poor network performance. The operating system provides host support for QoS to classify outbound traffic into distinct classes of service and to announce and establish resource reservations as requested by client applications.
QoS can be used by an institution to deploy and enforce network policies governing the use of network bandwidth. With QoS, a host can:
The QoS support provides the following functions:
The QoS subsystem consists of four components:
Note: This implementation of QoS is based on a set of evolving Internet standards and draft standards currently under development by the Internet Engineering Task Force (IETF) and its various working groups. This technology will become more consistent and well defined as these standardization efforts progress within the IETF. It is also important to note that QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.
The QoS models for the Internet are open standards defined by the IETF. There are two Internet QoS models currently being standardized within the IETF: integrated services and differentiated services. These two Internet QoS models augment the traditional best-effort service model described in RFC 1812.
Integrated Services (IS) is a dynamic resource reservation model for the Internet described in RFC 1633. Hosts use a signaling protocol called Resource ReSerVation Protocol (RSVP) to dynamically request a specific quality of service from the network. QoS parameters are carried in these RSVP messages and each network node along the path installs the parameters to obtain the requested quality of service. These QoS parameters describe one of two currently defined services, guaranteed service and controlled-load service. An important characteristic of IS is that this signaling is done for each traffic flow and reservations are installed at each hop along the route. Although this model is well-suited for meeting the dynamically changing needs of applications, there exist some significant scaling issues that imply it cannot be deployed in a network in which single routers handle many simultaneous flows.
Differentiated Services (DS) removes the per-flow and per-hop scalability issues, replacing them with a simplified mechanism of classifying packets. Rather than a dynamic signaling approach, DS uses bits in the IP type of service (TOS) byte to separate packets into classes. The particular bit pattern in the IP TOS byte is called the DS codepoint and is used by routers to define the quality of service delivered at that particular hop, in much the same way routers do IP forwarding using routing table lookups. The treatment given to a packet with a particular DS codepoint is called a per-hop behavior (PHB) and is administered independently at each network node. When the effects of these individual, independent PHBs are concatenated, this results in an end-to-end service.
Differentiated services is being standardized by an IETF working group, which has defined three PHBs: the Expedited Forwarding (EF) PHB, the Assured Forwarding (AF) PHB group, and the Default (DE) PHB. The EF PHB can be used to implement a low latency, low jitter, low loss, end-to-end service such as a virtual leased line (VLL). AF is a family of PHBs, called a PHB group, that is used to classify packets into various drop precedence levels. The drop precedence assigned to a packet determines the relative importance of a packet within the AF class. It can be used to implement the so-called Olympic service, which consists of three classes: bronze, silver, and gold. The DE PHB is the traditional best-effort service model as standardized in RFC 1812.
The following RFCs and Internet drafts describe the standards on which this
QoS implementation is based.
| RFC 2474 | Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers |
| RFC 2475 | An Architecture for Differentiated Services |
| RFC 1633 | Integrated Services in the Internet Architecture: an Overview |
| RFC 2205 | Resource ReSerVation Protocol (RSVP) |
| RFC 2210 | The Use of RSVP with IETF Integrated Services |
| RFC 2211 | Specification of the Controlled-Load Network Element Service |
| RFC 2212 | Specification of Guaranteed Quality of Service |
| RFC 2215 | General Characterization Parameters for Integrated Service Network Elements |
| draft-ietf-diffserv-framework-01.txt,
October 1998 | A Framework for Differentiated Services |
| draft-ietf-diffserv-rsvp-01.txt,
November 1998 | A Framework for Use of RSVP with DIFF-serv Networks |
| draft-ietf-diffserv-phb-ef-01.txt | An Expedited Forwarding PHB |
| draft-ietf-diffserv-af-04.txt | Assured Forwarding PHB Group |
| draft-rajan-policy-qosschema-00.txt,
October 1998 | Schema for Differentiated Services and Integrated Services in Networks |
| draft-ietf-rap-framework-01.txt,
November 1998 | A Framework for Policy-based Admission Control[25] |
| draft-ietf-rap-rsvp-ext-01.txt,
November 1998 | RSVP Extensions for Policy Control |
Note: QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.
QoS is packaged with bos.net.tcp.server. This fileset must be installed in order to use QoS. To use the RAPI shared library, bos.adt.include must also be installed.
QoS can be started or stopped through SMIT with the smit qos fast path or with the mkqos and rmqos commands.
To disable the QoS subsystem now and on the next system restart:
/usr/sbin/rmqos -B
To enable the QoS subsystem now only:
/usr/sbin/mkqos -N
See the command descriptions for mkqos and rmqos for the startup and removal command flags.
The policyd and rsvpd daemons are configured through the /etc/policyd.conf and /etc/rsvpd.conf configuration files, respectively. These configuration files must be edited to customize the QoS subsystem to the local environment. QoS does not work correctly with the supplied example configurations.
The RSVP agent is required if the host is to support the RSVP protocol. The /etc/rsvpd.conf configuration file is used to configure the RSVP agent. The syntax of the configuration file is described in the sample configuration file installed in /etc/rsvpd.conf.
interface 1.2.3.1
interface 1.2.3.2 disabled
interface 1.2.3.3 disabled
interface 1.2.3.4
{
trafficControl
}
rsvp 1.2.3.1
{
maxFlows 64
}
rsvp 1.2.3.4
{
maxFlows 100
}
The example illustrates a possible RSVP configuration in which the host has 4 interfaces (virtual or physical) given by the 4 IP addresses, 1.2.3.1, 1.2.3.2, 1.2.3.3, and 1.2.3.4.
Interface 1.2.3.1 has been enabled for RSVP. However, traffic control has not been specified and incoming RSVP RESV messages do not cause resource reservation within the TCP subsystem. This interface can support a maximum of 64 simultaneous RSVP sessions.
Interfaces 1.2.3.2 and 1.2.3.3 have been disabled. The RSVP agent cannot use this interface to transmit or receive RSVP messages.
Interface 1.2.3.4 has been enabled for RSVP. In addition, it can install resource reservations into the TCP subsystem in response to an RSVP RESV message. This interface can support up to 100 RSVP sessions.
Any other interfaces present on the host but not mentioned explictly in /etc/rsvpd.conf are disabled.
The policy agent is a required component of the QoS subsystem. The /etc/policyd.conf configuration file is used to configure the policy agent. The syntax of this configuration file is described in the sample configuration file installed in /etc/policyd.conf.
The policy agent can be configured by editing /etc/policyd.conf. Additionally, the following commands are provided to assist in configuring policies:
In the following example, a premium service category is created and used in the tcptraffic policy rule. This service category has a maximum rate of 110000 Kbps, a token bucket depth of 10000 bits, and an outgoing IP TOS value of 11100000 in binary. The tcptraffic policy rule gives this premimum service to all traffic with source IP address given by 1.2.3.6, destination address 1.2.3.3, and destination port in the range 0 to 1024.
ServiceCategories premium
{
PolicyScope DataTraffic
MaxRate 110000
MaxTokenBucket 10000
OutgoingTOS 11100000
}
ServicePolicyRules tcptraffic
{
PolicyScope DataTraffic
ProtocolNumber 6 # tcp
SourceAddressRange 1.2.3.6-1.2.3.6
DestinationAddressRange 1.2.3.3-1.2.3.3
DestinationPortRange 0-1024
ServiceReference premium
}
The following statements set up a default service category and use it to restrict the UDP traffic flowing from interfaces 1.2.3.1 through 1.2.3.4 to IP addresses 1.2.3.6 through 1.2.3.10, port 8000.
ServiceCategories default
{
MaxRate 110000
MaxTokenBucket 10000
OutgoingTOS 00000000
}
ServicePolicyRules udptraffic
{
ProtocolNumber 17 # udp
SourceAddressRange 1.2.3.1-1.2.3.4
DestinationAddressRange 1.2.3.6-1.2.3.10
DestinationPortRange 8000-8000
ServiceReference default
}
The followoing example configuration can be used to download rules from an LDAP server using the distinguished subtree name, to lookup the policies on the LDAP server host.
ReadFromDirectory
{
LDAP_Server 1.2.3.27
Base ou=NetworkPolicies,o=myhost.mydomain.com,c=us
}
The qosstat command may be used to display status information about the installed and active policies in the QoS subsystem. This information may be useful to you in determining where a problem exists if you are troubleshooting your QoS configuration. qosstat can be used to generate the following report.
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Min policied unit (B): 20
Max packet size (B): 1452
Type: IS-CL
Flags: 0x00001001 (POLICE,SHAPE)
Statistics:
Compliant packets: 1423 (440538 bytes)
Conditions:
Source address Dest address Protocol
192.168.127.39:8000 192.168.256.29:35049 tcp (1 connection)
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Outgoing TOS (compliant): 0xc0
Outgoing TOS (non-compliant): 0x00
Flags: 0x00001011 (POLICE,MARK)
Type: DS
Statistics:
Compliant packets: 335172 (20721355 bytes)
Non-compliant packets: 5629 (187719 bytes)
Conditions:
Source address Dest address Protocol
192.168.127.39:80 *:* tcp (1 connection)
192.168.127.40:80 *:* tcp (5 connections)
This section describes the object classes and attributes used by the policy agent to specify policies for quality of service (QoS) on outgoing traffic. The object classes and attributes are defined, followed by guidelines to enable marking, policing, and shaping.
These conventions are used in the explanations that follow
.
p : choose one in the allowed parameter set
B : integer value of a byte (i.e., 0 =< B =< 255)
b : bit string starting with left most bit (e.g., 101 is
equivalent 10100000 in a byte field)
i : integer value
s : a character string
a : IP address format B.B.B.B
(R) : Required parameter
(O) : Optional parameter
This statement specifies parameters for establishing an LDAP session. The ReadFromDirectory statement is used in the /etc/policyd.conf file to establish the LDAP session.
ReadFromDirectory
{
LDAP_Server a # IP address of directory server running LDAP
LDAP_Port i # Port number LDAP server is listening to
Base s # Distinguished Name for LDAP usage
LDAP_SelectedTag s # Tag to match SelectorTag in object classes
}
where
LDAP_Server (R): IP address of LDAP server
LDAP_Port (0): Unique port number, default port is 389
Base (R): Example is o=ibm, c=us where o is your organization and c is country
LDAP_SelectedTag (R): Unique string matching SelectorTag attribute in the object class
This statement specifies the type of service that a flow of IP packets (for example, from a TCP connection or UDP data) should receive end-to-end as they traverse the network. ServiceCategories can be repeated with each having a different name so that they can be referred to later. A ServiceCategories object requires ServicePolicyRules to complete the policy definition.
ServiceCategories s
{
SelectorTag s # Required tag for LDAP Search
MaxRate i # Target rate for traffic in this service class
MaxTokenBucket i # The bucket depth
OutgoingTOS b # TOS value of outbound traffic for this service class
FlowServiceType p # Type of traffic
}
where
s (R) : is the name of this service category
SelectorTag (R) : Required only for LDAP to Search object classes
MaxRate (O) : in Kbps (K bits per second), default is 0
MaxTokenBucket(O) : in Kb, default is system defined maximum
OutgoingTOS (O) : default is 0
FlowServiceType (O): ControlledLoad | Guaranteed, default is ControlledLoad
This statement specifies characteristics of IP packets that are used to match to a corresponding service category. In other words, it defines a set of IP datagrams that should receive a particular service. ServicePolicyRules are associated with ServiceCategories through the ServiceReference attribute. If two rules refer to the same ServiceCategory, each rule is associated with a unique instance of the ServiceCategory.
ServicePolicyRules s
{
SelectorTag s # Required tag for LDAP Search
ProtocolNumber i # Transport protocol id for the policy rule
SourceAddressRange a1-a2
DestinationAddressRange a1-a2
SourcePortRange i1-i2
DestinationPortRange i1-i2
PolicyRulePriority i # Highest value is enforced first
ServiceReference s # Service category name which for this policy rule
}
where
s (R): is the name of this policy rule
SelectorTag (R): required only for LDAP to Search object class
ProtocolNumber (R): default is 0 which causes no match, must explicity specify
SourceAddressRange (O): from a1 to a2 where a2 >= a1, default is 0, any source address
SourcePortRange (O): from i1 to i2 where i2 >= i1, default is 0, any source port
DestinationAddressRange (O): same as SourceAddressRange
DestinationPortRange (O): same as SourcePortRange
PolicyRulePriority (O): Important to specify when ovelapping policies exist
ServiceReference (R): service category this rule uses
The following are guidelines to specify policies for marking, shaping, and/or policing in a DiffServ environment.
OutgoingTOS : Desired Type Of Service
FlowServiceType : ControlledLoad
MaxRate : Take default of 0
OutgoingTOS : Take default of 0
FlowServiceType : Guaranteed
MaxRate : Target rate desired for traffic as a positive integer
OutgoingTOS : Desired Type of Service
FlowServiceType : ControlledLoad
MaxRate : Target rate desired for traffic as a positive integer
OutgoingTOS : Desired Type of Service
FlowServiceType : Guaranteed
MaxRate : Target rate desired for traffic as a positive integer
Note: The type of service set for the out of profile packets is set to zero in the case of policing.
The following is a complete example of the /etc/policyd.conf configuration file.
#loglevel 511 # Verbose logging
######################################################################
#
# Mark rsh traffic on TCP source ports 513 and 514.
ServiceCategories tcp_513_514_svc
{
MaxRate 0 # Mark only
OutgoingTOS 00011100 # binary
FlowServiceType ControlledLoad
}
ServicePolicyRules tcp_513_514_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
SourcePortRange 513-514
DestinationPortRange 0-0 # Any dst port
ServiceReference tcp_513_514_svc
}
#
######################################################################
#
# Shape connected UDP traffic on source port 9000.
ServiceCategories udp_9000_svc
{
MaxRate 8192 # kilobits
MaxTokenBucket 64 # kilobits
FlowServiceType Guaranteed
}
ServicePolicyRules udp_9000_flt
{
ProtocolNumber 17 # UDP
SourceAddressRange 0.0.0.0-0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
SourcePortRange 9000-9000
DestinationPortRange 0-0 # Any dst port
ServiceReference udp_9000_svc
}
#
######################################################################
#
# Mark and police finger traffic on TCP source port 79.
ServiceCategories tcp_79_svc
{
MaxRate 8 # kilobits
MaxTokenBucket 32 # kilobits
OutgoingTOS 00011100 # binary
FlowServiceType ControlledLoad
}
ServicePolicyRules tcp_79_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
SourcePortRange 79-79
DestinationPortRange 0-0 # Any dst port
ServiceReference tcp_79_svc
}
#
######################################################################
#
# Mark and shape ftp-data traffic on TCP source port 20.
ServiceCategories tcp_20_svc
{
MaxRate 81920 # kilobits
MaxTokenBucket 128 # kilobits
OutgoingTOS 00011101 # binary
FlowServiceType Guaranteed
}
ServicePolicyRules tcp_20_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0-0.0.0.0 # Any IP dst addr
SourcePortRange 20-20
DestinationPortRange 0-0 # Any dst port
ServiceReference tcp_20_svc
}
#
######################################################################
#
# LDAP server entry.
#ReadFromDirectory
#{
# LDAP_Server 9.3.33.138 # IP address of LDAP server
# Base o=ibm,c=us # Base distinguished name
# LDAP_SelectedTag myhost # Typically client hostname
#}
#
######################################################################
If the policy daemon is used with the IBM SecureWay Directory LDAP Server, use the following schema as a guide to update /etc/ldapschema/V3.modifiedschema before starting the LDAP server. Refer to the LDAP server documentation for details.
objectClasses {
( ServiceCategories-OID NAME 'ServiceCategories' SUP top MUST
( objectClass $ SelectorTag $ serviceName ) MAY
( description $ FlowServiceType $ MaxRate $ MaxTokenBucket $ OutgoingTos ) )
( ServicePolicyRules-OID NAME 'ServicePolicyRules' SUP top MUST
( objectClass $ PolicyName $ SelectorTag ) MAY
( description $ DestinationAddressRange $ DestinationPortRange $
ProtocolNumber $ ServiceReference $ SourceAddressRange $ SourcePortRange ) )
}
attributeTypes {
( DestinationAddressRange-OID NAME 'DestinationAddressRange' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( DestinationPortRange-OID NAME 'DestinationPortRange' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( FlowServiceType-OID NAME 'FlowServiceType'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( MaxRate-OID NAME 'MaxRate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( MaxTokenBucket-OID NAME 'MaxTokenBucket' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( OutgoingTos-OID NAME 'OutgoingTos' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( PolicyName-OID NAME 'PolicyName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( ProtocolNumber-OID NAME 'ProtocolNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SelectorTag-OID NAME 'SelectorTag' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( ServiceReference-OID NAME 'ServiceReference' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SourceAddressRange-OID NAME 'SourceAddressRange' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
( SourcePortRange-OID NAME 'SourcePortRange' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
}
IBMattributeTypes {
( DestinationAddressRange-OID DBNAME ( 'DestinationAddressRange' 'DestinationAddressRange' ) )
( DestinationPortRange-OID DBNAME ( 'DestinationPortRange' 'DestinationPortRange' ) )
( FlowServiceType-OID DBNAME ( 'FlowServiceType' 'FlowServiceType' ) )
( MaxRate-OID DBNAME ( 'MaxRate' 'MaxRate' ) )
( MaxTokenBucket-OID DBNAME ( 'MaxTokenBucket' 'MaxTokenBucket' ) )
( OutgoingTos-OID DBNAME ( 'OutgoingTos' 'OutgoingTos' ) )
( PolicyName-OID DBNAME ( 'PolicyName' 'PolicyName' ) )
( ProtocolNumber-OID DBNAME ( 'ProtocolNumber' 'ProtocolNumber' ) )
( SelectorTag-OID DBNAME ( 'SelectorTag' 'SelectorTag' ) )
( ServiceReference-OID DBNAME ( 'ServiceReference' 'ServiceReference' ) )
( SourceAddressRange-OID DBNAME ( 'SourceAddressRange' 'SourceAddressRange' ) )
( SourcePortRange-OID DBNAME ( 'SourcePortRange' 'SourcePortRange' ) )
}
ldapSyntaxes {
}
matchingRules {
}
Policies that overlap are installed in the QoS Manager in a nondeterministic ordering. In the case of overlapping policies the PolicyRulePriority attribute of the ServicePolicyRules should be specified to determine the ordering of enforcement of policies. The PolicyRulePriority attribute takes an integer as a parameter and, in the case of overlapping policies, the rule with the highest integer value is enforced.
Only connected UDP sockets are supported for QoS.
The policy and RSVP agents as mutually independent. Thus, care must be taken not to specify a policy that conflicts with, or is covered by, an existing RSVP reservation. In the presence of such conflicts, the system accepts the first policy or reservation while flagging a violation for the others.
For correct operation, the MaxTokenBucket attribute must be set to at least the maximum MTU of all interfaces configured in the system.
Policy modifications are handled by the policy agent by automatically deleting the existing policies and installing the new ones. This may result in a short, temporary window of time during which the corresponding traffic receives default (typically best effort) service.
This release is compatible with evolving Internet Engineering Task Force (IETF) standards for Differentiated (DiffServ) and Integrated Services (IntServ) on the Internet.
The following RFCs describe various components of the IntServ model:
The following RFCs describe various components of the DiffServ model:
The following RFC outlines the current usage of the IP TOS octet:
The following RFCs outline future practices governing usage of the IP TOS octet:
QoS for AIX 5.1 only supports IPv4; IPv6 is not supported.
The policy daemon can be controlled using the system resource controller (SRC). For example, the command:
startsrc -s policyd -a "-i 60"
starts the policy agent with a refresh interval of 60 seconds.
The refresh SRC command is not currently supported.
For important updates to this documentation, consult the README file in /usr/samples/tcpip/qos.