Существует три модели реализации QoS: наилучшая возможная; интегральная и дифференцированная. Наилучший возможный вид услуг реализуется в сети, когда делается все возможное для доставки пакета, но при этом ничего не гарантируется (например FTP или HTTP). Интегрированный вид услуг (RFC-1633, 1994 год) разрабатывался первым и реализуется путем резервирования по схеме точка-точка (протокол RSVP; 1997; см. book.itep.ru/4/44/rsv_4496.htm). Протокол RSVP предоставляет сигнальный механизм для конфигурирования удаленных маршрутизаторов с целью получения нужного QoS. Протокол ориентирован на работу с тремя видами трафика: best efforts (обычная передача IP-данных без установления соединения), чувствительный к скорости передачи и чувствительный к задержкам.Трафик чувствительный к загрузке требует формирования канала с гарантированной пропускной способностью. Приложение при этом вынуждено мириться с определенными задержками доставки (класс услуг с гарантированной скоростью в битах в сек). Третий вид трафика (чувствительный к задержкам) гарантирует минимальную задержку и низкую дисперсию времени доставки. Пропускная способность может при этом варьироваться. Примером такого вида трафика может служить передача голоса или видео. RSVP определяет два типа услуг для этого вида трафика: сервис с контролируемыми задержками и предсказуемый сервис (для приложений реального времени (видео-конференции и телефонные переговоры).
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
Следует помнить, что в Интернет нет гарантий ни по задержке, ни вообще по доставке, что неприемлемо для передачи голоса ( пропускная способность ≥ 16 кбит/с, максимально допустимая задержка <100мсек), видеоконференций и приложений виртуальной реальности.
Приложение в этой модели не будет осуществлять передачу, пока не получит подтверждения резервирования. Инициатором резервирования в этой модели всегда является получатель. Получатель в рамках RSVP анализирует параметры потока отправителя (Tspec) и посылает ему запрос резервирования Resv, который должны воспринять все промежуточные узлы (если они способны это сделать). Этот запрос специфицирует желательные параметры QoS. Для поддержания резервирования вдоль всего пути это сообщение должно периодически повторяться. В протоколе RSVP всего предусмотрено семь разных типов сообщений. Вообще RSVP превоначально предназначался для организации IP-телефонии. Если с помощью RSVP произведено резервирование всей полосы канала, никакая передача прочих данных через этот канал будет невозможна, пока хотя бы часть резервирований не будет отменена. Характер резервирования определяется спецификацией потока (flow spec). Если запрашивается лишь контроль загрузки, flow spec будет тождественна Tspec. Если же требуется гарантированный вид услуг, flow spec содержит Tspec и Rspec. Надо учитывать, что RSVP не очень удобен при работе с каналами малой пропускной способности. WFQ может начать работать, когда пакеты имеют разный приоритет. Существует 8 уровней приоритета (чем больше номер, тем выше приоритет):
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
- QoS Class 1 (называемый также классом услуг А) имеет те же характеристики, что и выделенный цифровой канал точка-точка
- QoS Class 2 (называемый также классом услуг В) обеспечивает режим, приемлемый для аудио и видео при видеоконференициях или передачи мультимедиа
- QoS Class 3 (называемый также классом услуг 3) обеспечивает режим, приемлемый для передачи, ориентированной на соединение, например, через посредство frame relay.
- QoS Class 4 (называемый также классом услуг 4) эквивалентен режиму IP-передачи в условиях наилучших усилий (best efforts) при отсутствии гарантии доставки.
Следует помнить, что в Интернет нет гарантий ни по задержке, ни вообще по доставке, что неприемлемо для передачи голоса ( пропускная способность ≥ 16 кбит/с, максимально допустимая задержка <100мсек), видеоконференций и приложений виртуальной реальности.
Приложение в этой модели не будет осуществлять передачу, пока не получит подтверждения резервирования. Инициатором резервирования в этой модели всегда является получатель. Получатель в рамках RSVP анализирует параметры потока отправителя (Tspec) и посылает ему запрос резервирования Resv, который должны воспринять все промежуточные узлы (если они способны это сделать). Этот запрос специфицирует желательные параметры QoS. Для поддержания резервирования вдоль всего пути это сообщение должно периодически повторяться. В протоколе RSVP всего предусмотрено семь разных типов сообщений. Вообще RSVP превоначально предназначался для организации IP-телефонии. Если с помощью RSVP произведено резервирование всей полосы канала, никакая передача прочих данных через этот канал будет невозможна, пока хотя бы часть резервирований не будет отменена. Характер резервирования определяется спецификацией потока (flow spec). Если запрашивается лишь контроль загрузки, flow spec будет тождественна Tspec. Если же требуется гарантированный вид услуг, flow spec содержит Tspec и Rspec. Надо учитывать, что RSVP не очень удобен при работе с каналами малой пропускной способности. WFQ может начать работать, когда пакеты имеют разный приоритет. Существует 8 уровней приоритета (чем больше номер, тем выше приоритет):
- Приоритет управления сетью (7)
- Приоритет управления Интернет = межсетевое управление (6)
- Критический приоритет (5)
- Экстренный приоритет (4)
- Немедленный приоритет (2)
- Предпочтительный приоритет (1)
- Ординартный приоритет (0)
Когда установлены соответствующие биты поля TOS, WFQ настраивает обработку так, чтобы очереди с более высоким приоритетом продвигались быстрее, чем менее приоритетные очереди. Порядок обслуживания очередей остается тем же, но объем данных, обрабатываемых из очереди, зависит от веса очереди. Весовой коэффициент обратно пропорционален уровню приоритета. Все это справедливо, если приложение и все участники обмена поддерживают приоритетное обслуживание с использованием TOS. Следует иметь в виду, что методы приоритетного обслуживания используются не только для получения требуемого уровня QoS, но и для подавления перезрузки канала. Смотри также book.itep.ru/4/net_4.htm.
Первой попыткой ввести некоторые параметры качества обслуживания относятся к 1981 году (RFC-791). Тогда было определено поле IP-заголовка TOS (Type of service; значения бит см. в http://book.itep.ru/4/44/ip_441.htm). Позднее (в 1992 году) определение TOS было скорректировано в RFC-1349 (определено 4 бита вместо трех). Из-за неопределенности механизмов реализации ToS реально это поле не использовалось в течение 20 лет. Значения бит поля TOS из RFC-1349 описаны в таблице:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Приоритет | X | X | X | X | 0 | ||
Значения поля приоритет определены выше. 4 бита, обозначенные "X", теоретически допускают 16 значений. Практически из них используется только 5 кодов
1000 - Минимальная задержка
0100 - Максимальная пропускная способность
0010 - Максимальная надежность
0001 - Минимальная стоимость
0000 - Обычные (нормальные) услуги
Diffserv не определяет частоту тбрасывания пакетов, но утверждает, что класс 4 обрабатывается более приоритетно, чем класс 3 и что в пределах каждого AF (Assured Forwarding) все классы имеют преимущества перед прочими классами. В таблице ниже предствлены значения приоритетов для AF.0100 - Максимальная пропускная способность
0010 - Максимальная надежность
0001 - Минимальная стоимость
0000 - Обычные (нормальные) услуги
| Класс 1 | Класс 2 | Класс 3 | Класс 4 | |
| Низкий приоритет отбрасыания | 001010 | 010010 | 011010 | 100010 |
| Средний приоритет отбрасыания | 001100 | 010100 | 011100 | 100100 |
| Высокий приоритет отбрасыания | 001110 | 010111 | 011110 | 100110 |
В рамках diffserv могут использоваться несколько механизмов обработки очередей, например, WRED (Weighted Random Early Detection). Зарезервировав на фазе формирования канала в АТМ достаточно большую пропускную способность, можно минимизировать временной разброс (также как и в intserv).
Компания CISCO разработала специальную технологию для обеспечения нужного уровня QoS - CISCO Content Networkig (транспортировка через сеть с учетом содержимого). В рамках этой технологии решается фундаментальная проблема - классификации транспортируемых пакетов с учетом содержимого их заголовков. Сетевые технологии стремительно усложняются. Раньше было достаточно определить приоритет для определенного адреса или для заданного протокола, теперь этого мало. Один и тот же пользователь с фиксированным IP может в одно и то же воемя реализовать через сеть передачу голоса, осуществлять поиск информации в WEB-сети и т.д., причем все это делать в рамках одного и того же протокола. Понятно, что эти задачи имеют разную значимость. Все это требует классификации трафика по большему числу параметров, чем адрес и протокол. Здесь следует учитывать динамическое присвоение кодов номера порта, которое усложняет распознавание приложений.
CISCO для решения этой проблемы в IP-среде разработала специальное средство, называемое NBAR (Network Based Application Recognition - распознавание приложения по сетевым параметрам). Техника NBAR применима только к такому трафику, который может быть переадресован с помощью технологии CEF (Cisco Express Forwarding). NBAR может классифицировать HTTP-трафик не только по адресам и номерам портов, но и по информации, содержащейся в URL (до 400 байт). Реально NBAR просматривает 512 байт (сюда помимо URL входят заголовки 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 и т.д.).
NBAR позволяет загружать в маршрутизатор шаблоны классификации в любой момент времени. Это осуществляется с помощью использования PDLM (Packet Description Language Module - модуль языка описания пакетов). PDLM копируется в флэш-память с консоли маршрутизатора или каким-то другим способом. Список поддерживаемых протоколов постоянно обновляется. Следует помнить, что NBAR сам по себе не обеспечивает QoS, а лишь выделяет определенный класс трафика из общего информационного потока. Раз трафик классифицирован, могут быть применены определенные механизмы для обеспечения определенного уровня сервиса. В перечень таких услуг входят:
- Минимальная гаранитрованная полоса на основе класса, определенного с помощью WFQ.
- Организация очередей с малой задержкой LLQ (Low Latency Queuing)
- Формирование политики трафика для ограничения загрузок
- Формирование трафика для избежания перегрузок.
- Исключение перегрузок, используя WRED (Weighted Random Early Detection)
- Пометка пакетов для использования архитектур diffserv или intserv
- Реализация WFQ (Flow-based Weighted Fair Queuing)
В то время как на уровне IP (L3) реализуется несколько подходов обеспечения QoS (intserv в RSVP и diffserv в MPLS; см. http://book.itep.ru/4/4/mpls17.htm), на уровне L2 ситуация пока много хуже. Следует, впрочем, признать, что решение в протоколе MPLS полностью пригодно и для L2. Требуется лишь появление на рынке сетевых приборов, поддерживающих MPLS или 802.1Q.
Стандарт 802.1Q (Virtual Bridged Local Area Network)
В стандарте 802.1Q (Virtual Bridged Local Area Network) определен тип маркированного кадра путем введения метки, содержащей следующие поля:
- TPID (Tagged Protocol Identifier) = 0x8100 (два октета). Этот идентификатор указывает программе, как следует обрабатывать остальную часть кадра. По назначению это поля совпадает с полем тип протокола стандартного кадра Ethernet
- Приоритет пользователя (802.1Q; 3 бита). (Смотри http://grouper.ieee.org/groups/802/1/index.html)
- CFI (Canonical Format Identifier) - 1 бит
- Идентификатор VLAN (ID) - 12 бит
Для управления протоколом SBM используются следующие мультикаст-адреса:
224.0.0.17 - все SBM-системы должны прослушивать этот адрес.
224.0.0.16 - все кандидаты DSBM должны прослушивать этот адрес. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP). В этом случае UDP-порт порт получателя = 2142
Обычно важно обеспечить качество обслуживания (QoS) в режиме точка-точка (см.
http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_qos.html). На практике это удается реализовать достаточно редко, в частности потому, что многие технологии LAN не поддерживают QoS. Ниже в таблице приведены приоритеты, поддерживаемые известными технологиями LAN (L2; см. http://www.cisco.com/warp/public/759/ipj_4-1/ipj_4-1_lan.htm). В локальных сетях различают приоритет доступа (access_priority) и приоритет пользователя (user_priority). Значение приоритета пользователя формируется МАС-уровнем, помещается в соответствующее поле заголовка кадра и используется для обеспечения QoS в режиме точка-точка в среде переключателей L2. Значение приоритета доступа используется переключателем LAN для передачи кадров. Приоритет пользователя может быть не равен приоритету доступа. К сожалению кадры 802.3 и 802.11 соответствующих полей приоритета в заголовке не имеют. Значение 0 соответствует наинизшему приоритету. Коды приоритета используются переключателями при обработке очередей. Применение приоритетов регламентируется документом IEEE 802.1D (1998).224.0.0.16 - все кандидаты DSBM должны прослушивать этот адрес. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP). В этом случае UDP-порт порт получателя = 2142
Приоритеты доступа в LAN
Таблица 1. Выходной приоритет доступа для разных технологий LAN
Параметр Access_priority
используется в 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 |
| 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) |
Переключатель может быть сконфигурирован так, чтобы можно было поддеживать несколько очередей. Для определения относительного приоритета очередей вводится класс трафика, так чтобы кадры с высоким классом передавались раньше. Кадр низкого класса может быть передан, если очереди более высокого класса пусты. Документ IEEE 802.1D определяет соответствие между классами трафика и приоритетами пользователя.
Ниже перечислены типы трафика, начиная с высоко приоритетного:
- Управление сетью (7). Передача данных для поддержания сетевой инфраструктуры (кадры маршрутных протоколов).
- Голос (6). Критичен по задержке (< 10мсек) при интерактивных переговорах.
- Видео (5). Критичен по задержке (< 100мсек) при интерактивных видео обменах.
- Контролируемая нагрузка (4). Работа в ситуации некритической по задержке, но критической по потерям (например, деловой трафик, поточный трафик с резервированием).
- Максимальные усилия (3). Работа в ситуации некритической по задержке, но критической по потерям, но в условиях с меньшим приоритетом, чем контролируемая нагрузка. В случае информационной службы этот режим может использоваться для привилигированных клиентов.
- Наилучшие усилия (2). Это трафик обычный трафик LAN.
- Фоновый режим (0, Background). Массовые пересылки данных и любая другая активность, не влияющая негативно на работу остальных.
Таблица 2. Рекомендуемые приоритеты пользователя для существующих классов трафика
Документ IEEE 802.1D предлагает установить соответствие между приоритетом пользователя =0 и классом трафика =2. Когда имеется 8 кодов класса трафика, то приоритету пользователя 1 и 2 ставится в соответствие код класса трафика 0 и 1, соответственно. В таблице 3 представлено соответствие классов трафика и числа очередей. Если реализуется только одна очередь, то все классы трафика реализуются через нее. Если имеется две очереди (вторая строка таблицы 3), рекомендуется отнести классы с кодами 7, 6, 5 и 4 к высоко приоритетной очереди, а остальные - низко приоритетной. В нижней строке табл. 3 представлены значения кода приоритета пользователя.| Приоритет пользователя | Число доступных классов трафика | |||||||
| 1 | 2 | 3 | 4 | 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 |
Рекомендуемое число очередей для разных классов трафика
Таблица 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 (наилучшие усилия) |
| EE | - Excelent Effort (максимальные усилия) |
| CL | - Controlled Load (контролируемая нагрузка) |
| VI | - Video (задержка и разброс доставки <100мсек) |
| VO | - Voice (голос, задержка и разброс доставки <10мсек) |
| NC | - Network Control (управление сетью) |
Одним из наиболее приемлемых, но пока не реализованных в LAN протоколов обеспечения заданного уровня QoS является MPLS. Этот протокол, предназначенный первоначально для формирования VPN и ускорения коммутации пакетов, оказался весьма удобным и для классификации трафика, а также обеспечения требуемого уровня QoS. Пакеты, входящие в VPN из традиционной сети Интернет, снабжаются метками в краевых маршрутизаторах LER (Label Edge Router), именно здесь осуществляется классификация этих пакетов. Метка представляет собой идентификатор фиксированной длины (см. http://book.itep.ru/4/4/mpls17.htm). В данном протоколе маршрут пакета определяется метками, а не IP-адресом места назначения. Полный анализ заголовка пакета выполняется только в краевом маршрутизаторе LER, последующие маршрутизаторы (или коммутаторы) рассматривают только метку (это касается и услуг с гарантированным QoS). Такое решение минимизирует время коммутации по сравнению с IP-сетями.
В современных сетях VPN часто содержат IP (PPP или Ethernet) и АТМ участки. Соединение сетевых элементов MPLS через АТМ каналы оказывается наиболее дешево. Обычно это реализуется с помощью постоянных виртуальных путей PVC ATM. Коммутация в АТМ производится в этом случае на основе поля VPI. Поле же VPI выполняет функцию метки. VPI-соединение должно быть заказано с определенным классом АТМ-сервиса. В АТМ предусмотрены следующие стандартные классы сервиса:
- 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 не гарантирует какого либо качества обслуживания, доставка осуществляется в режиме "наилучших усилий".
- Классификация пакетов и их пометка. Классификация пакетов позволяет разделить трафик на несколько потоков с разными приоритетами или классами обслуживания. IP TOS напрямую соответствует полю класса обслуживания в MPLS.
- Исключение перегрузки. Эта услуга реализуется за счет алгоритма WRED (Weighted Random Early Detection), работающего на уровне интерфейса и осуществляющего управление буфером.
- Управление перегрузкой. Когда сетевой интерфейс оказывается перегруженным, необходимы средства обслуживания очередей, чтобы гарантировать определенные для приоритеных приложений по отношению к неприоритетным.
- Кондиционирование трафика. Использование управления трафиком или политики может определить свойства входящего сетевого трафика. Такое кондиционирование может при заданной скорости сгладить поток. Примером такого кондиционирования может служить FRTS (Frame Relay Traffic Shaping - формирование трафика в Frame Relay), а примером использования политики может быть САR (Commited Access Rate - разрешенная скорость доступа).
- Управление (Signaling). Протокол резервирования ресурсов RSVP является основным механизмом реализации управления доступом для сетевых потоков. RSVP может запросит ресурсы, необходимые для осуществления обмена некоторым конкретным приложением в заданной сети.
Комментариев нет:
Отправить комментарий