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

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

Получили распространение следующие подходы решения данной проблемы:

а) Замена потерянного пакета предыдущим успешно принятым пакетом. Этот подход применим, когда количество потерянных пакетов невелико (до 5%).

б) Передача избыточной информации за счет дополнительного использования полосы пропускания. В этом случае вместе с n+1-м пакетом посылается и n-й пакет. Однако в случае использования этого подхода нерационально используется полоса пропускания и создается большая задержка.

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

Frame Relay, FR - протокол коммутации пакетов, используемый в глобальных сетях для высокоскоростной передачи кадров или пакетов с минимальными задержками в узле коммутации и для эффективного использования пропускной способности сети. Действует на канальном уровне модели OSI. Может применяться в ЛВС, в каналах с временным мультиплексированием, а также в сетях с коммутацией пакетов и каналов. При ретрансляции сеть направляет кадр в точку назначения в соответствии с содержащимся в нем адресом получателя. Вместо средств управления потоком включает функции извещения о перегрузках в сети, использует более длинные кадры. Главным фактором повышения скорости передачи является то, что анализ ошибок в данном случае не осуществляется и узлы ретрансляции не посылают уведомления или запросы на повтор ошибочно принятых кадров [1].

На рисунке 2.7 приведена схема подключения телефонного оборудования к сети Frame Relay.

Рисунок 2.7 - Схема организации телефонной связи по сети Frame Relay

При организации связи на основе сети Frame Relay (FR) основным руководящим документом является стандарт FRF.11. В нем четко сформулированы функции VFRAD, а также способы подключения к нему телефонного оборудования и место VFRAD в структуре сети. Для кодирования речи во FR желательно использовать вокодер ACELP, описанный в рекомендации ITU-T G.723.1 [10]. Выбор этого вокодера обусловлен самым выгодным соотношением «качество речи/скорость потока».

Для определенности предположим, что услугами телефонной связи пользуются абоненты двух узлов. Для этого выделен постоянный виртуальный канал, в рамках которого может быть организовано до 255 речевых трактов (подканалов). Теоретически, максимальная гарантированная скорость передачи по виртуальному каналу (CIR) не может превышать величины пропускной способности физического канала связи, соединяющего узлы сети [10].

Предположим, что в одном виртуальном канале функционируют три речевых тракта. Это означает, что FR-кадр, согласно стандарту FRF.11, будет иметь вид, представленный на рисунке 2.8.

Октеты	Биты
	8	7	6	5	4	3	2	1
1	Флаг
2	DLCI	CR	EA
3	DCLI	FECN	BECN	DE	EA
4	EI	LI	CID
5	Порядковый номер	Тип кодирования
6	Речевой кадр G.723.1 (5.3 кбит/с)
-
-
-
25
26	FCS
27
28	флаг

Рисунок 2.8 - Формат кадра Frame Relay для единственного речевого подканала

Из рисунка видно, что общий размер кадра FR составляет 28 байт. Из них 20 байт - полезная нагрузка. Исходя из того условия, что каждый речевой кадр должен быть передан со скоростью 5,3 кбит/с, скорость передачи кадра Frame Relay по каналу связи должна составить 7,4 кбит/с (20 байт, составляющих речевой кадр, должны быть переданы со скоростью 7,4 кбит/с для своевременной доставки речевого кадра). На рисунке 2.9 представлена схема распределения задержек, возникающих при передачи речи по сети Frame Re lay корпоративной сети передачи данных.

Рисунок 2.9 - Схема распределения задержек в сети передачи данных Frame Relay

Этот вывод показывает, что для организации трех речевых трактов потребуется 22,2 кбит/с пропускной способности канала (7,4 кбит/с*3=22,2 кбит/с), и это означает, что невозможно организовать три речевых тракта в канале 19,2 кбит/с. Возможна организация лишь двух речевых трактов. В случае организации двух речевых трактов, необходимо 14,8 кбит/с пропускной способности канала связи.

Таким образом, для удобства рассмотрения введем такое условие, что в сети организован один виртуальный канал содержащий единственный речевой тракт. В этом случае размер кадра будет составлять 28 байт и, следовательно, должен быть передан со скоростью 7,4 кбит/с.

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

Т=(t_накопл + t_обраб + t_посл) +…+ (t_распр + t_посл) +…+ (t_распр + t_посл + t_обраб), (2.1)

где t_накопл - задержка накопления (t_накопл=30 мс);

t_обраб - задержка обработки (t_обраб=30 мс);

t_посл - последовательная задержка (t_посл=30 мс);

t_распр - задержка распространения (t_распр=30 мс).

Последовательная задержка рассчитывается из того минимально допустимого условия, что кадры Frame Relay от узла к узлу будут передаваться с постоянной скоростью 7,4 кбит/с. Задержка распространения сигнала, рассчитывалась из того условия, что передача осуществляется по коаксиальному кабелю, и в соответствии с рекомендацией ITU G.I 14 рассчитывается из соотношения:

задержка распространения, мс = 0,004 * протяженность канала связи, км.

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

- задержка при обработке сигнала кодеком (величина постоянная, t обраб);

- задержка в выходной и входной очередях (величина переменная, зависит от загрузки маршрутизатора, канала и способа приоритезации, t накопл );

- задержка в сглаживающем буфере коммутатора (величина переменная, tпосл. Комм );

- задержка в маршрутизаторе (величина постоянная при данных скорости канала и размере пакета, tмарш. );

- задержка трафика при распространении по ЛВС и по кспд (величины переменные, t ЛВС и t распр , соответственно).

Учитывая количество транзитных узлов, при передаче речевого сигнала от абонента к абоненту, можно с достаточной точностью определить величину совокупной задержки передачи речевого сигнала по сети передачи данных IP КСПД, в соответствии со следующим соотношением:

T =( tнакопл + tобраб +tЛВС + tпосл. Комм)+ … (2.2)

+(tраспр. +tпосл. Комм. +tмаршр.) +…+

задержка вносимая

транзитным узлом

+…+ (tнакопл. + tобраб. + tЛВС + tпосл.комм.)

На рисунке 2.10 представлена схема распространения задержек при передаче речи по сети IP.

Рисунок 2.10 - Схема распределения задержек в сети IP

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

Положение шлюзов в сети показано на рисунке 2.11, а обработка сигнала - на рисунке 2.12.

Рисунок 2.11 - Положение шлюза в сети с коммутацией пакетов

Рисунок 2.12 - Схема обработки сигналов в шлюзе

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

Телефонный сигнал с двухпроводной абонентской линии поступает на дифференциальную систему, которая разделяет приемную и передающую части канала. Далее сигнал передачи вместе с «просочившейся» частью сигнала приема подается на аналогово-цифровой преобразователь (ADC) и превращается либо в стандартный двенадцати разрядный сигнал, либо в восьмиразрядный сигнал, закодированный по м- или А-закону. В последнем случае обработка должна также включать соответствующий экспандер. В устройстве эхокомпенсации (Echo canceller) из сигнала передачи удаляются остатки принимаемого сигнала. Эхокомпенсатор представляет собой адаптивный нерекурсивный фильтр, длина памяти (порядок) которого и механизм адаптации выбираются таким образом, чтобы удовлетворить требованиям МСЭ-Т G.165. Для обнаружения и определения сигналов внутриполосной многочастотной телефонной сигнализации (MF сигналов), сигналов частотного (DTMF) или импульсного наборов используются детекторы соответствующих типов. Дальнейшая обработка входного сигнала происходит в речевом кодере (Speech Coder). В анализаторе кодера сигнал сегментируется на отдельные фрагменты определенной длительности (в зависимости от метода кодировании) и каждому входному блоку присваивается информационный кадр соответствующей длины.

Часть параметров, вычисленная в анализаторе кодера, используется в блоке определения голосовой активности (VAD - Voice Activity Detector), который решает, является ли текущий анализируемый фрагмент сигнала речью или паузой. При наличии паузы информационный кадр может не передаваться в службу виртуального канала. На сеансовый уровень передается лишь каждый пятый «паузный» информационный кадр. Кроме того, при отсутствии речи для кодировки текущих спектральных параметров используется более короткий информационный кадр. На приемной стороне из виртуального канала в логический поступает либо информационный кадр, либо флаг наличия паузы. На паузных кадрах вместо речевого синтезатора включается генератор комфортного шума (Noise Generator), который восстанавливает спектральный состав паузного сигнала. Параметры генератора обновляются при получении паузного информационного кадра. Наличие информационного кадра включает речевой декодер, на выходе которого формируется речевой сигнал. Для эхокомпенсатора этот сигнал является сигналом дальнего абонента, фильтрация которого дает составляющую электрического эха в передаваемом сигнале. В зависимости от типа цифро-аналогового преобразования (DAC) сигнал может быть подвергнут дополнительной кодировке по А- или м-закону.

2.6 Стандартизация в сетях с коммутацией пакетов

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

- Сектор стандартизации телекоммуникаций Международного союза электросвязи МСЭ-Т (International Telecommunications Union - Telecommunications, ITU-T);

- Европейский институт стандартизации по телекоммуникациям (European Telecommunications Standard Institute, ETSI);

- Рабочая группа по инженерным проблемам Интернет (Internet Engineering Task Force - IETF);

- Американский национальный институт стандартов (American National Standards Institute, ANSI);

- Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE);

Стандарты являются критическим фактором для мира IP-телефонии. В 1996г. МСЭ-Т (ITU) разработал рекомендацию Н.323. Этот стандарт формулирует технические требования для передачи данных, видео и голосового трафика. Н.323 включает в себя:

- стандарты на видео кодер/декодер;

- стандарты на голосовые кодер/декодеры;

- стандарты на общедоступные приложения;

- стандарты на управление вызовами;

- стандарты на управление системой;

Технические требования к голосовым кодерам:

- малая полоса пропускания (8 kbit/s или меньше);

- высокое качество голоса;

- небольшие задержки;

- возможность реконструкции потерянных пакетов.

Согласно стандарту Н.323, сетевое оборудование обязано кодировать аудиосигнал в соответствии с G.711. такое преобразование, известное также как импульсно-кодовая модуляция (ИКМ), широко применяется в цифровой телефонии. Однако оно требует 64 кбит/с дуплексного телефонного канала для каждого речевого соединения. Следовательно, в сетях с коммутацией пакетов, например сетях IP, два одновременно говорящих абонента займут полосу 128 кбит/с [4].

Стандартом Н.323 определен список более эффективных кодеков, которые также могут быть использованы. Два самых популярных из них - это G.723.1 с выходной скоростью 6,4 кбит/с и G.729 с выходной скоростью 8 кбит/с. Проблема заключается в том, что одни продукты IP-телефонии первого поколения поддерживают G.723.1, а другие - G.729. Поэтому, чтобы обеспечить взаимодействие продуктов разных производителей, вы все равно должны будете использовать G.711. В противном случае придется работать с оборудованием только одной фирмы.

В рекомендацию Н.323 входит также утвержденный МСЭ-Т в ноябре 1996г. стандарт на сжатие голоса G. 729.

Во входящей в семейство Н.323 рекомендации Н.225 описаны механизмы сигнализации, необходимые для регистрации, контроля доступа и управления вызовами (на основе протокола Q.931) и непосредственной передачи трафика. В рекомендации Н.245 определены типы сигнальных сообщений конечных точек и процедуры согласования параметров между ними. Служебная информация Н.245 передается по логическому каналу, установленному в соответствии с Н.225.

Для полной совместимости с Н.323, терминальное устройство Интернет-телефонии должно поддерживать по крайней мере один стандартный аудиокодек (G.711) и факультативно несколько других (G.723, G.729), а также протокол реального времени RTP (Real Time Protocol) для передачи аудио - он обеспечивает стандарт на упорядочивание и обработку пакетов в случае ненадежных соединений. Голосовые терминалы Н.323 должны быть совместимы со стандартом Н.245 для обмена и согласования параметров, со стандартом на подачу вызова Q.931, а также с протоколами для взаимодействия с “привратниками”. Н.245 является чрезвычайно сложным стандартом, поскольку, помимо всего прочего, он рассматривает видеоконференции и конференции документов; урезанная версия Н.245 Profile - для голосовых терминалов.

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

Таблица 2.13 - Основные компоненты стандарта Н.323

Продолжение таблицы 2.13

Таблица 2.9 - Продолжение

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

Стандарт Н.323 входит в семейство рекомендаций Н.32Х, описывающих порядок организации мультимедиа-связи в сетях различных типов:

- Н.320 - узкополосные цифровые коммутируемые сети, включая ISDN;

- Н.321 - широкополосные сети ISDN и АТМ;

- Н.322 - пакетные сети с гарантированной полосой пропускания;

- Н.324 - телефонные сети общего пользования (ТФОП).

Данная задача реализуется с помощью шлюзов, осуществляющих трансляцию сигнализации и форматов данных. Стандарт Н.323 позволяет создать падежные решения для организации коммуникаций по надежным сетям с переменной задержкой. При условии соответствия стандарту устройства с различными возможностями могут и взаимодействовать друг с другом. Например, терминалы с видеосредствами могут участвовать в аудиоконференции. В совокупности с другими стандартами МСЭ-Т на мультимедийную связь и телеконференции рекомендации Н.323 применимы для любых видов соединений - от многоточечных до соединений “точка-точка”.Стандарт Н.323 определяет также порядок взаимодействия с оконечными устройствами других стандартов. Наиболее часто такая задача возникает при сопряжении телефонных сетей с коммутацией пакетов и коммутацией каналов.

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

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

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

В системах IP-телефонии процедуры управления вызовами управляются протоколами сигнализации, а непрерывная маршрутизация трафика через IP-сеть обеспечивается протоколами: OSPF или BGP (резервирование сетевых ресурсов возможно, например, при помощи протокола RSVP). Таким образом, архитектура сети IP-телефонии предусматривает разделение плоскостей управления и передачи пользовательской информации, что является наиболее благоприятным условием для внедрения новых услуг [1, 7].

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

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

В общем случае для установления соединения между вызываемым и вызывающим абонентом шлюзы IP-телефонии должны:

- найти gatekeeper, на котором возможна регистрация оконечного устройства;

- зарегистрировать свой мнемонический адрес на gatekeeper;

- указать требуемую полосу пропускания;

- передать запрос на установление соединения;

- установить соединение;

- в процессе вызова управлять параметрами соединения;

- разъединить соединение;

Для выполнения этих операций в настоящее время могут использоваться различные протоколы сигнализации.

Построение сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543 , основан на использовании протокола SIP-Session Initiation Protocol. SIP представляет собой текст ориентированный протокол, который является частью глобальной архитектуры мультимедиа.

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

SIP (Session Initiation Protocol) - это протокол прикладного уровня, разработанный рабочей группой по управлению многоточечными сеансами мультимедиа-связи (MMUSIC) организации IETF. Он позволяет организовать и провести такой сеанс, обеспечивая его установление, модификацию и завершение.

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

Возможный сценарий установления и завершения сеанса связи по протоколу SIP (в процессе установления соединения используется сервер DNS) приведен на рисунке 2.14

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

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

- уведомление о сеансе с использованием разных средств - электронной почты, новостных групп, Web-страниц или специального протокола SAP (Sessiol Announcement Protocol).

- приглашение к участию в сеансе с помощью протокола SIP.

Оба упомянутых протокола (SAP и SIP) используют механизм SDP (Session Description Protocol) для описания таких характеристик сеанса, как время проведения, требуемые ресурсы и т.д. [1, 4].

SIP работает по схеме клиент - сервер: клиент запрашивает определенный тип сервиса, а сервер обрабатывает его запрос и обеспечивает предоставление сервиса. Согласно протоколу SIP, пользовательская система может не только формировать, но и принимать запросы. Это означает, что она должна быть оснащена и клиентской (клиент агента пользователя - UAC) и серверной (сервер агента пользователя - UAS) частями.

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

В протоколе SIP определены два типа сигнальных сообщений - запрос и ответ. Они имеют текстовый формат (кодировка символов согласно RFC2279) и базируются на протоколе НТТР (Hyper Text Transfer Protocol) (синтаксис и семантика определены в RFC 2068). В запросе указываются процедуры, вызываемые для выполнения требуемых операций, а в ответе - результаты их выполнения. Определены шесть процедур:

INVITE - приглашает пользователя принять участие в сеансе связи (служит для установления нового соединения; может содержать параметры для согласования);

BYE - завершает соединение между двумя пользователями;

OPTIONS - используется для передачи информации о поддерживаемых характеристиках (эта передача может осуществляться напрямую между двумя агентами пользователей или через сервер SIP);

АСК - используется для подтверждения получения сообщения или для положительного ответа на команду INVITE;

CANCEL - прекращает поиск пользователя;

REGISTER - передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на сервер адресов (Location Server).

Сообщения-ответы могут содержать шесть типов возможных результатов: запрос в процессе выполнения (1xx), успешный запрос (2xx), переадресация (3хх), неправильный запрос (4хх), отказ сервера (5хх), глобальный отказ (6хх).

Используемая в SIP адресация основана на унифицированном указателе ресурсов SIP URL, в котором может быть записано имя домена (use@XZdomain) или IP-адрес (use@IP address) пользователя. Цель использования подобного формата - интеграция SIP-услуг с существующими службами Интернет. Сервер имен доменов (DNS) преобразует доменные имена в IP-адреса конечной точки. Вся маршрутизация и передача мультимедийных потоков выполняются нижележащей IP-сетью.

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

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

О протоколе SAP часто упоминают в сочетании с SIP, главным образом потому, что оба протокола используются для оповещения о сеансах конференц-связи. Клиент SAP информирует о сеансе, периодически посылая пакет-уведомление UDP на определенный групповой адрес и протокольный порт. Уведомление передается только тем узлам, которые являются потенциальными участниками сеанса, т.е. удовлетворяют требования в отношении полосы пропускания и других параметров. Эти особенности делают SAP менее пригодным для использования в качестве протокола установления телефонных соединений. Сфера его применения - уведомление о стандартных сеансах многоадресного вещания.

2.7 Протокол SDP (RFC2327)

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

- имя и назначение сеанса;

- период(ы) времени, в течение которого(ых) сеанс активен;

- среда передачи данных сеанса: тип мультимедиа (видео, аудио и т.д.); его формат (Н.261, MPEG и т.д.), используемый транспортный протокол (RTP/UDP/IF, Н.320 и т.д.) и номер порта;

- информация для приема потока (адреса, порты, форматы и т.д.);

- данные о необходимой полосе пропускания;

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

Как уже говорилось, протоколы SAP и SIP не имеют средств для передачи подобной информации. Для этого и служит протокол SDP (в принципе возможно применение и других механизмов). Его информация передается в составе некоторых сообщений SAP и SIP, например сообщений INVITE, ACK, и OPTIONS протокола SIP.

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

В документе RFC 2543 описана схема применения SDP для установления двунаправленного сеанса связи между двумя его участниками. В общих чертах она такова: вызывающий пользователь передает вызываемому в составе сообщения INVITE характеристики инициируемого мультимедиа-сеанса, а тот в ответном сообщении АСК указывает те из них, которые может поддержать. Для подтверждения возможности приема конкретного формата мультимедийной информации надо указать отличный от нуля номер протокольного порта. Единственный способ отказаться от приема этого формата - указать для него нулевой номер порта.

2.8 Сравнение Н.323 и SIP

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

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

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

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

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

Многие специалисты считают протокол SIP более масштабируемым, чем Н.323. это связано, в частности, с тем, что сервер SIP не сохраняет сведения о текущих сеансах связи (stateless). Следовательно, он способен обработать больше вызовов, чем контроллер зоны (привратник) Н.323, сохраняющий такие сведения (state-full).

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

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

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

3 МАТЕМАТИЧЕСКАЯ МОДЕЛЬ ДИАЛОГА ПАКЕТНОГО ПРЕДСТАВЛЕНИЯ РЕЧИ

3.1 Назначение приоритетов

Большинство известных достаточно подробных моделей позволяют получить распределение длительностей каждого из этих событий с необходимой точностью. Менее сложные модели описывают распределения только некоторых состояний, например, таких, как длительность активного состояния речевого сигнала или длительность пауз. Однако именно эти состояния являются наиболее важными при анализе моделей трафика и сетевых статистических характеристик. Упрощенные модели позволяют получить аналитические выражения, удобные для анализа основных характеристик сети, и могут быть использованы для анализа сетей со статистическим уплотнением [1].

При явной приоритезации данных соответствующее приложение запрашивает определенный уровень службы, а коммутатор или маршрутизатор пытается удовлетворить запрос. Вероятно, самым популярным механизмом явной приоритезации станет протокол IP Precedence (протокол старшинства), получивший второе название IP TOS (IP Type Of Service). IP TOS резервирует ранее не используемое поле TOS в стандартном заголовке пакета IP, где могут быть указаны признаки QoS, определяющие время задержки, скорость передачи и уровень надежности передачи пакета.

Три первых бита этого поля (0 - 2) позволяют устанавливать восемь уровней приоритета (IP Precedence):

111 - управлению сетью (Network Control);

110 - межсетевое управление (Internetwork Control);

101 - CRITIC/ECP;

100 - сверхурочный (Flash Override);

011 - срочный (Flash);

010 - неотложный (Immediate);

001 - приоритетный (Priority);

000 - обычный (Routine);

в документе RFC 791 биты 3, 4 и 5 были выделены для указания трех классов обслуживания:

бит 3: задержка 0 - нормальная, 1 - низкая;

бит 4: пропускная способность 0 - нормальная, 1 - высокая;

бит 5: надежность 0 - обычная, 1 - высокая.

Биты 6 и 7 были зарезервированы для будущего использования.

Однако после принятия документа RFC 1349 ранее разобщенные биты 3, 4, 5 и 6 стали рассматриваться как единое целое и называться полем toss. Они служат для указания следующих классов обслуживания:

1000 - с низкой задержкой;

0100 - с высокой пропускной способностью;

0010 - с высокой надежностью;

0001 - с низкой стоимостью;

0000 - стандартный (normal).

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

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

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

3.1.1 Организация и обслуживание очередей

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

Наиболее известными алгоритмами обработки очередей являются алгоритмы: FIFO (First In First Out) «первым пришел - первым обслужен», PQ (Priority Queuing) - с абсолютным приоритетом, CQ (Custom Queuing) - настраиваемый, WFQ (Weighted Fair Queuing) - равномерного пропорционального (или взвешенного) обслуживания. Каждый из этих механизмов был создан для решения конкретных задач и по разному воздействует на потоки данных и производительность сети.

Механизм FIFO, по сути, не предполагает никакого управления трафиком и предназначен для обслуживания одной очереди. Но он работает очень быстро и при отсутствии перегрузок его использование на скоростных интерфейсах (более 2 Мбит/с) вполне оправданно.

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

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

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

Алгоритм WFQ работает с учетом двух основных механизмов QoS - IP Precedence и RSVP. На этапе классификации трафика, в ходе которой могут учитываться разные характеристики потока, например номера протокольных портов TCP, каждому потоку назначается вес, определяющий порядок его отправки. Протокол RSVP использует WFQ для того, чтобы выделить буферное пространство и гарантировать в будущем полосу пропускания для обслуживаемых им (RSVP) потоков. Механизм WFQ минимизирует необходимость настройки, автоматически адаптируясь к изменению состояния сети и уровня загрузки интерфейса. Он позволяет эффективно использовать полосу пропускания канала, передавая трафик из очередей с малым приоритетом, если высокоприоритетные очереди пусты.

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

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

3.1.2 Управление нагрузкой

Служба QoS дает возможность использовать для управления сетью два важных механизма - управление в условиях нагрузки и предотвращения перегрузок. Первый из них позволяет конечной станции сразу снизить скорость передачи данных, когда в сети начинается потеря пакетов. В протоколах TCP/IP и SNA этот механизм поддерживается уже в течение нескольких лет. И хотя сам по себе он не гарантирует качества передачи, при его использовании совместно с механизмом предотвращения перегрузок результаты оказываются намного лучшими. В сетях TCP/IP механизм предотвращения перегрузок применяется достаточно давно, но лишь в последние годы он становится стандартом «де-факто» для маршрутизаторов телекоммуникационных сетей и Internet.

Стандартным способом предотвращения перегрузок в сети стало применение механизма случайного выделения пакетов (Random Early Detection, RED). При заполнении очередей выше определенной критической отметки этот механизм заставляет маршрутизатор выбирать из очереди по случайному закону некоторые пакеты и «терять» их. Скорость передачи данных станциями-отправителями снижается, что и позволяет избежать переполнения очереди. Механизм пропорционального случайного выделения пакетов - WRED (Weighted RED) можно считать следующей, более совершенной «версией» RED. Он базируется на алгоритме RED и учитывает значения битов IP Precedence. Учет механизмов WRED значений битов IP Precedence позволяет «оберегать» пакеты с более высоким приоритетом и обеспечивать разные уровни производительности для потоков с разным классом сервиса.

Последние усовершенствования, внесенные в алгоритм WRED (Flow-WRED), позволяет учитывать значимость каждого потока так же, как это делается в механизме WFQ. Как только поток превышает предустановленный лимит буферного пространства выходного интерфейса, вероятность сброса его пакетов повышается. Благодаря этому предотвращается захват полосы пропускания канала теми потоками, которые не способны реагировать на перегрузки.

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

Формирование трафика - это общий термин, которым принято обозначать различные способы манипулирования данными для повышен6ия качества их передачи. Один из таких способов - сегментация пакетов. В сетях АТМ гарантированно высокий уровень QoS достигается в том числе и за счет малого размера передаваемых пакетов (ячеек - в терминологии АТМ). Максимальное время задержки при передаче любого пакета сети АТМ - это время передачи одной ячейки.

Заимствуя полезные механизмы технологии АТМ, производители маршрутизаторов и коммутаторов начинают обеспечивать в своих продуктах возможность сегментации пакетов. Например, маршрутизаторы Cisco серии 12000 имеют встроенный механизм сегментации пакетов на ячейки размером 64 байта, что позволяет гарантировать качество передачи данных маршрутизатором. Некоторые устройства, предназначенные для сетей Frame Relay, сегментируют пакеты, передаваемые по каналам глобальных сетей, чтобы гарантировать конкретное время передачи и минимизировать задержки.

Еще одним способом повышения качества передачи данных является сжатие заголовков RTF-пакетов (Compressed Real-Time Protocol - CRTP). Использование протокола CRTP позволяет уменьшить размер заголовка RTP-пакета с 40 до 2 - 4 байт, что, в свою очередь, примерно в два раза уменьшает полосу пропускания, необходимую для передачи речевого потока, обработанного, например, кодеком G.729. Алгоритм сжатия заголовков для комбинации IP/UDP/RTP реализован аналогично алгоритму сжатия заголовка TCP (RFC 1144) и описан в документе RFC 2508.

3.1.4 Объединение всех средств реализации QoS

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

Однако в настоящее время уже разрабатываются так называемые policy-based management systems, т.е. системы управления сетью по заданным правилам. В их функции входит объединение всех средств и формирование алгоритмов управления, обеспечивающих QoS на всех участках сети.