Behavior Aggregate
Last updated
Last updated
Так что же за цифра? И в какое поле она записывается?
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 (хотя это можно и поменять).
IP Precedence (IPP) + DTR + 00.
Последние два бита должны быть нулём.
Приоритет определял следующие значения
111 — Network Control 110 — Internetwork Control 101 — CRITIC/ECP 100 — Flash Override 011 — Flash 010 — Immediate 001 — Priority 000 — Routine
Вот как следовало читать единицы в этих битах 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):
С этого момента именно поле DSCP должно было стать главной маркировкой DiffServ: в него записывается определённое значение (код), которое в пределах данного DS-домена характеризует конкретный класс сервиса, необходимый пакету и его приоритет отбрасывания. Это та самая цифра.
Все 6 бит DSCP администратор может использовать, как ему заблагорассудится, разделяя максимум до 64 классов сервиса. Однако в угоду совместимости с IP Precedence за первыми тремя битами сохранили роль Class Selector.
То есть, как и в IPP, 3 бита Class Selector позволяют определить 8 классов.
Далее также замечу, что согласно рекомендациям IETF, чем выше значение, записанное в CS, тем требовательнее этот трафик к сервису.
Но и это не стоит воспринимать как неоспоримую истину.
Если первые три бита определяют класс трафика, то следующие три используются для указания приоритета отбрасывания пакета (Drop Precedence или Packet Loss Priority - PLP).
Восемь классов — это много или мало? На первый взгляд мало — ведь так много разного трафика ходит в сети, что так и хочется каждому протоколу выделить по классу. Однако оказывается, что восьми достаточно для всех возможных сценариев. Для каждого класса нужно определять PHB, который будет обрабатывать его как-то отлично от других классов. Да и при увеличении делителя, делимое (ресурс) не увеличивается. Я намеренно не говорю о том, какие значения какой именно класс трафика описывают, поскольку здесь нет стандартов и формально их можно использовать по своему усмотрению. Ниже я расскажу, какие классы и соответствующие им значения рекомендованы.
Биты ECN…
Двухбитовое поле ECN появилось только в RFC 3168 (Explicit Congestion Notification). Поле было определено с благой целью — сообщить конечным хостам в явном виде о том, что кто-то по пути испытывает перегрузку. Например, когда в очередях маршрутизатора задерживаются пакеты надолго и заполняют их, например, на 85%, он меняет значение ECN, сообщая конечному хосту, что нужно помедленнее — что-то вроде Pause Frames в Ethernet. В этом случае отправитель должен уменьшить скорость передачи и снизить нагрузку на страдающий узел.
При этом теоретически поддержка этого поля всеми транзитными узлами не обязательна. То есть использование ECN не ломает сеть без его поддержки. Цель благая, но прежде применения в жизни ECN особо не находил. В наше время мега- и гиперскейлов на эти два бита смотрят с новым интересом.
ECN является одним из механизмов предотвращения перегрузок, о которых ниже.
Схема та же.
Linkmeup_R1. E0/0.
__pcapng
Таблица стандартных значений TOS для удобных попингушек:
__Подробнее__
Linkmeup_R2. E0/0
__pcapng
Linkmeup_R2. E0/0
__Файл конфигурации DSCP классификации
DiffServ нельзя было не распространить на него.
С ним есть одна проблема — его длина три бита, что ограничивает число возможных значений до 9. Это не просто мало, это на 3 двоичных порядка меньше, чем у DSCP.
Вообще согласитесь, ситуация странная — MPLS разрабатывался как помощь IP для быстрого принятия решения — метка MPLS мгновенно обнаруживается в CAM по Full Match, вместо традиционного Longest Prefix Match. То есть и про IP знали, и в коммутации участие принимает, а нормальное поле приоритета не предусмотрели.
Поэтому в плане классов сервиса всё же имеем соответствие 1:1, теряя только информацию о Drop Precedence.
Маркировка означает запись значения в поле Traffic Class заголовка MPLS.
(это просто выдержка из статьи).
Uniform Mode
Pipe Mode
Short-Pipe Mode
Uniform Mode
Pipe Mode
Short-Pipe Mode
Посмотрим, что происходит с маркировкой при пинге ping ip 172.16.2.2 source 172.16.1.1 tos 184.
Linkmeup_R2. E0/0.
__pcapng
Тут мы являемся свидетелями режима работы Uniform.
Однако очень скоро стало ясно, что финансовая привлекательность Ethernet+IP выводит эту связку на уровень магистрали и WAN. Да и сожительство в одном LAN-сегменте торрентов и телефонии нужно разруливать. По счастью к этому моменту подоспел 802.1q (VLAN), в котором выделили 3-битовое (опять) поле под приоритеты. В плане DiffServ это поле позволяет определить те же 8 классов трафика.
Ethernet-коммутатор — 802.1p
MPLS-узел — MPLS Traffic Class
IP-маршрутизатор — IP DSCP
Хотя это поведение можно и изменить: Interface-Based и Multi-Field классификация. А можно иногда даже явно сказать, в поле CoS какого заголовка смотреть.
Это плоская модель End-to-End. На Ingress PE мы доверяем IP DSCP и копируем (строго говоря, отображаем, но для простоты будем говорить «копируем») его значение в MPLS EXP (как туннельный, так и VPN заголовки). На выходе с Ingress PE пакет уже обрабатывается в соответствии со значением поля EXP верхнего заголовка MPLS. Каждый транзитный P тоже обрабатывает пакеты на основе верхнего EXP. Но при этом он может его поменять, если того хочет оператор. Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в VPN-заголовок. Не важно, что там стояло — в режиме Uniform, происходит копирование. Egress PE снимая метку VPN, тоже копирует значение EXP в IP DSCP, даже если там записано другое. То есть если где-то в середине значение метки EXP в туннельном заголовке изменилось, то это изменение будет унаследовано IP-пакетом.
Если же на Ingress PE мы решили не доверять значению DSCP, то в заголовки MPLS вставляется то значение EXP, которое пожелает оператор. Но допустимо и копировать те, что были в DSCP. Например, можно переопределять значения — копировать всё, вплоть до EF, а CS6 и CS7 маппировать в EF. Каждый транзитный P смотрит только на EXP верхнего MPLS-заголовка. Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в заголовок VPN. Egress PE сначала производит обработку пакета, опираясь на поле EXP в заголовке MPLS, и только потом его снимает, при этом не копируетзначение в DSCP. То есть независимо от того, что происходило с полем EXP в заголовках MPLS, IP DSCP остаётся неизменным. Такой сценарий можно применять, когда у оператора свой домен Diff-Serv, и он не хочет, чтобы клиентский трафик как-то мог на него влиять.
Этот режим вы можете рассматривать вариацией Pipe-mode. Разница лишь в том, что на выходе из MPLS-сети пакет обрабатывается в соответствие с его полем IP DSCP, а не MPLS EXP. Это означает, что приоритет пакета на выходе определяется клиентом, а не оператором. Ingress PE не доверяет IP DSCP входящих пакетов Транзитные P смотрят в поле EXP верхнего заголовка. Предпоследний P снимает транспортную метку и копирует значение в VPN-метку. Egress PE сначала снимает метку MPLS, потом обрабатывает пакет в очередях. Объяснение от cisco.
