Quality of Service (QoS) - это семейство развивающихся стандартов Internet по специальной обработке передаваемых по Internet данных определенного типа. Наличие поддержки QoS вдоль всего маршрута позволяет снизить потери производительности, вызванные различными задержками в очередях и перегрузками. Операционная система предоставляет поддержку QoS для разделения исходящих данных потока на классы обслуживания, а также для объявления о резервировании ресурсов по запросу клиентского приложения.
QoS можно применять в организациях для внедрения и развития стратегий управления пропускной способностью сети. Средства QoS позволяют хосту:
QoS предоставляет следующие функции:
Подсистема QoS состоит из четырех компонентов:
Примечание: Поддержка QoS основана на наборе стандартов и проектов стандартов Internet, разрабатываемых Рабочей группой Internet (IETF) и ее различными подгруппами. По мере развития стандартов эта технология будет становиться более полной и более тщательно определенной. Важно отметить также, что QoS - это сравнительно молодая технология, которая только-только начинает внедряться в Internet. QoS предоставляет разработчику множество преимуществ на всех стадиях разработки. Однако в полной мере эти преимущества можно реализовать только при поддержке QoS на всем отдельно взятом маршруте.
Модели QoS для Internet являются открытыми стандартами, разработанными IETF. В настоящее время IETF приняла два стандарта моделей QoS для Internet: интегрированные службы и дифференцированные службы. Эти две Internet-модели QoS дополняют и улучшают традиционную модель службы, описанную в RFC 1812.
Интегрированные службы (IS) представляют собой динамическую модель резервирования ресурсов для Internet, описанную в RFC 1633. С помощью протокола сигнализации, называемого Протоколом резервирования ресурсов (RSVP), хосты динамически запрашивают конкретный уровень качества обслуживания в сети. Параметры QoS передаются в сообщениях RSVP, так что каждый узел сети вдоль маршрута устанавливает параметры, необходимые для достижения требуемого качества обслуживания. Эти параметры QoS описывают одну или две определенных в настоящее время службы, а именно гарантийную службу и службу управляемой загрузки. Важная особенность интегрированных служб (IS) заключается в том, что сигнализация выполняется для каждого потока данных, а резервы создаются на каждом транзитном участке вдоль маршрута. Хотя эта модель хорошо приспособлена для удовлетворения динамически изменяющихся запросов приложений, по ряду весьма важных соображений она не может быть внедрена в сети, в которой отдельные маршрутизаторы одновременно обрабатывают несколько потоков данных.
В Дифференцированных службах (DS) упразднены инструменты масштабируемости для потока данных и для транзитных участков, а взамен реализован упрощенный механизм классификации пакетов. Для распределения пакетов по классам в DS применяется не динамическая сигнализация, а биты в байте типа обслуживания IP (TOS). Конкретный битовый шаблон байта IP TOS называется кодовым набором DS; с его помощью маршрутизаторы определяют качество обслуживания, предоставляемое на данном конкретном транзитном участке (практически тем же способом маршрутизаторы выполняют пересылку IP с помощью поиска в таблицах маршрутизации). Способ обработки пакета в соответствии с данным кодовым набором DS называется способом обработки на транзитном участке (PHB); этот способ задается отдельно на каждом узле сети. Совокупность всех этих независимых друг от друга PHB обеспечивает обслуживание на всем маршруте.
Рабочая группа IETF, занимающаяся разработкой стандартов для дифференцированных служб, определила три вида PHB: PHB с ускоренной пересылкой (EF), группа PHB с надежной пересылкой (AF) и PHB по умолчанию (DE). PHB EF предназначен для передачи с низким временем ожидания, низкой вероятностью потери данных и высокой защищенностью. Примером может служить виртуальная выделенная линия (VLL). AF представляет собой семейство PHB, называемое группой PHB. PHB этой группы применяются для распределения пакетов по уровням приоритета. Уровень приоритета, присвоенный пакету, определяет относительную важность этого пакета в классе AF. PHB этой группы можно использовать для организации обслуживания типа Olympic, состоящего из трех классов: bronze, silver и gold (т.е. бронзового, серебряного и золотого). PHB DE - это традиционная модель оптимального обслуживания, стандарт которого описан в RFC 1812.
В перечисленных ниже RFC и проектах стандартов Internet описаны стандарты,
на которых основана данная реализация QoS.
| 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 |
Примечание: QoS - это сравнительно молодая технология, которая только-только начинает внедряться в Internet. QoS предоставляет разработчику множество преимуществ на всех стадиях разработки. Однако в полной мере эти преимущества можно реализовать только при поддержке QoS на всем отдельно взятом маршруте.
QoS поставляется в наборе файлов bos.net.tcp.server. Для работы с QoS необходимо установить этот набор файлов. Для работы с общей библиотекой RAPI необходимо также установить набор файлов bos.adt.include.
Запуск и завершение работы QoS можно выполнить из SMIT командой быстрого доступа smit qos или командами mkqos и rmqos.
Для завершения работы подсистемы QoS сейчас и после следующего запуска системы введите команду:
/usr/sbin/rmqos -B
Для запуска подсистемы QoS только сейчас введите команду:
/usr/sbin/mkqos -N
Флаги запуска и завершения работы см. в описаниях команд mkqos и rmqos.
Для настройки демонов policyd и rsvpd применяются файлы конфигурации /etc/policyd.conf и /etc/rsvpd.conf соответственно. Для настройки подсистемы QoS в конкретной локальной среде необходимо отредактировать эти файлы. Если не изменить поставляемую конфигурацию, то QoS не сможет работать правильно.
Агент RSVP необходим, если хост должен поддерживать протокол RSVP. Для настройки агента RSVP служит файл конфигурации /etc/rsvpd.conf, синтаксис которого описан в примере файла конфигурации /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
}
Этот пример иллюстрирует возможную конфигурацию RSVP, в которой для хостов предусмотрено 4 интерфейса (виртуальных или физических), соответствующих четырем IP-адресам: 1.2.3.1, 1.2.3.2, 1.2.3.3 и 1.2.3.4.
Интерфейс 1.2.3.1 подключен для протокола RSVP. Однако управление потоком данных не указано, поэтому подсистема TCP/IP не будет резервировать ресурсы для входящих сообщений RSVP RESV. Этот интерфейс может поддерживать до 64 одновременных сеансов RSVP.
Интерфейсы 1.2.3.2 и 1.2.3.3 отключены. Агент RSVP не может отправлять или принимать сообщения RSVP через эти интерфейсы.
Интерфейс 1.2.3.4 подключен для протокола RSVP. Кроме того, через этот интерфейс можно резервировать ресурсы в подсистеме TCP/IP по запросам сообщений RSVP RESV. Этот интерфейс может поддерживать до 100 сеансов RSVP.
Все остальные интерфейсы, существующие на хосте, но явно не указанные в файле /etc/rsvpd.conf, считаются отключенными.
Агент стратегии - это обязательный компонент подсистемы QoS. Для его настройки служит файл конфигурации /etc/policyd.conf, синтаксис которого описан в примере файла конфигурации, установленном в /etc/policyd.conf.
Конфигурация агента стратегии хранится в файле /etc/policyd.conf. Кроме того, для настройки стратегий предусмотрены следующие команды:
В приведенном ниже примере создается категория службы premium, которая применяется в правиле стратегии tcptraffic. Характеристики этой категории службы следующие: максимальная скорость передачи данных - 110000 Кбит/с, размер стека маркеров - 10000 бит, значение TOS для исходящих пакетов IP - 11100000 в двоичной системе. По правилу стратегии tcptraffic обслуживание класса premimum предоставляется всем данным с IP-адресом отправителя 1.2.3.6, IP-адресом получателя 1.2.3.3 и номером порта получателя в диапазоне от 0 до 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
}
В следующем примере показана настройка категории обслуживания по умолчанию (default). Эта категория будет применяться для ограничения потока данных UDP, поступающих с интерфейсов 1.2.3.1-1.2.3.4 на IP-адреса 1.2.3.6-1.2.3.10, порт 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
}
Пример конфигурации, приведенный ниже, можно применять для загрузки правил с сервера LDAP по отличительному имени поддерева, а также для поиска стратегий на хосте сервера LDAP.
ReadFromDirectory
{
LDAP_Server 1.2.3.27
Base ou=NetworkPolicies,o=myhost.mydomain.com,c=us
}
С помощью команды qosstat можно просмотреть информацию о состоянии установленных и активных стратегий в подсистеме QoS. Эта информация поможет локализовать неполадку при анализе конфигурации QoS. Команда qosstat выдает отчет примерно следующего вида:
Действие:
Быстродействие стека маркеров (бит/с): 10240
Размер стека маркеров (бит): 1024
Пиковое быстродействие (бит/с): 10240
Мин. размер блока для стратегии (бит): 20
Макс. размер пакета (бит): 1452
Тип: IS-CL
Флаги: 0x00001001 (POLICE,SHAPE)
Статистика:
Согласованных пакетов: 1423 (440538 байт)
Параметры:
Адрес отправителя Адрес получателя Протокол
192.168.127.39:8000 192.168.256.29:35049 tcp (1 соединение)
Действие:
Быстродействие стека маркеров (бит/с): 10240
Размер стека маркеров (бит): 1024
Пиковое быстродействие (бит/с): 10240
Исходящий TOS (согласованный): 0xc0
Исходящий TOS (несогласованный): 0x00
Флаги: 0x00001011 (POLICE,MARK)
Тип: DS
Статистика:
Согласованных пакетов: 335172 (20721355 байт)
Несогласованных пакетов: 5629 (187719 байт)
Параметры:
Адрес отправителя Адрес получателя Протокол
192.168.127.39:80 *:* tcp (1 соединение)
192.168.127.40:80 *:* tcp (5 соединений)
В этом разделе описаны классы объектов и атрибуты, применяемые агентом стратегий для описания стратегий QoS отправляемых данных. Приведено описание классов и атрибутов, а также указания по их применению и настройке.
В данном разделе применяются следующие обозначения:
.
p : выберите один из допустимых параметров
B : целое значение размером в один байт (т.е. 0 =< B =< 255)
b : строка битов, начинающаяся с самого левого бита (т.е. 101 - это
10100000 в поле размером в байт)
i : целое значение
s : символьная строка
a : IP-адрес в формате B.B.B.B
(R) : Обязательный параметр
(O) : Необязательный параметр
Этот оператор задает параметры для установления сеанса LDAP. Оператор ReadFromDirectory применяется в файле /etc/policyd.conf для создания сеанса LDAP.
ReadFromDirectory
{
LDAP_Server a # IP-адрес сервера каталогов LDAP
LDAP_Port i # Номер порта на сервере LDAP
Base s # Отличительное имя
LDAP_SelectedTag s # Тег для сравнения с SelectorTag в классе объектов
}
где
LDAP_Server (R): IP-адрес сервера LDAP
LDAP_Port (0): Неповторяющийся номер порта; значение по умолчанию - 389
Base (R): Пример: o=ibm, c=us, где o - организация, а c - страна
LDAP_SelectedTag (R): Неповторяющаяся строка для сравнения с атрибутом SelectorTag в классе объектов
Этот оператор задает тип обслуживания, которое поток IP-пакетов (например, соединение TCP или данные UDP) должен полностью получить из сети. Операторы ServiceCategories могут повторяться с различными именами, позволяющими ссылаться на них в дальнейшем. Для полного определения стратегии кроме объекта ServiceCategories необходим объект ServicePolicyRules.
ServiceCategories s
{
SelectorTag s # Обязательный тег для поиска LDAP
MaxRate i # Целевая скорость потока данных в этом классе
MaxTokenBucket i # Размер набора маркеров
OutgoingTOS b # Значение TOS для исходящего потока данных в этом классе
FlowServiceType p # Тип потока данных
}
где
s (R) : - имя категории обслуживания
SelectorTag (R) : Требуется только для классов поиска LDAP
MaxRate (O) : Кбит в секунду, значение по умолчанию - 0
MaxTokenBucket(O) : Кб, по умолчанию равно системному максимуму
OutgoingTOS (O) : значение по умолчанию - 0
FlowServiceType (O): ControlledLoad | Guaranteed, по умолчанию - ControlledLoad
Этот оператор задает характеристики IP-пакетов, сравниваемых с соответствующей категорией обслуживания. Другими словами, он задает набор IP-дейтаграмм, которые должна обработать конкретная служба. ServicePolicyRules связан с ServiceCategories с помощью атрибута ServiceReference. Если два правила ссылаются на одну категорию ServiceCategory, то каждому правилу присваивается свой экземпляр ServiceCategory.
ServicePolicyRules s
{
SelectorTag s # Обязательный тег для поиска LDAP
ProtocolNumber i # ИД транспортного протокола для правила стратегии
SourceAddressRange a1-a2
DestinationAddressRange a1-a2
SourcePortRange i1-i2
DestinationPortRange i1-i2
PolicyRulePriority i # Первым обрабатывается самое большое значение
ServiceReference s # Имя категории обслуживания для данного правила
}
где
s (R): имя правила стратегии
SelectorTag (R): требуется только для классов поиска LDAP
ProtocolNumber (R): значение по умолчанию (0) нужно указать явно
SourceAddressRange (O): от a1 до a2, где a2 >= a1, по умолчанию - 0, любой исходный адрес
SourcePortRange (O): от i1 до i2, где i2 >= i1, по умолчанию - 0, любой исходный порт
DestinationAddressRange (O): то же, что и SourceAddressRange
DestinationPortRange (O): то же, что и SourcePortRange
PolicyRulePriority (O): Необходим при перекрывающихся стратегиях
ServiceReference (R): категория обслуживания для данного правила
Ниже приведены указания по определению стратегий в среде DiffServ.
OutgoingTOS : Требуемый тип обслуживания
FlowServiceType : ControlledLoad
MaxRate : Значение по умолчанию - 0
OutgoingTOS : Значение по умолчанию - 0
FlowServiceType : Guaranteed
MaxRate : Скорость потока данных, положительное целое
OutgoingTOS : Требуемый тип обслуживания
FlowServiceType : ControlledLoad
MaxRate : Скорость потока данных, положительное целое
OutgoingTOS : Требуемый тип обслуживания
FlowServiceType : Guaranteed
MaxRate : Скорость потока данных, положительное целое
Примечание: В данной стратегии тип обслуживания, заданный для внепрофильных пакетов, равен нулю.
Ниже приведен пример файла конфигурации /etc/policyd.conf.
#loglevel 511 # Подробные сообщения
######################################################################
#
# Маркировать данные rsh на исходных портах TCP 513 и 514.
ServiceCategories tcp_513_514_svc
{
MaxRate 0 # Только маркировать
OutgoingTOS 00011100 # двоичное
FlowServiceType ControlledLoad
}
ServicePolicyRules tcp_513_514_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Любой исходный IP-адрес
DestinationAddressRange 0.0.0.0-0.0.0.0 # Любой целевой IP-адрес
SourcePortRange 513-514
DestinationPortRange 0-0 # Любой целевой порт
ServiceReference tcp_513_514_svc
}
#
######################################################################
#
# Формировать данные UDP на исходном порту 9000.
ServiceCategories udp_9000_svc
{
MaxRate 8192 # килобит
MaxTokenBucket 64 # килобит
FlowServiceType Guaranteed
}
ServicePolicyRules udp_9000_flt
{
ProtocolNumber 17 # UDP
SourceAddressRange 0.0.0.0-0.0.0.0 # Любой исходный IP-адрес
DestinationAddressRange 0.0.0.0-0.0.0.0 # Любой целевой IP-адрес
SourcePortRange 9000-9000
DestinationPortRange 0-0 # Любой целевой порт
ServiceReference udp_9000_svc
}
#
######################################################################
#
# Маркировать и применять стратегию для данных FINGER на порту 79.
ServiceCategories tcp_79_svc
{
MaxRate 8 # килобит
MaxTokenBucket 32 # килобит
OutgoingTOS 00011100 # двоичное
FlowServiceType ControlledLoad
}
ServicePolicyRules tcp_79_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Любой исходный IP-адрес
DestinationAddressRange 0.0.0.0-0.0.0.0 # Любой целевой IP-адрес
SourcePortRange 79-79
DestinationPortRange 0-0 # Любой целевой порт
ServiceReference tcp_79_svc
}
#
######################################################################
#
# Маркировать и формировать данные FTP на исходном порту TCP 20.
ServiceCategories tcp_20_svc
{
MaxRate 81920 # килобит
MaxTokenBucket 128 # килобит
OutgoingTOS 00011101 # двоичное
FlowServiceType Guaranteed
}
ServicePolicyRules tcp_20_flt
{
ProtocolNumber 6 # TCP
SourceAddressRange 0.0.0.0-0.0.0.0 # Любой исходный IP-адрес
DestinationAddressRange 0.0.0.0-0.0.0.0 # Любой целевой IP-адрес
SourcePortRange 20-20
DestinationPortRange 0-0 # Любой целевой порт
ServiceReference tcp_20_svc
}
#
######################################################################
#
# Запись сервера LDAP.
#ReadFromDirectory
#{
# LDAP_Server 9.3.33.138 # IP-адрес сервера
# Base o=ibm,c=us # Основное отличительное имя
# LDAP_SelectedTag myhost # Имя хоста клиента
#}
#
######################################################################
Если демон стратегий применяется вместе с IBM SecureWay Directory LDAP Server, то перед запуском сервера LDAP обновите /etc/ldapschema/V3.modifiedschema следующим образом. Более подробные инструкции приведены в документации по серверу LDAP.
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 {
}
Перекрывающиеся стратегии устанавливаются Администратором QoS в произвольном порядке. Атрибут PolicyRulePriority оператора ServicePolicyRules должен указывать порядок применения перекрывающихся стратегий. Атрибут PolicyRulePriority принимает в качестве параметра целое значение и, в случае перекрывающихся стратегий, применяет правило с наибольшим значением.
QoS поддерживает только подключенные сокеты UDP.
Стратегии и агенты RSVP взаимно независимы. Поэтому не следует указывать стратегии, конфликтующие с резервированием RSVP или покрываемые им. В случае таких конфликтов система применяет первую стратегию или резервирование, а остальные помечает как недопустимые.
Для правильной работы атрибут MaxTokenBucket должен быть не меньше максимального значения MTU для всех интерфейсов, настроенных в системе.
Стратегии автоматически изменяются агентом путем удаления старых стратегий и установки новых. Во время выполнения этой процедуры все клиенты будут получать ответ по умолчанию (оптимальный приоритет).
Эта версия совместима с текущими стандартами Internet Engineering Task Force (IETF) для служб DiffServ и IntServ в Internet.
В следующих RFC описаны различные компоненты модели IntServ:
В следующих RFC описаны различные компоненты модели DiffServ:
В следующем RFC описан текущий формат октета IP TOS:
В следующих RFC описан планируемый в будущем формат октета IP TOS:
QoS для AIX 5.1 поддерживает только IPv4; IPv6 не поддерживается.
Демоном стратегий можно управлять с помощью Контроллера системных ресурсов (SRC). Например, команда:
startsrc -s policyd -a "-i 60"
запускает агент стратегий с интервалом обновления в 60 секунд.
Команда SRC refresh в данный момент не поддерживается.
Самая свежая информация по данному вопросу приведена в файле README в каталоге /usr/samples/tcpip/qos.