SONET нравится
https://computer.rip/2020-10-02%20so%20net.html
https://en.wikipedia.org/wiki/SONET
Хотел было написать какой SONET/SDH милый (so net):
81c7c6557af89e79e480b21f12a4ea97c01679cb, но это не по английски.
Только спустя несколько дней после прочтения статьи с computer.rip, до
меня дошло почему SONET так устроен и как это красиво! По сути во всех
статьях всё одно и то же написано что и тут, но иногда нужно немного
другими словами преподнести и оно раскроет тебе глаза. Уже давным давно
в мире телекоммуникаций параллельно рулили два мира: телефонистов и
компьютерщиков. Изначально последним конечно приходилось жить в мире
телефонов и их сетей, но сейчас победили компьютерщики и в LTE и 5G
используются и IPv6 несущие голос (а не как в GSM и прочих сетях: каналы
заточенные под голос передают, как уж получится, данные) и HTTP/2 вместо
SCTP придуманного телефонистами. Поэтому и SONET уже можно отнести к
истории. Но своим компьютерным умом я не мог сразу понять почему он так
устроен.
Цифровые АТС, само собой, передают звук оцифрованным. А с ISDN и сразу
из дома он идёт уже в цифре. Для хорошей по чёткости передачи речи
достаточно акустического канала в 3-4 кГц, поэтому при оцифровке частоту
дискретизации достаточно иметь 8kHz. Один канал, с глубиной в 8бит:
64Kbps для хорошей несжатой передачи речи в одну сторону. ISDN поэтому
имеет два 64Kbps канала для двусторонней связи. Сжатие не применяют в
нём, ибо усложняет железо, а значит и цену повышает.
Эти 64Kbps каналы затем мультиплексируются и передаются по всяким E1 (T1
в паре стран), которые, в свою очередь, тоже мультиплексируются,
агрегируются и передаются уже дальше вплоть до оптоволокна. Передача
данных в E1 идёт кадрами, длительностью 125мкс (те самые 8000kHz), где
находится по одному байту от/для каждого из 32-х 64Kbps каналов. Пара
каналов используется для синхронизации и управления. Очень просто,
значит и дёшево. Но, в отличии от компьютеров, тут реально льются потоки
ото всех каналов каждые 125мкс. Никаких эти заголовков, или
произвольного времени возможности передачи пакета, как в компьютерных
сетях.
А дальше это суётся в SONET. В нём тоже передача идёт кадрами каждые
125мкс. Всегда передаётся, чётко и жёстко кадр всегда будет передан. Но,
в отличии от компьютерных сетей, кадр передаётся не в виде заголовка,
после которого идут данные, а он буквально параллельно с данными идёт.
Кадр SONET поэтому удобно представлять в виде таблицы, где сколько-то
столбцов каждой строки передают данные заголовка, а остальные столбцы
несут сами данные. Часть заголовка, конечно же, содержит биты для
синхронизации, поэтому зная что каждые 125мкс мы должны видеть одну и ту
же фиксированную последовательность, мы можем ссинхронизироваться.
Зачем так? Полезная нагрузка, весь этот поток байт, перемешенный с
байтами заголовка, делится на virtual circuit-ы (VC). И заголовок несёт
информацию о них. Если у нас имеются данные для передачи, при этом мы
уже прямо сию микросекундно передаём кадр (а мы всегда их передаём,
постоянно, пускай и "пустышки" без полезной нагрузки), то мы на лету
может вставить в следующие строки кадра, в столбцы заголовка, данные о
нашем VC и передавать его. То есть, кадр буквально формируется на лету
(ведь всё же 125мкс это довольно продолжительное время!) и заголовок в
нём формируется на лету, как и данные засовываемые.
Если бы это был компьютерный кадр, то пришлось бы в буфер в памяти
накапливать данные, после этого формировать заголовок и только после
этого отправлять. Пока отправляется текущий кадр, то ещё нужно иметь
память для формирования параллельно нового. Новые приходящие данные
будут отправлены только с следующим кадром. SONET и дешевле (за счёт
отсутствия буферов) и задержки от ожидания передачи кадра нет.
Но, чтобы всё работало хорошо, тикало как часы, каждый из 8000kHz, нужно
чтобы все устройства хорошо были синхронизированы по времени. Поэтому в
SONET используются атомные часы, GPS-приёмники и подобное. С одной
стороны конечно геморрой, а с другой хороший QoS и меньшая цена
оборудования из-за ненужности буферизации кадров.
Но это (для меня) не самое интересное было и открывающее глаза. У нас
идёт оптоволоконный провод от АТС до какого-то дома. В нём много
телефонов. Так как оптоволокно очень информационно ёмкое, то от этого
дома и дальше будет идти волокно до следующего на улице. В одном кабеле
от АТС будет идти много сотен каналов (VC) несущих оцифрованный звук до
поднятых телефонных аппаратов. В дом заходит SONET кабель с кучей этих
каналов внутри, но только лишь небольшая часть из них "интересна" этому
дому, только некоторые из них предназначены для аппаратов в нём. И тут
самая красивая часть SONET: add-drop multiplexer (ADM), в который входит
кабель. Интересующие для него каналы внутри кадра(ов) являются по сути
входящим трафиком, который он копирует на внутренние E1/ISDN/whatever
каналы. Дальше передавать эти VC внутри кадра не имеет смысла, так как
больше они никому не интересны. Получается, что внутри кадра на выходе
имеются слоты вакантные. Но раз речь про телефонную связь, то она
дуплексная и симметричная -- нужен исходящий канал симметричной ёмкости.
И вакантные места исходящего кадра как-раз заполняются исходящим
трафиком с устройств этого дома. Входящие кадры, некоторые слоты в них,
немного изменяются на этом ADM, в основном на лету копируясь, даже не в
буфер, а сразу же в оптический канал в формируемый кадр (SONET --
поэтому и называется синхронной сетью). И так каждый дом, на пути
следования этого единственного кабеля, имеет ADM который "забирает"
некоторые слоты каналов и добавляет свои исходящие.
Если этот кабель замкнуть кольцом на этой же самой АТС, то она по сути
на вход получит кадры с агрегированным исходящим трафиком всех домов. По
моему очень красиво с инженерной точки зрения! И высочайший QoS и
стабильность. Чтобы не ждать пока исходящий трафик дойдёт через все
hop-ы через всё кольцо до АТС снова, можно бросить ещё одно волокно, но
с трафиком в противоположную сторону. Тогда кол-во hop-ов до и от
каждого дома будут симметричны, как и задержки для каждой стороны
трафика. А если одно из колец "порвётся", то оно автоматом просто
деградирует до первого варианта с полным проходом кольца для ответного
трафика.
Все компоненты (дискретизация звука, кадры E1/T1, кадры SONET) живут по
одному таймингу, симметричные, полнодуплексные, не требуют буферизации
(E1 буквально байты каждого канала отправляет в каждом кадре). Лучшее
качество в обслуживании для телефонных разговоров (как мне кажется, в
теории и, судя по статьям, на практике) и достаточно низкая цена для
перехода на всё это ещё уже в 80-е. Но со временем всё понижающаяся цена
компьютерных систем, их информационная ёмкость и гибкость конечно
сделали своё дело и убили телефонные технологии. И для компьютеров SONET
уже не очень, ибо, как минимум, на часто в Интернете трафик симметричный
в обе стороны и в нём просто навсего сложнее утилизировать в полной мере
ёмкость канала. А объёмы чисто компьютерных данных куда сильнее растут
чем телефонных разговоров.
Мне SONET ещё приятен тем, что он точь-в-точь похож на идею
store-and-forward NNCP сети где одну флешку передают по кругу по рукам,
где каждый забирает пакеты предназначенные для него (остальные он всё
равно дешифровать не сможет) и записывает свои исходящие для других
(собственно, первая команда в NNCP только на это и рассчитывалась --
никакой поддержки сети изначально даже не планировалось). Хотя и тут
идея, само собой, не нова, ибо Token Ring по кругу передавал токен. Но
SONET не обязан быть в кольце -- для него это одна из опций.