Глава 9

Протокол MEGACO/H.248

9.1    История создания и особенности протокола MEGACO/H.248

Рабочая группа MEGACO комитета IETF,  продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Так, в проекте 4-й версии рекомендации Н.323 ITU-T ввел принцип декомпозиции шлюзов, уже описанный с той или иной степенью детализации в главах 1, 2 и 8. Важной особенностью нововведения ITU-T явилось то, что управление транспортными шлюзами - Media Gateway (MG) - осуществляется контроллером транспортных шлюзов - Media Gateway Controller (MGC) - при помощи протокола MEGACO, адаптированного под сетевое окружение Н.323. Спецификации адаптированного протокола приведены в недавно утвержденной рекомендации ITU-T H.248. В данной книге этот протокол называется MEGACO/H.248, так как авторам не хотелось бы умалить чьи-либо заслуги в разработке и адаптации этого протокола. На рис. 9.1. представлено дерево эволюции протокола MEGACO/H.248.

Рассмотрим кратко основные особенности протокола MEGACO/ Н.248. Для переноса сигнальных сообщений MEGACO/H.248 могут использоваться протоколы UDR TCP, SCTP или транспортная технология ATM. Поддержка для этих целей протокола UDP - одно из обязательных требований к контроллеру шлюзов. Протокол TCP должен поддерживаться и контроллером, и транспортным шлюзом, а поддержка протокола SCTR так же, как и технологии ATM, является необязательной.

Рис. 9.1   Дерево эволюции протокола MEGACO/H.248

Еще одной особенностью протокола MEGACO/H.248 является то, что сообщения этого протокола могут кодироваться двумя способами. Комитет IETF предложил текстовый способ кодирования сигнальной информации, а для описания сеанса связи предложил использовать протокол SDR ITU-T предусматривает бинарный способ представления сигнальной информации - ASN.1, а для описания сеансов связи рекомендует специальный инструмент - Tag-length-value (TLV). Контроллер шлюза должен поддерживать оба способа кодирования,  в то время как шлюз - только один из этих способов.

9.2   Модель процесса обслуживания вызова

При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами внутри транспортного шлюза: порт (termination) и контекст (context), которыми может управлять контроллер шлюза. Пример модели процесса обслуживания вызова приведен на рис. 9.2.

Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные. Физические порты, существующие постоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1. Виртуальные порты, существующие только в течение разговорной сессии, являются портами со стороны IP сети (RTP-порты), через которые ведутся передача и прием пакетов RTP.

Рис. 9.2  Примеры модели процесса обслуживания вызова

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

Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется специальный идентификатор порта (TerminationID) - «Root».

Порты обладают рядом свойств (properties), каждое из которых имеет уникальный идентификатор (propertylD). Например, порты могут обладать свойствами генерировать речевые подсказки, акустические и вызывные сигналы, а также детектировать сигналы DTMF.

При создании портов некоторые свойства присваиваются им по умолчанию. При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами (таблица 9.1).

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

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

Если шлюз поддерживает конференцию, то контекст определяет топологию связей между портами, участвующими в конференции, то есть возможные направления потоков информации для каждой пары портов. Примеры топологий, поддерживаемых протоколом MEGACO/H.323, приведены на рис. 9.3.

Краткое описание вариантов топологии связей в конференции представленных на рис. 9.3, сведено в таблицу 9.2.

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

9.3   Сравнительный анализ протоколов MGCP и MEGACO

Цель данного параграфа - определить, в чем сходны и чем различаются протоколы MGCP и MEGACO. Начнем с общих черт протоколов.

Оба протокола используются в сетях с одинаковой архитектурой, где транспортными шлюзами управляют высокоинтеллектуальные контроллеры. Оба протокола умеют работать со шлюзами одних и тех же видов, классификация шлюзов была дана в предыдущей главе. Порты шлюзов поддерживают детектирование одних и тех же событий и генерацию одних и тех же сигналов. Используются одинаковые транспортные механизмы для доставки сообщений систем сигнализации ОКС7, DSS1, ВСК. Процедуры установления и разрушения соединений, реализуемые обоими протоколами, идентичны. Кроме того, используются одинаковые механизмы поддержания защиты сети. На этом сходство протоколов MGCP и MEGACO/H.248 заканчивается.

Самым важным отличием протокола MEGACO/H.248 от протокола MGCP является использование иной модели организации связи. Протокол MEGACO/H.248 работает не только с телефонными портами, ной UDP-портами. Кроме того, connection в модели MGCP-это, в общем случае, подключение к соединению между портами разного оборудования, в то время как context в модели MEGACO/H.248 всегда отображает связь между портами одного шлюза (рис. 9.4).

Рис. 9.4  Модели MGCP и MEGACO/H.248

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

Выше уже отмечалось, что для протокола MEGACO/H.248 предусмотрено два способа кодирования, тогда как сообщения протокола MGCP представляются в текстовом формате, а бинарный способ кодирования не поддерживается. Кроме того, в протоколах используются разные параметры команд и коды ошибок.

Протокол MEGACO/H.248, так же, как и протокол MGCP, предусматривает корреляцию команд и ответов. Но если в протоколе MGCP транзакция образуется из команды и ответа на нее, то в протоколе MEGACO/H.248 транзакция состоит из запроса - совокупности акций и отклика на запрос. Общая структура запроса выглядит так:

Каждая акция, в свою очередь, состоит из одной или нескольких команд, относящихся к одному контексту, и ответов на них (Рис. 9.5). Использование такого инструмента позволяет значительно уменьшить объем передаваемой сигнальной информации и увеличить скорость установления соединений за счет того, что контроллер может параллельно вести обработку сигнальной информации, относящейся к разным соединениям.

Аналоги двух избыточных команд EndpointConfiguration и NotificationRequest протокола MGCP в протоколе MEGACO/H.248 отсутствуют, но, в тоже время, добавлена команда Move, позволяющая в одно действие перевести порт из одного контекста в другой. В качестве примера использования команды Move приведем сценарий дополнительных услуг «Уведомление о входящем вызове и перевод существующего соединения в режим удержания», англоязычное название услуг-Call Waiting и Call Hold.

Рис. 9.5  Транзакция протокола MEGACO/H.248

Абонент А разговаривает с абонентом В, а абонент С вызывает абонента А, при этом вызываемому абоненту передается акустическое уведомление о входящем вызове {рис. 9.6). Далее абонент А переводит соединение с абонентом В в режим удержания и соединяется с абонентом С (рис. 9.7). Реализация комбинации дополнительных услуг Call Waiting и Call Hold, т.е. передача порта из одного контекста в другой, стала возможной благодаря команде Move.

Рис. 9.6  Сценарий реализации услуги Call Waiting

В заключение данного параграфа хотелось бы отметить, что неизвестно, как скоро понадобится расширенная, по сравнению с MGCP, функциональность протокола MEGACO/H.248. Кроме того, на базе протокола MGCP построен ряд сетей IP-телефонии. Все это означает, что оба протокола MGCP и MEGACO/H.248 вполне могут совместно использоваться в одной сети.

Рис. 9.7 Сценарий реализации услуги Call Hold

9.4   Структура команд и ответов

Далее идет описание команд, которые используются для манипулирования двумя основными объектами протокола MEGACO/H.248: портами и контекстами. В большинстве случаев команды передает контроллер, но существуют два исключения: команда Notify, передается шлюзом, а команда ServiceChange может передаваться и шлюзом, и контроллером. В квадратных скобках указаны необязательные дескрипторы команд. Те дескрипторы, которые расположены над командами, передаются в ответах на команды.

Команда Add добавляет порт к контексту. Если команда относится к первому порту, который должен быть добавлен к контексту, то создается новый контекст.

где TerminationID - это идентификатор порта, который должен быть добавлен к контексту. Для уже существующего порта должен быть указан его идентификатор, для несуществующего порта должен быть указан идентификатор «$». В ответе на команду должен передаваться TerminationID, назначенный шлюзом.

MediaDescriptor - необязательный дескриптор, описывающий информационные потоки.

ModemDescriptor - необязательный дескриптор, описывающий тип модема, который должен быть подключен к контексту.

MuxDescriptor - необязательный дескриптор, содержащий список портов, которые должны быть подключены к контексту.

EventsDescriptor - необязательный дескриптор, определяющий список событий, при детектировании которых порт должен оповестить контроллер.

SignalsDescriptor - необязательный дескриптор, определяющий сигналы, которые порт должен передавать в канал.

DigitMapDescriptor - необязательный дескриптор, определяющий план нумерации, который должен быть использован для соединения.

AuditDescriptor- необязательный дескриптор, специфицирующий параметры порта, которые должны быть переданы шлюзом контроллеру.

PackagesDescriptor - необязательный дескриптор, описывающий пакет поддерживаемых сигналов и событий.

Команда Modify изменяет свойства, события или сигналы для существующего порта.

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

В команде Modify используются такие же дескрипторы, как и в команде Add.

где TerminationID - идентификатор порта, который должен быть отсоединен от контекста. В случае отключения всех портов от контекста используется TerminationID «*».

В ответ на команду Subtract в дескрипторе StatisticsDescriptor шлюз посылает статистику, собранную за время соединения.

Команда Move переводит порт из текущего контекста в другой контекст в одно действие.

где TerminationID - идентификатор порта, который должен быть переведен из одного контекста в другой. Дескрипторы здесь используются такие же, как в команде Modify.

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

В ответ на команду передаются запрашиваемые параметры порта или портов шлюза.

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

В ответ на команду передаются запрашиваемые параметры порта. Команда Notify служит для того, чтобы известить контроллер о событиях, которые произошли в шлюзе.

где TerminationID идентифицирует порт, передавший команду Notify.

ObservedEventsDescriptor - дескриптор, содержащий список произошедших событий (в том порядке, в каком они происходили).

Команда ServiceChange позволяет шлюзу известить контроллер о том, что порт или группа портов вышли из обслуживания или вернулись в обслуживание. Media Gateway Controller может предписать порту выйти из обслуживания или вернуться в обслуживание. При помощи данной команды контроллер может передать управление шлюзом другому контроллеру.

где TerminationID идентифицирует порт или порты, вышедшие из обслуживания или вернувшиеся в обслуживание. Значение «Root» дескриптора TerminationID показывает, что весь шлюз вышел из обслуживания или вернулся в обслуживание.

ServiceDescriptor - дескриптор, содержащий поля со сведениями: о методе изменения состояния; причине изменения; задержке; адресе, куда должны передаваться сообщения; профиле поддерживаемого протокола и другие поля.

По аналогии с предыдущими главами, в таблицу 9.3 сведены все команды протокола MEGACO/H.248.

В заключение данного параграфа в таблице 9.4 приведены коды ошибок, используемые в протоколе MEGACO/H.248.

Таблица 9.3  Команды протокола MEGACO/H.248

9.5   Пример установления и разрушения соединения

На рисунке 9 8 приведен пример установления соединения с использованием протокола MEGACO между двумя шлюзами (Residential Gateway), управляемыми одним контроллером.

Рис. 9.8  Алгоритм установления и разрушения соединения с помощью протокола MEGACO

В данном примере вызывающий шлюз MG1 - имеет IP-адрес 124. 124. 124. 222, адрес вызываемого шлюза MG2 - 125.125.125.111 , адрес контроллера шлюзов MGC - 123.123.123.4. Порт для связи по протоколу MEGACO для всех трех устройств по умолчанию имеет значение 55555.

1. Шлюз MG1 регистрируется у контроллера MGC при помощи команды ServiceChange. Использование нулевого контекста означает что порт в настоящий момент не участвует ни в каком соединении, а использование идентификатора порта ROOT означает, что команда относится ко всему шлюзу, а не к какому-нибудь определенному порту.

3. Шлюз имеет свободные аналоговые порты, которые должны быть запрограммированы для отслеживания изменения сопротивления абонентского шлейфа, означающего поднятие абонентом трубки, после чего шлюз должен передать абоненту акустический сигнал «Ответ станции». Программирование производится при помощи команды Modify с соответствующими параметрами, причем программируется порт, находящийся в нулевом контексте. В команде указывается идентификатор порта (terminationld) - A4444, идентификатор информационного потока (streamld) - 1, транспортный адрес оборудования, передавшего команду- [123.123.123.4]:55555, специфицируется режим функционирования - дуплексный (SendReceive).

На этом же этапе в шлюз может быть загружен план нумерации (в дескрипторе digit map). В этом случае, после того как абонент поднимет трубку, шлюз должен передать ему акустический сигнал «Ответ станции» и начинать прием сигналов DTMF в соответствии с планом нумерации. Однако в нашем примере план нумерации будет загружен только после того, как абонент поднимет трубку, на 8 шаге.

Кроме того, следует отметить, что шаги 3 и 4 данного алгоритма могут быть совмещены с шагами 8 и 9, соответственно, при помощи дескриптора EventsDescriptor. При этом шаги 6 и 7 опускаются.

4. Шлюз MG1 подтверждает выполнение команды Modify:

5. Подобным же образом (шаги 1-4) программируется аналоговый порт шлюза MG2, в нашем примере имеющий идентификатор А5555.

6. Далее шлюз MG1 обнаруживает, что абонент А поднял трубку, и извещает об этом событии Media Gateway Controller при помощи команды Notify.

8. На следующем шаге MGC дает шлюзу инструкцию накапливать цифры номера вызываемого абонента в соответствии с выбранным планом нумерации. Кроме того, после получения первой цифры номера необходимо остановить передачу акустического сигнала «Ответ станции».

12. Далее контроллер MGC анализирует цифры номера вызываемого абонента, полученные от шлюза MG1, и определяет, что соединение должно проходить через шлюз MG2, к которому подключен вызываемый абонент. К вновь образованному контексту в шлюзе MG1 добавляются при помощи команды Add физический порт (аналоговый абонентский интерфейс) - А4444 и виртуальный порт(RТР- порт). Так как в этот момент шлюз, к которому прикреплен вызывающий абонент, не имеет информации о шлюзе MG2 (такой как IP-адрес, RTP-порт и поддерживаемые алгоритмы декодирования принимаемой речевой информации), то контроллер MGC предписывает шлюзу MG1 только принимать информацию (режим ReceiveOnly). Кроме того, контролер MGC специфицирует в команде Add предпочтительные для использования алгоритмы кодирования.

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

13. Шлюз MG1 создает новый виртуальный порт (RTP-порт), указывает его транспортный адрес: IP-адрес (124.124.124.222) и UDP/ RTP-порт (22220). Кроме того, шлюз выбирает алгоритмы кодирования информации, которые будут использоваться в соединении, основываясь на предпочтениях контроллера.

28. Вызываемый абонент первым завершает соединение, и шлюз MG2 извещает об этом контроллер MGC.

30. Получив информацию от любого из шлюзов о том, что один из абонентов положил трубку, контроллер MGC завершает соединение. К обоим шлюзам передается команда Subtruct. Алгоритм завершения соединения предусматривает одинаковый обмен сигнальными сообщениями между контроллером и обоими шлюзами, поэтому здесь этот алгоритм рассматривается на примере шлюза MG2.

31. Каждый из портов шлюза MG2, участвующих в соединении (физический порт - А5555 и RTP-порт - А5556), возвращает статистику, собранную за время соединения. В общем случае, контроллер может запрашивать статистическую информацию только у одного из портов.

32. После завершения соединения контроллер MGC предписывает шлюзам MG1 и MG2 быть готовыми к тому, что кто-то из обслуживаемых ими абонентов поднимет трубку. Примечательно, что портам шлюза, отображаемым окончаниями в нулевом контексте, по умолчанию может быть предписано обнаруживать, что абонент поднял трубку, при этом контроллер не передает шлюзам специальные команды, как это было показано ранее (шаг 3).

Глава 10

Качество обслуживания в сетях IP-телефонии

10.1    Что понимается под QoS?

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

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

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

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

Вместе с тем, налицо необходимость получения от сети гарантий, что в периоды перегрузки пакеты с информацией, чувствительной к задержкам, не будут простаивать в очередях или, по крайней мере, получат более высокий приоритет, чем пакеты с информацией, не чувствительной к задержкам. Иначе говоря, необходимо гарантировать доставку такой информации, как речь, видео и мультимедиа, в реальном времени с минимально возможной задержкой. Для этой цели в сети должны быть реализованы механизмы, гарантирующие нужное качество обслуживания (Quality of Service -QoS). Анализу таких механизмов и посвящена эта глава.

Идеальной была бы следующая ситуация. Приложение «договаривается» с сетью о том, что пакеты такого-то потока данных со средней скоростью предачи X Кбит/с будут доставляться от одного конца соединения к другому с задержкой не более Y мс, и что сеть в течение всего соединения будет следить за выполнением этого договора. Кроме указанной характеристики, сеть должна поддерживать согласованные значения таких параметров передачи как минимально доступная полоса частот, максимальное изменение задержки (джиттер), максимальные потери пакетов.

В конечном счете, качество обслуживания зависит не только от сети, но и от оборудования пользователя. Слабые системные ресурсы оборудования пользователя - малый объем оперативной памяти, невысокая производительность центрального процессора и др. -могут сделать показатели качества обслуживания неприемлемыми для пользователя вне зависимости от того, как соблюдает «договоренность» сеть. Хорошее качество обслуживания достигается лишь тогда, когда пользователь удовлетворительно оценивает работу системы в целом.

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

Чтобы добиться гарантий качества обслуживания от сетей, изначально на это не ориентированных, необходимо «наложить» на сеть так называемую QoS-архитектуру, которая включает в себя поддержку качества на всех уровнях стека протоколов TCP/IP и во всех сетевых элементах. Но и при этом обеспечение гарантированного качества обслуживания все равно остается самым слабым местом процесса передачи информации от источника к приемнику.

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

Кроме того, качество обслуживания - это относительное понятие; его смысл зависит от приложения, с которым работает пользователь. Как уже отмечалось раньше, разные приложения требуют разных уровней или типов качества. Например, скорее всего, пользователя не огорчит тот факт, что его текстовый файл будет передаваться на секунду дольше, или что за первую половину времени передачи будет передано 80% файла, а за вторую - 20%. В то же время, при передаче речевой информации такого рода явления весьма нежелательны или даже недопустимы.

10.2   Качество обслуживания в сетях пакетной коммутации

Идея обеспечить гарантированное качество обслуживания в сетях передачи данных впервые возникла в 1970 году, когда некий пользователь получил вместо одних данных другие. Идея была воплощена в сети Х.25. Однако пакетные системы Х.25, производя проверку ошибок на каждом сетевом узле, вносили задержку порядка нескольких сотен миллисекунд в каждом узле на пути информации от отправителя до получателя.

В сетевых узлах (коммутаторах пакетов) высокоскоростных транспортных сетей Frame Relay проверка и коррекция ошибок не производятся. Эти функции возложены на оборудование пользователя, вследствие чего задержка при передаче информации по таким сетям намного ниже, чем в сетях X. 25.

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

Но самой популярной сегодня технологией пакетной передачи информации является технология маршрутизации пакетов IP. Объем потоков данных, передаваемых по глобальной информационной сети Интернет, удваивается каждые три месяца. Частично это происходит из-за постоянного увеличения количества новых пользователей сети Интернет, а также из-за того, что мультимедийная передача и видеоконференции через Интернет стали, наконец-то, доступны и популярны среди обеспеченных пользователей. Качество обслуживания в этой сети привлекает все более пристальное внимание специалистов и пользователей, так как в Интернет заключается все больше сделок и контрактов, а рост ее пропускной способности несколько отстает от роста спроса.

10.3   Трафик реального времени в IP-сетях

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

Телефонный разговор-это интерактивный процесс, не допускающий больших задержек. В соответствии с рекомендацией ITU-T G. 114 для большинства абонентов задержка речевого сигнала на 150 мс приемлема, а на 400 мс - недопустима.

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

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

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

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

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

В сетях традиционных операторов обслуживается трафик разных видов, поэтому в таких сетях, чтобы обеспечить приемлемое качество, целесообразно применять дифференцированное обслуживание разнотипного трафика (Diff-Serv).

10.4   Дифференцированное обслуживание разнотипного трафика - Diff-Serv

Для обеспечения гарантированного качества обслуживания комитет IETF разработал модель дифференцированного обслуживания разнотипного трафика - Diff-Serv. В соответствии с этой моделью байт ToS (Type of Service) в заголовке IP-пакета получил другое название DS (Differentiated Services), а шесть его битов отведены под код Diff-Serv. Каждому значению этого кода соответствует свой класс PHB (Per-Hop Behavior Forwarding Class), определяющий уровень обслуживания в каждом из сетевых узлов. Пакеты каждого класса должны обрабатываться в соответствии с определенными для этого класса требованиями к качеству обслуживания.

Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра. Пример сети согласно модели Diff-Serv приведен на рисунке 10.1.

Рис. 10.1   Модель Diff-Serv

Поступающий в сеть трафик классифицируется и нормализуется пограничными маршрутизаторами. Нормализация трафика предусматривает измерение его параметров, проверку соответствия заданным правилам предоставления услуг, профилирование (при этом пакеты, не укладывающиеся в рамки установленных правил, могут быть отсеяны) и другие операции. В ядре магистральные маршрутизаторы обрабатывают трафик в соответствии с классом РНВ, код которого указан в поле DS.

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

•   класс срочной пересылки пакетов (Expedited Forwarding PHB Grouo);

•   класс гарантированной пересылки пакетов (Assured Forwarding PHB Group).

Механизм обеспечения QoS науровне сетевого устройства, применяемый в Diff-Serv, включает в себя четыре операции. Сначала пакеты классифицируются на основании их заголовков. Затем они маркируются в соответствии с произведенной классификацией (в поле Diff-Serv). В зависимости от маркировки выбирается алгоритм передачи (при необходимости - с выборочным удалением пакетов), позволяющий избежать заторов в сети. Заключительная операция, чаще всего, состоит в организации очередей с учетом приоритетов [15].

Хотя эта модель и не гарантирует качество обслуживания на 100%, у нее есть серьезные преимущества. Например, нет необходимости в организации предварительного соединения и в резервировании ресурсов. Атак как в модели Diff-Serv используется небольшое, фиксированное количество классов и трафик абонентов распределяется по общим очередям, не требуется высокая производительность сетевого оборудования.

10.5   Интегрированное обслуживание IntServ

Этот подход явился одной из первых попыток комитета IETF разработать действенный механизм обеспечения качества обслуживания в IP-сетях. Для трафика реального времени вводятся два класса обслуживания: контролируемой загрузки сети и гарантированного обслуживания.

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

Класс контролируемой загрузки сети идентичен традиционному подходу «best effort», но уровень QoS для уже обслуживаемого потока данных остается неизменным при увеличении нагрузки в сети.

Основными компонентами модели IntServ являются система резервирования ресурсов, система контроля доступа, классификатор и диспетчер очередей. Архитектура модели изображена на рис. 10.2. Спецификация потока (flow specification) нужна для определения необходимого уровня качества обслуживания потока.

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

10.6   Протокол резервирования ресурсов - RSVP

10.6.1   Общие принципы протокола

Чтобы обеспечить должное качество обслуживания трафика речевых и видеоприложений, необходим механизм, позволяющий приложениям информировать сеть о своих требованиях. На основе этой информации сеть может резервировать ресурсы для того, чтобы гарантировать выполнение требований к качеству, или отказать приложению, вынуждая его либо пересмотреть требования, либо отложить сеанс связи. В роли такого механизма выступает протокол резервирования ресурсов RSVP (Resource Reservation Protocol).

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

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

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

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

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

В основе протокола RSVP лежат три компонента:

•   сеанс связи, который идентифицируется адресом получателя данных;

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

•   спецификация фильтра, определяющая тип трафика, для обслуживания которого запрашивается ресурс.

10.6.2 Процедура резервирования ресурсов

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

Сообщение Path должно нести в себе шаблон данных отправителя {Sender Template), описывающий тип этих данных. Шаблон специфицирует фильтр, который отделяет пакеты данного отправителя от других пакетов в пределах сессии (по IP-адресу отправителя и, возможно, по номеру порта). Кроме того, сообщение Path должно содержать спецификацию потока данных отправителя Tspec, которая определяет характеристики этого потока. Спецификация Tspec используется, чтобы предотвратить избыточное резервирование.

Шаблон данных отправителя имеет тот же формат, что и спецификация фильтра в сообщениях Resv (см. ниже).

Приняв сообщение Path, его получатель передает к маршрутизатору, от которого пришло это сообщение (т.е. по направлению к отправителю), запрос резервирования ресурсов - сообщение Resv, В дополнение к информации Tspec, сообщение Resv содержит спецификацию запроса (Rspec), в которой указываются нужные получателю параметры качества обслуживания, и спецификацию фильтра (filter-spec), определяющую, к каким пакетам сессии относится данная процедура (по IP-адресу отправителя и, возможно, по номеру порта).

Когда получатель данных передает запрос резервирования, он может запросить передачу ему ответного сообщения, подтверждающего резервирование.

При получении сообщения Resv каждый маршрутизатор резервируемого пути, поддерживающий протокол RSVP, определяет, приемлем ли этот запрос, для чего выполняются две процедуры. С помощью механизмов управления доступом проверяется, имеются ли у маршрутизатора ресурсы, необходимые для поддержки запрашиваемого качества обслуживания, а с помощью процедуры авторизации пользователей (policy control) - правомерен ли запрос резервирования ресурсов. Если запрос не может быть удовлетворен, маршрутизатор отвечает на него сообщением об ошибке.

Если же запрос приемлем, данные о требуемом качестве обслуживания поступают для обработки в соответствующие функциональные блоки (способ обработки параметров QoS маршрутизатором в протоколе RSVP не определен), и маршрутизатор передает сообщение Resv следующему (находящемуся ближе к отправителю данных) маршрутизатору. Это сообщение несет в себе спецификацию flowspec, содержащую два набора параметров:

•   «Rspec», который определяет желательное QoS,

•   «Tspec», который описывает информационный поток.

Вместе flowspec и filterspec представляют собой дескриптор потока, используемый маршрутизатором для идентификации каждой процедуры резервирования ресурсов.

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

После окончания вышеописанной процедуры ее инициатор начинает передавать данные и на их пути к получателю будет обеспечено заданное QoS.

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

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

Протокол RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA {One Path With Advertising) (OPWA95). С помощью OPWA управляющие пакеты RSVP, передаваемые вдоль маршрута, могут быть использованы для переноса данных, которые позволяют предсказывать QoS маршрута в целом.

С точки зрения узла сети работа протокола RSVP выглядит так:

1.   Получатель вступает в группу многоадресной рассылки, отправляя соответствующее сообщение протокола IGMP ближайшему маршрутизатору;

2.  Отправитель передает сообщение по адресу группы;

3.   Получатель принимает сообщение Path, идентифицирующее отправителя;

4.  Теперь получатель имеет информацию об обратном пути и может отправлять сообщение Resv с дескрипторами потока;

5.  Сообщения Resv передаются по сети отправителю;

6.  Отправитель начинает передачу данных;

7.   Получатель начинает передачу данных.

Несмотря на то, что протокол RSVP является важным инструментом в арсенале средств, обеспечивающих гарантированное качество обслуживания, этот протокол не может решить все проблемы, связанные с QoS. Основные недостатки протокола RSVP - большой объем служебной информации и большие затраты времени на организацию резервирования.

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

Протокол RSVP работает с пакетами IP и не затрагивает схем сжатия, циклического контроля (CRCs) или работы с кадрами уровня звена данных (Frame Relay, PPP, HDLC).

Например, при использовании для IP-телефонии алгоритма кодирования речи G.729, обеспечивающего, с учетом сжатия заголовков RTP-пакетов, передачу речи со скоростью около 11 Кбит/с, в оборудовании Cisco по протоколу RSVP резервируется ресурс с пропускной способностью 24 Кбит/с. Другими словами, в канале с пропускной способностью 56 Кбит/с разрешено резервировать ресурс только для двух потоков со скоростью 24 Кбит/с каждый, даже если полоса пропускания располагает ресурсом для трех потоков со скоростью 11 Кбит/с каждый. Чтобы обойти это ограничение, можно применить следующий прием. Средствами эксплуатационного управления функциональному блоку RSVP маршрутизатора сообщается, например, что канал с фактической полосой пропускания 56 Кбит/с имеет, якобы, пропускную способность 100 Кбит/с и что допускается использовать для резервирования 75% его полосы пропускания. Такой «обман» разрешит протоколу RSVP резервировать полосу пропускания, которая необходима для трех речевых потоков, закодированных по алгоритму G.729. Очевидно, что при этом есть опасность перегрузки канала с реальной полосой 56 Кбит/с, если сжатие заголовков RTP-пакетов не применяется.

10.7   Технология MPLS

Технология многопротокольной коммутации по меткам (Multiprotocol Label Switching - MPLS), разработанная комитетом IETF, явилась результатам слияния нескольких разных механизмов, таких как IP Switching (Ipsilon), Tag Switching (Cisco Systems), Aris (IBM) и Cell Switch Router (Toshiba). В архитектуре MPLS собраны наиболее удачные элементы всех упомянутых механизмов, и благодаря усилиям IETF и компаний, заинтересованных в скорейшем продвижении этой технологии на рынке, она превратилась в стандарт Internet.

В обычных IP-сетях любой маршрутизатор, находящийся на пути следования пакетов, анализирует заголовок каждого пакета, чтобы определить, к какому потоку этот пакет относится, и выбрать направление для его пересылки к следующему маршрутизатору. При использовании технологии MPLS соответствие между пакетом и потоком устанавливается один раз, на входе в сеть MPLS. Более точно, соответствие устанавливается между пакетом и так называемым «классом эквивалентности пересылки» FEC (Forwarding Equivalence Class); к одному FEC относятся пакеты всех потоков, пути следования которых через сеть (или часть сети) совпадают. С точки зрения выбора ближайшего маршрутизатора, к которому их надо пересылать, все пакеты одного FEC неразличимы. Пакеты снабжаются метками -идентификаторами небольшой и фиксированной длины, которые определяют принадлежность каждого пакета тому или иному классу FEC. Метка имеет локальное значение она действительна на участке между двумя соседними маршрутизаторами, являясь исходящей меткой определенного FEC для одного из них и входящей - для второго. Второй маршрутизатор, пересылая пакет этого FEC к следующему маршрутизатору, снабжает его другой меткой, которая идентифицирует тот же FEC на следующем участке маршрута, и т.д. Таким образом, каждый FEC имеет свою систему меток.

Использование меток значительно упрощает процедуру пересылки пакетов, так как маршрутизаторы обрабатывают не весь заголовок IP-пакета, а только метку, что занимает значительно меньше времени.

На рис. 10.4 показана, в качестве примера, простейшая MPLS- ceть содержащая маршрутизаторы двух типов;

•    пограничные маршрутизаторы MPLS (Label Edge Routers - LER)

•   транзитные маршрутизаторы M PLS (Label Switching Routers - LSR По отношению к любому потоку пакетов, проходящему через MPLS-сеть, один LER является входным, а другой LER – выходным.  Входной LER анализирует заголовок пришедшего извне пакета, устанавливает, какому FEC он принадлежит, снабжает этот пакет меткой, которая присвоена данному FEC, и пересылает пакет к соответствующему LSR. Далее, пройдя, в общем случае, через несколько LSR, пакет попадает к выходному LER, который удаляет из пакета метку, анализирует заголовок пакета и направляет его к адресату, находящемуся вне MPLS-сети.

Рис. 10.4 Сеть, построенная на базе технологии MPLS

Последовательность (LER_bx, LSR,,..., LSR_n, LER_вых) маршрутизаторов, через которые проходят пакеты, принадлежащие одному FEC, образует виртуальный коммутируемый по меткам тракт LSP (Label Switched Path). Так как один и тот же LER для одних потоков является входным, а для других-выходным, в сети, содержащей N LER, в простейшем случае может существовать N(N-1) FEC и, соответственно, N(N-1)LSP.

Заметим, однако, что потоки пакетов из разных FEC, приходящие к одному выходному LER от разных входных LER, могут в каких-то LSR сливаться в более мощные потоки, каждый из которых образует новый FEC со своей системой меток. Возможно и обратное, то есть группа потоков может идти до некоторого LSR по общему маршруту и, следовательно, принадлежать одному и тому же FEC, а затем разветвиться, и тогда каждая ветвь будет иметь свой FEC (со своей системой меток). Кроме того, существует возможность образования внутри некоторого LSP одного или нескольких вложенных в него LSP (так называемых LSP-туннелей).

То обстоятельство, что система меток, присваиваемых пакету, может изменяться, приводит к образованию так называемого «стека меток». При переходе потока пакетов в другой FEC, метка нового FEC помещается поверх метки прежнего FEC и используется для коммутации, а прежняя метка сохраняется под ней, но не используется до тех пор, пока не восстановится прежний FEC. Ясно, что если FEC пакета меняется несколько раз, в стеке накапливается несколько меток.

Все это, с одной стороны, демонстрирует, насколько широки возможности MPLS в части распределения ресурсов сети при ее проектировании и в части их оперативного перераспределения при эксплуатации, но, с другой стороны, предъявляет непростые требования к средствам, с помощью которых устанавливается соответствие «FEC-метка» в каждом LER и LSR сети.

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

Метки для каждого FEC всегда назначаются «снизу», то есть либо выходным LER, либо тем LSR, который является для этого FEC «нижним» (расположенным ближе к адресату), и распределяются им по тем маршрутизаторам, которые расположены «выше» (ближе к отправителю).

Распределение меток может быть независимым или упорядоченным. В первом случае LSR может уведомить вышестоящий LSR о привязке метки к FEC еще до того, как получит информацию о привязке «метка-FEC» от нижестоящего маршрутизатора. Во втором случае высылать подобное уведомление разрешается только после получения таких сведений «снизу». Метки могут выдаваться нижним маршрутизатором как по собственной инициативе, так и по запросу верхнего. Наконец, возможен «либеральный» или «консервативный» режим распределения меток. В либеральном режиме нижний LSR раздает метки вышестоящим LSR, как имеющим с ним прямую связь, так и доступным лишь через промежуточные LSR. В консервативном режиме вышестоящий LSR обязан принять метку, если ее выдает смежный LSR, но может отказаться от метки, пришедшей к нему транзитом.

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

Для распределения меток может использоваться либо специальный протокол LDP (Label Distribution Protocol), либо модифицированная версия одного из существующих протоколов сигнализации (например, протокола RSVP).

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

MPLS предусматривает два способа пересылки пакетов. При одном способе каждый маршрутизатор выбирает следующий участок маршрута самостоятельно, а при другом заранее задается цепочка маршрутизаторов, через которые должен пройти пакет. Второй способ основан на том, что маршрутизаторы на пути следования пакета действуют в соответствии с инструкциями, полученными от одного из LSR данного LSP (обычно - от нижнего, что позволяет совместить процедуру «раздачи» этих инструкций с процедурой распределения меток).

Поскольку принадлежность пакетов тому или иному FEC определяется не только IP-адресом, но и другими параметрами, нетрудно организовать разные LSP для потоков пакетов, предъявляющих разные требования к QoS. Каждый FEC обрабатывается отдельно от остальных не только в том смысле, что для него образуется свой LSP, но и в смысле доступа к общим ресурсам (полосе пропускания канала, буферному пространству). Поэтому технология MPLS позволяет очень эффективно поддерживать требуемое QoS, соблюдая предоставленные пользователю гарантии.

Конечно, подобный результат удается получить и в обычных IP-сетях, но решение на базе MPLS проще и гораздо лучше масштабируется.

10.8   Обслуживание очередей

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

•   организации очереди;

•   обработки очередей.

10.8.1   Алгоритмы организации очереди

Существует два основных алгоритма организации очереди: Tail Drop и Random Early Detection.

10.8.1.1  Алгоритм Tail Drop

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

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

В некоторых ситуациях данный алгоритм может вызвать так называемый эффект «локаута» (lock-out). Это происходит в тех случаях, когда очередь монополизирует либо один поток пакетов, либо несколько потоков, случайно или по необходимости синхронизированных (например, потоков, несущих изображение и его звуковое сопровождение), что препятствует попаданию в очередь пакетов остальных потоков.

Алгоритм Tail Drop приводит к тому, что очереди оказываются заполненными (или почти заполненными) в течение длительного периода времени. Так происходит, поскольку алгоритм сигнализирует только о том, что очередь полна. Большой размер очередей сильно увеличивает время доставки пакета от одной рабочей станции к другой. Поэтому желательно, чтобы средний размер очередей в маршрутизаторах был невелик. С другой стороны, известно, что трафик в сети, как правило, неравномерен, и поэтому маршрутизатор должен иметь буфер, размер которого достаточен для того, чтобы «амортизировать» неравномерность трафика.

Имеются альтернативные алгоритмы отбрасывания пакетов: Random Drop (отбрасывание случайно выбранного) и Drop from Front (отбрасывание первого). Принцип работы алгоритма Random Drop понятен из его названия. При заполнении очереди отбрасывается не пакет, пришедший последним, а пакет, выбираемый из очереди случайно. Такой алгоритм предъявляет более высокие требования к вычислительным ресурсам маршрутизатора, поскольку он производит с очередью более сложные операции. Алгоритм Drop from Front отбрасывает пакет, стоящий в очереди первым. Помимо значительного снижения вероятности «локаута», этот алгоритм выгодно отличается от алгоритма Tail Drop тем, что при использовании протокола TCP рабочая станция раньше узнает о перегрузке в сети и, соответственно, раньше снижает скорость передачи пакетов.

10.8.1.2 Алгоритм Random Early Detection (RED)

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

При малых размерах очередей метод RED более эффективен, чем другие методы. Он также более устойчив к трафику, имеющему «взрывной» характер.

10.8.2 Алгоритмы обработки очередей

Алгоритмы обработки очередей составляют одну из основ механизмов обеспечения гарантированного качества обслуживания в сетевых элементах.

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

10.8.2.1   Стратегия FIFO

Алгоритм обслуживания очередей Firstln, FirstOut (FIFO), также называемый First Come First Served является самым простым. Пакеты обслуживаются в порядке поступления без какой-либо специальной обработки.

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

10.8.2.2 Очередь с приоритетами

Очередь с приоритетами (Priority Queuing) - это алгоритм, при котором несколько очередей FIFO (могут использоваться алгоритмы Tail Drop, RED и т.д.) образуют одну систему очередей. В случае простейшего приоритетного обслуживания трафик определенных классов имеет безусловное преимущество перед трафиком других классов. Например, если все IPX-пакеты имеют более высокий приоритет, чем IP-пакеты, то какова бы ни была ценность IP данных, IPX данные будут иметь первоочередной приоритет при разделе доступной полосы. Такой алгоритм гарантирует своевременную доставку лишь наиболее привилегированного трафика.

Рис. 10.6  Очереди с приоритетами

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

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

10.8.2.3 Class-Based Queuing (CBQ)

При использовании этого механизма трафику определенных классов гарантируется требуемая скорость передачи, а оставшийся ресурс распределяется между остальными классами. Например, администратор может зарезервировать 50% полосы пропускания для SNA-трафика, а другие 50% разделить между остальными протоколами, такими как IP и IPX.

Обработка очередей по алгоритму Class-Based Queuing, CBQ предполагает, что трафик делится на классы. Определение класса трафика в значительной степени произвольно. Класс может представлять весь трафик, проходящий через данный интерфейс, трафик определенных приложений, трафик, направленный к заданному подмножеству получателей, трафик с качеством услуг, гарантированным протоколом RSVP. Каждый класс имеет собственную очередь, и ему гарантируется, по крайней мере, некоторая доля пропускной способности канала. Драйвер интерфейса обходит все очереди по кругу и передает некоторое количество пакетов из каждой очереди. Если какой-либо класс не исчерпывает предоставленный ему лимит пропускной способности, то доля полосы пропускания, выделяемая каждому из остальных классов, пропорционально увеличивается.

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

Как и в предыдущем случае, используются очереди FIFO, следовательно, для потоков, разделяющих одну очередь, остаются проблемы, присущие FIFO, но гарантируется некоторая справедливость распределения ресурсов в сети между разными очередями. Кроме того, в отличие от приоритетного обслуживания, CBQ не допускает блокировки очереди и дает возможность учитывать использование сети разными классами.

Рис. 10.7  Иерархия классов.при использовании алгоритма CDQ

10.8.2.4 Взвешенные очереди

Если необходимо обеспечить для всех потоков постоянное время задержки, и не требуется резервирование полосы пропускания, то можно воспользоваться алгоритмом Weighted Fair Queuing.

Рис. 10.8   Взвешенные очереди

Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда каждому классу соответствуют свой поток (TCP-сеанс и т.д.). Как и в случае CBQ, каждому классу WFQ отводится одна очередь FIFO и гарантируется некоторая часть пропускной способности канала, в соответствии с весовым коэффициентом потока. Если некоторые потоки не используют предоставленную им полосу пропускания полностью, то другие потоки соответственно увеличивают свою долю. Так как в данном случае каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна гарантии максимальной задержки. Зная параметры сообщения, можно по известным формулам вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку.

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

Определение веса потока производится по полю precedence заголовка IP-пакета. Значение данного поля лежит в пределах от 0 до 7. Чем выше значение, тем большая полоса выделяется потоку.

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

10.8.3 Алгоритмы сглаживания пульсации трафика

10.8.3.1  Алгоритм Leaky Bucket

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

Представим себе ведро, в котором накапливаются данные, получаемые от отправителя. В днище ведра имеются отверстия, через которые данные «вытекают» из него для дальнейшей обработки {или передачи). Через определенные интервалы времени подсчитывается объем данных, которые накопились в ведре в течение интервала, предшествовавшего моменту подсчета. Если объем не превышает порога В, всплеск скорости передачи данных внутри этого интервала считается нормальным, и никаких действий не производится. Если объем накопившихся данных превысил порог В, все пакеты, оказавшиеся выше порога, но ниже краев ведра, снабжаются меткой DE {Discard Eligibility), а те, которые не поместились в ведре, отбрасываются. В следующем интервале данные продолжают поступать в ведро и вытекать из него в обычном порядке {независимо от наличия меток), но если ведро переполняется, то отбрасываются не вновь поступающие пакеты, а пакеты с меткой DE, которые еще не успели вытечь. Если при следующем подсчете окажется, что объем данных в ведре ниже порога В, то никаких действий не производится. Если порог превышен, и в числе пакетов, оказавшихся выше порога, имеются пакеты без метки DE, они получают такую метку.

Одна из версий этого алгоритма, называемая Generic Cell Rate Algorithm (GCRA), применяется в сетях ATM для контроля некоторых параметров.

10.8.3.2 Алгоритм «Token Bucket»

Алгоритм выполняет «калибровку» трафика, т.е. уменьшает до заданного предела пульсацию скорости потока данных и гарантирует, что не будет превышена заданная средняя скорость этого потока.

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

Глава 11

Принципы реализации

11.1    Оборудование IP-телефонии

Как оказалось, мудрым советом знаменитого бизнесмена Аристотеля Онассиса «Не гонись за деньгами - иди им навстречу» воспользовался целый ряд компаний, преуспевших в разработке программных средств и оборудования IP-телефонии, среди которых-VocalTec, Dialogic, Cisco, Ascend, 3Com, Nortel, Lucent, IBM, Motorola, RAD, Rockwell, Digitcomn др.

Некоторые из продуктов названных компаний уже упоминались на страницах этой книги. Так, в главе 5 обсуждались принципы построения оборудования, реализующего самый распространенный на сегодняшний день протокол Н.323; в главе 7 были отчасти затронуты технические решения, поддерживающие протокол SIP, а в главе 8 рассмотрены аспекты реализации протокола MGCP. Здесь же рассматриваются некоторые интересные решения в построении оборудования IP-телефонии, не вошедшие в предыдущие главы.

Начнем анализ с продукции компании Nortel Networks, выдвинувшей новый подход, который назван философией вечной молодости (Evergreen). Применительно к тематике данной книги этот принцип нашел свое воплощение в концепции Inca (Internet Communications Architecture), объявленной 8 июня 1999 г. и предусматривающей постепенное оснащение уже существующих IP-сетей функциями IP-телефонии.

Примером практической реализации концепции Nortel Networks является платформа MMCS (MultiMedia Carrier Switch), прошедшая сертификацию для ВСС России и известная по публикациям в журналах. Другими примерами являются семейство Magellan - пакетные коммутаторы серии DPN (протоколы Х.25, FR) и модельный ряд Passport - устройства доступа с компрессией речи по протоколу FR -Passport 4400, мультипротокольные маршрутизаторы серии Passport 7000/6000, пограничные устройства Passport Voice Gateway, сопрягающие телефонные сети и сети ATM, а также высокоскоростные ATM-коммутаторы Passport 15000. Все это оборудование позволяет полностью интегрировать речь, факсимильные сообщения, видеоинформацию, данные по протоколам IP, FR, SNA, X.25, HDLC, и обеспечивать мультимедийные услуги, оптимизируя использование имеющихся ресурсов (например, при передаче речи применяется технология передачи пакетов с переменной скоростью).

Еще одним примером оборудования IP-телефонии может служить универсальный маршрутизатор IP45/951 с функциями передачи речи и мультимедийной информации по IP-сетям, входящий в гамму продуктов корпорации NEC, Япония. Маршрутизатор IP45/951 реализует функции шлюза и привратника. Маршрутизатор поддерживает большое количество алгоритмов кодирования речи, в том числе, ITU-T G.729, G.729a, G.729b, G.729ab, G.723.1, G.729.1a, G.711, G.711VAD, G.728 и G.72SVAD. Это позволяет маршрутизатору IP45/951 соединяться практически со всеми шлюзами, поддерживающими протокол Н.323, в то время как возможности многих шлюзов ограничены небольшим количеством поддерживаемых алгоритмов кодирования. Маршрутизатор IP45/951 обеспечивает хорошее качество передачи речи благодаря следующим особенностям:

•   применение современных алгоритмов кодирования;

•   подавление эха (64 мс);

•   сглаживание джиттера;

•   подавление пауз в разговоре;

•   генерация комфортного шума;

•   поддержка протокола RSVP;

•   сжатие заголовков IP/UDP/RTP;

•   поддержка приоритетов для различных видов трафика.

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

Это же справедливо и в отношении программного обеспечения IP-телефонии, оно доступно и недорого. Популярные продукты Microsoft NetMeeting, IDT Net2Phone и DotDialer реализуют разные схемы телефонной связи через IP-сети: NetMeeting используется для связи по схеме «компьютер-компьютер», a Net2Phone и DotDialer реализуют схему «компьютер-телефон». Оба эти сценария IP-телефонии уже обсуждались в главе 2. Там же отмечались сложность и актуальность программно-аппаратных средств, реализующих сценарий «телефон-телефон».

За последнее время появились следующие виды оборудования IP-телефонии для всех этих сценариев:

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

2.  Магистральные речевые платы с интерфейсом 10/100BaseT (ЛВС Ethernet) для подключения учрежденческих АТС существующих моделей к корпоративной IP-сети. После установки в АТС такой платы речевой трафик в виде IP-пакетов может быть направлен по локальной или глобальной пакетной сети подобно тому, как он сейчас передается от АТС по телефонной сети.

3. Телефонные аппараты, упаковывающие речевую информацию в IP-пакеты (IP-телефоны) и подключаемые не к телефонной сети, а непосредственно к ЛВС Ethernet. Как правило, такие аппараты требуют от сетевого администратора минимальных настроек, используя протокол динамической конфигурации -Dynamic Host Configuration Protocol (DHCP).

4. Специализированные коммутаторы речевых пакетов, предназначенные для выполнения функций традиционной АТС на базе протокола IP. В литературе такие устройства часто называют IP-АТС, но это название представляется нам не совсем корректным, поскольку в данном случае осуществляется не автоматическая коммутация каналов, а коммутация пакетов.

Аппаратура IP-телефонии выпускается в совмещенной или автономной конструкции. Совмещенный сервер выполняет функции шлюза, привратника и администратора (manager), т.е. маршрутизацию, сбор биллинговой информации (IP-адрес, время начала и конца разговора и т.п.), подавление эхосигналов, детектирование пауз в разговоре, заполнение пауз на приеме комфортным шумом {comfort noise), буферизацию принятых пакетов для уменьшения джиттера, интерполяцию потерянных речевых пакетов, а также контроль состояния разговорного канала (среднее время задержки, джиттер, процент потерь пакетов). В автономной конструкции эти функции выполняются отдельными устройствами.

В ранних моделях цифровая обработка сигнала производилась программными средствами. Позднее программную обработку сменила аппаратная, основную роль стали выполнять уже упоминавшиеся в главе 3 платы DSP (Digital Signal Processing), что разгрузило основной процессор и оперативную память, увеличило число портов оборудования и уменьшило время задержки речевой информации. Наиболее известны платы DSP фирм Texas Instrument, Dialogic (DM3 IP Link) и Natural Microsystems (Quad E1).

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

•   полная поддержка рекомендаций Н.323;

•   поддержка всех основных алгоритмов кодирования речи;

•   поддержка основных систем телефонной сигнализации (ОКС7, DSS1,R1.5и т.д.);

•   удобство и функциональность средств управления и контроля. Важная категория удовлетворяющего этим требованиям оборудования IP-телефонии предназначена для построения сетевой инфраструктуры. Сегодня это главное препятствие для развития IP-телефонии, с которым столкнулись региональные операторы. Проблема состоит в построении структуры IP-сети, которая могла бы дать им шанс скоординировать свои действия и собрать свои ресурсы для того, чтобы составить конкуренцию операторам и поставщикам традиционного оборудования междугородной и международной связи. Для решения этой проблемы и создания магистральных транзитных узлов сегодня имеются сверхскоростные маршрутизаторы IP-пакетов производства Avici Systems Inc. (Челмсфорд, Массачусетс), Berkeley Networks Inc. (Сан Хосе, Калифорния), Gigapacket Networks Inc. (Литтлтон, Массачусетс), Juniper Networks (Санта Клара, Калифорния), Neonet LLC (Уэстборо, Массачусетс) и Torrent Networking Technologies Inc. (Лендовер, Мэриленд). Эти маршрутизаторы могут объединяться в IP-сети коммутаторами ATM, SDH/Sonet производства Ascend, Cisco и др.

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

В настоящее время несколько десятков компаний выпускают подобные изделия, среди них Cisco Systems, VocalTec, Lucent Technologies и др. Более того, на базе этих шлюзов почти каждая крупная телекоммуникационная компания имеет или заявленное, или уже поставляемое изделие IP-телефонии. Предлагаются АТС, реализованные на основе технологии маршрутизации IP-пакетов. Компания Cisco выпустила интегрированный сервер доступа AS5300 с коммутатором Catalyst 5500. Компания Ascend Communications Inc. объединила модем для коммутируемых каналов TNT с гигабитным маршрутизатором GRF. Компания 3Com добавила передачу речи по IP и факс в свой концентратор Total Control Hub.

Согласно некоторым оценкам, объем рынка сетевых изделий IP-телефонии в 2001 году составит 1.8 миллиарда долларов, а рынка устройств доступа к сетям IP-телефонии - 7.5 миллиарда долларов. Как известно из предыдущего опыта, эксплуатация оборудования создает рынок в десять раз выше, чем общая стоимость установленного оборудования. Поэтому общий рынок оборудования передачи речи по IP-сетям уже сегодня можно оценить в 90 миллиардов долларов.

11.2   Особенности оборудования IP-телефонии для России

При внедрении технологии передачи речевой информации по сетям с маршрутизацией IP-пакетов во Взаимоувязанной сети связи Российской Федерации (ВСС РФ), помимо рассмотренных выше, возникают следующие специфические трудности:

- при подключении оборудования IP-телефонии к АТС телефонной сети общего пользования по двухпроводным аналоговым абонентским линиям препятствием часто становится большое затухание сигналов в этих линиях;

- при подключении оборудования IP-телефонии к коммутационному оборудованию ТфОП по межстанционным соединительным линиям затруднения связаны с тем, что декадно-шаговые и координатные АТС имеют специфические системы сигнализации [6], основная из которых определяется неформальным, но весьма точным термином «R полтора»;

- присутствующие в ТфОП декадно-шаговые АТС создают большие помехи и поддерживают только импульсный набор номера.

Специфические требования к оборудованию IP-телефонии, подключаемому к ВСС России, изложены в руководящем документе отрасли РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденном Министерством связи 12.11.99 г., изложение которого выходит за рамки данной книги. Сэкономленное таким образом место отдано краткому описанию отечественной платформы IP-телефонии ПРОТЕЙ-IP, реализующей все требования данного РД и учитывающей упомянутую выше специфику ВСС России.

11.3   Шлюз IР-телефонии Протей-ITG

Шлюз IP-телефонии Протей-ITG реализует передачу речевого трафика и факсимильной информации по сетям с маршрутизацией пакетов IP по протоколу Н.323, версия 2. Основным функциональным назначением шлюза является преобразование речевой информации, поступающей отТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковка речевой информации в пакеты RTP/UDP/IR а также обратное преобразование. Кроме того, шлюз конвертирует сигнальные сообщения систем сигнализации E-DSS1 и ОКС7 (ISUP-R, российская версия) в сигнальные сообщения Н.323 и производит обратное преобразование по рекомендации ITU H.246.

Шлюз Протей-ITG подключается к ТфОП по цифровым линиям со скоростью передачи 2048 Кбит/с (Е1) с использованием сигнализации ISUP-R системы общеканальной сигнализации ОКС7, абонентской сигнализации E-DSS1, а также сигнализации по двум выделенным сигнальным каналам «R1.5», а к сетям с маршрутизацией пакетов IP - при помощи интерфейса 10/100 BaseT.

В таблицу 11.1 сведены основные технические характеристики шлюза.

Таблица 11.1  Технические спецификации шлюза IP-телефонии «Протей-ITG»

На рис.11.1. изображена обобщенная структура шлюза IP-телефонии Протей-ITG. Следует отметить, что кодирование и пакетирование речевых сигналов, поступающих из ТфОП для последующей их передачи по IP-сети, реализованы в Протей-ITG на базе специализированных процессоров обработки цифровых сигналов - Digital Signal Processors (DSP). Остальные функции выполняются программным обеспечением, использующим универсальный процессор.

Рис. 11.1   Структурная схема шлюза Протей-ITG

Модуль обработки телефонной сигнализации взаимодействует с телефонным оборудованием, преобразуя сигналы систем DSS1 и ОКС7 во внутрисистемные примитивы, которые отражают состояния процесса обслуживания вызова (установление соединения, отбой и т.п.) и используются модулем логики услуг шлюза для установления соединений между ТфОП и IP-сетью.

Модуль сигнализации Н.323 обрабатывает сигнальную информацию протоколов RAS,H.225.0 (Q.931) и Н.245. Информация о состояниях процесса обслуживания вызова в IP-сети передается в модуль логики услуг шлюза.

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

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

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

Рис. 11.2  Модуль пакетирования речи

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

В архитектуру платформы включен упрощенный вариант шлюза IP-телефонии - устройство уплотнения соединительных линий - для уплотнения межстанционных соединительных линий связи (сигнальных и разговорных каналов) и передачи мультиплексированной информации через сеть IP с последующим ее демультиплексированием на удаленной стороне. Данное устройство может использоваться, например, операторами сотовой связи для уменьшения числа соединительных линий. В таком варианте шлюза IP-телефонии отсутствует стандартная обработка сигнальных сообщений (сигнальная информация ОКС7 передается прозрачно), так как разговорные каналы постоянно открыты и по ним передается сжатая речь с подавленными паузами. Кроме того, система автоматически обнаруживает сигналы факса и начинает вести обработку информации по протоколу Т.38; после окончания факсимильной сессии система возвращается на прежний режим работы.

11.4   Привратник Протей-GK и варианты организации связи

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

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

•   регистрация оконечного оборудования;

•   контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (Рекомендация ITU H.225.0);

•   преобразование alias-адреса (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сети с маршрутизацией пакетов IP (IP адрес + номер порта TCP/UDP);

•   контроль, управление и резервирование пропускной способности сети;

•   ретрансляция сигнальных сообщений Н.225.0 и Н.245 между терминалами.

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

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

В первом варианте шлюз IР-телефонии Протей-ITG и привратник Протей-GK подключаются к существующей сети IР-телефонии.

Подключение может осуществляться на правах корпоративного клиента, т.е. биллинговым центром поставщика услуг IР-телефонии выставляется групповой счет местному оператору у которого установлено оборудование Протей-IP, а оператор в свою очередь выставляет групповой счет за терминированный трафик поставщику услуг, т.е. произодится взаиморасчет. Что касается расчетов со «своими» абонентами (пользователями услуги), то для этого местному оператору предпочтительно использовать предоплатные механизмы, т.е. систему сервисных телефонных карт, предоставляя доступ к услугам только по собственным картам оператора. Такой вариант требует от оператора минимальных вложений (особенно, если он уже предоставляет услуги обычной телефонной связи с использованием системы обработки телефонных карт с Протей-ТК) и, по мнению авторов является на сегодня оптимальным.

Если же в существующей сети IP-телефонии выставление счетов производится централизованно, то проблема взаимодействия решается следующим образом.

Если сеть построена на базе оборудования VocalTec или, по крайней мере, с наличием привратника, произведенного фирмой VocalTec, который, как правило, занимается начислением платы за разговоры абонентов, то шлюз Протей-ITG общается с привратником по протоколу RAS, входящему в семейство протоколов Н.323.

Если сеть построена на базе оборудования Cisco, то шлюз взаимодействует с биллинговым центром сети по протоколу RADIUS.

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

11.5   Экономические аспекты применения оборудования IP-телефонии

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

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

Указанная в таблице комплектация оборудования может изменяться в зависимости от того, какое оборудование уже имеется уместного оператора. В полный комплект оборудования, кроме шлюза, входят также привратник, биллинговая система, коммутатор Ethernet и маршрутизатор.

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

А если приведенные в таблице 11.2 суммы не показались достаточной компенсацией потраченного на чтение данной книги времени, то в следующем параграфе излагается техническая идея, экономическая эффективность которой эквивалентна разве что известной карте боцмана Билли Бонса из стивенсоновского «Острова сокровищ».

11.6   Виртуальная телефонная линия

Сколько раз мы пытались безуспешно дозвониться до абонента, работающего в сети Интернет? Неудобство, бесполезно потраченное время, моральные издержки, возможные убытки и отсутствие возможности сообщить вовремя срочную информацию - далеко неполный перечень неприятностей при использовании телефонной связи, связанных с многочасовым доступом к Интернет. Известные пути решения этой проблемы при помощи линий ADSL, базового доступа ISDN типа 2B+D, установкой второго телефонного номера имеют весьма ограниченное применение в нашей российской действительности.

В основу излагаемого здесь решения положено использование технологии IP-телефонии. Программно-аппаратный комплекс, в состав которого входят шлюз Протей-ITG и привратник Протей-GK, позволяет Оператору связи предоставить абонентам новую услугу: работать в сети Интернет и разговаривать по телефону одновременно, занимая всего лишь одну обычную аналоговую линию. Н иже представлено описание механизма организации виртуальной телефонной линии.

Перед началом работы в сети Интернет абонент активизирует на своей телефонной станции дополнительную услугу «Переадресация при занятости абонента». Предусмотрены два способа активизации услуги: самим абонентом при помощи сигналов DTMF или персоналом АТС при помощи средств эксплуатационного управления.

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

Абонент запускает любое клиентское приложение IP -телефонии, например, популярное программное обеспечение NetMeeting. При запуске клиентского приложения автоматически, по протоколу Н.323, инициируется процедура регистрации абонента у привратника сети Протей-GK, в ходе которой указывается телефонный номер и IP-адрес абонента. Кроме того, вводится PIN-код для идентификации абонента. Получив от абонента запрос регистрации - Registration Request, привратник обращается к базе данных для проверки прав абонента на пользование данной услугой. Если абонент подписан на эту услугу, то привратник подтверждает регистрацию сообщением Registration Confirm, после чего абонент может быть доступен во время работы в сети Интернет.

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

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

На рис. 11.3 представлен алгоритм вызова пользователя, работающего в сети Интернет.

Вызывающий абонент набирает номер вызываемого абонента (1), и, если этот номер занят (вызываемый пользователь работает в Интернете), вызов переадресуется телефонной станцией к шлюзу Протей-ITG (2). Для того, чтобы вызов мог быть автоматически переадресован к шлюзу, на станции для шлюза должно быть выделено отдельное внутристанционное направление (не включенное в городской план нумерации, чтобы не расходовать номерную емкость). Кроме того, каждому абоненту, подписавшемуся на услугу «Виртуальная телефонная линия», должен быть присвоен внутристанционный (внутрисетевой) номер, на который переадресуется вызов при работе абонента в сети Интернет.

Шлюз, в свою очередь, передает привратнику запрос допуска к использованию сетевых ресурсов Admission Request по протоколу Н.323 (3). В запросе указывается телефонный номер вызываемого абонента. Привратник дает шлюзу разрешение использовать сетевые ресурсы (Admission Confirm), в котором указывается IP-адрес вызываемого абонента (4). Далее шлюз маршрутизирует вызов к вызываемому абоненту через 1Р-сеть(5). У вызываемого абонента на экране появляется сообщение о входящем вызове с указанием телефонного номера вызывающего абонента и акустическое извещение. Он может либо принять этот входящий вызов, либо отказаться от приема.

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

Если автоматически реализовать услугу «Виртуальная телефонная линия» не представляется возможным по техническим причинам, например, в сети не поддерживается дополнительная услуга «Переадресация при занятости абонента», то ее можно реализовать при помощи системы обработки телефонных карт (СТК) Протей-ТК. Алгоритм такой реализации услуги представлен на рис.11.4. В этом случае услуга может предоставляться любым абонентам ТфОП, но для обеспечения хорошего качества речи, опять-таки, следует задействовать механизмы предоставления гарантированного качества обслуживания.

Рис. 11.4  Вызов абонента, работающего в сети Интернет, через СТК

Вызываемый абонент (абонент, подписавшийся на услугу) выполняет действия, аналогичные предыдущему алгоритму.

Вызывающий абонент соединяется с СТК (1). Отметим, что на станции для услуги СТК выделяется серийный номер. Далее абоненту передается приглашение к набору номера. После того, как абонент введет при помощи сигналов DTMF номер вызываемого абонента, СТК устанавливает через АТС соединение со шлюзом Протей-ITG (2), который подключается к станции таким же образом, как и в предыдущем случае. Дальнейший алгоритм установления соединения идентичен алгоритму, описанному выше.

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

11.7   Центр обработки вызовов

В центре обработки вызовов (Call-center) будут интегрированы как операторские, так и автоматизированные информационные службы, что позволит реализовать в одном комплексе максимально широкий спектр взаимосвязанных услуг. Центр реализован на базе технологии IP-телефонии с поддержкой протокола Н.323.

Для организации информационно-справочных служб в центре обработки вызовов предусмотрены ступень распределения вызовов (СРВ) и интерактивная речевая система (IVR).

Для офисного рынка в центре реализованы функции учрежденческой телефонной станции, так называемой IP-PBX. Благодаря этому отпадает необходимость разворачивать в офисе две сетевые инфраструктуры: телефонную и компьютерную. IP-PBX не только сохранит функциональные возможности традиционныхУАТС (предоставление базовых соединений и стандартных дополнительных услуг), но и предложит сотрудникам офиса новые возможности, например, пользование телефонными услугами своей корпоративной УАТС независимо от того, где они находятся, например, при работе дома.

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

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

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

11.8   Модуль IPU как средство интеграции цифровых АТС с IP-сетями

Все чаще телефонные сети общего пользования (ТфОП) используются для организации доступа к глобальной сети Internet. Операторы телефонной связи, как правило, не получают от этого существенного дохода, в то время как поставщики услуг сети Интернет получают значительную прибыль. Кроме того; коммутационное оборудование ТфОП проектировалось из расчета интенсивности нагрузки 0.1 - 0.15 Эрланга в час наибольшей нагрузки (ЧНН) на одну абонентскую линию, и именно при таких параметрах обеспечивалось удовлетворительное качество обслуживания телефонных вызовов. Анализ нагрузки с учетом модемных соединений между абонентами ТфОП и поставщиками услуг сети Интернет показывает, что в некоторых случаях интенсивность нагрузки на одну абонентскую линию может достигать 0,8 Эрланга в ЧНН. При этом занимаются не только абонентские, но и межстанционные соединительные линии, что приводит к ощутимым перегрузкам в ТфОП.

Предлагаются различные решения проблемы отвода трафика сети Интернет от соединительных линий ТфОП. Одним из наиболее действенных решений является организация в коммутационном оборудовании точки присутствия Интернет - Internet Point of Presence (IPoP). При этом не только отводится трафик Интернет, но  и операторы телефонной связи сами становятся поставщиками услуг глобальной сети Интернет, что позволяет существенно повысить их доходы.

На рис.11.5 представлен входящий в комплекс оборудования АТСЦ-90 модуль IPU (Internet Point of Presence Unit), позволяющий организовать интеграцию коммутационного оборудования АТС в сети с маршрутизацией пакетов IP. Модуль IPU является интегрированным сервером доступа: в качестве шлюза IP-телефонии он обеспечивает передачу речевого трафика и факсимильных сообщений по сетям с маршрутизацией пакетов IP, а в качестве сервера удаленного доступа к IP-сетям предоставляет абонентам ТфОП доступ к Интернет или к удаленным ЛВС по коммутируемым линиям.

Модуль IPU подключается к АТС по цифровым трактам Е1 с использованием систем сигнализации ОКС7 (ISUP) или E-DSS1, а к сетям с маршрутизацией пакетов IP - при помощи интерфейса 10/100 BaseT. Сервер автоматически (по набранному номеру) распознает, какое из приложений должно быть использовано для обслуживания поступившего вызова.

11.9   Тестирование протоколов IP-телефонии

Для тестирования семейства протоколов сигнализации Н.323, рассмотренных в главах 5 и 6, а также протоколов стека TCP/IP, в том числе, протоколов прикладного уровня RTP/RTCP, рассмотренных в главе 4, используется протокол-тестер SNT, представленный на рис.11.6.

Рис. 11.6  Протокол-тестер SNT

Протокол-тестер SNT-7531, наряду с тестированием протоколов ОКС7, V5, DSS1, проверяет протокол Н.323 (как и другие рассмотренные в книге протоколы IP-телефонии) на соответствие международным рекомендациям и российским национальным требованиям. Протокол-тестер может использоваться операторами связи для проведения пуско-наладочных работ и сопряжения оборудования разных фирм-производителей, разработчиками оборудования для отладки своего оборудования, сертификационными и испытательными центрами - для проведения испытаний по «Типовой программе и методике».

Определены два основных режима функционирования тестера: мониторинг и симуляция.

Мониторинг предусматривает пассивное чтение данных в сигнальных каналах. При работе тестера SNT в режиме мониторинга передаваемые и принимаемые сигнальные сообщения выводятся на экран в порядке их передачи и приема. Различные фильтры и настройки монитора позволяют выводить на экран в удобном для пользователя формате только необходимые данные (например, только сигнализацию RAS и т.д.). Существует возможность сохранения данных в файле в ASCII формате.

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

•   обнаружение привратника и регистрацию в нем (сигнализация RAS);

•   установление сигнального соединения (сигнализация RAS иН.225.0/0.931);

•   определение ведущего и ведомого оборудования и обмен информацией о его функциональных возможностях (сигнализация Н.245);

•   открытие логических каналов (сигнализация Н.245);

•   передачу речевой информации {протокол RTP/RTCP);

•   завершение соединения.

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

•   отсутствие ответа от привратника;

•   отказ в регистрации.

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

В протокол-тестере реализованы следующие ошибочные ситуации, возникающие при установлении сигнального соединения:

•   запрет доступа привратником {из-за того, что не зарегистрирована вызываемая сторона, не зарегистрирован вызывающий терминал (шлюз), или отсутствует запрошенная полоса пропускания);

•   не получен ответ на сообщение Setup: отсутствие сообщений Call Proceeding/Alerting/Connect.

После успешного установления сигнального соединения терминалы (шлюзы) Н.323 открывают управляющий канал Н.245. На этом этапе выполняются две процедуры: определение ведущего и ведомого оборудования и обмен информацией о функциональных возможностях.

Во время выполнения любой из этих процедур могут возникнуть сбои в работе протокола Н.245, отработка которых предусмотрена в тестовых сценариях протокол-тестера:

•   сбой в определении ведущего и ведомого оборудования {из-за того, что совпали числовые значения в поле типа оборудования, или инициирующая сторона не принимает ответа от встречной стороны в течение назначенного промежутка времени);

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

После выполнения вышеуказанных процедур начинается процедура открытия логических каналов. В тестовые сценарии для проверки этого этапа включены следующие возможные случаи:

•   приемный шлюз запрещает открытие канала (из-за того, что вид информации неизвестен или не поддерживается, ширина полосы недостаточна, идентификатор сеанса связи недействителен и т.д.);

•   инициирующий шлюз своевременно не получает подтверждения и завершает соединение.

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

Завершая эту главу и всю книгу, хочется пожелать читателю, дочитавшему ее до конца, не пожалеть о потраченном времени. Ко всем приведенным в книге аргументам и длинному списку упомянутых в данной главе продуктов IP-телефонии можно добавить и знаменательное событие, произошедшее 1 июня 1999 года, когда Министерство связи (в ту пору - Госкомитет по связи и информатизации) официально признало IP-телефонию подлежащим лицензированию видом услуг связи, хотя и под псевдонимом «Телематическая служба речевой информации».

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

Глоссарий

ACELP           Algebraic Code-Excited Linear Prediction. Популярный алгоритм компрессии речевого сигнала (скорость передачи 8 Кбит/с)

ADPCM Adaptive Differential PCM. Адаптивная дифференциальная ИКМ

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

ARP Adress Resolution Protocol. Протокол, обеспечивающий динамическое

преобразование адресов Интернет в физические (аппаратные) адреса оборудования локальной сети

ARPA             Advanced Research Projects Agency. Специальное агентство при Министерстве обороны США (Department of Defense - DoD), создавшее сеть ARPANET

ASCII             American Standard Code for Information Interchange. Американский

стандартный код для обмена информацией

ASN.1 Abstract Syntax Notation One. Спецификация абстрактной синтаксической нотации, версия 1. Служит для описания информационных объектов прикладного уровня

BGP Border Gateway Protocol. Одноуровневый многопунктовый протокол

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

CBQ Class Based Oueuing. Организация очередей с учетом класса трафика. Каждый класс имеет свою очередь, и ему гарантируется некоторая доля пропускной способности канала. Если какой-то класс не использует весь отведенный ему ресурс, доля каждого из остальных классов пропорционально увеличивается.

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

CS-ACELP Conjugate Structure - Algebraic Code - Excited Linear Prediction. Технология CS-ASELP применяется в кодеках G.729, используемых для передачи речи по сетям Frame Relay. Обеспечивает скорость передачи 8 Кбит/с при длительности кадра 10 мс.

CSRC Contributing Source Identifier. Список полей с идентификаторами источников, речевая информация которых смешивается при создании RTP-пакета. Во время речевой конференции каждый RTP-пакет содержит свой SSRC.

DiffServ Differentiated Services. Система дифференцированного обслуживания трафика разных классов, разработанная комитетом IETF

DNS Domain Name System. Сервер имен доменов в Интернет, преобразующий эти имена в IP-адреса.

DSP Digital Signal Processor. Процессор цифровой обработки сигналов.

DTMF             Dual Tone Multi-Freqency. Многочастотная система кодирования цифр

номера. Имеется две группы частот, и цифра кодируется двумя частотами из разных групп.

DTX                Discontinuous Transmission. Прерываемая передача. Кодек прекращает передачу пакетов, когда детектор речевой активности обнаруживает паузу в речи.

DVMRP Distance Vector Multicast Routing Protocol. Один из основных протоколов, на базе которых реализуется многоадресная рассылка в IP-сетях.

Е1                   Цифровая система передачи со скоростью 2.048 Мбит/с, используемая в России и других европейских странах.

ЕСМА            European Computer Manufacturer's Association. Ассоциация европейских производителей компьютеров.

EIA Electronic Industries Association. Ассоциация электронной промышленности. Группа, разрабатывающая стандарты передачи данных. Разработчик ряда коммуникационных стандартов, в том числе, стандарты EIA/TIA-232 и EIA/TIA-449.

ETSI               European Telecommunication Standards Institute. Европейский институт стандартов в области связи.

FIFO First In, First Out. Дисциплина обслуживания, при которой первой обслуживается та заявка, которая первой поступила в очередь.

FTP                File Transfer Protocol. Протокол переноса файлов.

GCP               Gateway Control Protocol. Протокол управления шлюзом.

GK Gatekeeper. Привратник. Выполняет функции управления зоной сети

Н.323. GW Gateway. Шлюз. Аппаратно-программный комплекс, обеспечивающий обмен данными между сетями разных типов.

Н.323            Рекомендация ITU-T, которая определяет системы мультимедийной

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

ICMP             Internet Control Message Protocol Протокол управляющих сообщений

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

IDCP IP Device Control Protocol. Протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP. Предложен фирмой Level 3.

IEEE               Institute of Electrical and Electronics Engineers. Институт инженеров

электротехнической и электронной отраслей. Ведет исследования в области связи и разрабатывает коммуникационные и сетевые стандарты.

IETF               Internet Engineering Task Force. Группа инженерных проблем Интернет. Включает в себя более 80 самостоятельных подгрупп, отвечает за разработку стандартов для Интернет. Устанавливает приоритеты и вырабатывает решения по краткосрочным вопросам и проблемам, включая протоколы, архитектуру и эксплуатацию. Работает под эгидой ISO.

IP Internet Protocol. Протокол межсетевого взаимодействия.

IPOP              Internet Point of Presence. Точка присутствия поставщика услуг Интернет в коммутационном оборудовании.

ISO                 International Organization for Standardization. ISO - это не просто аббревиатура: греческое слово iso означает «равный». ISO Основана в 1946 г. и представляет собой международную организацию, объединяющую более 75 национальных бюро разных стран. Разработала важнейшие стандарты, в том числе и компьютерные.

ISP Internet Service Provider. Поставщик услуг Интернет. Компания, предоставляющая доступ в Интернет другим компаниям или частным лицам.

ITU-T             International Telecommunications Union Telecommunication Standardization Sector. Сектор Международного Союза Электросвязи, разрабатывающий рекомендации в области телекоммуникаций. Выполняет функции бывшего CCITT (МККТТ).

LDP Label Distribution Protocol. Протокол распределения меток. Поддерживает процедуры «раздачи» и согласования меток между маршрутизаторами сети MPLS.

LER Label Edge Router. Пограничный маршрутизатор сети MPLS.

LPC Linear Prediction Coding. Кодирование с линейным предсказанием.

LSP Label Switched Path, Коммутируемый по меткам тракт.

LSR Label Switching Router. Маршрутизатор коммутации по меткам.

MCU Multipoint Control Unit. Устройство управления конференцией. Обеспечивает согласование функциональных возможностей участников I конференции, то есть алгоритмов, используемых каждым из них для кодирования речи, видеоинформации и данных; может транскодировать информацию любого вида, если терминалы, участвующие в конференции, используют разные алгоритмы кодирования; в процессе согласования выбирает режим конференции. Производит смешивание или коммутацию информации, принимаемой от участников, и ее распределение.

MEGACO/    Протокол управления транспортным шлюзом. Создан рабочей

Н.248            группой MEGACO комитета IETF.

MG Media Gateway. Транспортный шлюз.

MGCP            Media Gateway Control Protocol. Протокол управления шлюзами.

MOS Mean Opinion Score. Характеристика качества передачи речи с применением кодека того или иного типа, получаемая как среднее значение результатов оценки качества большой группой экспертов по пятибалльной шкале.

МР       Multipoint processor. Процессор для обработки информации пользователей при централизованных конференциях.

MPLS             Multi-Protocol Label Switching. Многопротокольная коммутация по меткам. Основана на том, что пакеты, поступающие в пограничный маршрутизатор сети MPLS извне, разделяются на «классы эквивалентности пересылки». Каждому классу назначается система меток - коротких заголовков, используемых для маршрутизации пакетов внутри сети MPLS вместо длинных заголовков сетевого уровня.

Multicasting Многоадресная рассылка информации (аудио, видео или данных).

OPWA            One Path With Advertising. Вариант алгоритма, который поддерживается протоколом RSVP. С помощью OPWA информация управляющих пакетов RSVP может быть использована для предсказания «сквозного» QoS всего маршрута.

OSI Open System Interconnection. Взаимодействие открытых систем. Созданная ISO и ITU-T международная программа разработки стандартов сетевой передачи данных.

POTS             Plain Old Telephone Service. Услуги традиционной телефонии.

РРР Point-to-Point Protocol. Протокол двусторонней связи. Используется

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

PSTN             Public Switched Telephone Network. Телефонная сеть общего пользования (ТфОП). Общий термин, используемый для обозначения телефонных сетей во всем мире.

QCIF              Quarter-Common Intermediate Format. Обязательный формат изображений, который должны обеспечивать кодеки.

QoS Quality of Service. Качество обслуживания (услуги).

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

RADIUS Remote Authentication Dial-In User Service. Протокол аутентификации и авторизации абонентов, а также убета объема предоставленных им услуг.

RAS                Registration Admission and Status. Протокол взаимодействия терминального оборудования с привратником. Входит в семейство протоколов Н.323.

RSVP Resource Reservation Protocof. Протокол резервирования ресурсов.

RTCP             Real-time Transport Control Protocol. Протокол контроля транспортировки информации в реальном времени. Организует обратную связь получателя информации с ее отправителем, используемую для обмена сведениями о числе переданных и потерянных пакетов, о задержке, ее джиттере и т.д. Эти сведения отправитель может использовать для изменения параметров передачи с целью улучшить QoS (например, уменьшить коэффициент сжатия информации).

RTP                Real Time Transport Protocol. Протокол транспортировки в реальном

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

SGSP             Simple Gateway Control Protocol. Простой протокол управления шлю-

зами. Разработан компанией Telecordia (бывшая компания Bellcore).

SIP Session Initiation Protocol. Протокол инициирования сеансов связи.

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

SNMP            Simple Network Management Protocol. Простой протокол эксплуатационного управления сетью.

TAPI               Telephony Applications Programming Interface. Интерфейс для программирования телефонных приложений. Это - стандартный программный интерфейс для создания приложений компьютерной телефонии в среде windows, определяющий набор функций, которые необходимы программе для взаимодействия с телефонами, линиями и коммутаторами. Стандарт TAPI используется при разработке приложений для рабочих станций, выполняющих все интеллектуальные действия.

TCP Transmission Control Protocol. Протокол управления передачей (данных). Основной транспортный протокол в стеке протоколов TCP/IP. Устанавливает связь между двумя компьютерами и организует надежный обмен данными в дуплексном режиме.

TCP/IP          Transmission Control Protocol/Internet Protocol. Стек протоколов, обеспечивающих организацию связи между компьютерами в сети Интернет. Встроен в операционную систему UNIX и широко используется при операциях в сети Интернет, являясь de facto сетевым стандартом для передачи данных. Даже те сетевые операционные системы, которые имеют собственные протоколы, поддерживают также и TCP/IP.

TIPHON Telecommunications and Internet Protocol Harmonisation Over Networks. Проект под эгидой ЕТSI(начат в 1997 г), в котором участвует более 40 крупных компаний. Цель проекта - поддержка рынка, предусматривающего сочетание телекоммуникационных услуг сетей с коммутацией каналов и сетей с коммутацией пакетов.

TSAPI            Telephony Services Application Programming Interface. API для создания телефонных услуг. Разработан Novell и AT&T. Позволяет программистам конструировать телефонные и CTI-приложения. Аналогичен TAPI, но, в отличие от него, функционирует на платформах Netware. Другое отличие - TAPI используется как для клиентских, так и для серверных приложений, a TSAPI предназначен исключительно для сервера.

UAC User Agent Client. Агент пользователя - клиент. Прикладная программа, которая инициирует SIP-запрос.

UAS User Agent Server. Агент пользователя - сервер. Прикладная программа, которая принимает запрос и от имени пользователя возвращает ответ с информацией о том, что запрос принимается, не принимается или переадресуется.

UDP User Datagram Protocol. Протокол передачи дейтаграмм пользователя. Подобно TCP, использует для доставки данных протокол IP. В отличие от TCP/IP, предусматривает обмен дейтаграммами без подтверждения (то есть доставка не гарантируется).

VAD                Voice Activity Detector. Детектор речевой активности. Используется в

кодеках со сжатием речевой информации для определения момента окончания паузы в речи.

VoIP              Voice over Internet Protocol. Технология, позволяющая использовать

IP-сеть для передачи речевой информации.

WFQ Weighted Fair Queuing. Взвешенная справедливая очередь. Один из алгоритмов управления обслуживанием очередей.