Теперь интересен смысл их работы. Тоесть как должно идти? как должен выглядеть тарифный план если у человека допустим 64 кб а он на час хочет активировать опцию на 1500 кб?

Задача у нас изначально стоит такая: У клиента есть базовый тарифный план, мы продаем ему некую услугу в качестве дополнения к основному тарифному плану. В нашем случае - локальный трафик с определенной скоростью за определенную абонентскую плату. Т.е. нужно не просто добавить клиенту соответствующую абонплату в договор, но и выдать дополнительные radius-атрибуты. Для реализации подобного придется создавать дублирующие тарифные планы с небольшими изменениями, либо писать скрипты, модифицирующие Radius-атрибуты при их выдаче в зависимости от наличия абонплаты и/или тарифного плана-"пустышки". Сейчас появляется концепция тарифных опций, но это не совсем то - тарифные опции предполагают разовый бустер на x часов через расход, а не абонплату.

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

Общие идеи:
- Модификаторы вешаются на договор с определенным периодом.
- Для избежания конфликтов и разночтений ввести позиции, задающие приоритет (аналогично тарифным планам).
- default-модификатор, работающий всегда либо когда не найдено других. Первое кажется проще и логичнее - при необходимости значения переопределяются в узлах других модификаторов. Видимо по такой схеме сейчас сделаны опции (см второй узел опций):


- [опционально] Модификаторы с параметрами. Параметры подставляются в значения узлов договора. Скажем, цена=100*$1 - значит, берем $1 - первый параметр текущего (при обходе дерева) модификатора. Параметры обязательно должны иметь значения по умолчанию. Т.е. нужно будет прогонять все mtree_node.data через специальный eval, делающий подстановки и, возможно, производящий арифметические действия. Конечно слишком круто для реализации, но предоставляет широкие возможности для индивидуальной кастомизации тарифов.

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

ps. Дилера не сдам

может тут стоит опцию "Драйв" и зону turbo приподнять выше зоны normal, а то ведь дерево по порядку просматривается?

Даже если и поднять, разница то какая? он скорость вообще не ограничивает!! ладно бы если скорость резалась не так как надо. А вообще я попробовал поднять. Ситуация не изменилась.
А тут как должно быть? Как изначально режется скорость? не опциями же

Опции просто передаются в тариф как условие. В зависимости от включенных опций срабатывает тот или иной узел "Опция" тарифного плана. А внутри него уже срабатывает уже "Набор ограничений". Вы выложите скрин вашего тарифа, который не режет.

CoA это Change of Authorization - расширение RADIUS, позволяющее динамически, без разрыва соединения менять некоторые его параметры. Очень удобно, и тогда все будет действительно "без единого разрыва"