# Рекомендации 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-LIy_T4fn9FETAa89h6y%2F-LIz-mhI5akO1Ptg0w1J%2Fimage.png?alt=media\&token=ec7737a2-2fd9-4c26-9b22-63830da77480)

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

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LIy_T4fn9FETAa89h6y%2F-LIz0-piC-dJJpq0RPYe%2Fimage.png?alt=media\&token=1ca63214-e412-4d3a-8c37-e9a4e59eabf2)

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

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LIy_T4fn9FETAa89h6y%2F-LIz0VQ_gMmKqYNNrBTA%2Fimage.png?alt=media\&token=d1f18139-154e-468b-8533-79fd51fadd48)

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

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

![](https://3903873742-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LIgRTPaaN7wUujKIWEz%2F-LIy_T4fn9FETAa89h6y%2F-LIz0aIP5POopz96culO%2Fimage.png?alt=media\&token=afe5c688-b417-4720-96e0-0dc4fdd5d4a2)

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