Голосовая связь : Качество голосовой связи

Качество обслуживания для VoIP

2 апреля 2008 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Английский (13 апреля 2001) | Отзыв


Содержание

Качество обслуживания (QoS) для VoIP
Обзор функции QoS для VoIP
Требования к полосе пропускания
Классификация пакетов
Механизмы организации очередей QoS
Фрагментация и чередование
Формирование трафика
Сжатие заголовков IP RTP
Дифференцированные услуги (DS) для VoIP
Resource Reservation Protocol (RSVP)
Функция QoS VoIP по выделенным линиям (с использованием протокола PPP)
Функция QoS VoIP в сетях по протоколу Frame Relay
Функция QoS VoIP для протокола ATM
Дополнительная документация

Качество обслуживания (QoS) для VoIP

История версий

Номер версии Дата Примечания

1

16.04.2001 г.

Создание документа.

2

15.05.01 г.

Включены правки редактора.

3

30.06.01 г.

Включены дополнительные правки редактора.



В документе Качество обслуживания для VoIP рассматриваются различные понятия и характеристики функции качества обслуживания (QoS) применительно к передаче голоса, в частности, к технологии Voice over IP (VoIP). Также приводятся общие примеры методов развертывания этих возможностей в различных сетевых средах.

Документ Качество обслуживания для VoIP содержит следующие разделы:

Обзор функции QoS для VoIP

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

  • Для работы кодека G.729, использующегося по умолчанию, потеря пакетов должна быть существенно ниже 1 процента — это позволяет избежать различимых на слух ошибок. В идеальном случае потери пакетов при использовании технологи VoIP быть не должно.

  • В спецификации ITU G.114 для качественного трафика в режиме реального времени (например, голосового) рекомендуется сквозная задержка не более 150 мс при передаче сигнала в одном направлении. (При международных звонках допустима задержка при передаче в одном направлении до 300 мс, в частности, при передаче данных через спутник. При этом учитывается задержка распространения — время, необходимое сигналу для прохождения расстояния.)

  • Буфера флуктуации сигнала (используются для компенсации изменения задержки) в дальнейшем добавляются к сквозной задержке и обычно эффективны только при разбросе задержки менее 100 мс. По этой причине флуктуации сигнала необходимо свести к минимуму.

Технология VoIP обеспечивает высокое качество передачи голоса только при условии, что голосовым пакетам для канала сигнализации звукового канала присвоен более высокий приоритет, чем другим видам сетевого трафика. Чтобы при использовании VoIP пользователи могли получать приемлемый уровень качества голоса, необходимо обеспечить для трафика VoIP полосу пропускания, задержку и флуктуации сигнала, которые соответствовали бы предъявляемым требованиям. Необходимая приоритетная обработка голосовых пакетов VoIP обеспечивается механизмом «Качество обслуживания» (QoS). В общем, механизм QoS обеспечивает более качественные (и более предсказуемые) сетевые услуги благодаря наличию следующих функций:

  • Поддержка выделенной полосы пропускания

  • Улучшение характеристик потерь

  • Уменьшение и предотвращение перегрузок сети

  • Формирование сетевого трафика

  • Настройка приоритетов трафика по всей сети

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

Требования к полосе пропускания

Перед использованием любой функции QoS, рассматриваемой в этом документе, необходимо обеспечить пропускную способность сети, необходимую для реализации голосового трафика в реальном времени. Например, для вызова VoIP по стандарту G.711 на скорости 80 Кбит/с (64 Кбит/с полезной нагрузки плюс 16 Кбит/с данных заголовка) недостаточно канала со скоростью 64 Кбит/с, поскольку теряется, по меньшей мере, 16 Кбит/с пакетов (что составляет 20 процентов). В данном примере также предполагается, что в канале нет другого трафика. Если необходимая полоса пропускания для голосового трафика обеспечена, можно перейти к последующим шагам, чтобы голосовые пакеты получили приоритет и определенный процент от общей полосы пропускания.

Классификация пакетов

Основой для реализации любой модели механизма качества обслуживания служит способность сетевых устройств идентифицировать и группировать пакеты определенного типа. Этот процесс идентификации называется классификацией пакетов. После того как пакет классифицирован, он должен получить маркировку путем установки предназначенных для этого битов в заголовке IP-пакета. Процесс классификации и маркировки описывается в следующих разделах:

Классификация пакетов: обзор

Чтобы обеспечить полосу пропускания для VoIP-пакетов, сетевому устройству необходимо идентифицировать VoIP-пакеты во всем IP-трафике, проходящем через это устройство. Для идентификации VoIP-пакетов сетевые устройства используют IP-адрес источника и пункта назначения в заголовке IP-пакета или номера портов источника и пункта назначения протокола датаграммы пользователя (UDP) в заголовке пакета UDP. Этот процесс идентификации и группирования называется классификацией и служит основой для обеспечения любой модели QoS.

Помимо методов статической классификации, при которых используется сравнение данных заголовков Layer 3 или Layer 4, для динамической классификации можно использовать такой механизм, как протокол резервирования ресурсов (RSVP). Чтобы определить, какой UDP-порт будет использоваться при обмене голосовыми пакетами, в протоколе RSVP применяются сигнальные пакеты стандарта H.245. Затем, чтобы идентифицировать VoIP-трафик, с помощью протокола настраиваются динамические списки доступа, а трафик помещается в зарезервированную очередь. Протокол RSVP будет рассмотрен ниже.

При классификации пакетов нагрузка на процессор может быть очень высокой, поэтому должна выполняться как можно дальше от границ сети. Поскольку на каждом участке нужно определять способ обработки полученного пакета, необходим более простой и эффективный метод классификации в самой сети. Эта более простая классификация обеспечивается посредством маркировки или установки байта типа обслуживания (ToS) в IP-заголовке пакета.

Три старших бита байта ToS называются битами IP Precedence. Большинство приложений и поставщиков поддерживают настройку и распознавание этих трех битов. Методы маркировки развиваются, поэтому теперь для определения классов дифференцированных служб могут использоваться шесть старших битов байта ToS, которые называются дифференцированными кодами обслуживания (Differentiated Services Code Point, DSCP). DSCP рассматривается ниже в данном документе.

После того как возможность классификации и идентификации VoIP-пакетов (через сведения об адресе порта или через байт ToS) реализована на каждом участке сети, эти участки обеспечивают необходимый уровень качества обслуживания для VoIP-пакетов. Теперь можно настроить механизмы приоритетной организации очереди так, чтобы крупные пакеты данных не препятствовали передаче голосовых данных и чтобы за счет сжатия заголовков протоколов IP, UDP и RTP с 40 до 2–4 байтов снизились требования к полосе пропускания.

Классификация и маркировка

Классификация представляет собой процесс идентификации класса или группы, к которым принадлежит пакет. Чтобы отнести трафик к одному из нескольких конкретных классов, сетевые устройства используют следующие критерии сопоставления:

  • Команда глобальной конфигурации dial-peer voice voip

  • Список доступа (стандартный и расширенный)

  • Протокол (такой как URL, протоколы состояний или протокол Layer 4)

  • Порт ввода

  • IP Precedence или DSCP

  • Класс обслуживания (CoS) Ethernet 802.1p

Как уже упоминалось, повторная классификация пакетов, основанная на совпадениях списков доступа, может создавать высокую нагрузку на процессор. Поэтому необходимо, чтобы узлы маркировали VoIP-пакеты сразу же при их идентификации и классификации. Если после распознавания VoIP-трафика узел настраивает биты IP Precedence или биты DSCP в байте ToS IP-заголовка, все другие узлы в сети выполняют классификацию на основе этих битов.

Маркировка представляет собой процесс установки узлом одного из следующих параметров:

  • Три бита IP Precedence в байте IP ToS

  • Шесть битов DSCP в байте IP ToS

  • Три бита MPLS Experimental (EXP)

  • Три бита Ethernet 802.1p CoS

  • Один бит вероятности потери ячейки ATM (CLP)

В большинстве IP-сетей необходимо, чтобы маркировки IP Precedence или DSCP было достаточно для распознавания VoIP-трафика.

Классификация одноранговых телефонных соединений и примеры маркировки

Обычно в сетях со шлюзами Cisco VoIP для классификации VoIP-пакетов и маркировки битов протокола IP Precedence используются одноранговые телефонные соединения. В следующем примере настройки показана маркировка битов IP Precedence:

Пример настройки 1: Классификация и маркировка с использованием одноранговых телефонных соединений
dial-peer voice 100 voip 
 
 destination-pattern 100 
 session target ipv4:10.10.10.2 
 ip precedence 5
 

В данном примере для любого VoIP-вызова, соответствующего команде dial-peer voice 100 voip, все пакеты полезной голосовой нагрузки будут настроены с уровнем 5 IP Precedence. Это означает, что для трех старших битов байта IP ToS установлено значение 101.



Классификация согласованной скорости доступа и примеры маркировки

Согласованная скорость доступа (Committed access rate, CAR) представляет собой давно используемый метод, который связан с ограничением скорости или трафика соответственно максимальным значениям определенных критериев. Согласованная скорость доступа поддерживает большинство механизмов сопоставления и позволяет настраивать биты IP Precedence или биты DSCP по-разному в зависимости от того, соответствуют ли пакеты указанной скорости или превышают ее.

В общем, согласованная скорость доступа больше подходит для пакетов данных, чем для голосовых пакетов. Например, весь трафик данных, поступающий на интерфейс Ethernet со скоростью менее 1 Мбит/с, можно отнести к классу 3 приоритета IP Precedence. Тогда любой трафик, поступающий на скорости выше 1 Мбит/с, можно отнести к классу 1 или отбросить. При этом другие узлы сети могут по-другому обрабатывать превышающий скорость или несоответствующий критериям трафик, маркированный более низким уровнем IP Precedence. Необходимо, чтобы весь правильно предоставленный голосовой трафик соответствовал указанной скорости.

В следующем примере настройки показано использование согласованной скорости доступа для классификации и маркировки VoIP-пакетов:

Пример настройки 2: Классификация и маркировка с использованием согласованной скорости доступа
access-list 100 permit udp any any range 16384 32767
 
access-list 100 permit tcp any any eq 1720
!
interface Ethernet0/0 
ip address 10.10.10.1 255.255.255.0 
 rate-limit input 
 access-group 100 1000000 8000 8000 conform-action    
set-prec-continue 5 exceed-action set-prec-continue 5
 

В данном примере любой трафик, совпадающий со списком доступа 100, настраивается с уровнем 5 IP Precedence. Это означает, что для трех старших битов байта IP ToS установлено значение 101. В данном случае список доступа 100 совпадает с общими UDP-портами, используемыми VoIP и сигнальным трафиком H.323 к TCP-порту 1720.



Классификация маршрутизации на основе политик и примеры маркировки

Маршрутизация на основе политик (Policy-based routing, PBR) — это еще одна давно используемая функция, которая позволяет маршрутизировать трафик на основе исходного порта или списка доступа. Ее также можно использовать для классификации и маркировки пакетов. Простой пример настройки:

Пример настройки 3: Классификация и маркировка с использованием маршрутизации на основе политик
access-list 100 permit udp any any range 16384 32767
 
access-list 100 permit tcp any any eq 1720
!
route-map classify_mark 
 match ip address 100 
 set ip precedence 5
!
interface Ethernet0/0 
 ip address 10.10.10.1 255.255.255.0 
 ip policy route-map classify_mark
 

В данном примере любой трафик, совпадающий со списком доступа 100, настраивается с уровнем 5 IP Precedence. Это означает, что для трех старших битов байта IP ToS установлено значение 101. В данном случае список доступа 100 совпадает с общими UDP-портами, используемыми VoIP и сигнальным трафиком H.323 к TCP-порту 1720.



Классификация модульного интерфейса командной строки QoS и примеры маркировки

Рекомендуемый способ классификации и маркировки — это функция классификации модульного интерфейса командной строки QoS (Mod QoS CLI или MQC). Он представляет собой способ настройки, основанный на шаблоне, который отделяет классификацию от политики, разрешая совместную настройку нескольких функций качества обслуживания для нескольких классов. Следует использовать карту классов для классификации трафика на основе различных критериев сопоставления и карту политики для определения развития событий для каждого класса. Затем к входящему или исходящему трафику на интерфейсе применяется политика с помощью команды настройки интерфейса service-policy. В следующем примере настройки показано использование модульного QoS для классификации и маркировки пакетов:

Пример настройки 4: Классификация и маркировка с использованием способа настройки MQC
access-list 100 permit udp any any range 16384 32767
 
access-list 100 permit tcp any any eq 1720
!
class-map voip 
 match access-group 100
!
policy-map mqc 
 class voip
  set ip precedence 5 
  <<#various other QoS commands>>
 class class-default 
  set ip precedence 0 
  <<#various other QoS commands>>
!
interface Ethernet0/0 
 service-policy input mqc
 

В данном примере любой трафик, совпадающий со списком доступа 100, будет отнесен к классу voip и настроен с уровнем 5 IP Precedence. Это означает, что для трех старших битов байта IP ToS установлено значение 101. В данном случае список доступа 100 совпадает с общими UDP-портами, используемыми VoIP и сигнальным трафиком H.323 к TCP-порту 1720. Прочие виды трафика настраиваются со значением 0 в битах IP Precedence. Такая политика называется mqc и применяется к входящему трафику на интерфейсе Ethernet 0/0.



Механизмы организации очередей QoS

После того как весь трафик распределен по классам в соответствии с требованиями к качеству обслуживания, следует обеспечить полосу пропускания и приоритетное обслуживание посредством механизма интеллектуальной организации выходной очереди. Данный раздел содержит описание механизма организации очереди и состоит из следующих подразделов:

Организация очереди с малым временем ожидания (LLQ)

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

Наиболее гибким способом организации очереди, удовлетворяющим требованиям VoIP-пакетов, является LLQ. Чтобы предоставить приоритет определенным классам и обеспечить минимально необходимую полосу пропускания для других классов, организация очереди с малым временем ожидания (LLQ) использует способ настройки MQC. Во время перегрузки очередь по приоритету ограничивается настройками скорости так, что приоритетный трафик не монополизирует всю доступную полосу пропускания. (Если приоритетный трафик монополизирует полосу пропускания, это препятствует предоставлению полосы пропускания для других классов.) Если все настройки LLQ выполнены должным образом, скорость трафика, поступающего в очередь по приоритету, не должна превышать заданного значения.

Организация очереди с малым временем ожидания также позволяет указывать глубину очереди. Это дает возможность определить, в какой момент времени маршрутизатор должен отбрасывать пакеты, если в очереди какого-либо конкретного класса находится слишком много пакетов. Кроме того, существует класс по умолчанию, который используется для определения способа обработки всего трафика, не отнесенного ни к одному сконфигурированных классов. Класс по умолчанию можно сконфигурировать командой настройки интерфейса fair-queue, которая означает, что каждому неклассифицированному потоку будет назначена приблизительно равная доля свободной полосы пропускания. На рис. 1 показано, как работает очередь с малым временем ожидания (LLQ).


Рис. 1. Работа очереди с малым временем ожидания (LLQ)


На рис. 1 весь трафик, исходящий из интерфейса или подчиненного интерфейса (для Frame Relay и ATM), сначала классифицируется с использованием способа настройки MQC. Существует четыре класса: один класс с высоким приоритетом, два класса с гарантированной полосой пропускания и класс по умолчанию. Трафик приоритетного класса помещается в приоритетную очередь, а трафик класса гарантированной полосы пропускания помещается в зарезервированные очереди. Трафику класса по умолчанию может быть назначена зарезервированная очередь или незарезервированная очередь по умолчанию, где каждый поток получит приблизительно равную долю незарезервированной и доступной полосы пропускания. Планировщик обслуживает очереди таким образом, что трафик приоритетной очереди выводится первым, за исключением случаев, когда трафик превышает заданную приоритетную полосу пропускания, и эта полоса пропускания необходима зарезервированной очереди (то есть в случае перегрузки). Зарезервированные очереди обслуживаются в соответствии с зарезервированной для них полосой пропускания, которая используется планировщиком для вычисления веса. Вес используется для определения частоты обслуживания зарезервированной очереди и количества одновременно обслуживаемых байтов. Услуги планировщика основаны на алгоритме взвешенной равноправной очередности (weighted fair queueing, WFQ), рассмотрение которого выходит за рамки данного документа.

Когда приоритетная очередь заполняется из-за того, что скорость передачи приоритетного трафика превышает заданную приоритетную полосу пропускания, пакеты в конце приоритетной очереди отбрасываются только в том случае, если не осталось ни одной доступной незарезервированной полосы пропускания. Если полоса пропускания доступна, ни одна из зарезервированных очередей не ограничивается настроенной полосой пропускания. Пакеты, не соответствующие настройкам гарантированной полосы пропускания и приоритетам, отбрасываются только во время перегрузки сети. Поэтому для обработки всего VoIP-трафика, требующего приоритетного обслуживания, необходимо обеспечить приоритетную очередь достаточной полосой пропускания.

Пример конфигурации LLQ

В следующем примере показана настройка LLQ:

Пример настройки 5: LLQ
access-list 100 permit udp any any range 16384 32000
 
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
access-list 102 permit tcp any any eq 23
!
class-map voip 
 match access-group 100
class-map data1
 match protocol
class-map data2 
 match access-group 102
!
policy-map llq 
 class voip 
  priority 32 
 class data1 
  bandwidth 64 
 class data2 
  bandwidth 32 
 class class-default 
  fair-queue
!
interface Serial1/0 
 bandwidth 256 
service-policy output llq
 

В данном примере любой трафик, совпадающий со списком доступа 100, относится к классу voip (то есть рассматривается как голосовой трафик) и получает высокий уровень приоритета — до 32 Кбит/с. В данном случае список доступа 100 совпадает с общими UDP-портами, используемыми VoIP и сигнальным трафиком H.323 к TCP-порту 1720. Команда class data1 соответствует Интернет-трафику (TCP-порт 80, как это видно из списка доступа 101) и гарантирует 64 Кбит/с; команда class data2 соответствует Telnet-трафику (TCP-порт 23, как это видно из листа доступа) и гарантирует 32 Кбит/с. Класс по умолчанию настроен так, чтобы поровну разделить оставшуюся пропускную способность между неклассифицированными потоками. Такая политика называется llq и применяется к исходящему трафику на последовательном интерфейсе 1/0, общая полоса пропускания которого составляет 256 Кбит/с.


Примечание   Необходимо, чтобы заданная по умолчанию общая гарантированная полоса пропускания и приоритетная полоса пропускания для всех классов занимали менее 75 процентов пропускной способности интерфейса. Данное процентное соотношение можно изменить с помощью команды настройки интерфейса max-reserved bandwidth.



Другие механизмы организации очередей QoS

Существуют и другие способы организации очередей. Например, измененный механизм кругового обслуживания с дефицитом (MDRR) — это механизм организации очереди, доступный на гигабитных коммутирующих маршрутизаторах (GSR) серий Cisco 12000. Этот механизм гарантирует полосу пропускания и приоритетное обслуживание, основанное на протоколах IP Precedence, DSCP и классах MPLS EXP. MDRR поддерживает одну приоритетную очередь, семь зарезервированных очередей и одну многоадресную очередь.

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

Таблица 1 описывает доступное программное обеспечение механизмов организации очередей.


Таблица 1: Программное обеспечение механизмов организации очереди
Программное обеспечение механизмов организации очереди Описание Преимущества Ограничения
FIFO

Пакеты покидают очередь в порядке поступления.

Простая настройка и быстрая работа.

Невозможно гарантировать приоритетное обслуживание или полосу пропускания.

WFQ

С помощью алгоритма хэширования потоки разделяются на очереди, где для определения количества одновременно обслуживаемых пакетов используется вес. Вес определяется путем установки битов IP Precedence и значений DSCP.

Простая конфигурация. Используется по умолчанию для каналов менее 2 Мбит/с.

Невозможно гарантировать приоритетное обслуживание или полосу пропускания.

Настраиваемая очередь (CQ)

Трафик классифицируется по нескольким очередям с настраиваемым максимальным размером очереди. Максимальный размер очереди вычисляется на основе среднего размера пакета, максимальной единицы передачи данных (MTU) и процентной доли выделенной полосы пропускания. Максимальный размер очереди (в байтах) рассматривается вне очередности для каждой очереди, поэтому обеспечивает выделенную полосу пропускания статистически.

Используется уже в течение нескольких лет, разрешает приближенное выделение полосы пропускания для различных очередей.

Приоритетное обслуживание невозможно. Выделение полосы пропускания выполняется приближенно. Существует ограниченное число очередей. Относительно сложная настройка.

Очереди по приоритетам (PQ)

Трафик распределяется по очередям с высоким, средним, обычным и низким приоритетом. Сначала обслуживается трафик с высоким приоритетом, затем трафик со средним, обычным и низким приоритетами.

Используется уже в течение нескольких лет, предоставляет приоритетное обслуживание.

В очереди с более низким приоритетом возможно возникновение дефицита полосы пропускания у трафика с более высоким приоритетом. Невозможно гарантировать полосу пропускания.

Механизм взвешенной равноправной очередности на основе классов (Class-Based WFQ, CBWFQ)

Для классификации трафика используется способ настройки MQC. Классифицированный трафик помещается в резервированные очереди полосы пропускания или же, по умолчанию, в нерезервированные очереди. Планировщик обслуживает очереди на основе весов с учетом гарантированного выделения полосы пропускания.

Похожий механизм используется в LLQ, за исключением того, что в нем не существует приоритетной очереди. Простая конфигурация и возможность обеспечить гарантированную полосу пропускания.

Приоритетное обслуживание невозможно.

Механизм взвешенной равноправной очередности по приоритетам (PQ-WFQ, так называемый приоритет IP-пакета RTP)

Для предоставления приоритетного обслуживания всем пакетам UDP, направляемым на четные номера портов в указанном диапазоне, необходима всего одна команда.

Простая настройка, вызов одной командой. Предоставляет приоритетное обслуживание для пакетов RTP.

Прочие виды трафика обслуживаются при помощи механизма WFQ. RTCP-трафику приоритеты не присваиваются. Возможности полосы пропускания не гарантируются.

LLQ (ранее называемая PQ-CBWFQ)

Для классификации трафика используется способ настройки MQC. Классифицированный трафик помещается в очередь с приоритетами, очередь с зарезервированной полосой пропускания или, по умолчанию, в незарезервированную очередь. Планировщик обслуживает очереди на основе весовых значений, таким образом, приоритетный трафик отправляется первым (в периоды перегрузки сети — в пределах заданного максимального значения), и выполняются требования по выделению гарантированной полосы пропускания.

Простая конфигурация. Возможность предоставлять приоритеты разнообразным классам трафика и задавать верхние границы приоритетного использования полосы пропускания. Можно также настраивать классы гарантированной полосы пропускания и класс по умолчанию.

Пока не существует механизма предоставления нескольких уровней приоритета, и весь приоритетный трафик посылается через одну приоритетную очередь. Отдельные приоритетные классы могут иметь отдельные значения приоритетной полосы пропускания во время перегрузки, но распределение приоритетной очереди между приложениями может привести к флуктуации сигнала.



Фрагментация и чередование

Так как передача по протоколу VoIP в высшей степени чувствительна к задержкам, VoIP-пакеты необходимо вставлять между или чередовать с фрагментами пакетов данных. Данный раздел содержит описание механизма фрагментации и чередования и состоит из следующих подразделов:

Фрагментация и чередование: обзор

Даже если организация очереди работает наилучшим образом и назначает приоритеты голосовому трафику, бывают случаи, когда приоритетная очередь пуста, и обслуживается пакет из другого класса. Пакеты, относящиеся к классам с гарантированной полосой пропускания, необходимо обслуживать в соответствии с настройками их веса. Eсли во время их обслуживания в исходящую очередь прибывает приоритетный VoIP-пакет, то его отправка может занять длительное время. Можно вычислить время ожидания, основываясь на скорости соединения. Для этого предположим, что VoIP-пакету потребуется ожидать позади одиночного пакета данных, и что этот размер этого пакета данных не может быть больше MTU (1500 байтов для последовательного и 4470 байтов для высокоскоростного последовательного интерфейсов).

Например, при скорости соединения 64 Кбит/с и размере MTU 1500 байтов, получается следующее:

    Serialization delay = (1500 bytes * 8 bits/byte)  /  (64,000 bits/sec) = 187.5 ms
     
    

В результате ожидание отправки VoIP-пакета может занять до 187,5 мс, если при соединении на скорости 64-Кбит/с он задерживается позади одиночного 1500-байтного пакета. VoIP-пакеты обычно отправляются каждые 20 мс. При сквозном балансе задержек 150 мс и строгих требованиях к флуктуациям сигнала интервал более 180 мс недопустим.

Необходим механизм, гарантирующий, что размер единицы передачи меньше 10 мс. Любые пакеты, для преобразования которых в последовательность требуется более 10 мс, должны разбиваться на фрагменты по 10 мс. каждый. Фрагмент размером 10 мс — это количество байтов, которые можно послать по каналу за 10 мс. Для вычисления размера фрагмента можно использовать скорость соединения:

    Fragmentation size = (0.01 seconds * 64,000 bps) / (8 bits/byte) = 80 bytes
     
    

При скорости соединения 64 Кбит/с 10 мс занимает отправка пакета размером 80 байтов.

На низкоскоростных каналах, где пакеты размером в 10 мс меньше MTU, также требуется фрагментация. Однако простой фрагментации недостаточно, поскольку если VoIP-пакету приходится ожидать отправки после всех фрагментов большого одиночного пакета данных, то задержка VoIP-пакета может превысить максимальную сквозную задержку. Необходимо чередовать VoIP-пакет с фрагментами пакетов данных или вставлять его между ними. На рис. 2 показаны фрагментация и чередование.


Рис. 2. Фрагментация и чередование VoIP-пакетов


В таблице 2 приведены рекомендованные размеры фрагментов для различных скоростей соединения, основанные на правиле 10 мс.


Таблица 2: Скорость соединения и размеры фрагментов

Скорость соединения (Кбит/с) Размер фрагмента (байт)

56

70

64

80

128

160

256

320

512

640

768

960

1024

1280

1536

1920 (Фрагментация не требуется, если размер фрагмента больше размера MTU для канала. Например, для канала T1, где MTU=1500 байт, размер фрагмента равен 1920 байтам, поэтому фрагментация не нужна).




Примечание   Размер фрагментов пакета не должен быть меньше размера VoIP-пакета. VoIP-пакеты фрагментировать нельзя, так как это может вызвать многочисленные проблемы с настройкой и качеством.

Существуют три механизма фрагментации и чередования каналов (LFI). В таблице 3 приведены все их преимущества и ограничения.


Таблица 3: Скорость соединения и размеры фрагментов
Механизм LFI Описание Преимущества Ограничения
Фрагментация MTU с помощью механизма WFQ

Команды изменения размера MTU или IP MTU, применяемые на уровне интерфейса. Используется для фрагментации больших IP-пакетов до указанного размера MTU. LFI использует WFQ для чередования пакетов реального времени и фрагментов.

Простая конфигурация.

Фрагменты собираются заново только приложением-получателем, поэтому использование сети оказывается неэффективным. Фрагментация оказывается удачной только при использовании IP-пакетов, где нет бита Don't Fragment (DF) (Не фрагментировать). Создает высокую нагрузку на процессор. Не рекомендуется.

Фрагментация и чередование канала (LFI) в протоколе многоканальной двухточечной связи (MLP)

На последовательных двухточечных каналах необходимо сначала настроить протокол MLP, а затем задать размер фрагментации в миллисекундах. Также должно быть включено чередование для многоканального интерфейса.

Пакеты фрагментируются на одном конце канала связи и повторно собираются на другом. Можно объединить несколько каналов, чтобы они действовали как большой виртуальный канал.

Доступно только на каналах, настроенных для PPP. Начиная с версии 12.1(5)T, Cisco IOS поддерживает решения для PPP по протоколам Frame Relay или PPP в режиме ATM.

Фрагментация в протоколе Frame Relay (FRF.12)

Для PVC-каналов Frame Relay необходимо включить команду настройки интерфейса frame-relay traffic-shaping и установить параметр fragmentation size в разделе map class.

Пакеты фрагментируются на одном конце постоянного виртуального канала и вновь собираются на другом.

Доступны только для PVC-каналов Frame Relay с активированной командой настройки интерфейса frame-relay traffic-shaping.



Пример фрагментации и чередования трафика канала MLP

В следующем примере показана настройка фрагментации и чередования с использованием протокола MLP LFI:

Пример настройки 6: протокол MLP LFI
interface Serial1/0 
 
 bandwidth 256 
 encapsulation ppp 
 no fair-queue 
 ppp multilink 
 multilink-group 1
!
interface Multilink1 
 ip address 10.1.1.1 255.255.255.252 
 bandwidth 256 
 ppp multilink 
 ppp multilink fragment-delay 10 
 ppp multilink interleave 
 multilink-group 1
 

В данном примере протокол MLP LFI настроен на размер фрагментов 10 мс, который вычисляется на основе полосы пропускания, настроенной для многоканального интерфейса. Последовательный интерфейс 1/0 помещается в многоканальную группу 1 и поэтому наследует многоканальную конфигурацию в многоканальном интерфейсе 1.



Пример фрагментации и чередования трафика канала FRF.12

В следующем примере показана настройка фрагментации и чередования с использованием FRF.12:

Пример настройки 7: Фрагментация Frame Relay (FRF.12) LFI
interface Serial 0/1 
 
 no ip address 
 encapsulation frame-relay 
 frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point 
 ip address 10.14.96.2 255.255.255.252 
 frame-relay interface-dlci 128 
  class voice
!
map-class frame-relay voice 
 frame-relay cir 256000 
 frame-relay fragment 320
 

В данном примере формирование трафика Frame Relay активировано на идентификаторе DLCI 128, а FRF.12 настроен на размер фрагментов 320 байтов, или 10 мс согласованной скорости передачи данных (CIR). Необходимо, чтобы размер фрагментов 10 мс был определен для низкой скорости на портах оконечных устройств PVC-канала. Данный пример подразумевает, что согласованная скорость передачи данных и низкая скорость на портах одинаковы, а именно 256 Кбит/с.



Формирование трафика

Формирование трафика представляет собой технологию в рамках механизма QoS для передачи трафика короткими блоками при заданной в настройках скорости передачи данных. Он чаще всего используется в средах Frame Relay, где частота синхронизации интерфейса не совпадает с гарантированной полосой пропускания или согласованной скоростью передачи данных. Данный раздел содержит описание формирования трафика и состоит из следующих подразделов:

Обзор формирования трафика

Формирование трафика Frame Relay — это наиболее распространенное приложение формирования трафика в средах VoIP. Сценарии Frame Relay обычно предусматривают сеть типа «звезда», где скорость канала концентратора выше, чем любая из скоростей удаленных каналов. В некоторых случаях сумма скоростей удаленных каналов превосходит скорость канала концентратора, что приводит к их недостаточной загрузке. Если формирование трафика Frame Relay не производится, концентратор может пытаться отправить трафик на скоростях, превышающих скорость приема на удаленных узлах, вызавая произвольное отбрасывание трафика сетью Frame Relay. Кроме того, все удаленные узлы могут послать трафик на суммарной скорости, превышающей возможности его получения концентратором, что также приводит к произвольному отбрасыванию трафика сетью Frame Relay. Говоря о сети Frame Relay, мы подразумеваем поставщика услуг (SP) сети коммутаторов WAN, который предоставляет возможность подключения сквозного постоянного виртуального канала PVC. Поскольку облако WAN SP может не иметь логики Layer 3 или выше, оно отбрасывает трафик VoIP, если контракты нарушены. Следовательно, необходимо управлять скоростями передачи в облако Frame Relay так, чтобы получить возможность контролировать, какие пакеты отбрасываются, а какие получают приоритетное обслуживание. На рис. 3 показан типичный пример сети Frame Relay без формирования трафика.


Рис. 3. Сеть Frame Relay


Пример формирования трафика Frame Relay

В следующем примере показана настройка формирования трафика Frame Relay:

Пример настройки 8: Формирование трафика Frame Relay
interface Serial 0/1 
 
 no ip address 
 encapsulation frame-relay 
 frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point 
 ip address 10.14.96.2 255.255.255.252 
 frame-relay interface-dlci 128 
  class voice
!
map-class frame-relay voice 
 no frame-relay adaptive-shaping 
 frame-relay cir 256000 
 frame-relay bc 2560 
 frame-relay mincir 256000
 

В данном примере формирование трафика Frame Relay активируется на основном последовательном интерфейсе 0/1, и протокол DLCI 128 помещен в класс формирования голоса. Команда map class voice устанавливает для согласованной скорости (CIR) значение 256000 бит/с и согласованную скорость передачи блока (Bc) 2560 битов. Данная настройка означает, что маршрутизатор отправляет 2560 битов каждые 2560/256,000 секунд (10 мс) и ставит в очередь все избыточные блоки. Для минимальной согласованной скорости передачи данных установлено то же значение, что и для CIR, а адаптивное формирование отключено. Значение избыточного блока (Be) Frame Relay не установлено, поэтому по умолчанию равно 0, что предотвращает любые пакетные передачи на согласованной скорости (CIR). Эта настройка рекомендуется для формирования трафика во время передачи VoIP.



Сжатие заголовков IP RTP

Сжатие заголовков IP RTP уменьшает 40-байтный заголовок IP+UDP+RTP до 2-4 байтов, тем самым, уменьшая полосу пропускания, запрашиваемую для голосового вызова на двухточечных каналах. Заголовок сжимается на одном конце канала и распаковывается на другом. Другое стандартное название для этого метода — cRTP, что значит «сжатый RTP». На рис. 4 показаны функциональные возможности сжатия заголовка RTP.


Рис. 4. Сжатие заголовков RTP


Для настройки сжатие заголовка IP RTP следует настроить команду ip rtp header-compression в области последовательного интерфейса или команду frame-relay ip rtp header-compression в области подчиненного интерфейса Frame Relay. Чтобы задать максимальное количество потоков, подлежащих сжатию, можно также настроить команду настройки интерфейса ip rtp compression-connections. Так как протокол cRTP может создавать высокую нагрузку на процессор, следует ограничить количество сжимаемых потоков. В противном случае произойдет существенное снижение производительности маршрутизатора. Сжатый RTP рекомендуется на низкоскоростных каналах, где принимается несколько VoIP-вызовов при дефиците полосы пропускания.

Дифференцированные услуги (DS) для VoIP

Модель архитектуры QoS с дифференцированными услугами (DS) предоставляет масштабируемый механизм для классификации пакетов по группам или классам, которые имеют сходные требования к качеству обслуживания. Данный раздел содержит описание DS и состоит из следующих подразделов:

DS и DSCP (RFC 2474, RFC 2475): обзор

В основе первых IP-сетей была модель обслуживания «с максимальными усилиями» (best-effort service). В такой модели задержка, флуктуации сигнала, потеря пакетов и выделение полосы пропускания были непредсказуемы. Сегодня большое количество сетей все еще следует модели «максимальных усилий» и не поддерживает усовершенствованные приложения, которые требуют определенных гарантий обслуживания.

Используя модель «максимальных усилий», поставщики услуг не имеют возможности предложить своим клиентам соглашения об уровне обслуживания (SLA), за исключением избыточного резервирования их сети для работы в часы наибольшей загрузки трафика. Корпоративные клиенты и конечные пользователи не имеют ни малейшей возможности получить приоритетную обработку или гарантированную полосу пропускания для VoIP-пакетов. Трафик обрабатывается на основе принципа FIFO (первым поступил — первым обслужен), без принудительного обеспечения качества обслуживания.

Сначала архитектура метода предоставления сквозного качества обслуживания требовала, чтобы приложение передавало в сеть сигнал о своих требованиях к ресурсам для обеспечения качества обслуживания (таким, как полоса пропускания и гарантированная задержка). В условиях VoIP такая архитектура означает, что для выполнения запросов QoS к каждому участку сети для выделения ресурсов по всему маршруту нужен IP-телефон или голосовой шлюз. Каждый участок должен поддерживать сведения о состоянии вызовов, для того чтобы определять, когда следует освободить ресурсы QoS для других вызовов или приложений и при наличии достаточных свободных ресурсов принять вызовы с гарантированным качеством обслуживания. Этот способ называется «модель комплексных услуг качества обслуживания». Наиболее распространенная реализация модели комплексных услуг использует протокол резервирования ресурсов (Resource Reservation Protocol, RSVP). Протокол RSVP обладает некоторыми преимуществами, такими как контроль за установлением вызова (Call Admission Control, CAC): если для поддержания вызова в сети нет доступных ресурсов качества обслуживания, система перенаправляет звонок, посылая соответствующий сигнал отправителю. Однако у RSVP есть некоторые проблемы, связанные с масштабируемостью. Протокол RSVP и указанные проблемы рассматривается далее в этом документе.

На сегодняшний день архитектура DS является наиболее широко используемой и поддерживаемой моделью качества обслуживания. Она предоставляет расширяемый механизм для распределения пакетов по группам и классам, имеющим сходные требования к качеству обслуживания, и, таким образом, обеспечивает требуемое обслуживание этих групп на каждом участке сети. Масштабируемость основана на том, что пакеты классифицируются на границах «облака» DS или области и соответственно маркируются таким образом, что опорные маршрутизаторы в облаке могут предоставлять качество обслуживания, основываясь просто на классе DS. Шесть старших битов байта IP-типа обслуживания (ToS) используются для указания DS-класса и определяются дифференцированными кодами обслуживания (DSCP). Остальные два бита байта IP ToS в данный момент не используются.

На рис. 5 показано, как определять DS-класс с помощью IP-заголовка.


Рис. 5. Определение поля дифференцированного обслуживания


Описание и определения дифференцированного обслуживания даны в следующих RFC:

  • RFC 2474, Definition of the Differentiated Service Field (DS Field)

  • RFC 2475, An Architecture for Differentiated Service

  • RFC 2597, Assured Forwarding PHB Group

  • RFC 2598, An Expedited Forwarding PHB

RFC 2474 предлагает способ интерпретации поля, которое всегда было частью IP-пакета. Как уже упоминалось в этом документе ранее, поле ToS — это один целый байт (восемь битов) IP-пакета. Приоритет определяется по трем старшим битам байта ToS, например, [123]45678. (В частности, термин «ToS» используется для обращения к следующим трем битам: 123[456]78. Однако для соответствия исходной спецификации RFC заголовка IP (RFC 791) ToS в данном документе обращается к целому набору из восьми битов.)

Первые три бита DSCP используются как биты выбора класса. Биты выбора класса делают протокол DSCP совместимым с протоколом IP Precedence, так как в протоколе IP Precedence для определения класса используются те же три бита. Таблица 4 содержит значения битов IP Precedence, соответствующие протоколу DSCP.


Таблица 4: Сопоставление протокола IP Precedence с протоколом DSCP

Протокол IP Precedence Значение битов IP Precedence Биты DSCP Классы DSCP
5

101

101000

Срочная доставка

4

100

100000

Гарантированная доставка 4

3

011

011000

Гарантированная доставка 3

2

010

010000

Гарантированная доставка 2

1

001

001000

Гарантированная доставка 1

0

000

000000

«Максимальные усилия»



Следующие два бита используются для определения приоритет отбрасывания. Например, если трафик класса 4 (первые три бита 100) превышает некоторую согласованную скорость, избыточные пакеты могут не отбрасываться, а быть заново маркированы с более высоким приоритетом отбрасывания. Если перегрузка возникла в облаке DS, первыми отбрасываемыми пакетами будут пакеты с «высоким приоритетом отбрасывания». То же происходит и в случае с маркировкой DE-бита в протоколе Frame Relay, и в случае с маркировкой CLP-бита в протоколе ATM. Данные механизмы позволяют сети Layer 2 принять в периоды перегрузки интеллектуальные решения об отбрасывании для трафика, не соответствующего критериям. DS разрешает подобные действия в IP-сети. Чтобы указать сетевым устройствам, что классы были заданы в соответствии со стандартом DS, необходимо задать для шестого бита значение 0.

Архитектура DS определяет набор формирователей трафика для его ограничения в области DS и помещения его в соответствующие классы DS. Формирователи трафика — это измерители, маркировщики, формировщики и отсекатели. По сути, измерители являются ограничителями, а основанное на классах определение политик (которые настраиваются с помощью команды police policy-map configuration в области любого класса механизма Modular QoS CLI) является DS-совместимой реализацией измерителя. Чтобы настроить DSCP и основанное на классах формирование в качестве формировщика, можно использовать основанную на классах маркировку. Взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detect, WRED) является поддерживаемым механизмом отсекателя, однако не следует использовать WRED в классе VoIP. PHB-политика (поведение на каждом участке) описывает все события в классе DS в терминах потерь, задержки и флуктуаций сигнала. PHB-политика определяет, как назначается полоса пропускания, как ограничивается трафик и как пакеты отбрасываются во время перегрузки.

В DS определены три PHB-политики на основе требуемого поведения при доставке:

  • Класс «с максимальным усилием»: для битов выбора класса установлено значение 000

  • PHB-политика гарантированной доставки: для битов выбора класса установлено значение 001, 010, 011 или 100

  • PHB-политика срочной доставки: для битов выбора класса установлено значение 101

Стандарт гарантированной доставки (AF) определяет четыре класса гарантированной полосы пропускания и описывает обработку, которую надлежит получить каждому из них. В стандарте оговариваются уровни приоритета отбрасывания, которые сводятся к 12 возможным классам AF, как показано в таблице 5.


Таблица 5: Возможные классы гарантированной доставки пересылки

Уровни приоритета отбрасывания Класс AF1 Класс AF2 Класс AF3 Класс AF4
Низкий приоритет отбрасывания

001010

010010

011010

100010

Средний приоритет отбрасывания

001100

010100

011100

100100

Высокий приоритет отбрасывания

001110

010110

011110

100110



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

Внедрение DS для VoIP: PHB-политика срочной доставки (RFC 2598)

Срочная доставка (EF) предусмотрена для чувствительных к задержкам приложений, которые запрашивают гарантированную полосу пропускания. Маркировка EF гарантирует приоритетное обслуживание путем резервирования некоторого минимального размера полосы пропускания, которая может использоваться для трафика с высоким приоритетом. При срочной доставке выходная скорость (или заданная приоритетная полоса пропускания) должна быть больше или равна сумме входных скоростей, поэтому для пакетов с маркировкой «EF» перегрузок не бывает. Политика EF реализуется путем использования очереди со строгими приоритетами в рамках организации очереди с малым временем ожидания (LLQ). Трафику, принадлежащему к классу EF, гарантируется постоянная полоса пропускания. В то же время, в условиях перегрузки несоответствующие критериям пакеты, превышающие указанную приоритетную скорость, отбрасываются. Это гарантирует, что пакеты в других очередях, принадлежащих к разным классам, не страдают от недостатка полосы пропускания. Рекомендуемое значение DSCP для EF: 101110 (46). Первые три бита этого значения EF соответствуют уровню 5 IP Precedence, который является рекомендуемым параметром для команды ip precedence, используемой для конфигурации точки набора номера для VoIP-трафика. Поэтому можно обеспечить сквозное качество обслуживания, если устройства IP в сети могут распознавать биты IP Precedence или DSCP в целях классификации и маркировки.

Пример настройки маркировки DSCP на основе классов

Архитектура DS определяет способы классификации, маркировки, ограничения и формирования трафика, входящего в область DS, а также способы обработки разных классов на каждом участке области DS. На границе DS все IP-пакеты маркируются соответствующими битами DSCP, поэтому можно предоставить качество обслуживания, основываясь на битах DSCP внутри области DS. В следующем примере показана настройка маркировки DSCP на границе путем маркировки на основе классов:

Пример настройки 9: Маркировка на основе классов DSCP
access-list 100 permit udp any any range 16384 32000
 
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
!
class-map voip 
 match access-group 100
class-map webtraffic 
 match access-group 101
!
policy-map dscp_marking 
 class voip 
  set ip dscp 46   #EF Class 
 class webtraffic 
  set ip dscp 26   #AF Class
!
interface Ethernet0/0 
 service-policy input dscp_marking
 
В данном примере весь трафик, входящий на интерфейс Ethernet 0/0, проверяется и классифицируется на основе схем классов voip и webtraffic. Команда глобальной настройки policy-map устанавливает в трафике класса voip значение DSCP 46 (101110 для EF); в трафике класса webtraffic — 26 (011010 для AF3).


Теперь можно настроить все параметры очереди и другие параметры QoS для соответствия DSCP в остальной области DS.

В остальных разделах данного документа мы сравним трафик IP Precedence 5 по протоколу VoIP и трафик IP Precedence 3 по протоколу HTTP (Интернет-трафик) с прочими видами трафика, входящими в класс по умолчанию. Аналогичным образом DSCP 46 можно применять для VoIP, а DSCP 26 — для HTTP. Можно применять и другие классификации и механизмы маркировки, однако для согласованности и простоты мы используем протокол IP Precedence

Resource Reservation Protocol (RSVP)

Протокол резервирования ресурсов (RSVP) представляет собой реализацию архитектуры комплексных услуг для QoS (RFC 2205). После внедрения VoIP протокол RSVP незамедлительно стал ключевым компонентом, который предоставляет контроль доступа и качество обслуживания для VoIP-потоков. Однако способ, которым протоколы RSVP и H.323 были ранее интегрированы, не предоставлял ни контроль доступа, ни удовлетворительное качество обслуживания для голосовых потоков. Благодаря некоторым улучшениям, внедренным для преодоления этих ограничений, теперь можно использовать RSVP для реализации контроля за установлением вызова (CAC), а также для передачи сигнала о желаемом качестве обслуживания, которое обеспечит хорошее качество голоса даже в условиях перегрузки.

В данном разделе приводится общее описание протокола RSVP, при этом особое внимание уделяется конкретному подмножеству платформ, топологий и протоколов. Кроме того, предполагается, что в качестве протокола сеанса для сети VoIP на базе шлюза используется протокол H.323. Данный раздел состоит из следующих подразделов:

Обзор протокола RSVP

Первоначальная реализация протокола RSVP для VoIP имела два ограничения. Первое ограничение состояло в невозможности реализации механизма CAC в рамках протокола RSVP, поскольку процесс резервирования не был синхронизирован с передачей сигнала голосового вызова. Могла возникнуть ситуация, когда вызов продолжался, даже если резервирование RSVP не удалось или не было завершено. Второе ограничение заключалось в том, что успешное резервирование RSVP не всегда обеспечивало хорошее качество голоса во время перегрузки сети. Протокол RSVP создавал резервированный поток «одна очередь на трафик» внутри системы WFQ и полагался на данную систему, чтобы гарантировать ограничение задержки. Однако в некоторых случаях система WFQ не могла обеспечить голосу приемлемое ограничение задержки. Требовалось, чтобы протокол RSVP мог использовать приоритетную очередь в LLQ. Это могло гарантировать такую ограниченную задержку, которая не влияла бы на качество голоса. Кроме того, протокол RSVP не поддерживался в каналах ATM или на сформированных постоянных виртуальных каналах (PVC) Frame Relay.

Чтобы улучшить качество обслуживания VoIP, необходимо использовать протокол RSVP только там, где это может положительно сказаться на качестве и функциональности. Преимущества использования протокола RSVP перевешивают его стоимость (с учетом затрат на управление, накладных расходов и влияния на производительность) только в условиях ограниченной полосы пропускания, когда в сети часто возникают перегрузки. Некоторые IP-среды имеют достаточную полосу пропускания, чтобы гарантировать соответствующее качество обслуживания без реализации механизма CAC для каждого вызова.

В программном обеспечении Cisco IOS для управления механизмом CAC на основе ресурсов были внедрены четыре механизма:

  • Функция перехода к аварийному режиму работы сети ТфОП. Данный способ полагается на зондирование сети с целью измерения задержки, флуктуаций сигнала и потерь. Он используется для оценки возможного ухудшения качества голоса во время вызова. (Возможное ухудшение, или «запланированный фактор ухудшения качества передачи» (Calculated Planning Impairment Factor — ICPIF), разъясняется в ITU-T G.113.) С помощью данного механизма можно задать несколько пороговых значений, которые позволят отклонять вызовы в случае перегрузки IP-сети.

  • Механизм CAC определен в ресурсах локального шлюза, таких как ЦП, память и количество вызовов. При помощи данного механизма можно настраивать пороговые значения, которые могут вызвать различные действия, такие как возврат вызова, отклонение вызова или воспроизведение сообщения.

  • Управление полосой пропускания через привратник H.323. Данный способ позволяет настраивать максимальную ширину полосы пропускания, которую привратники впоследствии выделяют для вызовов.

  • Протокол RSVP

В данном документе рассматривается только использование протокола RSVP для механизма CAC.

Обзор применения протокола RSVP для контроля за установлением вызова (CAC)

Использование протокола RSVP для механизма CAC VoIP требует синхронизации передачи сигнала установки вызова и передачи сигнала RSVP. Данная синхронизация гарантирует, что телефон вызываемого абонента звонит только после резервирования ресурсов для этого вызова. В случае, если резервирование завершилось неудачей или не было завершено в пределах предварительно заданногo отрезка времени, такая синхронизация позволяет голосовым шлюзам выбирать выполняемые действия до того, как настройка вызова переходит к этапу оповещения. Голосовой вызов влечет за собой двойное резервирование по протоколу RSVP, поскольку механизмы резервирования и контроля доступа, предоставляемые протоколом RSVP, однонаправлены. Каждый голосовой шлюз отвечает за инициирование и поддержание одного резервирования, направленного к другому голосовому шлюзу. Механизм CAC для VoIP-вызова завершается неудачей, если не удалось выполнить хотя бы одно резервирование. На рис. 6 показана последовательность пакетов, которыми обмениваются шлюзы во время настройки вызова, если для резервирования ресурсов используется RSVP.


Рис. 6. Настройка вызова с активированным RSVP


На рис. 6 исходный шлюз (OGW) инициирует вызов в направлении конечного шлюза (TGW). Чтобы инициировать вызов, исходный шлюз отправляет на конечный шлюз сообщение H.323 SETUP. Сообщение SETUP содержит настройки QoS, которые исходный шлюз считает приемлемыми для данного вызова. Конечный шлюз отвечает сообщением H.323 CALL PROCEEDING. Как исходный, так и конечный шлюзы инициируют запрос о резервировании, посылая сообщение RSVP PATH. Потоки пакетов обоих резервирований независимы друг от друга, кроме случаев неудачи при выполнении одного из них. В ожидании результатов резервирования конечный шлюз блокирует процесс настройки вызова. Контроль за установлением вызова осуществляет конечный шлюз. Его следует уведомить о том, что процесс резервирования в обоих направлениях завершился успешно. Конечный шлюз узнает, что резервирование было удачным, при получении сообщения RSVP RESV. Конечный шлюз определяет, что резервирование исходного шлюза завершилось удачно при получении из исходного шлюза сообщения RSVP RESV CONFIRMATION. Затем конечный шлюз разрешает продолжение настройки вызова: после получения уведомления о том, что вызываемый абонент находится в состоянии готовности, на исходный шлюз посылается сообщение H.323 ALERTING. Обычное разъединение инициируется, если после подключения вызова отправляется сообщение H.323 RELEASE COMPLETE. В таком случае шлюзы разрывают свои резервирования, посылая сообщения RSVP PATH TEAR и RESV TEAR.

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

  • Голосовой шлюз может выдавать отчет об ошибке вызова пользователю или коммутатору, доставившему вызов.

  • Вызов может быть перенаправлен по другому маршруту.

  • Вызов может быть подключен с качеством обслуживания «с максимальными усилиями».

Последний вариант возможен благодаря тому, что конечный шлюз получает сведения о приемлемом для вызова уровне качества обслуживания из собственной конфигурации, а также благодаря значению, включенному исходным шлюзом в сообщение H.323 SETUP. Если конечный и исходный шлюзы запрашивают качество обслуживания не «с максимальными усилиями», и хотя бы одно резервирование завершается неудачей, обслуживание вызова с «максимальными усилиями» возможно только в случае, когда оба шлюза согласны принять качество обслуживание «с максимальными усилиями». Если один из двух голосовых шлюзов не принимает обслуживание «с максимальными усилиями», возможно отключение и перенаправление вызова. Если шлюз настроен для отклонения вызова и создания отчета об ошибке, CAS-магистрали и аналоговые каналы формируют учащенный сигнал «занято». На магистралях CCS PRI будет сформировано сообщение Q.931 DISCONNECT с указанием причины «QoS unavailable» (49).

На рис. 7 показаны подробности вызова, отклоненного из-за ошибки резервирования, инициированного конечным шлюзом.


Рис. 7. Вызов, завершенный неудачей RSVP CAC из-за ошибки резервирования из конечного шлюза


Использование механизма CAC на базе протокола RSVP

Как упоминалось выше, чтобы улучшить качество обслуживания VoIP, необходимо использовать RSVP только там, где это может положительно сказаться на качестве и функциональности. Преимущества использования RSVP перевешивают затраты, только если полоса пропускания ограничена. Если нужно реализовать CAC для VoIP с применением RSVP, рекомендуется использование Cisco IOS версии 12.1(5)T или более поздней.

Чтобы сконфигурировать CAC для VoIP-вызовов с применением RSVP, выполните три следующих основных действия:

  • Активируйте синхронизацию между RSVP и передачей сигнала вызова. (Данная синхронизация активируется по умолчанию при запуске Cisco IOS версии 12.1(5)T или более поздней.

  • Чтобы запросить определенное качество обслуживание через RSVP, настройте голосовые шлюзы на обеих сторонах однорангового телефонного соединения VoIP.

  • Там, где велика вероятность перегрузки, активируйте RSVP и укажите максимальную полосу пропускания на всех каналах, по которым проходят голосовые пакеты.

В следующем примере показана настройка CAC для VoIP-вызовов с использованием RSVP:

Пример настройки 10: Развертывание CAC с использованием RSVP
hostname LongBay
 
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface Ethernet0/0
 ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
 bandwidth 1536
 ip address 10.10.1.1 255.255.255.0
 encapsulation ppp
 ip tcp header-compression iphc-format
 ip rtp header-compression iphc-format
 ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
 no ip address
 no logging event link-status
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!
 
ip route 0.0.0.0 0.0.0.0 10.10.1.2
 
!
voice-port 1/0:23
!
dial-peer voice 100 pots
 destination-pattern 2......
 no digit-strip
 direct-inward-dial
 port 1/0:23
!
dial-peer voice 300 voip
 destination-pattern 3......
 session target ipv4:10.77.39.129
 req-qos guaranteed-delay
 acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
!
end

В данном примере полностью показана настройка голосового шлюза и описаны команды для настройки CAC с использованием RSVP. В такой конфигурации голосовой шлюз может выступать в качестве исходного и конечного шлюзов. В данном примере голосовому сигналу приоритет не присваивается.



Конфигурация однорангового телефонного соединения по умолчанию запрашивает и принимает качество обслуживания VoIP-вызовов «с максимальными усилиями». Это передается на шлюз, не инициирующий резервирование RSVP для вызова, поскольку IP предоставляет обслуживание «с максимальными усилиями» по умолчанию. Два других варианта обслуживания: controlled-load или guaranteed-delay QoS. Данные виды обслуживания запрашивают передачу сигнала RSVP. Это делается с помощью команды настройки однорангового телефонного соединения req-qos. Строгость или слабость критериев механизма CAC зависит от требуемого качества обслуживания. Для настройки контроля приемлемого качества обслуживания используется команда настройки однорангового телефонного соединения acc-qos. Рекомендуется настроить исходный и конечный шлюзы, чтобы запрашивать и принимать гарантированную задержку.

Иногда, чтобы запросить и принять качество обслуживания «с максимальными усилиями», можно настроить неявное одноранговое телефонное соединение, соответствующее конечному шлюзу. Это одноранговое телефонное соединение действует в тех случаях, когда нет явного совпадения однорангового телефонного соединения.

Настройка ресурсов локального шлюза при отказе CAC

Как упоминалось ранее, можно настроить голосовой шлюз на выполнение различных действий в случае ошибки контроля за установлением соединения. Первый вариант состоит в том, чтобы настроить шлюзы для передачи сигнала пользователю или на коммутатор, доставивший вызов с учащенным сигналом «занято». В противном случае произойдет разъединение. Если вызов доставлен на шлюз коммутатором ISDN, можно точно настроить причины разрыва соединения Q.931, чтобы гарантировать правильную обработку вызова коммутатором. Причина «QoS unavailable» (49) указывается по умолчанию, если при вызове ISDN выполнение CAC завершается неудачей из-за настроек запрашиваемого и приемлемого качества обслуживания. Можно изменить эту причину командой настройки интерфейса isdn network-failure-cause или isdn disconnect-cause. Текущая реализация команды isdn network-failure-cause используется вместо значения, установленного с использованием команды isdn disconnect-cause.

В следующем примере показана настройка ресурсов локального шлюза путем точной настройки причины разъединения Q.931 в случае ошибки механизма CAC:

Пример настройки 11: Точная настройка причины разъединения O.931
!
 
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn network-failure-cause 42
isdn incoming-voice voice
no cdp enable
!
 

В данном примере маршрутизатор посылает сообщение Q.931 DISCONNECT, содержащее причину «Switching Equipment Congestion» (42), когда вызов ISDN завершается ошибкой CAC в линии VoIP.



Вторая возможность состоит в том, чтобы разрешить шлюзу перенаправлять вызов по другим маршрутам. Если одноранговое телефонное соединение, согласованное вызовом, является частью поисковой группы, другие одноранговые телефонные соединения в этой группе выполняются в соответствии с командой настройки однорангового телефонного соединения preference. Это позволяет реализовывать разные типы маршрутизации вызовов на шлюзе, который рассматривает качество обслуживания во всех IP-сетях.

В следующем примере показана настройка ресурсов локального шлюза путем перенаправления вызовов на шлюз в случае ошибки механизма CAC:

Пример настройки 12: Перенаправление вызова на шлюз
dial-peer voice 100 pots
 
 destination-pattern 2......
 no digit-strip
 direct-inward-dial
 port 1/0:23
!
dial-peer voice 300 voip
 preference 0
 destination-pattern 3......
 session target ipv4:10.77.39.129
 req-qos guaranteed-delay
 acc-qos guaranteed-delay
!
dial-peer voice 400 voip
 preference 2
 destination-pattern 3......
 session target ipv4:10.23.45.2
 req-qos guaranteed-delay
 acc-qos guaranteed-delay
!
dial-peer voice 500 pots
 preference 5
 destination-pattern 3......
 no digit-strip
 direct-inward-dial
 port 1/1:23
!
 

В данном примере показано, как перенаправить вызов на шлюз. Вызовы семизначных номеров, начинающихся с цифры 3, сначала опробуют два голосовых шлюза. Если VoIP-вызовы завершаются ошибкой из-за механизма CAC или по любой другой причине, вызовы направляются по ТфОП через голосовой порт 1/1:23.



Третья возможность, доступная в версиях Cisco IOS, более новых, чем версия 12.1(5)T, состоит в том, чтобы настроить шлюзы для обработки вызова, даже если резервирование RSVP завершилось неудачей. Данная возможность, однако, не обеспечивает значительного улучшения по сравнению с функциональности более ранних версий Cisco IOS. Единственным преимуществом является то, что, в случае успешного резервирования по протоколу RSVP, вызов не выполняется до установки резервирования.

Как упоминалось ранее, при вызове может произойти ошибка контроля установления соединения, если не удалось выполнить хотя бы одно из двух резервирований RSVP, необходимых для вызова. Для каждого резервирования RSVP контроль установления соединения выполняется на всех интерфейсах, где RSVP активирован с помощью команды настройки интерфейса ip rsvp bandwidth. Командой ip rsvp bandwidth можно сконфигурировать два значения: общую максимальную ширину зарезервированной полосы пропускания и максимальную ширину полосы пропускания на одно резервирование. Общая максимальная ширина полосы пропускания по умолчанию должна составлять не более 75% всей полосы пропускания интерфейса. Это ограничение можно изменить командой настройки интерфейса max-reserved-bandwidth. Исключения для ограничений общей максимальной ширины полосы пропускания представляют PVC-каналы Frame Relay и ATM. Для PVC-каналов Frame Relay предельная ширина резервируемой полосы пропускания равна минимальному значению CIR, или, если эта полоса не настроена, — половине CIR. Для PVC-каналов ATM предельная ширина резервируемой полосы пропускания равна 75% доступной скорости передачи, указанной в настройках, а именно, выходной минимальной скорости передачи ячеек, или выходной скорости SCR с VBR режима почти реального времени, или средней скорости передачи в реальном времени VBR. Общая ширина полосы пропускания, доступная для резервирования RSVP, может быть меньше, если полоса пропускания зарезервирована с использованием способов организации очереди CBWFQ или LLQ через настройку MQC. Диспетчер полосы пропускания в процессе управления операциями маршрутизации проверят, не превышают ли лимит интерфейс или полоса пропускания PVC-канала.


Примечание   Эта проверка не выполняется в процессе настройки маршрутизатора.

Необходимо настроить максимальную ширину полосы пропускания для каждого резервирования так, чтобы она не была меньше запрашиваемой кодеком, плюс служебная информация протокола, за исключением служебной информации протокола Layer 2. В таблице 6 показаны минимальные значения, которые можно использовать для разных кодеков. Следует помнить, что данные значения не учитываются функцией экономии полосы пропускания, представленной в протоколе cRTP или в функции обнаружения активности речи (voice activity detection, VAD). Действующий голосовой поток может использовать меньшую полосу пропускания, но в системе используется наихудший вариант полосы пропускания.


Таблица 6: Полоса пропускания, зарезервированная RSVP на каждый VoIP-вызов
Кодек Зарезервированная полоса пропускания на каждый VoIP-вызов (Кбит/с)
G711alaw

80

G711ulaw

80

G723ar53

22

G723ar63

23

G723r53

22

G723r63

23

G726r16

32

G726r24

40

G726r32

48

G728

32

G729br8

24

G729r8

24

GSMEFR

29

GSMFR

30



Особенностью применения RSVP для VoIP является влияние резервирования ресурса на задержку после набора номера. Реализация механизма CAC VoIP на основе протокола RSVP зависит от немедленного подтверждения или отклонения запрашиваемого резервирования. Время, затраченное на резервирование ресурсов, добавляется к задержке после набора номера, которая в большинстве случаев должна быть как можно меньшей. RSVP-пакеты передаются внутри IP-дата граммы, и по своей сути ненадежны. Если во время настройки начального резервирования RSVP-пакет теряется, необходимо завершить действие RSVP-таймера обновления до повторной отправки потерянного пакета. Поскольку значение таймера обновления обычно определяется в десятках секунд, увеличение задержки после набора номера неприемлемо для пользователя. Команда глобальной настройки call rsvp-sync resv-timer позволяет контролировать максимальное время ожидания конечным шлюзом результатов запросов резервирования по протоколу RSVP. Значение данного таймера, заданное по умолчанию, равно 10 секундам, но его можно настроить в диапазоне от 1 до 60 секунд в соответствии с вероятной задержкой после набора номера.

Использование протокола RSVP с механизмом LLQ

Потоки, запрашивающие конкретное качество обслуживания по протоколу RSVP, могут воспользоваться преимуществами механизма организации очереди LLQ, который состоит из двух основных компонентов: жесткой очереди по приоритетам (PQ) и системы CBWFQ. Более ранние реализации RSVP полагались на соответствие WFQ требованиям к качеству обслуживания чувствительного к задержке трафика. Если установлено резервирование RSVP, создается зарезервированная очередь с низким весом. Однако WFQ не мог соответствовать требованиям задержки голосового трафика, и голосовые вызовы с помощью RSVP не были готовы воспользоваться преимуществом PQ, доступным в LLQ.

В ПО Cisco IOS версии 12.1(3)T и более поздних версий существует приоритетный профиль, основанный на характеристиках трафика. Поэтому строгая очередь по приоритетам в LLQ обеспечивает определенным потокам преимущество. Если запрос резервирования RSVP получен на интерфейсе с активированным WFQ, технические характеристики потока трафика (TSpec) сравниваются с профилем. Выполнение данной процедуры позволяет решить, получит ли этот поток преимущество PQ, или же необходимо зарезервировать очередь в системе WFQ. TSpec — это описание трафика, передаваемое в сообщениях RSVP. Данное описание трафика выполняется на основе алгоритма token bucket (скорость эстафеты r, плюс размер участка памяти b) и некоторых дополнительных параметров (пиковая скорость p, минимальная ограниченная единица m и максимальный размер пакета M). Профиль PQ определяется показателями «скорость эстафеты», «размер участка памяти» и, по выбору, отношением пиковой скорости к скорости эстафеты. Резервирования потоков с техническими характеристиками, не превышающими определенных в профиле PQ, будут использовать PQ. Потоки, технические характеристики которых превышают хотя бы один параметр, определенный в профиле, получат зарезервированную очередь в системе WFQ. Профиль приоритета позволяет классифицировать приоритетные потоки на основе характеристик их трафика, а не только с помощью транспортного протокола и порта. На рис. 8 показана структура LLQ для интерфейса, где трафик распределяется по разным очередям несколькими способами, включая RSVP.


Рис. 8. Поддержка RSVP для LLQ на двухточечных интерфейсах


Программное обеспечение Cisco IOS версии 12.1(5)T впервые содержало поддержку RSVP для LLQ на PVC-каналах Frame Relay. В данном случае каждый PVC-канал обладает собственной структурой организации очереди с PQ и системой CBWFQ. На уровне интерфейса, если фрагментация FRF.12 не активирована, настраивается очередь по принципу FIFO. В таком случае для двойной системы FIFO настраиваются очереди с высоким и низким приоритетом. Очередь с высоким приоритетом получает трафик PQ со всех PVC-каналов плюс трафик управления Layer 2 . Прочий трафик со всех PVC-каналов помещается в очередь с низким приоритетом. Следует помнить, что формирование трафика Frame Relay (FRTS) запрашивается для схемы Frame Relay независимо от активации фрагментации FRF.12. Чтобы обнаружить перегрузку на каждом PVC-канале, FRTS предоставляет механизм обратного давления. Поддержка для PVC-каналов в режиме ATM доступна в Cisco IOS версии 12.2(1)T.

Использование поддержки RSVP для LLQ

Активируйте поддержку RSVP для LLQ по умолчанию для голосовых потоков на интерфейсах с активированными RSVP и WFQ. Нет необходимости явно настраивать очереди по приоритетам для голосовых пакетов. Можно настроить профиль пользовательской очереди по приоритетам с помощью команды глобальной настройки ip rsvp pq-profile. Настройка профиля как ip rsvp pq-profile voice-like восстанавливает параметры по умолчанию. Профиль пользовательской очереди по приоритетам использует скорость эстафеты, равную 12,288 байтов в секунду (приблизительно 98 Кбит/с), размер участка памяти 592 байтов и пиковую скорость, равную 110% скорости эстафеты (13,516 байтов в секунду или приблизительно 108 Кбит/с). Эти значения параметра поддерживают все возможные настройки кодека на голосовых шлюзах с работающим программным обеспечением Cisco IOS. Голосовой шлюз Cisco, настроенный для резервирования ресурсов через RSVP, логически выводит правильные технические характеристики исключительно из кодека, используемого на одноранговом телефонном соединении. Невозможно контролировать значения технических характеристик с помощью интерфейса командной строки, и ни одна функция экономии полосы пропускания (например, VAD) не принимается во внимание. Некоторые новые версии Microsoft NetMeeting для Windows 98 и Windows 2000 (использующие RSVP) передают в технических характеристиках (TSpec) значение размера участка памяти, не совпадающее с характеристиками по умолчанию. Данная проблема затрагивает Microsoft NetMeeting для вызовов, которые используют кодеки с полосой пропускания не менее 32 Кбит/с. В таких случаях необходимо создать пользовательский профиль и сопоставить параметры, передаваемые сигналом Microsoft Windows.

В следующем примере показана настройка поддержки RSVP для LLQ на схеме Frame Relay, имеющей два PVC-канала:

Пример настройки 13: Поддержка RSVP для LLQ на PVC-каналах Frame Relay
hostname LongBay
 
!
isdn switch-type primary-ni
call rsvp-sync
!
interface Serial0/0
 bandwidth 1536
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
 ip address 10.10.1.2 255.255.255.0
 frame-relay interface-dlci 16
 class VoIPoFR
 ip rsvp bandwidth 48 24
!
interface Serial0/0.2 point-to-point
 ip address 10.10.2.2 255.255.255.0
 frame-relay interface-dlci 17
 class VoIPoFRip 
 rsvp bandwidth 48 24
!
ip rsvp pq-profile voice-like
!
map-class frame-relay VoIPoFR
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay mincir 64000
frame-relay fair-queue
frame-relay fragment 80
!
 

В данном примере WFQ активируется на PVC-канале, а отключается на физическом интерфейсе. Очередь по приоритетам для голосового трафика есть в каждом PVC-канале. Физическому интерфейсу присваивается очередь со структурой типа двойной системы FIFO. После активации FRTS его параметры определяются в классе сопоставления VoIPoFR .



Одним из важнейших следствий поддержки RSVP для LLQ является возможность классификации голосового трафика на основе собственных характеристиках трафика, а не на транспортном протоколе (UDP) и номере порта (от 16384 до 32767). Правильная работа LLQ основывается на условии, что очередь по приоритетам используется только для стабильного трафика (например, голосового), который имеет предсказуемую скорость и очень малый размер блока. Классификация на основе транспортного протокола и портов могла бы допустить пульсирующий или некритичный трафик в очередь по приоритетам, которая, в свою очередь, могла бы с помощью системы WFQ влиять на качество существующих голосовых вызовов и характеристики трафика. Во время определения профиля пользовательской очереди по приоритетам необходимо учитывать пульсирующий или некритичный трафики. Следует понимать все последствия для других типов трафика, в особенности, если профиль PQ может вводить в очередь по приоритетам потоки с некоторым уровнем пульсации. Поддержка RSVP для LLQ назначает приоритеты голосовым пакетам, но не следит за передачей голосового сигнала. При возникновении значительной перегрузки из-за потерь сигнальных пакетов может оказаться невозможным инициировать новые вызовы. Во избежание подобной ситуации, с помощью механизма MQC можно зарезервировать некоторый объем полосы пропускания исключительно для сигнальных пакетов. Можно также маркировать сообщения RSVP для особой обработки с помощью команды глобальной настройки ip rsvp signaling dscp.

В следующем примере настройки голосовым пакетам с помощью протокола RSVP назначается приоритет, а средствами механизма MQC для сигнализации гарантируется минимальная полоса пропускания во время перегрузок:

Пример настройки 14: Поддержка RSVP для LLQ + QoS для сигнального трафика
hostname LongBay
 
!
class-map h323
 match access-group 101
!
policy-map VOIP_SIG
 class h323
  set ip dscp 34
  bandwidth 96
 class class-default
  fair-queue
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
interface Ethernet0/0
 ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
 bandwidth 1536
 ip address 10.10.1.1 255.255.255.0
 encapsulation ppp
 ip tcp header-compression iphc-format
 ip rtp header-compression iphc-format
 service-policy output VOIP_SIG
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
 no ip address
 no logging event link-status
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!
access-list 101 permit tcp any eq 1720 any
 
access-list 101 permit tcp any any eq 1720
!
voice-port 1/0:23
!
dial-peer voice 100 pots
 
 destination-pattern 2......
 no digit-strip
 direct-inward-dial
 port 1/0:23
!
dial-peer voice 300 voip
 destination-pattern 3......
 session target ipv4:10.77.39.129
 req-qos guaranteed-delay
 acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4

В данном примере список доступа 101 сопоставляется с сигнальным трафиком H.323 из порта TCP 1720 и обратно. Данный трафик помещается в класс h323, в котором методом LLQ гарантируется полоса пропускания 96 Кбит/с. Полезной голосовой нагрузке с помощью конфигурации RSVP присваивается приоритет.



QoS VoIP по выделенным линиям (с использованием протокола PPP)

В данном разделе описывается настройка VoIP в обычных сетях, использующих низкоскоростные каналы WAN для передачи как данных, так и голосового трафика. Он состоит из следующих подразделов:

Сценарий VoIP по выделенным линиям (с использованием протокола PPP)

Большие корпорации обычно используют существующую для трафика данных инфраструктуру VoIP WAN для обмена голосовыми вызовами между головным офисом и филиалами. На рис. 9 показана типичная среда сети VoIP, в которой низкоскоростные каналы WAN использовались для передачи как данных, так и голосового трафика.


Рис. 9. Типичная среда сети VoIP


Для низкоскоростных каналов WAN, которые не слишком подходят для обслуживания голосового трафика, такие проблемы, как задержка, флуктуация сигнала и потери, становятся еще более серьезными. В этой отдельной сетевой среде плохое качество голоса может быть вызвано следующими причинами:

  • Большие пакеты данных, отправленные раньше голосовых пакетов, вызывают длительные задержки.

  • Пакеты данных переменной длины, отправленные раньше голосовых пакетов, делают задержки непредсказуемыми, что приводит к флуктуациям сигнала.

  • Из-за узкой полосы пропускания объединенный заголовок RTP, UDP и IP размером 40 байтов для VoIP-пакета размером 20-байтов занимает слишком много ресурсов.

  • Из-за узкой полосы пропускания канал часто испытывает перегрузки, что приводит к существенным задержкам и потерям.

  • Многие популярные методы QoS, например механизмы WFQ и RED (Random Early Detect), которые прекрасно обслуживают трафик данных, неэффективны для голосовых приложений:

    • Если WFQ применяется и к голосу, и к данным, то, по мере возрастания в канале количества потоков данных и потоков от голосовых приложений, WFQ на основе потоков назначает каждому каналу все меньшую полосу пропускания. В отличие от гибкого трафика данных, который приспосабливается к имеющейся полосе пропускания, качество голоса становится неприемлемым в условиях отбрасывания большого количества пакетов и увеличении задержек.

    • Механизм RED разработан специально для TCP-трафика. Протокол VoIP основывается на протоколе UDP. Поэтому, при наличии возможности, голосовой трафик и трафик данных следует отнести к раздельным категориям, а RED применять не к голосу, а к данным.

Кроме того, каждый канал и каждая единица оборудования на пути VoIP вызывают задержку передачи голосового пакета. Помимо этого, вероятность потери голосовых пакетов возрастает c увеличением расстояния передачи голосового трафика и количества проходимых участков сети. Низкоскоростные WAN-соединения обычно представляют собой самые слабые каналы.

Рекомендуемое решение VoIP по выделенным линиям (с использованием протокола PPP)

В нормальных условиях сетевое оборудование и конечные станции не в состоянии устанавливать различия между требованиями голосовых пакетов в реальном времени и стандартным трафиком данных. Это может вызвать серьезное ухудшение качества речи. Чтобы обеспечить качество голоса, необходимо отнести трафик данных и голосовой трафик к разным категориям и назначить голосовому трафику приоритетную обработку в совместно используемых сетевых магистралях данных. Назначение приоритетной обработки голосовому трафику сводит к минимуму задержки и отбрасывание пакетов и, по возможности, назначает предсказуемые характеристики передачи голосового трафика. Для каналов PPP рекомендуются следующие функции QoS:

  • Классификация пакетов при помощи MQC

  • Маркировка на основе классов (на границе DS)

  • Приоритетная обработка посредством LLQ

  • CRTP: Нужен только на низкоскоростных каналах с небольшим количеством вызовов для достижения наилучшего качества полосы пропускания

  • MP LFI: Нужен только на низкоскоростных каналах (со скоростью менее 1,2 Мбит/с), чтобы обеспечить время передачи одного фрагмента не более 10 мс

Следующий пример показывает полную настройку, в которой активированы все перечисленные функции качества обслуживания:

Пример настройки 15: Качество обслуживания для VoIP по каналам PPP WAN
Команды
Описание
class-map voip 
 
 match ip precedence 5
!

Создает класс voip для голосового трафика с маркировкой уровнем 3 IP Precedence, выполненной любым из доступных способов маркировки.

class-map webtraffic 
 
 match ip precedence 3
!

Создает класс webtraffic для голосового трафикатрафика с маркировкой уровнем 3 IP Precedence, выполненной любым из доступных способов маркировки.

policy-map llq 
 
 class voip 
  priority 64 
 class webtraffic 
  bandwidth 64 
 class class-default 
  fair-queue
!

Определяет схему политик QoS — llq: трафику класса voip присваивается приоритет и ограничение до 64 Кбит/с на время перегрузки, а пакетам класса webtraffic гарантируется скорость 64 Кбит/с. Оставшаяся полоса пропускания распределяется между другими видами трафика.

interface Serial1/0 
 
 bandwidth 256 
 encapsulation ppp 
 no fair-queue 
 ppp multilink 
 multilink-group 1
!

Прикрепляет последовательный интерфейс 1/0 к многоканальному интерфейсу в группе 1. (Для полосы пропускания канала со скоростью более 1,2 Мбит/с не требуются многоканальный протокол PPP LFI и протокол cRTP. В данном случае IP-адрес и инструкция service-policy будут включены в настройки последовательного интерфейса.)

interface Multilink1 
 
 ip address 10.1.1.1 255.255.255.252 
 bandwidth 256
!

Настраивает многоканальный PPP LFI для каналов с полосой пропускания менее 1,2 Мбит/с.

ip rtp header-compression iphc-format
 
ip tcp header-compression iphc-format
!

Настраивает сжатый протокол RTP для снижения требований каждого голосового вызова к полосе пропускания.

ppp multilink 
 
 ppp multilink fragment-delay 10

Включает фрагментацию с размером фрагментов 10 мс.

 ppp multilink interleave
 

Включает чередование пакетов и фрагментов.

 multilink-group 1 
 
 service-policy output llq
!

Прикрепляет многоканальный интерфейс к группе 1. Прикрепляет политику качества обслуживания llq к выходящему трафику на многоканальном интерфейсе.

В данном примере многоканальный PPP LFI препятствует задержке VoIP-пакетов позади больших пакетов данных, сжатый протокол RTP снижает требования к полосе пропускания VoIP, а LLQ назначает приоритет VoIP-трафику и предоставляет другим классам гарантированную полосу пропускания. Необходимо настроить эти функции на обеих сторонах канала PPP. Использование многоканального PPP LFI полезно только для каналов с полосой пропускания менее 1,2 Мбит/с. Применение сжатого протокола RTP рекомендуется только на каналах с небольшим количеством VoIP-вызовов при условии невысокой загрузки ЦП.



QoS VoIP в сетях по протоколу Frame Relay

В данном разделе описывается настройка VoIP в обычных сетях, использующих для передачи голосового трафика каналы Frame Relay WAN. Он состоит из следующих подразделов:

Сценарий качества обслуживания VoIP по протоколу Frame Relay

Большие корпорации также используют технологию VoIP и присущую ему инфраструктуру трафика данных Frame Relay WAN для обмена голосовыми вызовами между головными офисами и филиалами. Существует два варианта выбора: либо передавать голос и данные по различным PVC-каналам, либо использовать единый PVC-канал для голосового трафика и для трафика данных. В первом случае по-прежнему необходимо присваивать голосовому трафику приоритет такими методами, как, например, очередь по приоритетам интерфейса постоянного виртуального канала (PIPQ). Метод PIPQ позволяет назначать для PVC-каналов приоритеты разного уровня: высокого, среднего, обычного или низкого. Метод PIPQ также позволяет организовать очередь PVC-каналов на основном физическом интерфейсе так, что трафик с высоким приоритетом идет перед трафиком со средним, нормальным и низким приоритетами. Для метода PIPQ, однако, существует та же проблема, что и при организация очереди по приоритетам: трафик с высоким приоритетом может отнимать ресурсы другого трафика в полосе пропускания. Однако при правильном использовании формирования трафика Frame Relay данную проблему можно свести к минимуму, поскольку каждый PVC-канал будет иметь определенную максимальную скорость передачи.

В наиболее распространенном сценарии для передачи трафика между сайтами используется один PVC-канал, как показано на рис. 10.


Рис. 10. Качество обслуживания VoIP на низкоскоростных каналах Frame Relay


Рекомендуемое решение QoS VoIP для протокола Frame Relay

Чтобы гарантировать правильную обработку несоответствия скоростей на удаленных сайтах и концентраторе, необходимо настроить формирование трафика Frame Relay. Например, если сайт-концентратор имеет подключение T1 в сети Frame Relay, а удаленный узел имеет скорость доступа 128-Кбит/с, то удаленный сайт имеет возможность использовать скорости T1 для отправки этому удаленному узел. Коммутаторы Frame Relay в некоторой мере буферизирует данный трафик, но затем произвольно отбрасывают все данные, скорость передачи которых превышает 128 Кбит/с. Необходимо принять решение о том, что следует отбросить, а чему присвоить приоритет на оконечных устройствах PVC-канала.

Формирование трафика Frame Relay позволяет маршрутизатору отправлять трафик в облако Frame Relay со скоростью, ниже предварительно настроенной. Любой трафик со скоростью, превышающей данную, помещается в очередь. Чтобы принять интеллектуальное решение о том, какие пакеты следует отправить, можно использовать такой алгоритм организации очереди как LLQ. При заполнении очередей пакеты просто отбрасываются. Однако если VoIP имеет определенный приоритет, а скорость общего VoIP-трафика ниже скорости формирования трафика, то VoIP-пакеты обслуживаются с небольшой задержкой и не отбрасываются.

Для более низкоскоростных каналов с полосой пропускания менее 1,2 Мбит/с необходимо настроить фрагментацию пакетов. Это позволит избежать задержки VoIP-пакета, находящегося в очереди позади большого пакета. Фрагментация больших пакетов данных до 10 мс соответственно скорости канала может ограничить максимальный период ожидания. Если количество вызовов слишком велико, можно использовать сжатый протокол RTP, что позволит эффективно использовать полосу пропускания.

Чтобы обеспечить высокий приоритет VoIP в сети Frame Relay, необходимо настроить следующие функции:

  • Формирование трафика Frame Relay

    • Установите команду настройки map-class frame-relay cir на максимальную скорость передачи (это должна быть установленная в порядке договоренности гарантированная скорость от поставщика услуг).

    • Чтобы обеспечить наилучшее качество голоса, отключите команду настройки map-class frame-relay adaptive-shaping и установите значение команды mincir в соответствии со значением команды cir.

    • Чтобы разрешить формирование трафика для обслуживания пакетов, по меньшей мере, каждые 10 мс, установите в команде настройки map-class frame-relay bc 1/100 CIR.

  • FRF.12 LFI: LFI требуется, только если скорость удаленного порта или концентратора конечного порта меньше 1,2 Мбит/с. Необходимо, чтобы размер фрагментации равнялся 10 мс, или 80 байтам, умноженным на количество каналов DS0 (например, для 4x64k, размер фрагментации должен составлять 4x80 = 320 байтов)

  • LLQ на Frame Relay PVC: для формирования трафика Frame Relay в разделе map class применяется LLQ.

  • cRTP: сжатый протокол RTP в зависимости от платформы применяется в подчиненном интерфейсе Frame Relay только при низкой загрузке ЦП и для небольшого количества вызовов.

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

Пример настройки 16: Качество обслуживания для VoIP в каналах Frame Relay WAN
Команды
Описание
class-map voip 
 
 match ip precedence 5
!

Создает класс voip для голосового трафика с маркировкой уровнем 3 IP Precedence, выполненной любым из доступных способов маркировки.

class-map webtraffic 
 
 match ip precedence 3
!

Создает класс webtraffic для голосового трафикатрафика с маркировкой уровнем 3 IP Precedence, выполненной любым из доступных способов маркировки.

policy-map llq 
 
 class voip 
  priority 64 
 class webtraffic 
  bandwidth 64 
 class class-default 
  fair-queue
!

Определяет схему политик QoS — llq: трафику класса voip присваивается приоритет и ограничение до 64 Кбит/с на время перегрузки, а пакетам класса webtraffic гарантируется скорость 64 Кбит/с. Оставшаяся полоса пропускания распределяется между другими видами трафика.

interface Serial 0/1 
 
 no ip address 
 encapsulation frame-relay
 frame-relay traffic shaping
!

Активирует формирование трафика Frame Relay. Для обработки несоответствий скоростей и недостаточной загрузки каналов необходимо активировать формирование трафика Frame Relay. (Механизм LLQ также запрашивает формирование трафика Frame для на каждого PVC-канала Frame Relay.)

interface Serial 0/1.64 point-to-point 
 
 ip address 10.14.96.2 255.255.255.252
 frame-relay interface-dlci 128 
  class voice

Назначает данному PVC-каналу Frame Relay класс формирования трафика voice.

  frame-relay ip rtp header-compression 
 
!

Настраивает сжатый протокол RTP для снижения требований каждого голосового вызова к полосе пропускания.

map-class frame-relay voice 
 
 no frame-relay adaptive-shaping

Отключает адаптивное формирование. Использование адаптивного формирования для IP-телефонии не рекомендуется.

 frame-relay cir 256000
 

Устанавливает CIR или верхнюю границу скорости передачи 256 Кбит/с.

 frame-relay bc 2560
 

Устанавливает согласованную скорость блока 1/100 от CIR.

 frame-relay mincir 256000
 

Устанавливает минимальную приемлемую скорость CIR. Необходимо, чтобы значение mincir превышало суммарное значение приоритета и выделенной полосы пропускания.

 frame-relay fragment 320
 

Активирует фрагментацию FRF.12 с размером фрагментов 320 байтов.

 service-policy output llq!
 
 

Назначает политику качества обслуживания llq определенному разделу map class.

В данном примере рассматривается комплекс мер по управлению трафиком. Так, с помощью механизма формирования трафика Frame Relay обрабатывается несоответствие скоростей, а выполнение фрагментации FRF.12 препятствует задержке VoIP-пакетов позади больших пакетов данных. Использование сжатого протокола RTP позволяет снизить требования к полосе пропускания VoIP, а применение механизма LLQ обеспечивает приоритет VoIP-трафику и предоставляет другим классам гарантированную полосу пропускания. Необходимо настроить эти функции на обоих концах канала Frame Relay. Использование FRF.12 полезно только для каналов с полосой пропускания менее 1,2 Мбит/с. Применение сжатого протокола RTP рекомендуется только на каналах с небольшим количеством VoIP-вызовов, при условии, что ЦП не слишком загружен.



Функция QoS VoIP для протокола ATM

Данный раздел содержит описание настройки QoS VoIP в ATM и состоит из следующих подразделов:

Сценарий QoS VoIP при использовании протокола ATM

Технология ATM имеет несомненные преимущества при обработке трафика IP-телефонии благодаря ее малому и постоянному количеству ячеек и механизмам класса обслуживания (CoS). Эти преимущества, однако, не гарантируют автоматическое получение VoIP-трафиком необходимого качества обслуживания от ATM-сети, в которой он передается. Автоматическое получение необходимого качества обслуживания для VoIP-трафика невозможно, поскольку определения качества обслуживания на IP-уровне, таком, как настройки IP Precedence в заголовке пакета, не совпадают с настройками класса обслуживания ATM автоматически. В число таких настроек входят: класс трафика (постоянная скорость передачи данных (CBR), переменная скорость передачи данных (VBR), доступная скорость передачи данных (ABR), неопределенная скорость передачи данных (UBR)) и параметры трафика, такие как нормальная скорость передачи ячеек (SCR), пиковая скорость передачи ячеек (PCR) и размер блока. Следовательно, после идентификации и сортировки пакетов данных и голосовых пакетов на уровне IP, оператор сети должен вручную настроить виртуальные каналы (VC) в режиме ATM. Это позволит гарантировать качество обслуживания для голосовых пакетов по всей ATM-сети. Ручное управление и настройка занимает много времени, трудоемко, не защищено от ошибок и, помимо прочего, несоизмеримо со все большими объемами голосового трафика, которые вводятся в сеть.

На рис. 11 показан пример VoIP QoS VoIP, настроенного для поддержки ATM.


Рис. 11. VoIP QoS в каналах ATM


Для обеспечения QoS VoIP в сети ATM существуют два решения. Первое состоит в использовании разных виртуальных каналов для передачи данных и голоса, второе — в передаче голоса и данных по общим виртуальным каналам.

Решение QoS VoIP для протокола ATM с использованием раздельных постоянных виртуальных каналов (PVC) ATM для данных и голоса

Для голосового трафика и трафика данных, использующих один пункт назначения, но запрашивающих разное качество обслуживания, необходимо определить группы виртуальных каналов ATM, чтобы сформировать пучки PVC-каналов. В пучке PVC-каналов всем постоянным виртуальным каналам предписан один источник и пункт назначения. Каждому пучку присваивается передача IP-трафика с определенным уровнем IP Precedence или с диапазоном уровней. После настройки пучков постоянных виртуальных каналов настройте параметры QoS для ATM каждого PVC-канала особо. Рассмотрим случай, когда на ATM-интерфейс маршрутизатора поступает и голосовой трафик, и трафик данных с различными уровнями IP Precedence. Программное обеспечение Cisco IOS динамически отсылает трафик на соответствующий PVC-канал, фактически сопоставляя классы качества обслуживания IP-пакетов с классами обслуживания ATM.

Реализация механизма QoS для технологии VoIP данным способом обеспечивает следующие основные преимущества:

  • Автоматическое разделение голосового трафика и трафика данных по разным постоянным виртуальным каналам.

  • Сохранение дифференцированных услуг сети IP в сети ATM.

В данном примере показана настройка VoIP для ATM с использованием пучков PVC-каналов, чтобы разделить постоянные виртуальные каналы для передачи данных и PVC-канала для передачи голоса:

Пример настройки 17: QoS для VoIP в сети ATM с раздельными PVC-каналами для передачи голоса и данных
Команды
Описание
ip cef
 
!

Активирует технологию коммутации IP Cisco Express Forwarding (CEF). Чтобы данное решение работало, необходимо активировать коммутацию IP CEF.

interface ATM 2/0/0 
 
 no ip address
!
interface ATM 2/0/0.1 point-to-point 
 ip address 10.1.1.2 255.255.255.252 
 bundle qosmap

Создает группы пучков PVC-каналов, которая называется qosmap.

protocol ip 10.1.1.1 broadcast 
 
 pvc-bundle control 1/100 
 precedence 6-7

Сопоставляет трафик уровня 6 и 7 IP Precedence с идентификатором виртуального пути (VPI) или с идентификатором виртуального канала (VCI) 1/100.

pvc-bundle voice 1/101 
 
 vbr-rt 6000 5000 1000   
 precedence 5

Сопоставляет трафик уровня 5 IP Precedence (VoIP) с VPI или VCI 1/101 при нормальной скорости передачи (SCR) 5 Мбит/с и некоторыми возможностями передачи пакетов.

pvc-bundle web 1/102 
 
 cbr 5000 
 precedence 4

Сопоставляет трафик уровня 5 IP Precedence с 1/102 при нормальной скорости передачи (SCR) 5 Мбит/с.

pvc-bundle data 1/103 
 
 precedence 0-3

Сопоставляет трафик с другим уровнем приоритета с PVC-каналом с VPI или VCI 1/103.

В данном примере четыре класса трафика на основе протокола IP Precedence сопоставляются с четырьмя раздельными PVC-каналами ATM в связке. Голосовой PVC-канал с гарантированной полосой пропускания 5 Мбит/с обеспечивает возможность передачи нескольких блоков. Полоса пропускания 5 Мбит/с также гарантируется для PVC-канала Интернет-трафика, но без передачи блоков (CBR). В сети ATM нет никаких гарантий скорости для контрольного трафика и потоков других видов трафика.



Решение QoS VoIP для протокола ATM с использованием общих постоянных виртуальных каналов (PVC) ATM для данных и голоса

Если принято решение об использовании раздельных PVC-каналов для передачи голоса и данных, необходимо подстроить выделение полосы пропускания соответственно возрастанию голосового трафика вне полосы пропускания голосового PVC-канала. Такое дублирование настроек вручную необязательно, если и голос, и данные передаются по общему PVC-каналу, при условии, что голосу всегда присваивается необходимый приоритет. Чтобы получить абсолютный приоритет над трафиком данных, можно настроить VoIP-трафик, настроив механизм LLQ на PVC-канале в сети ATM.

В данном примере показана настройка VoIP в сети ATM с использованием одного PVC-канала как для трафика данных, так и для голосового трафика:

Пример настройки 18:QoS VoIP в сети ATM на общем PVC-канале для передачи голоса и данных.
Команды
Описание
ip cef
 
!

Активирует коммутацию IP CEF. Чтобы данное решение работало, необходимо активировать коммутацию IP CEF.

class-map voip 
 
 match ip precedence 5
!

Создает класс voip для голосового трафика, маркированного одним из доступных способов с уровнем 5 приоритета IP-пакета.

class-map webtraffic 
 
 match ip precedence 3
!

Создает класс voip для голосового трафика, маркированного одним из доступных способов с уровнем 3 приоритета IP-пакета.

policy-map llq 
 
 class voip 
  priority 1000 
 class webtraffic 
  bandwidth 1000 
 class class-default 
  fair-queue
!

Определяет схему политик llq, которая, в свою очередь, определяет политику QoS: трафику класса voip присваивается приоритет и ограничение до 1 Мбит/с на время перегрузки, а пакетам класса webtraffic гарантируется скорость 1 Мбит/с. Оставшаяся полоса пропускания распределяется между другими видами трафика.

interface ATM2/0/0   
 
 no ip address
!
interface ATM2/0/0.1 point-to-point
 ip address 10.1.1.2 255.255.255.252
 pvc data+voice 1/101
  vbr-rt 6000 5000 1000
  encapsulation aal5snap!

Настраивает параметры формирования для ATM.

service-policy output llq
 
! 

Приписывает схему политики качества обслуживания llq PVC-каналу сети ATM.

В данном примере механизм LLQ используется на единственном PVC-канале сети ATM, передающем как VoIP-пакеты, так и данные. Политика LLQ применяется к подчиненному интерфейсу ATM для одного PVC-канала. Трафику класса voip присваивается приоритет до 1 Мбит/с, а классу webtraffic гарантируется скорость 1 Мбит/с, однако приоритетная обработка не обеспечивается. Механизм формирования для ATM также гарантирует PVC-каналу среднюю скорость 5 Мбит/с.



Дополнительная документация