Реализовать функцию "всестороннего резервирования"

[alx]

Реализовать функцию "всестороннего резервирования" (выбора направления групповых каналов) и формирования констант в незанятые канальные интервалы

[alx]

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

[san]

Этот тикет о "Канальном резервировании" которое недавно было реализовано? пора закрыть тикет или это что-то другое?

[alx]

Это что-то другое. Это что-то типа STP, только для телефонных каналов. :) Подробнее может рассказать Толя. Пока эта тема "заглохла" на этапе постановки задачи.

[san]

Толя, проясни пожалуйста?

[anatoly]

Это и есть то самое пресловутое канальное резервирование. Уже реализовано.

[alx]

Replying to anatoly:

Уже реализовано.

Как? Когда? Кем? Я ни строчки кода для реализации этой фичи не написал, все ограничилось парой обсуждений за столом в пищеблоке...

[alx]

Кстати, а что такое это "канальное резервирование", о котором вы оба говорите? Может я что-то неправильно понял?

Насколько я помню, суть функции "всестороннее резервирование" в следующем. Организуется сеть (групповых) каналов с избыточным числом путей. Через тракты, по которым эти каналы проходят, должны периодически передаваться специальные сообщения с информацией о состоянии каналов (рабочий или в аварии). На основании этой информации узлы сети блокируют избыточные пути, отключая лишние суммирования - подобно тому как STP блокирует избыточные линки ethernet...

[san]

Ну, да, "канальное резервирование", это то что ты описал, только вместо отключения суммирования в слагаемое передаётся константа.

Вот описание: ​https://docs.google.com/document/d/1FKFho2XiKoE8_ee2pSlaZwnfu6rITeIi1knrxQh8BnE/edit

[alx]

Replying to san:

Ну, да, "канальное резервирование", это то что ты описал, только вместо отключения суммирования в слагаемое передаётся константа.

Хорошо. Но где, в таком случае, обмен сообщениями, на основании которых строится дерево (точнее, наоборот, "обрезаются" лишние связи)? В текущем коде, насколько я знаю, ничего такого нет...

Вот описание: ​https://docs.google.com/document/d/1FKFho2XiKoE8_ee2pSlaZwnfu6rITeIi1knrxQh8BnE/edit

Гугл говорит, что у меня нет прав доступа к этому документу.

[anatoly]

Обмен сообщениями, на основании которых строится дерево - это передача бита целостности тракта.

[san]

Гугл говорит, что у меня нет прав доступа к этому документу.

Прости, забыл открыть. Открыл.

[alx]

Replying to san:

Гугл говорит, что у меня нет прав доступа к этому документу.

Прости, забыл открыть. Открыл.

Спасибо, теперь документ открылся.

Replying to anatoly:

Обмен сообщениями, на основании которых строится дерево - это передача бита целостности тракта.

Хм... Из соображений общего характера напрашивается вывод, что одного бита для этого недостаточно. С помощью одного бита узел сети может получить лишь одно из двух состояний: либо данные достоверны, либо не достоверны. Этот бит привязан к тракту. Но в одном и том же тракте может передаваться много разных каналов, при этом часть из них могут быть достоверны, часть - нет (разные каналы могут иметь разную топологию сети)... Если бы резервировались целиком тракты (например, E1), а не отдельные каналы, это было бы еще понятно, но у нас-то резервируются именно каналы! Логика подсказывает, что для реализации резервирования каналов необходимо передавать состояние каждого канала в отдельности, и одного бита на тракт для этого явно недостаточно...

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

Как реализуется логика блокировки, если узел получает канал не с двух, а хотя бы с трех направлений? Если я ничего не путаю, в этом случае для блокировки, как минимум, одного из направлений необходимо учитывать два других направления сразу... Разве у нас сейчас существует возможность реализации такой логики?

Не говоря уже о случаях типа такого:

[san]

Толя, похоже, не хочет отвечать на вопросы :)

Алексей, может быть у тебя есть какие-то соображения/предложения по поводу реализации "настоящего" канального резервирования?

[alx]

Не совсем понятно, какие именно соображения тебя интересуют. То, что я, например, написал в comment:13, разве не соогбражения?

[san]

В коменте больше критика Толиного варианта :)
Может, быть у тебя есть соображения как реализовать полноценную схему резервирования? где/как передавать служебную информациию, и т.д.

p.s. Заказчикам(МВтел) Толин вариант тоже не понравился, но по другим причинам - топология "простое кольцо" их устраивает, но не нравится значительная сложность настройки и необходимость использовать большое кол-во групповых каналов, по расчётам их даже не всегда хватает для резервирования всех нужных каналов.

[alx]

Replying to san:

В коменте больше критика Толиного варианта :)

Критика - это тоже мои соображения! :)

Может, быть у тебя есть соображения как реализовать полноценную схему резервирования? где/как передавать служебную информациию, и т.д.

Только в самых общих чертах - насколько мы это обсуждали с Толей и Алексеем. Мне видится, что здесь должен применяться алгоритм типа Spanning Tree (можно было бы взять его за основу). В результате работы этого алгоритма топология "сеть" преобразуется в топологию "дерево" путем искусственных "разрывов" избыточных путей.

Для работы такого алгоритма требуется обмен сообщениями между узлами сети, посредством которых один узел (блок 3U) сообщает другому о том, какие каналы в тракте достоверны, а какие - нет. Как/где передавать это сообщение, зависит от типа линейного тракта: если это, например, E1, можно использовать национальные биты, если это RTP-поток платы VE-01, можно передавать пакеты NTE, если это DSL - я не знаю...

Вот такие соображения...

p.s. Заказчикам(МВтел) ... не нравится значительная сложность настройки

Вот это уже более конкретно. Давай рассмотрим настройку на конкретных примерах, может можно упростить процесс...

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

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