# Channel Management

## Канал

Под каналом понимается канал типа точка-точка, способный прозрачно пропускать ethernet-фреймы IEEE 802.3 от порта клиента до другого порта клиента или до сервисной границы.

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

Каждый канал имеет собственные характеристики:

* Гарантированный ethernet MTU
* Способность пропускать тегированные пакеты 802.1Q
* Соглашения по QoS по раскраске пакетов 802.1p

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

> Открытые вопросы:
> * Стоит ли жестко замыкаться на ethernet?

## Planes

Канал можно представить как путь, проходящий через различные области, имеющие свои уникальные свойства. Данные области могут являться полными антагонистами друг к другу и не могут пересекаться. Кроме того, их положение относительно друг друга не определено. Так как слово domain в телекоме уже и так перегружено различными смыслами, позаимствуем из эзотерики концепциию plane, или плоскости, сферы, мира, и так далее. В древности люди выделяли 4 стихии: воздух, вода, огонь, земля. Считалось, что каждая стихия населена своими уникальными видами существ и существовали специально обученные маги, разбирающиеся в отдельных сферах.

Анализ предметной области показывает, что для образования каналов
задействуются следующие plane:

* Optic
* Electric
* Radio
* OTN
* VLAN
* VXLAN/EVPN
* MPLS

Основная задача plane -- предоставить путь (trail). Пути, проходящие через разные plane объединяются вместе и образуют канал.
Фактически, каналы сами по себе образуют собсвенный Channel Plane,
который является единой точкой входа для клиентского сигнала.

Внутри каждого plane trail может быть составным и состоять из sub-trail'ов, каждый из которых не выходит за пределы собственного plane. При взгляде со стороны детали реализации каждого trail не имеют особого значения, важен сам факт его существования.


Необходимо отметить, что sub-trail внутри plane не обязан быть атомарным, а может быть разбит на более элементарные пути, подвергаться различным инкапсуляциям, мультиплексироваться и так далее.

При организации внутренних путей отдельные plane могут использовать пути через другие plane.


Optic, Electric и Radio planes являются элементарными, так как они не могут взаимодействовать с другими plane для организации своих внутренних trail.

Существуют следующие топологи trail:

* p2p - точка-точка
* p2mp - дерево
* mp2mp - облако

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

## Planes

### Channel Plane

Уровень каналов. Является самым высоким уровнем, к которому напрямую подключаются клиенты. trail уровня channel plane эквивалентен каналу. Отличается от других plane тем, что не способен самостоятельно передавать данных (нет собственных subtrail), но целиком и полностью использует другие plane для организаци trail.

### Optic Plane

Оптическая сеть. Осуществляет передачу оптического сигнала
по заранее проложенным волокнам оптического кабеля.

Состоит из оптических кабелей, муфт, кроссов, патч-кордов, аттенюаторов и прочего пассивного оборудования. В силу исторических причин оптическая сеть разделяется на single- и multi-mode сегменты, различающиеся по частотным характеристикам и не связанные между собой. Отдельные сегменты оптческого кабеля могут иметь собственные дополнительные ограничения.

Как правило, вся оптика пассивна, изменения топологии осуществляются путем ручной коммутации или разварки волокон.
Редкое исключение - управляемые кроссы.

Таким образом, в большинстве случаев, организация trail через
optic plane не может быть осуществлена автоматически и требует
оформления наряда на выполнение работ. Кроме того, планирование модернизации оптической также является ручной операцией.

@todo: Колодцы?

Optic Plane является элементарным и не может задействовать другие plane для организации trail.

### Electric Plane

Электрическая сеть. Осуществляет передачу энергии и сигнала по заранее проложенным металлическим кабелям. Условно подразделяется на силовую и слаботочную.

Состоит из металлических кабелей, кроссов, патч-кордов, защитных автоматов и прочего пассивного оборудованя. Отдельные сегменты сети могут иметь собственные дополнительные ограничения.

Для изменения топологии требуется ручная перекоммутация. Таким образом, организация trail через electric plane не может быть осуществлена автоматически и требует
оформления наряда на выполнение работ. Кроме того, планирование модернизации оптической также является ручной операцией.

Electric Plane является элементарным и не может задействовать другие plane для организации trail.

### Radio Plane

Радио-эфир. Осуществляет передачу сигнала между антеннами.

@todo: Описать дополнительные характеристики.

Radio Plane является элементарным и не может задействовать другие plane для организации trail.

### OTN

Optical Transport Network. Состоит из актиивного оборудования, которое осуществляет прозрачную транспортировку клиентского сигнала
через оптическую сеть. Фактически, является одной из возможных точек входа и выхода в Optic Plane. Позволяет расширить функционал Optic Plane следующими функциями:

* Оптическое уплотнение - позволяет параллельно передавать несколько оптических сигналов на разных длинах волны по одному волокну
* Прозрачная регенерация, усиление и коррекция дисперсии сигнала - позволяет увеличвать длину линка за пределы возможности лазеров класса 1 (~80км)
* Дополнительный контроль ошибок
* Мультиплексирование - несколько клиентских сигналов могут быть собраны в одну транспортную группу.
* Транспортная защита - автоматическое переключение на резервный маршрут в случае обрыва основного (<50ms). В отличии от MPLS FRR доступно для любого оконечного оборудования и не требует поддержки MPLS.
* Оптическая защита - автоматическое переключение на резервный маршрут на уровне оптического сигнала. Обеспечивает рекордное время переключения (единицы ms) и доступно для любых видов сигнала.

Является иерархической средой, определяемой рекоммендациями ITU-T G.709.

Транспортный уровень - OTU (Optical Transport Unit) определяет модуляцию на уровне оптического сигнала.

| Signal | Marketing data Rate (Gbit/s) | True Signal rate (OTU) (Gbit/s) | Applications |
| --- | --- | --- | --- |
| OTU1 | 2.5 | 2.66 | Transports SONET OC-48 or synchronous digital hierarchy (SDH) STM-16 signal |
| OTU2 | 10 | 10.7| Transports an OC-192, STM-64 or wide area network (WAN) physical layer (PHY) for 10 Gigabit Ethernet (10GBASE-W) |
| OTU2e | 10.5 | 11.1 | Transports a 10 Gigabit Ethernet local area network (LAN) PHY coming from IP/Ethernet switches and routers at full line rate (10.3 Gbit/s). This is specified in G.Sup43. |
| OTU25 | 25 | 26.4 | Transports a 25 Gigabit Ethernet signal |
| OTU3 | 40 | 43 | Transports an OC-768 or STM-256 signal or a 40 Gigabit Ethernet signal. |
| OTU3e1/2 | 41 | 44.5 | develop for transport of 10G LAN PHY, and one for 10G WAN PHY, over SDH and OTN. |
| OTU50 | 50 | 52.8 | Transports a 50 Gigabit Ethernet signal|
| OTU4 | 100| 111.8| Transports a 100 Gigabit Ethernet signal|
| OTUCn | n x 100 | n x 105.2 | n instances of a logically interleaved 100G (C=100) frame format Total bandwidth / ODU size. e.g. 200G Channel support 4xODU3 and 4xODU2 |

OTU обеспечивает транспортировку одного или нескольких контейнеров ODU, несущих клиентский сигнал.

| Signal | Data Rate (Gbit/s) | Typical Applications |
| --- | --- | --- |
| ODU0 | 1.24416 | Transport of a timing transparent transcoded (compressed) 1000BASE-X signal or a stream of packets (such as Ethernet, MPLS or IP) using Generic Framing Procedure |
| ODU1 | 2.49877512605042 | Transport of two ODU0 signals or a STS-48/STM-16 signal or a stream of packets (such as Ethernet, MPLS or IP) using Generic Framing Procedure. |
| ODU2 | 10.0372739240506 | Transport of up to eight ODU0 signals or up to four ODU1 signals or a STS-192/STM-64 signal or a WAN PHY (10GBASE-W) or a stream of packets (such as Ethernet, MPLS or IP) using Generic Framing Procedure |
| ODU2e | 10.3995253164557 | Transport of a 10 Gigabit Ethernet signal or a timing transparent transcoded (compressed) Fibre Channel 10GFC signal |
| ODU3 | 40.3192189830509 | Transport of up to 32 ODU0 signals or up to 16 ODU1 signals or up to four ODU2 signals or a STS-768/STM-256 signal or a timing transparent transcoded 40 Gigabit Ethernet signal or a stream of packets (such as Ethernet, MPLS or IP) using Generic Framing Procedure |
| ODU3e2 | 41.7859685595012 | Transport of up to four ODU2e signals |
| ODU4 | 104.794445814978 | Transport of up to 80 ODU0 signals or up to 40 ODU1 signals or up to ten ODU2 signals or up to two ODU3 signals or a 100 Gigabit Ethernet signal |
| ODUflex (CBR) | 239⁄238 x client bit rate | Transport of a constant bitrate signal such as Fibre Channel 8GFC, InfiniBand or Common Public Radio Interface |
| ODUflex (GFP) | any configured rate | Transport of a stream of packets (such as Ethernet, MPLS or IP) using Generic Framing Procedure |

OTN принимает клиентские сигналы через Optic или Electric Plane,
преобразовывает его в оптические сигналы и использует Optic Plane для передачи.

В отличии от чистого Optic Plane, OTN позволяет конфигурировать топологию на уровне оборудования, таким образом, trail через OTN в большинстве случаев может быть построен автоматически на уровне контроллера OTN.

### VLAN

@todo

### VXLAN/EVPN

@todo

### MPLS

@todo

### Partner

Виртуальный plane для субаренды каналов у партнера

## Plane Controller

Программные сущности, являющиеся оркестраторами для конфигурирования собственных plane. Контроллеры для определенных plane могут взаимодействовать с контроллерами других plane для организации собственных каналов.

В случае необходимости выделения ресурсов для организации trail
Controller может использовать пулы ресурсов.

Контроллер должен поддерживать следующие вызовы:

### Проверка технической возможности
ПТВ, Technical Feasiility Check - проверяет, возможна ли организация trail. Ответ:

* order_id - идентификатор заказа/проекта. Используется для дальнейшей организации trail. Не заполняется при отсутсвии техвозможности
* result - принимает следующе значения:
* Возможно автоматически - канал может быть целиком и полностью организован автоматически и на всех этапах.
* Кроссировка - канал может быть организован, но требуется ручная кроссировка в пределах достижимости порта или кросса (коммутация на кроссе или прокладка кабеля внутри здания)
* Прокладка кабеля - канал может быть организован, но требуется прокладка кабеля по городу. Также может включать кроссировку.
* Установка оборудования - требуется дополнительное оборудование, возможно, в комбинациии с прокладкой кабеля и кроссировкой.
* В проработке - необходимо повторно запросить ПТВ через указанное время
* Нет ресурсов - не хватает определенных ресурсов (например, ODU или VLAN). Возможно, ресурсы освободятся позже по мере снятия бронирования или отключения.
* Нет технической возможности - требуется серьезная модификация сети, которая может быть выполнена только в рамках отдельного бюджета или инвестпроекта.
* check_after - для статуса "В проработке" - через какое минимальное время осуществить повторный ПТВ. Заполняется для всех ответов, кроме "Возможно автоматически" и "Нет технической возможности"
* price - стоимость дополнительных работ. Заполняется для всех ответов, кроме "нет технической возможности"
* details - список деталей для всех вложенных ответов
* order_id - номер задания ПТВ/формирования
* controller - назване контроллера plane (channel, otn, ...)
* parent - для вложенных нарядов - order_id родителя
* status - статус наряда
* description - дополнительное описание
* price - цена
* check_after - повторная проверка

Вызов ПТВ содержит:

* Дескриптор точки входа
* Десткриптор точки выхода
* Ограничения
* Время бронирования ресурсов

При задании времени бронирования ресурсов, существующие ресурсы, необходимые для организации trail, блокируются на заданное время и не рассматриваются при последующих запросах ПТВ.

Plane Controller может осуществлять дополнительные вызовы к другим plane controller. В таком случае:

* check_after - устанавливается в максимальное время среди собственных значений и результатов вложенных ответов.
* price - является суммой своей стоимости и всех стоимостей вложенных ответов.
* result - Самый жесткий между своими и всеми полученными ответами.

### Повторная проверка технической возможности

Осуществляется не ранее, чем через retry_after после предыдущего вызова ПТВ.

Формат запроса:

* order_id - из ответа ПТВ

Формат ответа - идентичен ПТВ.

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

### Формирование trail

После согласования с клиентом запускается фактиический запрос на формирование trail.

Формат запроса:

* order_id

Ответ:

* status:

* Разобран
* В процессе
* Готов
* Сбой

* check_after - время повторной проверки

### Проверка trail

Проверка завершения процесса.

Формат запроса:

* order_id

Ответ:

* status - аналогично старту
* check_after - аналогично старту
* details - список деталей для всех вложенных ответов
* order_id - номер задания ПТВ/формирования
* controller - назване контроллера plane (channel, otn, ...)
* parent - для вложенных нарядов - order_id родителя
* status - статус наряда
* description - дополнительное описание
* price - цена
* check_after - повторная проверка

### Расформирование trail

Разборка существующего trail и освобождение ресурсов:

Формат запроса:

* order_id

Запрос асинхронный и немедленно запускает процесс освобождения ресурсов, который может занять длительное время. Во время разборки trail можно выполнять запрос на проверку trail.

## Модель данных

### Plane

* id
* name - уникальное имя
* description - описание
* enable_p2p - разрешены p2p-трейлы
* enable_p2mp - разрешены p2mp-трейлы
* enable_mp2mp - разрешены mp2mp-трейлы
* protocols - список протоколов, которые пропускает plane.

### Trail

Путь в пределах plane:

* id - идентификатор (он же order_id)
* name - уникальное имя (возможно - автогенерация)
* plane - ссылка на Plane
* parent - id родителя, для вложенных заданий
* n - возрастающий номер в пределах parent
* profile - TrailProfile
* service - Опцииональная привязка к сервису
* labels - метки
* effective_labels - эффективные метки
* project - ссылка на проект
* subscriber - ссылка на абонента
* supplier - ссылка на поставщика
* state - состояние workflow
* remote_system - ссылка на внешнюю систему (внешний оркестратор)
* remote_id - id во внешней системе
* resources - список используемых ресурсов
* model - модель ресурса
* id - id ресурса
* path - дополнительный путь:
* Имя слота для inv.Object
* role - ??? Роль ресурса в trail ???

Прочая информация по trail может лежать в traits.

@todo: Убрать ресурсы и заменить описанием точек входа

### TrailLog

Логгирование событий trail'а, лежит в ClickHouse.

* date - дата (ключ шардирования)
* ts - timestamp
* trail - trail id
* system - инициатор событий
* message - сообщение

### TrailProfile

Групповые настройки trail

* id - идентификатор профиля
* plane - ссылка на Plane
* workflow - ссылка на workflow
* labels - метки
* effective_labels - эффективные метки
* protocols - пропускаемые протоколы

### Link

Для интеграции L2 линков и trail в модель Link добавляется поле:

* trail - ссылка на trail

NB: Возможна ситуация, при которой несколько параллельных линков
представлены одной структурой Link. Так как привязка канала к линку почти всегда делается руками, такие линки следует уточнять до состояния точка-точка и привязывать к свом trail. В таком случае нет необходимости хранить на линке список trail'ов.

### ObjectConnection

Так как на настоящий момент кабельные трассы в inventory не реализованы, предлагается использовать Channel Trail в качестве
подложки для ObjectConnection. Для этого в ObjectConnection необходимо добавить поле:

* trail - ссылка на Channel Trail

При этом, в качестве подложки использовать связки:

* channel trail -> optic trail
* channel trail -> electric trail

### DWDMLambda

Справочник стандартных частот DWDM

* itu_channel - Номер канала
* wavelength - Длинна волны
* frequencey - Частота
* spacing - 25/50/100Ghz

Вопросы:

* Объеднить с CWDM?

### OTUTrail

Ресурс OTN. Представляет собой лямбду между WDM мультиплексорами
с наложенным на нее OTU. Является абстракцией транспорта между мультплексорами.

* id
* connection trail - ссылка на channel tail (cм. ObjectConnection)
* lambda - ссылка на DWDMLambda
* otu - тип верхней группы OTU:
* OTU1
* OTU2
* OTU2e
* ...

Если локальный OTU trail больше не используется, он удаляется.

NB: Порты достаются через связку connection_trail -> object connection

Вопросы:

* OTUCn ложится на одну лямбду?

### ODUSelector

Контейнеры ODU могут группировать контейнеры меньшего размера, как показано на схеме:


Для задач мультиплексирования необходимо иметь возможность адресовать
конкретный контейнер в общей иерархии. Для этого вводится структура ODUSelector:

* Массив объектов:
* odu - тип ODU
* n - порядковый номер в пределах родителя, zero based

Контейнер верхнего уровня иерархии


адресуется как `[("ODU2", 0)]`

Вложенный контейнер


адресуется через всех родителей: `[("ODU2", 0), ("ODU1", 1)]`

Более глубокие уровни


иерархии адресуются аналогично: `[("ODU2", 0), ("ODU1", 1), ("ODU0", 1)]`

### ODUMux

OTN-specific. Мультиплексирование ODU в пределах платы:

* op - код операции
* add - добавление из клиентского порта в линейный
* drop - сброс из линейного порта в линейный
* transit - транзит из линейного порта в линейный
* object - ссылка на карту
* ingress_trail - входной OTUTrail (drop, transit)
* ingress_odu_selector - ODUSelector для ingress (drop, transit)
* egress_pri_trail - выходной (OTUTrail), основной порт (add, trainsit)
* egress_pri_selector - ODUSelector для egress primary (add, transit)
* egress_back_trail - выходной (OTUTrail), backup порт (add, trainsit)
* egress_back_selector - ODUSelector для egress backup (add, transit)
* client_slot - имя слота для клиенского порта (add, drop)
* client_odu_selector - ODUSelector для клиентского порта (add, drop)

Матрица заполнения полей, в зависимости от операци

| Поле | Add | Add, Protect | Drop | Transit | Transit, Protect |
| --- | --- | --- | --- | --- | --- |
| op | add | add | drop | transit | transit |
| object | + | + | + | + | + |
| ingress_trail | | | + | + | + |
| ingress_odu_selector | | | + | + | + |
| egress_pri_trail | + | + | | + | + |
| egress_pri_selector | + | + | | + | + |
| egress_back_trail | | + | | | + |
| egress_back_selector | | + | | | + |
| client_slot | + | + | + | | |
| client_odu_selector | + | + | + | | |

NB: Замыкане резерва на drop и transit задается как 2 записи,
замыкающие основной и резервный путь на один и тот же ODUSelector

Для каждого Object верны ограничения:

* Может быть не более 1 правила add для клентского порта
* Может быть не более 1 правила transit для ingress trail
* ...

#### Add


{
    "op": "add",
    "object": "XXX",
    "egress_pri_trail": "<OTUTrail #3>",
    "egress_pri_selector": [("ODU0", 0), ("ODU1", 1)],
    "client_slot": "Client",
    "client_odu_selector": [("ODU0", 0)]
}

#### Add + Protect


{
    "op": "add",
    "object": "XXX",
    "egress_pri_trail": "<OTUTrail #3>",
    "egress_pri_selector": [("ODU0", 0), ("ODU1", 1)],
    "egress_back_trail": "<OTUTrail #4>",
    "egress_back_selector": [("ODU0", 0), ("ODU1", 1)],
    "client_slot": "Client",
    "client_odu_selector": [("ODU0", 0)]
}

#### Transit


{
    "op": "transit",
    "object": "XXX",
    "ingress_pri_trail": "<OTUTrail #1>",
    "ingress_pri_selector": [("ODU0", 0)],
    "egress_pri_trail": "<OTUTrail #3>",
    "egress_pri_selector": [("ODU0", 0)],
}

#### Transit + Protect


{
    "op": "transit",
    "object": "XXX",
    "ingress_pri_trail": "<OTUTrail #1>",
    "ingress_pri_selector": [("ODU0", 0)],
    "egress_pri_trail": "<OTUTrail #3>",
    "egress_pri_selector": [("ODU0", 0)],
    "egress_back_trail": "<OTUTrail #4>",
    "egress_back_selector": [("ODU0", 0)],    
}

#### Drop


{
    "op": "drop",
    "object": "XXX",
    "ingress_pri_trail": "<OTUTrail #1>",
    "ingress_pri_selector": [("ODU1", 0), ("ODU0", 1)],
    "client_slot": "Client",
    "client_odu_selector": [("ODU0", 0)]
}

## OTN Plane Specific

### Inventory Protocols

В протоколы inventory необходимо добавить стандартные частотные сетки DWDM:

* `DWDM-100Ghz-<N>` - где `<N>` - номер канала, от 1 до 72
* `DWDM-50Ghz-<N>` - где `<N>` - номера каналов от 1 до 72 с шагом 0.5

По общей конвенции, DWDM порты, выдающие сигнал, размечаются префиксом `<`, принимающие - `>`. Протоколы размечаются на внутренних line портах.

Доступные DWDM-каналы на оптическом линке ограничиваются пересечениием множеств протоколов на принимаемых и передающих портах с обоих концов.

Также в протоколы необходимо добавить поддерживаемые типы OTU:

* OTU1
* OTU2
* OTU2e
* OTU25
* OTU3
* OTU50
* OTU4
* OTUC1
* OTUC2
* ...

Точно так же, принмающие порты выдающие сигнал, размечаются префиксом `<`, принимающие - `>`. Протоколы размечаются на внутренних line портах. Доступные DWDM-каналы на оптическом линке ограничиваются пересечениием множеств протоколов на принимаемых и передающих портах с обоих концов.

Для разметки поддерживаемых типов ODU на клиентских портах вводятся протоколы:

* ODU0
* ODU1
* ODU2e
* ODU3
* ODU4

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

Прмер описания линейного порта в inventory

"connnections": [
    {
        "name": "line1.1",
        "direction": "s",
        "gender": "f",
        "description": "Line Port"
        "protocols": ["<OTU1", "<OTU2", "<DWDM-100Ghz-1", "<DWDM-100Ghz-2"]
    },
    
    {
        "name": "client1",
        "direction": "s",
        "gender": "f",
        "description": "Line Port"
        "protocols": ["ODU0", "ODU2e", "TransEth1G", "TransEth10G"]       
    }
]

См. [документацию по Inventory Protocols](https://docs.getnoc.com/master/en/dev/reference/inventory-protocols/) для уточнения деталей.

!!! Вопрос для обсуждения по названиям протоколов частотной сетки.

### OTN Trail

Путь через OTN Plane задается входным и выходным клиентскими портами

## Интеграция с FM

Логику корреляции аварии Link Down следует доработать. В случае падения порта, принадлежащего линку, неоходимо проверять, задана ли привязка к trail. В случае наличия аварии на любом компоненте trail необходимо провести корреляцию Link Down с соответсвующей аварией.
То же самое верно и в обратном направлении - при поднятии аварии на любом компоненте trail необходимо подшивать существующие Link Down.

@todo: Для сработавшей защиты линка необходимо проверять наличие резерва