IPTV, к слову сказать, вообще убыточная для практических всех операторов услуга. Она, как правило, служит лишь для удержания имеющейся базы ШПД-абонентов, чтобы они не уходили к другому оператору.
Это очень сложно. Для того, чтобы статистика бьла репрезентативной, необходимо собирать статистику достаточно долгое время. Если же оператор изменит политики, на основании которых выполняется построение очередей, статистику надо будет собирать заново. Методика, как мне кажется, обречена при наличии думающего администратора в NOC.
Проблема в том, что когда операторы увидят аномальный рост в их сети какого-либо легитимного трафика без особых предпосылок, это будет для них звоночком, что что-то не так. В свою очередь, вендоры DPI найдут способ корректного распознавания такого типа трафика. Это всё напоминает кошки-мышки.
Система весьма и весьма надёжна. Есть живой опыт уже более чем трёхлетней работы у двух немаленьких клиентов (в районе 200 телефонов). Остановки сервиса были только при смене софта, CME работает как часы.
CME достаточно простая для освоения вещь, масштабируемая, и весьма надёжно работающая в масштабах не самого маленького офиса. Мы как-то заморачивались с настройкой скриптов для вывода погоды на экраны цискофонов. Бестолково, зато поигрались:) А самый ад наступил в тот момент, когда пришлось осваивать Cisco Unity Express с её адским редактором скриптов автосекретаря. Это был костыль на костыле.
Ну это понятно, P2P подключение даёт бОльшую скорость до абонента, но худшую утилизацию волокна до коробки, которая эту оптику принимает (OLT в случае GPON, коммутатор доступа/агрегации в случае ETTH). Free пошли по более дорогому, но более перспективному варианту. GPON, как и xDSL — это компромисс.
Полностью согласен, подписываюсь под каждым словом. xDSL — это прекрасная технология для своего времени, которая позволила сделать интернет максимально доступным всем группам пользователей. Операторы экономили достаточно приличные деньги на последней миле, что делало бизнес более рентабельным при меньших end-user ценах на услуги предоставления доступа в интернет, а пользователям нравилось, что в квартире не надо долбить стены и заводить дополнительные шнурки, и стоимость выше, чем на «выделенках». В плане надёжности у xDSL (по крайней мере в специфике России) есть один колоссальный плюс. Оборудование оператора всегда находится на площадке этого самого оператора, что позволяет решать проблемы, связанные с получением физического доступа к коробкам, значительно оперативней.
Но есть и минусы, основной из которых — ограниченная вполне известными цифрами пропускная способность. Бурное развитие IPTV, а в особенности услуг VoD, диктует свои правила. Не за горами времена, когда пользователи захотят в выходной день посмотреть что-нибудь в 3D-формате, в то время как дети будут смотреть HD-мультики или играть в игры посредством какого-нибудь сервиса наподобие OnLive. Для этого никакого DSL не хватит.
Здесь можно много говорить о том, что в России подобного не будет ещё лет пять. Но мы так и будем стоять на обочине новых технологий, приговаривая как же хорошо и быстро на западе. Проблема в слабой работе маркетологов наших операторов, которые не показывают реальных профитов IPTV. К сожалению, я не знаю конкретных цифр, но что-то мне подсказывает, что продажи HD-ready теликов за последние пару лет выросли в разы. А в HD-контент по сути никто не вкладывается. В Москве самый активный игрок на этом рынке, насколько я понимаю, это Акадо. Все остальные делают HD для галочки, чтобы отчитаться перед начальством. Т.е. народ покупает большие телики с FHD, и смотрит на них эфирные каналы, которые до SD-качества не дотягивают…
Разумеется, но надо ж придумать как оно будет ползать по комнате и обнаруживать носки, попутно выполняя их сортировку:)
В общем, надо задачку придумать для начала
К 26 годам я наконец-таки заполучил в руки эту игрушку. Оно того стоит. завораживает наблюдать за тем, как программа исполняется не на компьютере, а в живом железе, которое жужжит моторчиками:) Думаю над тем, как произвести интеграцию этого хозяйства с моим любимым 8725
Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…
Бесспорно. Но неужели нельзя использовать существующий байт Suboption type чуть более оптимально, чем сейчас? К примеру, разбить его на равное количество кусков, соответствующих Circuit ID, Remote ID, какому-либо ещё несуществующему зарезервированному ID и т.д. И внутри каждого из этих кусков напилить соответствия типам (Router interface number, Switching Hub port number и т.д.). Думаю, байта вполне себе хватит для этих нужд.
В общем, это переливание из пустого в порожнее. Надо работать с тем, что есть, и не забывать держать в голове все эти расклады во избежание некорректного интеропа.
Циска решила значения субопций хранить в виде TLV-триплетов
Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV. Можно пойти дальше и сделать ещё одну иерархию и т.д.
извольте не додумывать всякое и не строить беспочвенных теорий
Как же мне не додумывать, если в документе явно не оговаривается что такое Value и какую информацию оно несёт? Если не оговорено, самое логичное что приходит в голову (мою, естественно) — это собственно value, т.е. символьное значение той строки, на основании которой происходит DHCP-машинерия в части option-82. Мои теории настолько же беспочвенны, как и цискины, которая решила. Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить. Циска не смогла продавить это расширение в RFC? Так ведь на то, видимо, были причины, не находите?
Тем не менее, к чему вы клоните я понял. Признаю, что наезды на циску настолько же беспочвенны, как и на джунипер и иже с ними. Наезжать надо на написателей RFC.
Отбросим лишнее — за что отвечают Circuit ID Type и Remote ID Type? Нигде не нашёл ни одного объяснения.
RFC должен быть таким, чтобы не вызывать разночтений.
Про ASCII согласен, это может быть и hex, но здесь другой момент.
TLV, ок. У циски же скорей сделано в виде TLTLV, о чём свидетельствует картинка-пояснение с офсайта:
Но там нигде не поясняется что есть Circuit ID Type и Remote ID Type.
Давайте посмотрим что происходит, когда такое сообщение приходит на тот же жунипер. Он видит поле Type и понимает, что приехал, к примеру, Remote ID. Отлично, дальше смотрим на длину. Он видит длину, которая составляет, как вы правильно подметили, ASCII String + 2 байта. Взглянув на цисковскую картинку, это объяснимо. Далее коробка уверена, что после поля Length следует полезная информация — ASCII String. Вместо этого там два байта с какой-то ерундой, которые ломают String к чертям. Приводит это к тому, что коробка не в состоянии корректно распознать строку, т.к. реально она начинается на два байта позже.
В RFC нарисовано следующее:
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?! Видимо, при написании RFC подразумевалось, что вендоры не будут изобретать велосипед, но это явно не про циску:)
Вам повезло, что всё работает как надо. Я имел большое несчастье тестить интероп в части option-82 с использованием Juniper MX как DHCP-коробки, и свитчей juniper EX, Cisco ME3400 и какого-то Edgecore. Жуниперы друг друга поняли сразу. Иджкор начал пониматься после того, как китайцы спешно переписали софт. Циску же так и не удалось заставить работать. Видимо, и не удастся.
Но есть и минусы, основной из которых — ограниченная вполне известными цифрами пропускная способность. Бурное развитие IPTV, а в особенности услуг VoD, диктует свои правила. Не за горами времена, когда пользователи захотят в выходной день посмотреть что-нибудь в 3D-формате, в то время как дети будут смотреть HD-мультики или играть в игры посредством какого-нибудь сервиса наподобие OnLive. Для этого никакого DSL не хватит.
Здесь можно много говорить о том, что в России подобного не будет ещё лет пять. Но мы так и будем стоять на обочине новых технологий, приговаривая как же хорошо и быстро на западе. Проблема в слабой работе маркетологов наших операторов, которые не показывают реальных профитов IPTV. К сожалению, я не знаю конкретных цифр, но что-то мне подсказывает, что продажи HD-ready теликов за последние пару лет выросли в разы. А в HD-контент по сути никто не вкладывается. В Москве самый активный игрок на этом рынке, насколько я понимаю, это Акадо. Все остальные делают HD для галочки, чтобы отчитаться перед начальством. Т.е. народ покупает большие телики с FHD, и смотрит на них эфирные каналы, которые до SD-качества не дотягивают…
В общем, надо задачку придумать для начала
А с русскоязычными сообществами я так понял всё достаточно грустно?
теперь непонятно когда работать))
Бесспорно. Но неужели нельзя использовать существующий байт Suboption type чуть более оптимально, чем сейчас? К примеру, разбить его на равное количество кусков, соответствующих Circuit ID, Remote ID, какому-либо ещё несуществующему зарезервированному ID и т.д. И внутри каждого из этих кусков напилить соответствия типам (Router interface number, Switching Hub port number и т.д.). Думаю, байта вполне себе хватит для этих нужд.
В общем, это переливание из пустого в порожнее. Надо работать с тем, что есть, и не забывать держать в голове все эти расклады во избежание некорректного интеропа.
Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV. Можно пойти дальше и сделать ещё одну иерархию и т.д.
извольте не додумывать всякое и не строить беспочвенных теорий
Как же мне не додумывать, если в документе явно не оговаривается что такое Value и какую информацию оно несёт? Если не оговорено, самое логичное что приходит в голову (мою, естественно) — это собственно value, т.е. символьное значение той строки, на основании которой происходит DHCP-машинерия в части option-82. Мои теории настолько же беспочвенны, как и цискины, которая решила. Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить. Циска не смогла продавить это расширение в RFC? Так ведь на то, видимо, были причины, не находите?
Тем не менее, к чему вы клоните я понял. Признаю, что наезды на циску настолько же беспочвенны, как и на джунипер и иже с ними. Наезжать надо на написателей RFC.
RFC должен быть таким, чтобы не вызывать разночтений.
TLV, ок. У циски же скорей сделано в виде TLTLV, о чём свидетельствует картинка-пояснение с офсайта:
Но там нигде не поясняется что есть Circuit ID Type и Remote ID Type.
Давайте посмотрим что происходит, когда такое сообщение приходит на тот же жунипер. Он видит поле Type и понимает, что приехал, к примеру, Remote ID. Отлично, дальше смотрим на длину. Он видит длину, которая составляет, как вы правильно подметили, ASCII String + 2 байта. Взглянув на цисковскую картинку, это объяснимо. Далее коробка уверена, что после поля Length следует полезная информация — ASCII String. Вместо этого там два байта с какой-то ерундой, которые ломают String к чертям. Приводит это к тому, что коробка не в состоянии корректно распознать строку, т.к. реально она начинается на два байта позже.
В RFC нарисовано следующее:
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?! Видимо, при написании RFC подразумевалось, что вендоры не будут изобретать велосипед, но это явно не про циску:)
Вам повезло, что всё работает как надо. Я имел большое несчастье тестить интероп в части option-82 с использованием Juniper MX как DHCP-коробки, и свитчей juniper EX, Cisco ME3400 и какого-то Edgecore. Жуниперы друг друга поняли сразу. Иджкор начал пониматься после того, как китайцы спешно переписали софт. Циску же так и не удалось заставить работать. Видимо, и не удастся.