DiffServ: DSCP и TC

Теоретические основы и архитектура

Обеспечение качества обслуживания (QoS) в сетях MPLS базируется на архитектуре DiffServ (Differentiated Services, RFC 3270). Входящие IP-пакеты клиента содержат 6-битное поле DSCP (Differentiated Services Code Point) в заголовке IP (например, EF — голос, AF31 — критичные данные, CS0 — Best Effort). Однако в заголовке MPLS для QoS выделено всего 3 бита — поле Traffic Class (TC, ранее именовавшееся EXP), поддерживающее только 8 значений приоритета (0-7). Задача пограничного маршрутизатора Ingress PE — выполнить трансляцию (маппинг) 64 значений IP DSCP в 8 классов MPLS TC при добавлении метки. Транзитные P-маршрутизаторы ядра не смотрят в IP DSCP: они классифицируют трафик, выделяют полосу и управляют очередями исключительно на основе 3 бит поля TC внешней метки. Различают два метода классификации в ядре: E-LSP (EXP-Inferred-PSC LSP), где класс обслуживания задаётся исключительно битами TC, и L-LSP (Label-Only-Inferred-PSC LSP), где класс обслуживания определяется значением самой метки MPLS.

Три заголовка, три поля приоритета

Один и тот же пакет несёт приоритет в трёх разных местах. В IP-заголовке это поле DS (бывший ToS): 6 бит DSCP по RFC 2474 и 2 бита ECN по RFC 3168. В заголовке Ethernet с 802.1Q это 3 бита PCP (и бит DEI). В MPLS shim-заголовке (RFC 3032) это 3 бита TC: 20 бит метка, 3 бита TC, 1 бит S, 8 бит TTL. Поле TC называлось EXP, пока RFC 5462 не переименовал его в TC (Traffic Class): "experimental" оно перестало быть давно, а название путало с ECN. Планировщик на каждом узле читает только то поле, которое умеет разобрать на данном шаге: ingress PE смотрит на клиентский DSCP, транзитный P - на TC верхней метки, egress PE - на TC (Pipe) или на DSCP (Short-Pipe). Весь MPLS QoS - это договор о том, кто, где и в какое поле переписывает приоритет.

DSCP и PHB: код и поведение

DSCP - это только числовой код, а PHB (Per-Hop Behavior) - поведение узла при пересылке: какая очередь, какая вероятность сброса. Соответствие "код - PHB" задаётся локально в каждом домене (RFC 2474), стандарт лишь рекомендует значения. Class Selector (CS0-CS7, формат xxx000) обратно совместим с IP Precedence. EF (Expedited Forwarding, RFC 3246) - код 46 (101110): низкие потери, задержка и джиттер, скорость выхода агрегата не меньше настроенной; EF обязательно ограничивают по скорости на входе, иначе он вытесняет всё остальное. AF (Assured Forwarding, RFC 2597) - 4 независимых класса по 3 уровня Drop Precedence; код считается как 8*класс + 2*drop: AF11=10, AF12=12, AF13=14, AF21=18 ... AF31=26, AF32=28, AF33=30, AF41=34, AF42=36, AF43=38. Внутри класса AF пакеты не переупорядочиваются, а при заторе первыми сбрасываются пакеты с большим Drop Precedence. RFC 4594 рекомендует 12 сервисных классов: Network Control CS6, Telephony EF, Signaling CS5, Multimedia Conferencing AF41-43, Real-Time Interactive CS4, Multimedia Streaming AF31-33, Broadcast Video CS3, Low-Latency Data AF21-23, OAM CS2, High-Throughput Data AF11-13, Standard DF, Low-Priority Data CS1.

Из 64 значений в 8: маппинг DSCP в TC

В TC всего 3 бита, то есть 8 значений. Поведение по умолчанию на большинстве платформ - копировать 3 старших бита DSCP (то есть IP Precedence): TC = DSCP >> 3. Для EF: 101110 -> 101 = 5, для AF41 (100010) - 4, для AF31 - 3. Таблица результата:

Из таблицы видны две потери. Первая: Drop Precedence AFx1/x2/x3 в одной строке неразличим для P-маршрутизатора, поэтому WRED внутри TC 4 не может сбрасывать AF43 раньше AF41. Если различие нужно, оператор делит 8 значений иначе: например, 4 AF-класса с двумя Drop Precedence занимают все 8 значений без места для EF и CS6, поэтому на практике жертвуют третьим уровнем drop или числом классов. Вторая: CS5 и EF попадают в один TC 5; если клиент пометит весь трафик как CS5, он займёт приоритетную очередь. Отсюда правило: классификацию на ingress PE делают по точным DSCP/ACL, а не по "верхним трём битам", а таблицу соответствия фиксируют в документе и применяют одинаково на всех платформах (у разных вендоров значения по умолчанию различаются).

E-LSP и L-LSP (RFC 3270)

RFC 3270 описывает два способа донести PHB через LSP. E-LSP (EXP-Inferred-PSC LSP): PHB выводится из поля TC, один LSP переносит до 8 PHB, соответствие TC-PHB либо преднастроено одинаково по сети, либо передаётся при установлении LSP (RSVP-TE: объект DIFFSERV; LDP: Diff-Serv TLV); сигнализация для E-LSP необязательна. L-LSP (Label-Only-Inferred-PSC LSP): класс планирования PSC (Per-Hop Scheduling Class, например AF1 со всеми тремя Drop Precedence) определяется самой меткой, а TC несёт только Drop Precedence; PSC обязательно сигнализируется. L-LSP нужен, когда PHB больше 8 или канальный уровень не умеет переносить TC, но стоит одной метки на каждый PSC: при EF, AF1-AF4, BE и CS6 это 7 привязок вместо одной на каждый FEC, то есть в 7 раз больше состояния LFIB и RSVP. Поэтому в реальных сетях (и на всех платформах курса) используется E-LSP.

Где ставится TC и что с ним делает P

Ingress PE пишет TC при push: на транспортную метку и на VPN-метку (для L3VPN их две; на большинстве платформ значение одинаковое). Транзитный P при swap копирует TC входящей метки в исходящую, если политика не говорит иное; P может понизить TC (re-marking) для сверхпрофильного трафика. Что происходит при снятии метки (PHP, Uniform/Pipe), разбирается в следующем уроке; здесь важно одно следствие: при PHP последний хоп до egress PE несёт уже только VPN-метку (или чистый IP при IPv4-over-LDP без VPN), поэтому очередь на выходе penultimate P должна классифицировать и по TC, и по DSCP.