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

Обеспечение надежной передачи видео по IP-сетям

В рубрику "IP-security" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Обеспечение надежной передачи видео по IP-сетям

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

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

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

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

Пропускная способность

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

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

Отказоустойчивость

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

Однако при обеспечении отказоустойчивости в сетях с трафиком реального времени следует также учесть, что в зависимости от используемых технологий время перехода на резервные каналы может быть слишком большим и неприемлемым для решения поставленных задач. Это не относится кагрегации каналов Ethernet, поскольку там переключение происходит сразу же после выхода из строя одного из соединений. Но, например, протокол STP в своей основной реализации по умолчанию перестраивает коммутационный путь в течение 30 с. Протокол OSPF при отказе основного канала при настройках по умолчанию ожидает до 1 5 с, прежде чем применить резервный маршрут. Для таких случаев многие протоколы поддерживают дополнительные настройки, позволяющие ускорить время сходимости маршрутов или путей коммутации. Так, у протокола STP были разработаны различные модификации (RSTP - Rapid Spanning Tree Protocol), позволяющие переключаться на резервные каналы практически сразу же после отказа основных физических линий. В случае с протоколом OSPF оборудование большинства производителей позволяет изменять значения таймеров таким образом, что переход на резервный маршрут происходит менее чем за секунду.

Восстановление потерь

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

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

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

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

Технологии восстановления пакетов трафика реального времени сложны в реализации и требуют оборудования с соответствующей функциональностью. Тем не менее многие производители сетевого оборудования предлагают собственные успешные реализации восстановления потерь в своих решениях. Кроме того, существуют стандарты, описывающие эти технологии, но из-за сложности реализации они все еще находятся на стадии развития. Например, уже давно разрабатывается протокол PGM (Pragmatic General Multicast), который может использоваться в качестве альтернативы протоколу UDP на транспортном уровне для передачи трафика multicast. Этот протокол предусматривает специальные сигнальные сообщения, которыми обменивается сетевое оборудование в случае возникновения потерь, и позволяет повторно отправлять недостающие пакеты. Протокол PGM частично поддерживается некоторыми производителями, но, находясь в экспериментальной стадии, пока еще не получил широкого распространения

Мониторинг видеопотоков

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


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

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

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

Новейшие разработки

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

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

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


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

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

  Автор

Илья Назаров

Илья Назаров

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

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

В рубрику "IP-security" | К списку рубрик  |  К списку авторов  |  К списку публикаций