И снова здравствуйте. В прошлый раз мы подробно разбирали технологию частотной синхронизации SyncE, в позапрошлый пробежались по верхушкам профиля G.8275.2 ATR. Сегодня же с интересом будем препарировать никем неиспользуемый базовый протокол IEEE 1588v2 или PTPv2 Default Profile. Планируется много любопытного: поностальгируем о былых деньках, натянем STP на маршрутизаторы, всем миром извинимся перед афроамериканцами, заглянем в миллион дампов, устанем смотреть картинки, как следует изучим всю матчасть, поднаберемся нужных словечек, чтобы уже в следующем акте со всей необходимой теоретической базой че-нить куда-нить внедрить и даже потраблшутить. Айда разбираться.

Современный PTP - Precision Time Protocol или Протокол Точного Времени описан в стандарте IEEE1588v2-2008. Он был разработан специально для организации частотной и фазовой (временной) синхронизации в пакетных сетях, бонусом прилагается распространение информации о времени суток. Совместно с технологией SyncE протокол PTPv2 обеспечивает невероятную точность синхронизации, измеряемую в единицах наносекунд. Главным потребителем систем синхронизации в пакетных сетях являются мобильные базовые станци 2G, 3G, LTE, в дальнейшем 5G. В наше время протокол становится очень востребован и популярен в сетях операторов, в первую очередь, из-за перехода на новые поколения мобильной связи и планового обновления оборудования. Доросли, так сказать.

Байки из склепа

В силу возраста не все читатели могли вживую наблюдать за эволюцией технологий. Поэтому давайте отмотаем пленку лет на 20 назад.

История развития протоколов синхронизации идет бок о бок с технологическими решениями в области базовых станций мобильных сетей, являясь своего рода ответом на вызовы времени. Раньше сотовая связь поколений 2G и 3G работала в режиме TDM по сетям PDH и SDH. Основной задачей мобильных сети была передача голосовых вызовов и SMS. А частотная синхронизация - неотъемлемая составляющая TDM сетей. Позже начали появляться мобильные технологии передачи данных GPRS и EDGE в 2G, UMTS, HSPDA, HSPA+ в 3G.

С появлением смартфонов мобильный интернет быстро завоевал популярность в ширнармассах. Но операторам стало понятно, что емкостей классических TDM-сетей категорически не хватает. Например, в базовой станции 3G старого поколения было всего 4 порта под потоки E1, т.е. можно было подать на базу канал емкостью всего 8 Мбит/с (и это на сотню абонентов). А дома уже была проведена выделенка под 100 Мбит/с. Сами сети SDH тоже были не резиновые. Тогда-то разработчики мобилы обратили свое внимание на популярные сети Ethernet.

Еще в 2000-ых интерфейсы 1G и 10G были довольно распространенным явлением, коммутаторы практически бесплатными, а возможность собирать лаги делала сети поистине бездонными. С тех пор начался технологический переход мобилы с TDM на пакетный транспорт. Сначала через костыли в виде конверторов E1overEthernet, потом на БС начали появляться дырдочки непосредственно под RJ-45 с возможностью назначить влан и IP-адрес. Следующее поколение мобильных сетей - LTE - полностью ушло от TDM и сразу разрабатывалось под работу поверх пакетных сетей. И каждый из этапов развития сталкивался с извечным вопросом: а как теперь передать синхронизацию?

Сети Ethernet/IP/MPLS по определению являются асинхронными. Перво-наперво пришлось научиться выуживать синхру из эмуляций потоков E1 поверх Ethernet. Операторы довольно быстро распробовали прелести MPLSа. Очень уж им понравилась возможность через PWE3 кидаться эмуляциями E1oMPLS: CESoPSN и SAToP - отличные инкапсуляции для переходного периода с TDM на пакетку. Вместе с ними одной из первых технологий передачи синхры стал CES ACR (Circuit Emulation Service with Adaptive Clock Recovery). Довольно неожиданно, но таинственное поле Control Word (CW), сигнализируемое T-LDP и передаваемое под MPLS-заголовком, на долгие годы стало основой частотной синхронизации (если надуюсь на еще одну главу, то расскажу как именно это устроено).

Но CES ACR работает только с потоками. А мобильная сеть тем временем ударными темпами готовится к переходу на IP.

Усилия разделились. Первая группа весьма прагматично настроенных товарищей вооружившись кусачками пошла срезать медь отправилась выпаивать чипы синхронизации из SDH, попутно придумывая с какого боку этот SDH натянуть на Ethernet. И по итогу родила SyncE – технологию распространения частотной синхронизации на физическом уровне, о которой речь шла в прошлом акте.

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

Вторая группа товарищей, явно под веществами с творческим уклоном, пошла другим путем. Они решили изобрести протокол, который сможет в синхронизацию в виде сигнальных сообщений поверх Ethernet-сетей. Задача крайне амбициозная. Кой чего спипозаимствовали у предшественников, что-то придумали сами, скрестили ужа с ежом - так миру явился гениальнейший 1588/PTP, а потом 1588v2/PTPv2, к которому со временем нуждающиеся прикрутили несколько профилей.

Для использования в телекоммуникационных сетях настоятельно рекомендуется использовать что-то из:

G.8265.1 (ACR - Adaptive Clock Recovery) – частотная синхронизация абсолютно без поддержки транспортной сети. Этим протоколом они полностью заткнули скептиков проблему. Уже лет 15 в нашей стране он успешно является основной для мобильных сетей технологий 2G, 3G и LTE FDD. Профиль вышел настолько хорош собой, что поверх пакетной высоконагруженной сети местами даже безо всяких QoS умудряется передавать данные о частоте с приемлемым уровнем.

G.8275.2 (ATR - Adaptive Time Recovery) – частотная и фазовая синхронизация с частичной или совсем без поддержки транспортной сети, а также не особо нужное нам время суток (все равно из NTP возьмем). Шли годы, развитие мобилы не стояло на месте, придумали сначала LTE TDD, LTE Advanced, потом 5G, сейчас 6G где-то в Япониях. И там категорически нужна фазовая синхронизация. Ее можно взять из GPS, но, если базовая станция стоит в тоннеле метро или в здании - это физически недоступно. Не говоря уже про зоны горячих конфликтов. Технология ATR получилась хорошая, но точность явно страдала, LTE TDD еще как-то можно запустить, остальное мимо. Хотя, безусловно, свою нишу она нашла. Вообще этот профиль можно запустить с полной поддержкой сети и тогда точность будет великолепна. Можно. Но зачем?

G.8275.1 – частотная и фазовая синхронизация с полной поддержкой сети. Разработчики настолько преисполнились в сознании, что в оконцовке слились в экстазе с изобретателями SyncE и придумали в придачу гибридный режим. Технология настолько совершенна, что поверх кривых-косых пакетных сетей умудряется нести наносекундные точности. И это действительно восхищает. Правда также требуется специальный чип и ПО в составе устройства. Очень удачно, что G.8275.1 и SyncE разрабатывались параллельно и явно с прицелом друг на друга. Поэтому чипы по умолчанию содержат обе технологии.

1588v2 Default Profile или PTPv2

Сам по себе протокол PTPv2 без конкретных профилей никому особо не интересен. По сути это описание философии, логики работы, типов устройств, математического аппарата, сигнальных сообщений, метрологии и сфер применения. Дальше приходят специальные умные люди и на основе этого знания созидают необходимые профили. Простейший пример: делают адаптацию передачи сигнальных сообщений на канальном уровне или сетевом. Для общего развития давайте следующие 20 минут посмотрим, что предлагает нам Default Profile.

Самое главное — протокол умеет передавать информацию о частоте, фазе и времени суток. И при удачном стечении обстоятельств может сделать это с точностью фазы ±1,5мкс и частоты ±0,05ppm. И надо же такому случиться, что именно такие параметры нужны различным технологиям мобильной сети:

Дальше немного базовой терминологии.

Clock – по-ихнему это задающий генератор устройства, который мы тут собрались синхронизировать с помощью подстройки чипа ФАПЧ/PLL.

Time Source – источник точного времени или эталонный генератор. В идеале нечто, что имеет прямую связь с космосом, ведь именно оттуда GPS/ГЛОНАСС/Beidou/Galileo присылают на Землю информацию об единой частоте, фазе и времени суток. Как правило этот девайс носит имя GrandMaster.

PTP Domain – число в пакете, которое определяет набор железок, синхрящихся от одного источника. Что-то типа единого широковещательного домена. Именно по этим циферкам железки понимают нужно обращать внимание на пришедший пакет или нет.

Устройства в сети делятся на 3 типа:

• Ordinary clock (OC) — обычные часы. Дословный перевод мне не нравится, абсолютно не понятно, что они имели ввиду. Поэтому я бы назвал их оконечными устройствами. Это либо источник синхронизации (GrandMaster - GM), либо ее потребитель (базовая станция).

• Boundary clock (BC) — пограничные часы. Звучит кринжово. На нашем языке это транзитный маршрутизатор/коммутатор, который ловит пакеты PTP и об них синхронизирует свой генератор с вышестоящим устройством (GM или другим BC).

• Transparent clock (TC) — прозрачные часы. Камон, ну правда, рука-лицо. Креативный отдел у разработчиков нужно выставить на мороз. С задачей донести мысль максимально просто они не справились. TC — это транзитный маршрутизатор/коммутатор, который не синхронизируется с GM или BC, а прозрачно пропускает через себя пакеты PTP. Но при этом вносит в них информацию о времени, которое пакет провел с момента входа, до момента выхода из устройства. Чтобы OC или BC, которые будут обрабатывать этот пакет, смогли это время учесть при расчетах.

Информация о типе устройства нигде не переносится, это философское понятие, которое следует из выполняемой железкой функции. Из всего выше сказанного формируется топология или сетевая иерархия

Если в двух словах, то из космоса на GM прилетает точное время и частота, там оно транскодируется и превращается в сообщения протокола PTP. Далее через транзитные устройства BC и TC летит к потребителям OC (например, базовые станции). Хэппи энд.

У нас тут немножечко ролевые игры получаются. Железкам названия придумали, нужно и о портах не забыть. Порт, с которого железка засинхрилась, называется Slave. Все остальные, через которые отправляются сообщения PTP, называются Master. Картинку вместо тысячи слов.

Важное упрощенное замечание: у GrandMaster порт может быть только в состоянии Master. У OC (базовых станций) — только в Slave. У BC (маршрутизаторов) в Master и Slave.

Есть еще один тип порта Passive, он активной роли не играет, никому не интересен, но об его очень крутой функциональности, которую придумали сумрачные гении из Huawei, я расскажу в следующем акте на конкретном примере.

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

• Announce — рассказывает о характеристиках сервера;

• Sync, Follow_Up, Delay_Req, Delay_Resp — используются в вычислениях;

• Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up — используются в вычислениях;

• Management — некое управление;

• Signaling — некая сигнализация.

Последние три сложно объяснить без реальных примеров, которых я не видел, т.к. они не применяются в телекоммуникационных профилях, поэтому и пытаться не буду.

В качестве транспорта для PTPv2 предусмотрели разные комбинации L2/L3, unicast/multicast. Понятно, что пришлось изобретать и формат сообщений. На мой взгляд идеально ?

Протоколу, к счастью, достался свой Ethertype 0x88f7, поэтому его смогли инкапсулировать напрямую в Ethernet.

Для IP получилось тоже норм, правда зачем-то зарезервировали два UDP-порта 319 и 320 для разных типов сообщений. Видимо, так было удобнее кодить кодерам и обрабатывать пакет. На 319 порту бегают сообщения (типа Sync и Delay_Req), которые участвуют в вычислениях и непосредственно синхронизации

На 320 порт повесили все остальные сообщения, которые специализированным чипом не обрабатываются, но участвуют в алгоритме BMCA.

1588v2/PTPv2 Default Profile: BMCA

Любые сети - это не только попытка передать что-то куда-то, но и сделать красиво какое-никакое резервирование. PTP здесь не исключение. Никогда не знаешь, в какой момент отсохнет GrandMaster и сеть останется на внутренних генераторах. Поэтому логично использовать кондовые дедовские методики agile и scrum — воткнуть второй GrandMaster. Так надежнее! А чтобы выбрать, кто из них теперь главнее, изобрели алгоритм BMCA – Best Master Clock Algorithm – алгоритм выбора лучшего источника. И вправду, если в сети будет несколько GM (на картинке ниже называются BITS), то неплохо бы выбрать, кто будет из них главный, а кто резервный.

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

Задачи BMCA просты как три копейки:

1. Перебрать всех кандидатов и выбрать одного GrandMaster’а;

2. Назначить всем портам в сети статус Master или Slave;

3. Разорвать петли синхронизации.

На мой взгляд, разрабов сложно заподозрить в попытке изобрести велосипед. Походу они ведрами начерпали вдохновения из бессмертной классики — STP – Spanning Tree Protocol. Там тоже сначала среди равных выбирается Root (GM), потом корневые (Slave) и назначенные (Master) порты, и в конце производится блокировка одного линка в кольце (Passive). Только в PTP время сходимости минут 10-15)

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

В первую очередь BMCA нужно выбрать GM. Для этого в стандарте заложена таблица

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

В нулевой момент времени все девайсы ничего ни о ком не знают, считают себя Grandmaster, сидят на внутренних генераторах (local) и все их порты будут в состоянии Master.

Далее они начинают слать сообщения Announce, где будут рассказывать о личных параметрах. Все маршрутизаторы в сети по умолчанию имеют одинаково плохие показатели точности, об этом сигнализирует Source port = local и Class = 248 – железка находится на внутреннем генераторе. Но мы-то знаем, что где-то в сети есть альфач, который обязательно выиграет выборы. В его Announce обычно Class=6.

Получив Announce-сообщение от соседа, железки начинают мериться друг с другом, у кого короче. У кого самый короткий, тот и подебил. Короче всего должно быть у GrandMaster.

Поле Priority1 по умолчанию у всех девайсов выставлено в значение 128. Его никогда не надо трогать (даже если система позволяет), потому что иначе это будет полностью ручной режим выбора источника. Железку никто не сможет победить в честных выборах. Например, GM с Pri1=127, потерявший сигнал GPS, будет считаться лучше, чем резервный GM с Pri1=128, у которого сигнал GPS есть. И вообще регулировать параметры на GM предстоит не нам, а специально обученным синхролюдям, так что и лезть туда со своими советами не надо.

Поле Clock Class указывает на класс часов, а именно их качество. 6 класс — высший. Про него хочется думать, что GM синхрится об GPS/ГЛОНАСС. Но это не совсем так. Поле сообщает, что источник получает всего-навсего частотную синхронизацию с качеством PRC (в т.ч. из рассказа про SyncE). Источником частоты может быть как ПЭГ, так и спутник. В случае с фазовой синхронизацией наличие эталонной частоты — залог успеха. Значения, которые могут выскочить в этом поле, немногочисленны и, в общем-то, описывают куда скатится Class 6, когда потеряет источник PRC. До дна не так уж и далеко

Параллельно существует табличка, которая поясняет за понятие колбасы 3 Категории частоты из предыдущей

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

Поля Clock Accuracy и Clock Variance рассказывают о текущих параметрах точности. Вот, например, кусочек лога на джуне, где можно пронаблюдать, как на GM после ухудшения до SSU-A вернулось качество частотной синхронизации PRC (про это рассказывалось в прошлом акте).

16:26:17 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_CLASS_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_class: 7
16:26:47 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_CLASS_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_class: 6
16:28:27 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_ACCU_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_accuracy: 254
16:35:07 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_ACCU_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_accuracy: 35
17:09:48 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_ACCU_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_accuracy: 34
18:26:40 Juniper clksyncd[10377]: %DAEMON-5-CLKSYNCD_EVENT_PTP_CLOCK_ACCU_CHG: gm_id: 00:18:17:FF:FE:00:22:B4, clock_accuracy: 33

Здесь мы видим, что класс сменился с 7 на 6, после чего параметр Accuracy (точность) начал улучшаться наносекундными шагами 254→35→34→33. Эти числа характеризуют процесс подстройки и фазовое расхождение с источником. На джуне отображаются в формате DEC, на хуавее в HEX.

Чтобы пройти путь от 35 до 33 GM, понадобилось 2 часа. Так что сломать просто, а оправиться после такого удара тяжело. Не гоняйте не ломайте источники частоты, пацаны!

За поле ClockVariance (или где-то зовется offsetScaledLogVariance) говорить ничего не решусь, там что-то связанное с дисперсией Аллана и логарифмами, ну его нафиг. Характеризует стабильность источника. Чем меньше число, тем лучше. Полагаю, именно оно влияет на итоговую стоимость девайса.

Параметры ClockClass, ClockAccuracy, ClockVariance руками не задаются, а формируются автоматически источником на основе собственного мироощущения, поэтому управлять ими особо не получится. Если у двух GM все в порядке с подключением к GPS или PRC, то эти параметры будут скорее всего в обычной жизни равны.

Еще одним свойством источника является параметр TimeSource. И было бы преступлением о нем не рассказать. Передается оно в пакетах PTP Announce

и отображается в диагностике. На Huawei тут

На Juniper тут

Самое интересное, что поле не участвует в BMCA от слова совсем, но самым прямым образом рассказывает об источнике получения сигнала. Вообще, это самое последнее поле, назначение которого я узнал. Случись это на этапе знакомства с протоколом, я бы выглядел в приличном синхрообществе минимум на 50% менее глупо. Ведь именно из него можно было сразу узнать, что GM не должен брать свое время только из космоса от GPS. Есть множество способов, рвущих все шаблоны. Чего только стоит вариант с NTP

Тут ведь как? Нам изо всех утюгов вещали, что GrandMaster берет время с GPS и все такое. А по факту оказывается, что наш самый главный источник может действовать абсолютно автономно. Время на нем можно выставить локально (а не принять из космоса), подключить к нему источник частоты с качеством, например, PRC. После чего он будет выдавать в сеть фазу с ClockClass=6, такую же что и c GPS. Параметр TimeSource как раз позволяет понять, где провернули такой фокус. На самом деле опция архиважная, а во многих южных и западных регионах нашей Родины в данный момент безальтернативная. Ну а куда деваться, если РЭБ глушит и своих, и чужих, и доступа к спутникам просто физически нет. Тут важно только то, чтобы вся сеть синхронизировалась от одного GM. А еще хорошо бы все GM в одной сети связать друг с другом (хотя бы по PTP), чтобы они выровняли фазу и уменьшили время пересинхронизации сети при падении основного источника. В общем, знание факультативное, но дает сразу +10 к ловкости, уму и харизме. Для должности >= ведущего инженера рекомендую перечитать и все-таки понять.

Первый параметр, которым можно самостоятельно выбрать того, кто равнее среди равных — Priority 2. По умолчанию задается 255. Уменьшая именно это значение, можно управлять тем, кого делаем самым-самым главным, чтобы не полагаться на удачу. В общем, один в один, как в STP поле Priority.

Если уж и эти параметры равны, то выбираем наименьший GrandMasterClockID, который, барабанная дробь… формируется из мак-адреса.

Если не отрегулировать выбор GM через поле Priority 2, то корневой GM в сети все равно будет выбран по минимальному мак-адресу, ой, простите, по GMClockID. Мак на GM можно поменять, поэтому им тоже можно управлять вручную. Можно, но зачем, если есть Priority 2? Собственно на этом этапе кончается последняя интрига по выбору GM. Все девайсы в сети приходят к тому, что в своих сообщениях Announce рассылают информацию о выбранном GM через все порты, кроме тех, откуда получили.

Далее STP BMCA занимается только тем, что принуждает все транзитные железки определиться какой порт у них будет Slave (Root), а какие Master (Designated). Тут все также по-STPшному просто. В сообщениях Announce передается параметр cost Steps removed – количество шагов до GM, которое каждый транзитный маршрутизатор увеличивает на 1. Чем шагов меньше, тем ближе GM, тем лучше порт. Если у двух портов одинаковое число шагов, то выбираем наименьший, делаем его Slave. Остальные в Master. Готово.

Там, где в кольцевых топологиях по итогу Master смотрит в Master, один из портов переходит в режим Passive (видимо, на железке с меньшим ClockID). Теперь, во-первых, именно в этом месте разорвано кольцо синхронизации, а, во-вторых, через этот порт отработает резерв (спустя несколько минут), если основной маршрут пропадет. Всё, выдохнули, алгоритм BMCA построил дерево распространения синхронизации во все углы сети свободное от петель. Поздравляю, вы только что побывали на мастер-классе, как еще одним способом натянуть нелюбимый всеми STP на маршрутизаторы)

Но все, что я рассказал, работает не совсем так. Выше описана общая логика, как отработает сферический BMCA в вакууме. Однако каждая рассылка Announce с измененным GM (Root) произойдет только после того, как нижестоящая железка засинхронизируется об вышестоящую, т.е. перейдет в состояние LOCK.

Когда мы включили рубильник в сети, начался хаос поиска GM. На каждом линке, где запущен PTP, рассылаются Announce, одна из сторон быстро замолкает, т. к. ее параметры хуже полученных от соседа. Девайсы на соседних линках начинают бестолково синхриться друг об друга, выстраивая самые немыслимые топологии. Раньше всех найдет настоящий GM самый близко стоящий к нему маршрутизатор в ядре сети. С помощью BMCA маршрутизатор проиграет выборы GM, и тут же начнется процесс синхронизации, который занимает несколько минут. Только после этого маршрутизатор в своих Announce соседям начнет рассказывать, что у него доступно качество ClockClass=6. До этого он им говорил про ClockClass=248, даже несмотря на то, что получал ClockClass=6 от GM. И далее так далее по цепочке минут на 10-15. Чем больше диаметр сети, тем больше времени займет процесс первичной отработки BMCA. Многим устройствам придется пересинхронизироваться заново, т.к. в процессе работы BMCA будет предлагать им все лучших и лучших кандидатов на роль GM. Чтобы еще непонятнее, давайте с картинкой

На Time Server 1 по картинке явно лучше параметр Priority 2 или GMClockID, поэтому в итоге он будет GM.

В момент времени (1) маршрутизаторы BC1 и BC2 получили Announce от Time Server 1 и Time Server 2. Быстренько проиграли выборы и начали синхриться об них. Допустим этот процесс занял абсолютно одинаковое время.

В момент времени (2) устройство BC1 и BC2 начали рассылать сообщения Announce всем своим соседям с clockClass=6, но разными Priority2 или GMClockID. Time client 1 засинхрился об BC1. BC3 видит, что Announce от BC1 лучше, чем от BC2, синхрится об него. Time Client 3 от безысходности синхрится за BC2. А вот BC2 в свою очередь видит, что Announce от BC1 лучше, чем от его ближайшего TS2 и начинает пересинхронизироваться на новый источник.

В момент времени (3) Time Client 2 синхрится от BC3. А Time Client 3 вынужден пересинхронизироваться от того же BC2, но уже с новым GMClockID.

По итогу вся сеть синхронизирована из жопы одного места.

И здесь нужно уловить еще одну важную мысль. В сети есть условный GrandMaster-батя с хорошими параметрами типа clockClass=6, который знает о времени всё, именно он генерирует эталонную частоту и сообщение Announce, о котором мечтает каждый BC и OC. Мы же помним, что в каноническом STP сообщение BPDU генерирует только устройства, выбранные в качестве Root, а все остальные девайсы по дороге его ретранслируют, подменяя только BridgeID и Root Path Cost? Здесь так же. Ближайшая к GM-бате транзитная железка, синхрясь об него, начинает транслировать его GMClockID. Но частоту и фазу нижестоящим маршрутизаторам распространяет уже свою собственную. Т.е. каждый транзитный маршрутизатор тоже становится этаким GM-пездюком, но уже для своих клиентов. Именно из-за этого, шаг за шагом, на каждом следующем маршрутизаторе мы начинаем терять исходную частоту и фазу. В итоге получается как всегда.

Еще важно понимать, что BMCA используется во всех профилях: G.8265.1 (ACR), G.8275.2 (с поддержкой сети или без нее в режиме ATR), G.8275.1. В случае ACR и ATR сеть становится вырожденной, из нее пропадают устройства BC, остаются только GM и OC. Но там точно также летают сообщения Announce и работает BMCA.

Минутка нетрадиционных ценностей

Было непросто разобраться в STP во второй раз в жизни, нужно перевести дух. Поэтому проведем сеанс зрительной гимнастики. Посмотрим вдаль, что там на другой половине глобуса. Когда я разбирался во всем этом, сайт джунипера почему-то настойчиво вместо BMCA писал про какой-то BTCA, категорически отказываясь объяснять, почему так.

Я даже было потерялся, думал может еще какой-то протокол изобрели. Но нет, контекст тот же, речь про PTP. WTF? Давай судорожно лазать по интернету. И чтобы вы думали? Все дело в рабах, вот прям в самых взаправдашних столетней давности.

Мы тут никогда бы не подумали, но слова Master и Slave, это не только ведущий и ведомый. У них там в Америке своя атмосфера: Master – это господин, а Slave – раб. На фоне истерии, связанной с движением BLM и прочей повесточкой, кто-то явно решил прогнуться под изменчивый мир и начал продавливать ученое сообщество на исключение этих слов из лексикона. Дескать мол, таким образом мы уж точно смоем вину за 250 лет рабовладельческого строя! Ну и по карьерной лестнице продвинемся. Ученое сообщество аргументированно возразило:

• вам там в США надо, вы и извиняйтесь, а протоколы не трогайте;

• слова Master и Slave используются в 50000 патентах, вы там совсем ку-ку?

Но лгбт-поезд уже набрал ход, весь мир в труху должен платить и каяться. И вот IEEE на своем сайте вполне официально употребляет BTCA вместо BMCA.

Извименений-то в целом немного: Master теперь TimeTransmitter, Slave — нейтральное TimeReciever. BMCA стал Best Master TimeTransmitter Clock Algorithm. Что интересно, тип узла GrandMaster не тронули, оставили Великим Белым Господином, не шмогли полностью отказаться от расовой сегрегации, оставили-таки лазеечку.

Академики как могут игнорируют этот бред, в литературе доминирует BMCA. Куда в итоге качнется маятник идиотии пока не понятно. Например, в Cisco, к слову, такой же американской, как и Juniper, показали характер нордический, выдержанный, но чтобы не ссать против ветра нагнетать, таки придумали заменить слово Slave на безобидное Client, резонно рассудив: нет рабов — нет проблемы.

Так что имейте в виду и не поддавайтесь на провокации потенциальных идеологических противников/партнеров (нужное подчеркнуть на момент прочтения статьи).

1588v2/PTPv2 Default Profile: синхронизируемся

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

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

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

• Sync Message (опционально может идти совместно с Follow_Up Message)

• Delay_Req Message

• Delay_Resp Message

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

Сообщение Sync в момент времени t1 отсылается ведущей железкой (ранее она была выбрана BMCA как ближе стоящая к GM-бате) через Master-порты. В этом сообщении содержится информация о точном времени. Собственно, это параметр originTimestamp = t1.

Железка-раб через slave-порт получает сообщение Sync в момент времени t2 и по нему уже в принципе может выставить себе примерное время. Но т.к. полет пакета Sync по сети занимал какое-то время (t2-t1 = односторонняя задержка MS или Master-Slave), то t2 – это время из прошлого. Необходимо узнать задержку, чтобы вернуть его назад в будущее

Для этого в момент t3 в направлении мастера вылетает сообщение Delay_Req. Задача сетевых инженеров сделать так, чтобы Delay_Req летел по сети ровно столько же, сколько Sync. Это называется симметричная задержка. Только благодаря этому свойству, можно будет правильно вычислить реальное время.

Время t2 по сети не передается, а просто фиксируется внутри маршрутизатора. Время t3 по сети можно передавать, а можно не передавать. Это ни на что не влияет. Главное, что маршрутизатор его запоминает.

В момент времени t4 сообщение Delay_Req врывается в недры мастера, он фиксирует это время и ответным сообщением Delay_Resp отсылает информацию о метке t4 рабу (уже без всяких временных отметок на диаграмме выше).

t4-t3 = односторонняя задержка SM или Slave-Master.

Совместное немного выцветшее на солнце фото реальных сообщений с сети

Те же яйки, но с Follow_Up

Не отходя далеко от кассы, давайте сразу разберемся, кто такое Follow_Up. Я долго не мог понять, что это и зачем, круто это или не очень, нужно оно мне или нет. А суть оказалась предельно простая. Задача протокола PTP - отправлять метки времени (в общем-то, как и в NTP). Но PTP хорош тем, что старается делать это максимально близко к физическому уровню, чтобы исключить лишний джиттер, связанный буферизацией. Т.е. уже фактически сформированный пакет PTP с сообщением Sync, готовый улететь в линию, перехватывается чипом синхронизации, вставляет в него метку времени t1 и только теперь отправляет. Это режим One-Step

Правда жизни такова, что не только лишь все чипы так умеют. Задача-то действительно нетривиальная, на полном скаку остановить пакет PTP перед началом сериализации, вставить в него метку времени, а потом пересчитать CRC в кадре Ethernet. Поэтому есть второй подход - Two-Step

Отправляем пакет Sync с нулевым originTimestamp (t1) и флагом PTP_TWO_STEP, чип для себя фиксирует время выхода из интерфейса.

следом отправляем пакет Follow_Up, где указываем время выхода Sync (ту самую метку времени t1). Связь Follow_Up и Sync осуществляется через sequenceId.

Т.о. сложная инженерная задача разбивается на два простых этапа: зафиксировать время и отдельно сообщить о нем.

Резюмируя: Follow_Up это для старых чипов, поэтому некруто. Но на практике абсолютно ни на что не влияет. Для точности расчетов не хуже, и не лучше. Современные Huawei и Juniper (даже ACX2100) по умолчанию работают в режиме One-Step. Включать режим Two-Step можно. Даже есть ответ зачем. Например, чтобы снять дампы для написания этой статьи.

Возвращаемся к калькулятору. Итак, задача всех этих сообщений принести на slave-железку всю необходимую информацию о метках времени:

• t1 – время выхода пакета Sync из Master’а;

• t2 – время прихода пакета Sync на Slave’а;

• t3 – время выхода пакета Delay_Req из Slave’а;

• t4 – время прихода пакета Delay_Req на Master’а.

Начинаем считать:

t_ms = t2 – t1 – это односторонняя задержка от мастера до слэйва

t_sm = t4 – t3 – это односторонняя задержка от слэйва до мастера

(t_ms – t_sm) должно быть равно 0. По крайней мере, протокол на это рассчитывает. На практике же так бывает не всегда. Например, прямая и обратная трасса идут разными путями, или прямое и обратное волокно разной длины

PTP на этот случай дает возможность внести коррективы на маршрутизаторах для компенсации асимметрии (в наносекундах), мы на это еще посмотрим в практической части.

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

MeanPathDelay = (t_ms + t_sm)/2 - это усредненное время, которое пакет летит от Master до Slave.

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

Сама по себе формула Delay, наверное, особо не нужна, но в целом удобна. Через нее, например, можно узнать довольно точную длину линка в метрах (тоже посмотрим как).

Остается вычислить время, на которое нужно скорректировать часы на Slave относительно Master. Параметр называется Offset – смещение (или ошибка). Делается довольно просто. Из времени на слэйве вычитаем время на мастере, докидываем одностороннюю задержку

Offset = (t2-t1) + MeanPathDelay

Для нелюбителей лишних вычислений этот же Offset считается по формуле

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

Именно параметр Offset в PTP показывает, на сколько наносекунд Slave убежал от Master по фазе. И именно этот параметр в режиме реального времени несколько раз в секунду приводит к подстройке фазы на ФАПЧ/PLL.

Здесь надо прерваться на минутку и вернуться чуток взад, чтобы пояснить аудитории, что за дохреналлиарды секунд летают в метке t1 (originTimestamp) в пакете Sync/Follow_Up.

Бывают разные шкалы времени: TAI, UTC, GPS, GLONASS и пр. Смысл в том, что прогрессивное человечество ведет свой отсчет не только от Рождества Христова или по календарю династии Цинь, но и от момента ключевых событий в науке. Так 1 января 1958 в 00:00:00 была запущена единая система TAI (International Atomic Time), основанная на показателях множества атомных часов, синхронизированных между собой.

В тот прекрасный день решили, что

секунда в системе СИ представляет собой интервал времени, равный 9 192 631 770 периодам излучения, соответствующего переходу между двумя сверхтонкими уровнями энергии основного состояния атома цезия-133, находящегося в покое при 0 градусов Кельвина

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

Протокол PTP использует в расчетах именно TAI, но точкой отсчета (началом эпохи) считается не 1958 год, а 1 января 1970 года. К слову в Unix-системах начало эпохи приходится на этот же день, но там время считается по UTC. А между UTC и TAI на апрель 2026 набежала разница в 37 коррекционных секунд, которые, кстати, передаются в Announce и отображаются в диагностике на маршрутизаторах (пример с джуна). А делается это для того, чтобы как раз можно было использовать PTP для установки правильного времени на компуктере

Так или иначе, получив это бесполезное для сетевиков знание, шибко любопытный читатель может с точностью до наносекунды установить дату, когда автор снял любой дамп в статье (или когда их надергали для интернетов). А заодно и внезапно понять, что в PTP представляет из себя время суток (ToD - Time of Day) и как оно переносится.

Возвращаемся к нашим синхроделишкам. Помимо передачи точного времени и фазы, PTP умеет корректировать частоту, чем крайне активно пользуются поголовно все операторы мобильной связи в профиле G.8265.1 (ACR). Происходит это благодаря внимательному наблюдению за пакетами Sync.

В каждом Sync содержится информация о точном моменте времени (t1), когда пакет вылетел из Master’а. Slave фиксирует время прихода каждого Sync по своей внутренней шкале времени (t2). Например:

t1(0)=100 t2(0)=200

t1(1)=200 t2(1)=400

….

t1(n-1)=900 t2(n-1)=1350

t1(n)=1000 t2(n)=1500

Смещение частоты вычисляется, сравнивая время на источнике и получателе для текущего и предыдущего отсчета. В ходе этого процесса вычисляется коэффициент коррекции для ФАПЧ/PLL

[t2(1)-t2(0)] / [t1(1)-t1(0)] = (400 – 200) / (200 – 100) = 200/100 = 2

[t2(n)-t2(n-1)] / [t1(n)-t1(n-1)] = (1500 – 1350) / (1000 – 900) = 150/100 = 1,5

Коэффициент коррекции 2 означает, что часы на Slave бегут в 2 раза быстрее, чем на Master, именно во столько раз их нужно притормозить. По прошествии времени часики на slave замедлились до 1,5. Со временем ФАПЧ/PLL должен подстроиться под данную частоту и коэффициент должен стать равен 1 или максимально близко к нему. Собственно, так и производится частотная синхронизация.

Есть одно поле в пакетах PTP, которое долго не давало мне покоя. Право, я даже расстраивался, что оно у меня всегда равно 0, думал может что-то неправильно работает, до того мне хотелось увидеть там циферки, сил нет. Речь о correctionField.

Встречается во всех типах сообщений: Sync, Delay_Req, Delay_Resp, Follow_Up, Announce. И вряд ли в телекоммуникационных сетях вы его когда-нибудь встретите отличным от нуля. Дело в том, что именно оно заготовлено PTPv2 Default Profile для элементов типа TC – Transparent Clock. Напомню, что TC не выполняют синхронизацию от GM, но вносят в транзитные пакеты PTP отметку о том, сколько пакет задержался в их недрах (синяя стрелочка на схеме).

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

1588v2/PTPv2 Default Profile: конечный автомат

Последнее, о чем стоит упомянуть в разговоре о процессе синхронизации — конечный автомат состояний, через который проходит ФАПЧ/PLL железки в процессе выравнивания частоты и фазы.

Как и в SyncE начинается все с FreeRun – состояние, когда железка никогда не видела внешнего источника и работает на внутреннем тактовом генераторе. Возникает или после перезагрузки, или после выкл/вкл протокола.

После того, как появился внешний источник (его выбрал BMCA), начинается процесс подстройки — Acquiring. В нем железка может легко зависнуть минут на 5-10 в зависимости от модели чипа. А может остаться навсегда, если частота плавает или не хватает еще каких-то вещей для счастья (например SyncE для Huawei). Именно на этом этапе производится физическая подстройка ФАПЧ/PLL.

Freq_Locked – ФАПЧ/PLL маршрутизатора залочился (выровнялся) по частоте. Конечный этап в G.8265.1 ACR. Вряд ли вы на маршрутизаторах его увидите, скорее только на базовых станциях.

Phase_Aligned – ФАПЧ/PLL маршрутизатора залочился по фазе. Конечный этап для G.8275.1 и G.8275.2. Почему вместо слова Lock соригинальничали и придумали Aligned я так и не понял. Но именно в ожидании этого кульминационного момента базовики судорожно жмут F5, чтобы запустить свою прелесть - LTE TDD.

Напомню, что слово Lock по-нашенски означает полностью синхронизированные железки. Когда говорят «база залочилась», это значит она синхронизировалась по частоте или фазе с источником. Термин пришел из электроники вместе с ФАПЧ/PLL, поэтому нашему сетевому уху причиняет нестерпимую боль и нравственные страдания. Тут только терпеть. Мы сейчас играм на чужом поле, не нам диктовать терминологию. А вот, например, мистеры из SDH’а на 40 лет дольше разговаривают на этом языке, поэтому для них это норма.

Если внешний источник отвалится или частота станет нестабильной, то железка перейдет на внутренний генератор в режим Holdover. Этот режим будет характеризоваться ухудшением параметров clockClass, clockAccuracy и сопровождаться перезапуском BMCA в попытке найти что-то повеселее.

Антракт

Дальше у меня уже была написана часть главы про G.8275.1, ради которого весь цикл статей и затевался, но я устал, я ухожук не хочется повторять ошибок прошлого и раздувать статью до размеров дешевого романа. Так что об этом в следующий раз. Здесь бы еще надо добавить, что до потопа был PTPv1, который обеспечивал микросекундную точность, но нам он неинтересен, потому что устарел и несовместим с PTPv2. Также хорошо было бы написать про PTPv2.1, который обратно совместим с v2 и из важного для нас разве что научился в специальные TLV для аутентификации, но я его в глаза не видел. Встретимся в сетях!

Всякое почитать на чужой мове:

Отличные статьи от Хуавея

https://support.huawei.ru/enterprise/en/doc/EDOC1100366532/d8310318/1588v2-description

https://info.support.huawei.com/info-finder/encyclopedia/en/1588v2.html

Блог крутого любителя PTP (там куча статей пятиминуток)

https://blog.meinbergglobal.com/2023/06/01/when-a-boundary-clock-is-the-grandmaster-in-a-ptp-network/

https://blog.meinbergglobal.com/2022/02/01/bmca-deep-dive-part-1/

Хорошие обрывки платных статей

https://networklessons.com/ip-services/precision-time-protocol-ptp-explained

Цискины обширные статьи

https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/5x/system-management-configuration/cisco-apic-system-management-configuration-guide-51x/m-precision-time-protocol.html

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-12/configuration_guide/lyr2/b_1612_lyr2_9500_cg/configuring_precision_time_protocol__ptp_.html

Нокия почему-то решила, что краткость - сестра таланта

https://documentation.nokia.com/html/0_add-h-f/93-0267-HTML/7X50_Advanced_Configuration_Guide/ACG- IEEE-1588-FP-TD.html

Неплохие заметки

https://www.techplayon.com/ieee-1588-precision-time-protocol-ptp-for-telecom-networks/