Развитие сетей передачи данных влечёт за собой рост объёма передаваемого трафика, что требует модернизации устройств и каналов связи. При обновлении парка сетевого оборудования можно столкнуться с множеством проблем: технических, организационных, финансовых и т.д., поэтому одним из решений является внедрение политики качества обслуживания на существующем парке устройств. Внедрение политики позволит классифицировать сетевой трафик и распределять сетевые ресурсы между классами трафика.
В пакетных сетях передачи данных трафик распространяется от узла-отправителя к узлу-получателю через каналы связи и промежуточные устройства. В общем случае пакет данных обрабатывается каждым из промежуточных устройств независимо. Рассмотрим пример обработки пакета данных промежуточным сетевым устройством (рис. 1):
Следует отметить, что в большинстве современных сетевых устройств интерфейсы являются комбинированными и могут выступать как в роли входящих, так и в роли исходящих.
Рисунок 1 - Схема прохождения трафика через сетевое устройство |
Сетевое устройство может быть промежуточным для нескольких пар узлов, каждая из которых может передавать данные нескольких сервисов (рис. 2а). Рассмотрим схему, в которой сетевое устройство является промежуточным для трафика пар узлов Узел-1 - Узел-4, Узел-2 - Узел-5 и Узел-3 - Узел-6, при этом первая пара передаёт данные трёх сервисов, вторая - двух, третья - одного. В общем случае, при отсутствии настроек QoS, данные всех сервисов попадают в общую очередь в порядке поступления их на сетевое устройство и в этом же порядке будут из очереди переданы на выходные интерфейсы.
При настроенном QoS, можно классифицировать каждый из входящих потоков трафика, например по его типу, и сопоставить каждому классу свою очередь (рис. 2б). Каждой из очередей пакетов может быть назначен свой приоритет, который будет учитываться при извлечении пакетов из очередей сообщений, что позволит гарантировать показатели качества. Классификация потоков трафика может быть выполнена не на основании используемых сервисов, а по другим критериям. Например, каждой паре пользователей может быть выделена отдельная очередь сообщений (рис. 2в).
Рисунок 2а - Формирование очереди для различных сервисов без QoS Рисунок 2б - Формирование очередей различных сервисов с QoS Рисунок 2в - Формирование очередей различных пользователей с QoS |
Следует иметь в виду, что на пути данных от источника до получателя может быть расположено несколько промежуточных сетевых устройств, очереди сообщений на которых независимы друг от друга, т.е. эффективное внедрение политики QoS потребует конфигурации всех сетевых узлов.
Основываясь на предыдущем разделе, можно сформулировать предпосылки для оценки эффективности передачи данных:
Выделяют три основные метрики качества:
Подробно рассмотрим метрики на примере: Узел-2 передаёт три пакета данных Узлу-5, источник и получателя данных соединяет промежуточное сетевое устройство, пакеты передаются в рамках одного сервиса, т.е. их ключевые служебные поля совпадают.
При передачи потока данных, часть из них могут быть не приняты, либо приняты с ошибками. В этом случае можно говорить о потери данных, которые измеряются как отношение принятых данных к переданным. В примере (рис. 3) Узел-2 передаёт пакеты с идентификаторами 1,2 и 3, однако Узел-5 принимает только пакеты 1 и 3, т.е. пакет с идентификатором 2 потерян. Существуют сетевые механизмы, позволяющие выполнить повторную передачу потерянных данных. Например, к таким механизмам можно отнести протоколы TCP и ARQ.
Причины потерь данных можно выделить в следующие группы:
Рисунок 3 - Пример потери пакета данных |
Одной из основных метрик, используемых на практике, является пропускная способность, величина которой зависит от потерь. Пропускная способность определяется физическими возможностями канала связи и возможностью обработки потока данных промежуточными сетевыми устройствами. Пропускная способность канала связи определяется как максимальный объём данных, который может быть предан от источника к получателю в единицу времени.
Параметром, влияющий на пропускную способность и состояние очередей сообщений является пакетная производительность устройства. Под пакетной производительностью понимается максимальное число пакетов данных заданной длины, которое устройство способно передать в единицу времени.
Пропускная способность, получаемая на практике, зависит как от пакетной производительности, так и от характеристик интерфейса, поэтому на этапе проектирования следует обращать внимание на согласованность этих параметров, чтобы ни одно из них не стало "бутылочным горлышком" канала связи и сетевого сегмента.
Под задержкой понимается время распространения пакета данных от источника до получателя. Величина задержки складывается из следующих компонентов:
При измерениях задержки часто используется понятие круговой задержки (RTT), т.е. времени распространения пакета данных от источника к получателю и обратно. Такое значение, например, используется при выводе результатов команды ping. Состояние промежуточных сетевых устройств при обработке прямого и обратного пакета данных может отличаться, поэтому в общем случае круговая задержка не равна двум односторонним задержкам.
Рисунок 4 - Пример задержки при передачи данных |
Загрузка ЦП и состояние очередей сообщений на промежуточных сетевых устройствах постоянно меняются, поэтому задержка при распространении пакетов данных может изменяться. В примере (рис. 5) время распространения пакетов с идентификаторами 1 и 2 отличаются. Разница между максимальным и средним значениями задержки называется джиттером.
Рисунок 5 - Пример плавающей задержки при передачи данных |
В сетевой инфраструктуре с избыточностью каналов связи данные между источником и получателем могут быть переданы различными путями, что, также, приведёт к появлению джиттера. В частном случае, разница между задержками в каналах связи может оказаться настолько большой, что порядок переданных пакетов данных изменится на приёмной стороне (рис. 6). В примере пакеты с идентификаторами были приняты в разном порядке.
Влияние эффекта зависит от характеристик сервиса и возможностей восстановления исходной последовательности протоколами высших уровней сетевого взаимодействия. Например, если трафик различных сервисов будет передан разными путями, то это не повлияет на неупорядоченность принятых данных.
Рисунок 6 - Пример неупорядоченной доставки данных |
Каждый из сервисов передачи данных имеет набор требований к показателям качества. Документ RFC 4594 предусматривает следующие виды сервисов:
|
Передача трафика различных сервисов реализована на единой сетевой инфраструктуре, которая имеет ограниченные ресурсы, поэтому должны быть должны быть предусмотрены механизмы по распределению ресурсов между сервисами.
Рассмотрим пример (рис. 7), в котором Узел-2 генерирует трафик нескольких сервисов с суммарной скоростью 1 Гбит/с, Среда-2 позволяет передать этот поток данных промежуточному сетевому устройству, однако максимальная пропускная способность канала связи сетевого устройства и Узла-5 равна 500 Мбит/с. Очевидно, что поток данных не может быть обработан полностью и часть этого потока должна быть отфильтрована. Задача QoS сделать эту фильтрацию управляемой, обеспечив конечным сервисам требуемые значения метрик. Разумеется, не получится обеспечить требуемые показатели для всех сервисов, т.к. пропускные способности каналов связи не совпадает, поэтому в рамках реализации политики QoS трафик критичных сервисов должен обрабатываться в первую очередь.
Рисунок 7 - Пример несогласованности объёма входящего трафика и пропускной способности каналов связи |
Рассмотренный пример позволяет сформулировать два основных метода, используемых при реализации политики QoS:
Рассмотрим пример, представленный выше, добавив в схему распространения данных второе промежуточное сетевое устройство (рис. 8а). Схема распространения пакетов описывается следующими этапами:
Каждое из промежуточных сетевых устройств, на котором отсутствуют настройки приоритизации трафика, будет задерживать распространение данных, при этом величина вносимой задержки будет случайной и неконтролируемой. Таким образом, большое число промежуточных устройств сделает невозможным работу сервисов реального времени из-за недостижимости качественных метрик, т.е. настройка приоритизации трафика должна быть выполнена на всём пути распространения трафика в сети (рис. 8б).
Рисунок 8а - Пример распространения данных с частично внедрённой политикой QoS Рисунок 8б - Пример распространения данных с внедрённой политикой QoS |
С точки зрения возможности управления путь распространения трафика в сети может быть описан двумя концепциями (рис. 9а,б):
Рисунок 9а - Пример структуры "белого ящика" Рисунок 9б - Пример структуры "черного ящика" |
Одним из решений описанной проблемы для сетевой структуры "черный ящик" является маркировка заголовков пакетов: приоритет, требуемый для обработки пакета, устанавливается в одном из полей заголовка и сохраняется на протяжении всего пути. В этом случае все промежуточные устройства могут помещать входные данные в очередь сообщений в соответствии со значениями полей, где указан приоритет. Это потребует разработки стандартных протоколов и их реализации производителями оборудования.
Следует отметить, что в общем случае оборудование, находящееся в чужой зоне ответственности, не поддерживает приоритизацию данных в соответствии со значениями приоритета в служебных заголовков. Согласование приоритизации трафика на стыке зон ответственности должно быть выполнено на административном уровне.
Для установки приоритета обслуживания пакета могут использоваться служебные поля различных сетевых протоколов. В рамках данной статьи подробно рассмотрим использование заголовков протоколов Ethernet и IPv4.
Заголовок кадров Ethernet включает в себя служебное поле "User Priority", которое предназначено для приоритизации кадров данных. Поле имеет размер 3 бита, что позволяет выделить 8 классов трафика: 0 класс - наименьший приоритет, 7 класс - наибольший приоритет.
Рисунок 10 - Служебное поле в заголовке Ethernet для приоритизации кадров |
Протокол IP включает в себя три стадии развития служебного поля, отвечающего за приоритизацию пакетов:
Таким образом, приоритизация в IP позволяет выделить 64 класса трафика: 0 - наименьший приоритет, 63 - наивысший приоритет.
Рисунок 11а - Служебное поле ToS в заголовке IP для приоритизации пакетов Рисунок 11б - Служебное поле DSCP в заголовке IP для приоритизации пакетов |
устройства не умеют устанавливать приоритеты
маркировка
перемаркировка
DS-домен
Тип трафика в соответствии с 802.1p
Тип трафика | 802.1p | ToS (Precedence) | DSCP | InfiLINK 2x2, InfiMAN 2x2 | InfiLINK XG, InfiLINK XG 1000 | Vector 5, Vector 70 |
---|---|---|---|---|---|---|
Background (наименьший приоритет) | 00 | 00 | 00 | 16 | 1 | 0 |
Best Effort | 01 | 01 | 08 | - | 1 | |
Excellent Effort | 02 | 02 | 16 | - | 2 | 2 |
Critical Applications | 03 | 03 | 24 | 9 | 3 | |
Video | 04 | 04 | 32 | 7 | 3 | 4 |
Voice | 05 | 05 | 40 | 3 | 5 | |
Internetwork Control | 06 | 06 | 48 | 1 | 4 | 6 |
Network Control (наивысший приоритет) | 07 | 07 | 56 | 0 | 7 |
3. Механизмы приоритизации трафика
Использование приоритета из заголовка Ethernet
Использование приоритета из заголовка IP
Приоритизация трафика в MINT
Описание
Автоматическое распознавание приоритета
Назначение приоритета вручную
Приоритизация трафика в XG
Приоритизация трафика в V5
4. Механизмы ограничения пропускной способности
Предотвращение и управление перегразками
Policing и Shaping
Алгоритм Token Bucket
Ограничение пропускной способности в R5000
Ограничение пропускной способности в XG
Ограничение пропускной способности в V5