Сети для самых матёрых. Часть пятнадцатая. QoS18.08.2018 14:17

СДСМ-15. Про QoS.
Теперь с возможностью Pull Request’ов.

И вот мы дошли до темы QoS.
Знаете почему только сейчас и почему это будет закрывающая статья всего курса СДСМ? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.
Это не какой-то магический архиватор, который ловко сожмёт трафик на лету и пропихнёт ваш гигабит в стомегабитный аплинк. QoS это про то как пожертвовать чем-то ненужным, впихивая невпихуемое в рамки дозволенного.
QoS настолько опутан аурой шаманизма и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование, считая, что достаточно закидать проблемы деньгами, и бесконечно расширяя линки. Правда пока они не осознают, что при таком подходе их неизбежно ждёт провал. Или бизнес начнёт задавать неудобные вопросы, или возникнет масса проблем, почти не связанных с шириной канала, зато прямо зависящих от эффективности его использования. Ага, VoIP активно машет ручкой из-за кулис, а мультикастовый трафик ехидно поглаживает вас по спинке.
Поэтому давайте просто осознаем, что QoS это обязательно, познать его придётся так или иначе, и почему-бы не начать сейчас, в спокойной обстановке.

1. Чем определяется QoS?

• Потери
• Задержки
• Джиттер

2. Три модели обеспечения QoS

• Best Effort
• Integrated Services
• Differentiated Services

3. Механизмы DiffServ

4. Классификация и маркировка

• Behavior Aggregate
• Multi-Field
• Interface-Based

5. Очереди

6. Предотвращение перегрузок (Congestion Avoidance)

• Tail Drop и Head Drop
• RED
• WRED

7. Управление перегрузками (Congestion Management)

• First In, First Out
• Priority Queuing
• Fair Queuing
• Round Robin

8. Ограничение скорости

• Shaping
• Policing
• Механизмы Leaky Bucket и Token Bucket

9. Аппаратная реализация QoS

До того как читатель нырнёт в эту нору, я заложу в него три установки:
— Не все проблемы можно решить расширением полосы.
— QoS не расширяет полосу.
— QoS про управление ограниченными ресурсами.

Бизнес ожидает от сетевого стека того, что он будет просто хорошо выполнять свою несложную функцию — доставлять битовый поток от одного хоста до другого: без потерь и за предсказуемое время.

Из этого короткого предложения можно вывести все метрики качества сети:

• Потери
• Задержки
• Джиттер

Эти три характеристики определяют качество сети независимо от её природы: пакетная, канальная, IP, MPLS, радио, голуби.

Потери

Эта метрика говорит о том, сколько из отправленных источником пакетов дошло до адресата.
Причиной потерь может быть проблема в интерфейсе/кабеле, перегрузка сети, битовые ошибки, блокирующие правила ACL.
Что делать в случае потерь решает приложение. Оно может проигнорировать их, как в случае с телефонным разговором, где запоздавший пакет уже не нужен, или перезапросить его отправку — так делает TCP, чтобы гарантировать точную доставку исходных данных.

Как управлять потерями, если они неизбежны, в главе Управление перегрузками.
Как использовать потери во благо в главе Предотвращение перегрузок.

Задержки

Это время, которое необходимо данным, чтобы добраться от источника до получателя.

Совокупная задержка складывается из следующих компонентов.

• Задержка сериализации (Serialization Delay) — время, за которое узел разложит пакет в биты и поместит в линк к следующему узлу. Она определяется скоростью интерфейса. Так, например, передача пакета размером 1500 байтов через интерфейс 100Мб/с займёт 0,0001 с, а на 56 кб/с — 0,2 с.
• Задержка передачи сигнала в среде (Propagation Delay) — результат печально известного ограничения скорости распространения электромагнитных волн. Физика не позволяет добраться из Нью-Йорка до Томска по поверхности планеты быстрее чем за 30 мс (фактически порядка 70 мс).
• Задержки, вносимые QoS — это томление пакетов в очередях (Queuing Delay) и последствия шейпинга (Shaping Delay). Об этом мы сегодня будем говорить много и нудно в главе Управление скоростью.
• Задержка обработки пакетов (Processing Delay) — время на принятие решения, что делать с пакетом: lookup, ACL, NAT, DPI — и доставку его от входного интерфейса до выходного. Но в день, когда Juniper в своём M40 разделил Control и Data Plane, задержкой обработки стало можно пренебречь.

Задержки не так страшны приложениям, где не требуется спешка: обмен файлами, сёрфинг, VoD, интернет-радиостанции итд. И напротив, они критичны для интерактивных: 200 мс уже неприятны на слух при телефонном разговоре.

Связанный с задержкой термин, но не являющийся синонимом — RTT (Round Trip Time) — это путь туда-обратно. При пинге и трассировке вы видите именно RTT, а не одностороннюю задержку, хотя величины и имеют корреляцию.

Джиттер

Разница в задержках между доставкой последовательных пакетов называется джиттером.

Как и задержка, джиттер для многих приложений не имеет значения. И даже, казалось бы, какая разница — пакет доставлен, чего же боле?
Однако для интерактивных сервисов он важен.
Возьмём в качестве примера ту же телефонию. По сути она является оцифровкой аналоговых сигналов с разбиением на отдельные чанки данных. На выходе получается достаточно равномерный поток пакетов. На принимающей стороне есть небольшой буфер фиксированного размера, в который укладываются последовательно поступающие пакеты. Для восстановление аналогового сигнала необходимо определённое их количество. В условиях плавающих задержек следующий чанк данных может не прийти вовремя, что равносильно потере, и сигнал не удаётся восстановить.

Наибольший вклад в вариативность задержки вносит как раз QoS. Об этом тоже много и нудно в тех же главах Ограничение скорости.

Это три основные характеристики качества сети, но есть две другие, которые тоже играют не последнюю роль.

Неупорядоченная доставка

Ряд приложений, таких как телефония, NAS, CES экстремально чувствительны к неупорядоченной доставке пакетов, когда они приходят к получателю не в том порядке, в котором были отправлены. Это может приводить к потере связности, ошибкам, повреждению файловой системы.
И хотя неупорядоченная доставка не является формально характеристикой QoS, но определённо относится к качеству сети.
Даже в случае TCP, толерантного к этому виду проблем, происходят дублирующиеся ACK’и и рентрансмиты.

Полоса пропускания

Её не выделяют, как метрику качества сети, поскольку фактически её недостаток выливается в три указанные выше. Однако в наших реалиях, когда некоторым приложениям она должна быть гарантирована или, наоборот, по договору должна быть ограничена, а например MPLS TE её резервирует на всём протяжении LSP, упомянуть её, хотя бы как слабую метрику, стоит.
Механизмы управления скоростью рассмотрим в главах Ограничение скорости.

Почему характеристики могут портиться?
Итак, начнём мы с очень примитивного представления, что сетевое устройство (будь то коммутатор, маршрутизатор, файрвол, да что угодно) — это просто ещё один кусочек трубы под названием канал связи, такой же, как медный провод или оптический кабель.

Тогда все пакеты пролетают насквозь в том же порядке, в котором они пришли и не испытывают никаких дополнительных задержек — негде задерживаться.

Но на самом деле каждый маршрутизатор восстанавливает из сигнала биты и пакеты, что-то с ними делает (об этом пока не думаем) и потом обратно преобразует пакеты в сигнал.
Появляется задержка сериализации. Но в целом это не страшно поскольку она постоянна. Не страшно до тех пор, пока ширина выходного интерфейса больше, чем входного.

Например, на входе в устройство гигабитный порт, а на выходе радио-релейная линия 620 Мб/с, подключенная в такой же гигабитный порт?
Никто не запретит пулять через формально гигабитный линк гигабит трафика.
Ничего тут не поделаешь — 380 Мб/с будут проливаться на пол.

Вот они — потери.

Но при этом очень бы хотелось, чтобы проливалась худшая его часть — видео с youtube, а телефонный разговор исполнительного директора с директором завода не прерывался и даже не квакал.
Хотелось бы, чтобы у голоса была выделенная линия.

Или входных интерфейсов пять, а выходной один, и одновременно пять узлов начали пытаться влить трафик одному получателю.

Добавим щепотку теории VoIP (статью, про который никто так и не написал) — он весьма чувствителен к задержкам и их вариации.
Если для TCP-потока видео с youtube (на момент написания статьи QUIC — ещё остаётся экспериментом) задержки даже в секунды ровным счётом ничего не стоят благодаря буферизации, то директор после первого же такого разговора с камчаткой призовёт к себе руководителя тех.отдела.
В более старые времена, когда автор цикла ещё делал уроки по вечерам, проблема стояла особенно остро. Модемные соединения имели скорость 56к.
И когда в такое соединение приходил полуторакилобайтный пакет, он оккупировал всю линию на 200 мс. Никто другой в этот момент пройти не мог. Голос? Не, не слышал.
Поэтому таким важным является вопрос MTU — пакет не должен слишком надолго оккупировать интерфейс. Чем менее он скоростной, тем меньший MTU необходим.
Вот они — задержки.
Сейчас канал свободен и задержка низкая, через секунду кто-то начал качать большой файл и задержки выросли. Вот он — джиттер.

Таким образом нужно, чтобы голосовые пакеты пролетали через трубу с минимальными задержками, а youtube подождёт.

Имеющиеся 620 Мб/с нужно использовать и для голоса, и для видео, и для B2B клиентов, покупающих VPN. Хотелось бы, чтобы один трафик не притеснял другой, значит нужна гарантия полосы.

Все вышеуказанные характеристики универсальны относительно природы сети. Однако существует три разных подхода к их обеспечению.

• Best Effort — никакой гарантии качества. Все равны.
• IntServ — гарантия качества для каждого потока. Резервирование ресурсов от источника до получателя.
• DiffServ — нет никакого резервирования. Каждый узел сам определяет, как обеспечить нужное качество.

Best Effort (BE)

Никаких гарантий.

Самый простой подход к реализации QoS, с которого начинались IP-сети и который практикуется и по сей день — иногда потому что его достаточно, но чаще из-за того, что никто и не думал о QoS.

Кстати, когда вы отправляете трафик в Интернет, то он там будет обрабатываться как BestEffort. Поэтому через VPN, прокинутые поверх Интернета (в противовес VPN, предоставляемому провайдером), может не очень уверенно ходить важный трафик, вроде телефонного разговора.

В случае BE — все категории трафика равны, никакому не отдаётся предпочтение. Соответственно, нет гарантий ни задержки/джиттера, ни полосы.
Этот подход носит несколько контринтуитивное название — Best Effort, которое новичка вводит в заблуждение словом «лучший».
Однако фраза «I will do my best» означает, что говорящий постарается сделать всё, что может, но не гарантирует ничего.

Для реализации BE не требуется ничего — это поведение по умолчанию. Это дёшево в производстве, персоналу не нужны глубокие специфические знания, QoS в этом случае не поддаётся никакой настройке.
Однако эта простота и статичность не приводят к тому, что подход Best Effort нигде не используется. Он находит применение в сетях с высокой пропускной способностью и отсутствием перегрузок и всплесков.
Например, на трансконтинентальных линиях или в сетях некоторых ЦОДов, где нет переподписки.
Иными словами в сетях без перегрузок и где нет необходимости особенным образом относиться к какому-либо трафик (например, телефонии), BE вполне уместен.

IntServ

Заблаговременное резервирование ресурсов для потока на всём протяжении от источника до получателя.

В растущий бессистемно Интернет отцы сетей MIT, Xerox, ISI решили добавить элемент предсказуемости, сохранив его работоспособность и гибкость.
Так в 1994 году родилась идея IntServ в ответ на стремительный рост реал-тайм трафика и развитие мультикаста.  Сокращалась она тогда до IS.
Название отражает стремление в одной сети одновременно предоставлять услуги для реал-тайм и не-реал-тайм типов трафика, предоставив, при этом первым приоритетное право использования ресурсов через резервирование полосы. Возможность переиспользования полосы, на которой все и зарабатывают, и благодаря чему IP выстрелил, при этом сохранялась.

Миссию по резервированию возложили на протокол RSVP, который для каждого потока резервирует полосу на каждом сетевом устройстве.
Грубо говоря, до установки A Single Rate Three Color MarkerP сессии или начала обменом данными, конечные хосты отправляют RSVP Path с указанием требуемой полосы. И если обоим вернулся RSVP Resv — они могут начать коммуницировать. При этом, если доступных ресурсов нет, то RSVP возвращает ошибку и хосты не могут общаться или пойдут по BE.

Пусть теперь храбрейшие из читателей представят, что для любого потока в интернете сегодня будет сигнализироваться канал заранее. Учтём, что это требует ненулевых затрат CPU и памяти на каждом транзитном узле, откладывает фактическое взаимодействие на некоторое время, становится понятно, почему IntServ оказался фактически мертворожденной идеей — нулевая масштабируемость.
В некотором смысле современная инкарнация IntServ — это MPLS TE с адаптированной под передачу меток версией RSVP — RSVP TE. Хотя здесь, конечно же не End-to-End и не per-flow.

IntServ описан в RFC 1633.
Документ в принципе любопытен, чтобы оценить, насколько можно быть наивным в прогнозах.

DiffServ

DiffServ сложный.

Когда в конце 90-х стало понятно, что End-to-End подход IntServ в IP провалился, в IETF созвали в 1997 рабочую группу «Differentiated Services», которая выработала следующие требования к новой модели QoS:

• Никакой сигнализации (Адьёс, RSVP!).
• Основан на агрегированной классификации трафика, вместо акцента на потоках, клиентах итд.
• Имеет ограниченный и детерминированный набор действий по обработке трафика данных классов.

В результате в 1998 родились эпохальные RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) и RFC 2475 (An Architecture for Differentiated Services).

И дальше всю дорогу мы будем говорить только о DiffServ.

Стоит обратить внимание, что название DiffServ — это не антитеза IntServ. Оно отражает, что мы дифференцируем сервисы, предоставляемые различным приложениям, а точнее их трафику, иными словами разделяем/дифференцируем эти типы трафика.
IntServ делает то же самое — он различает типы трафика BE и Real-Time, передающиеся на одной сети. Оба: и IntServ и DiffServ — относятся к способам дифференциации сервисов.

Что же собой являет DiffServ и почему он выигрывает у IntServ?
Если очень просто, то трафик делится на классы. Пакет на входе в каждый узел классифицируется и к нему применяется набор инструментов, который по-разному обрабатывает пакеты разных классов, таким образом обеспечивая им разный уровень сервиса.

Но просто не будет.
В основе DiffServ лежит идеологически выдержанная в традициях IP концепция PHB — Per-Hop Behavior. Каждый узел по пути трафика самостоятельно принимает решение о том, как вести себя относительно пришедшего пакета, на основе его заголовков.
Действия маршрутизатора с пакетом назовём моделью поведения (Behavior). Количество таких моделей детерминировано и ограничено. На разных устройствах модели поведения по отношению к одному и тому же трафику могут отличаться, поэтому они и per-hop.
Понятия Behavior и PHB я буду использовать в статье как синонимы.

Тут есть лёгкая путаница. PHB — это с одной стороны общая концепция независимого поведения каждого узла, с другой — конкретная модель на конкретном узле. С этим мы ещё разберёмся.

Модель поведения определяется набором инструментов и их параметров: Policing, Dropping, Queuing, Scheduling, Shaping.

Используя имеющиеся модели поведения, сеть может предоставлять различные классы сервиса (Class of Service).
То есть разные категории трафика могут получить разный уровень сервиса в сети путём применения к ним разных PHB.

Соответственно прежде всего нужно определить к какому классу сервиса относится трафик — классификация (Classification).
Каждый узел самостоятельно классифицирует поступающие пакеты.

После классификации происходит измерение (Metering) — сколько битов/байтов трафика данного класса пришло на маршрутизатор.
На основе результатов пакеты могут окрашиваться (Coloring): зелёный (в рамках установленного лимита), жёлтый (вне лимита), красный (совсем берега попутал).

Если необходимо, далее происходит полисинг (Policing) (уж простите за такую кальку, есть вариант лучше — пишите, я поменяю). Полисер на основе цвета пакета назначает действие по отношению к пакету — передать, отбросить или перемаркировать.

После этого пакет должен попасть в одну из очередей (Queuing). Для каждого класса сервиса выделена отдельная очередь, что и позволяет их дифференцировать, применяя разные PHB.
Но ещё до того, как пакет попадёт в очередь, он может быть отброшен (Dropper), если очередь заполнена.

Если он зелёный, то он пройдёт, если жёлтый, то его вполне вероятно, отбросят, если очередь полна, а если красный — это верный смертник. Условно, вероятность отбрасывания зависит от цвета пакета и наполненности очереди, куда он собирается попасть.

На выходе из очереди работает шейпер (Shaper), задача которого очень похожа на задачу полисера — ограничить трафик до заданного значения.
Можно настроить произвольные шейперы для отдельных очередей или даже внутри очередей.
Об отличии шейпера от полисера в главе Ограничение скорости.

Все очереди в итоге должны слиться в единый выходной интерфейс.
Вспомните ситуацию, когда на дороге 8 полос сливаются в 3. Без регулировщика это превращается в хаос. Разделение по очередям не имело бы смысла, если бы на выходе мы имели то же, что на входе.
Поэтому есть специальный диспетчер (Scheduler), который циклически вынимает пакеты из разных очередей и отправляет в интерфейс (Scheduling).
На самом деле связка набора очередей и диспетчера — самый главный механизм QoS, который позволяет применять разные правила к разным классам трафика, одним обеспечивая широкую полосу, другим низкие задержки, третьим отсутствие дропов.

Далее пакеты уже выходят на интерфейс, где происходит преобразование пакетов в поток битов — сериализация (Serialization) и далее сигнал среды.

В DiffServ поведение каждого узла независимо от остальных, нет протоколов сигнализации, которые бы сообщили, какая на сети политика QoS. При этом в пределах сети хотелось бы, чтобы трафик обрабатывался одинаково. Если всего лишь один узел будет вести себя иначе, вся политика QoS псу под хвост.
Для этого, во-первых, на всех маршрутизаторах, настраиваются одинаковые классы и PHB для них, а во-вторых, используется маркировка (Marking) пакета — его принадлежность определённому классу записывается в заголовок (IP, MPLS, 802.1q).
И красота DiffServ в том, что следующий узел может довериться этой маркировке при классификации.

Такая зона доверия, в которой действуют одинаковые правила классификации трафика и одни модели поведения, называется домен DiffServ (DiffServ-Domain).

Таким образом на входе в домен DiffServ мы можем классифицировать пакет на основе 5-Tuple или интерфейса, промаркировать (Remark/Rewrite) его согласно правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
То есть явной сигнализации в DiffServ нет, но узел может сообщить всем следующим, какой класс нужно обеспечить этому пакету, ожидая, что тот доверится.

На стыках между DiffServ-доменами нужно согласовывать политики QoS (или не нужно).

Целиком картина будет выглядеть примерно так:

Чтобы было понятно, приведу аналог из реальной жизни.
Перелёт на самолёте (не Победой).
Есть три класса сервиса (CoS): Эконом, Бизнес, Первый.
При покупке билета происходит классификация (Classification) — пассажир получает определённый класс сервиса на основе цены.
В аэропорту происходит маркировка (Remark) — выдаётся билет с указанием класса.
Есть две модели поведения (PHB): Best Effort и Premium.
Есть механизмы, реализующие модели поведения: Общий зал ожидания или VIP Lounge, микроавтобус или общий автобус, удобные большие сиденья или плотностоящие ряды, количество пассажиров на одну борт-проводницу, возможность заказать алкоголь.
В зависимости от класса назначаются модели поведения — эконому Best Effort, Бизнесу — Premium базовый, а Первому — Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX!
При этом два Premium отличаются тем что, в одном дают бокал полусладкого, а в другом безлимит Бакарди.

Далее по приезду в аэропорт все заходят через одни двери. Тех, кто попытался провезти с собой оружие или не имеет билета, не пускают (Drop). Бизнес и эконом попадают в разные залы ожидания и разный транспорт (Queuing). Сначала на борт пускают Первый класс, потом бизнес, потом эконом (Scheduling), однако потом они в пункт назначения все летят одним самолётом (интерфейс).

В этом же примере перелёт на самолёте — это задержка передачи (Propagation), посадка — задержка сериализации (Serialization), ожидание самолёта в залах — Queuing, а паспортный контроль — Processing. Заметьте, что и тут Processing Delay обычно пренебрежимо мал в масштабах общего времени.

Следующий аэропорт может обойтись с пассажирами совсем иначе — его PHB отличается. Но при этом если пассажир не меняет авиакомпанию, то, скорее всего, отношение к нему не поменяется, потому что одна компания — один DiffServ-domain.

Как вы могли уже заметить, DiffServ предельно (или беспредельно) сложен. Но всё описанное выше, мы разберём. При этом в статье я не буду вдаваться в нюансы физической реализации (они могут различаться даже на двух платах одного маршрутизатора), не буду рассказывать про HQoS и MPLS DS-TE.
Порог входа в круг инженеров, понимающих технологию, для QoS значительно выше, чем для протоколов маршрутизации, MPLS, или, прости меня Радья, STP.
И несмотря на это DiffServ заслужил признание и внедрение на сетях по всему миру, потому что, как говорится, хайли скэлэбл.
Всю дальнейшую часть статьи я буду разбирать только DiffServ.

Ниже мы разберём все инструменты и процессы, указанные на иллюстрации.

По ходу раскрытия темы некоторые вещи я буду показывать на практике.
Работать мы будем вот с такой сетью:

Trisolarans — это клиент провайдера linkmeup с двумя точками подключения.
Жёлтая область — это DiffServ-домен сети linkmeup, где действует единая политика QoS.
Linkmeup_R1 — это CPE устройство, которое находится под управлением провайдера, а потому в доверенной зоне. С ним поднят OSPF и взаимодействие происходит через чистый IP.
В пределах ядра сети MPLS+LDP+MP-BGP с L3VPN, растянутый от Linkmeup_R2 до Linkmeup_R4.
Все остальные комментарии я буду давать по мере необходимости.

Файл начальной конфигурации.

Внутри своей сети администратор определяет классы сервиса, которые он может предоставлять трафику.
Поэтому первое, что делает каждый узел при получении пакета, проводит его классификацию.

Существует три способа:

1. Behavior Aggregate (BA)
   Просто довериться имеющейся маркировке пакета в его заголовке. Например, полю IP DSCP.
   Называется он так, потому что под одной меткой в поле DSCP агрегированы различные категории трафика, которые ожидают одинакового по отношению к себе поведения. Например, все SIP-сессии будут агрегированы в один класс.
   Количество возможных классов сервиса, а значит и моделей поведения, ограничено. Соответственно нельзя каждой категории (или тем более потоку) выделить отдельный класс — приходится агрегировать.
2. Interface-based
   Всё, что приходит на конкретный интерфейс, помещать в один класс трафика. Например, мы точно знаем, что в этот порт подключен сервер БД и больше ничего. А в другой рабочая станция сотрудника.
3. MultiField (MF)
   Проанализировать поля заголовков пакета — IP-адреса, порты, MAC-адреса. Вообще говоря, произвольные поля.
   Например, весь трафик, который идёт в подсеть 10.127.721.0/24 по порту 5000, нужно маркировать как трафик, условно, требующий 5-й класс сервиса.

Администратор определяет набор классов сервиса, которые сеть может предоставлять, и сопоставляет им некоторое цифровое значение.

На входе в DS-домен мы никому не доверяем, поэтому проводится классификация вторым или третьим способом: на основе адресов, протоколов или интерфейсов определяется класс сервиса и соответствующее цифровое значение.

На выходе из первого узла эта цифра кодируется в поле DSCP заголовка IP (или другое поле Traffic Class: MPLS Traffic Class, IPv6 Traffic Class, Ethernet 802.1p) — происходит ремаркировка.

Внутри DS-домена принято доверять этой маркировке, поэтому транзитные узлы используют первый способ классификации (BA) — наиболее простой. Никакого сложного анализа заголовков, смотрим только записанную цифру.

На стыке двух доменов можно классифицировать на основе интерфейса или MF, как я описал выше, а можно довериться маркировке BA с оговорками.
Например, доверять всем значениям, кроме 6 и 7, а 6 и 7 перемаркировывать в 5.
Такая ситуация возможна в случае, когда провайдер подключает юрлицо, у которого есть своя политика маркировки. Провайдер не возражает сохранить её, но при этом не хочет, чтобы трафик попадал в класс, в котором у него передаются пакеты сетевых протоколов.

Behavior Aggregate

В BA используется очень простая классификация — вижу цифру — понимаю класс.
Так что же за цифра? И в какое поле она записывается?

• IPv6 Traffic Class
• MPLS Traffic Class
• Ethernet 802.1p

В основном классификация происходит по коммутирующему заголовку.
Коммутирующим я называю заголовок, на основе которого устройство определяет, куда отправить пакет, чтобы он стал ближе к получателю.
То есть если на маршрутизатор пришёл IP-пакет, анализируется заголовок IP и поле DSCP. Если пришёл MPLS, анализируется — MPLS Traffic Class.
Если на обычный L2-коммутатор пришёл пакет Ethernet+VLAN+MPLS+IP, то анализироваться будет 802.1p (хотя это можно и поменять).

IPv4 TOS

Поле QoS сопутствует нам ровно столько же, сколько и IP. Восьмибитовое поле TOS — Type Of Service — по задумке должно было нести приоритет пакета.

Ещё до появления DiffServ RFC 791 (INTERNET PROTOCOL) описывал поле так:
IP Precedence (IPP) + DTR + 00.

То есть идёт приоритет пакета, далее биты требовательности к Delay, Throughput, Reliability (0 — без требований, 1 — с требованиями).
Последние два бита должны быть нулём.

Чуть позже в RFC 1349 (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили:

Левые три бита остались IP Precedence, четыре следующих превратились в TOS после добавления бита Cost.
Вот как следовало читать единицы в этих битах TOS:

• D — «minimize delay»,
• T — «maximize throughput»,
• R — «maximize reliability»,
• C — «minimize cost».

Туманные описания не способствовали популярности этого подхода.

Системный подход к QoS на всём протяжении пути отсутствовал, чётких рекомендаций, как использовать поле приоритета тоже не было, описание битов Delay, Throughput и Reliability было крайне туманным.

Поэтому в контексте DiffServ поле TOS ещё раз переопределили в RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers):

Вместо битов IPP и DTRC ввели шестибитовое поле DSCP — Differentiated Services Code Point, два правых бита не были использованы.
С этого момента именно поле DSCP должно было стать главной маркировкой DiffServ: в него записывается определённое значение (код), которое в пределах данного DS-домена характеризует конкретный класс сервиса, необходимый пакету и его приоритет отбрасывания. Это та самая цифра.

Все 6 бит DSCP администратор может использовать, как ему заблагорассудится, разделяя максимум до 64 классов сервиса.
Однако в угоду совместимости с IP Precedence за первыми тремя битами сохранили роль Class Selector.
То есть, как и в IPP, 3 бита Class Selector позволяют определить 8 классов.

Однако это всё же не более, чем договорённость, которую в пределах своего DS-домена, администратор может легко игнорировать и использовать все 6 бит по усмотрению.
Далее также замечу, что согласно рекомендациям IETF, чем выше значение, записанное в CS, тем требовательнее этот трафик к сервису.
Но и это не стоит воспринимать как неоспоримую истину.

Если первые три бита определяют класс трафика, то следующие три используются для указания приоритета отбрасывания пакета (Drop Precedence или Packet Loss Priority — PLP).

Восемь классов — это много или мало? На первый взгляд мало — ведь так много разного трафика ходит в сети, что так и хочется каждому протоколу выделить по классу. Однако оказывается, что восьми достаточно для всех возможных сценариев.
Для каждого класса нужно определять PHB, который будет обрабатывать его как-то отлично от других классов.
Да и при увеличении делителя, делимое (ресурс) не увеличивается.
Я намеренно не говорю о том, какие значения какой именно класс трафика описывают, поскольку здесь нет стандартов и формально их можно использовать по своему усмотрению. Ниже я расскажу, какие классы и соответствующие им значения рекомендованы.

Практика классификации DSCP

Не помешает немного практики.
Схема та же.

Для начала просто отправим запрос ICMP:

Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Linkmeup_R1. E0/0.

pcapng

А теперь с установленным значением DSCP.
Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1 tos 184
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Значение 184 — это десятичное представление двоичного 10111000. Из них первые 6 бит — это 101110, то есть десятичные 46, а это класс EF.

Linkmeup_R2. E0/0

pcapng

Любопытное замечание: адресат попингушек в ICMP Echo reply устанавливает такое же значение класса, как было в Echo Request. Это логично — если отправитель послал пакет с определённым уровнем важности, то, очевидно, он хочет получить его гарантировано назад.

Linkmeup_R2. E0/0

Файл конфигурации DSCP классификации.

IPv6 Traffic Class

IPv6 мало чем в вопросе QoS отличается от IPv4. Восьмибитовое поле, называемое Traffic Class, также разбито на две части. Первые 6 бит — DSCP — играют ровно ту же роль.

Да, появился Flow Label. Говорят, что его можно было бы использовать для дополнительной дифференциации классов.

© Habrahabr.ru