Распространение радиотелевизионного контента по IP-сети

Полнокровный телевизионный контент систем Интернет - телевидения формируется в ЦУСе. От антенного поста туда приходят пакеты телепрограмм различных провайдеров, там же находится центральный видеосервер и серверы иных персонифицированных услуг. Можно было бы говорить о ядре сети, но этот термин более приемлем, когда речь идет о Triple Play-услуге. В дальнейшем, применяя термин «ядро сети», молчаливо предполагаем, что нас интересуют и телевидение (будем для простоты вести речь только о IPTV), и высокоскоростной Интернет HSI (High Speed Internet), и VoIP. Говоря о ЦУСе, будем затрагивать более узкие вопросы, а именно, как будут распространяться broadcast-, multicast- и unicast-трафики, будут ли они перегружать какие-то участки сети и будут ли мешать друг другу. При организации Triple Play-сети основную нагрузку в ней создает услуга IPTV. По некоторым данным, в ближайшем будущем абоненты будут предпочитать смотреть HDTV (на что при стандарте MPEG-2 нужна скорость передачи данных 18...20 Мбит/с). Если добавить услуги HSI, VoIP и другие, то необходимая скорость доступа в Интернет может возрасти до 25...30 Мбит/с. В связи с этим возникает вопрос выбора технологии «последней мили». Использование технологии ADSL2+ позволяет теоретически достичь требуемых скоростей, но на практике большие расстояния линий и их плохое качество очень часто не дают необходимой пропускной способности.

Также не стоит забывать, что далеко не все операторы имеют доступ к существующей кабельной инфраструктуре. Зачастую перед ними стоит задача создания собственной оптической кабельной системы. Принимая во внимание вышесказанное, все более актуальным становится использование в будущем или прямого подключения клиентов к Ethernet-коммутаторам, или применение технологий PON (Passive Optical Networks). Однако на данный момент технологии ADSL2+ пока имеют широкое применение и будут долго использоваться там, где уже созданы такие IPTV-сети.

Рассмотрим пример построения IPTV-сети в неком крупном городе (рис. 2.1).

Рис. 2.1. Топология построения уровней доступа

Магистральный уровень сети (далее не рассматриваем) построен по кольцевому принципу, объединяя шесть микрорайонов. В нашем примере физические сети доступа в одном микрорайоне построены па коммутаторах Gigabit, Ethernet по схеме «кольцо», а в другом — по схеме «дерево». Обсуждение начнем с более простой древовидной топологии сети. Она начинается корневыми (root) коммутаторами, которые подключаются к узлам магистрального уровня. В свою очередь, к корневым подсоединяются коммутаторы для непосредственного предоставления услуг конечным пользователям. Данная схема имеет преимущества и недостатки. Основное преимущество — возможность постепенного наращивания количества клиентских портов путем добавления новых коммутаторов к корневым. Это позволяет избежать больших единовременных финансовых вложений в сеть доступа. Другим преимуществом данной топологии является наличие запасного (резервного) пути коммутации пакетов до узла магистрального уровня. К недостаткам относится отсутствие резервирования каналов.

Кольцевая топология представляет собой цепочку из коммутаторов, которая замыкается на узлах уровня магистрали. Все коммутаторы в подобной топологии используются для подключения конечных пользователей. В таких топологиях неизбежно образование петель коммутации. Для решения этой проблемы применяются протоколы «связующего дерева» STP (Spanning Tree Protocol). Основным требованием к коммутаторам уровня доступа для реализации кольцевых топологии является поддержка протоколом RS'I'P (802.1w) и MSTP (802.1s). Данные протоколы позволяют гибко распределять полезную нагрузку по двум направлениям «кольца». В этом случае рекомендуется «разрыв кольца» протоколами STP в самой удаленной точке от магистрального узла.

Второй принципиальный вопрос состоит в том, как разнородные услуги будут делить ресурсы сетей, т.е. какая логика доступа может использоваться, чтобы услуги HSI и VoIP как можно меньше мешали передачам IPTV и чтобы разные видеопотоки по возможности не мешали друг другу. Известны две модели логической топологии сети доступа: своя виртуальная сеть (VLAN) на каждый сервис и все сервисы передаются в пределах одной общей VLAN. Реализацию этих моделей иллюстрирует рис. 2.2.

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

Виртуальные сети

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

При реализации данной модели нет необходимости анализировать заголовки IP-пакетов. Каждая из трех виртуальных сетей заканчивается непосредственно на клиентском устройстве СРЕ (Customer Premise Equipment), которое должно поддерживать протокол IEEE 802.1q, заносящий VLAN ID в заголовок Ethernet-фрейма. Затем каждый порт СРЕ закрепляется за определенной VLAN в соответствии с принадлежностью к услуге. Так как можно однозначно определить, к какому виду услуги относится данный тип трафика (по идентификатору VLAN ID), то все процедуры, связанные с обеспечением заданного качества обслуживания (классификация трафика, ограничение полосы пропускания и т.п.) необходимо выполнять на коммутаторе уровня доступа.

При подключении клиентов к коммутатору нет необходимости осуществлять приоритезацию на клиентском оборудовании, поскольку СРЕ будут подключаться по интерфейсам Fast Ethernet (100 Мбит/с), полоса пропускания которых будет более чем достаточной для передачи трафика от клиента.

Проанализируем теперь вторую модель, когда все сервисы предоставляются в одной общей VLAN (в нижней части рис. 2.2 это соответствует одной большой трубе). Очевидно, что здесь можно пропустить большие объемы информации (вспомним, как это получается при статистическом мультиплексировании в MPEG-стандартах). Однако возможен вариант, когда большая загрузка скоростного Интернета переполнит сеть, и тогда начнутся теряться пакеты IPTV-трафика. Здесь ведь трафик всех услуг клиента коммутируется на узлы магистрального уровня в одной виртуальной сети LAN. Клиентское СРЕ подключается к порту коммутатора доступа без использования протокола IEEE 802.1q (не комментируем здесь и далее протоколы, отсылая читателя к разделу 2.4 или к иной литературе). При реализации данной схемы возникает вопрос корректной обработки клиентского трафика для обеспечения требуемого уровня качества обслуживания, для чего необходимо однозначно разделить график каждого сервиса. Ввиду отсутствия заголовков протокола IEEE 802.1q (в том числе и протокола IEEE 802.1р) первичную классификацию трафика следует осуществлять в клиентском СРЕ на основании поля DSCP заголовка IP-пакета.

Для каждого вида сервиса четко определен порт на клиентском СРЕ. Весь пользовательский трафик, приходящий на порт СРЕ, предварительно маркируется определенным значением поля DSCP. Далее уже непосредственно на коммутаторе уровня доступа происходит конечная обработка пакетов в соответствии с политикой качества обслуживания (конечная классификаций трафика, ограничение полосы пропускания и т.п.). При реализации этой модели требуется решить еще одну проблему. Если в модели 1 VLAN per Service однозначно можно определить, из какого пула следует выделять IP-адрес для данного абонентского устройства услуги (на основании VLAN ID-сервиса), то в данном случае необходимо использовать дополнительные возможности. На абонентских устройствах клиента для каждого вида услуги (IP-телефон, STB IPTVи т.п.) необходима поддержка Option 60 протокола DHCP. В Option 60 пакета DHCP Discovery добавляется информация о типе устройства (другими словами, вида услуги), запрашивающего адрес. Таким образом, оператор может гибко управлять адресным пространством. Для предоставления же услуги HSI в модели 2 используется только DHCP-схема.

Не все коммутаторы подходят для предоставления триединых услуг и IPTV. В нашем случае для общих моделей коммутаторы должны соответствовать двум требованиям: контроль широковещательной рассылки (BroadCast Stream Control) и ограничение максимального количества МАС-адресов на порту коммутатора доступа Dynamic Port Security (MAC-based). Оба этих требования диктуются соображениями безопасности.

Рассмотрим первое требование, т.е. необходимость контролировать широковещательную рассылку, широко используемую в среде Ethernet. Большое число таких пакетов может вызвать перегрузку сети, что приводит к потере качества предоставляемых услуг. Данная функция позволяет ограничивать количество широковещательных пакетов, которые приходят от клиента на порт коммутатора. Обычно на порту выставляется максимальная пропускная способность (в пакетах в секунду) для данного типа трафика.

Теперь обсудим второе требование, состоящее в необходимости ограничения максимального количества МАС-адресов. В коммутаторах размер таблицы МАС-адресов конечен, в связи с этим переполнение данной таблицы приводит к сбрасыванию адресов самых первых пользователей, что ведет к появлению уязвимых мест, чем могут воспользоваться злоумышленники. Переполнение таблиц можно вызвать посылкой большого количества Ethernet-фреймов с различными MAC-адресами источника. Функция Dynamic Port Security позволяет ограничить количество МАС-адресов, с которых могут приходить пакеты на порт коммутатора.

Для обеспечения безопасности и возможности контроля клиентского трафика следует предоставить прохождение всего трафика через узлы магистрального уровня. Для этого реализуется два технических решения: во-первых, использование технологии Private Edge позволяет исключить возможность обмена трафиком между клиентами, подключенными к одному коммутатору, а во-вторых, у каждого коммутатора уровня доступа VLAN-сервисов должны быть уникальные VLAN ID (за исключением multicast VLAN).

Это позволит исключить возможность обмена трафиком между клиентами, подключенными к разным коммутаторам.

Вне зависимости от выбора модели в сети используется большое количество VLAN для предоставления услуг. При использовании сервиса широковещательного телевидения для услуги IPTV возникает многократное дублирование multicast-трафика. Группы пользователей, находящиеся в различных сетях VLAN, просматривают одни и те же телевизионные программы. Для решения данной проблемы используется функция MVR. (Multicast VLAN Registration): на сеть доступа выделяется одна виртуальная сеть VLAN для распространения multicast-трафика (MVR VLAN). Когда клиент посылает IGMP-запрос на определенную группу, коммутатор стандартными способами отправляет его в MVR VLAN. При наличии требуемой телепрограммы multicast начинает реплицироваться в порт клиента. С точки зрения безопасности сервиса широковещательного телевидения необходима поддержка фильтрации IGMP-запросов (IGMP Filtering) и максимального количества multicast-групп (IGMP Max Group). IGMP Filtering позволяет указать диапазон Multiсast-адресов, на которые может подписаться клиент. IGMP Max Group ограничивает количество multicast-групп, на которые может быть одновременно подписан каждый клиент.

Для схемы сети, представленной на рис. 2.1, предполагается, что VoD-yслуга любому абоненту IPTV-сети поступает от центрального видеосервера, находящегося в ЦУСе. Если много абонентов одновременно пользуется услугой «видео по требованию», то это будет сильно перегружать магистральную сеть. Для того, чтобы не гонять трафик по всей сети, целесообразно перед каждым корневым коммутатором ставить локальный видеосервер. Локальные видеосерверы имеют в своем видеоархиве самые популярные фильмы и востребованные видеосюжеты (причем накапливаются они автоматически путем анализа запросов клиентов). Вероятность заказа популярного контента очень высока и уже это разгружает магистральную сеть. Кроме того, услуга NVoD обычно делается существенно дешевле, чем VoD. Поэтому за счет перекачки нужного локальным видеосерверам контента во временные промежутки, когда нет перегрузки магистральной сети, тоже удается экономить ресурсы. Сказанное иллюстрирует желательные подходы к оптимизации unicast-трафика, циркулирующего по сети.

Формирование IP-пакетов