О проблемах внедрения multicast и сетевых методах улучшения его работы

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

Для доставки ТВ-каналов по IP-сетям используют multicast - многоадресную (один-ко-многим) рассылку IP-трафика. По сравнению с unicast-трафиком multicast позволяет существенно оптимизировать занимаемую полосу, так как репликация трафика происходит только в местах ветвления (рис. 1 и 2).

Рис. 1 Unicast-доставка видео.

Рис. 2. Multicast-доставка видео.

Обозначим основные условия, необходимые для качественного оказания сервиса операторами связи, внедряющими multicast-доставку видео на своей сети:

1. Гарантированная полоса пропускания.
2. Малая задержка распространения.
3. Небольшая вариация задержки (DF).
4. Передача трафика с наименьшим количеством потерь.

При этом возникают и следующие задачи:

1. Сохранение простоты эксплуатации сети.
2. Оптимизация нагрузки.
3. Минимизация времени обнаружения и устранения аварийных ситуаций.

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

Пожалуй, самый популярный метод. Работает практически в любой сети, на любом оборудовании. Для ресивера важен только адрес группы. Имеет дополнительную сложность в виде одного или, как правило, нескольких RP (rendezvous-points) и настройке MSDP между ними.

Довольно прост в настройке. Совместим не со всем оборудованием. Требует поддержки IGMPv3 на ресиверах или меппинга (*,G) ` (S,G) на первом от ресивера маршрутизаторе.

Прост в реализации. Сводит на нет преимущества multicast, так как репликация трафика делается на точке входа в VPLS-облако, хотя и существуют доработки по использованию P2MP LSP.

Устройствам уровня ядра не нужно обрабатывать PIM и заниматься multicast-маршрутизацией. Вариант с использованием P2MP RSVP-TE позволяет статически прокладывать RSVP-TE туннели и резервировать под них полосу. Но при этом устройство-headend туннеля держит состояние всех sub-LSP, а изменение топологии влияет на все маршрутизаторы, через которые проложен туннель. Вариант с mLDP является более масштабируемым и простым, хотя лишен встроенных в RSVP механизмов резервирования полосы и принудительного задания маршрута. Примеры построения деревьев распространения LSM представлены на рис. 3 и 4.

Рис. 3. Сигнализация P2MP RSVP-TE.

Рис. 4 Сигнализация mLDP.

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

• выделение отдельных аппаратных очередей под multicast,
• приоритизация данного типа трафика над другими.

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

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

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

Рис. 5. Резервирование источников через Anycast.

FRR (Fast Re-Route) при отказах линков в сети может уменьшить время перерыва доставки трафика до значений менее 50 мс. Это обычный вариант Link Protection, когда для резервируемого линка выстраивается обходной туннель до маршрутизатора, доступного через этот линк.

Еще один интересный метод улучшения сходимости для multicast-трафика - MoFRR (Multicast only FRR). Этот метод подразумевает наличие активного резервного пути дохождения multicast до PE-устройства. Пакеты, приходящие по резервному пути, отбрасываются. При аварии на основном маршруте пакеты с резервного пути перестают отбрасываться. Для функционирования MoFRR требуется его поддержка на PE.

Рис. 6 Функционирование MoFRR.

Рассмотрим пример, изображенный на рис. 5. Имеются два ресивера, подключенных к маршрутизаторам B и D. Маршрутизатор D посылает два Join запроса в сторону маршрутизаторов B и C. Путь через C становится активным, а через B ? резервным. При этом трафик поступает на D с обоих линков - от В и от C. Так как пакеты, приходящие со стороны B, отбрасываются, то полоса на линке B-D занимается впустую. Но зато при отказе линка C-D или полностью маршрутизатора C практически моментально маршрутизатор D перестает отбрасывать пакеты со стороны B. Тем самым время перерыва доставки multicast до ресивера, подключенного к D, сводится к долям секунды (может быть существенно меньше пресловутых 50 мс), потраченным на детектирование аварии и принятие решения о переключении. Но для такого подхода необходимо иметь минимум два маршрута с одинаковой стоимостью до источника, чтобы маршрутизатор смог опознать наличие резервного пути.

Но так ли актуальна сходимость в течение 50 мс для видеотрафика? Если вспомнить структуру MPEG видеопотока:

Рис. 7. Порядок кадров в потоке MPEG-видео.

• I-frame - содержит полную информацию о кадре;
• P-frame - формируют кадр с учетом информации из предыдущих I или P-frame;
• B-frame - формируют кадр с учетом соседних I или P-frame.

При этом потеря всего лишь одного I-frame может повлечь за собой потерю всей GOP (Group Of Pictures). Размер GOP зависит от вида и настроек кодирования. Для MPEG2 это 12-18 кадров (до 0,6 с), для H.264 может достигать уже 300 кадров (10 секунд). Напрашивается вывод - доставка видео должна быть непрерывной. То есть желательно резервировать все, кроме самого ресивера, и время переключения должно быть равно 0.

Такой метод резервирования называется Live-Live. Ресивер принимает два идентичных потока multicast-трафика от различных источников. При этом пути распространения от источников до ресивера в идеале нигде не пересекаются. Это может достигаться применением MTR (multi-topology routing) или прокладкой непересекающихся P2MP RSVP-TE туннелей. Так как пакеты multicast-видео имеют порядковые номера, ресивер может с легкостью собрать из двух потоков один, даже если с какой-либо из них доходил с перерывами. На рис. 8 изображен пример использования метода Live-Live для доставки видео до EdgeQAM в сети оператора кабельного ТВ.

Рис. 8. Пример использования Live-Live.

В то же время такой подход очень неэкономно расходует ресурсы сети, так как фактически объем передаваемых данных возрастает в два раза! Бесперебойную доставку можно обеспечить и другим способом - с использованием серверов unicast-докачки VQE (Video Quality Experience). Такие сервера позволяют досылать пропавшие пакеты через unicast. Также важной функцией VQE является ускорение переключения каналов. Остановимся подробнее на методах работы:

Переключившись на другую группу multicast, ресивер начинает получать пакеты с I-, P- и B-frame. Представим ситуацию, когда ресивер начинает получать трафик сразу после прохождения I-frame. Тогда, для начала отображения видео, он должен дождаться следующего I-frame. Как упоминалось ранее, период ожидания может доходить до 10 секунд! В таких случаях и спасает VQE, который на непродолжительное время кэширует все потоки multicast-трафика. Ресивер запрашивает начало GOP у VQE-сервера и, получив его через unicast (значительно быстрее 10 с), начинает воспроизводить видео. Также это работает и при пропадании пакетов с кадрами на активной группе. Недостаток такого подхода проявляется при пропадании пакетов одновременно у многих пользователей (может быть вызвано сбоем на участке сети). Тогда все N ресиверов обращаются на VQE-сервер(а), что создает нагрузку на сеть, в N раз превосходящую таковую в нормальном режиме (оптимизация: при множественных обращениях - докачка тоже через multicast). Для функционирования VQE в ресиверах должна быть реализована поддержка данного метода. Пример использования VQE изображен на рис. 9.

Рис. 9. Использование VQE.

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

Для проактивного мониторинга и устранения аварий операторы, как правило, развертывают решения, состоящие как из программных так и аппаратных компонент. Хорошим примером такого решения является Cisco VAMS (Video Assurance Management Solution). Оно включает в себя программные средства мониторинга, поиска и устранения неисправностей:

1. ROSA - мониторинг headend`а.
2. Cisco Multicast Manager - ПО мониторинга и сбора метрик потоков multicast с оборудования Cisco (платформ ASR9000 и 7600) и сторонних производителей (Bridgetech, IneoQuest и др.).
3. Cisco ANA - элемент-менеджер.
4. CiscoInfoCenter - управляющее ПО с возможностью корреляции событий.

С помощью функции Inline Video Monitoring на линейных картах платформ ASR9000 и 7600 можно детектировать и устранять проблемы с распространением видео до того, как недовольные абоненты обрушатся на операторский call center. А интеграция с IP-probe производителей-партнеров позволяет мониторить качество доставки вплоть до самого ресивера! При этом Inline Video Monitoring не требует покупки и установки дополнительного оборудования - передача трафика и его мониторинг осуществляются на линейных картах одновременно без потери производительности. Проекты по тестированию и развертыванию VAMS ведутся на сетях многих крупных (и не очень) операторов связи.

Будущее телевидения в том виде, котором мы его знаем, скорее всего, будет не очень долгим. Это подтверждает стремительный рост таких сервисов, как YouTube, Hulu и многих других. Но multicast останется с нами надолго: для применения в интерактивном телевидении, граничащем с видеоконференциями и видеоприсутствием, передачи данных в сенсорных сетях, сетях видеонаблюдения, финансовых приложениях (биржевая торговля, аналитика) и других областях.

PS. Более детально изложенные решения можно изучить на семинарах Cisco Learning Club и, естественно, в сети Интернет.

Об авторе: Артур Якупов - системный инженер Cisco.