Все-симки.ру Механизмы DiffServ
Что же собой являет DiffServ и почему он выигрывает у IntServ?Если очень просто, то трафик делится на классы. Пакет на входе в каждый узел классифицируется и к нему применяется набор инструментов, который по-разному обрабатывает пакеты разных классов, таким образом обеспечивая им разный уровень сервиса.
Но просто не будет.В основе DiffServ лежит идеологически выдержанная в традициях IP концепция PHB — Per-Hop Behavior. Каждый узел по пути трафика самостоятельно принимает решение о том, как вести себя относительно пришедшего пакета, на основе его заголовков.
Действия маршрутизатора с пакетом назовём моделью поведения (Behavior). Количество таких моделей детерминировано и ограничено. На разных устройствах модели поведения по отношению к одному и тому же трафику могут отличаться, поэтому они и per-hop.Понятия Behavior и PHB я буду использовать в статье как синонимы.
Тут есть лёгкая путаница. PHB — это с одной стороны общая концепция независимого поведения каждого узла, с другой — конкретная модель на конкретном узле. С этим мы ещё разберёмся.
Используя имеющиеся модели поведения, сеть может предоставлять различные классы сервиса (Class of Service).
То есть разные категории трафика могут получить разный уровень сервиса в сети путём применения к ним разных PHB.
Соответственно прежде всего нужно определить к какому классу сервиса относится трафик — классификация (Classification).
Каждый узел самостоятельно классифицирует поступающие пакеты. 
Metering) — сколько битов/байтов трафика данного класса пришло на маршрутизатор.
На основе результатов пакеты могут окрашиваться (Coloring): зелёный (в рамках установленного лимита), жёлтый (вне лимита), красный (совсем берега попутал). 
Policing) (уж простите за такую кальку, есть вариант лучше — пишите, я поменяю). Полисер на основе цвета пакета назначает действие по отношению к пакету — передать, отбросить или перемаркировать. 
Queuing). Для каждого класса сервиса выделена отдельная очередь, что и позволяет их дифференцировать, применяя разные PHB.
Но ещё до того, как пакет попадёт в очередь, он может быть отброшен (Dropper), если очередь заполнена.
Если он зелёный, то он пройдёт, если жёлтый, то его вполне вероятно, отбросят, если очередь полна, а если красный — это верный смертник. Условно, вероятность отбрасывания зависит от цвета пакета и наполненности очереди, куда он собирается попасть. 
Shaper), задача которого очень похожа на задачу полисера — ограничить трафик до заданного значения.
Можно настроить произвольные шейперы для отдельных очередей или даже внутри очередей.
Об отличии шейпера от полисера в главе Ограничение скорости.
Все очереди в итоге должны слиться в единый выходной интерфейс.
Вспомните ситуацию, когда на дороге 8 полос сливаются в 3. Без регулировщика это превращается в хаос. Разделение по очередям не имело бы смысла, если бы на выходе мы имели то же, что на входе.
Поэтому есть специальный диспетчер (Scheduler), который циклически вынимает пакеты из разных очередей и отправляет в интерфейс (Scheduling).
На самом деле связка набора очередей и диспетчера — самый главный механизм QoS, который позволяет применять разные правила к разным классам трафика, одним обеспечивая широкую полосу, другим низкие задержки, третьим отсутствие дропов.
Далее пакеты уже выходят на интерфейс, где происходит преобразование пакетов в поток битов — сериализация (Serialization) и далее сигнал среды. 
Для этого, во-первых, на всех маршрутизаторах, настраиваются одинаковые классы и PHB для них, а во-вторых, используется маркировка (Marking) пакета — его принадлежность определённому классу записывается в заголовок (IP, MPLS, 802.1q).
И красота DiffServ в том, что следующий узел может довериться этой маркировке при классификации.
Такая зона доверия, в которой действуют одинаковые правила классификации трафика и одни модели поведения, называется домен DiffServ (DiffServ-Domain). 
Remark/Rewrite) его согласно правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
То есть явной сигнализации в DiffServ нет, но узел может сообщить всем следующим, какой класс нужно обеспечить этому пакету, ожидая, что тот доверится.
На стыках между DiffServ-доменами нужно согласовывать политики QoS (или не нужно).
Целиком картина будет выглядеть примерно так: 
Чтобы было понятно, приведу аналог из реальной жизни.
Перелёт на самолёте (не Победой).
Есть три класса сервиса (CoS): Эконом, Бизнес, Первый.
При покупке билета происходит классификация (Classification) — пассажир получает определённый класс сервиса на основе цены.
В аэропорту происходит маркировка (Remark) — выдаётся билет с указанием класса.
Есть две модели поведения (PHB): Best Effort и Premium.
Есть механизмы, реализующие модели поведения: Общий зал ожидания или VIP Lounge, микроавтобус или общий автобус, удобные большие сиденья или плотностоящие ряды, количество пассажиров на одну борт-проводницу, возможность заказать алкоголь.
В зависимости от класса назначаются модели поведения — эконому Best Effort, Бизнесу — Premium базовый, а Первому — Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX! При этом два Premium отличаются тем что, в одном дают бокал полусладкого, а в другом безлимит Бакарди.
Далее по приезду в аэропорт все заходят через одни двери. Тех, кто попытался провезти с собой оружие или не имеет билета, не пускают (Drop). Бизнес и эконом попадают в разные залы ожидания и разный транспорт (Queuing). Сначала на борт пускают Первый класс, потом бизнес, потом эконом (Scheduling), однако потом они в пункт назначения все летят одним самолётом (интерфейс).
В этом же примере перелёт на самолёте — это задержка передачи (Propagation), посадка — задержка сериализации (Serialization), ожидание самолёта в залах — Queuing, а паспортный контроль — Processing. Заметьте, что и тут Processing Delay обычно пренебрежимо мал в масштабах общего времени.
Следующий аэропорт может обойтись с пассажирами совсем иначе — его PHB отличается. Но при этом если пассажир не меняет авиакомпанию, то, скорее всего, отношение к нему не поменяется, потому что одна компания — один DiffServ-domain.
Как вы могли уже заметить, DiffServ предельно (или беспредельно) сложен. Но всё описанное выше, мы разберём. При этом в статье я не буду вдаваться в нюансы физической реализации (они могут различаться даже на двух платах одного маршрутизатора), не буду рассказывать про HQoS и MPLS DS-TE.
Порог входа в круг инженеров, понимающих технологию, для QoS значительно выше, чем для протоколов маршрутизации, MPLS, или, прости меня Радья, STP.
И несмотря на это DiffServ заслужил признание и внедрение на сетях по всему миру, потому что, как говорится, хайли скэлэбл.
Всю дальнейшую часть статьи я буду разбирать только DiffServ.
Ниже мы разберём все инструменты и процессы, указанные на иллюстрации. 
Dwrr — deficit weighted round robin
И вдруг, крайне любопытный подход в 1995-м году предложили M. Shreedhar and G. Varghese.
Каждая очередь имеет отдельную кредитную линию в битах.
При проходе из очереди выпускается столько пакетов, на сколько хватает кредита.
Из суммы кредита вычитается размер того пакета, что в голове очереди.
Если разность больше нуля, этот пакет изымается, и проверяется следующий. Так до тех пор, пока разность не окажется меньше нуля.
Если даже первому пакету не хватает кредита, что ж, увы-селявы, он остаётся в очереди.
Перед следующим проходом кредит каждой очереди увеличивается на определённую сумму, называемую квант.
Для разных очередей квант разный — чем большую полосу нужно дать, тем больше квант.
Таким образом все очереди получают гарантированную полосу, независимо от размера пакетов в ней. 
Разберём сферический случай:
- DRR (без W),
- 4 очереди,
- в 0-й все пакеты по 500 байтов,
- В 1-й — по 1000,
- Во 2-й по 1500,
- А в 3-й лежит одна колбаса на 4000,
- Квант — 1600 байтов.
Цикл 1
Цикл 1. Очередь 0
Начинается первый цикл, каждой очереди выделяется по 1600 байтов (квант)
Обработка начинается с 0-й очереди. Диспетчер считает:
Первый пакет в очереди проходит — Пропускаем (1600 — 500 = 1100).
Второй — проходит — пропускаем (1100 — 500 = 600).
Третий — проходит — пропускаем (600 — 500 = 100).
Четвёртый — уже не проходит (100 — 500 = -400). Переходим к следующей очереди.
Финальный кредит — 100 байтов. 
Цикл 1. Очередь 1
Первый пакет проходит — пропускаем (1600 — 1000 = 600).
Второй не проходит (600 — 1000 = -400). Переходим к следующей очереди.
Финальный кредит — 600 байтов. 
Цикл 1. Очередь 2
Первый пакет проходит — пропускаем (1600 — 1500 = 100).
Второй не проходит (100 — 1000 = -900). Переходим к следующей очереди.
Финальный кредит — 100 байтов. 
Цикл 1. Очередь 3
Первый пакет уже не проходит. (1600 — 4000 = -2400).
Переходим к следующей очереди.
Финальный кредит — те же 1600 байтов. 
Итак, по окончании первого цикла работы диспетчера пропустили:
- Очередь 0 — 1500
- Очередь 1 — 1000
- Очередь 2 — 1500
- Очередь 3 — 0
Имеющийся кредит:
- Очередь 0 — 100
- Очередь 1 — 600
- Очередь 2 — 100
- Очередь 3 — 1600
Цикл 2
В начале цикла к кредиту очереди прибавляется заданный квант — то есть 1600 байтов.
Цикл 2. Очередь 0
Кредит увеличивается до 1700 (100 1600).
Первые три пакета в очереди проходят — пропускаем их (1700 — 3*500 = 200).
Четвёртому уже не хватает кредита.
Финальный кредит — 200 байтов. 
Цикл 2. Очередь 1
Кредит увеличивается до 2200 (600 1600).
Первые два пакета в очереди проходят — пропускаем их (2200 — 2*1000 = 200).
Третий уже не проходит.
Финальный кредит — 200 байтов. 
Цикл 2. Очередь 2
Кредит увеличивается до 1700 (100 1600).
Первый пакет в очереди проходит — пропускаем его (2200 — 1500 = 200).
А второй — уже нет.
Финальный кредит — 200 байтов. 
Цикл 2. Очередь 3
Кредит увеличивается до 3200 (1600 1600).
Но она всё равно в пролёте (3200 — 4000 = -800)
Финальный кредит — 3200 байтов. 
Итак, по окончании второго цикла работы диспетчера пропустили:
- Очередь 0 — 3000
- Очередь 1 — 3000
- Очередь 2 — 3000
- Очередь 3 — 0
Имеющийся кредит:
- Очередь 0 — 200
- Очередь 1 — 200
- Очередь 2 — 200
- Очередь 3 — 3200
Цикл 3
В начале каждого цикла к кредиту очереди прибавляется квант — 1600 байтов.
Цикл 3. Очередь 0
Кредит увеличивается до 1800 (200 1600).
И снова три пакета в очереди проходят — пропускаем их (1800 — 3*500 = 300).
Четвёртому опять не хватает кредита.
Финальный кредит — 300 байтов. 
Цикл 3. Очередь 1
Кредит увеличивается до 1800 (200 1600).
Один пакет проходит — пропускаем (1800 — 1000 = 800).
Финальный кредит — 800 байтов. 
Цикл 3. Очередь 2
Кредит увеличивается до 1800 (200 1600).
Один пакет проходит — пропускаем (1800 — 1500 = 300).
Финальный кредит — 300 байтов. 
Цикл 3. Очередь 3
Будет и в 3-й очереди праздник!
Кредит увеличивается до 4800 (3200 1600).
Пакет наконец проходит — пропускаем (4800 — 4000 = 800).
Финальный кредит — 800 байтов. 
Итак, по окончании третьего цикла работы диспетчера пропустили:
- Очередь 0 — 4500
- Очередь 1 — 4000
- Очередь 2 — 4500
- Очередь 3 — 4000
Имеющийся кредит:
- Очередь 0 — 300
- Очередь 1 — 800
- Очередь 2 — 300
- Очередь 3 — 800
Достаточно наглядна здесь работа DRR. В масштабах многих итераций все очереди получат причитающуюся часть полосы.
Если кому не лень, смотрите анимации. 
Отличие DWRR от DRR только в том, что в начале цикла каждой очереди выделяется квант, полагающийся именно ей, а не одинаковый для всех.
Выше был описан подход DRR, в котором очереди нельзя уходить в минус — если кредитов не хватает, пакет не пропускается.
Однако есть и более либеральный: пакеты пропускаются, пока очередь не в минусе. В следующий раз пакет пройдёт как только кредит окажется опять положительным.
С DWRR всё же остаётся вопрос с гарантией задержек и джиттера — вес его никак не решает.Теоретически, здесь можно поступить как и с CB-WFQ, добавив LLQ.Однако это лишь один из возможных сценариев набирающего сегодня популярность
Ipv4 tos
Поле QoS сопутствует нам ровно столько же, сколько и IP. Восьмибитовое поле TOS — Type Of Service — по задумке должно было нести приоритет пакета.
Ещё до появления DiffServ RFC 791 (INTERNET PROTOCOL) описывал поле так:
IP Precedence (IPP) DTR 00. 
Последние два бита должны быть нулём.Чуть позже в RFC 1349 (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили: 
Вот как следовало читать единицы в этих битах 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): 
Differentiated Services Code Point, два правых бита не были использованы.
С этого момента именно поле 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 появилось только в
RFC 3168
(
Explicit Congestion Notification
). Поле было определено с благой целью — сообщить конечным хостам в явном виде о том, что кто-то по пути испытывает перегрузку.
Например, когда в очередях маршрутизатора задерживаются пакеты надолго и заполняют их, например, на 85%, он меняет значение ECN, сообщая конечному хосту, что нужно помедленнее — что-то вроде Pause Frames в Ethernet. В этом случае отправитель должен уменьшить скорость передачи и снизить нагрузку на страдающий узел.
При этом теоретически поддержка этого поля всеми транзитными узлами не обязательна. То есть использование ECN не ломает не поддерживающую его сеть.
Цель благая, но прежде применения в жизни ECN особо не находил. В наше время мега- и гиперскейлов на эти два бита смотрят с
новым интересом
.
ECN является одним из механизмов предотвращения перегрузок, о которых
ниже
.
Mpls traffic class
Концепция DiffServ была ориентирована на IP-сети с маршрутизацией на основе IP-заголовка. Вот только незадача — через 3 года опубликовали RFC 3031 (Multiprotocol Label Switching Architecture). И MPLS начал захватывать сети провайдеров.
DiffServ нельзя было не распространить на него.
По счастливой случайности в MPLS заложили трёхбитовое поле EXP на всякий экспериментальный случай. И несмотря на то, что уже давным-давно в RFC 5462 («EXP» Field Renamed to «Traffic Class» Field) официально стало полем Traffic Class, по инерции его называют ИЭксПи.
С ним есть одна проблема — его длина три бита, что ограничивает число возможных значений до 9. Это не просто мало, это на 3 двоичных порядка меньше, чем у DSCP. 
L-LSP. Использует комбинацию Traffic Class значение метки.
Вообще согласитесь, ситуация странная — MPLS разрабатывался как помощь IP для быстрого принятия решения — метка MPLS мгновенно обнаруживается в CAM по Full Match, вместо традиционного Longest Prefix Match. То есть и про IP знали, и в коммутации участие принимает, а нормальное поле приоритета не предусмотрели.
На самом деле выше мы уже увидели, что для определения класса трафика используется только первые три бита DSCP, а три другие — Drop Precedence (или PLP — Packet Loss Priority).Поэтому в плане классов сервиса всё же имеем соответствие 1:1, теряя только информацию о Drop Precedence.
В случае MPLS классификация так же как и в IP может быть на основе интерфейса, MF, значения DSCP IP или Traffic Class MPLS.Маркировка означает запись значения в поле Traffic Class заголовка MPLS.Пакет может содержать несколько заголовков MPLS.
- Uniform Mode
- Pipe Mode
- Short-Pipe Mode
Uniform mode
Это плоская модель 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-пакетом.
Pipe mode
Если же на 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, и он не хочет, чтобы клиентский трафик как-то мог на него влиять.
Short-pipe mode
Этот режим вы можете рассматривать вариацией Pipe-mode. Разница лишь в том, что на выходе из MPLS-сети пакет обрабатывается в соответствие с его полем IP DSCP, а не MPLS EXP.
Это означает, что приоритет пакета на выходе определяется клиентом, а не оператором.
Ingress PE не доверяет IP DSCP входящих пакетов
Транзитные P смотрят в поле EXP верхнего заголовка.
Предпоследний P снимает транспортную метку и копирует значение в VPN-метку.
Egress PE сначала снимает метку MPLS, потом обрабатывает пакет в очередях.
Объяснение от cisco.
Single rate — two color marking
Пока не обращайте внимания на название =)
Имеем ведро, в которое падают монетки с постоянной скорость — 400 мегамонет в секунду, например.
Объём ведра — 600 миллионов монет. То есть наполняется оно за полторы секунды.
Рядом проходят две ленты конвейера: одна подвозит пакеты, вторая — увозит.
Чтобы попасть на отвозящий конвейер, пакет должен заплатить.
Монетки для этого он берёт из ведра в соответствии со своим размером. Грубо говоря — сколько битов — столько и монеток. 
Если ведро уже полное, все новые монеты будут выбрасываться. 
Если она стабильно ниже или равна 400 Мб в секунду, значит монет всегда будет хватать.
Если выше, то часть пакетов будет теряться.
Более конкретный пример с гифками, как мы все любим. 
- Есть ведро ёмкостью 2500 байтов. На начальный момент времени в нём лежит 550 токенов. На конвейере три пакета по 1000 байтов, которые хотят быть отправлены в интерфейс. В каждый квант времени в ведро падает 500 байтов (500*8 = 4 000 бит/квант времени — ограничение полисера).
- На исходе первого кванта времени в ведро падает 500 токенов. И в это время подходит первый пакет. Его размер 1000 байтов, а в ведре 1050 токенов — хватает. Пакет красится в зелёный цвет и пропускается. 1000 токенов вынимается из ведра. В ведре остаётся 50 токенов.
- На исходе второго кванта времени в ведро падает ещё 500 токенов — итого 550. А размер пришедшего пакета — 1000 — не хватает. Пакет красится красным и отбрасывается, токены не вынимаются.
- На исходе третьего кванта в ведро падает ещё 500 токенов — снова 1050. Размер пришедшего пакета — 1000 — хватает. Пакет красится в зелёный и пропускается, токены вынимаются из ведра.
Объём ведра в 2500 байтов фактически означает, что через такой полисер ни при каких условиях не пройдёт пакет больше 2500 байтов — ему никогда не будет хватать токенов. Поэтому его объём должен быть не меньше MTU и вообще рекомендуется объём, равный количеству трафика на максимальной скорости, разрешённой полисером, за 1,5-2 секунды.
То есть формула следующая:
CBS = CIR (бит в секунду)*1,5 (секунды)/8 (бит в байте)
Если вернуться к практическому примеру по полисингу, где мы настраивали всплески (Bc), то станет понятно, что при большом значении (1 875 000 байтов) все всплески амортизируются хорошо. А при маленьком (10 000 байтов), несмотря на то, что оно заметно больше MTU, полисер упирается в постоянное заполнение ведра и отбрасывает большое количество пакетов.
Зачем ведру объём? Битовый поток не всегда равномерен, это очевидно. Ограничение в 400 Мб/с — это не асимптота — трафик может её пересекать. Объём хранящихся монет позволяет небольшим всплескам пролетать, не будучи отброшенными, однако среднюю скорость сохранить на уровне 400Мб/с.
Например, стабильный поток 399 Мб/с за 600 секунд позволит ведру наполниться до краёв.
Далее трафик может подняться до 1000Мб/с и держаться на этом уровне 1 секунду — 600 Мм (Мегамонет) запаса и 400 Мм/с гарантированной полосы.
Или же трафик может подняться до 410 Мб/с и держаться таким на протяжении 60 секунд. 
Теперь к терминологии.
Скорость поступления монет в ведро — CIR — Committed Information Rate (Гарантированная средняя скорость). Измеряется в битах в секунду.
Количество монет, которые могут храниться в ведре — CBS — Committed Burst Size. Разрешённый максимальный размер всплесков. Измеряется в байтах. Иногда, как вы уже могли заметить, называется Bc. Tc — Количество монет (Token) в ведре C (CBS) в данный момент. 
В статье я использую термин «Tc«, так же, как он использован в RFC 2697 (A Single Rate Three Color Marker).
Однако есть и другой Tc, который описывает интервал времени, когда в ведро ссыпается новая порция монет.
Здесь следует сделать отступление.
Невозможно подстроить скорость интерфейса, чтобы удовлетворить условиям полисера, поэтому и вводится система Token Bucket, реализующая по сути TDM (Time-Division Multiplexing) — она разрешает отправку трафика только в определённые моменты времени.
То есть монеты не льются в ведро непрерывным потоком — современный мир, увы, дискретен.
В первом приближении предлагается один раз в секунду насыпать CIR монет. Потом через секунду итд.
Это работает плохо, потому что всплеск — и секунда молчания, всплеск — и секунда молчания, всплеск — и секунда молчания.
Поэтому во втором приближении секунда делится на интервалы времени, в которые спускается определённое число монет.
Такой интервал времени тоже называется (как минимум в литературе Cisco) Tc, а количество падающих монет — Bc. При этом Bc = CIR*Tc.
То есть в начале каждого интервала Tc в ведро опускается Bc монет.
Это самый простой сценарий. Он называется Single Rate — Two Color.Single Rate означает, что есть только одна средняя разрешённая скорость, а Two Color — что можно покрасить трафик в один из двух цветов: зелёный или красный.
- Если количество доступных монет (бит) в ведре C больше, чем количество бит, которые нужно пропустить в данный момент, пакет красится в зелёный цвет — низкая вероятность отбрасывания в дальнейшем. Монеты изымаются из ведра.
- Иначе, пакет красится в красный — высокая вероятность дропа (либо, чаще, сиюминутное отбрасывание). Монеты при этом из ведра С не изымаются.
Используется для полисинга в PHB CS и EF, где превышения по скорости не ожидается, но если оно произошло, то лучше сразу отбросить.Дальше рассмотрим посложнее: Single Rate — Three Color.
Как определить приоритет трафика
После того, как вы включили Quality of Service, пришло время создать основные правила приоритизации трафика.
Некоторые новые маршрутизаторы имеют мертвые простые параметры QoS, где вы просто выбираете сервисы, которые вы хотите расставить по приоритетам (или перетаскивайте их в список). Вот, к примеру, это скриншот от нового маршрутизатора ASUS, который у нас есть:
Если это все, что вам нужно, и ваш маршрутизатор имеет эту функцию, попробуйте и посмотрите, что работает. Но если вам нужен более мелкий контроль, или у вас есть более старый маршрутизатор, у которого нет такой простой настройки, вот несколько более подробных инструкций по настройке QoS.
Приоритет службы
Если вы хотите, чтобы каждое устройство в вашей сети имело приоритетный доступ к определенному приложению или сервису, вы можете создать правило приоритета службы сети. Скажем, для примера, вы хотите убедиться, что Netflix получает приоритет за менее чувствительные к пропускной способности вещи, такие как общий просмотр веб-страниц. Сначала вы выберите услугу в раскрывающемся меню, как показано ниже, а затем нажмите «Добавить».
После того, как сервис указан, выберите приоритет, который вы хотите использовать для этого.
Приоритет по интерфейсу
В сетевом языке «интерфейс» — это метод, с помощью которого ваше устройство подключено к сети. Вы можете установить приоритеты в локальной сети Ethernet, вы можете назначить приоритеты беспроводным соединениям, или вы даже можете установить правила, которые делают сетевой трафик для гостей невысоким.
Давайте посмотрим, как мы можем сделать гостевой сетевой трафик низким приоритетом. В раскрывающемся меню мы выберем «wl0.1», который в сетевом сокращении будет виртуальной локальной сетью № 0. Виртуальная сеть 1. Нажмите «Добавить».
После того, как вы добавили интерфейс, вы можете указать максимальную скорость загрузки / скачивания и даже приоритизировать службы на конкретном соединении, как показано на скриншоте ниже.
Приоритет интерфейса заключается в том, что из-за необходимых знаний о схемах тайного сетевого наименования используется одна из наиболее сложных систем приоритета.
Приоритет устройства с IP-адресами
Предположите, что вы всегда должны указывать определенное устройство, такое как ваш рабочий компьютер. Если вы используете статические IP-адреса или резервирования DHCP в своей сети, вы можете определить приоритет трафика на определенных компьютерах и устройствах, используя их IP-адрес.
Скажем, например, что вы хотите, чтобы ваш домашний сервер, расположенный на статическом IP-адресе 10.0.0.200, имел доступ с наивысшим приоритетом к вашей сети. Вы должны ввести адрес в разделе «Приоритет сетевой маски» и добавить конец с 32, как показано ниже.
Элемент 32 — это сетевая маска. Подробное обсуждение использования netmask немного выходит за рамки этого руководства, но достаточно сказать, что маска / 32 — это сокращение сетевой маски для «только для разрешения этого единственного IP-адреса». Любое другое меньшее число позволит массе охватить большее количество адресов в данном блоке (например, 10.0.0.
200/24 приведет к тому, что правило качества обслуживания будет применяться ко всем 254 потенциальным адресам в блоке 10.0.0. *) , Вы можете обратиться к этому краткому справочному руководству сетевой маски, чтобы выбрать номер, который работает для раздела и размера блока адресов, который вы хотите установить приоритет.
Если вы обнаружите, что сетевая маска немного запутана (это не совсем интуитивно понятно), лучше всего просто придерживаться / 32 и вводить вручную каждый IP-адрес.
Как только вы нажмете «Добавить», вы можете назначить приоритетный доступ к адресу, как в предыдущем разделе.
Приоритет устройства с MAC-адресами
Если вы не используете статические IP-адреса в своей сети, вы все равно можете определить приоритеты для определенных компьютеров и устройств с их MAC-адресом. Он будет либо на физическом ярлыке, прикрепленном к устройству, либо где-нибудь в его настройках программного обеспечения.
С MAC-адресом в руке просто введите его в раздел приоритета MAC, нажмите «Добавить», а затем назначьте приоритет устройству, как это было в предыдущих разделах.
Теперь, независимо от того, какой IP-адрес назначает ваш маршрутизатор, скажем, вы можете обеспечить свой рабочий ноутбук, он всегда будет иметь приоритет.
Качество обслуживания в сетях lte
Концепция системы QoS для сетей UMTS мобильной связи 3-го поколения определена в спецификации TS 23.107, и используется также для сетей LTE 4-го поколения.
При разработке и внедрении системы качества обслуживания к атрибутам такой системы предъявляются следующие общие требования:
· Количество и значения атрибутов должны быть таковы, чтобы обеспечить возможность многоуровневой градации пользователей.
· Использование механизма QoS не должно мешать политике эффективного использования радиоресурсов, независимому развитию базовой сети и сети радиодоступа.
· Все атрибуты и их комбинации должны иметь однозначно определённые значения.
Исходя из перечисленных общих требований к качеству обслуживания, в спецификациях сформулированы конкретные технические
требования, касающиеся набора параметров QoS:
· Механизмы QoS функционируют в рамках одноранговой (peerto peer) модели организации связи в границах «пользовательский терминал – сетевой шлюз», обеспечивая взаимно-однозначное отображение между сетевыми услугами и внешними приложениями.
· Управление качеством обслуживания осуществляется на основе конечного, по возможности, минимального набора параметров QoS, поддерживающих эффективное использование радиоресурсов, а также ассиметричное функционирование сквозных каналов.
· Методы управления QoS реализуются на основе последовательных сессий, применительно к пакетной передачи данных, в том числе, к мультипотоковой передаче, когда несколько различных потоков имеют один и тот же адрес.
· Сетевые ухудшения и усложнения, вызванные внедрением системы качества обслуживания, должны быть по возможности минимизированы, также, как и количество дополнительной информации, хранимой и передаваемой в сети.
· Пользовательские приложения должны иметь возможность индикации значений QoS при передаче данных в различных сетевых узлах.
· Система качества обслуживания должна быть динамической, позволяющей изменять параметры QoS в течение активной сессии.
Перечислим и кратко опишем основные функции сети LTE, относящиеся к управлению качеством обслуживания. В пользовательской плоскости такие функции направлены на поддержку пользовательского трафика и сигнализации с определёнными ограничениями, установленными параметрами QoS.
Функция отображения (MF, Mapping Function) обеспечивает на-
деление каждого предназначенного для передачи пакета данных соответствующими параметрами QoS.
Функция классификации (CF, Classification Function) предназначена для выставления пакетам данных параметров QoS, предназначенных для определённого ПТ, в том случае, если для этого ПТ в сети установлено несколько каналов передачи услуг.
Функция управления ресурсами (RMF, Resource Manager Function) распределяет доступные ресурсы между услугами в соответствии с параметрами QoS.
Функция согласования (очистки) трафика (TCF, Traffic Conditioner Function) обеспечивает согласование между потоком пользовательских данных и установленным уровнем качества обслуживания. Те пакеты данных, которые не соответствуют выставленным параметрам QoS, будут отброшены или помечены как несоответствующие для последующего отбрасывания после накопления [1].
Функция классификации, реализованная в ПТ и СШ, назначает пакеты данных, полученным из внешнего (или локального) канала в услугу сети LTE с соответствующими параметрами QoS. Функция согласования трафика, при необходимости, обеспечивает согласование пользовательского потока в восходящем (в ПТ) и нисходящем (в СШ) направлениях с установленными параметрами QoS. Далее, функция отображения снабжает каждый пакет данных специальным QoS-индикатором, отправляя того в путь по сети, что требует выделения соответствующих ресурсов – за это ответственна функция управления ресурсами, реализованная в каждом сетевом узле.
В плоскости управления, как обычно, сосредоточены функции, необходимые для реализации механизмов управления и контроля.
Функция управления услугами (SMF, Service Manager Function) является координирующей функцией при установке, модифицировании и управлении услугами, а также управляющей для функций управления качеством обслуживания в пользовательской плоскости.
Трансляционная функция (TF, Translation Function) преобразует внутренние примитивы услуг сети LTE в модули различных протоколов взаимодействующих внешних сетей, включая преобразования атрибутов услуг сети LTE в параметры QoS протоколов внешних сетей.
Функция управления возможностями (A/CCF, Admission / Capability Control Function) обеспечивает информацией обо всех возможных ресурсах сетевых узлов, определяя при каждом запросе (или модифицировании) услуги, могут ли сетевые узлы обеспечить требуемые ресурсы. Данная функция также контролирует возможность предоставления самой услуги, т.е. реализована ли в сети запрашиваемая услуга.
Функция управления подпиской (SCF, Subscription Control Function) обеспечивает контроль доступности абонентов на пользование различными услугами с требуемыми параметрами QoS.
Трансляционная функция, действующая в ПТ и СШ, преобразует служебную информацию, связанную с внешней услугой, в примитивы внутренней услуги, включая и атрибуты услуги.
Функция управления услугой, локализованная в ПТ, СШ и базовой сети (т.е. соответствующий подфункции), с помощью трансляционной функции устанавливает или модифицирует услугу, используя при этом связанные с ней функцию управления возможностями, с целью выяснения наличия требуемых для данной услуги ресурсов, и функцию управления подпиской, для определения прав пользователя на эту услугу.
Концепция предоставления услуг предполагает наличие четырёх классов качества обслуживания, называемых также трафиковыми классами:
· голосовой (разговорный);
· потоковый;
· интерактивный;
· фоновый.
Главным различием между названными классами является чувствительность к задержкам: наиболее чувствительным является голосовой трафик, наименее чувствительным – фоновый трафик. Голосовой и потоковый классы предназначены для использования в реальном масштабе времени. Интерактивный и фоновый классы используются для традиционных интернет-приложений: интернет-навигация, электронная почта, удалённая связь и др. При этом трафик интерактивного класса имеет более высокий приоритет, чем трафик фонового класса.
Перечислим список параметров QoS, по которым осуществляется относительная градация пользователей.
1. Трафиковый класс (голосовой, потоковый, интерактивный, фоновый).
2. Максимальная скорость передачи данных (в Кбит/с). Данный параметр определяет максимальное число бит, доставляемых сетью LTE (или в сеть LTE) за определённые интервалы времени.
3. Гарантированная скорость передачи данных (в Кбит/с) определяет гарантированное число бит, доставляемых сетью за определённые интервалы времени.
4. Порядок доставки (Да/ Нет). Параметр, показывающий, обеспечивает ли сквозной канал последовательную доставку пакетов данных или нет. Фактически данный параметр показывает отличие протокола передачи данных от пользовательского PDP-протокола.
5. Максимальный размер (в байтах) пакетов данных, переносящих содержимое услуги (SDU, Service Data Unit). Данный параметр следует отличать от параметра MTU (Maximum Transfer Unit), используемого в IP-протоколе.
6. Информация (в битах) о формате пакетов данных, переносящих содержимое услуги, необходимая в сети радиодоступа в целях обеспечения функционирования RLC-протокола в прозрачном режиме.
7. Относительный уровень ошибочно переданных пакетов данных, переносящих содержимое услуги. Параметр используется для выбора надлежащей схемы (модуляции / кодирования) передачи данных по сети радиодоступа.
8. Остаточный коэффициент ошибок, отражающий число ошибочно переданных бит в доставленных пакетах данных, переносящих содержимое услуги. Также используется для выбора надлежащей схемы (модуляции / кодирования) передачи данных по сети радиодоступа.
9. Возможность доставки искажённых пакетов данных, переносящих содержимое услуги (Да/Нет). Параметр используется при принятии решений о пересылке искажённых пакетов данных.
10. Задержка передачи (в мс) определяет допустимое отклонение значения задержки в сети радиодоступа от общего времени задержки в сквозном канале среди 95% значений задержек доставленных пакетов данных в течение времени существования всей услуги.
11. Приоритет в управлении трафиком отражает относительную важность рассматриваемого потока данных по сравнению с другими потоками. Параметр применяется к услугам интерактивного класса, позволяя вести диспетчеризацию трафика.
12. Назначение/снятие приоритета. Используется для выявления приоритетных различий между каналами передачи услуг, когда выполняются операции по назначению и снятию каналов в условиях ограниченности ресурсов.
13. Статистический дескриптор источника (речевой/неизвестный). Разговорная речь имеет хорошо известные статистические параметры. Поэтому, в целях информирования о том, что пакеты данных имеют речевую природу, этот факт может быть экспериментально (на основе подсчёта) обнаружен в различных точках.
14. Индикатор служебной информации (Да/Нет), определённые только для услуг интерактивного класса, показывает природу информации (служебная или пользовательская) в принятых пакетах. Если индикатор установлен в значение `Да’, то ПТ должен установить в `1′ приоритет управления трафиком. Данный параметр является дополнительным в системе качества обслуживания.
15. Выделенное назначение/снятие приоритета — «усиленный» параметр назначения/снятия приоритета, содержащий увеличенный диапазон уровней приоритета, а также дополнительную информацию о возможности преимущественного занятия канала и преимущественной степени защищённости.
В таблице 3.1 указаны диапазоны значений некоторых параметров QoS для различных классов услуг.
Таблица 3.1 – Диапазоны значений параметров QoS для различных классов услуг.
Параметр QoS | Голосовой класс | Потоковый класс | Интерактивный класс | Фоновый класс |
Максимальная скорость пере- дачи (Кбит/с) | 256 000 | 256 000 | 256 00 | 256 000 |
Гарантирован- ная скорость передачи (Кбит/с) | 256 000 | 256 000 | ||
Порядок дос- тавки | Да /Нет | Да /Нет | Да /Нет | Да /Нет |
Максимальный размер (в байтах) пакетов данных | 1 500 или 1 502 | 1 500 или 1 502 | 1 500 или 1 502 | 1 500 или 1 502 |
Возможность доставки искажённых пакетов данных | Да /Нет | Да /Нет | Да /Нет | Да /Нет |
Остаточный коэффициент ошибок | 5·10-2, 10-2, 5·10-3, 10-3, 10-4, 10-5, 10-6 | 5·10-2, 10-2, 5·10-3, 10-3, 10-4, 10-5, 10-6 | 4·10-3, 10-5, 4·10-8 | 4·10-3, 10-5, 4·10-8 |
Задержка передачи (мс) | 100 –макс. значение | 300 –макс. значение | ||
Приоритет в управлении трафиком | 1, 2, 3 | |||
Назначение / снятие приори- тета | 1, 2, 3 | 1, 2, 3 | 1, 2, 3 | 1, 2, 3 |
Статистический дескриптор источника | Речевой / неизвестный | Речевой / неизвестный | Речевой / неизвестный | Речевой / неизвестный |
Индикатор служебной информации | Да/Нет | |||
Выделенное назначе- ние / снятие приоритета: | ||||
· уровень при- оритета; | 1…15 | 1…15 | 1…15 | 1…15 |
· преимущест- венное занятие канала; | Да /Нет | Да /Нет | Да /Нет | Да /Нет |
· преимущест- венная степень защищённости | Да /Нет | Да /Нет | Да /Нет | Да /Нет |
Практика по mf классификации
Схема та же: 
Это прекрасно внутри DS-домена, но неприемлемо в точке входа.
А давайте теперь не будем слепо доверять? На Linkmeup_R2 ICMP будем метить как EF (исключительно для примера), TCP как AF12, а всё остальное CS0.
Это будет MF (Multi-Field) классификация.
- Процедура та же, но теперь матчить будем по ACL, которые выцепляют нужные категории трафика, поэтому сначала создаём их. На Linkmeup_R2:
ip access-list extended TRISOLARANS_ICMP_ACL permit icmp any any ip access-list extended TRISOLARANS_TCP_ACL permit tcp any any ip access-list extended TRISOLARANS_OTHER_ACL permit ip any any - Далее определяем классификаторы:
class-map match-all TRISOLARANS_TCP_CM match access-group name TRISOLARANS_TCP_ACL class-map match-all TRISOLARANS_OTHER_CM match access-group name TRISOLARANS_OTHER_ACL class-map match-all TRISOLARANS_ICMP_CM match access-group name TRISOLARANS_ICMP_ACL - А теперь определяем правила перемаркировки в политике:
policy-map TRISOLARANS_ADMISSION_CONTROL class TRISOLARANS_ICMP_CM set ip dscp ef class TRISOLARANS_TCP_CM set ip dscp af11 class TRISOLARANS_OTHER_CM set ip dscp default - И вешаем политику на интерфейс. На input, соответственно, потому что решение нужно принять на входе в сеть.
interface Ethernet0/1 service-policy input TRISOLARANS_ADMISSION_CONTROL
ICMP-тест с конечного хоста Trisolaran1. Никак сознательно не указываем класс — по умолчанию 0. Политику с Linkmeup_R1 я уже убрал, поэтому трафик приходит с маркировкой CS0, а не CS7.
Linkmeup_R1. E0/0.
pcapng
Linkmeup_R2. E0/0.
pcapng
Видно, что после классификаторов и перемаркировки на Linkmeup_R2 на ICMP-пакетах не только DSCP поменялся на EF, но и MPLS Traffic Class стал равным 5.
Аналогичный тест с telnet 172.16.2.2. 80 — так проверим TCP: 
Linkmeup_R1. E0/0.
pcapng
Linkmeup_R2. E0/0.
pcapng
ЧИТО — Что И Требовалось Ожидать. TCP передаётся как AF11.
Следующим тестом проверим UDP, который должен попасть в CS0 согласно нашим классификаторам. Для этого воспользуемся iperf (привезти его в Linux Tiny Core изи через Apps). На удалённой стороне iperf3 -s — запускаем сервер, на локальной iperf3 -c -u -t1 — клиент (-c), протокол UDP (-u), тест в течение 1 секунды (-t1). 
Linkmeup_R1. E0/0.
pcapng
Linkmeup_R2. E0/0
pcapng
С этого момента всё, что приходит в этот интерфейс, будет классифицировано согласно настроенным правилам.