Published in author’s version

Е.С. Чердынцев

МУЛЬТИМЕДИЙНЫЕ СЕТИ

Учебное пособие

Издательство ТПУ

УДК 681.327.1 (0.75.8)

ББК 32.973.202 Я73

Ч 459

Чердынцев Е.С.

Ч 459 Мультимедийные сети: Учебное пособие. – Томск: Изд-во Томского политехнического университета, 2011. – 95 с.

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

УДК 681.327.1 (0.75.8)

ББК 32.973.202 Я73

Рекомендовано к печати Редакционно-издательским советом Томского политехнического университета

Рецензенты

Доктор технических наук, профессор ТУСУРа

Ю.П. Ехлаков

Кандидат технических наук, доцент кафедры КСУП ТУСУРа

Н.Ю. Хабибулина

© Томский политехнический университет, 2011

© Оформление. Издательство ТПУ, 2011

Глава 1. Введение в мультимедиа

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

1.1. Классификация мультимедиа

С точки зрения передачи мультимедиа она может быть классифицирована на передаваемую в реальном времени (Real-Time – RT) или не в реальном времени (Non Real-Time – NRT). Мультимедиа первого типа (RT) требует ограничений на задержку пакетов, в то время как мультимедиа второго типа (например, текст и изображение) таких ограничений не требует, но может иметь жесткие ограничения на наличие ошибок при передаче. Существует два основных подхода к контролю ошибок при передаче мультимедийной информации [1]. Первый основан на автоматическом повторе передачи потерянных или поврежденных пакетов (Automatic Retransmission reQuest – ARQ). Этот подход используется в протоколе транспортного уровня TCP (Transport Control Protocol) в стеке протоколов TCP/IP. Приложения, требующие безошибочной передачи NRT информации, обычно используют именно этот протокол. При втором подходе (Forward Error Correction – FEC) – передается избыточная информация, позволяющая обнаруживать и исправлять ошибки без повторной передачи пакетов. Такой подход используется в другом протоколе транспортного уровня UDP (User Datagram Protocol) в том же стеке протоколов TCP/IP. Приложения, обменивающиеся мультимедийной информацией, допускающей ошибки (как RT, так и NRT) обычно используют UDP для исключения потерь времени на повторную передачу пакетов. В [2] приводится ряд результатов экспериментов по использованию FEC в UDP на глобальной широкополосной сети STARTAP.

RT мультимедиа разделяется на дискретную (Discrete media – DM) и непрерывную (Continuous media – CM), в зависимости от того, передаются ли данные дискретными порциями или непрерывным потоком.

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

1.2. Текст

Текст наиболее популярен среди остальных типов мультимедиа. Он представлен в сети Интернет различными формами, включая файлы или сообщения, использующие различные протоколы передачи, такие как FTP (File Transfer Protocol: для передачи двоичных и ASCII файлов), HTTP (Hyper Text Transfer Protocol: для передачи HTML страниц) или SMTP (Simple Mail Transfer Protocol: для обмена почтовыми сообщениями). В двоичном виде текст представляется в 7-битной US-ASCII, 8-битной ISO-8859, 16-битной Unicode или 32-битной ISO 10646 кодировочных таблицах, в зависимости от используемого языка и страны. Требования к пропускной способности для текстовой информации в основном зависят от ее размера, который может быть существенно уменьшен при использовании различных схем сжатия информации [3] как показано в таблице 1.1.

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

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

Таблица 1.1

Схемы сжатия текста

1.3. Звук

Звуковая информация представляет собой звуки, преобразованные в цифровой вид с использованием выборок (sampling) и квантизации (quantization). Оцифрованный звук передается по сети как поток дискретных пакетов. Требования к пропускной способности сети зависят от характеристик звука. Например, голос по телефону сжимается с потерей информации с 12 бит до 8 бит. Это уменьшает скорость передачи с 96 kbps до 64 kbps. Некоторые схемы сжатия [4], как показано в таблице 1.2, часто используются для звуковых файлов.

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

Требования реального времени для звука жестко связаны с ожидаемым уровнем интерактивности участвующих сторон. Некоторые приложения, такие как Интернет-телефония, подразумевающие двустороннее взаимодействие, имеют высокий уровень интерактивности и требуют коротких времен отклика. В этом случае накладываются жесткие ограничения на задержку пакетов для обеспечения приемлемого качества звука. Приложения, использующие такой тип мультимедиа, называют зависимыми от режима реального времени (Real-Time Intolerant – RTI). В большинстве RTI приложений допускается задержка не более 200 мс. В других приложениях, таких как Интернет-вещание (webcast), использующих одностороннюю передачу звука, уровень интерактивности близок к нулю. Интерактивность в этом случае ограничивается командами пользователя к смене каналов.

Таблица 1.2

Схемы сжатия звука

1.4. Графика и анимация

В эту группу входят как статичные цифровые изображения, так и динамические изображения, такие как flash-презентации. Несжатое цифровое изображение состоит из массива пикселей, где каждый пиксель со своими параметрами хранится в определенном количестве битов памяти. По сравнению с текстом, цифровые изображения требуют намного больше памяти. Например, изображение размером 4 на 6 дюймов при разрешении экрана 480 на 640 пикселей и 24-битном цвете требует около одного мегабайта памяти. Передача такого изображения по сети со скоростью 56.6 Kbps занимает около двух минут. Если изображение сжато в 10 раз, требуется уже около 100 Кбайт памяти и передача занимает около 14 секунд. Некоторые популярные схемы сжатия [5] приведены в таблице 1.3. Большинство современных схем сжатия имеют прогрессивный характер, что очень важно при передаче изображений по коммуникационным сетям [3]. Когда такое изображение получается, пользователь вначале видит вариант низкого качества, который затем постепенно улучшается. Обычно достаточно принять 5-10% изображения, чтобы получить общее представление о нем. Прогрессивное сжатие достигается: (а) прогрессивным кодированием часто встречающихся фрагментов изображения, (б) использованием векторной квантизации, начинающей с оттенков серого цвета с последовательным добавлением цветов, (в) использованием пирамидального кодирования, разбивающего изображение на слои в порядке увеличения разрешения при росте номера слоя.

Таблица 1.3

Схемы сжатия изображения

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

1.5. Видео

Видео является последовательностью кадров, показываемых с определенной скоростью, обычно 24 или 30 кадров в секунду. Цифровое видео, как и оцифрованный звук, передается по сети потоком дискретных пакетов. Требования к пропускной способности зависят от уровня избыточности информации, как в каждом кадре, так и в их последовательности. Оба этих вида избыточности информации могут быть использованы для алгоритмов сжатия видео. Таблица 1.4 иллюстрирует некоторые распространенные [6] схемы сжатия видео.

Таблица 1.4

Схемы сжатия видео

Ограничения на наличие ошибок передачи и передачу в реальном времени аналогичны ограничениям для звука.

1.6. Требования к передаче мультимедиа по сетям

В этом разделе мы рассмотрим требования, накладываемые распределенными мультимедийными приложениями на передающую сеть. Они могут быть разбиты на две категории [7] – требования к трафику и функциональные требования. Первые включают требования реального времени (задержки и нестабильность, пропускная способность и достоверность), а вторые включают поддержку сервисов мультимедиа (мультикастинг, безопасность, мобильность и управление сессиями). Требования к трафику могут быть удовлетворены только расширением базовой архитектуры Интернет, в то время как функциональные требования можно выполнить введением новых протоколов в стеке протоколов TCP/IP. Функциональные требования не являются абсолютно необходимыми, в том смысле, что распределенные мультимедийные приложения могут работать с высокой производительностью путем внедрения необходимых функций в само приложение.

1.6.1. Характеристики реального времени (ограничения на задержки и нестабильность)

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

1.6.2. Требование высокой пропускной способности

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

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

Таблица 1.5

Требования к пропускной способности для различных элементов мультимедиа

1.6.3. Требования к ошибкам

Как отмечалось ранее, разные типы мультимедиа имеют разные требования к наличию ошибок при их передаче по сетям. Ошибки возникают при повреждении или потере пакетов. Большинство приложений, допускающих ошибки при передаче, используют технику маскирования ошибок (error concealment techniques – FEC), которая позволяет восстановить потерянную информацию на основе информации из других пакетов.

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

1.6.4. Поддержка мультикаста

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

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

Управление сессиями

Управление сессиями включает:

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

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

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

· Управление сессией. Информация, содержащаяся в разных потоках, может иметь внутренние связи и это должно быть учтено при ее передаче. Это называется синхронизацией мультимедиа и может быть достигнуто расстановкой меток времени (timestamps) в передаваемых пакетах. Более того, получатели потокового мультимедиа могут захотеть иметь возможность управления воспроизведением [8], как это делается в обычных видеомагнитофонах.

Безопасность

При обсуждении процесса передачи мультимедиа часто забывают про вопросы безопасности. Однако с ростом использования сервисов реального времени вопросы безопасности становятся достаточно важными. Безопасность для данных мультимедиа выражается в трех аспектах: целостность, аутентичность, шифрованность. Например, публичное вещание требует целостности и аутентичности данных, а частное – их шифрования. Для этого можно использовать различные криптографические схемы [9].

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

Поддержка мобильности

Все более широкое использование беспроводных и сотовых сетей подталкивает приложения мультимедиа к мобильности. Сотовые сети покрывают огромную площадь и поддерживают высокий уровень мобильности. Беспроводные сети, таки е как IEEE 802.11x [12], покрывают относительно небольшие участки и имеют ограниченный уровень мобильности. Однако такие сети обладают большей скоростью передачи и более удобны для подключения пользователей.

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

Глава 2. Поддержка распределенного мультимедиа трафика в Интернете

В этой главе анализируется текущее состояние сети Интернет в плане поддержки распределенного мультимедиа трафика, в том числе и в режиме реального времени.

2.1. Поддержка трафика реального времени в Интернете

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

2.1.1. Задержки при обработке пакетов

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

2.1.2. Задержки при передаче пакетов

Это время, затрачиваемое на физическом уровне для передачи пакетов. Оно зависит от нескольких факторов, например:

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

· Пропускная способность канала. Увеличение пропускной способности канала уменьшает задержки передачи пакетов. Так при переходе от 10 Mbps Ethernet к 100 Mbps fast Ethernet задержки передачи должны уменьшиться в 10 раз.

· Medium Access Control (MAC) задержка. Если канал передачи делится несколькими приложениями, то может использоваться соответствующий уровень сетевого доступа и обнаружения ошибок (MAC protocol) [14]. Выбор MAC протокола существенно влияет на величину задержки. Например, если пропускная способность C bps, а длина пакета L бит, время передачи для выделенной линии равно L/C. Но если MAC протокол использует TDMA (Time Division Multiple Access), скажем, при m слотах, задержка будет равна mL/C. Большие сети Ethernet не могут дать никаких гарантий на величину этой задержки из-за неопределенности прогноза коллизий между различными потоками данных в канале [16]. Fast Ethernet работает по той же схеме, как и 10 Mbps Ethernet и также не дает таких гарантий. Изохронный Ethernet и Ethernet с запросами приоритетов могут обеспечить качество передачи, но их распространение пока под вопросом.

· Переключатель контекста в ОС. Отсылка и получение пакетов подразумевает некоторое время на работу контекстных переключателей. Следовательно, существует некоторый максимум для скорости передачи пакетов компьютером. Для 10 Mbps LAN эта задержка может быть несущественной, но для гигабитных сетей ее уже надо учитывать. Для уменьшения этой задержки требуется улучшение драйверов устройств и повышение частоты работы компьютера.

2.1.3. Задержка передачи

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

2.1.4. Задержки маршрутизации и обработки очередей

Это единственный тип задержки, которая может быть уменьшена путем введения улучшенных моделей архитектуры Интернет. В Интернете каждый пакет обрабатывается одинаково, вне зависимости от его характера (реального или нереального времени). Промежуточные маршрутизаторы принимают независимые решения для каждого пакета. Когда пакеты встраиваются в очередь, они ожидают случайное время до их обработки, зависящее от текущей загрузки маршрутизатора. Это время добавляется к задержке в очереди. Этот тип задержки случаен и является основной причиной несинхронности в передаче данных. Если задержка времени в очереди становится слишком большой, пакет может быть послан повторно. Это может вызвать лавинный эффект и привести к перегрузке и еще большему увеличению задержки в очереди. В современных сервисах Интернета используется специальная технология для предотвращения подобных эффектов. Например, в простейшем случае образуется виртуальный выделенный канал (с выделением ресурсов в форме буферов или частот пропускания) и эта задержка исчезает. По такому принципу работают модели Integrated Services (Intserv) и Multi-Protocol Label Switching (MPLS). Другим вариантом является комбинация упорядочивания трафика, контроль входов и модификации технологии обработки очередей с учетом приоритетов пакетов. Этот подход использует модель Differentiated Services (Diffserv).

2.2. Требование высокой пропускной способности

Передача потока мультимедиа требует высокой пропускной способности каналов (см. таблицу 5). Модель негарантированной доставки (best effort Internet model) не обеспечивает никаких механизмов для приложений по резервированию сетевых ресурсов при передаче больших объемов информации. Неконтролируемая передача на высокой скорости может привести к перегрузке канала и полной остановке передачи. В данной модели нет механизма предотвращения подобных ситуаций, кроме простого отключения источников информации. Приложения сами должны динамически адаптироваться к перегрузкам каналов. Гибкие приложения, использующие TCP, применяют механизм обратной связи (closed-loop feedback mechanism), встроенный в TCP для предотвращения перегрузок. Этот метод называется реактивным контролем перегрузок. Однако многие приложения используют при передаче протокол UDP, в котором нет механизмов контроля перегрузок и есть тенденция к полной остановке передачи от перегрузок канала.

Для решения этих проблем, используется управление доступом (admission control), резервирование пропускной способности (bandwidth reservation) и механизмы управления трафиком (traffic policing mechanisms). Приложение должно сначала получить полномочия передавать трафик с заданной скоростью и с некоторыми заданными характеристиками трафика. Если такие полномочия даются, оно создает запас необходимых ресурсов (пропускной способности и буферов) для передачи данных на заданной скорости. Механизмы контроля трафика обеспечивают соблюдение заданных скоростей.

2.3. Ошибки характеристик сети

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

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

2.4. Предлагаемые модели сервисов Интернет

Мы рассмотрим несколько новых моделей архитектуры Интернет – Integrated Services (Intserv), Differentiated Services (Diffserv) и Multi-protocol Label Switching (MPLS) – которые предлагаются для удовлетворения требований распределенных приложений мультимедиа при передаче информации по обычной сети. Но, прежде чем углубляться в обсуждение этих моделей, сформулируем некоторые принципы, которые являются для них общими.

2.4.1. Уточнение требований к сервисам и описанию трафика

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

Пропускная способность определяет, сколько данных (максимально и в среднем) могут быть переданы в сети [15]. Одной битовой скорости здесь недостаточно, так как схемы QoS должны быть применимы к сетям разного типа. Например, при обработке протокола передачи важную роль играют такие вопросы, как управление буфером, таймерами и запросы управляющей информации. Затраты на эти операции связаны с числом обрабатываемых пакетов, что определяет важность пакето-ориентированных спецификаций пропускной способности. Информация о пакетах может задаваться указанием максимального и среднего размера пакетов, а также скоростью их передачи.

Задержка, в качестве второго параметра, определяет максимальную задержку передачи данных от отправителя до получателя [11]. Значение задержки при передаче мультимедийной информации может варьироваться от одного элемента к другому. Источником этих изменений задержки может быть нестабильность процесса передачи (jitter) и его сдвиг (skew). Нестабильность означает, что в потоке объектов их фактическое время появления отличается от заданного момента (рис. 2.1).

Рис. 2.1. Эффект несинхронности потока объектов:

(a)–исходный поток с регулярными интервалами; (b)–эффект нестабильности; (c)–эффект сдвига.

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

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

Надежность связана с потерями и повреждениями данных. Может быть указана вероятность потерь и метод борьбы с ошибочными данными.

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

2.4.2. Управление доступом

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

Модуль контроля доступа (см. рис. 2.2) принимает в качестве входных данных дескриптор трафика и требования QoS, а на его выходе формируется решение о принятии потока (в соответствии с требованиями QoS) или его отклонении, если требования QoS не выполняются [17]. Для этого он обращается модулю критериев приема, содержащему правила, по которым схема управления доступом принимает или отклоняет поток.

Рис. 2.2.Компоненты управления доступом

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

Другим полезным компонентом управления доступом является модуль измерения процесса (measurement process module). Если источник информации строго соответствует заданным значениям дескриптора потока, модуль управления доступом может просто использовать эти значения. Однако при передаче в реальном времени строго задать эти параметры не удается. Когда реальный трафик становится пульсирующим (bursty traffic), использования сети может быть очень низким, если управление доступом производится исключительно на основе параметров, заданных в начале сеанса.

2.4.3. Управление трафиком

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

Для управления трафиком почти всегда используется алгоритм дырявого ведра (Token Bucket алгоритм) [18]. Задача алгоритма – принять решение: передать пакет или отбросить. Параметрами алгоритма являются скорость поступления пакетов в «ведро» (бит/c) и объём «ведра». Когда ведро переполняется, дополнительные пакеты будут потеряны.
Этот алгоритм используется для систем управления трафиком, в которых избыточный трафик отбрасывается.

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

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

2.4.5. Планирование пакетов

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

2.4.6. Потеря пакетов

При перегрузке сети некоторые пакеты должны быть маршрутизаторами удалены. Раньше это делалось случайно, что приводило к неэффективной производительности при передаче мультимедийного трафика. Например, кодированный MPEG поток пакет содержит I, P и B кадры. Кадры I сжимаются без использования временной избыточности между кадрами, а Р и В кадры формируются с использованием векторов движения от кадра I (или Р). Таким образом, пакеты, содержащие кадры I, являются более важными, чем те, которые содержат кадры P или B. Когда дело доходит до потерь пакетов в сети, приоритетное внимание должно уделяться кадрам I. Обзор различных схем потерь пакетов можно найти в [19].

2.4.7. Маршрутизация на основе QoS

Интернет с негарантированной доставкой использует протоколы маршрутизации Open Shortest Path First (OSPF), Routing Information Protocol (RIP) и Border Gateway Protocol (BGP) [20]. Эти протоколы называются протоколами негарантированной маршрутизации и обычно используют одноцелевые алгоритмы оптимизации, которые рассматривают только один показатель (число транзитных участков или стоимость линии) и сводят его к минимуму, чтобы найти кратчайший путь от источника к месту назначения. Таким образом, весь трафик направляется по кратчайшему пути, что приводит к перегрузке в некоторых узлах и недогрузке в других. Кроме того, если перегрузка используется для определения стоимости линии, то сильно перегруженные узлы имеют более высокую стоимость, и такие алгоритмы могут вызывать колебания в сети, где трафик непрерывно переключается от сильно перегруженных узлов к недогруженным узлам, что приведет к увеличению задержки и нестабильности для конечных пользователей.

При маршрутизации на основе QoS пути для разных потоков определяются с учетом некоторой информации о доступности ресурсов сети. Например, на рис. 2.3 предполагается, что поток от хоста X до хоста Y требует пропускной способности 4Mbps. Следовательно, хотя путь A-B-C короче (всего два транзитных участка), он не будет выбран, так как не имеет достаточной пропускной способности. Вместо него будет выбран путь A-E-D-C.

Рис. 2.3. Маршрутизация на основе QoS

Кроме маршрутизации на основе QoS, есть еще маршрутизации на основе политик и маршрутизация на основе ограничений. Маршрутизации на основе политик [21] обычно означает, что решения о маршрутизации основана не на знании топологии сети и ее метрик, а на некоторых политиках администрирования. Например, политика может запретить транспортный поток по конкретному пути из соображений безопасности, даже если путь удовлетворяет всем ограничениям QoS. Маршрутизация на основе ограничений [22] – еще одна новая концепция, которая происходит от маршрутизации на основе QoS, но имеет более широкий смысл. В ней маршруты вычисляются на основе нескольких ограничений, в том числе и ограничений QoS и политик. Оба этих способа маршрутизации можно рассматривать как частные случаи маршрутизации на основе ограничений.

2.5. Интегрированные сервисы

Для поддержки мультимедийного трафика через Интернет, рабочая группа Integrated Services в Internet Engineering Task Force (IETF) разработала усовершенствованную модель Интернет под названием интегрированный сервис (IntServ) [23]. Эта модель характеризуется резервированием ресурсов. Она требует от приложений знания их требований к трафику и требований QoS, а также передачи промежуточным маршрутизаторам информации для резервирования ресурсов, таких как пропускная способность и размер буферов. Соответственно, если маршрутизаторы зарезервировали их и отправили обратно положительное подтверждение, можно начать передачу данных. Если, с другой стороны, достаточные ресурсы не доступны в любом маршрутизаторе пути, попытка повторяется через некоторое время. Эта модель также требует использования пакета классификаторов для определения потоков, которые должны получить определенный уровень сервиса, а также пакет планировщиков для обработки пересылки различных пакетов в порядке, обеспечивающем выполнения требований QoS.

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

Intserv вводит три класса обслуживания для поддержки RTI, RTT и гибких мультимедийных приложений. К ним относятся: гарантированный сервис (Guaranteed service), сервис контроля нагрузки (Controlled Load service) и сервис негарантированной доставки (best-effort service). Для описания передачи и требований QoS используется поток дескрипторов [1]. Поток дескриптора состоит из двух частей: спецификации фильтра (filterspec) и спецификации потока (flowspec). Filterspec предоставляет информацию, необходимую классификатору пакетов для определения пакетов, которые принадлежат к этому потоку. Flowspec состоит из спецификации трафика (Tspec) и спецификации запроса на обслуживание (RSpec). Tspec описывает поведение трафика в потоке через маркер параметров ведра (b,r), в то время как RSpec содержит требования QoS с точки зрения пропускной способности, задержки, нестабильности передачи и потери пакетов.

Поскольку все узлы сети на пути от источника к месту назначения должны быть проинформированы о запрашиваемых ресурсах, протоколов сигнализации не требуется. Для этой цели используется протокол резервирования ресурсов (RSVP) [24]. Процесс сигнализации показан на рис. 2.4. Отправитель посылает сообщение PATH для приемника, с указанием характеристик трафика. Каждый промежуточный маршрутизатор на пути сообщения PATH для следующего шага определяется протоколом маршрутизации. Приемник, получив сообщение PATH, реагирует сообщением RESV запроса ресурсов для потока. Каждый промежуточный маршрутизатор на пути может отклонить или удовлетворить запрос сообщения RESV. Если запрос отклоняется, маршрутизатор посылает сообщение об ошибке на приемник и процесс сигнализации завершается. Если запрос будет принят, для потока выделяются буфер передачи и пропускная способность, а в маршрутизаторе будет установлено соответствующее состояние.

Рис. 2.4.Сигнализация RSVP

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

2.5.1. Классы гарантированного обслуживания

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

Используя спецификацию трафика (TSpec), сеть может вычислить различные параметры, описывающие, как она будет обрабатывать поток, и путем комбинирования параметров может вычислить максимальную длину очередей и задержки маршрутизации пакета. При использовании модели потока жидкости, задержка в очереди выражается функцией двух параметров: 'B' – маркер размера ведра, и "R" – скорость передачи данных, запрашиваемая приложением.

2.5.2. Сервис управления загрузкой

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

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

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

2.5.3. Сервис негарантированной доставки

Сервис негарантированной доставки не имеет полей TSpec или RSpec, поэтому доставка действительно не гарантируется. Никакого контроля доступа в этом случае не производится.

2.5.4. Недостатки модели Intserv для Интернета

Intserv использует RSVP, чтобы резервировать на маршрутизаторах сетевой путь для каждого потока. Хотя это позволяет сети предоставлять гарантии сервиса на уровне потока, возникает проблемы масштаба. Маршрутизаторы должны поддерживать заданное состояние потока для каждого потока, проходящего через маршрутизатор, что может привести к перегрузке сети. Более того, RSVP является программным протоколом и его состояние обновляется через регулярные промежутки времени. Это также увеличивает расход трафика.

2.6. Дифферецированный сервис

Дифферецированный сервис (Differentiated Services – Diffserv) был предложен рабочей группой Diffserv из IETF как модель сервиса Интернет, устраняющую некоторые проблемы архитектуры Intserv [25]. DiffServ делит сеть на отдельные регионы, называемые DS доменами, где каждый домен управляется как отдельный объект. Одним из важных результатов является обеспечение гарантированного сервиса в рамках одного DS домена. Но если даже один транзитный участок находится за пределами домена, то гарантии уже не даются. Архитектура DiffServ может быть распространена на несколько доменов с использованием соглашений по уровню сервиса (Service Level Agreement's – SLA) между ними. SLA определяет правила разметки трафика, действия по обработке лишнего трафика и т.д.

Каждая вершина в домене DS может быть:

· Граничной вершиной. Граничные вершины являются воротами домена DS. Граничная вершина является первой (или последней) вершиной, которую проходит пакет при входе (или выходе) в (из) домен(а) DS. В ней выполняются специфичные граничные действия, такие как контроль доступа, классификация пакетов и обеспечение условий прохождения трафика. Алгоритм контроля доступа ограничивает число потоков внутри домена DS. Например, в простейшем случае, алгоритм контроля доступа может создать центральную структуру данных, содержащую текущий статус всех связей в домене DS. Когда поток проверяется на доступ, соответствующая граничная вершина должна просто проверить структуру данных на удовлетворение путей потока требованиям QoS. Каждый пакет, принадлежащий принятому потоку, по прибытии в домен DS классифицируется и маркируется как принадлежащий одному из классов сервиса, называемых “Behavior Aggregates” в терминах Diffserv. Каждому такому классу соответствует 8-битовое кодовое слово, называемое точкой кода (DS code-point). Маркировка пакетов проводится добавлением в поле TOS IP-заголовка пакета значения точки кода. Граничные вершины также обеспечивают соглашения по трафику (Traffic Conditioning Agreements – TCA) между собственным доменом DS и другими доменами, если это необходимо.

· Внутренней вершиной. Внутренняя вершина расположена полностью внутри домена DS и соединяется с другими внутренними вершинами или граничными вершинами этого же домена DS. Внутренние вершины занимаются только пересылкой пакетов. Когда пакет со своей точкой входа поступает в такую вершину, он пересылается на один транзитный участок дальше в соответствии с некоторыми заранее определенными правилами для этого класса пакетов. Такие правила называют Per-Hop Behaviors (PHB) и более детально будут рассмотрены ниже.

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

2.6.1. Per Hop Behavior

PHB является набором заранее определенных правил, определяющих, каким образом буферы маршрутизатора и пропускная способность сети будет разделяться между конкурирующими потоками. PHB могут быть определены или в терминах ресурсов маршрутизатора (буферы и пропускная способность), или в терминах приоритетов относительно других PHB, или в терминах свойств трафика (задержки и потери). Несколько PHB могут быть объединены в группу. Группа может действовать на несколько путей, так как она определена в терминах характеристик поведения и не зависит от специфики приложений. PHB могут рассматриваться как базовые блоки при создании сервисов. Для пакета PHB выбирается в первой вершине на основе точки кода. Соответствие между точкой кода и PHB может быть 1 к 1 или N к 1. Примером параметров поведения при пересылке может быть определение для потока выделенной пропускной способности (Weighted Fair Queuing – WFQ) и приоритеты при потере (Random Early Detect – RED). IETF определены два общих PHB:

· Assured Forwarding (AF) PHB. Делит входящий трафик на 4 класса с разным уровнем гарантий минимальной пропускной способности и размера буферов. Внутри каждого класса пакетам назначается один из трех приоритетов потери пакета. Путем варьирования количества ресурсов в классе может быть достигнут разный уровень производительности.

· Expedited Forwarding (EF) PHB.EF PHB определяет, что скорость отправки трафика из любого маршрутизатора должна быть больше или равна предусмотренной в конфигурации. Так для класса трафика, принадлежащего к EF PHB, в любой интервал времени гарантируется скорость отправки из любого маршрутизатора большая или равная его суммарной скорости получения пакетов. Это гарантирует минимальную задержку пакетов в очередях, ограниченную только пропускной способностью сети. EF PHB используется для обеспечения сервиса класса «премиум» (Premium Service) без задержек и нестабильности передачи. Однако EF PHB требует очень жесткого механизма контроля доступа. Он должен обеспечивать скорость прибытия трафика меньше скорости его отправки, заданной в конфигурации EF PHB. Правильное функционирование EF PHB требует еще и жестких политик. Если пакеты нарушают установленные правила, они могут быть либо отброшены, либо переведены в более низкий класс трафика.

2.7. Мультипротокольная коммутация по меткам

Когда пакет IP прибывает на маршрутизатор, следующий транзитный участок (hop) для этого пакета определяется алгоритмом маршрутизации с использованием метода «совпадения длиннейшего префикса» (“longest prefix match”), т.е. совпадения самого длинного префикса в IP-адресе пункта назначения со входами в таблице маршрутизации при выборе подходящего выходного маршрута [26]. Этот процесс добавляет некоторую задержку, так как таблицы маршрутизации достаточно велики и их просмотр требует времени. Также этот процесс приходится повторять независимо для каждого входящего пакета, даже если все пакеты принадлежат одному потоку и следуют в одном направлении. Этот недостаток может быть устранен использованием IP-коммутаторов, в которых небольшая метка прикрепляется к пакету и обновляется после каждого транзитного участка. Когда такой модифицированный пакет поступает на коммутатор (маршрутизатор в предыдущих терминах), эта метка используется для индексирования в короткой коммутационной таблице для определения дальнейшего маршрута и обновления метки. Все это легко реализуемо на уровне оборудования, поэтому выполняется с высокой скоростью. Этот подход раньше использовался в ATM для сотовых коммутаторов, которые работали с полем VPI/VCI пакета как с меткой. MPLS использует этот подход в сетях IP. Он называется мультипротокольным, так как эта технология также может быть использована на любом уровне сети, а не только на уровне IP.

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

Подобно Diffserv, сеть MPLS также делится на домены с граничными вершинами, называемыми ‘Label Edge Routers’ (LER), и внутренними вершинами, называемыми ‘Label Switching Routers’ (LSR). Пакетам, входящие в домен MPLS, назначаются метки, по которым и происходит коммутация пакета внутри домена. Метки определяют качество обслуживания потоков, проходящих через сеть. Последовательность LSR на пути внутри домена MPLS называется ‘Label Switched Path’ (LSP). И снова, подобно Diffserv, гарантируется определенный уровень обслуживания как внутри домена, так и между доменами при наличии соответствующего соглашения.

MPLS использует концепцию ‘Forward Equivalence Class’ (FEC) для обеспечения дифференцированной обработки разных типов мультимедиа. Группа пакетов пересылается одинаково, если они принадлежат одному классу FEC. Ограничений на количество и сложность структуры FEC не накладывается. Следовательно, возможно определить отдельный FEC для каждого потока или для каждого типа мультимедиа. Здесь следует отметить один важный момент. Данные метки имеют локальное значение в пределах заключенных соглашений. Необходимо назначать метки на каждом транзитном участке LSP до того, как этот поток начнет использовать LSP. Назначение меток может быть выполнено одним из следующих трех способов:

· Topology-driven label assignment. LSP (для каждого возможного FEC) автоматически устанавливается для каждой пары LSR. Эта схема накладывает жесткие требования на использование меток в каждом LSR. Однако основное преимущество такого подхода заключается в отсутствии задержек на установку LSP до использования его потоком трафика.

· Request driven label assignment. LSP устанавливается на базе определенных запросов. Для формирования запросов может быть использован RSVP. Преимуществом данного подхода в том, что LSP формируется только по запросу. Но с другой стороны, появляется новый источник задержек.

· Traffic driven label assignment. Это комбинация преимуществ двух предыдущих подходов. LSP устанавливаются только в тот момент, когда LSR идентифицирует шаблоны трафика. Если идентификация не нужна, используются обычные методы маршрутизации.

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

Глава 3. Расширение стека протоколов TCP/IP для поддержки функциональных требований распределенных мультимедийных приложений

В этой главе будут кратко рассмотрены протоколы, работающие на базе протокола TCP/IP и удовлетворяющие функциональные требования мультимедийных потоков. Затем будут представлены две архитектуры протоколов (H.323 и SIP), которые стандартизуют поддержку этих функциональных требований.

3.1. Поддержка мультикаста

Самым простым способом организации мультикаста в Интернете является простая посылка пакетов по заданным адресам [27]. Хост, готовый посылать сообщения в режиме мультикаста определенным группам мультикаста, информирует их ближайшие маршрутизаторы с использованием протокола IGMP (Internet Group Management Protocol). Мультикаст тривиален на одном сегменте Ethernet, где пакеты могут отсылаться на заданные MAC-адреса. Однако при доставке пакетов мультикаста через другие сети, маршрутизатор мультикаста нуждается в обмене информацией с соседними маршрутизаторами. Существует много различных алгоритмов, таких как "flooding", "spanning tree", "reverse path broadcasting" и "reverse path multicasting" для обмена информацией между маршрутизаторами. Некоторые из этих алгоритмов были использованы в динамических протоколах многоадресной маршрутизации, таких как Distance Vector Multicast Routing Protocol (DVMRP), Multicast extension to Open Shortest Path First (MOSPF), и Protocol Independent Multicast (PIM) [28]. На основе информации о маршрутизации, полученной с помощью одного из этих протоколов, маршрутизаторы мультикаста будут решать, следует ли направить этот пакет по своей сети или нет.

Другой подход называется MBone или Multicast Backbone. Mbone – по существу виртуальная сеть, создаваемая над фрагментами Интернет. В MBone «острова» мультикаста связаны друг с другом виртуальными ссылками, называемые «туннелями». Именно через эти туннели сообщения мультикаста передаются через обычные части Интернет. Для пересылки пакетов мультикаста через эти туннели они инкапсулируются как пакеты IP-over-IP (с уровнем протокола до 4) и выглядят как обычные пакеты.

ITU-T H.323 и IETF Session Initiation Protocol (SIP), как будет рассмотрено позже, поддерживают мультикаст посредством использования Multi-point control unit, что обеспечивает функциональные возможности, необходимые для аудио/видео конференц-связи. В [29] дается обзор вопросов QoS при мультикасте.

3.2. Управление сессиями

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

Описание сессии (Session Description Protocol – SDP) [30] [31], разработанный IETF, может быть использован для обеспечения функциональности описания сессии (описание типа мультимедиа, способ его кодирования в данной сессии). SDP кодирует описание мультимедиа в простом текстовом формате. Сообщение SDP состоит из серии строк, называемых полями, имена которых сокращены до одной буквы в нижнем регистре, и расположенных в заданном порядке для облегчения процесса анализа. Поля заполняются по шаблону attribute_type = значение. Пример сообщения SDP показан на рис. 3.1. Значение всех атрибутов записано в левой колонке, а само сообщение – в правой.

Рис. 3.1:Пример сообщения SDP

Оповещение о сессии (Session Announcement). Протокол оповещения о сессиях (Session Announcement Protocol – SAP) [32][33] используется для оповещения о предстоящих сессиях мультикаста. Оповещатель SAP периодически рассылает пакеты оповещения зарегистрированным участникам мультикаста по их адресам и портам (обычно порт 9875). Одну сессию могут анонсировать несколько оповещателей, гарантируя надежность доставки данной информации в условиях возможной потери пакетов и выхода из строя отдельных оповещателей. Период времени между повторениями объявления выбирается так, чтобы суммарный поток сообщений в сети, используемой всеми оповещателями из одной группы SAP, оставался ниже предварительно настроенного предела. Каждый оповещатель получает и другие оповещения, чтобы определить общее число сессий в конкретной группе. SAP объявляет о предстоящих многопользовательских сессиях мультикаста и начинает свою работу задолго до ее старта. SAP также содержит механизмы обеспечения целостности сессии оповещений, проверки их подлинности и шифрования.

Идентификация сессий (Session Identification). В обычном Интернете каждый поток (или сессия) могут быть идентифицированы кортежом <Src Ip, Src Port, Dst IP, Dst Port, Protocol>. Таким образом, для каждой сессии может быть установлен индивидуальный сокет транс