# Channel Management v2

## Канал

С точки зрения клиента, канал состоит из 2 или более точек подключения, между которыми прозрачно осуществляеся передача клиентских данных с зараннее определеннымии SLA.

Под "прозрачностью" понимается способность сохранять оригинальные клиентские фреймы на выходе из канала. Исторически, каналы делятся на три основных категории:

* **Темная оптика/прямой провод**: обеспечивает прозрачную передачу оптического сигнала между точками подключения. Тип передаваемых данных, модуляция и скорость передачи полностью задается и контролируется оборудованием клиента.
* **L2**: Обеспечивает прозрачную передачу ethernet-фреймов IEEE 802.3. В зависимости от типа канала, на каждой точке подключения фреймы могут быть нетегированными, иметь тег 802.1Q, или иметь вложенные теги (Q-in-Q, MAC-in-MAC). Скорость и тип сигнала согласовывается между клиентом и оператором для каждой точки подключения. Передача клиентской маркировки 802.1p не гарантируется, если не оговорено заранее. MTU оговаривается заранее. Передача multicast оговаривается заранее.
* **L3**. Обеспечивает передачу IPv4 и/или IPv6 пакетов. В зависимости от типа может поддерживать или не поддерживать динамическую маршрутизацию. Скорость и тип сигнала для каждой точки подключения оговаривается заранее. MTU оговаривается заранее. Передача multicast оговаривается заранее.

Топологически каналы делятся на четыре основные категории:

* **Точка-точка** (p2p) - две точки подключения
* **Точка-многоточка** (p2mp) - одна точка подключения с репликацией сигнала на все выходы
* **Дерево** (tree) - обеспечивается передача сигнала от корня дерева ко всем листья и в обратном направлении. Прямая передача сигнала между листьями запрещена
* **Звезда** (star) - разрешена передача сигнала между всеми узлами

Таким образом с точки зрения клиента прослеживаются две сущности:

* Канал
* Точка подключения

И должны обеспечиваться следующие операции:

* Проверка технической возможности (изначальная)
* Проверка технической возможности (доп. подключение, если разрешено типом канала)
* Создание канала
* Расформирование канала
* Добавление точки подключения (если разрешено типом канала)
* Удаление точки подключения (при 3 и более точках)
* Получение карты

> NB: Внутренняя реализация канала с точки зрения клиента является черным ящиком и имеет право эволюционировать со временем.

## Технологическе домены

На настоящий момент сущесвует несколько технологий организации канала:

* **Оптическая сеть**: Совокупность оптического кабеля, муфт, кроссов и патч-кордов.
* **Медная сеть**: Совокупность медного кабеля, кроссов и патч-кордов.
* **VLAN**: Пространство ethernet-коммутации, основанное на mac-address learning
* **GRE**: Инкапсуляция IP-пакетов
* **VXLAN/EVPN**: Инкапсуляция ethernet-фреймов в UDP в комбинации с mac address learning
* **MPLS**: Универсальный транспорт L2.5, с возможностью организации L2 и L3 каналов.
* **OTN**: Оптическая транспортная сеть уровня L1 с возможностью передавать ethernet-фреймы. Поддерживает оптическое мультиплексирование.
* **SDH**: Предшественник OTN, на настоящий момент мало интересен.
* **Прочее**: @todo: Дополнить по необходимости.

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

Технологии разбивают сеть оператора на взаимнонепересекающиеся области, называющиеся **технологическими доменами** или просто **доменами**.

Таким образом, на сети могут существовать технологические домены:

* optic
* copper
* vlan
* vxlan/evpn
* mpls
* otn

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

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

С этой точки зрения - домены являются внуренними микро-операторами или субподрядчиками для организации канала.

> Уровень каналов в общем случае не является доменом, так как не всегда соблюдается условие технологического единства.

### Специальные домены

Домен *partner* позволяет реализовывать каналы через субподрядчиков-партнеров.

## Простые и составные каналы

Если все точки подключения канала находятся в пределах одного
домена, канал называется **простым**, в противном случае - **составным**.

Пример простого канала:

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

Составные каналы образовываются путем соединения нескольких простых каналов. Рассмотрим схему:


* Левая точка подключения соединяется с MPLS-ядром медным кабелем.
* Средняя - оптическиим.
* Подключене правой точки - комплексное, сначала протягвается оптика до существующей сети доступа, по которой пробрасывается VLAN. Далее - между сетью доступа и MPLS-ядром организуется дополниельнаяя оптическая перемычка. В отдельных случаях она может быть переиспользована для нескольких каналов.

Итого, для организации канала потребовалось 6 внутренних простых каналов:

* Домен optic: 3 канала
* Домен copper: 1 канал
* Домен mpls: 1 канал
* Домен vlan: 1 канал

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

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

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

## Жизненный цикл каналов и контроллеры

Программная сущность, реализующая API канала называется *контроллер*. За взаимодействие с внешним миром отвечает *channel controller*. Он занимается оркестрацией верхнего уровня, принимает решение о топологии канала и задействовании соответсвующих доменов
и распределяет задачи для соответсвующих контроллеров доменов.


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

Простейший контроллер представляет собой workflow, обрабатываемый вручную.

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

### TransportDomain

Транспортный домен. Задает сущесвующие домены и их ограничения.

* id
* name - уникальное имя
* description - описание
* controller - текущий handler контроллера, порожден от BaseController
* pass_l1 - пропуск фреймов L1
* pass_l2 - ... L2
* pass_l3 - ... L3
* topo_p2p - поддержка топологии точка-точка
* topo_p2mp - ... точка-многоточка
* topo_tree - ... дерево
* topo_start - ... звезда
* is_homogenous - все точки подключения канала должны иметь одинаковую скорость подключения и модуляцию
* labels - метки

Заполняется из коллекций.

### Channel

Канал

* id
* name - уникальное имя
* description - описание
* parent - для служебных каналов - ссылка на составной канал
* transport_domain - для простых каналов - ссылка на TransportDomain
* provider - организация-поставщик канала, если приобретается у другого юрлица
* subscriber - абонент, если канал заказан абонентом. Для служебных каналов всегда пустой
* project - ссылка на проект
* topology - топология
* p2p
* p2mp
* tree
* star
* kind - тип канала
* l1
* l2
* l3
* labels - метки
* effective_labels - полный набор эффективных меток
* remote_system - ссылка на внешнюю систему при импорте
* remote_id - id во внешней системе

Правила перетока меток:

graph LR
    TransportDomain --expose_channel--> Channel

Вопросы:

* Автогенерация уникального имени.
* workflow/state
* Дополнительные аттрибуты - traits
* Пропуск специфичный фреймов: multicast, lldp, cdp, stp, ...

### Channel Log

Логгирование всей истории изменениий на канале. Хранится в ClickHouse.

* date
* ts - timestamp
* channel - id Channel
* endpoint - id endpoint, если событие привязано к endpoint
* domain - соответсвующй transport domain
* user - имя пользователя, если есть
* type - тип сообщения
* msg - сообщение

### Endpoint

Точки подключения

* id
* channel - ссылка на канал
* peer - ссылка на endpoint:
* Если endpoint служебного и композитного канала совпадают
* Если происходит стык служебных каналов
* name - уникальное имя в пределах канала
* description
* connections - список физических подключении. Для обычных подключений - строго одно значение, для аггрегированых > 1
* object - ссылка на объект inventory
* slot - ссылка на слот объекта
* discriminator - Опциональный дискриминатор
* labels - метки
* effective_labels - полный набор эффективных меток
* remote_system - ссылка на внешнюю систему при импорте
* remote_id - id во внешней системе

Правила перетока меток:

graph LR
    Channel --expose_endpoint--> Endpoint
    TransportDomain --> Channel
    Workflow --> State
    State --expose_endpoint--> Endpoint

Вопросы:

* Дополнительные аттрибуты - в traits
* Поддержка LACP

#### Discriminator

Необходимо учитывать, что одна точка подключения может быть переиспользована для организации нескольких каналов. Простейший пример - подключение транковым портом, когда каждому каналу, получаемому из порта, соответсвует отдельный номер VLAN. На один endpoint может быть задано несколько дискримнаторов.

Допускается использование комбнации object + slot в нескольких
endpoint при условии, что они имеют непересекающиеся дискрмнаторы.

Формат дискриминатора:

class Item(BaseModel):
    scope: str
    value: str

Discriminator: List[Item]

Форматы дискриминаторов:

| Scope | Value | Описание |
| --- | --- | --- |
| `vlan` | `<vlan id>` | Фреймы 802.1Q с VLAN ID `<vlan id>` |
| `lambda` | `<freq>-<width>` | Центральная частота `<freq>` Ghz, ширина канала `<width>` Ghz |

### Пример


Channel:

| id | name | parent | transport_domain | topology | kind |
| --- | --- | --- | --- | --- | --- |
| ch1 | Channel | | | star | l3 |
| ch2 | copper-1 | ch1 | copper | p2p | l1 |
| ch3 | optic-1 | ch1 | optic | p2p | l1 |
| ch4 | optic-2 | ch1 | optic | p2p | l1 |
| ch5 | optic-3 | ch1 | optic | p2p | l1 |
| ch6 | mpls-1 | ch1 | mpls | star | l3 |
| ch7 | vlan-1 | ch1 | vlan | star | l2 |

Endpoint

| id | channel | name | peer |
| --- | --- | --- | --- |
| ep1 | ch1 | left | ep4 |
| ep2 | ch1 | center | ep6 |
| ep3 | ch1 | right | ep8 |
| ep4 | ch2 | 1 | ep1 |
| ep5 | ch2 | 2 | ep12 |
| ep6 | ch3 | 1 | ep2 |
| ep7 | ch3 | 2 | ep13 |
| ep8 | ch4 | 1 | ep3 |
| ep9 | ch4 | 2 | ep15 |
| ep10 | ch5 | 1 | ep16 |
| ep11 | ch5 | 2 | ep14 |
| ep12 | ch6 | 1 | ep5 |
| ep13 | ch6 | 2 | ep7 |
| ep14 | ch6 | 3 | ep11 |
| ep15 | ch7 | 1 | ep9 |
| ep16 | ch7 | 2 | ep10 |

## Optic Domain

Оптическая сеть состоит из:

* Оптческих кабелей, состоящих из нескольких волокон.
* Оптических муфт, соединяющих два или более кабеля физически.
* Оптических кроссов, на которых кабель терминируется на стандартные оптические разъемы: LC, SC, ST ...
* Оптических патч-кордов - специального вида кабеля с разделанными на торцах вилками для оптических разъемов.
* ROADM - программируемые коммутаторы оптического сигнала

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

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

Способы изменения топологии оптической сети:

* Переконфигурация ROADM
* Прямой патч-корд между точками подключения
* Подключение патч-корда к кроссу
* Коммутация патч-кордом на кроссе
* Прокладка кабеля по зданию
* Прокладка кабеля по городу
* Установка кросса
* Разварка волокон в муфте
* Разрез кабеля и установка новой муфты

Методы различаются как по времении реализации и трудоемкости, так и по оценке реалиизуемости.

| Метод | Авто. ПТВ[^1] |
| --- | --- |
| Переконфигурация ROADM | + |
| Прямой патч-корд между точками подключения | + |
| Подключение патч-корда к кроссу | + |
| Коммутация патч-кордом на кроссе | + |
| Прокладка кабеля по зданию | - |
| Прокладка кабеля по городу | - |
| Установка кросса | - |
| Разварка волокон в муфте | + |
| Разрез кабеля и установка новой муфты | - |

Необходимо отметить, что в случае наличя ROADM топология оптической сети задается не только физической коммутацией, но и зависит от входящей длины волны. В таком случае endpoint оптческого канала должен меть discriminator `lambda`.

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

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

* Стойка
* Ряд стоек
* Комната
* Этаж
* Подъезд
* Здание
* Точка присутсвия

Все упомянутые сущности являются объектами inventory, соответсвено тип ресурсных групп один:

Технология: optic_cross_coverage
server model: inv.Object
client model: inv.Object

Алгоритм нахождения возможных кроссов для подключения прост:

* Находим все resource group для текущего контейнера точкии подключения: technology == optic_cross_coverage, client_model == container
* Если записи найдены - получаем кроссы из server model
* Проверяем, есть ли на кроссе свободные порты
* В противном случае поднимаемся к родителю текущего контейнера и повторяем поиск
* При выходе за пределы точки присутсвия останавливаемся

Таким образом осуществляется приоретизация кроссов - кросс с более детальным покрытием возьмет заявки первым.

### ROADM

ROADM является программируемым оптческим коммутатором, перенаправляющим определенные длины волны с входного порта на выходной.


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

#### ROADMux

Таблица коммутациии ROADM:

* `object` - ссылка на карту
* `ingress_slot` - входной порт
* `egress_slot` - выходной порт
* `freq` - центральная частота, Ghz
* `width` - шиирна канала, Ghz

Приимечания:

* Если `freq` и `width` пустые, то ROADM работает в режиме опттческого кросса и просто замыкает вход и выход
* Может быть задано несколько правил на один входной порт

## Copper Domain

## OTN Domain

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

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

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

OTN принимает клиенские сигналы по электрическому или медному кабелю, следовательно каналы OTN Domain всегда состыковываются с каналами Optic или Copper Domain.

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

### Частотная сетка

OTN позволяет передачу нескольких сигналов по одному оптическому волокну используя разные длинны волны. Стандарты ITU определяют несколько частотных сеток:

* ITU-T G.694.1 определяет сетки DWDM с шагом 12.5Ghz, 25Ghz, 50Ghz и 100Ghz в диапазонах
* ITU-T G.694.2 определяет сетку из 18 частот для нужд CWDM

Помимо фиксированной сетки G.694.1 Appendix 1 упоминает Flexible Grid с возможностью в рамках одной частотной сетки использовать разные ширины каналов.

Таким образом частотная сетка определяется центральной частотой $f$ и шириной канала $w$. Допускается использование частот 190-198THz с шагом 6.25GHz и ширин каналов от 50 до 100Ghz с шагом 12.5Ghz. То есть:

$$
\begin{cases}
f_i = 190000 + 6.25 i, i \in [0, 1280] \\
w = 50 + 12.5 j, j \in [0, 4]
\end{cases}
$$

### OTU

Транспортный уровень - 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 передается на одной из фиксрованных длин волны (лямбда). В пределах одного волокна на разных длинах волны могут передаваться несколько OTU.

### ODU

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 |

### ADM

С точки зрения топологии OTN основным действующим элементом является add-drop multiplexer (ADM). ADM обычно представляет собой отдельную плату, которая осуществляет упаковку клиентского сигнала в ODU соотвествующего уровня и группировку ODU в OTU.


OTU передаются по оптическому волокну каждый на своей длине волны.
Необходимо отметить, что в отдельных случаях ADM могут быть соединены оптическим волокном напрямую, но в большинстве случаев по пути расположены дополнительные устройства - усилители, интерливеры.

Топология OTN задается оптическиимии каналами, проложенными между картами ADM. Данные каналы относяятся к optic domain и называются `OCh`. Возможны два сценария прокладки `OCh`:

* Между муультплексорами нет ROADM - в таком случае между муультплексорами прокладывается одн OCh
* В случае наличя ROADM порт мультплексора может соединяться с несколькими OCh, в таком случае OCh должны разделяться между собой дискриминаторами `lambda`. См. разделы [ROADM](#ROADM) и [Discriminator](#Discriminator)

> NB: Модель канала соединяет между собой endpoint'ы в виде слотов на оборудовании - у нас есть все данные для формирования топологии OTN.

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

#### Inventory Protocols

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

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

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

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

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

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

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

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

* ODU0
* ODU1
* ODU2e
* ODU3
* ODU4

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

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

Вопрос:

* Названия протоколов частотной сетки.

#### Платы ADM

Платы ADM моделирууются как обычные слоты в inventory. На линейных портах размечаются доступные протоколы DWDM и OTU. На клиенских - доступные типы контейнеров ADU. Топология OTN описывает в виде WDM-каналов, связывающих соотвествующие порты ADM,

Прмер описания линейного и клиентского порта в 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"]       
    }
]

Вопросы:

* Прочие ограничения плат?

#### OTU

Описывает OTU на конкретной длинне волны между ADM.

* channel - ссылка на OCh
* freq - центральная частота, GHz (см. частотная сетка)
* width - ширина канала, GHz (см. частотная сетка)
* otu - тип OTU.

> NB: Соединяемые устройсва и порты мы получим через endpoint'ы channel. Направление получим из протоколов модели.
> В случае ROADM для определения топологии также необходмо анализировать дискриминаторы

#### ODUSelector

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


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

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

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


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

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


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

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


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

ODUSelector не является самостоятельной таблицей, а представляет формат поля структуры ODUMux

#### ODUMux

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

* op - код операции
* add - добавление из клиентского порта в линейный
* drop - сброс из линейного порта в линейный
* transit - транзит из линейного порта в линейный
* object - ссылка на карту ADM
* ingress_otu - входной OTU (drop, transit)
* ingress_odu_selector - ODUSelector для ingress (drop, transit)
* egress_pri_otu - выходной (OTU), основной порт (add, trainsit)
* egress_pri_selector - ODUSelector для egress primary (add, transit)
* egress_back_otu- выходной (OTU), 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_otu | | | + | + | + |
| ingress_odu_selector | | | + | + | + |
| egress_pri_otu | + | + | | + | + |
| egress_pri_selector | + | + | | + | + |
| egress_back_otu | | + | | | + |
| 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_otu": "<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_otu": "<OTUTrail #3>",
    "egress_pri_selector": [("ODU0", 0), ("ODU1", 1)],
    "egress_back_otu": "<OTUTrail #4>",
    "egress_back_selector": [("ODU0", 0), ("ODU1", 1)],
    "client_slot": "Client",
    "client_odu_selector": [("ODU0", 0)]
}

##### Transit


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

##### Transit + Protect


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

##### Drop


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

#### OTN Channel

Клиентский канал, проложенный через OTN моделируется как
обычный канал, связывающий два клиенский порта на ADM.

При этом - тип ODU мы получаем из записей ODUMux типа add и drop,
а полную топологию основного и резервного направления - из топологии ADM и записей типа transit в ODUMux.

Каналы OTN устанавлвают Channel.transport_domain == "otn".

#### Ограничения

* Частоты не должны пересекаться: $Для\ порта\ с частотной\ сеткой\ <f_n, w_n > \nexists i, j: i \neq j, \lvert f_i - f_j\rvert < \frac{\lvert w_i + w_j \rvert}{2}$

## Заметки на полях

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

## Изменения

### Review 003

* Дискриминаторы - список значений
* Дискриминатор `lambda`
* В описание оптческого домена добавлен ROADM.
* Структура ROADMux
* Переписана глава "Частотная сетка" с учетом Flexible Grid
* Удалена структура OTNLambda
* В структуре OTU добавлены поля freq и width
* В разделе ADM описан случай множественных каналов с использованиием ROADM.

### Review 002

* Изменена формулировка простого канала
* Исправлена картинка иерархии конроллеров
* В модели channel исправлено определение `parent`
* Endpoint в модели данных може быть аггрегированным
* Начальное описание Optical Domain
* Начальное описание OTN

## Задачи

* ChannelTask
* Сценарий, когда оборудование устанавливаеся в процессе подключения - endpoint в воздухе
* Очереди строительства
* Контроллер - корреляция

## Возражения

* Есть устройства, которые реализуют резервное переключение на уровне оптических каналов.

* Ну и нужно понимать, что каналы мультиплексируются, т.е. где-то мы работаем с групповым сигналом, а где-то с отдельными OTN каналами.

* Например, мы можем мультиплексировать 40 каналов в групповой сигнал, а потом через устройства ROADM доставлять определенные каналы в разные части сети.

---
WARNING: old trash below

Разгрести

### Свойсва доменов

Ограничения по типу каналов

| Домен | Темная оптика | Прямой провод | L2 | L3 |
| --- | --- | --- | --- | --- |
| Optic | + | - | - | - |
| Copper | - | + | - | - |
| VLAN | - | - | + | - |
| VXLAN/EVPN | - | - | + | - |
| MPLS | - | - | + | + |
| OTN | - | - | + | - |

Ограничения по типу топологии

| Домен | p2p | p2mp | tree | star |
| --- | --- | --- | --- | --- |
| Optic | + | +[^5] | - | - |
| Copper | + | - | - | - |
| VLAN | + | - | - | + |
| VXLAN/EVPN | + | - | - | + |
| MPLS | + | + | + | + |
| OTN | + | - | - | - |

Прочее

| Домен | Конфигурируем |
| --- | --- |
| Optic | - |
| Copper | - |
| VLAN | + |
| VXLAN/EVPN | + |
| MPLS | + |
| OTN | + |

[^1]: Автоматизированная проверка технической возможности
[^5]: Со сплиттерами