Перейти к содержимому
Калькуляторы

Правильная передача каналов в IP сеть как?

Привет всем.

У меня такой вопрос, возможно он уже обсуждался, но толком ничего найти не могу:

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

 

заранее спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то мне подсказывает что вы не до конца въезжаете в основы мультикаста, даже не видео. Оно немного отличается от юникаста, в основном тем, что маршрутизируется по тем же принципам, только все наборот. Не пойму зачем вам IP истоника переписывать. Но если уж так надо, то делается это обычным iptables в linux или ipnat в freebsd/solaris и тут вообще нет ни чего ни про мультикаст. Если говорить про фильтрацию/ограничение доступных пользователю групп, то тут обычный мультикаст-роутер с функциями фильтрации групп по подписчику/источнику спасет отца отечественного ТВ. Обычный ip-фильтр, к сожалению не пойдет -- начнут появляться группы-призраки (которые вроде и фильтруются, а все равно доползают инфа о них до потребителя). То есть нужен либо ip-фильтр, залезающий в управляющий мульткаст траффик, а это не только трафик из сети 224.0.0.0/24, но есть и другие группы, не такие очевидные. Либо обычный mvrp-/pim-/mospf-/mbgp- роутер или тупо igmp-прокси, но с возможностью фильтрации подписчиков и источников. Igmp-прокси в данном случае даже самое лучшее, в том смысле что igmp snooping сейчас даже на ноу-нэймах есть, в вот с тем же pim-snooping'ом не так уж и много, у циски pim snooping начинается на 7ххх серии или есть мега-прошивки для 37хх за сумашедшую кучу килобаксов с pim snooping'ом? В mvrp вообще смысл снупигна отсутствует, так как там идет обмен всех со всеми (между маршрутизаторами) и если пытаться снупинговать по групам, то получаться просто дыры в вещании. MVRP имеет смысл между двумя концами тунеля или когда в одном сегменте только два маршрутизатора, тогда даже этот типа mvrp-snooping (читать как недоснупинг) помогает, как в сегменте появляется третий сервер -- пошел спам: подписался один, а получают все.

 

То есть обычный igmp-прокси с фильтрацией групп + немного шаманства с конечным оборудованием (практика показывает, что можно в любой ценовой категории выудить нужную железку) и вполне полноценная система вещания готова. Полноценная в смысле, что будут смотреть только те, кто платит и пакет каналов за который платят. Ни каких извращений типа тайм-шифта или кинозала. Кинозал и VoD тоже быстро решается на базе бесплатного ПО без особого труда, если предыдущая система внедрена. Тайм-шифт -- ну это чистое извращение и топтание кнопок (кодирование), но тоже не проблема на базе фри-ПО. Dvblast потихоньку продвигается в сторону скрамблирования вещаемых потоков (если научится хотя бы обычные потоки без проблем пересылать), то есть скоро появится "коробочное" решение по скрамблированию каналов, которое, при условии, что все сделанно по схеме описанной ранее, вообще-то нафиг не нужно. Скрамблирование уже сейчас можно собрать из бесплатных библиотек и ПО, но придется покодировать.

 

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

 

Врят ли каждый шаг надо расписывать. Думаю у каждого свой рецепт для решения этих задач, да и очереность может быть другая. Например, введя скрамблирование отпадает задача по фильтрации/контролю того, что клиент смотрит только то за что платит, и в сети можно развести колхоз и бардак: "igmp snooping есть? -- ставь!".

 

ПС. гигабит мультикаста -- это хоум-аикс что ли? Ну гигабит -- это сильно завышено, живого контента там не так уж и много.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

спасибо за ответ, но вы не поняли вопрос :)

уточню положение вещей - гигабит мультикаста получается таким образом:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, все равно скорее всего не понял. Наверно живем на разных ассоциациях. Если вопрос какое железное решение покупать, то не ясна фраза.

 

но если в дальнейшем нужно будет еще что-то делать с этими потоками?

То есть нужно железо, требования к которому могут изменяться со временем в неограниченных пределах? Я бы тоже прикупил такое железо, если честно, если цена разумная.

 

Если говорить о програмных маршрутизаторах, то гигабит трафика современные процессоры пережевывают без проблем, на один зубок я бы даже сказал, карточки сетевые подороже надо будет взять (может даже есть смысл взять какие-нибудь atheros 10-гигабитный, чем нормальный, честный гигабитный интел). Даже ресурсы на какие-нибудь извращения остануться. Переписывание src-поля в ip-пакете -- это дешевая операция для современных фаерволов, если не делать откровенные глупости а-ля conntracking. Ну а мультикаст маршрутизация -- это даже дешевле юникаст-маршрутизации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если говорить про железное решение PBI из пришпиленного топика на ферху не пойдут? Тащут из мультикаста в мультикаст и да, там можно выбирать что посылать, а что нет. Перезапись src мне вот совсем не понятна, если там какие-то бубны с igmpv3, то сбросить всю сеть до igmpv2, там нет вообще такого понятия как адрес источника. Если честно, то не могу даже придумать где может IP-адрес источника помешать, даже если эти адреса будут меняться случайным в процессе вещания одного потока (забавный цирк, надо сказать) igmpv2 подъест все эти проблемы, при чем на любом железе, если оно заявлено как поддерживающее v2. Может объясните зачем IP-адрес источника мультикаста менять, для общего образования, может что проясниться тогда в общей картине. Может вы забываете какую-то деталь упомянуть, которая очевидна для вас и не совсем очевидна для меня. Терминировать куда в конце-концов ip-потоки? В СТБ или в другую КТВ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ip-адреса источников вещания нужны для PIM-SM, проверки RPF-check. Для КТВ это не имеет никакого смысла, а вот для мультикаст-вещания имеет, если изменится source-адрес источника, и он не будет известен, поток к пользователю не придет.

Про дальнейшее использование потоков - это из разряда добавить-убрать-зашифровать потоки.

Почему спрашиваю про отдельное решение - потому что городов покрытия много, и запускать придется везде, но гонять потоки критичные к задержкам\потерям по арендованному транспорту не очень вариант. Лучше в каждом городе делать это отдельно.

Зачем менять адреса источников - например, контент-провайдер А вещает в группы с одних адресов, а провайдер Б - с других. Их адресация совпадает с нашей уже использующейся в сети. Они естественно менять их не будут. В таком случае - мультикаст не запустить.

Протокол IGMP не оперирует адресами источников.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Их адресация совпадает с нашей уже использующейся в сети. Они естественно менять их не будут. В таком случае - мультикаст не запустить.

 

Вы ошибаетесь, адрес сорса может быть любой, мультикаст к юникасту имеет опосредованное отношение. При полностью мертвой юникаст-маршрутизации мультикаст будет работать, даже если понаставить всем юникаст-адресов 0.0.0.1 (с поправкой на невозможность установки одного адреса на разные интерфейсы и т.п.) igmp ходить будет. У pim'a могут быть проблемы при расчете рандеву всяких ну и где он там в юникаст таблицы лезет, неужели без pim'a ни как?

 

Ну ладно, я понял. В PBI позвоните, есть у них железка из мультикаста в мультикаст и, учитывая, что железо у них модульное, то есть можно взять из dvb в мультикаст или из мультикаста в ASI, ASI <-> dvb (что закажете), с очень большой вероятностью может оказаться, что мультикаст с мультикаста будет выходить чистым, в смысле src-IP будет самого PBI. Для вас, где много точек установки, самое оно будет -- дешево, гибко и сердито. Сам не пробовал, он кто пробовал хвалят. У них вроде даже есть из dvb в ASI _и_ мультикаст, может вам вообще то что надо будет.

 

ЗЫ IGMPv3 как раз и оперирует адресами источника на уровне подписаться на группу только от иточника с именно х.х.х.х адресом, это его основное отличие от v2.

 

ЗЫ2 Я, наверно, совсем извращен в своем представлении мультикаст-сетей, но я не могу представить себе сеть, пусть даже городскую, с настолько разветвленной гигабитной сетью (кольцо на кольце, кольцом погоняет и внутри ещё кольца... кольца... кольца...), где на всех узлах стоят 7ххх или джуниперы. Так что имело бы смысл pim запускать вместо простого резервирования, как это обычно делается, с помощью семейства протоколов stp. Это ж сколько веков такая сеть будет окупаться, учитывая замкадные цены на интернет (500р за 30Мбит)? Это не провокация, это просто мое извращенное видиние сетей. Pim'ом интерено, конечно, поиграться, но когда эти игры превращают в повседневный колхоз, как-то все обратно скатывается к уровню 2.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость Tplink

Cisco (Scientific Atlanta) DCM - штука готовая, в которую на входе подается все что есть, а на выходе пакет из нужных каналов, с нужными источниками-группами, которые можно нормально стерминировать? На входе и на выходе - мультикаст-потоки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость Nic

Есть решение которое может вам подойти. Железо собираете сами, софт запрашивайте с iptvportal.ru.

В запросе напишите что нужна система CAS на тест.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

спасибо всем за ответы!

тоже вот склоняюсь к решению от iptvportal

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот такой мультиплексор неплохой:

http://www.shs-systems.ru/catalog/head/mult/bnp.html?ch=11

Дорогой. Надежный

позволяет принять каналы по аси, ip. на выход выдает уже с нужным мультикаст адресом, отфильтровать при этом ненужные пиды, переставить их в нужном порядке, позволяет зарезервировать, например берется первый канал с двух источников, если один из источников сбойнет = переключит на другой.

шифровать _вроде_ не умеет - это через cas надо пропустить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.