А теперь со всей этой фигней
мы постараемся взлететь.
Едва ли не самый распространенный вопрос последнего времени - "какой коммутатор поставить, что бы работало IPTV". Отвечать на него почти то же самое, что объяснять "в чем смысл жизни" Слишком широкий пласт технологий при этом нужно поднимать.
После краткого изучения литературы и форумов, а так же бесед с полуграмотными сейлами, сетестроитель знает волшебные слова Multicast и IGMP, но делу это помогает мало. Самое неприятное свойство IP Multicast – он весьма просто выглядит в книжке. Кстати, лучше сразу освежить в памяти классическую теорию, этот текст едва ли не самый подробный из имеющихся в он-лайне.
Если говорить кратко, то Multicast – возможность передачи потоков данных от одного пользователя ко многим при помощи специально выделенных под эту функцию IP и MAC адресов. Получатели одного и того же потока объединяются в группы рассылки, актуальное состояние которых (членство того или иного конечного узла сети) поддерживается специальным протоколом IGMP.
Очень красиво и удобно для целей трансляции видео. Задумано практически так же хорошо, как e-mail. Понять смысл и запустить в лабе может любой студент, и на любом оборудовании. Но при промышленной эксплуатации начинается такое, что у бывалых админов седеют вискИ. И быстро кончаются запасы вИски.
Так что Welcome to the real world.
Начнем с самого простого – домового коммутатора. Как минимум, он должен уметь определять запросы абонентов на мультикастовую рассылку (без нее работа IPTV фактически невозможна). Называется это чудное свойство IGMP Snooping.
Если в устройстве нет такой поддержки – оно для мультикастовых рассылок не годятся однозначно. Но это выбор не облегчает, так как управляемый коммутатор без IGMP Snooping найти сейчас не просто.
Принцип функционирования: для подписки на канал вещания (включения в группу мультикастовой рассылки) клиентское устройство должно посылать IGMP запросы примерно раз в 30 секунд, иначе маршрутизатор рассылки вырубит адрес по таймауту.
ASIC коммутатора выделяет в трафике IGMP-запросы и ответы от маршрутизатора и отправляют копию пакета на программную обработку CPU свитча. ПО свитча разбирает IGMP-сессию и создает запись в таблице коммутации для передачи запрашиваемого потока с порта роутера в нужный порт. Таким образом, в памяти должны храниться специальная таблица IGMP Snooping Groupe. Иначе говоря, сопоставление номеров порта, MAC потока и vlan (безопасность виртуальной сети нельзя нарушать).
Отсюда сразу вытекают три проблемы. Во-первых, коммутатору нужно получить из тела IGMP пакета IP адрес вещателя, потом по нему вычислить его MAC-адрес (привязать к коммутации L2 IP адрес напрямую невозможно).
Соответствие простое, младшие 23 бита адреса IP Multicast полностью соответствуют 23 битам адреса Ethernet. Вот только старшие 5 бит IP адреса Multicast при этом игнорируются. А значит при подписке на группу детских мультиков вполне можно получить в довесок нечто существенно иное. С немалым результирующим скандалом.
Создателями Multicast подразумевалось, что получатель "умный", и сам выберет что ему нужно. Только не были учтены злоупотребления, шаловливые руки настройщика, и глюки софта дешевых STB. Как тут не вспомнить проблему спама...
Во-вторых, как уже рассматривалось в #278, быстрая память ресурс не бесконечный, и дорогой. Поэтому размер таблицы невелик, в простеньком 3com 3300 – 128 записей, в Cisco 2950T – 256.
Этого хватит на распределение десятка потоков по 24 портам. Для конечного коммутатора это должно хватить, едва ли потребуется более. Но запаса нет, так как IGMP используется не только для просмотра IPTV. Достаточно приложений (от плееров до Ad-Aware), которые пытаются получить (или передать) что-то по этому протоколу. Пусть безуспешно – но место в памяти занимают от этого не менее эффективно.
Когда коммутаторы собраны каскадом или кольцом – все становится очень и очень плохо. Уже давно известно, как переполнением MAC-адресов из свитча получить хаб, рассылающий бродкасты во все стороны. Переполнение записей IGMP приводит примерно к таким же результатам, но для видеопотоков. Попытки запустить вещание приводят к его пересылке во все порты и существенной перегрузке сети. Клиентским компьютерам и домашним микрошлюзам, на которые валится это многомегабитное "счастье", то же иногда приходится тяжело.
В-третьих, IGMP обрабатывается программно. А значит, в большинстве случаев все отдано на откуп китайским мастерам софта. Доверия к которым существенно меньше, чем производителям чипсетов.
А так как функции мультикаста используются редко, тестировать их – только на пользователях. Тут даже слабо утешают "вылизанные" под крупные проекты релизы - ситуации бывают разные, и в стабильную работату в перспективе следующей пятилетки верится слабо (как призрак С.Кинга идет очередной апдейт, погасивший телевизоры извращенным способом на нескольких тысячах домов).
Мало? Но и это еще не все (с). Пользователи могут не только принимать мультикаст, но и рассылать его. Ведь в плоской сети Ethernet мультикаст не "от одного ко многим", а "от множества к множеству"! В желающих "пошалить" недостатка не будет - просто тема видеовещания доморощенными хацкерами еще не распробована.
Проблемы отступают, но за все надо платить. Cisco за $800 как рабочая лошадка, домовой свитч, дело накладное. Даже китайский коммутатор с поддержкой всех нужных функций (на бумаге) стоит на одну-две сотни дороже обычного управляемого (разница на больших сетях заметная). А сколько понадобится производителю времени, чтоб довести их софт до реальной боевой кондиции – вообще неизвестно (и не факт что возможно в принципе).
Таким образом, для сети, пригодной к промышленному IPTV, есть два варианта.
Первый:
Второй:
В идеале лучше сочетать и то, и другое. Например, даже средние по цене коммутаторы могут не спасти от переполнения записей соответствия IGMP-потоков и портов. А пользователь может по глупости или злобе выдать мультикаст с адресом "легального" потока.
Но чаще всего тонкая настройка и управление доступом оказываются банально невостребованным независимо от коммутаторов и топологи.
На пути технического прогресса насмерть, как полосатый жезл гаишника, легли правообладатели. Их требование к вещанию все еще несокрушимо – шифрация, и продажа/раздача карточек доступа абонентам. А есть там система закрытия контента средствами сети, или нет ее – их не волнует.
От этой грустной ситуации даже сети "с полным фаршем" на уровне доступа часто упрощают схему работы за ненадобностью (лень, некогда, потом, и еще десять тысяч админских отмазок).
Деньги, ушедшие на избыточно умное оборудование, оказываются потраченными "на развитие китайской школы программирования". Это должно сильно радовать Ху Цзиньтао, но никак не отечественных провайдеров.
В то же время, решение на уровне агрегации весьма просто, и давно используется многими Ethernet-провайдерами. Выглядит оно как vlan на дом (линия на дом), которая терминируется на серьезном коммутаторе L3, который заодно является мультикаст-маршрутизатором (выдает потоки).
Задача на агрегатор при этом выпадает потяжелее (фактически, это и есть тот самый BRAS из #284). Но даже фильтрация нескольких тысяч пользователей сейчас не такая серьезная задача, если речь идет всего о нескольких узлах. Каталист 650х справится. ;-)
Нужно только серьезно подойти к настройке IP-PIM, при помощи которого маршрутизаторы обмениваются информацией о потоках. Или как минимум, ничего мультикастового не рутить в сеть от абонента.
Недостатки, конечно, весьма и весьма серьезны. То, что ушло на домовой коммутатор - будет доступно всем его абонентам (однако, в легальной схеме закрыто шифрацией). Да и навредить "своему дому" можно до рассыпания картинки на квадратики (но выявить и оторвать руки не сложно). Как недорогой вариант - вполне жизнеспособно.
Впрочем, можно и эту схему (без управления на доступе) довести до логического завершения - vlan до абонента (и полный контроль).
При этом появляется два варианта:
На первый взгляд идея с юникастом кажется утопией. Но не все так просто, технологии обработки видеосигнала приходят в эту же точку с другой стороны.
Multicast очень плохо дружит с MPEG, причем на уровне стандартов. Если говорить очень упрощенно (реально механизм работы намного сложнее), то расстояние между I-кадрами (которые несут основную информацию) - около 5 секунд для MPEG-4, и 0,5 секунды для MPEG-2 (подробнее тут). Но это для динамичной картинки, где изменения идут быстро.
Для статичного изображения задержки на переключение между каналами могут растягиваться до неприличных (и неприятных) величин. Бороться с этим сложно - ограничение длинны последовательности возможно, но тут растёт ширина полосы. Поэтом приходится I-фрейм специально "запрашивать", а это опять заметное усложнение.
Что бы все это хоть как-то заработало, в некоторые системы добавляют "перевещатели". Это по сути выносы от middlware, которые преобразуют мультикаст в юникаст, буферизируют потоки, обрабатывают IGMP, запрашивают/пересылают ключи... Т.е. весьма умные и дорогие аппараты.
Если уходить еще вглубь софтовых проблем, надо запасать валокардин ведрами. Например, до сих пор нет общих стандартов примерно на 80% взаимодействия. Все знают про RTSP - а начнёшь смотреть совместимость, - появляется забавное до колик словечко "диалект". И все они "патентованы".
Даже "стандартный формат потока" у стримеров разный. Кладут информацию о потоке как захочется. И не самодельщики какие, даже Harmonic этим страдает...
Вернемся на землю L2-L3. "Перевернем медаль", посмотрим ради чего "все это". То, что для компьютерных пользователей перечисленное не слишком нужно, очевидно, на мой взгляд, без особых доказательств.
Но стоит задуматься о некомпьютерных потребителях контента, ясность теряется. Если честно, мне не понятно, как оно может работать на дешевых решениях (тем более с выносом всего сетевого интеллекта на агрегацию).
Несколько сотен абонентов с дома (а одним TV-ящиком счас обходится редкая квартира), не удастся "переварить" BRASом (по крайней мере на сегодня, по цене менее $10k). Просто задавят массой.
Так что если цель – конкурировать с КТВ за души с пультами-ленивчиками, нужно тщательно и вдумчиво разбираться с мультикастом, и вкладываться в домовые коммутаторы, агрегацию и middlware по полной программе, не жалея долларов (в том числе на оклады инженеров).
Если получится, и "полетит" - пяток-десяток баксов с проникновением 90% (что для TV реально) превзойдут все ожидания, и компенсируют любые затраты. Хотя мне в это не верится.
... А можно не мучаться и тянуть параллельно с ethernet стекло под аналоговое вещание. Но это "неспортивный" путь, и рассмотрению в этой теме не подлежит.
Началась подготовка к конференции КРОС-2007 – пока только с конкурса карикатуры "Провайдеры Средиземья". Регистрация на само мероприятие (30 мая – 02 июня) чуть позже – со следующей недели. Второе достижение - наконец заработал проект провайдеры России. Не все гладко, но "тестовый" Екатеринбург "оформился" более-менее неплохо.
Фигурки из сетевых раритетов. Многие ли сейчас помнят, что такое Т-коннектор и терминатор...
Прислал ALEX
Ссылки в одну строку:
Красноярский бизнес ищет своё место в интернете.
Публичный DNS. Не смотря на скептическое отношение, результаты мини-тестов показали, что отклик едва ли не в два раза быстрее, чем от сервиса провайдера.
Слухи о покупке Ростелекома. Есть упоминания, кто же будет реальный владелец МРК.
Белорусские власти собираются взять под контроль все локальные сети.
Сумма национальных проектов. Некторый пиар странного оператора "Сумма".
В планах оператора на этот год - построение канала связи между материком, Сахалином и Японией.
... А WiMAX и будет с ними конкурировать. Только, в отличие от домовых сетей, мы можем предоставлять доступ вне зависимости от местоположения абонента.
Wireless Audio Adapter. Технической новинкой не назвать. Но цена...
Очередное письмо по безлимитным тарифам.
Первые Безлимитные тарифы на Дальнем Востоке похоже накрылись. Во всяком случае все провайдеры молчат и занизили скорость в 2 раза минимум, до прошлой недели (до 03.03.2007) работало хорошо, скорость чуть больше заявленной например unlim 64 был где-то 8.4KB/С.
И примерно 2 дня уже паника, скорость средняя 2.5-3Kbit/s Люди готовят иск к Дальсвязи 16.03.2007.
Ссылки: http://vunlim.narod.ru/
http://www.vladivostok.ru/forum4/viewforum.php?f=38
http://forums.vl.ru/list.php?20
http://dszlo.2bb.ru/
Чтение вслух (с интонациями) сказочки про четыре unix-системы. В главных ролях HP-UX, RedHat Linux, FreeBSD, Solaris.
Прислал Станислав
Обновление в разделах:
![vk](https://vk.com/share.php?url=https://nag.ru/material/11491&title=Черт не нашего Бога&description=Едва ли не самый распространенный вопрос последнего времени - "какой коммутатор поставить, что бы работало IPTV". Отвечать на него почти то же самое, что объяснять "в чем смысл жизни". Слишком широкий пласт технологий при этом нужно поднимать. После&image=https://nag.ru/uploads/material/images/11491/social_cover.png)
