Распространение радиотелевизионного контента по 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-пакетов