Rambler's Top100


Вы

посетитель








А нужен ли АСР модуль Inventory ?


Модуль управления и контроля доступа LBInventory.

  Анализ тенденций развития операторов ШПД (широкополосного доступа), телефонии и цифрового ТВ наводит на некоторые мысли, в частности, на мысли о том, что сети средних операторов (в данном случае под средними, я понимаю операторов, услугами ШПД которых пользуется от 3000 до 20 000 человек), активно строящиеся, кстати, медленно, но верно приблизились к состоянию, в котором стало возможно управление услугой (в частном случае ШПД) непосредственно на порту устройства. Стоит подчеркнуть управляемого устройства. Опрос, который провел отдел маркетинга [нашей компании] (среди, более, чем 600 активно эксплуатирующих систему операторов), также свидетельствует о том, что сети либо уже построены на управляемых устройствах [56% опрошенных], (речь идет именно об уровне доступа), либо частично [30% респондентов], что означает, что в таких сетях имеется полностью управляемый сегмент.

  Эта информация заставляет задуматься о системе поддержки этой возможности в системе управления и контроля доступа биллинговой системы. Вопрос бы может быть и не стоял бы в необходимости реализации (изменения существующей системы контроля) подобной поддержки в АСР, если бы изначально производители биллингов предусмотрели использование не только централизованного механизма управления (практически все системы из ценового диапазона: от 1000$ до 10000$ не содержат в себе механизма контроля доступа, позволяющего контролировать, именно, распределенную сеть управляемых устройств), но и возможность определить конкретное сетевое устройство (как правило его IP/MAC адрес), которым необходимо управлять для, как минимум, регулирования доступа к услуге (услугам) конкретного абонента.

  Казалось бы что может быть проще привязать конкретную учетную запись к порту устройства ? Да, в общем-то, ничего. С точки зрения понимания способа реализации. Однако, на практике, разнообразие применяемых коммутаторов / маршрутизаторов в сетях накладывает определенные сложности на реализацию. Фактически это разнообразие вынуждает реализовать полноценную систему инвентаризации сетевых устройств в рамках биллинга (включая конструктор устройств и пр. "прелести" Inventory), несмотря на то, что существует масса дорогих и не очень Inventory и ГИС в разной степени функциональных для решения подобной задачи: от простых систем учета аппаратуры на складе и в сети, до полноценных ГИС с привязкой устройств к карте, ведением описания кабельного хозяйства и online мониторинга.

  Цель текста - обсудить эту тенденцию и поделиться опытом по поднятому вопросу. Как решается задача в боевых условиях? Решается ли вообще? Ведь несколько особняком стоит вопрос управления "локальным" трафиком. В идеале необходима возможность сепаратного управления услугами "доступ в Интернет" и "доступ в локальную сеть".

  Наша компания разработала концепцию развертывания Inventory модуля в LANBilling (выход - декабрь месяц 2008 г.) которая приведена ниже и на наш взгляд может стать лишь одним из способов решения означенной выше задачи.

  Обсуждение статьи можно провести на форуме [forums.lanbilling.ru], а также на форумах [opennet.ru], [hub.ru] и [nag.ru] с надеждой на то, что модераторы поддержат эту инициативу.

Примечание: Цели и задачи LBInventory (выдержка из ТЗ)

Обеспечить путем "привязки" абонентской учетной записи, идентифицируемой ip адресом (mac - адресом, или их связкой) к порту управляемого устройства (ближайшему к аппаратуре абонента управляемому порту) следующие возможности:


     
  • Управление услугой доступа к ресурсам непосредственно на порту устройства (регулирование доступа к услугам путем применения листов/списков доступа на устройстве 3го уровня, ближайшему к абоненту). В частности реализация возможности предоставления доступа к тем или иным услугам в зависимости от баланса абонента, например: положительный баланс - И доступ в Интернет И доступ к локальным ресурсам сети, отрицательный, не превышающий разрешенный кредит/overdraft - только доступ к локальным ресурсам, отрицательный, превышающий разрешенный кредит/overdraft - доступ только к странице с возможностью оплаты услуги.
  • Отказ от VPN-подобного механизма контроля доступа (либо доступ есть, либо нет - RADIUS-ACCEPT|RADIUS-REJECT ответы при наличии сессионного контроля) в пользу 802.1х механизма сессионного контроля, который дает преимущество управления доступом к услуге на уровне 2 ЭМВОС в зависимости от возможностей устройства, например, доступ абонента только в гостевой VLAN (пример коммутаторов производства HP) при задолженности.
  • Контроля сетевой инфраструктуры (online диагностика, представление об утилизации ресурса (наличие свободных портов в тех или иных устройствах и т.п.)).

  •  

Следующая статья отдела маркетинга из открытой серии статей "Актуально на рынке" будет на тему "Все покупается, все продается: а долго ли осталось жить мелким и средним операторам пока их не купили Вымпелкомы и СММы?".

(с) Сетевые решения, 2008




В начало страницы