Со всем согласен, но есть один нюанс - это клиентский CPE. Как оказалось, количество CPE, которые могут исполнить 1q на WAN и при этом сделать 3play на любом LAN интерфейсе (а не маппинг vlan(vci)-lanport) исчезающе мало, плюс требует некоторой магии со стороны оператора (dns, разбирающийся в типе клиента 3play/regular). Аналогично igmp snooping, не везде есть. Вообщем надо что-бы теперь вендоры китайского барахла за 50уе почитали и осознали куда идти 13 августа 2009 г. 18:24 пользователь Vladimir Litovka (doka.ua@gmail.com) написал:

Привет,

в процессе работы (как всегда :) ) нарисовалась вот такая преза -

http://vugluskr.mml.org.ua/pubCiscoDocs/SP-Implementing3play-E0903.pdf

в которой собраны некоторые соображения на тему того, как можно строить сеть для предоставления услуг на основе IP. Данный подход не стремится быть истиной в последней инстанции и может быть творчески переосмыслен в любой его части :-) Некоторые вещи являются повторением когда-то уже сказанного, просто в этот раз я постарался собрать отдельные части во что-то целое.

Enjoy reading и если что-то спорно или не слишком ясно изложено - можно дискутировать :)

-- /doka

-- Yours, Max Telecommunication/HPC consulting

Они осознали давно. И работают в полный рост на то, что будет через 3-5 лет. А цицко судя по этой презентации делает в этом только первые, совсем еще неуклюжие и смешные шажочки ;) Гуглить Elecard iTelec82, например. Был представлен на НАГовке. Цена - $95 FOP, умеет 2 Ether (вход-выход), FXS, S-VHS и DVB видео. Есть 1 MiniPCI и 2 USB 2.0 слоты расширения (скажем, под WiFi). Открытая Linux-платформа. Max Speransky wrote:

Со всем согласен, но есть один нюанс - это клиентский CPE. Как оказалось, количество CPE, которые могут исполнить 1q на WAN и при этом сделать 3play на любом LAN интерфейсе (а не маппинг vlan(vci)-lanport) исчезающе мало, плюс требует некоторой магии со стороны оператора (dns, разбирающийся в типе клиента 3play/regular). Аналогично igmp snooping, не везде есть. Вообщем надо что-бы теперь вендоры китайского барахла за 50уе почитали и осознали куда идти

13 августа 2009 г. 18:24 пользователь Vladimir Litovka (doka.ua@gmail.com) написал:

...

Привет,

в процессе работы (как всегда :) ) нарисовалась вот такая преза -

http://vugluskr.mml.org.ua/pubCiscoDocs/SP-Implementing3play-E0903.pdf

в которой собраны некоторые соображения на тему того, как можно строить сеть для предоставления услуг на основе IP. Данный подход не стремится быть истиной в последней инстанции и может быть творчески переосмыслен в любой его части :-) Некоторые вещи являются повторением когда-то уже сказанного, просто в этот раз я постарался собрать отдельные части во что-то целое.

Enjoy reading и если что-то спорно или не слишком ясно изложено - можно дискутировать :)

-- /doka

-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Да ну, эт не серьезно. Когда оно в каждом магазине будет, тогда оно есть. А так, это все прототипы, у меня такие CPE собраны на старых ноутах =) p.s. а так конечно посмотреть этот элекард интересно, есть живая железка ? 14 августа 2009 г. 0:26 пользователь Max Tulyev (maxtul@netassist.kiev.ua) написал:

Они осознали давно. И работают в полный рост на то, что будет через 3-5 лет. А цицко судя по этой презентации делает в этом только первые, совсем еще неуклюжие и смешные шажочки ;)

Гуглить Elecard iTelec82, например. Был представлен на НАГовке. Цена - $95 FOP, умеет 2 Ether (вход-выход), FXS, S-VHS и DVB видео. Есть 1 MiniPCI и 2 USB 2.0 слоты расширения (скажем, под WiFi). Открытая Linux-платформа.

Max Speransky wrote:

...

Со всем согласен, но есть один нюанс - это клиентский CPE. Как оказалось, количество CPE, которые могут исполнить 1q на WAN и при этом сделать 3play на любом LAN интерфейсе (а не маппинг vlan(vci)-lanport) исчезающе мало, плюс требует некоторой магии со стороны оператора (dns, разбирающийся в типе клиента 3play/regular). Аналогично igmp snooping, не везде есть. Вообщем надо что-бы теперь вендоры китайского барахла за 50уе почитали и осознали куда идти

13 августа 2009 г. 18:24 пользователь Vladimir Litovka (doka.ua@gmail.com) написал:

...

Привет,

в процессе работы (как всегда :) ) нарисовалась вот такая преза -

http://vugluskr.mml.org.ua/pubCiscoDocs/SP-Implementing3play-E0903.pdf

в которой собраны некоторые соображения на тему того, как можно строить сеть для предоставления услуг на основе IP. Данный подход не стремится быть истиной в последней инстанции и может быть творчески переосмыслен в любой его части :-) Некоторые вещи являются повторением когда-то уже сказанного, просто в этот раз я постарался собрать отдельные части во что-то целое.

Enjoy reading и если что-то спорно или не слишком ясно изложено - можно дискутировать :)

-- /doka

-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

-- Yours, Max Telecommunication/HPC consulting

Добрый день! On Fri, Aug 14, 2009 at 12:08:38PM +0300, Andrey Elperin wrote: ...

Кстати, всем кто интересуется темой, могу порекомендовать следующую книгу :

http://www.amazon.com/Broadband-Network-Architectures-Designing-Triple-Play/...

К сожалению, где взять в электронном виде - не знаю, у меня старообрядный бумажный вариант.

Для тех, кому лень искать: http://rapidshare.com/files/267273133/Prentice_Hall_Broadband_Network_Archit... -- Dmitry Kiselev

Приветствую, Вы писали 18 августа 2009 г., 15:50:57:

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

В принципе вполне реализуемо, но тогда нужно еще включать стоимость адекватной биллинговой системы (разработка или покупка). -- Sergey Galat

Приветствую, Вы писали 19 августа 2009 г., 11:11:57:

Якщо це читають колеги з Датагрупа, то вони можуть поправити трохи :) OSS (а не біллінг) займається такими справами.

А в Алкателівських [серйозних] комутаторах це вміє їх рідна NMS. Алкател NMS просто так дает ... в качестве дружеского жеста? ;)

P.S. Коню ясно, що, вважаємо, що і OSS, і всі NMS інтегруються з біллінгом.

Именно. Но тогда нужно и эту часть учитывать при расчетах затрат.

2009/8/18 Sergey Galat

...

Приветствую,

Вы писали 18 августа 2009 г., 15:50:57:

...

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

В принципе вполне реализуемо, но тогда нужно еще включать стоимость адекватной биллинговой системы (разработка или покупка).

-- Sergey Galat

-- Sergey Galat

2009/8/13 Vladimir Litovka :

2009/8/13 Max Speransky :

...

Со всем согласен, но есть один нюанс - это клиентский CPE. Как оказалось, количество CPE, которые могут исполнить 1q на WAN и при

+1 Кроме того, рост количества сервисов требует их распределения по VLANам, что нетривиально, особенно если сервисы генерируются 3-ими сторонами. Также непонятно, как один и тот же сервис использовать на разных абонентских устройствах -- например, вместо обычного телефона на FXS порте принять сервис на софтфоне. Unified communications на дворе, так сказать. В общем, IMHO, "VLAN-per-service" будет жить только до того момента, когда оператор сможет утвердить бюджет с L3-устройствами на access уровне.

На самом деле, эта модель может применяться и без транка в сторону абонента. В этом случае либо -

1) предоставляется одна услуга (например, inet) - тогда попросту маркируется весь трафик на порту. На самом деле, большинство операторов на этом останавливается ;-)

надеюсь, это не надолго :-)

2) или маркировка трафика на входе от абонента делается по IP ACL (оператор все же знает, на каких адресах у него сидит video и voice системы)

...

Вообщем надо что-бы теперь вендоры китайского барахла за 50уе почитали и осознали куда идти

у тебя есть знакомые, куда можно было заслать на почитать? :))

Интересна вообще жизненность концепции - отказ от BRAS'а как выделенного устройства в пользу использования достаточно стандартных возможностей оборудования (STP на доступе, IP routing (не MPLS) на агрегации, простой QoS (1R2C, queueing only), HSRP/VRRP) для вполне качественного и надежного предоставления услуги - с резервированием и некоторыми гарантиями.

IMHO, речь идет не о том, чтобы выбрать среди 2-х вариантов размещения BRAS'а -- централизованного и распределенного, а о том, насколько вообще близко к абоненту можно поставить BRAS. В идеале с точки зрения управления абонентом BRAS должен стоять вплотную к нему и реализовывать функциональность SBC. По мере движения BRAS к абоненту промежуточные L3 и L2 средства сокращаются и упрощаются. Пример подобного BRAS -- семейство Smart Edge от Red Back (он же -- Ericsson). Ну и отдельный вопрос -- что делать с мобильным бродбендом, который, все ближе и ближе, и скоро может начать вытеснять традиционный стационарный бродбенд. Понятно, что уже никакие транки в сторону клиента не проходят. PPPoE -- тоже. Как быть с клиентами, которые могут входить в сеть географически разнесенных точках -- дотянуть VLAN не удастся, а "узнать" клиента (т.е. аутентифицировать и предоставить все заказанные сервисы) надо именно в этой точке входа.

Плата - отказ от тарификации внутрисегментного трафика в пользу абонплаты (размер сегмента определяется оператором) и некоторая "червивая" хоботня в неконтролируемом (с точки зрения объема, а не качества) сегменте сети (размер которого определяется оператором).

Опять же, IMHO -- этот отказ может быть как временная мера, позволяющая сократить расходы до лучших времен. Ну и в любом случае -- не преподносить возможность локального неконтролируемого обмена трафиком между абонентами как специальную услугу. Ты ведь неспроста назвал это "червивой хоботней" :-) P.S. Сорри за запоздавшую реплику, но вопрос ведь не потерял свою актуальность. -- Dmitry Cherkasov

At 12:17 Tuesday 01 of December 2009 Andrew Stesin wrote:

2009/8/14 Dmitry Kiselev :

...

Для тех, кому лень искать: http://rapidshare.com/files/267273133/Prentice_Hall_Broadband_Network_Arc hitectures.pdf.html

Коллеги, у кого-то это сохранилось? рапидшара говорит, что мол "давно файл не качали и он удален".

У меня есть. 7.6 Мб. Куда лучше будет положить? -- Marina S. Uzhentseva UM551-RIPE