Протокол RSVP является сквозным резервированием на вызов и может просматривать только этот вызов. Неизвестно число других активных вызовов, исходящих с узла или проходящих через интерфейс, а также источник и адрес назначения любого другого вызова. Следовательно, нет способа настроить уровень объединения контроля приема вызовов с протоколом RSVP, таких как механизм контроля вызовов типа «узел-на-узел», который можно было настроить с контролем полосы пропускания контроллера шлюза.
Классификация голосовых пакетов по критерию минимального времени ожидания (LLQ) LLQ является одним из важных механизмов обеспечения качества Cisco QoS, который гарантирует качество голоса благодаря установке более высокого приоритета голосовым пакетам над пакетами данных на выходном интерфейсе маршрутизатора. Для работы этого механизма необходимо классифицировать голосовые пакеты так, чтобы они помещались в очередь приоритетов LLQ. Традиционно это достигается с помощью классификации списка контроля доступа (Access Control List, ACL), где порты TCP (сигналы) и UDP (среда) сопоставлены так, чтобы направлять голосовые пакеты в соответствующую очередь.
Общими средствами Cisco IOS для трафика с резервированием RSVP протокол RSVP снабжается собственным набором зарезервированных очередей в составе WFQ (взвешенной очереди с обслуживанием по принципу равнодоступности). Эти очереди, несмотря на более низкий вес, отделены от PQ. Пакеты в зарезервированных очередях не получают приоритета над пакетами из других очередей из-за низкого веса. Давно известно, что этого метода (очереди с низким весом в составе очереди WFQ) недостаточно для обеспечения качества голосовой связи по перегруженному интерфейсу с несколькими разными потоками трафика. Следовательно, при настройке RSVP на голосовой вызов необходимо относить голосовые пакеты к очереди PQ.
Пакеты потока данных RSVP в этом случае не требуется относить к PQ. Протокол RSVP классифицирует поток пакетов как голосовой поток на основании профиля. В профиле учитывается размер пакета, скорость появления и другие параметры. Поток пакетов, соответствующий определенным параметрам, считается голосовым. В случае несоответствия он считается неголосовым потоком, который может включать как данные, так и видео. Внутренний профиль настроен таким образом, что весь голосовой трафик, исходящий со шлюза Cisco IOS, соответствует этим параметрам и будет, следовательно, считаться голосовым потоком без необходимости в дополнительной настройке.
Для обработки специфического трафика от приложений сторонних поставщиков, таких как NetMeeting, может потребоваться настройка профиля. Процесс поясняется на рис. 22. Рис. 22. Критерии классификации пакетов RSVP RSVP является первым выходным интерфейсом, который проверяет приходящий пакет. Если протокол RSVP классифицирует пакет как относящийся к голосовому потоку, то пакет попадает в раздел PQ механизма организации очередей LLQ. Если поток не соответствует голосовому профилю, но является, тем не менее, потоком, зарезервированным RSVP, то он будет помещен в обычные зарезервированные очереди RSVP.
Если поток не является ни голосовым потоком, ни потоком данных RSVP, другим классификаторам выходного интерфейса (например, ACL и операторам соотнесения в таблице классов) предоставляется возможность классифицировать пакет для постановки в очередь. Важно отметить, что протокол RSVP классифицирует только полезный голосовой трафик, а не служебный трафик. Если для голосового служебного трафика необходим иной способ обработки, чем Best-effort (передача только при наличии возможности), то для классификации этого необходимо использовать один из прочих механизмов классификации, например, ACL или DSCP.
Если принятие решения становится ответственностью одного механизма RSVP, служебный трафик будет считаться трафиком Best-effort (передаваемым только при наличии возможности), как показано на рис. 22. Присвоение полосы пропускания в протоколе RSVP и механизме LLQ Голосовой трафик RSVP можно смешивать с трафиком «приоритетного класса» (в пределах таблицы политики) в очереди PQ, но настройка проще при использовании одного механизма классификации. Тем не менее, рекомендуется использовать только один или другой для голоса, но не сразу оба. Необходимо настроить либо протокол RSVP для определения приоритета голосового трафика, либо