Каталог документации / Раздел "Cisco маршрутизаторы и коммутаторы"

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

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

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

Понятие качества обслуживания (QoS)
Требования к качеству обслуживания корпоративных пользователей и "Базовые Основы QoS"
Влияние полно-связности сетей MPLS VPN на QoS
Руководство по сокращению классов обслуживания в корпоративных сетях
- Вопросы сериализации
- Смешение TCP и UDP
Рекомендации по маркировке
Прозрачность QoS с использованием Методов Туннелирования MPLS DiffServ (QoS Transparency with MPLS DiffServ Tunneling Modes)
Модели мапирования классов Клиент-Оператор
Требования по уровню качества обслуживания к сети оператора
Модели настроек пограничных маршрутизаторов оператора
Особенности дизайна магистрали оператора
- Определение магистральных классов
Заключение

Понятие качества обслуживания (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 и т.д.). Классификация и маркировка производится на основе анализа следующих параметров:

параметры Уровня 2 (биты класса услуг [CoS] 802.1Q, значение экспериментальных бит MPLS);
параметры Уровня 3 (биты IP Precedence [IPP], кодовые точки дифференцированных услуг [DSCP Code-Points], IP-адреса источника и пункта назначения);
параметры Уровня 4 (порты TCP или UDP);
параметры Уровня 7 (подписи приложений).

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

802.1Q/p классы услуг (CoS) - Ethernet фреймы могут помечаться с помощью бит в заголовке второго уровня с использованием 802.1p бит приоритета в заголовке 802.1Q. Размер поля 802.1p - 3 бита, таким образом только восемь классов сервиса (0-7) доступны для маркировки Ethernet фреймов второго уровня.
Байт типа сервиса -IP Type of Service (ToS) - В связи с тем, что в процессе прохождения пакетов от источника к назначению часто меняется среда второго уровня, более универсальный метод маркировки заключается в использовании заголовка третьего уровня. Второй байт заголовка IPv4 пакета - это байт TOS. Первые три бита байта TOS называются битами IPP. IPP, также как и CoS биты 802.1p, позволяют пометить пакет только восемью значениями (0-7). Обычно IPP биты устанавливаются соответствующим образом:

IPP значения 6 и 7 резервируются для сетевого управляющего трафика (например, протоколов маршрутизации);
IPP значение 5 рекомендовано для речевого трафика;
IPP значение 4 используется совместно трафиком видеоконференций и потокового видео;
IPP значение 3 предназначено для сигнализации вызовов;
IPP значения 1 и 2 могут использоваться для приложений данных;
IPP значение 0 - маркировка по умолчанию.

Многие корпоративные пользователи считают, что IPP маркировка очень ограничена и не позволяет иметь большое число классов сервиса. В этом случае применяется 6-битная модель маркировки DSCP (64 значения).

DSCP - значения DSCP могут быть выражены в цифровой форме или с использованием специальных ключевых слов, называемых поведением сетевых участков (PHB - Per-Hop Behavior). Определено три класса DSCP маркировки: по возможности (BE - best effort или DSCP 0), гарантированная доставка (Assured Forwarding, AFxy) и срочная доставка (Expedited Forwarding - EF). В дополнение к этим трем определенным классам существуют коды селектора классов (class selector code points), которые обратно совместимы с IPP (CS1-CS7 идентичны значениям 1-7 IPP). Эти PHB описаны в RFC 2547, 2597 и 3246, соответственно. Определено четыре класса гарантированной доставки, они начинаются с AF и далее две цифры. Первая цифра определяет AF класс и принимает значения от 1 до 4. Вторая цифра определяет уровень вероятности сброса пакета в пределах каждого класса и принимает значения от 1 (минимальная вероятность сброса) до 3 (максимальная вероятность сброса). Значения DSCP могут быть выражены в десятичном формате или с использованием ключевых слов DSCP. Например, DSCP EF аналогично DSCP 46, а DSCP AF31 аналогично DSCP 26.
MPLS EXP - Биты MPLS EXP - это три бита в MPLS метке, содержащие индикатор QoS. По умолчанию, во время импозиции (добавления) метки в значение MPLS EXP записывается значение поля IPP IP пакета. Размер поля позволяет использовать до восьми QoS маркировок против 64 для DSCP. Значения EXP бит используются для определения PHB на узлах MPLS сети и могут использоваться для обеспечения прозрачности переноса значений IPP/DSCP в пакетах клиента в случае применения MPLS методов тунелирования Diffserv (MPLS DiffServ Tunneling Modes).

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

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

Class-Based Weighted Fair Queuing (CBWFQ, справедливое, взвешенное управление очередями на основе классов). CBWFQ - это композитный алгоритм взвешенной справедливой очередности, позволяющий определять классы по настраиваемым критериям, таким как списки доступа (ACL), входящий интерфейс, протокол и так далее. В рамках Cisco MQC (Modular QoS Command-Line Interface), он позволяет выделять полосу каждой из до 64 очередей и обрабатывать эти очереди по алгоритму справедливой очередности. Он, также, поддерживает механизм WRED (Weighted Random Early Detect - взвешенное случайное раннее обнаружение), в качестве механизма, обеспечивающего свою политику отбрасывания пакетов для каждого класса трафика.
Modified Deficit Round Robin (MDRR)-MDRR - это композитный механизм, основанный на использовании классов трафика, и позволяющий организовать буферизацию до восьми классов на платформах Cisco 12000 Series. Он работает подобно CBWFQ и также позволяет организовывать буферизацию трафика чувствительного к задержкам в случае использования очереди строгого приоритета. MDRR может применяться на направлении к матрице коммутации (на входящем интерфейсе) или от матрицы (на исходящем интерфейсе). Биты MPLS EXP и IPP обрабатываются в MDRR одинаково.
Low-Latency Queuing (LLQ)-LLQs (использование очереди строгого приоритета в случае MDRR) использует выделенную очередь для обработки трафика чувствительного к задержке, такого как голос или видео. Так как LLQ в MQC включает функцию полисинга трафика, она позволяет обрабатывать пакеты в определенной очереди LLQ в момент поступления, что, в свою очередь, позволяет конфигурировать несколько очередей строгого приоритета (например, одна LLQ очередь может быть сконфигурирована для голоса, а вторая для интерактивного видео). Программное обеспечение абстрагируется от того факта, что на самом деле существует только одна LLQ очередь. Продолжая пример, если для приоритетной очереди сконфигурировано 100kbps для голосового трафика и 400kbps для интерактивного видео, то программное обеспечение настроит приоритетную очередь на 500kbps. Оно будет обрабатывать голосовой трафик как трафик строгой приоритетности до 100kbps. Затем, любой дополнительный голосовой трафик будет подвержен полисингу (сброшен), что подчеркивает важность правильной настройки CAC (Call Admission Control). Алгоритм будет продолжать выделять для интерактивного видео 400kbps полосы пропускания. Если поступит более 400kbps видео трафика, то избыточный трафик будет опять же подвержен полисингу. При алгоритме MDRR со строгой приоритетностью приоритетная очередь будет обрабатываться до тех пор, пока в этой очереди есть пакеты. Помимо подобной реализации в MDRR существует буферизация с альтернативной приоритезацией. В этом режиме приоритетная очередь обслуживается по очереди с другими очередями.
WRED -WRED - это механизм предупреждения перегрузок в сети, позволяющий осуществить интеллектуальный сброс пакетов на основании маркировки конкретного пакета в момент возникновения перегрузки. Не смотря на то, что сбросы осуществляются и случайным образом, статистически, пакеты с меньшим приоритетом сбрасываются более агрессивно при достижении административно заданного порога заполнения очереди. WRED позволяет избежать проблем с массовым сбросом пакетов в хвосте очереди и глобальной синхронизацией 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	Классификация L2 CoS/MPLS-exp
Маршрутная информация	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 трафика рекомендуется придерживаться следующих правил:

Голосовой трафик должен быть промаркирован как DSCP EF, в соответствии с "Базовыми Основами QoS" и RFC 3246.
Сигнализация должна быть промаркирована как CS3, в соответствии с "Базовыми Основами QoS" (во время миграции можно использовать AF31).
Потери пакетов в магистралях спроектированных для предоставления VoIP сервиса высокого качества не должны превышать 0.25 процентов.
Односторонняя задержка не должна превышать 150ms, в соответствии со International Telecommunication Union (ITU) G.114.
Колебания задержки (jitter) должны быть менее 10 мсек. Максимальный jitter должен быть менее чем бюджет по задержке в сети минус минимальная сетевая задержка. Это типовое значение колебания задержки для VoIP обусловлено бюджетом по задержке, так называемым mouth-to-ear, в 100 мсек. (Это достаточно консервативный бюджет по сравнению с G.114, в котором рекомендуется jitter менее 150 мсек). Из этого значения мы вычитаем время распространения по магистрали (30 мсек) и задержку кодека (35 мсек), что дает нам бюджет для jitter в 35 мсек. Эти 35 мсек разбиваются на 30 мсек на доступе (15 мсек вход/выход) и 5 мсек на магистрали. То есть в худшем варианте, для адаптивных jitter-буферов, колебания задержки должны быть менее 10 мсек.
Для каждого разговора (в зависимости от частоты квантирования, кодека и заголовка второго уровня) требуется 21-106 kbps гарантированной приоритетной полосы пропускания.
Для трафика сигнализации требуется 150 bps (плюс заголовок второго уровня) гарантированной полосы пропускания.

На качество голосовой связи напрямую влияют все три фактора качества QoS: потери пакетов, задержка и вариации задержки.

Потери пакетов вызывают кратковременные пробелы в разговоре. Стандартные алгоритмы кодирования используемые в Cisco Digital Signal Processor (DSP) с помощью алгоритмов маскирования могут восстановить потери до 30 мсек. Таким образом, потери двух и более последовательных 20 мсек сэмплов приведут к заметной деградации качества голоса. Предположив случайное распределение сбросов пакетов в одном речевом потоке, сброс 1-го процента в голосовом потоке привела бы в среднем к потери, которую нельзя было бы восстановить каждые 3 минуты. Аналогично, уровень сброса 0,25 процента привел бы в среднем к потери, которую нельзя было бы восстановить каждые 53 минуты.
Задержка более 200 мсек может вызвать деградацию качества голосовой связи. Если общая задержка в канале становится слишком большой, разговор по телефону начинает напоминать переговоры по спутниковому каналу связи или по симплексному радиоканалу. В стандарте Международного Союза Электросвязи для технологии VoIP (G.114) говорится, что задержка величиной в 150 мсек в одном направлении является приемлемой для качество голосовой связи. Было продемонстрировано, что разница в качестве голоса между сетями с задержкой в 150 мсек и 200 мсек является незначительной и практически незаметной для пользователя. Cisco рекомендует ориентироваться на ITU стандарт 150 мсек, но если существуют ограничения не позволяющие добиться такого бюджета, то размер задержки может быть увеличен до 200 мсек без значительной деградации качества связи.
Что же касается колебаний задержки, то для их выравнивания в устройствах Cisco для IP-телефонии используются адаптивные буферы. Однако они могут компенсировать колебания задержки лишь в пределах от 20 до 50 мсек. При централизованной обработке вызовов IP-телефоны используют контрольные каналы TCP для связи с Cisco CallManager. Если эти весьма небольшие каналы не получат достаточной полосы пропускания, качество обслуживания абонентов будет ухудшаться. Давайте для примера рассмотрим время, которое проходит с момента поднятия трубки до момента, когда абонент слышит гудок. Когда абонент поднимает трубку IP-телефона, телефон "спрашивает" CallManager, что делать дальше. CallManager, в свою очередь, говорит IP-телефону, чтобы тот начал воспроизведение гудка в поднятой трубке. Если контрольный трафик будет потерян или задержан в сети, пользователь не услышит гудка и решит, что телефон не работает. Та же логика применима к любому сигнальному трафику, которым обмениваются шлюзы и телефоны.

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

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

Бюджета задержки на канале доступа;
Максимальной задержки на пустой LLQ/PQ очереди. Это должно исключать задержку вызванную конфликтами VoIP пакетов;
Скорости подключения. Для данной скорости задержка, вызванная конфликтами VoIP пакетов, будет расти с ростом интервалов пакетизации и последующим ростом задержки сериализации VoIP пакета;
Используемого кодека и интервала пакетизации. Для данного кодека и интервала пакетизации, задержка вызванная конфликтами пакетов VoIP будет расти с процентным ростом LLQ/PQ составляющей трафика на линии доступа. Задержка будет падать с ростом полосы пропускания канала. Чем более скоростные кодеки применяются, тем больше будет задержка связанная с ростом размера VoIP пакетов, что, в свою очередь, увеличивает задержку сериализации. Основываясь на выше изложенном, пример планирования VoIP в части процентного соотношения PQ трафика в сети оператора выглядит следующим образом:

Скорость доступа к сети 512 kbps и оптимальный бюджет по задержке на канале доступа 15 мсек
Худший вариант задержки на не загруженной PQ очереди - 10 мсек;
5мсек-задержки буферизации VoIP
G.711 кодек даст 20 мсек без cRTP В этом случае можно гарантировать максимум два вызова, что составляет примерно 35 процентов загрузки PQ очереди. Это дает нам примерно 180 kbps с небольшим запасом. При расчете полосы пропускания для VoIP необходимо обеспечить достаточно дополнительной емкости и для трафика данных.

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

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

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

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

Интерактивный видео трафик, в соответствии с "Базовыми основами QoS", должен быть промаркирован AF41.
Потери должны быть не более одного процента.
Однонаправленная задержка должна быть не более 150 мсек.
Колебания задержки должны быть не более 30 мсек.
Минимально гарантированная полоса пропускания (LLQ) должна быть равна размеру сессии видео конференции плюс 20 процентов. (Например, сессия видео конференции в 384 kbps требует настройки 460 kbps полосы трафика гарантированного приоритета.)

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

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

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

Потоковое видео (одноадресной или многоадресной рассылки), в соответствии с "Базовыми основами QoS" должно быть промаркировано CS4.
Потери должны быть менее 2 процентов.
Задержка должна быть менее 4-5 секунд (в зависимости от возможностей буферизации видео приложений).
Не существует значительных требований по колебанию задержки.
Требования по гарантиям полосы (CBWFQ) зависят от формата кодирования скорости видео потока.
Потоковое видео обычно однонаправленное и, поэтому, в удаленных филиалах маршрутизаторы можно не настраивать на поддержку потокового видео в направлении от филиала к центру.
Не важные приложения потокового видео, такие как видео для развлечения, могут быть промаркированы DSCP CS1 и для них требуется минимум гарантий полосы пропускания в очереди CBWFQ (Используя класс Интернет/scavenger). Приложения потокового видео менее требовательны к QoS, так как они менее чувствительны к задержкам (может пройти несколько секунд перед началом видео картинки) и нечувствительны к колебаниям задержки (благодаря буферизации на уровне приложений). Однако, потоковое видео может содержать важную информацию, такую как электронное обучение или трансляцию корпоративных совещаний и, следовательно, требовать гарантий QoS. Не важное видео содержание (такое как фильмы, музыкальные видео клипы и так далее) может рассматриваться как Интернет сервис (сервис хуже чем "Best Effort"), что означает, что эти потоки работают пока есть полоса пропускания, но будут вытесняться в случае возникновения перегрузок в сети.

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

Определяя требования QoS для данных, нужно принимать во внимание следующие факторы:
Используйте не более четырех основных классов трафика, такие как

Локально-определенный Критический (для критически важных приложений) -транзакционные и интерактивные приложения с высоким бизнес-приоритетом;
Транзакционный/интерактивный - приложения клиент-сервис, приложения по передаче сообщений;
Объемные приложения- передача больших файлов, синхронизация и репликация баз данных, электронная почта (e-mail);
По возможности- класс по умолчанию для всего не назначенного трафика; конфигурируйте как минимум 25 процентов полосы для этого класса;
Опционный класс - Интернет/scavenger (игровой трафик, развлечения.) Дополнительный опционный класс включает в себя маршрутизацию и сетевое управление.

Локально-определенный Критический класс трафика данных
Локально-определенный Критический класс трафика данных - это возможно самый недопонимаемый класс трафика в "Базовых основах 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 потоков, но необходимо осознавать последствия такого смешения.

Прозрачность 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);
Метод Короткой Трубы (Short Pipe Mode);
Метод Трубы (Pipe Mode).

Унифицированный метод (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 уровень сервиса. Например потребность в передачи речи и видео определяет следующие требования к сквозному уровню обслуживания:

потери пакетов не более 1 процента;
односторонняя задержка не более 150 мсек (в соответствии со стандартом G.114);
колебания задержки не более 30 мсек.

Таким образом, операторская составляющая должна быть значительно меньше. Параметры 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. Сервисные характеристики этой модели следующие:

Каждый клиент покупает агрегатную услугу (на все классы). Оператор гарантирует сервис используя формирование трафика DLCI (shaping) в соответствии с контрактной агрегатной полосой
Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов.

В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации.
Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов.
Эта модель применима к 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. Однако для того, чтобы клиент мог, если позволяет наличие емкости канала доступа, превысить свою гарантированную полосу пропускания применяется адаптивное формирование потока. Сервисные характеристики модели следующие:

Каждый клиент покупает агрегатную услуги (на все классы) с гарантированной минимальной (min) и максимальной (max) полосой. При наличии индикаторов перегрузки второго уровня (BECN/FECN для FR, пауза для Ethernet) используется адаптивное формирование потока для снижения скорости DLCI до гарантированного минимума. В случае отсутствия индикаторов перегрузки второго уровня скорость повышается до максимально гарантированной.

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

Агрегат клиента может разбиваться на отдельные полосы пропускания доступные для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима к /DLCI и Ethernet/VLAN, но не применима к ATM/PVC и PPP/HDLC. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

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 конфигурируется основной интерфейс. Сервисные характеристики модели следующие:

Каждый клиент покупает агрегатную услугу (на все классы). Оператор гарантирует сервис либо посредством конфигурирования контрактной скорости на канале доступа, либо конфигурируя большую скорость и используя формирование трафика (shaping) на основном интерфейсе до контрактного значения.
Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима только к каналам точка-точка, то есть сериальным HDLC/PPP/FR или Ethernet/VLAN. Так как модель не использует мультиплексирующие возможности второго уровня ее можно расширить и на PPP/HDLC. Может показаться излишним использование FR инкапсуляции. Но она применима по двум причинам:

FR - это универсальная инкапсуляция второго уровня, которая может применяться и для интерфейсов с одним
подключенным клиентом и для интерфейсов с несколькими клиентами.

Поддержка IP QoS в IOS исторически лучше, чем на просто PPP/HDLC инкапсуляциях.
Маловероятно, что данная модель будет применяться на ATM интерфейсах, так как АТМ обычно используется из-за своих возможностей по мультиплексированию трафика и потому более применима к модели с множеством клиентов на одном интерфейсе.

Для случая 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 поддерживает логически отдельный сервис (на третьем уровне). Сервисные характеристики модели следующие:

Каждый клиент покупает агрегатную услугу (на все классы) в x Mbps, которая может быть меньше чем скорость интерфейса. Оператор обеспечивает контрактные обязательства формированием трафика (shaping) на интерфейсном уровне (не на уровне DLCI) до контрактного значения.
Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима для FR/DLCI и Ethernet/VLAN. Эта модель не применима к ATM и PPP/HDLC.

До последнего времени эта модель не была применима на скоростях менее 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. Сервисные характеристики модели следующие:

Каждый клиент покупает агрегатную услугу (на все VLAN и все классы) в x Mbps. Оператор обеспечивает контрактные обязательства формированием трафика (shaping) для каждой группы VLAN каждого клиента до контрактного агрегатного значения каждого клиента.
С помощью конфигурирования min_cir (bandwidth) меньшим, чем cir (shape) можно обеспечить клиенту минимальную и максимальную гарантированную скорость.
Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов.

Эта модель применима к 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 в магистрали обеспечивает: или достижение тех же параметров SLA с использованием меньшей полосы пропускания, или поддержку большего агрегатного трафика при том же значении полосы пропускания сети. К недостатку этой модели можно отнести повышенную сложность при дизайне сети и ее обслуживании. В DiffServ магистрали не обязательно должно поддерживаться столько же классов, что и на границе сети (на интерфейсе РЕ-СЕ).

Пример DiffServ магистрали - Модель магистрали оператора с поддержкой трех классов сервиса
Как упоминалось ранее, нет необходимости поддерживать в магистрали то же количество DiffServ классов, что и на границе сети. Один из примеров реализации - это использование трех DiffServ классов в магистрали и пяти на пограничных устройствах (РЕ).

DiffServ классы оператора на границе сети	DiffServ классы оператора в магистрали
Реальное время (Realtime)	Реальное время (Core Realtime)
(Потоковое) Видео (Streaming Video)	Критические данные (Core Critical Data)
Критические данные (Critical Data)
Объемные данные (Bulk Data)
По умолчанию (Best Effort)	По умолчанию (Core Best Effort)

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

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

Магистральный класс реального времени-Этот класс используется для приложений типа VoIP и интерактивное видео, которые требуют низких потерь пакетов (меньше 0.25 процентов), малой задержки и малого значения колебаний задержки (обычно по магистрали 5 мсек) и все это с определенным уровнем доступности. Этому классу может также потребоваться поддержка сохранения очередности пакетов в пределах потоков. Проектировать этот класс нужно всегда из соображений худшей задержки. Обычно избыточный трафик этого класса сбрасывается. В этот класс должны направляться пакеты с маркировкой EF и он должен обслуживаться в приоритетных очередях. Под приоритетную очередь следует отводить 25-33 процента полосы пропускания канала. WRED на этих очередях не применяют.
Магистральный класс критических данных -Этот класс используется для бизнес-критичных приложений, таких как SNA, SAP R/3, Telnet, и, возможно, внутренних Web-приложений. Он определяется в терминах задержки (RTT должен быть менее 250 мсек - порог человеческого восприятия задержки) и потерь (обычно это 1 процент, но возможно и достижение 0.1 процента). Колебания задержки для этого класса не важны и не определяются. Избыточный трафик этого класса обычно перемаркируется идентификатором "вне контракта" (меньшее значение EXP). В этом классе может обеспечиваться сохранение последовательности пакетов в потоке. В этот класс должны назначаться пакеты с маркировкой AF и ему должно выделяться до 90 процентов оставшейся полосы пропускания канала (после выделения полосы для PQ/EF трафика). Следует использовать WRED для оптимизации производительности TCP и применения политики сбросов пакетов для трафика выше контрактных обязательств.
Магистральный класс по умолчанию - Этот класс используют для клиентского трафика, который не был классифицирован как трафик реального времени или критических данных. Он определяется в терминах потери пакетов и доступности. Задержка и колебания задержки не важны для этого сервиса и их не следует определять. Таким образом, только 10 процентов оставшейся полосы пропускания канала (послу определения PQ) следует отводить на обработку этого класса. На границе сети оператора производится мапирование нескольких классов клиента в единый агрегатный магистральный класс оператора. В предыдущем примере несколько РЕ классов (потоковое видео, критические данные и объемные данные) мапировались в один магистральный класс критических данных. Это мапирование можно реализовать двумя способами:
Магистральный класс проверяет установку нескольких значений DSCP. Применительно к предыдущему примеру, если DSCP AF31 представляет на границе критические данные, DSCP AF21 - (потоковое) видео и DSCP AF11 - объемные данные, то магистральный агрегатный класс (класс критических данных) проверяет на соответствие значениям DSCP AF31, AF21 и AF11.
Если в магистрали используется MPLS, то пограничный маршрутизатор может устанавливать значение поля MPLS EXP (3 бита) как функцию полученного DSCP. Применительно к тому же примеру, если в качестве критерия принадлежности к магистральному классу (критических данных) служит MPLS EXP = 3, то РЕ пограничный маршрутизатор оператора должен устанавливать значение MPLS EXP в 3 для всех пакетов со значением DSCP AF31 (пограничный класс критических данных), AF21 (пограничный класс потокового видео) и AF11 (пограничный класс объемных данных).

Заключение

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру