Классификация и маркировка
𝔯𝔱_𝔣𝔞𝔫Внутри своей сети администратор определяет классы сервиса, которые он может предоставлять трафику.
Поэтому первое, что делает каждый узел при получении пакета, проводит его классификацию.
Существует три способа:
- Behavior Aggregate (BA) Просто довериться имеющейся маркировке пакета в его заголовке. Например, полю IP DSCP. Называется он так, потому что под одной меткой в поле DSCP агрегированы различные категории трафика, которые ожидают одинакового по отношению к себе поведения. Например, все SIP-сессии будут агрегированы в один класс. Количество возможных классов сервиса, а значит и моделей поведения, ограничено. Соответственно нельзя каждой категории (или тем более потоку) выделить отдельный класс — приходится агрегировать.
- Interface-based Всё, что приходит на конкретный интерфейс, помещать в один класс трафика. Например, мы точно знаем, что в этот порт подключен сервер БД и больше ничего. А в другой рабочая станция сотрудника.
- 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 используется очень простая классификация — вижу цифру — понимаю класс.
Так что же за цифра? И в какое поле она записывается?
- IPv4 TOS/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 — с требованиями).
Последние два бита должны быть нулём.
Приоритет определял следующие значения:
111 — Network Control
110 — Internetwork Control
101 — CRITIC/ECP
100 — Flash Override
011 — Flash
010 — Immediate
001 — Priority
000 — Routine
Чуть позже в RFC 1349 (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили:
Вот как следовало читать единицы в этих битах 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, который будет обрабатывать его как-то отлично от других классов. Да и при увеличении делителя, делимое (ресурс) не увеличивается. Я намеренно не говорю о том, какие значения какой именно класс трафика описывают, поскольку здесь нет стандартов и формально их можно использовать по своему усмотрению. Ниже я расскажу, какие классы и соответствующие им значения рекомендованы.
Биты ECN…
Двухбитовое поле ECN появилось только в RFC 3168 (Explicit Congestion Notification). Поле было определено с благой целью — сообщить конечным хостам в явном виде о том, что кто-то по пути испытывает перегрузку. Например, когда в очередях маршрутизатора задерживаются пакеты надолго и заполняют их, например, на 85%, он меняет значение ECN, сообщая конечному хосту, что нужно помедленнее — что-то вроде Pause Frames в Ethernet. В этом случае отправитель должен уменьшить скорость передачи и снизить нагрузку на страдающий узел.
При этом теоретически поддержка этого поля всеми транзитными узлами не обязательна. То есть использование ECN не ломает сеть без его поддержки. Цель благая, но прежде применения в жизни ECN особо не находил. В наше время мега- и гиперскейлов на эти два бита смотрят с новым интересом.
ECN является одним из механизмов предотвращения перегрузок.
Interface-based.
Это наиболее простой способ классифицировать пакеты в лоб. Всё, что насыпалось в указанный интерфейс, помечается определённым классом.
В большинстве случае такой гранулярности не хватает. Поэтому Interface-based классификация не сказать, что часто встречается в чистом виде.
Multi-Field.
Наиболее часто встречающийся тип классификации на входе в DS-домен. Не доверяем имеющейся маркировке, а на основе заголовков пакета присваиваем класс.
Зачастую это способ вообще «включить» QoS, в случае, когда отправители не проставляют маркировку.
Достаточно гибкий инструмент, но в то же время громоздкий — нужно создавать непростые правила для каждого класса. Поэтому внутри DS-домена актуальнее BA.
Маркировка внутри устройства.
Ещё раз: на входе в DS-домен может происходить классификация MF, Interface-based или BA.
Между узлами DS-домена пакет в заголовке несёт знак о необходимом ему классе сервиса и классифицируется по BA.
Независимо от способа классификации после неё пакету присваивается внутренний класс в пределах устройства, в соответствии с которым он и обрабатывается. Заголовок при этом снимается, и голый (нет) пакет путешествует к выходу.
А на выходе внутренний класс преобразуется в поле CoS нового заголовка.
То есть Заголовок 1 ⇒ Классификация ⇒ Внутренний класс сервиса ⇒ Заголовок 2.
В некоторых случаях нужно отобразить поле заголовка одного протокола в поле заголовка другого, например, DSCP в Traffic Class.
Происходит это как раз через промежуточную внутреннюю маркировку.
Например, Заголовок DSCP ⇒ Классификация ⇒ Внутренний класс сервиса ⇒ Заголовок Traffic Class.
Формально, внутренние классы могут называться как угодно или просто нумероваться, а им в соответствие только ставится определённая очередь.
На глубине, до которой мы погружаемся в этой статье, не важно, как они называются, важно, что конкретным значениям полей QoS ставится в соответствие определённая модель поведения.
Если мы говорим о конкретных реализациях QoS, то количество классов сервиса, которое устройство может обеспечить, не больше, чем количество доступных очередей. Зачастую их восемь (не то под влиянием IPP, не то по неписанной договорённости). Однако в зависимости от вендора, устройства, платы, их может быть как больше, так и меньше.
То есть если очередей 4, то классов сервиса просто нет смысла делать больше четырёх.
Чуть поподробнее об этом поговорим в аппаратной главе.
Вот несколько условных таблиц соответствия между различными маркировками.
Таблицы ниже могут показаться удобными для первого взгляда на соотношение между полями QoS и внутренними классами, однако вводят несколько в заблуждение, называя классы именами PHB. Всё-таки PHB - это то, какая модель поведения назначается трафику определённого класса, имя которого, грубо говоря, произвольно.
Поэтому относитесь к таблицам ниже с долей скепсиса.
На примере Huawei. Здесь Service-Class — это та самая внутренняя маркировка пакета.
То есть, если на входе происходит классификация BA, то значения DSCP будут транслироваться в соответствующие им значения Service-Class и Color.
Здесь стоит обратить внимание на то, что многие значения DSCP не используются, и пакеты с такой маркировкой фактически обрабатываются, как BE.
Вот таблица обратного соответствия, которая показывает, какие значения DSCP будут установлены трафику при перемаркировке на выходе.
Обратите внимание, что только у AF есть градация по цветам. BE, EF, CS6, CS7 — все только Green.
Это таблица преобразования полей IPP, MPLS Traffic Class и Ethernet 802.1p во внутренние классы сервиса.
И обратно.
Заметьте, что здесь вообще теряется какая-либо информация о приоритете отбрасывания. Следует повториться — это только конкретный пример соответствий по умолчанию от наугад выбранного вендора. У других это может отличаться. На своей сети администраторы могут настроить совершенно отличные классы сервисов и PHB.
В плане PHB нет абсолютно никакой разницы что используется для классификации — DSCP, Traffic Class, 802.1p.
Внутри устройства они превращаются в классы трафика, определённые администратором сети. То есть все эти маркировки — это способ сообщить соседям, какой класс сервиса им следует назначить этому пакету. Это примерно, как BGP Community, которые не значат ничего сами по себе, пока на сети не определена политика их интерпретации.
Рекомендации IETF (категории трафика, классы сервиса и модели поведения).
Стандарты вообще не нормируют, какие именно классы сервиса должны существовать, как их классифицировать и маркировать, какие PHB к ним применять.
Это отдано на откуп вендорам и администраторам сетей.
Имеем только 3 бита — используем, как хотим.
Это хорошо:
- Каждая железка (вендор) самостоятельно выбирает, какие механизмы использовать для PHB.
- Нет сигнализации, нет проблем совместимости.
- Администратор каждой сети может гибко распределять трафик по разным классам, выбирать сами классы и соответствующий им PHB.
Это плохо:
- На границах DS-доменов возникают вопросы преобразования.
- В условиях полной свободой действий — кто в лес, кто бес.
Поэтому IETF в 2006 выпустила методичку, как следует подходить к дифференциации сервисов: RFC 4594 (Configuration Guidelines for DiffServ Service Classes).
Далее коротко суть этого RFC.
Модели поведения (PHB).
DF — Default Forwarding.
Стандартная пересылка. Если классу трафика не назначена модель поведения специально, он будет обрабатываться именно по Default Forwarding.Это Best Effort — устройство сделает всё возможное, но ничего не гарантирует. Возможны отбрасывания, разупорядочивание, непредсказуемые задержки и плавающий джиттер, но это не точно.
Такая модель подходит для нетребовательных приложений, вроде почты или загрузки файлов.
Есть, кстати, PHB и ещё менее определённый — A Lower Effort.
AF — Assured Forwarding.
Гарантированная пересылка. Это улучшенный BE. Здесь появляются некоторые гарантии, например, полосы. Отбрасывания и плавающие задержки всё ещё возможны, но уже в гораздо меньшей степени.
Модель подходит для мультимедии: Streaming, видео-конференц-связь, онлайн-игры.
RFC 2597 (Assured Forwarding PHB Group).
EF — Expedited Forwarding.
Экстренная пересылка. Все ресурсы и приоритеты бросаются сюда. Это модель для приложений, которым нужны отсутствие потерь, короткие задержки, стабильный джиттер, но они не жадные до полосы. Как, например, телефония или сервис эмуляции провода (CES — Circuit Emulation Service).
Потери, разупорядочивание и плавающие задержки в EF крайне маловероятны.
RFC 3246 (An Expedited Forwarding PHB).
CS — Class Selector.
Это модели поведения, призванные сохранить обратную совместимость с IP-Precedence в сетях, умеющих в DS.
В IPP существуют следующие классы CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7.
Не всегда для всех них существует отдельный PHB, обычно их два-три, а остальные просто транслируются в ближайший DSCP класс и получают соответствующий ему PHB.
Так например, пакет, помеченный CS 011000, может классифицироваться как 011010.
Из CS наверняка в оборудовании сохранились только CS6, CS7, которые рекомендованы для NCP — Network Control Protocol и требуют отдельного PHB.
Как и EF, PHB CS6,7 предназначены для тех классов, что имеют очень высокие требования к задержкам и потерям, однако до некоторой степени толерантны к дискриминации по полосе.
Задача PHB для CS6,7 обеспечить уровень сервиса, который исключит дропы и задержки даже в случае экстремальной перегрузки интерфейса, чипа и очередей.
Важно понимать, что PHB — это абстрактное понятие — и на самом деле реализуются они через механизмы, доступные на реальном оборудовании.
Таким образом один и тот же PHB, определённый в DS-домене, может различаться на Juniper и Huawei.
Более того, один PHB — это не статический набор действий, PHB AF, например, может состоять из нескольких вариантов, которые различаются уровнем гарантий (полосой, допустимыми задержками).
Классы сервиса.
В IETF позаботились об администраторах и определили основные категории приложений и агрегирующие их классы сервиса.
Я здесь не буду многословен, просто вставлю пару табличек из этого Guideline RFC.
Категории приложений:
Требования в характеристикам сети:
И наконец рекомендованные имена классов и соответствующие значения DSCP:
Комбинируя вышеуказанные классы различным образом (чтобы уложиться в 8 имеющихся), можно получить решения QoS для разных сетей.
Наиболее частым является, пожалуй, такое:
Классом DF (или BE) маркируется абсолютно нетребовательный трафик — он получает внимание по остаточному принципу. PHB AF обслуживает классы AF1, AF2, AF3, AF4. Им всем нужно обеспечить полосу, в ущерб задержкам и потерям. Потери управляются битами Drop Precedence, поэтому они и называются AFxy, где x — класс сервиса, а y — Drop Precedence. EF нужна некая минимальная гарантия полосы, но что важнее — гарантия задержек, джиттера и отсутствия потерь. CS6, CS7 требуют ещё меньше полосы, потому что это ручеёк служебных пакетов, в котором всё же возможны всплески (BGP Update, например), но в ней недопустимы потери и задержки — какая польза от BFD с таймером в 10 мс, если Hello вялится в очереди по 100 мс? То есть 4 класса из 8 доступных отдали под AF.
И несмотря на то, что фактически обычно так и делают, повторюсь, что это только рекомендации, и ничто не мешает в вашем DS-домене трём классам назначить EF и только двум — AF.
Короткий итог по классификации.
На входе в узел пакет классифицируется на основе интерфейса, MF или его маркировки (BA).
Маркировка — это значение полей DSCP в IPv4, Traffic Class в IPv6 и в MPLS или 802.1p в 802.1q.
Выделяют 8 классов сервиса, которые агрегируют в себе различные категории трафика. Каждому классу назначается свой PHB, удовлетворяющий требованиям класса.
Согласно рекомендациям IETF, выделяются следующие классы сервисов, это CS1, CS0, AF11, AF12, AF13, AF21, CS2, AF22, AF23, CS3, AF31, AF32, AF33, CS4, AF41, AF42, AF43, CS5, EF, CS6, CS7 в порядке возрастания важности трафика.
Из них можно выбрать комбинацию из 8, которые реально можно закодировать в поля CoS.
Наиболее распространённая комбинация: CS0, AF1, AF2, AF3, AF4, EF, CS6, CS7 с 3 градациями цвета для AF.
Каждому классу ставится в соответствие PHB, которых существует 3 — Default Forwarding, Assured Forwarding, Expedited Forwarding в порядке возрастания строгости. Немного в стороне стоит PHB Class Selector. Каждый PHB может варьироваться параметрами инструментов, но об этом дальше.
В незагруженной сети QoS не нужен, говорили они. Любые вопросы QoS решаются расширением линков, говорили они. С Ethernet и DWDM нам никогда не грозят перегрузки линий, говорили они.
Они — те, кто не понимает, что такое QoS.
Но реальность бьёт VPN-ом по РКНу.
1) Не везде есть оптика. РРЛ — наша реальность. Иногда в момент аварии (да и не только) в узкий радио-линк хочет пролезть весь трафик сети.
2) Всплески трафика — наша реальность. Кратковременные всплески трафика легко забивают очереди, заставляя отбрасывать очень нужные пакеты.
3) Телефония, ВКС, онлайн-игры — наша реальность. Если очередь хоть на сколько-то занята, задержки начинают плясать.
В моей практике были примеры, когда телефония превращалась в азбуку морзе на сети, загруженной не более чем на 40%. Всего лишь перемаркировка её в EF решила проблема сиюминутно.
Пришло время разобраться с инструментами, которые позволяют обеспечить разный сервис разным классам.