Контакты
Подписка
МЕНЮ
Контакты
Подписка

Передача видео Multicast: простые решения сложных проблем

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Передача видео Multicast: простые решения сложных проблем

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

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

Обеспечение надежности передачи Multicast

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

На сегодня различные возможности QoS реализованы практически на любом сетевом оборудовании. С принципами их работы и примерами настроек можно ознакомиться в Интернете, поэтому рассматривать их не будем. Сложности возникают, когда даже при обеспечении гарантированной пропускной способности на канале все равно возникают потери пакетов. Такая ситуация типична для каналов последней мили, где потери пакетов происходят вследствие ошибок на физическом уровне. Наиболее актуальной данная проблема является для операторов услуг IPTV, которые не всегда могут обеспечить качественный канал до оборудования абонента Производители решений IPTV решают данную проблему, встраивая возможность повторной отправки потерянного пакета. В общем случае для этого используются специальные серверы, кэширующие видеопотоки, которые устанавливаются на периферийных узлах. Абонентские устройства (set top box) отслеживают состояние потоков и при возникновении потерь пакетов запрашивают повторную передачу этих пакетов у ближайшего сервера. Если поток передается в формате Multicast, повторные пакеты передаются абонентскому устройству в виде Unicast, чтобы не нагружать каналы других пользователей.

В настоящее время ведутся разработки стандартного протокола Pragmatic General Multicast (RFC 3208), который также предназначен для отслеживания потерь пакетов Multicast и повторной их отправки. Некоторые производители сетевого оборудования и операционных систем уже реализуют функционал PGM в своих продуктах.

Передача поверх сетей Unicast

Другая проблема, которая часто случается при построении сетей вещания, - отсутствие поддержки маршрутизации Multicast на некоторых сегментах сети. Такая ситуация может возникнуть, например, если источник и приемник находятся в разных сегментах сети, соединяемых через Интернет или посредством арендованного IP VPN. В подобном случае применяются технологии туннелирования. Для этих целей разработано множество протоколов и стандартов, на особенностях которых не будем заострять внимание, отметим лишь, что туннель может быть маршрутизирующим или коммутирующим. В первом случае маршрутизаторы на концах туннеля должны поддерживать протоколы передачи IP Multicast (PIM), во втором - поток передается прозрачно на уровне кадров Ethernet.

В качестве примера можно привести популярную утилиту OpenVPN с открытым исходным кодом, которая может работать в любом из этих режимов. Режим маршрутизации здесь используется по умолчанию, в этом случае создается виртуальный TUN-интерфейс с присвоенным IP-адресом. Для настройки туннеля в режиме коммутации требуется, во-первых, установить пакет утилит Bridge UtiIs, во-вторых, произвести дополнительные изменения в файле конфигурации. Вместо TUN указываем тип интерфейса ТАР (этот тип используется для прозрачной передачи кадров Ethernet) и указываем сценарии инициализации и отключения туннеля:

dev tap0
up "/etc/openvpn/up.sh"
down "/etc/openvpn/down.sh"

В сценарии инициализации (up.sh) включаем виртуальный интерфейс в режиме прозрачной передачи кадров и присваиваем ему соответствующий идентификатор bridge:

/sbin/ip link set tap0 up promise on
/usr/sbin/brctl addif br0 tap0

В сценарии отключения (down.sh) отвязывается идентификатор и отключается интерфейс:

/usr/sbin/brctl delif br0 tap0
/sbin/ip link set tap0 down

При этом в файле /etc/network/interfaces уже должны быть прописаны настройки интерфейса bridge:

auto br0
iface br0 inet static
bridge_ports eth0

На интерфейсе br0 при этом можно настроить IР-адрес, который будет использоваться для удаленного доступа на сам сервер. Таким образом, туннельный интерфейс и интерфейс локальной сети (eth0) оказываются в одной группе с общим идентификатором br0, и трафик между этими интерфейсами будет передаваться прозрачно, аналогично тому, как это делает обычный коммутатор. Полностью описание и примеры настроек можно найти на сайте www.openvpn.net.

Объединение доменов

Одна из самых сложных задач при использовании IP Multicast возникает, когда требуется объединить несколько существующих изолированно друг от друга сетей в единый домен, где получатели потоков должны иметь возможность принимать потоки как из своей сети, так и из присоединенной сети. Главная неприятность, с которой в этой ситуации могут столкнуться администраторы сети, - это пересечение адресного пространства. Если повторяющихся адресов не так уж и много, то можно просто поменять адреса (если есть такая возможность). Но что делать, если такой возможности нет?

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

Другой способ - использование технологии SSM (Source Specific Multicast) на базе протокола PIM. В этом случае маршрутизация каждого потока в сети осуществляется не по адресу группы рассылки Multicast (G), а по каждой уникальной паре "источник - группа" (S,G). Таким образом, для потоков, имеющих одинаковые адреса Multicast, но разные IP-адреса источников, создаются отдельные маршруты. При использовании SSM следует озаботиться еще и тем, чтобы приложения, принимающие потоки, также могли различить их по адресам источников. Чтобы приложение могло подписаться на необходимые потоки, нужно, чтобы оно использовало протокол IGMP версии 3.

Использование шлюза

Кардинальным решением при объединении доменов вещания будет использование специального шлюза. Такой вариант, несмотря на дороговизну, обладает наибольшей гибкостью и иногда является единственным способом решить проблему совместимости. Шлюз может не только осуществлять трансляцию адресов, но и полностью преобразовывать потоки на более глубоком уровне. Например, можно, принимая постоянный поток RTP из одного домена, осуществлять его перекодировку (transcoding) на лету и добавить возможность подписки на поток по протоколу RTSP в другом домене. При этом для приема и передачи потоков можно использовать адреса и Multicast, и Unicast, а также их комбинации при дублировании потоков. Решения IPTV и VoD различных производителей, как правило, содержат в себе подобный функционал, чтобы обеспечить совместимость с различными абонентскими устройствами и сетевой инфраструктурой.


Разнообразные варианты работы шлюза рассмотрим на примере еще одной популярной утилиты с открытым исходным кодом - VLC media player. Многие пользуются этой программой как обычным видеопроигрывателем, даже не подозревая, насколько богатым функционалом она обладает. Для настройки VLC в качестве шлюза можно пользоваться как графическим интерфейсом, так и командной строкой. Синтаксис командной строки зависит от используемой ОС и может различаться в зависимости от версии программы. В версии 2.0.0 для Windows строка запуска может выглядеть так (одной строкой):

vlc.exe rtp://@239.1.1.1:5004 :sout=#transcode {vcodec=mp2v,vb=800,scale=1,acodec=mpga, ab=128,channels=2,samplerate=44100} :rtp {dst=239.2.2.2,port=1234,mux=ts,ttl=8}

В качестве первого аргумента программе передается адрес принимаемого потока (это также может быть имя файла или устройства видеозахвата), следующие за ним аргументы - список опций. В данном случае мы подписываемся на поток RTP с адресом 239.1.1.1 и портом UDP 5004, перекодируем его (опция transcode), используя видеокодек MPEG-2 и аудиокодек MPEG Audio, и передаем уже с другим адресом - 239.2.2.2 и портом 1234.


Еще один вариант использования:

vlc.exe rtp://@239.1.1.1:5004 :sout=#duplicate {dst=rtp{dst=239.2.2.2,port=5004,mux=ts,ttl= 16},dst=rtp{dst=192.168.1.1 ,port=5500,mux= ts,ttl=16}}

Опция duplicate позволяет дублировать потоки, используя разные IP-адреса и UDP-порты. В данном примере мы принимаем тот же поток и передаем его в двух экземплярах: с адресами 239.2.2.2 и 192.168.1.1. Указывая в качестве параметра dst-адреса Unicast, можно также решить проблему с передачей потока через сети, которые не поддерживают маршрутизацию Multicast.

Обо всех опциях и возможностях VLC можно узнать на сайте www.videolan.org

Изучайте протоколы!

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

Опубликовано: Журнал "Системы безопасности" #4, 2012
Посещений: 24894

  Автор

Илья Назаров

Илья Назаров

Системный инженер
компании "Интелком лайн"

Всего статей:  6

В рубрику "Комплексные решения. Интегрированные системы" | К списку рубрик  |  К списку авторов  |  К списку публикаций