Рекомендации IETF (категории трафика, классы сервиса и модели поведения)

Стандарты вообще не нормируют, какие именно классы сервиса должны существовать, как их классифицировать и маркировать, какие PHB к ним применять.

Это отдано на откуп вендорам и администраторам сетей. Имеем только 3 бита — используем, как хотим.

Это хорошо:
  • Каждая железка (вендор) самостоятельно выбирает, какие механизмы использовать для PHB.

  • Нет сигнализации, нет проблем совместимости.

  • Администратор каждой сети может гибко распределять трафик по разным классам, выбирать сами классы и соответствующий им PHB.

    Это плохо:

  • На границах DS-доменов возникают вопросы преобразования.

  • В условиях полной свободой действий — кто в лес, кто бес.

Поэтому IETF в 2006 выпустила методичку, как следует подходить к дифференциации сервисов: [RFC 4594](https://tools.ietf.org/html/rfc4594) \(_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.

Last updated