# Рекомендации 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](https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-00).

### **AF — Assured Forwarding**

*Гарантированная пересылка.* Это улучшенный BE. Здесь появляются некоторые гарантии, например, полосы. Отбрасывания и плавающие задержки всё ещё возможны, но уже в гораздо меньшей степени.

Модель подходит для мультимедии: Streaming, видео-конференц-связь, онлайн-игры.\
[RFC 2597](https://tools.ietf.org/html/rfc2597) (*Assured Forwarding PHB Group*).

### **EF — Expedited Forwarding**

*Экстренная пересылка.* Все ресурсы и приоритеты бросаются сюда. Это модель для приложений, которым нужны отсутствие потерь, короткие задержки, стабильный джиттер, но они не жадные до полосы. Как, например, телефония или сервис эмуляции провода (CES — Circuit Emulation Service).

Потери, разупорядочивание и плавающие задержки в EF крайне маловероятны.\
[RFC 3246](https://tools.ietf.org/html/rfc3246) (*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.

### **Категории приложений:**

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LMaZAd3eKxVTz6opO3a%2F-LMaZGOwltXTrJZYVrhR%2Fimage-119.png?generation=1537171593886536\&alt=media)

### **Требования в характеристикам сети:**

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LMaZAd3eKxVTz6opO3a%2F-LMaZGOywZtSHghLRvfo%2Fimage-37.png?generation=1537171599111857\&alt=media)

### И наконец **рекомендованные имена классов** и соответствующие значения DSCP:

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LMaZAd3eKxVTz6opO3a%2F-LMaZGP-3ykR0PXC1evB%2Fimage-85.png?generation=1537171599750525\&alt=media)

Комбинируя вышеуказанные классы различным образом (чтобы уложиться в 8 имеющихся), можно получить решения QoS для разных сетей.

Наиболее частым является, пожалуй, такое:

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LMaZAd3eKxVTz6opO3a%2F-LMaZGP1SO2Dszt2Ensn%2Fimage-199.png?generation=1537171598968069\&alt=media)

Классом 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.