Алгоритмы мультимедиа

В начале 90-х годов были сделаны первые попытки использовать Интернет для передачи голоса в реальном масштабе времени (VocalTek). В настоящее время IP-телефония стала обычным видом услуг. Более того, она сыграла определяющую роль в снижении телефонных тарифов. Появились регулярные музыкальные программы. На подходе подключение к этому виду сервиса всех мобильных коммуникаций и цифрового телевидения. Этому способствовала разработка алгоритмов MPEG-1 + -4 и прикладных программ, реализующих эти алгоритмы.

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

Для формирования групп слушателей в 1982 (RFC-1112) был создан протокол IGMP (Internet Group Management Protocol), позднее он несколько раз дополнялся и совершенствовался (RFC-2236 и -3376). В рамках технологии IPv6 функцию IGMP взял на себя протокол ICMP (см. http://book.itep.ru/4/44/igmp_449.htm и там же ~/ip6_4411.htm).

Для доставки мультимедиа-потоков обычно используется мультикастинг-адресация, но в последнее время определенную популярность приобрела технология P2P (Peer-to-Peer). Маршрутизация таких потоков также имеет свою специфику. Если обычно маршрут прокладывается от отправителя к получателю, то для мультикаст-потоков это делается в обратном направлении (см. описание протоколов PIM и DVMRP).

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

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

Разработано два алгоритма гарантии QoS – это IntServ и DiffServ. Первый вариант реализуется протоколом RSVP, второй – MPLSTE. Эти два протокола используют разные механизмы резервирования.

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

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

10.1. Протокол управления группами IGMP

Передача мультимедийных данных по сетям Интернет является одним из наиболее важных направлений. Этот вид информации передается обычно в режиме без установления соединения (протокол UDP-RTP). Наиболее типичной схемой в этом случае является наличие одного передатчика и большого числа приемников. Эта схема реализуется с использованием мультикастинг-адресации. Мультикастинг-адресация может осуществляться на IP- и MAC-уровнях. В Ethernet для этих целей зарезервирован блок адресов в диапазоне от 01:00:5E:00:00:00 до 01:00:5E:7F:FF:FF. Первый байт адреса, равный 01, указывает на то, что адрес является мультикастным. Данная схема резервирования адресного пространства позволяет использовать 23 бита Ethernet-адреса для идентификации группы рассылки при IP-мультикастинге (см. рис. 10.1.).

Рис. 10.1. 1 Соотношение мультикастинговых MAC- и IP-адресов

Область из 5 бит в IP-адресе, отмеченная *****, не используется при формировании Ethernet-адреса. Так как соотношение IP и MAC-адресов не является однозначным, драйверы должны обеспечивать обработку адресов, чтобы интерфейсы получали только те кадры, которые действительно им предназначены. Для того, чтобы информировать маршрутизатор о наличии участников мультикастинг-обмена в субсети, связанной с тем или иным интерфейсом, применяется протокол IGMP.

Протокол IGMP (internet group management protocol, RFC-1112) служит для передачи по каналам Интернет музыки, для аудио- и видеоконференций, а также группового исполнения команд различными ЭВМ. Этот протокол использует групповую адресацию (мультикастинг).

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

При групповой адресации один и тот же пакет может быть доставлен заданной группе ЭВМ. Членство в этой группе может динамично меняться со временем. Любая ЭВМ может войти в группу и выйти из группы в любое время по своей инициативе. В то же время ЭВМ может быть членом большого числа таких групп. ЭВМ может посылать пакеты членам группы, не являясь им сама. Каждая группа имеет свой IP-адрес класса D (рис. 10.2, см. также рис. 10.1).

Рис. 10.2. Формат группового адреса

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

Ряд мультикастинг-адресов зарезервирован строго для определенных целей (таблица 10.2).

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

Рис. 10.3. Формат IGMP-сообщений

Поле версия определяет используемую версию протокола, поле тип=1 говорит о том, что это запрос, отправленный мультикастинг-маршрутизатором, тип=2 указывает, что этот отклик послан ЭВМ. ЭВМ использует групповой адрес, чтобы сообщить о своем подключении к группе. Контрольная сумма вычисляется по тому же алгоритму, что и для ICMP. IGMP-сообщения используются мультикастинг­маршрутизатором, чтобы отслеживать членство в группе каждой из сетей, подключенных к нему. В группе может участвовать несколько активных процессов одной и той же ЭВМ, но при этом посылается только один запрос для регистрации. Когда какой-то процесс покидает группу, ЭВМ не шлет сообщения об этом, даже в случае, когда это последний из процессов-членов группы на данной ЭВМ. Просто при очередном запросе ЭВМ не подтвердит членство в группе. Мультикастинг-маршрутизатор регулярно посылает запросы с требованием подтвердить участие в группе. ЭВМ посылает отклик-подтверждение для каждой из групп, если у нее есть хотя бы один процесс-член группы. На основе этих запросов-откликов мультикастинг-маршрутизатор составляет и поддерживает таблицу интерфейсов, которые имеют одну или более ЭВМ, входящих в мультикастинг-группы.

Протокол IGMP применяется при организации мультикас­тинг-туннелей для передачи звуковой и видеоинформации. Для решения проблем мультимедиа в сетях Интернет используется идея MBONE.

По умолчанию мультикаст-дейтограммы имеют значение поля TTL=1 (time-to-live), что ограничивает их распространение одной субсетью. Приложения могут увеличивать значение TTL. Первая дейтограмма, тем не менее, всегда имеет TTL=1. Если получение этой дейтограммы не подтверждается сервером, посылается вторая — с TTL=2 и т.д. Таким образом, попутно измеряется и число шагов между клиентом и сервером. Для случая, когда число шагов не более 1, зарезервирован блок адресов 224.0.0.0 - 224.0.0.255. Маршрутизатор не обрабатывает пакеты с такими адресами, вне зависимости от кода поля TTL.

При использовании мультикастинга MAC-переключатели переадресуют пакеты через все имеющиеся интерфейсы, что заметно ухудшает эффективность сети. Чтобы решить эту проблему, компания CISCO разработала протокол CGMP (Cisco Group Management Protocol), который позволяет взаимодействовать маршрутизаторам и переключателям, и это способствует передаче мультикаст-пакетов только на те интерфейсы, где имеются активные члены группы.

10.2. Мультикастинг и MBONE

MBONE — это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные компанией Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются туннелями. Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэндфордском университете в 1988 году.

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

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

MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с.

Каждый туннель имеет определенный порог для переменной времени жизни пакета (timetolive — TTL). Согласно договоренности (IETF) широкополосная видеоинформация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видеопакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, который существует в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами.

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

Увеличивая TTL, прикладной процесс может расширять зону взаимодействия. Сначала дейтограмма может посылаться с TTL=1, затем, если отклика не получено — c TTL=2, и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами, вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает.

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

phyint <localaddr> [disable] [metric <m>] [threshold <t>]
tunnel <localaddr> <remoteaddr> [metric <m>] [threshold <t>]

Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<localaddr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Вторая команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1.

10.3. Протокол реального времени RTP

В Интернет, так же, как и в некоторых других сетях, возможна потеря пакетов, изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. Мультимедийные приложения накладывают достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями LAN и Интернет был разработан протокол RTP. Протокол RTP (См. RFC-3550, 3551, 3711; 4571 4586, "RTP: A Transport Protocol for RealTime Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предложенных Кларком и Тенненхаузом [10.1] и предназначен для доставки данных в реальном масштабе времени (например, аудио или видео). При этом определяется тип поля данных, производится нумерация посылок, присвоение временных меток и мониторирование доставки. Приложения обычно применяют RTP поверх протокола UDP для того, чтобы использовать его возможности мультиплекси рования и контрольного суммирования. Но RTP может работать и поверх любой другой сетевой транспортной среды. Протокол RTP поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем.

Следует иметь в виду, что сам по себе RTP не обеспечивает своевременной доставки и не предоставляет каких-либо гарантий уровня сервиса (QoS). Этот протокол не может гарантировать также корректного порядка доставки данных.

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

На практике протокол RTP неотделим от протокола RTCP (RTP control protocol). Последний служит для мониторинга QOS и для передачи информации об участниках обмена в ходе сессии.

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

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

Заголовок пакета RTP указывает, какой вид кодирования звука применен (PCM, ADPCM или LPC), что позволяет отправителю при необходимости сменить метод кодирования, если к конференции подключился новый потребитель с определенными ограничениями или сеть требует снижения скорости передачи.

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

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

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

На уровне RTP не существует какой-либо взаимосвязи между аудио- и видеосессиями. Только RTCP-пакеты несут в себе одни и те же канонические имена участников.

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

Смеситель преобразует поток аудиопакетов в последовательность дейтограмм, которая соответствует возможностям узкополосного канала. Эти пакеты могут быть уникастными (адресованными одному получателю) или мультикастными. Заголовок RTP включает в себя средства, которые позволяют мультиплексорам идентифицировать источники, внесшие вклад, — так что получатель может правильно идентифицировать источник звукового сигнала.

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

Смесители и трансляторы могут выполнять и другие функции, например, преобразование IP/UDP пакетов в ST-II при видеоконференциях.