Автор: Захватов Михаил
Оригинал: www.mpls-exp.ru/ispqoscisco.html

Качество обслуживания в операторских сетях

В этом документе даются основные рекомендации и приводятся примеры настройки параметров качества обслуживания (QoS) в операторских сетях. Основная цель данного руководства заключается в обеспечении соответствия операторского QoS требованиям корпоративных заказчиков и в предоставлении операторам рекомендаций по настройке их пограничного и магистрального оборудования для обеспечения этих требований.



Понятие качества обслуживания (QoS)

Качество обслуживания определяется как мера производительности передающей системы, отражающая качество передачи и доступность услуг. Доступность услуг является важнейшим элементом QoS. Для успешного внедрения QoS необходимо обеспечить максимально высокую доступность сетевой инфраструктуры. (Конечной цели высокой доступности соответствует уровень 99,999 процентов, то есть только 5 минут простоя в год). Качество передачи сети определяется следующими факторами:
Доступность - Диапазон времени сетевой достижимости между входной и выходной точкой сети - это сетевая доступность. Доступность сервиса - это диапазон времени, в течение которого этот сервис доступен между определенными входной и выходной точками с параметрами, оговоренными в соглашении об уровне обслуживании (SLA).
Потери -это отношение правильно принятых пакетов к общему количеству пакетов, которые были переданы по сети. Потери выражаются в процентах отброшенных пакетов, которые не были доставлены по назначению. Обычно, потери - это функция от доступности. Если сеть не загружена, то потери (во время отсутствия перегрузок) будут равны нулю. Во время перегрузок, однако, механизмы QoS будут определять, какие пакеты могут быть сброшены.
Задержка - это время, которое требуется пакету для того, чтобы после передачи дойти до пункта назначения. В случае голоса, эта задержка определяется как время прохождения сигнала от говорящего к слушающему.
Колебания задержки (jitter) -это разница между сквозным временем задержки, которая возникает при передаче по сети разных пакетов. Так, например, если для передачи одного пакета по сети требуется 100 мсек, а для передачи следующего пакета - 125 мсек, то колебание задержки составит 25 мсек.
У каждого терминала VoIP (голос поверх IP) или "видео поверх IP" имеется буфер колебаний задержки (jitter buffer). Этот буфер используется для выравнивая колебаний задержки голосовых пакетов. Буфер колебаний задержки может быть динамическим и адаптивным и может регулировать время задержки пакетов в пределах 30 мсек. Если колебания задержки будут превышать возможности буфера, то он будет работать с недогрузкой (under-run) или перегрузкой (over-run). И то и другое оказывает отрицательное влияние на качество связи.
Пропускная способность - это доступная пользователю полоса пропускания между двумя точками присутствия оператора.

Инструменты классификации и маркировки пакетов

Для любого правила QoS нужно прежде всего определить трафик, имеющий особые требования. Инструмент классификации помечает пакет или фрейм определенным значением. Эти значения меток позволяют разграничить разные типы трафика и применить к ним разные правила обработки очередей (CBWFQ, MDRR и т.д.). Классификация и маркировка производится на основе анализа следующих параметров:
Только после полной идентификации трафика к нему можно применять QoS правила (policies). Рекомендуется идентифицировать и помечать трафик (с помощью DSCP) как можно ближе к источнику. Периферийная часть сети, где происходит прием (или отклонение) классификации пакетов, называется "границей доверия" (trust boundary). Если метки проставлены правильно, то промежуточным участкам сети не приходится повторно идентифицировать трафик. На этих участках просто выполняются правила QoS, определенные проставленными ранее метками DSCP. Такой подход упрощает сетевое управление и сокращает нагрузку на процессоры.
Классификация должна производиться на сетевой периферии, обычно на оборудовании в распределительных шкафах, на IP-телефонах или на других терминалах голосовой связи. Однако, не рекомендуется доверять маркировке сделанной приложениями на персональных компьютерах, так как возможны злоупотребления со стороны пользователей. Классификация осуществляется с помощью списков доступа (ACL), DSCP или MPLS EXP.
Для маркировки трафика могут использоваться следующие механизмы:
Многие корпоративные пользователи считают, что IPP маркировка очень ограничена и не позволяет иметь большое число классов сервиса. В этом случае применяется 6-битная модель маркировки DSCP (64 значения).

Инструменты планировки

Инструментами планировки (scheduling) называются средства, которые определяют, как фрейм или пакет будет выходить из сетевого узла. В любом случае, когда пакеты входят в устройство быстрее, чем выходят из него (т.е. в случае несовпадения скоростей на входе и выходе) возникает "точка переполнения" или "узкое место". У сетевых устройств имеются буфера, которые позволяют приоритетным пакетам поступать на выход быстрее, чем не приоритетным. Этот подход называется "очередностью" (queuing).
Алгоритмы очередности начинают работать только в моменты переполнения и отключаются после того, как переполнение исчезает. Буфера очередей имеют ограниченную емкость и похожи на воронки с широким входом и узким выходом. Если вы будете постоянно наливать в воронку больше воды, чем из нее вытекает, воронка переполнится. Когда переполняется буфер очереди, входящие пакеты начинают отбрасываться либо в общем порядке (tail-drop), либо избирательно. Избирательное отбрасывание пакетов до полного заполнения буфера называется технологией предотвращения переполнения (congestion avoidance).
Механизмы предотвращения переполнения лучше всего работают с приложениями TCP, поскольку в случае отбрасывания пакетов механизмы TCP начинают автоматически снижать скорость передачи до приемлемого уровня. Механизмы предотвращения переполнения хорошо сочетаются с алгоритмами буферизации. Алгоритмы буферизации управляют "головой" очереди, а механизмы борьбы с переполнением управляют ее "хвостом" и тем самым косвенно помогают указанным алгоритмам справляться со своими задачами.
Инструменты планировки включают в себя:

Канальные механизмы

Категория канальных механизмов включает:
Средства ограничения скорости (Policing) и выравнивания трафика (Shaping)-Как средства полисинга, так и средства выравнивания трафика обычно идентифицируют нарушения идентично. Их главное отличие заключается в том, как они реагируют на эти нарушения. Средства ограничения скорости (policer) обычно сбрасывают трафик. Средство выравнивания трафика обычно задерживает избыточный трафик в буфере, используя буфер для хранения пакетов и выравнивания потока в случае всплесков трафика.
Фрагментация и чередование пакетов (Link Fragmentation and Interleaving)-В случае применения низкоскоростных каналов для передачи больших пакетов в канал требуется значительно время. Эту задержку называют задержкой сериализации и она может привести к тому, что для голосовых пакетов будет превышено значение порога задержки и/или колебаний задержки (jitter). Существует два основных инструмента сокращения задержки на низкоскоростных каналах: фрагментация и чередование пакетов для многоканального PPP (Link-Fragmentation and Interleaving for Multilink Point-to-Point Protocol) и Frame Relay фрагментация (FRF.12).
Механизмы компрессии-Технологии компрессии, такие как Compressed Real-Time Protocol (cRTP), минимизируют требования по полосе пропускания и чрезвычайно эффективны на низкоскоростных каналах. Заголовок IP пакета в 40 байт может составить практически две трети всего пакета. Для того, чтобы избежать неэффективного использования доступной полосы пропускания канала применяется механизм cRTP (он работает не глобально, а на отдельном канале - точка-точка). Применение cRTP позволяет сократить IP/UDP/RTP заголовок с 40 до 2-5 байт.
Настройка буфера TX Ring-Тransmit (TX) ring - это последняя FIFO очередь, в которой находятся фреймы перед их отправкой на физический интерфейс. Цель этого буфера в том, чтобы гарантировать наличие готового к передаче фрейма на тот момент, когда интерфейс будет готов принять трафик и, таким образом, добиться 100 процентной утилизации канала. Размер TX Ring буфера зависит от модели маршрутизатора, программного обеспечения, среды второго уровня и механизма буферизации сконфигурированного на интерфейсе. Существует рекомендация устанавливать размер TX Ring буфера в значение 3 на низкоскоростных интерфейсах.

Требования к качеству обслуживания корпоративных пользователей и "Базовые Основы QoS"

При проектировании сети операторы должны учитывать требования к качеству обслуживания, предъявляемые корпоративными клиентами. Общая проблема операторов и корпоративных клиентов заключается в богатстве QoS функциональности Cisco IOS и, как следствие, мириады вариантов реализации и комбинаций. Практически каждый опытный инженер имеет свой собственный, слегка отличный взгляд на их применение. Для того, чтобы дать некоторые общие рекомендации по реализации качества обслуживания, Cisco воплотила новую инициативу, под названием "Базовые Основы QoS", целью которой является унификация решений на платформах оборудования Cisco.  В "Базовых Основах QoS" специфицирована маркировка и правила обработки до 11 классов сервиса в корпоративных сетях. Более подробно они описаны в последующих разделах. Важно отметить, что "Базовые Основы QoS" не диктуют каждому корпоративному клиенту немедленно внедрить 11 классов трафика, а скорее учитывают существующие и будущие потребности в поддержке QoS. Даже если корпоративному клиенту сейчас нужна только часть из этих 11 классов, то следование рекомендациям "Базовых Основ QoS" позволит им в будущем плавно мигрировать на расширение количества поддерживаемых классов в будущем.
Сводная таблица промежуточного варианта "Базовых Основ QoS" по маркировке трафика представлена в таблице.


Приложение
Классификация L3
Классификация
L2 CoS/MPLS-exp
IPP
PHP
DSCP
Маршрутная информация
6
CS6
48
6
Голос
5
EF
46
5
Интерактивное видео
4
AF41
34
4
Потоковое видео
4
CS4
32
4
Данные чувствительные к потерям
3
-
25
3
Сигнализация звонков
3
AF31/CS3
26/24
3
Транзакционные данные
2
AF21
18
2
Сетевое управление
2
CS2
16
2
Объемный класс 1
AF11
10
1
Интернет/Scavenger 1
CS1
8
1
Все остальное
0
0
0
0


Примечание N1: В "Базовых Основах QoS" рекомендуется маркировать голосовую сигнализацию с помощью CS3. Однако в настоящий момент, Cisco IP телефоны маркируют сигнализацию как AF31. Миграция от AF31 к CS3 уже запланирована, но как временное решение рекомендуется зарезервировать AF31 и CS3 для сигнализации и использовать DSCP 25 для локальных критичных приложений данных. По завершении миграции следует применять рекомендации "Базовых Основ QoS" по маркировке сигнализации с помощью CS3 и локальных критичных приложений с помощью AF31. Эти рекомендации по маркировке более соответствуют RFC2597 и RFC2474.

Примечание N2: Вторая версия AutoQoS будет автоматически конфигурировать QoS для голоса, видео и данных. Cisco AutoQoS Enterprise будет определять и конфигурировать до 10 классов трафика на основании модели отображенной выше. (Единственный класс, который не будет конфигурироваться автоматически - это локальные критичные данные, так как этот класс требует осведомленности о бизнес процессах, что находится за пределами возможностей AutoQoS). AutoQoS Enterprise предназначен для автоматизации и упрощения проектирования сети в соответствии с "Базовыми Основами QoS". Хотя AutoQoS и не имеет отношения к операторской сети, для оператора важно понимать его влияние на корпоративные сети. По мере распространения AutoQoS в корпоративных сетях все большее значение будет получать поддержка QoS в операторских сетях.

Требования к качеству обслуживания для голоса

Определяя требования QoS корпоративного VoIP трафика рекомендуется придерживаться следующих правил:
  1. Голосовой трафик должен быть промаркирован как DSCP EF, в соответствии с "Базовыми Основами QoS" и RFC 3246.
  2. Сигнализация должна быть промаркирована как CS3, в соответствии с "Базовыми Основами QoS" (во время миграции можно использовать AF31).
  3. Потери пакетов в магистралях спроектированных для предоставления VoIP сервиса высокого качества не должны превышать 0.25 процентов.
  4. Односторонняя задержка не должна превышать 150ms, в соответствии со International Telecommunication Union (ITU) G.114.
  5. Колебания задержки (jitter) должны быть менее 10 мсек. Максимальный jitter должен быть менее чем бюджет по задержке в сети минус минимальная сетевая задержка. Это типовое значение колебания задержки для VoIP обусловлено бюджетом по задержке, так называемым mouth-to-ear, в 100 мсек. (Это достаточно консервативный бюджет по сравнению с G.114, в котором рекомендуется jitter менее 150 мсек). Из этого значения мы вычитаем время распространения по магистрали (30 мсек) и задержку кодека (35 мсек), что дает нам бюджет для jitter в 35 мсек. Эти 35 мсек разбиваются на 30 мсек на доступе (15 мсек вход/выход) и 5 мсек на магистрали. То есть в худшем варианте, для адаптивных jitter-буферов, колебания задержки должны быть менее 10 мсек.
  6. Для каждого разговора (в зависимости от частоты квантирования, кодека и заголовка второго уровня) требуется 21-106 kbps гарантированной приоритетной полосы пропускания.
  7. Для трафика сигнализации требуется 150 bps (плюс заголовок второго уровня) гарантированной полосы пропускания.
На качество голосовой связи напрямую влияют все три фактора качества QoS: потери пакетов, задержка и вариации задержки.
  1. Потери пакетов вызывают кратковременные пробелы в разговоре. Стандартные алгоритмы кодирования используемые в Cisco Digital Signal Processor (DSP) с помощью алгоритмов маскирования могут восстановить потери до 30 мсек. Таким образом, потери двух и более последовательных 20 мсек сэмплов приведут к заметной деградации качества голоса. Предположив случайное распределение сбросов пакетов в одном речевом потоке, сброс 1-го процента в голосовом потоке привела бы в среднем к потери, которую нельзя было бы восстановить каждые 3 минуты. Аналогично, уровень сброса 0,25 процента привел бы в среднем к потери, которую нельзя было бы восстановить каждые 53 минуты.
  2. Задержка более 200 мсек может вызвать деградацию качества голосовой связи. Если общая задержка в канале становится слишком большой, разговор по телефону начинает напоминать переговоры по спутниковому каналу связи или по симплексному радиоканалу. В стандарте Международного Союза Электросвязи для технологии VoIP (G.114) говорится, что задержка величиной в 150 мсек в одном направлении является приемлемой для качество голосовой связи. Было продемонстрировано, что разница в качестве голоса между сетями с задержкой в 150 мсек и 200 мсек является незначительной и практически незаметной для пользователя. Cisco рекомендует ориентироваться на ITU стандарт 150 мсек, но если существуют ограничения не позволяющие добиться такого бюджета, то размер задержки может быть увеличен до 200 мсек без значительной деградации качества связи.
  3. Что же касается колебаний задержки, то для их выравнивания в устройствах Cisco для IP-телефонии используются адаптивные буферы. Однако они могут компенсировать колебания задержки лишь в пределах от 20 до 50 мсек. При централизованной обработке вызовов IP-телефоны используют контрольные каналы TCP для связи с Cisco CallManager. Если эти весьма небольшие каналы не получат достаточной полосы пропускания, качество обслуживания абонентов будет ухудшаться. Давайте для примера рассмотрим время, которое проходит с момента поднятия трубки до момента, когда абонент слышит гудок. Когда абонент поднимает трубку IP-телефона, телефон "спрашивает" CallManager, что делать дальше. CallManager, в свою очередь, говорит IP-телефону, чтобы тот начал воспроизведение гудка в поднятой трубке. Если контрольный трафик будет потерян или задержан в сети, пользователь не услышит гудка и решит, что телефон не работает. Та же логика применима к любому сигнальному трафику, которым обмениваются шлюзы и телефоны.

Выделение полосы пропускания для голоса и видео

И операторы и их заказчики должны обеспечивать требуемую полосу пропускания для приложений голоса и видео, чтобы гарантировать присутствие требуемых ресурсов на сети. Операторы должны также обеспечивать и требуемые параметры задержки для VoIP пакетов в случае возникновения перегрузок в сети.
Операторы должны гарантировать соответствующую полосу пропускания для VoIP приложений корпоративных клиентов. Планирование должно быть достаточно точным и учитывать несколько факторов. Лимитирующим фактором для выделения процента общей полосы пропускания являются параметры задержки и колебаний задержки, а также общей пропускной способности последней мили. Трафик попадающий в приоритетные очереди (LLQ или PQ) подвергается задержке вследствие уровня утилизации канала и задержки сериализации одного VoIP пакета. Максимальный процент VoIP трафика на конкретном канале между оператором и клиентом зависит от:

Требования к качеству обслуживания для Видео

Существует два основных типа видео приложений: Интерактивное видео (например видео конференции) и Потоковое видео (например IP/TV, которое может использовать как одно-так и многоадресную рассылку).

Настройки для трафика интерактивного видео

При настройке интерактивного видео (видео конференций) рекомендуется следующее:
Так как видео конференция включает аудио кодек G.711 для речи, то у нее и соответствующие голосовому трафику требования к потерям, задержке и колебаниям задержки. Однако трафик видео конференции радикально отличается от трафика голоса. Например, трафик видео конференций использует переменные размеры пакетов и переменные скорости передачи пакетов. Скорость видео конференции - это скорость сэмплирования видео потока, но не реальная полоса пропускания, которую требует видео вызов. Иными словами, полезная нагрузка пакетов видео конференции заполняется 384 kbps потока видео сэмплов. IP, UDP и RTP заголовки (40 байт на пакет) должны быть дополнительно включены в требования по полосе пропускания (также как и заголовки второго уровня). Так как используются переменные размеры пакетов и скорости генерации пакетов, то достаточно трудно точно подсчитать абсолютное значение накладных расходов. Тестирование, однако, показало, что для расчета можно использовать скорость видео конференции плюс 20 процентов. Замечание: Алгоритм LLQ Cisco по умолчанию поддерживает всплески до 200 мсек трафика. Тестирование показало, что этой настройки достаточно для видео конференций. Для поддержки большего количества потоков можно по потребности увеличить этот параметр.

Настройки для трафика потокового видео

При настройке потокового видео рекомендуется следующее:

Требования к качеству обслуживания для трафика данных

Определяя требования QoS для данных, нужно принимать во внимание следующие факторы:
Используйте не более четырех основных классов трафика, такие как
Локально-определенный Критический класс трафика данных
Локально-определенный Критический класс трафика данных - это возможно самый недопонимаемый класс трафика в "Базовых основах QoS". В соответствии с моделью "Базовых основ QoS" все классы трафика (за исключением Интренет/scavenger и Best-Effort) рассматриваются как критические для корпоративного клиента. Термин локально-определенный используется, чтобы подчеркнуть назначение этого класса - то есть иметь высший класс сервиса для каждого клиента для избранного набора их интерактивных и транзакционных приложений, имеющий для них наибольший бизнес-приоритет. Например, компания может настроить Oracle, SAP, BEA и DLSw+, как транзакционный/интерактивный класс. Однако, большая часть их доходов зависит от SAP, и тогда они могут захотеть дать этому транзакционному приложению еще более высокий уровень приоритета, назначив его в выделенный класс (такой как локально-определенный критический класс). Так как критерий назначения такого класса не технический (а определяется бизнес требованиями и целями организации), решение о том, какие приложения должны попасть в этот специальный класс могут быть решены только организационно. В этот класс рекомендуется назначать как можно меньшее количество приложений.
Транзакционный/Интерактивный класс данных
Транзакционный/Интерактивный класс - это комбинация двух схожих типов приложений: транзакционных приложений клиент-сервер и приложений интерактивных сообщений. Требования по времени отклика отличают транзакционные от обычных клиент-серверных приложений. В случает транзакционных клиент-серверных приложений (таких как SAP, PeopleSoft и DLSw+) пользователь вынужден ожидать завершения операции. E-mail - это не транзакционное приложение, так как большинство операций происходит в фоновом режиме и пользователи, обычно, не замечают задержек в несколько сот миллисекунд. Замечание: по умолчанию, DLSw+ помечает свой IP трафик IPP 5, что конфликтует с VoIP. Таким образом, рекомендуется перемаркировать трафик DLSw+.
Объемный класс данных (Bulk)
Класс данных Объемный предназначен для не интерактивных приложений не критичных к потерям пакетов, обычно работающих в фоновом режиме. Такие приложения включают: FTP, e-mail, backup, синхронизация и репликация баз данных, распространение видео содержания или другие типы приложений, в которых пользователь не вынужден ждать результатов выполнения операций. Преимущество выделения полосы пропускания для Объемного класса трафика (вместо накладывания на них ограничений) заключается в том, что приложения могут динамически использовать свободную полосу пропускания и, таким образом, повышать свою производительность в спокойные периоды времени, что, в свою очередь, снижает вероятность влияния на них перегрузок.
Класс По возможности (Best Effort)
Класс По возможности - это класс по умолчанию для всего трафика данных. Только в том случае, если приложение было отобрано для особенной обработки, оно будет удалено из класса по умолчанию. Так как многие корпоративные клиенты используют сотни, если не тысячи, приложений данных в своих сетях (большинство из которых и останется в этом классе) требуется выделить адекватную полосу пропускания для класса по умолчанию. В противном случае, приложения, которые попали в этот класс, будут подавлены. Рекомендуется выделять по крайней мере 25 процентов полосы пропускания для поддержки класса трафика По возможности.
Интернет/Scavenger Класс
Интернет/Scavenger Класс предназначен для предоставления определенным приложениям дифференцированных услуг или услуг по остаточному принципу. Эти приложения, как правило, не имеют прямого отношения к основному бизнесу компании и обычно ориентированы на развлечение. Они включают: приложения однорангового медиа-обмена (KaZaa, Morpheus, Groekster, Napster, iMesh, и т.д.), игровые приложения (Doom, Quake, Unreal Tournament, и т.д.), и развлекательные видео приложения. Это типичный класс определенный для корпоративного клиента, но обычно перемаркируемый на класс Best Effort на границе сети оператора. Назначение минимальных гарантий по полосе пропускания этому классу означает, что в моменты перегрузок он практически не получает никаких ресурсов, но может использовать свободную полосу в спокойные периоды.
Классы Маршрутизации и Сетевого управления
Некоторые клиенты предпочитают в явном виде гарантировать минимальную полосу пропускания для протоколов маршрутизации и приложений сетевого управления (SNMP, NTP, Syslog или NFS). Замечание: Важно отметить, что протоколы внутренней маршрутизации, такие как RIP и EIGRP, обычно не требуют выделения специальной полосы пропускания. Это преимущество использования внутреннего механизма Cisco - PAK_PRIORITY. В OSPF только пакеты hello маркируются с помощью PAK_PRIORITY. В BGP (хотя он и раскрашен IPP6/CS6) также могут потребоваться специальные настройки. Информация по PAK_PRIORITY.

Влияние полно-связности сетей MPLS VPN на QoS

Из-за дороговизны, недостатков масштабируемости и ограниченной управляемости полно-связные топологии редко встречаются в традиционных дизайнах. Напротив, большинство дизайнов второго уровня построены по принципу hub-and-spoke используя либо централизованный хаб или более эффективный дизайн с региональными хабами. При таком дизайне QoS обычно настраивается и администрируется клиентом на центральном узле. До тех пор пока оператор обеспечивает контрактный уровень обслуживания, фреймы или ячейки на удаленных узлах соответствуют политике центрального узла (иногда называемого WAN агрегатором). WAN агрегатор контролирует не трафик только в направлении от центра к филиалу, но и от филиала к филиалу, как показано на рисунке N1.

Рисунок N1. Администрирование QoS при традиционном Hub-and-Spoke WAN дизайне (контролируется клиентом).
Однако, с внедрением услуги MPLS VPN, которая по природе своей предлагает полную связность, решение по обеспечению QoS видоизменяется. При полно-связном дизайне центральный маршрутизатор продолжает администрировать QoS для всего трафика от центра к филиалам, но более не контролирует QoS для трафика от филиала к филиалу. Может показаться, что единственное изменение касается настройки QoS на всех филиальных маршрутизаторах, но это не так, так как решает только часть задачи. Например, рассмотрим пример настройки видео конференции каждый с каждым. Как и в случае традиционного дизайна второго уровня требуется настройка на WAN агрегаторе политики приоритезации IP/VC трафика. Затем клиент должен соответствующим образом настроить и филиальные маршрутизаторы. Таким образом, любые видео вызовы из центра в филиалы и между филиалами защищены по отношению к менее важному трафику между теми же точками. Сложность полно-связной модели появляется в случае принятия во внимание того факта, что конкурирующий трафик может теперь не всегда приходить с того же сайта, а может приходить c любого. Более того, теперь клиент не контролирует QoS трафика между филиалами, так как теперь он не проходит через центральный хаб. Продолжая пример, если видео конференция работает между двумя филиалами и пользователь одного из филиалов начинает большую FTP загрузку файла с центрального узла, то появляется потенциальная возможность возникновения перегрузки PE-CE канала со стороны облака полно-связной MPLS VPN. Это может привести к ухудшению качества видео конференции. Единственное решение в этом сценарии - это необходимость для оператора сконфигурировать QoS на всех РЕ, к которым подключены филиалы, в соответствии с политикой клиента. Иными словами, операторы и их клиенты должны согласовывать политику QoS в MPLS VPN, как это показано на рисунке N2.

Рисунок N2. Администрирование QoS в полно-связном MPLS VPN дизайне (QoS администрируется совместно оператором и клиентом).

Руководство по сокращению классов обслуживания в корпоративных сетях

Несмотря на принятие Cisco инициативы "Базовых основ QoS" и наличие инструментов типа Cisco AutoQoS Enterprise для упрощения и ускорения внедрения комплексных моделей QoS в корпоративных сетях, на сегодняшний момент не многие компании используют большое количество классов трафика. Поэтому большинство операторов предлагают ограниченное количество классов при предоставлении услуги MPLS VPN. Со временем, это может привести к необходимости сокращения в корпоративных сетях количества поддерживаемых классов для интеграции с моделями QoS операторов. Вопросы, рассматриваемые в этом разделе, должны быть учтены в процессе выбора стратегии по сокращению числа классов и интеграции классов клиента с классами поддерживаемыми в сети оператора.

Вопросы сериализации

Что касается сериализации, необходимо учитывать следующие аспекты.
Голос и Видео
Обычно, операторы предлагают только один класс сервиса "реального времени" или "приоритетный" класс. Если заказчик хочет использовать в своей MPLS VPN и голос и интерактивное видео (каждый из которых рекомендуется назначать в класс строгой приоритетности), то перед ним может встать проблема выбора. Какой трафик должен быть назначен в класс "реального времени"? Существуют ли какие либо последствия назначения обоих типов трафика в один класс "реального времени"? Голос и Видео никогда не должны быть назначены в одну и ту же очередь низкой задержки на каналах, скорость которых менее 768kbps, то есть где присутствует фактов сериализации. Пакеты в LLQ очереди обычно не фрагментируются и, таким образом, большие пакеты IP/VC могут привести к значительным задержкам VoIP пакетов. Альтернативным решением может быть назначение IP/VC в менее приоритетный класс, что приведет не только к очевидной деградации качества (более низкий уровень сервиса), но также может быть подвержено влиянию смешивания разнородного трафика. Это описано в разделе "Смешивание TCP и UDP".
Сигнализация голосовых вызовов
VoIP требует конфигурирования не только трафика RTP полезной нагрузки, но также и сигнального или трафика управления вызовами. Этот трафик незначителен и требует малую гарантированную полосу пропускания. Так как уровень сервиса, c которым работает телефонная сигнализация, определяет время задержки выдачи в телефонную трубку тона приглашения к набору, то этот уровень становится важен с точки зрения ожиданий конечного абонента. Операторы не всегда могут предоставить подходящий класс сервиса только для трафика сигнализации, что приводит к вопросу - с какими другими классами трафика можно смешивать трафик сигнализации? На каналах где не значителен эффект сериализации (то есть более 768kbps), сигнализация может быть отнесена к классу реального времени, вместе с голосом. Этого не рекомендуется делать на более низкоскоростных каналах. Вместо этого, сигнализация должна быть назначена в один из приоритетных классов данных, для которых оператор дает гарантии по полосе пропускания. Важно понимать, что гарантии оператора на определенный класс, не означают гарантий по полосе пропускания для конкретного приложения.

Смешение TCP и UDP

Рекомендуется не смешивать TCP трафик и трафик UDP (особенно потоковое видео) в одном и том же операторском классе из-за различного поведения этих протоколов в моменты возникновения перегрузок. В частности, TCP начнет тормозить потоки в том случае, если будут обнаружены потери пакетов. Не смотря на то, что некоторые UDP приложения используют окна, управление потоком и возможности перепосылки, в большинстве своем, UDP передатчики нечувствительны к потерям пакетов и не снижают скорость передачи. В случае объединения TCP и UDP потоков в одном классе, и в случае если в этом классе возникает перегрузка, то TCP потоки начнут последовательно снижать скорость, потенциально отдавая свою полосу пропускания UDP потокам, нечувствительным к потерям. Этот эффект называется TCP-starvation/UDP-dominance (Доминация UDP/Истощение TCP)
Даже если для этого класса включен алгоритм WRED, будет наблюдаться то же явление. Это объясняется тем, что WRED (в большинстве своем) влияет только на TCP потоки. Конечно, не всегда представляется возможным разделить TCP потоки от UDP потоков, но необходимо осознавать последствия такого смешения.

Рекомендации по маркировке

Операторы используют атрибуты маркирования третьего уровня (IPP или DSCP) для определения какому операторскому классу сервиса следует назначить этот пакет. Следовательно, клиенты для достижения соответствующего уровня сервиса должны маркировать/перемаркировать трафик в соответствии политикой операторской сети. Дополнительно, оператор может перемаркировать трафик вне контракта в пределах своего облака, что может повлиять на клиентский трафик и требует последовательной политики сквозной маркировки. Следующие вопросы должны быть учтены при определении стратегии маркировки/перемаркировки на границе клиент-оператор.
Перемаркировка клиент-оператор
Общее правило маркировки в корпоративных сетях заключается в маркировке трафика и установке границ доверия как можно ближе к источнику, насколько это возможно административно и технически. IP телефоны, например, маркируют голосовой трафик DSCP EF (46), и существующие руководства по дизайн рекомендуют доверять этой маркировке. Однако рекомендуется не доверять маркировке установленной на хостах пользователей (так как здесь возможны злоупотребления). Определенные типы трафика, возможно, нужно перемаркировать еще до передачи на пограничные устройства оператора для получения доступа к определенному классу. Если требуется такая перемаркировка, то рекомендуется производить ее на исходящем CE маршрутизаторе, а не в кампусной сети. Это связано с тем, что набор предлагаемых оператором сервисов скорее всего изменится или расширится со временем, а производить перенастройку проще, если она производится только на CE границе. Могут существовать классы, где множество типов трафика требуется пометить одинаковыми значениями для получения доступа к определенным очередям. Например, на высокоскоростных каналах может потребоваться передавать голос, интерактивное видео и сигнализацию в операторском классе реального времени. Если в операторский класс реального времени направляются только пакеты промаркированные DSCP EF и CS5, то это означает, что три этих приложения должны использовать один и тот же код приоритета DSCP. Пример конфигурации далее демонстрирует, как это может быть сделано с помощью маркирования классов (в этом примере и интерактивное видео и сигнализация используют DSCP CS5).

class-map match-any VOICE match ip dscp ef class-map match-all INTERACTIVE-VIDEO match ip dscp af41 class-map match-any CALL-SIGNALING match ip dscp af31 match ip dscp cs3

policy-map CE-EGRESS-EDGE class VOICE
priority percent 18
class INTERACTIVE-VIDEO
priority percent 15
set ip dscp cs5 class CALL-SIGNALING
priority percent 2
set ip dscp cs5
interface Serial1/0
service-policy output CE-EGRESS-EDGE
Перемаркировка оператор-клиент
Операторы могут перемаркировать трафик на третьем уровне для отображения того факта, что определенные потоки поступили с превышением контрактных обязательств. Это делается в соответствии со стандартами DiffServ, в частности RFC 2597. Однако некоторым клиентам, для целей управления и сбора статистики, требуется последовательная сквозная маркировка. В таких случаях клиенту может потребоваться перемаркировка трафика полученного из операторской сети (во входящем направлении на клиентском СЕ маршрутизаторе). В этом случае может использоваться маркировка по классам (class-based marking), так как она поддерживает списки доступа для классификации пакетов, а также NBAR (распознавание на уровне приложений). Продолжая и расширяя предыдущий пример, клиент захотел восстановить первоначальное значение маркировки для интерактивного видео и голосовой сигнализации. Дополнительно они хотят восстановить первоначальную маркировку для трафика Oracle (который они изначально пометили DSCP 25 используя TCP Port 9000) и трафика DLSw+ (изначально помеченный AF21). Трафик этих приложений они передали в сеть оператора с маркировкой AF21, но возможно в операторской сети он был перемаркирован в AF22. Фрагмент такой конфигурации показан ниже. Используемый критерий "match-all" в карте класса (class-map) выполняет операцию логического "И" между потенциальными маркировками и перемаркировками и списком доступа (или протоколом поддерживаемым NBAR). Политика применяется к тому же СЕ-РЕ интерфейсу, только во входящем направлении.

class-map match-all REMARKED-INTERACTIVE-VIDEO
match ip dscp cs5 match access-group 101 class-map match-all REMARKED-CALL-SIGNALING match ip dscp cs5 match access-group 102 class-map match-all REMARKED-ORACLE match ip dscp af21 af22 match access-group 103 class-map match-all REMARKED-DLSW+ match ip dscp af21 af22 match protocol dlsw
policy-map CE-INGRESS-EDGE
class REMARKED-INTERACTIVE-VIDEO set ip dscp af41 class REMARKED-CALL-SIGNALING set ip dscp af31 class REMARKED-ORACLE set ip dscp 25 class REMARKED-DLSW+ set ip dscp af21
interface serial 1/0
service-policy output CE-EGRESS-EDGE service-policy input CE-INGRESS-EDGE
access-list 101 permit udp any any
access-list 102 permit tcp any any access-list 103 permit tcp any eq 9000 any

Прозрачность QoS с использованием Методов Туннелирования MPLS DiffServ (QoS Transparency with MPLS DiffServ Tunneling Modes)

Во многих случаях оператору желательно проводить собственную политику QoS и выдерживать Соглашения о качестве обслуживания (SLA) не изменяя значений DSCP и IPP клиента. Для туннелирования QoS маркировки пакетов и обеспечения прозрачности QoS клиента может использоваться MPLS. Например можно выставлять значения поля MPLS EXP отличными (и даже независимо) от значений полей IPP или DSCP. Для назначения пакетов в тот или иной класс PHB (класс поведения на узле коммутации) с последующим установкой поля MPLS EXP при назначении пакету MPLS метки оператор может пользоваться различными критериями классификации -включая или исключая маркировку IP РНВ. Например, это может быть полезно оператору, которому требуется выполнение SLA для трафика клиента, но без привязки к используемой этим заказчиком политики маркировки QoS и без переписывания значений IP PHB клиента. Это можно рассматривать как инкапсуляцию РНВ клиентского пакета в туннельный РНВ оператора. Существует три метода туннелирования MPLS DiffServ (описанные в RFC 3270). Это:

Унифицированный метод (Uniform Mode)

Унифицированный метод используется в том случае, когда и клиент и оператор используют один и тот же домен DiffServ (иными словами используют одинаковую политику маркировки трафика). Внешний заголовок всегда используется для определения QoS РНВ. При назначении MPLS метки в поле MPLS EXP копируется значение классификации IPP. Это происходит по умолчанию. Для обеспечения полной поддержки DSCP на входящем интерфейсе, где устанавливается определенное значение приоритетности сброса пакетов для каждого заказчика, можно использовать команду set mpls exp imposition (в описании input policy map). На выходе из операторской сети, в процессе снятия внешней метки, маршрутизатор переносит значение CoS в поле IP DSCP. Этот процесс конфигурируется командой mpls propagate-cos на исходящем РЕ. Для полной поддержки DSCP в Унифицированном режиме в процессе снятия метки следует использовать комбинацию qos-groups и discard-classes в описании входящей карты политик на исходящем РЕ маршрутизаторе. Это обеспечивает соответствующую обработку пакета в процессе коммутации и в исходящей очереди уже после того как была снята метка, как показано на рисунке N3.

Рисунок N3. Унифицированный метод (Uniform Mode).

Метод Короткой Трубы (Short Pipe Mode)

Метод Short Pipe применяется в том случае, когда клиент и оператор используют различные домены DiffServ. Это полезно в тех случаях, когда оператор использует собственную политику DiffServ и требованием клиента является сохранение его DiffServ информации, то есть сеть оператора обеспечивает прозрачность DiffServ настроек клиента. Внешняя метка определяет QoS PHB оператора. В процессе назначения метки не происходит копирования IP классификации в поле EXP MPLS пакета. Значение MPLS EXP устанавливается с помощью команды set mpls exp imposition на входящем РЕ маршрутизаторе. Таким образом помечается CoS на внешней метке пакета, но само содержимое заголовка (IP DSCP) остается прежним. Для пере-классификации пакетов в туннеле необходимо использовать команду set mpls experimental topmost при определении политики либо на входящем либо на исходящем интерфейсе, там где требуется пере-классификация. На выходе из операторской сети, в процессе снятия внешней метки, РЕ маршрутизатор не трогает значение DSCP информации в заголовке пакета клиента, как это показано на рисунке N4

Рисунок N4. Метод Short Pipe

Метод Трубы (Pipe Mode)

Метод Pipe очень похож на метод Short Pipe, так как клиент и оператор используют различные домены DiffServ. Отличие заключается в том, что при методе Pipe оператор использует значение собственной классификации для конфигурирования алгоритмов обработки очередей WRED, WFQ (и не использует для этих целей маркировку пакетов клиента). Это влияет на процесс обработки пакета на исходящем РЕ до снятия внешней метки. Для этих целей в картах политик на исходящем РЕ используются параметры qos-group и discard-class. Такая конфигурация избавляет от необходимости настроек исходящих интерфейсов РЕ для каждого клиента с индивидуальными правилами обработки классов для каждого клиента. Метод Pipe проиллюстрирован на рисунке N5.

Рисунок N5. Метод Pipe

Модели мапирования классов Клиент-Оператор

Операторы могут предложить клиентам MPLS VPN множество моделей QoS. На скоростях E1 и ниже маловероятно, что клиенту предложат более 3-5 моделей, поэтому возможно мапирование 1:1. На более скоростных интерфейсах возможно потребуется мапирование в меньшее количество операторских классов. Несколько примеров такого мапирования проиллюстрированы ниже.

Операторская Модель Трех Классов

В этой модели оператор предлагает три класса сервиса: реального времени (строгая приоритетность), критические данные (гарантированная полоса) и best effort (по возможности). Признаком классификации в класс реального времени служит DSCP EF или CS5; класс критических данных DSCP CS 6, AF31 или CS3. Все остальные значения перемаркируются в 0. Дополнительно, трафик AF31 поступивший с превышением контракта перемаркируется в AF32. В такой модели не рекомендуется использовать потоковое видео (раздел "Смешение TCP и UDP"). Аналогично, в этой модели нет операторского класса подходящего для передачи Объемных данных (Bulk Data), которые представляют собой большие, не динамичные TCP сессий, которые могли бы вытеснить более мелкие транзакции данных. Диаграмма перемаркировки (Рисунок N6) и соответствующий фрагмент конфигурация представлены ниже. В этом примере используется двойной канал T1.

Рисунок N6. Диаграмма перемаркировки для модели трех классов.

Операторская Модель Трех Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Трех Классов представлена ниже.

class-map match-all ROUTING match ip dscp cs6 class-map match-all VOICE match ip dscp ef class-map match-all INTERACTIVE-VIDEO match ip dscp af41 class-map match-all MISSION-CRITICAL-DATA match ip dscp 25 class-map match-any CALL-SIGNALING match ip dscp af31 match ip dscp cs3 class-map match-all TRANSACTIONAL-DATA match ip dscp af21 class-map match-all NETWORK-MANAGEMENT match ip dscp cs2 class-map match-all SCAVENGER match ip dscp cs1
policy-map CE-THREE-CLASS-SP-MODEL
class ROUTING bandwidth percent 3 class VOICE priority percent 18 class INTERACTIVE-VIDEO priority percent 15 set ip dscp cs5 class CALL-SIGNALING priority percent 2 set ip dscp cs5 class MISSION-CRITICAL-DATA bandwidth percent 20 random-detect set ip dscp af31 class TRANSACTIONAL-DATA bandwidth percent 15 random-detect set ip dscp cs3 class NETWORK-MANAGEMENT bandwidth percent 2 set ip dscp cs3 class SCAVENGER bandwidth percent 1 class class-default bandwidth percent 24 random-detect

interface serial 1/0 max-reserved bandwidth 100 service-policy output CE-THREE-CLASS-SP-MODEL

WRED (а по сути RED, так как значения IPP у всех классов одинаковы) включен только на основных классах данных. Тестирование показало очень незначительное улучшение производительности при включении WRED также и на специализированных классах (таких как протоколы маршрутизации, сетевое управление и голосовая сигнализация). Более того, если классы маршрутизации и голосовой сигнализации будут подвержены сбросам, то скорее всего потребуется конфигурирование дополнительной полосы пропускания. Этот пример также гарантирует минимальную полосу пропускания для класса по умолчанию (24 процента). Если не использовать команду bandwidth в классе по умолчанию, то в случае появления дополнительного трафика классов Объемный (Bulk) или Интернет (Scavanger) пострадает класс По умолчанию. Однако теперь сумма полос пропускания всех сконфигурированных классов превышает 75 процентов, поэтому прежде чем транслятор примет настройки "service policy"требуется интерфейсная команда max reserved bandwidth 100.

Операторская Модель Трех Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Трех Классов представлена ниже.

class-map match-any REALTIME match ip dscp ef match ip dscp cs5 class-map match-any CRITICAL-DATA match ip dscp cs6 match ip dscp af31 match ip dscp cs3
policy-map PE-THREE-CLASS-SP-MODEL
class REALTIME priority percent 35 class CRITICAL-DATA bandwidth percent 40 random-detect dscp-based class class-default fair-queue random-detect

Операторская Модель Четырех Классов

Основываясь на предыдущей модели мы добавляем четвертый класс, который может использоваться для Объемных данных (Bulk Data) или потокового видео. Признаком классификации в этот новый класс служит DSCP AF21 или CS2. Ниже приведен пример использования этого нового класса для передачи потокового видео и (в основном UDP) трафика сетевого управления.



Рисунок N7. Диаграмма перемаркировки Операторской Модели Четырех Классов

Операторская Модель Четырех Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Четырех Классов представлена ниже.

class-map match-all ROUTING  match ip dscp cs6 class-map match-all VOICE match ip dscp ef class-map match-all INTERACTIVE-VIDEO  match ip dscp af41 class-map match-all STREAMING-VIDEO  match ip dscp cs4 class-map match-all MISSION-CRITICAL-DATA  match ip dscp 25 class-map match-any CALL-SIGNALING  match ip dscp af31  match ip dscp cs3 class-map match-all TRANSACTIONAL-DATA  match ip dscp af21 class-map match-all NETWORK-MANAGEMENT  match ip dscp cs2 class-map match-all SCAVENGER  match ip dscp cs1

policy-map CE-FOUR-CLASS-SP-MODEL  class ROUTING  bandwidth percent 3  class VOICE   priority percent 18  class INTERACTIVE-VIDEO  priority percent 15   set ip dscp cs5  class STREAMING-VIDEO  bandwidth percent 13  set ip dscp af21  class CALL-SIGNALING  priority percent 2   set ip dscp cs5  class MISSION-CRITICAL-DATA  bandwidth percent 12   random-detect   set ip dscp af31  class TRANSACTIONAL-DATA  bandwidth percent 10   random-detect   set ip dscp cs3  class NETWORK-MANAGEMENT  bandwidth percent 2  class SCAVENGER   bandwidth percent 1  class class-default   bandwidth percent 24   random-detect

interface serial 1/0  max-reserved bandwidth 100  service-policy output CE-FOUR-CLASS-SP-MODEL

Операторская Модель Четырех Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Четырех Классов представлена ниже.

class-map match-any REALTIME  match ip dscp ef match ip dscp cs5 class-map match-any CRITICAL-DATA  match ip dscp cs6  match ip dscp af31  match ip dscp cs3 class-map match-any PREFERRED-DATA  match ip dscp af21  match ip dscp cs2

policy-map PE-FOUR-CLASS-SP-MODEL  class REALTIME  priority percent 35  class CRITICAL-DATA   bandwidth percent 25   random-detect dscp-based  class PREFERRED-DATA   bandwidth percent 15   random-detect dscp-based  class class-default   fair-queue   random-detect

Операторская Модель Пяти Классов

Опять же основываясь на предыдущей модели мы добавляем пятый класс, который можно использовать для передачи Объемных Данных (Bulk Data) или потокового видео (то что не использовалось в модели четырех классов). Признаком классификации в этот новый класс служит DSCP AF11 или CS1, что влечет за собой ранее не требуемое перемаркирование Интернет/Scavanger класса в DSCP 0 (так, чтобы он не попал в класс Объемных данных (Bulk Data), а попал в класс По умолчанию.

Рисунок N8. Диаграмма перемаркировки Операторской Модели Пяти Классов

Операторская Модель Пяти Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Пяти Классов представлена ниже.

class-map match-all ROUTING match ip dscp cs6 class-map match-all VOICE match ip dscp ef class-map match-all INTERACTIVE-VIDEO match ip dscp af41 class-map match-all STREAMING-VIDEO match ip dscp cs4 class-map match-all MISSION-CRITICAL-DATA match ip dscp 25 class-map match-any CALL-SIGNALING match ip dscp af31 match ip dscp cs3 class-map match-all TRANSACTIONAL-DATA match ip dscp af21 class-map match-all BULK-DATA match ip dscp af11 class-map match-all NETWORK-MANAGEMENT match ip dscp cs2 class-map match-all SCAVENGER match ip dscp cs1
policy-map CE-FIVE-CLASS-SP-MODEL
class ROUTING
bandwidth percent 3 class VOICE priority percent 18 class INTERACTIVE-VIDEO  priority percent 15   set ip dscp cs5  class STREAMING-VIDEO  bandwidth percent 13   set ip dscp af21  class CALL-SIGNALING  priority percent 2  set ip dscp cs5  class MISSION-CRITICAL-DATA  bandwidth percent 12   random-detect  set ip dscp af31  class TRANSACTIONAL-DATA  bandwidth percent 5   random-detect   set ip dscp cs3  class NETWORK-MANAGEMENT  bandwidth percent 2  class BULK-DATA  bandwidth percent 5   random-detect  class SCAVENGER   bandwidth percent 1   set ip dscp 0  class class-default   bandwidth percent 24   random-detect
interface serial 1/0
 max-reserved bandwidth 100  service-policy output CE-FIVE-CLASS-SP-MODEL

Операторская Модель Пяти Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Пяти Классов представлена ниже.

class-map match-any REALTIME match ip dscp ef match ip dscp cs5 class-map match-any CRITICAL-DATA match ip dscp cs6 match ip dscp af31 match ip dscp cs3 class-map match-any PREFERRED-DATA match ip dscp af21 match ip dscp cs2 class-map match-any BULK-DATA match ip dscp af11 match ip dscp cs1
policy-map PE-FIVEOUR-CLASS-SP-MODEL
class REALTIME priority percent 35 class CRITICAL-DATA bandwidth percent 20 random-detect dscp-based class PREFERRED-DATA bandwidth percent 15 random-detect dscp-based class BULK-DATA bandwidth percent 5 random-detect dscp-based class class-default fair-queue random-detect

Требования по уровню качества обслуживания к сети оператора

Сквозная модель QoS представляет из себя цепочку, крепость которой определяется крепостью самого слабого звена. Поэтому для клиентов важно найти оператора способного обеспечить требуемый приложениям AVVID уровень сервиса. Например потребность в передачи речи и видео определяет следующие требования к сквозному уровню обслуживания:
Таким образом, операторская составляющая должна быть значительно меньше. Параметры SLA для Cisco Powered
Multiservice Networks показаны ниже: -потери пакетов не более 0.5 процента -односторонняя задержка между пограничными устройствами не более 60 мсек -колебания задержки не более 20 мсек Для того, чтобы добиться такого сквозного SLA клиенты и оператор должны скоординировать свои действия по классификации, конфигурации и интеграции решений QoS.

Рисунок N9. Требуемые параметры качества обслуживания

Модели настроек пограничных маршрутизаторов оператора

Последующие разделы иллюстрируют модели настройки пограничных устройств оператора.

Голосовой трафик

Существует две наиболее часто используемые конфигурации настройки класса реального времени (приоритетного класса или класса низкой задержки). Различаются они по используемому режиму полисинга. MQC поддерживает два варианта конфигурации приоритетной очереди:
∙ Полисинг с учетом перегрузок (Congestion-aware policer)

class SP-VOIP priority [percent <%>|<kbps>] <burst> set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7> imposition
В этом режиме приоритетный трафик подвергается полисингу только в случае возникновения перегрузок на интерфейсе. Он инициируется опцией задания скорости в команде priority.
∙ Всегда работающий полисинг
class SP-VOIP priority police <bps> bc <bytes> conform transmit exceed drop
set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7>

В этом режиме приоритетный трафик подвергается полисингу постоянно. Он инициируется командой police в описании приоритетного класса. Этот метод предпочтительнее для операторов желающих строго следовать условиям VoIP контракта.

Трафик данных

В этом разделе описываются наиболее частые конфигурации MQC для типовых классов данных.
Минимальная полоса со сбросом с конца очереди (Tail-Drop)
Следующая конфигурация представляет собой самый простой способ классификации в класс данных. Классу гарантируется минимальная полоса пропускания и применяется сброс с конца очереди с указанием максимального размера очереди. Такой класс может занимать полосу выше сконфигурированной в случае, если она не используется другими классами в той же политике. Такая конфигурация редко используется на СЕ и РЕ устройствах, так как чаще всего для оптимизации TCP используют не сброс с хвоста очереди (tail-drop), а алгоритм WRED.

class SP-DATA bandwidth [remaining] [percent <%>|<kbps>] queue-limit <packets|bytes>

Конфигурация CE: Минимальная полоса с WRED и маркированием / перемаркированием DSCP

Следующая конфигурация представляет собой типичную настройку класса данных. Классу гарантируется минимальная полоса, и для оптимизации пропускной способности TCP используется WRED. В этом примере подразумевается, что оператор управляет СЕ маршрутизатором.
class SP-DATA bandwidth [remaining] [percent <%>|<kbps>] random-detect random-detect [dscp-based | prec-based] random-detect exponential-weighting-constant <expw> random-detect [dscp <dscp> | prec <prec>] <minth> <maxth> <mpd> set ip dscp <dscp> | ip prec <prec>

Конфигурация PE: Минимальная полоса и WRED

Следующая конфигурация представляет типовую настройку класса данных на РЕ маршрутизаторе: классу данных гарантирована минимальная полоса пропускания и включен WRED. Трафик данного класса может использовать полосу выше сконфигурированной, если она не используется другими классами в той же политике
class SP-DATA bandwidth [remaining] [percent <%>|<kbps>] random-detect random-detect dscp-based | prec-based | discard-class-based random-detect exponential-weighting-constant <expw> random-detect dscp <dscp> <minth> <maxth> <mpd>

Команда random-detect discard-class-based используется для обеспечения прозрачности QoS, как описано в разделе "Прозрачность QoS с использованием Методов Туннелирования MPLS DiffServ"

Варианты конфигурации PE и CE: Максимальная полоса пропускания

Команда "bandwidth" гарантирует минимальную полосу для описываемого класса. В качестве вариации предыдущих конфигураций СЕ и РЕ в настройках класса для ограничения максимальной полосы пропускания можно использовать команду shape:
class SP-DATA bandwidth [remaining] [percent <%>|<kbps>] shape average <cir> <bc> <be>

Варианты конфигурации CE: ограничения на вход/выход

В дополнение к предыдущим конфигурациям PE и CE, но при отсутствии вариации с максимальной полосой предыдущего примера, к классу данных часто применяют команду police.
class SP-DATA bandwidth [remaining] [percent <%>|<kbps>] police <bps> bc <bytes> conform { action#1} exceed {action#2}
action#1 обычно одна из двух опций: transmit или set-dscp|prec-transmit <dscp|prec>. action#2 обычно одна из трех опций: drop или set-dscp|prec-transmit <dscp|prec> и / или set-frde-transmit или set-cos-transmit или set-clp-transmit. Первая опция action#2 реализует сброс пакетов. Вторая и третья - перемаркируют пакеты, то есть трафик вне контракта помечается. В случае использования последней опции над пакетом поступившем в соответствии с контрактными обязательствами производится два действия: маркировка на третьем уровне и маркировка фрейма на втором уровне. Опция frde-transmit  предназначена для Frame Relay, опция set-cos-transmit -для Ethernet/VLAN и опция set-clp-transmit -для АТМ.

Варианты конфигурации CE: ограничения на вход/выход с исключениями

В предыдущей модели весь трафик класса данных подвергался полисингу. Во многих случаях операторы хоте ли бы исключить какой-либо трафик того же класса из этого процесса. Например пробники Cisco Service Assurance Agent (SAA) посланные соответствующей раскраской в результате обработки могут быть сброшены или перекрашены. В следующей конфигурации используются иерархические карты правил для исключения трафика SAA из функции полисинга класса данных.
ip access-list extended SAA .

class match-all POLICED-TRAFFIC match not access-group name SAA

policy-map POLICING class POLICED-TRAFFIC police <bps> bc <bytes> conform {action#1} exceed {action#2}

policy-map CE-EDGE  . class SP-DATA  . service-policy POLICING

Варианты конфигурации CE и РЕ: ограничения на вход/выход и WRED

В случае применения полисинга для определения трафика в-и вне-контрактных условий в пределах класса, обычно используют WRED с различными уровнями сброса пакетов для трафика удовлетворяющего и не удовлетворяющего контракту. Пример такой конфигурации приведен ниже:
random-detect random-detect dscp-based random-detect exponential-weighting-constant <expw> random-detect dscp <dscp_in> <minth_in> <maxth_in> <mpd> random-detect dscp <dscp_out> <minth_out> <maxth_out> <mpd>
Использование трех профилей сброса в пределах одного класса - явление редкое из-за отсутствия ясной бизнес модели для такого сервиса. В типичной конфигурации  mpd = 1 и minth_in > maxth_ou, так что во время перегрузки трафик вне контракта будет сбрасываться более агрессивно, чем трафик в пределах контракта. В случае, когда WRED применяется совместно с полисингом для определения трафика в-и вне-контракта, критично чтобы выбор профиля WRED осуществлялся после исполнения полисинга. Это делается для того, чтобы в случае, если полисинг изменит значение DSCP, то профиль выбирался бы на основании этого нового значения.
Модели обработки трафика на третьем уровне и примеры конфигураций
Все примеры для обсуждаемых моделей даны на примере Frame Relay доступа. Каждая модель описана в терминах конфигурации MQC.
Модель нескольких клиентов на нескольких DLCI
В настоящее время это самая распространенная модель предоставления сервиса третьего уровня. При этой модели на одном физическом интерфейсе конфигурируется n DLCI, по DLCI на клиента. На каждом под-интерфейсе/DLCI специфическая для клиента конфигурация MQC. Сервисные характеристики этой модели следующие:
В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации.
Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов.
Эта модель применима к FR/DLCI, ATM/PVC, и Ethernet/VLAN. Пример работы данной модели на Frame Relay показан ниже (конфигурация применима и для СЕ в направлении РЕ, и для РЕ в направлении СЕ).
 
policy-map CHILD class SP-VOIP   {VoIP-sub-model} class SP-DATA  {Data-sub-model} class class-default   {Default-sub-model}

policy-map PARENT class class-default shape average <cir> <bc> <be> service-policy CHILD

map-class frame-relay FRTS service-policy output PARENT
interface SerialX/Y
encapsulation frame-relay IETF

interface SerialX/Y.1 point-to-point frame-relay interface-dlci <dlci> class FRTS

Карты класса (map-class) привязаны к каждому point-to-point под-интерфейсу интрефейса Serial X/Y. Для поддержки различных скоростей доступа потребуется несколько FRTS карт класса. Каждый point-to-point под-интерфейс поддерживает только один DLCI.
Модель нескольких клиентов на нескольких DLCI с фрагментацией и чередованием второго уровня (L2 Fragmentation and Interleaving )
Эта модель является расширением предыдущей посредством добавления механизмов фрагментации и чередования второго уровня. Использование этого механизка позволяет фрагментировать большие фреймы данных и смешивать их с фреймами VoIP. Это приводит к исключению задержек трафика реального времени из-за задержек сериализации фреймов данных. Обычно фрагментацию включают в том случае, если худшая задержка VoIP пакета (в приоритетной очереди), возникающая из-за задержки сериализации больших фреймов данных, превышает бюджет задержки на канале доступа (15 мсек). Это обычно происходит на скоростях доступа до 768 kbps, но LFI может применяться и на интерфейсах до 2 Mbps. Обычно это зависит от размера передающей очереди (последний буфер FIFO между планировщиком и физическим проводом, цель которого довести утилизацию канала до 100 процентов). Эта модель применима к FR/DLCI с FRF.12. Похожий механизм - MLP LFI, может использоваться на сериальных каналах с MLP инкапсуляцией, ATM PVC с MLPoATM и даже Frame Relay каналах с MLPoFR. Эта модель не применима к Ethernet/VLAN и не поддерживается на сериальных каналах с HDLC инкапсулацией. Пример для Frame Relay приведен ниже. Конфигурация применима к СЕ в направлении РЕ, и на РЕ в направлении СЕ.

policy-map CHILD  . policy-map PARENT  . map-class frame-relay FRTS
service-policy output PARENT frame-relay fragment <bytes>
interface SerialX/Y
encapsulation frame-relay IETF

interface SerialX/Y.1 point-to-point frame-relay interface-dlci <dlci> class FRTS
Эта конфигурация может применяться совместно с адаптивным выравниванием потока и cRTP.
Модель нескольких клиентов на нескольких DLCI с адаптивным формированием потока (Adaptive Shaping)
Эта модель - расширение модели нескольких клиентов на нескольких DLCI. Однако для того, чтобы клиент мог, если позволяет наличие емкости канала доступа, превысить свою гарантированную полосу пропускания применяется адаптивное формирование потока. Сервисные характеристики модели следующие:

Примечание: Начиная с версии IOS 12.2(15)T, клиенты могут воспользоваться функцией Frame Relay Voice Adaptive Traffic-Shaping (FR-VATS), которая в случае наличия VoIP трафика немедленно задействует выравнивание потока до минимальной полосы. FR-VATS, если необходимо, в случае присутствия VoIP может также задействовать фрагментацию FRF.12. Дополнительная информация по FR-VATS в документации на IOS.


policy-map CHILD . policy-map PARENT . map-class frame-relay FRTS frame-relay adaptive-shaping service-policy output PARENT

interface SerialX/Y encapsulation frame-relay IETF

interface SerialX/Y.1 point-to-point frame-relay interface-dlci <dlci> class FRTS
Эта конфигурация может использоваться совместно с фрагментацией второго уровня и cRTP. 
Модель нескольких клиентов на нескольких DLCI с применением cRTP
Эта модель - вариант модели нескольких клиентов на нескольких DLCI с добавлением RTP компрессии заголовка для сокращения занимаемой голосовым потоком полосы пропускания канала и для сокращения задержки сериализации VoIP (PQ) пакетов. Эта модель применима к FR/DLCI, ATM/PVCs с MLPoATM, и сериальным каналам  PPP/MLP/HDLC. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

policy-map CHILD ...
policy-map PARENT
...
map-class frame-relay FRTS service-policy output PARENT
interface SerialX/Y
encapsulation frame-relay IETF

interface SerialX/Y.1 point-to-point frame-relay interface-dlci <dlci> class FRTS
frame-relay ip rtp header-compression

Эта конфигурация может использоваться совместно с фрагментацией второго уровня и адаптивным формированием потока.
Модель одного клиента и одного DLCI
Эта модель - специфический вариант модели нескольких клиентов и нескольких DLCI и также очень распространена. Это прямое повторение основной модели, но с единственным сконфигурированным на основном интерфейсе DLCI. С помощью MQC конфигурируется основной интерфейс. Сервисные характеристики модели следующие:
FR - это универсальная инкапсуляция второго уровня, которая может применяться и для интерфейсов с одним
подключенным клиентом и для интерфейсов с несколькими клиентами.
Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

policy-map CHILD
...
policy-map PARENT
...
map-class frame-relay FRTS service-policy output PARENT

В том случае, если формирование трафика (shaping) не используется на основном интерфейсе сервисную политику (service╛policy) CHILD можно применить непосредственно в карте класса (map-class) frame relay (тем самым сервисная политика PARENT нам больше не нужна).

interface SerialX/Y encapsulation frame-relay IETF frame-relay interface-dlci <dlci> class FRTS
Эта модель может использоваться совместно с фрагментацией второго уровня, адаптивным формированием трафика и cRTP.
Модель одного клиента и нескольких DLCI
При этой модели к физическому интерфейсу подключается один клиент и для него конфигурируется n DLCI. С помощью MQC конфигурируется основной интерфейс. Обычно эта модель используется в контексте RFC 2547 и каждый DLCI поддерживает логически отдельный сервис (на третьем уровне). Сервисные характеристики модели следующие:
До последнего времени эта модель не была применима на скоростях менее 2 Mbps вследствие отсутствия фрагментации на интерфейсном уровне. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

access-list 100 permit <.> access-list 101 permit <.>

class-map match-any SP-VOIP match dlci 201 match [access-group 100|protocol <prot>] class-map match-all SP-DATA match [access-group 101|protocol <prot>]

policy-map child class SP-VOIP {VoIP-sub-model} class SP-DATA {Data-sub-model} class class-default {Default-sub-model}

policy-map PARENT class class-default shape average <cir> <bc> <be> service-policy CHILD

map-class frame-relay FRTS
service-policy output PARENT

interface SerialX/Y encapsulation frame-relay IETF frame-relay class FRTS

interface SerialX/Y.1 point-to-point description e.g. Managed VoIP Service frame-relay interface-dlci 201

interface SerialX/Y.1 point-to-point description e.g. Intranet Service frame-relay interface-dlci 202

interface SerialX/Y.1 point-to-point description e.g. Internet Service frame-relay interface-dlci 203

Эта модель может использоваться совместно с фрагментацией второго уровня.
Модель нескольких клиентов и нескольких VLAN на каждого клиента
Эта модель - расширение модели нескольких клиентов на нескольких DLCI для Ethernet доступа. Каждому клиенту выделяется несколько VLAN, и каждый VLAN представляет свой сервис. Главная (parent) политика формирования трафика применяется для всей группы VLAN конкретного клиента. Второстепенная (child) политика буферизации применяется внутри главной политики. При этой модели на одном физическом интерфейсе конфигурируется множество VLAN. На физическом интерфейсе присутствует MQC конфигурация для каждого клиента. Для различия трафика клиентов используется match vlan type. Сервисные характеристики модели следующие:
Эта модель применима к Ethernet/VLAN и не применима к FR/DLCI, ATM/PVC, и PPP/HDLC. Для случая Ethernet доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

class-map CUSTOMER-A match vlan 1 2 3 class-map CUSTOMER-B match vlan 4 5 6

policy-map PARENT class CUSTOMER-A bandwidth <min_cir> shape average <cir> <bc> <be> service policy CHILD-A

class CUSTOMER-B bandwidth <min_cir> shape average <cir> <bc> <be> service policy CHILD-B

Такая конфигурация повторяется для всех n клиентов подключенных к GigabitEthernet0 интерфейсу.

policy-map CHILD-A
class SP-VOIP {VoIP-sub-model} class SP-DATA
{Data-sub-model} class class-default {Default-sub-model}

policy-map CHILD-B
.

interface GigabitEthernet0 service-policy output PARENT

Особенности дизайна магистрали оператора

Для обеспечения строгого соответствия SLA в терминах потерь пакетов, задержки и колебаний задержки в операторской сети существуют следующие опции.
Пример DiffServ магистрали - Модель магистрали оператора с поддержкой трех классов сервиса
Как упоминалось ранее, нет необходимости поддерживать в магистрали то же количество DiffServ классов, что и на границе сети. Один из примеров реализации - это использование трех DiffServ классов в магистрали и пяти на пограничных устройствах (РЕ).
DiffServ классы оператора на границе сети
DiffServ классы оператора в магистрали
Реальное время (Realtime)
Реальное время (Core Realtime)
(Потоковое) Видео (Streaming Video)
Критические данные (Core Critical Data)


Критические данные (Critical Data)
Объемные данные (Bulk Data)
По умолчанию (Best Effort)
По умолчанию (Core Best Effort)

Определение магистральных классов

Магистральные классы определяются следующим образом:

Заключение

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