2.2 Сервисные модели QoS.

1
Оглавление
Оглавление ................................................................................................... 2
1. Введение ................................................................................................... 3
2. Качество обслуживания (Quality of Service, QoS) .................................... 4
2.1 Параметры QoS....................................... Error! Bookmark not defined.
2.2 Сервисные модели QoS. ........................ Error! Bookmark not defined.
2.3 Дифференциальный вид услуг .............. Error! Bookmark not defined.
2.4. Методы и алгоритмы реализации QoS в разных средахError! Bookmark
not defined.
2.5. Алгоритм NBAR ...................................... Error! Bookmark not defined.
2.6. Стандарт 802.1Q (Virtual Bridged Local Area Network)Error! Bookmark not
defined.
2.7. Приоритеты доступа в LAN.................... Error! Bookmark not defined.
2.8. Рекомендуемое число очередей для разных классов трафика Error!
Bookmark not defined.
3. Вывод ...................................................................................................... 21
4. Список используемой литературы ........................................................ 23
2
1. Введение.
Очевидно, что в ближайшее время сохранится тенденция построения
интегрированных, многосервисных сетей. Как показывает текущее состояние
сети Internet, обработка всего трафика на равных правах приводит к
серьезням проблемам, осбенно при ограниченной пропускной способности.
Так, пересылка важнейших данных может быть временно заблокирована
передачей
большого
файла.
В
этой
связи,
при
создании
сети
с
комбинированными функциями нужно гарантировать необходимый уровень
сервиса для каждого приложения. В противном случае пользователи будут
вынуждены
отказаться
от
многосервисной
сети
в
пользу
старой
специализированной сети.
Больше всего проблем возникает при попытке “собрать” множество
однофункциональных сетей в одну гибкую многосервисную сеть. Еще
трудней получить такую сеть, которая бы смогла разрешить абсолютно все
проблемы. Функции сети могут изменяться, появляться новые. Меняются и
приложения, ориентированные на работу в сети, с собой они приносят новые
требования к сети. Пользовательские рабочие станции сейчас предоставляют
услуги по обработке сообщений, видеоинформации, телефонии и т.д.
Поэтому возникла необходимость гарантировать время реакции, пропускную
способность сети и другие параметры сети. Такая технология была
разработана и получила название качество обслуживания (Quality of
Service, QoS).
3
2. Качество обслуживания (Quality of Service, QoS)
Существует три модели реализации QoS: наилучшая возможная;
интегральная и дифференцированная. Наилучший возможный вид услуг
реализуется в сети, когда делается все возможное для доставки пакета, но
при этом ничего не гарантируется (например FTP или HTTP).
Интегрированный вид услуг (RFC-1633, 1994 год) разрабатывался первым и
реализуется путем резервирования по схеме точка-точка. Протокол RSVP
предоставляет сигнальный механизм для конфигурирования удаленных
маршрутизаторов с целью получения нужного QoS. Протокол ориентирован
на работу с тремя видами трафика: best efforts (обычная передача IP-данных
без установления соединения), чувствительный к скорости передачи и
чувствительный к задержкам. Трафик чувствительный к загрузке требует
формирования канала с гарантированной пропускной способностью.
Приложение при этом вынуждено мириться с определенными задержками
доставки (класс услуг с гарантированной скоростью в битах в сек. Третий
вид трафика (чувствительный к задержкам) гарантирует минимальную
задержку и низкую дисперсию времени доставки. Пропускная способность
может при этом варьироваться. Примером такого вида трафика может
служить передача голоса или видео. RSVP определяет два типа услуг для
этого вида трафика: сервис с контролируемыми задержками и предсказуемый
сервис (для приложений реального времени (видео-конференции и
телефонные переговоры).
2.1 Параметры QoS
QoS – способность сети обеспечить необходимый сервис заданному трафику
в определенных технологических рамках.
Необходимый сервис описывается многими параметрами, отметим среди
них самые важные.
4
Bandwidth (BW) - полоса пропускания, описывает номинальную пропускную
способность среды передачи информации, определяет ширину канала.
Измеряется в bit/s (bps), kbit/s (kbps), mbit/s (mbps).
Delay - задержка при передаче пакета.
Jitter - колебание (вариация) задержки при передаче пакетов.
Packet Loss – потери пакетов. Определяет количество пакетов,
отбрасываемых сетью во время передачи.
Чаще всего для описания пропускной способности канала проводят
аналогию с водопроводной трубой. В ее рамках Bandwidth – это ширина
трубы, а Delay – длина.
Время передачи пакета через канал Transmit time [s] = packet size [bytes] / bw
[bytes/s].
Например, найдем время передачи пакета размером 64 байта по каналу
шириной 64 килобита/c:
Packet size = 64*8=512 (bit) Transmit Time = 512/64000 = 0.008 (c)
2.2 Сервисные модели QoS.
Существует 3 модели QoS:
 Best Effort Service
Негарантированная доставка. Абсолютное отсутствие механизмов
QoS. Используются все доступные ресурсы сети без какого-либо
выделения отдельных классов трафика и регулирования. Считается,
что лучшим механизмом обеспечения QoS является увеличение
пропускной способности. Это в принципе правильно, однако
некоторые виды трафика (например, голосовой) очень чувствительны
к задержкам пакетов и вариации скорости их прохождения. Модель
Best Effort Service даже при наличии больших резервов допускает
5
возникновение перегрузок в случае резких всплесков трафика.
Поэтому были разработаны и другие подходы к обеспечению QoS.
 Integrated Service (IntServ).
Integrated Service (IntServ, RFC 1633) - модель интегрированного
обслуживания. Может обеспечить сквозное (End-to-End) качество
обслуживания, гарантируя необходимую пропускную способность.
IntServ использует для своих целей протокол сигнализации RSVP.
Позволяет приложениям выражать сквозные требования к ресурсам и
содержит механизмы обеспечения данных требований. IntServ можно
кратко охарактеризовать как резервирование ресурсов (Resource
reservation).
 Differentiated Service (DiffServ).
Differentiated Service (DiffServ, RFC 2474/2475) - Модель
дифференцированного обслуживания. Определяет обеспечение QoS
на основе четко определенных компонентов, комбинируемых с
целью предоставления требуемых услуг. Архитектура DiffServ
предполагает наличие классификаторов и формирователей трафика
на границе сети, а также поддержку функции распределения ресурсов
в ядре сети в целях обеспечения требуемой политики пошагового
обслуживания (Per-Hop Behavior - PHB). Разделяет трафик на классы,
вводя несколько уровней QoS. DiffServ состоит из следующих
функциональных блоков: граничные формирователи трафика
(классификация пакетов, маркировка, управление интенсивностью) и
реализаторы PHB политики (распределение ресурсов, политика
отбрасывания пакетов). DiffServ можно кратко охарактеризовать как
приоритезацию трафика (Prioritization).
2.3 Дифференциальный вид услуг
Дифференциальный вид услуг (RFC-2474 и RFC-2475) предполагает наличие
определенного набора средств классификации и механизмов организации
очередей, обеспечивающих работу с приоритетами. Дифференциальный вид
услуг обычно предполагает использование 6-битового поля DSCP (DiffServ
6
Code Point) и определяет по-шаговое поведение вируального канала PHB (Per
Hop Behavior). PHB задается сервис-провайдером и определяется на основе
кода в поле DSCP. Запись в поле DSCP обычно осуществляется на входе
сети. Поле DS (Differentiated Services), где размещается DSCP, фактически
замещает поле TOS (RFC-791) в IP-заголовке. Стандартизации значений поля
DS пока не произведено. Любая сеть должна поддерживать, по крайней мере,
два класса PHB. Express Forwarding PHB (экспрессная переадресация)
относится к наивысшему уровню услуг, возможному в модели Diffserv. Здесь
для обеспечения низких потерь, малого временного разброса и
гарантированной полосы используется RSVP. Diffserv достаточно хорошо
адаптируется для работы в каналах с малой пропускной способностью.
Первой попыткой ввести некоторые параметры качества обслуживания
относятся к 1981 году (RFC-791). Тогда было определено поле IP-заголовка
TOS. Позднее (в 1992 году) определение TOS было скорректировано в RFC1349 (определено 4 бита вместо трех). Из-за неопределенности механизмов
реализации ToS реально это поле не использовалось в течение 20 лет.
Значения бит поля TOS из RFC-1349 описаны в таблице:
0
1
2
34567
Приоритет X X X X 0
Значения поля приоритет определены выше. 4 бита, обозначенные "X",
теоретически допускают 16 значений. Практически из них используется
только 5 кодов
1000 - Минимальная задержка
0100 - Максимальная пропускная способность
0010 - Максимальная надежность
7
0001 - Минимальная стоимость
0000 - Обычные (нормальные) услуги
Diffserv не определяет частоту отбрасывания пакетов, но утверждает, что
класс 4 обрабатывается более приоритетно, чем класс 3 и что в пределах
каждого AF (Assured Forwarding) все классы имеют преимущества перед
прочими классами. В таблице ниже предствлены значения приоритетов для
AF.
Класс 1 Класс 2 Класс 3 Класс 4
Низкий приоритет отбрасыания
001010 010010 011010 100010
Средний приоритет отбрасыания 001100 010100 011100 100100
Высокий приоритет отбрасыания 001110 010111 011110 100110
В рамках diffserv могут использоваться несколько механизмов обработки
очередей, например, WRED (Weighted Random Early Detection).
Зарезервировав на фазе формирования канала в АТМ достаточно большую
пропускную способность, можно минимизировать временной разброс (также
как и в intserv).
2.4. Методы и алгоритмы реализации QoS в разных средах
Компания CISCO разработала специальную технологию для обеспечения
нужного уровня QoS - CISCO Content Networkig (транспортировка через сеть
с учетом содержимого). В рамках этой технологии решается
фундаментальная проблема - классификации транспортируемых пакетов с
учетом содержимого их заголовков. Сетевые технологии стремительно
8
усложняются. Раньше было достаточно определить приоритет для
определенного адреса или для заданного протокола, теперь этого мало. Один
и тот же пользователь с фиксированным IP может в одно и то же воемя
реализовать через сеть передачу голоса, осуществлять поиск информации в
WEB-сети и т.д., причем все это делать в рамках одного и того же протокола.
Понятно, что эти задачи имеют разную значимость. Все это требует
классификации трафика по большему числу параметров, чем адрес и
протокол. Здесь следует учитывать динамическое присвоение кодов номера
порта, которое усложняет распознавание приложений.
CISCO для решения этой проблемы в IP-среде разработала специальное
средство, называемое NBAR (Network Based Application Recognition распознавание приложения по сетевым параметрам). Техника NBAR
применима только к такому трафику, который может быть переадресован с
помощью технологии CEF (Cisco Express Forwarding). CEF предоставляет
следующие преимущества:
 Улучшенная производительность - CEF меньше загружает процессор,
чем быстрое переключение маршрута кэширования. Дополнительные
мощности центрального процессора могут быть отданы для
обеспечения других сервисов, как например качество обслуживания
(QoS) и шифрования данных.
 Масштабируемость - CEF предлагает способность переключения к
любой линии при использовании распределенного CEF режима
(dCEF).
 Упругость - CEF можно переключать трафик более эффективно, чем
типичные спроса кэширования схем.
NBAR может классифицировать HTTP-трафик не только по адресам и
номерам портов, но и по информации, содержащейся в URL (до 400 байт).
Реально NBAR просматривает 512 байт (сюда помимо URL входят заголовки
9
L2, L3, L4 и HTTP). В рамках NBAR предусматривается классификация
субпортов. NBAR классифицирует HTTP-трафик по mime-типу или getзапросам. Предельное число одновременно обслуживаемых URL-ЭВМ или
mime-типов не должно превышать 24. Анализ NBAR 400 байт URL-заголовка
способствует уменьшению вероятности злоупотреблений сетевыми
ресурсами. Здесь появляется возможность выявления неавторизованной
пересылки пользователями больших файлов mp3 и пр.. NBAR может
классифицировать TCP и UDP-протоколы, использующие стандартизованные
номера портов, а также и прочие протоколы (например, маршрутные, ICMP,
IPSec, IPINIP, Kerberos, IMAP/SIMAP, HTTPS, L2TP, LDAP, NETBIOS,
RSVP, SNNTP, NTP, POP3/SPOP3, SFTP, SSH, X-Windows, SOCKS и т.д.).
2.5. Алгоритм NBAR
NBAR позволяет загружать в маршрутизатор шаблоны классификации в
любой момент времени. Это осуществляется с помощью использования
PDLM (Packet Description Language Module - модуль языка описания
пакетов). PDLM копируется в флэш-память с консоли маршрутизатора или
каким-то другим способом. Список поддерживаемых протоколов постоянно
обновляется. Следует помнить, что NBAR сам по себе не обеспечивает QoS,
а лишь выделяет определенный класс трафика из общего информационного
потока. Раз трафик классифицирован, могут быть применены определенные
механизмы для обеспечения определенного уровня сервиса. В перечень таких
услуг входят:

Минимальная гаранитрованная полоса на основе класса,
определенного с помощью WFQ.

Организация очередей с малой задержкой LLQ (Low Latency Queuing)

Формирование политики трафика для ограничения загрузок

Формирование трафика для избежания перегрузок.
10

Исключение перегрузок, используя WRED (Weighted Random Early
Detection)

Пометка пакетов для использования архитектур diffserv или intserv

Реализация WFQ (Flow-based Weighted Fair Queuing)
Использование NBAR для классификации 500 потоков потребует
дополнительно 1 Мбайт памяти. В младших моделях маршрутизаторов,
например 2600, применение NBAR займет до 15% мощности процессора. Это
обстоятельство следует учитывать, если нужно обеспечить определенный
уровень QoS, ведь это потребует дополнительной мощности процессора.
Применение CEF потребует еще больше ресурсов процессора. NBAR не
поддерживает трафик, отличный от IP. NBAR не может таже использоваться
для VLAN, многоканальных PPP (multilink PPP).
В то время как на уровне IP (L3) реализуется несколько подходов
обеспечения QoS на уровне L2 ситуация пока много хуже. Следует, впрочем,
признать, что решение в протоколе MPLS полностью пригодно и для L2.
Требуется лишь появление на рынке сетевых приборов, поддерживающих
MPLS или 802.1Q.
2.6. Стандарт 802.1Q (Virtual Bridged Local Area Network)
В стандарте 802.1Q (Virtual Bridged Local Area Network) определен тип
маркированного кадра путем введения метки, содержащей следующие поля:

TPID (Tagged Protocol Identifier) = 0x8100 (два октета). Этот
идентификатор указывает программе, как следует обрабатывать
остальную часть кадра. По назначению это поля совпадает с полем тип
протокола стандартного кадра Ethernet

Приоритет пользователя (802.1Q; 3 бита).

CFI (Canonical Format Identifier) - 1 бит
11

Идентификатор VLAN (ID) - 12 бит
Введении этих полей в кадр Ethernet приходится пересчитать контрольную
сумму кадра (FCS). Для поддержки стандарта IEEE 802.1р канальный
уровень должен работать с множественными очередями (по одной на каждый
код приоритета). В настоящее время разрабатывается стандарт расширения
RSVP для 802.3 (SBM - Subnet Bandwidth Manager http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-sbm-08.txt). Смотри
также http://www.ietf.org/html.charters/issll-charter.html (Integrated Services over
Specific Lower Layers).
Для управления протоколом SBM используются следующие мультикастадреса:
224.0.0.17 - все SBM-системы должны прослушивать этот адрес.
224.0.0.16 - все кандидаты DSBM должны прослушивать этот адрес. Данная
технология может использоваться, например, в IP-телефонии (TDMoIP - Time
Division Multiplexing over IP). В этом случае UDP-порт порт получателя =
2142
Обычно важно обеспечить качество обслуживания (QoS) в режиме точкаточка. На практике это удается реализовать достаточно редко, в частности
потому, что многие технологии LAN не поддерживают QoS. Ниже в таблице
приведены приоритеты, поддерживаемые известными технологиями LAN. В
локальных сетях различают приоритет доступа (access_priority) и приоритет
пользователя (user_priority). Значение приоритета пользователя формируется
МАС-уровнем, помещается в соответствующее поле заголовка кадра и
используется для обеспечения QoS в режиме точка-точка в среде
переключателей L2. Значение приоритета доступа используется
переключателем LAN для передачи кадров. Приоритет пользователя может
быть не равен приоритету доступа. К сожалению кадры 802.3 и 802.11
12
соответствующих полей приоритета в заголовке не имеют. Значение 0
соответствует наинизшему приоритету. Коды приоритета используются
переключателями при обработке очередей. Применение приоритетов
регламентируется документом IEEE 802.1D (1998).
2.7. Приоритеты доступа в LAN
Таблица 1. Выходной приоритет доступа для разных технологий LAN
Приоритет
пользователя
Выходной приоритет для МАС-технологий
802.3
802.4
802.5
802.6
802.11
802.12
FDDI
0
0
0
0
0
0
0
0
1
0
1
1
1
0
0
1
2
0
2
2
2
0
0
2
3
0
3
3
3
0
0
3
4
0
4
4
4
0
4
4
5
0
5
5
5
0
4
5
6
0
6
6
6
0
4
6
7
0
7
7
7
0
4
6
802.3
CSMA/CD
13
802.4
Token Bus
802.5
Token Ring
802.6
DQDB - Double Queue, Double Bus
802.11
Беспроводные локальные сети
802.12
100VGAnyLAN (с приоритетным запросом)
FDDI
Fiber Distributed Data Interface (token ring)
Параметр Access_priority используется в LAN для управления доступом со
стороны других сетевых устройств (оконечных устройств и прочих
переключателей), когда доступ к среде хотят получить несколько устройств.
Переключатель может быть сконфигурирован так, чтобы можно было
поддеживать несколько очередей. Для определения относительного
приоритета очередей вводится класс трафика, так чтобы кадры с высоким
классом передавались раньше. Кадр низкого класса может быть передан,
если очереди более высокого класса пусты. Документ IEEE 802.1D
определяет соответствие между классами трафика и приоритетами
пользователя.
Ниже перечислены типы трафика, начиная с высоко приоритетного:

Управление сетью (7). Передача данных для поддержания сетевой
инфраструктуры (кадры маршрутных протоколов).
14

Голос (6). Критичен по задержке (< 10мсек) при интерактивных
переговорах.

Видео (5). Критичен по задержке (< 100мсек) при интерактивных видео
обменах.

Контролируемая нагрузка (4). Работа в ситуации некритической по
задержке, но критической по потерям (например, деловой трафик,
поточный трафик с резервированием).

Максимальные усилия (3). Работа в ситуации некритической по
задержке, но критической по потерям, но в условиях с меньшим
приоритетом, чем контролируемая нагрузка. В случае
информационной службы этот режим может использоваться для
привилигированных клиентов.

Наилучшие усилия (2). Это трафик обычный трафик LAN.

Фоновый режим (0, Background). Массовые пересылки данных и
любая другая активность, не влияющая негативно на работу остальных.
Восьмой тип (1) оставлен на будущее, он имеет приоритет выше фонового,
но ниже наилучших усилий. Это означает, что в каждом из выходных портов
формируется до 8 очередей. Ниже в табл. 2 перечислены рекомендуемые
приоритнты пользователя для указанных выше классов трафика.
Таблица 2. Рекомендуемые приоритеты пользователя для существующих
классов трафика
Приоритет
пользователя
Число доступных классов трафика
1
2
3
4
15
5
6
7
8
0
по
0
0
0
1
1
1
1
2
1
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
1
3
0
0
0
1
1
2
2
3
4
0
1
1
2
2
3
3
4
5
0
1
1
2
3
4
4
5
6
0
1
2
3
4
5
5
6
7
0
1
2
3
4
5
6
7
умолчанию
Документ IEEE 802.1D предлагает установить соответствие между
приоритетом пользователя =0 и классом трафика =2. Когда имеется 8 кодов
класса трафика, то приоритету пользователя 1 и 2 ставится в соответствие
код класса трафика 0 и 1, соответственно. В таблице 3 представлено
соответствие классов трафика и числа очередей. Если реализуется только
одна очередь, то все классы трафика реализуются через нее. Если имеется две
очереди (вторая строка таблицы 3), рекомендуется отнести классы с кодами
7, 6, 5 и 4 к высоко приоритетной очереди, а остальные - низко
приоритетной. В нижней строке табл. 3 представлены значения кода
приоритета пользователя.
16
2.8. Рекомендуемое число очередей для разных классов трафика
Таблица 3. Рекомендуемое число очередей для разных классов трафика
Число очередей
Типы трафика
1
BE (EE,BK,Vo,CL,VI,NC)
2
BE(EE,BK)
VO(CL,VI,NC)
3
BE(EE,BK)
CL(VI)
VO(NC)
4
BK
BE(EE)
CL(VI)
VO(NC)
5
BK
BE(EE)
CL
VI
VO(NC)
6
BK
BE
EE
CL
VI
VO(NC)
7
BK
BE
EE
CL
VI
VO
NC
8
BK
-
BE
EE
CL
VI
VO
NC
1
2
0
3
4
5
6
7
Приоритет
пользователя
Надписи полужирным шрифтом относятся к типу трафика, который
определяет типы классов.
BK - Background (фон)
BE - Best Effort (наилучшие усилия)
17
EE - Excelent Effort (максимальные усилия)
CL - Controlled Load (контролируемая нагрузка)
VI - Video (задержка и разброс доставки <100мсек)
VO - Voice (голос, задержка и разброс доставки <10мсек)
NC - Network Control (управление сетью)
Одним из наиболее приемлемых протоколов обеспечения заданного уровня
QoS является MPLS. Этот протокол, предназначенный первоначально для
формирования VPN и ускорения коммутации пакетов, оказался весьма
удобным и для классификации трафика, а также обеспечения требуемого
уровня QoS. Пакеты, входящие в VPN из традиционной сети Интернет,
снабжаются метками в краевых маршрутизаторах LER (Label Edge Router),
именно здесь осуществляется классификация этих пакетов. Метка
представляет собой идентификатор фиксированной длины. В данном
протоколе маршрут пакета определяется метками, а не IP-адресом места
назначения. Полный анализ заголовка пакета выполняется только в краевом
маршрутизаторе LER, последующие маршрутизаторы (или коммутаторы)
рассматривают только метку (это касается и услуг с гарантированным QoS).
Такое решение минимизирует время коммутации по сравнению с IP-сетями.
В современных сетях VPN часто содержат IP (PPP или Ethernet) и АТМ
участки. Соединение сетевых элементов MPLS через АТМ каналы
оказывается наиболее дешево. Обычно это реализуется с помощью
постоянных виртуальных путей PVC ATM. Коммутация в АТМ производится
в этом случае на основе поля VPI. Поле же VPI выполняет функцию метки.
VPI-соединение должно быть заказано с определенным классом АТМсервиса. В АТМ предусмотрены следующие стандартные классы сервиса:
18

CBR - (Constant Bit Rate Service). Этот класс предназначен для передачи
не сжатого голоса и видео при эмуляции канала

VBR-rt - (Variable Bit Rate Real Time). Этот класс предназначен для
поддержки нестационапного (импульсивного) трафика, такого как
сжатый голос и видео.

VBR-nrt - (Variable Bit Rate Non-Real Time). Этот класс может быть
использован для импульсивных приложений, таких как Frame Relay
через АТМ.

AVR - (Available Bit Rate). Этот класс первоначально предназначался для
большинства приложений. Здесь применены механизмы управления
трафиком, кторые управляют перегрузкой. Кроме того, ABR может
гарантировать минимальный поток ячеек, а также обрабатывать
всплески трафика, если это позволяет доступная полоса.

UBR - (Unspecified Bit Rate). Этот класс трафика используется для
приложений с импульсивными потоками данных. Сервис UBR не
гарантирует какого либо качества обслуживания, доставка
осуществляется в режиме "наилучших усилий".
Обычно для приложений MPLS используются классы ATM CBR или VBR.
Выбор определяется расценками сервис-провайдеров, которые могут
варьироваться в широких пределах. Протокол MPLS поддерживает
следующие услуги в сфере QoS:

Классификация пакетов и их пометка. Классификация пакетов
позволяет разделить трафик на несколько потоков с разными
приоритетами или классами обслуживания. IP TOS напрямую
соответствует полю класса обслуживания в MPLS.
19

Исключение перегрузки. Эта услуга реализуется за счет алгоритма
WRED (Weighted Random Early Detection), работающего на уровне
интерфейса и осуществляющего управление буфером.

Управление перегрузкой. Когда сетевой интерфейс оказывается
перегруженным, необходимы средства обслуживания очередей, чтобы
гарантировать определенные для приоритеных приложений по
отношению к неприоритетным.

Кондиционирование трафика. Использование управления трафиком
или политики может определить свойства входящего сетевого трафика.
Такое кондиционирование может при заданной скорости сгладить
поток. Примером такого кондиционирования может служить FRTS
(Frame Relay Traffic Shaping - формирование трафика в Frame Relay), а
примером использования политики может быть САR (Commited Access
Rate - разрешенная скорость доступа).

Управление (Signaling). Протокол резервирования ресурсов RSVP
является основным механизмом реализации управления доступом для
сетевых потоков. RSVP может запросит ресурсы, необходимые для
осуществления обмена некоторым конкретным приложением в
заданной сети.
20
3. Выводы
Будучи уверенным, что сеть жизнеспособна, возникает вопрос а нужно
ли применить к ней QoS? Если нагрузка управляема, и сеть хорошо
разработана, зачем нужна QoS? Разве QoS не последствие хорошего качества
сети? Это означает, не является ли QoS последствием большого количества
ресурсов и хорошо разработанный сети?
Ответ на последние два вопроса - да. QoS всегда лучше, если сеть
жизнеспособна и хорошо разработана. Но можно привести список причин, по
которым стоит применить QoS даже на хорошо разработанной сети.
1.
Нагрузка и потребности любой сети растут очень быстро, всегда
быстрее, чем любой хороший проектировщик сети может оценить. Из-за
этого разработчик должен подвергнуть строгому контролю оригинальные и
новые требования к сети; делая это, разработчик обнаружит что некоторые
оригинальные требования нарушаются почти сразу(например, начальная
оценка потребления полосы пропускания), а просматривая новые требования,
осознает, что, некоторые из них неожиданны, некоторые из них ожидаются,
но никто не оценил, что они могут появиться в ближайшем будущем.
2.
Проблема с вирусами электронной почты и электронные письма
спама, которые размножаются и крадут немалое количество полосы
пропускания,
является
одной
из
таких
неожиданных
потребностей.
Разработчик сети должен принять во внимания пагубные эффекты этой
проблемы и предвидеть дополнительную полосу пропускания.
3.
Большинство ожидаемых потребностей связаны с бурным ростом
использования интернет-услуг пользователями. Загрузка и выгрузка больших
файлов(изображения, видео, музыка, игры и т.д.), частый доступ к
мультимедийным ресурсам, электронные письма с тяжелыми вложениями,
разговоры через VoIP, потоковое видео и др. Очень важно предусмотреть все
эти нагрузки и для этого помимо других технологий, применяется QoS
21
Также очень важно установить политику приоритетов. Не все
4.
требования имеют одинаковую важность. Установление заранее ясная
политика приоритетов является лучшим способом гарантировать хорошее
использование ресурсов сети. Нельзя оставлять случайное распределение
ресурса полосы пропускания сети. Применение политики "best effort"
походит на отсутствие политики вообще. Это похоже на страну, в которой
нет законов.
6. Каждый requeriment, старый или новый, производит поток, и все
потоки не равны. Продолжаясь с параллелизмом страны, некоторые
потоки - хорошие граждане, это означает, они разработаны, чтобы
быть сам управляются и предотвращение скопления как основанные
на протоколе TCP; но некоторый другой - плохие парни, плохо себя
ведет потоки, как основанные на протоколе UDP, и они голодают,
хорошо ведут себя потоки. Потоки UDP и некоторые другие из тех же
самых
особенностей
должны
быть поддержаны
под
строгим
контролем и наблюдением. Также очень важно сказать, что движение
в реальном времени как аудио, видео и мультимедиа, управляет
большинством из них по UDP, ухудшая даже больше вещей, принятых
во внимание, показательные растут использования этого вида
заявлений.
7.
После
классификации
потоков
очень
важно
управлять,
расположить по приоритетам и смоделировать движение сети; этим
путем Вы убедитесь, что золотые пользователи и клиенты,
критические
серверы
и
заявления
получают
количество доступной полосы пропускания.
22
гарантируемое
4. Список используемой литературы
1) http://book.itep.ru/4/44/qos_lan.htm - Качество обслуживание (QoS)
в локальных сетях и не только
2)
http://www.hub.ru/archives/3110
-
Качество
обслуживания
в
современных сетях
3) http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_qos.html - The
Internet Protocol Journal - Volume 3, No. 1. QoS Fact or Fiction
4) http://www.opalsoft.net/qos/WhyQos-10.htm - Why QoS need to be
applied?
23