Введение
Концепция построения «Цифровой подстанции» в электроэнергетике требует синхронизации с точностью 1 мкс. Для проведения финансовых транзакций также требуется точность в мкс. В этих приложениях точности времени NTP уже недостаточно.
Протокол синхронизации PTPv2, описанный стандартом IEEE 1588v2, позволяет добиться точности синхронизации в несколько десятков наносекунд. PTPv2 позволяет отправлять пакеты синхронизации через L2 и L3-сети.
Основными областями, где применяется PTPv2, являются:
В данном посте разбирается, как работает протокол синхронизации PTPv2.
У нас больше опыта в промышленности и мы часто встречаемся с этим протоколом в энергетических приложениях. Соответственно, и обзор сделаем с оглядкой на энергетику.
Зачем необходим?
На данный момент в СТО 34.01-21-004-2019 ПАО «Россети» и в СТО 56947007-29.240.10.302-2020 ПАО «ФСК ЕЭС» содержатся требования к организации шины процесса с обеспечением синхронизации времени по PTPv2.
Связано это с тем, что к шине процесса подключаются терминалы релейной защиты и устройства измерения, которые через шину процесса, при помощи так называемых SV-потоков (multicast-потоки), передают мгновенные значения тока и напряжения.
Терминалы релейной защиты используют эти значения для реализации защит присоединений. Если точность измерений по времени будет небольшой, то некоторые защиты могут ложно отрабатывать.
Например, жертвой «слабой» синхронизации времени могут стать защиты абсолютной селективности. Часто логика подобных защит строится на сравнении двух величин. Если величины расходятся на достаточно большое значение, то защита срабатывает. Если эти величины измерить с точностью времени 1 мс, то можно получить большую разницу там, где значения на самом деле находятся в норме, если измерить их с точностью 1 мкс.
Версии PTP
Протокол PTP был изначально описан в 2002 году в стандарте IEEE 1588-2002 и имел название «Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems». В 2008 году был выпущен обновленный стандарт IEEE 1588-2008, который описывает PTP Version 2. В этой версии протокола была улучшена точность и стабильность, но не была сохранена обратная совместимость с первой версией протокола. Также, в 2019 году вышла версия стандарта IEEE 1588-2019, описывающая PTP v2.1. Эта версия добавляет небольшие улучшения к PTPv2 и является обратно совместимой с PTPv2.
Другими словами, имеем следующую картину с версиями:
Но, как и всегда, есть нюансы.
Несовместимость между PTPv1 и PTPv2 предполагает, что устройство с поддержкой PTPv1 не сможет синхронизироваться от точных часов, работающих на PTPv2. Для синхронизации они используют разные форматы сообщений.
Но совместить устройства c PTPv1 и устройства с PTPv2 в одной сети все-таки можно. Для этого некоторые производители позволяют на портах граничных часов выбирать версию протокола. То есть, граничные часы могут синхронизироваться по PTPv2 и при этом синхронизировать другие подключенные к ним часы и по PTPv1, и по PTPv2.
Устройства PTP. Какие бывают и чем различаются?
Стандартом IEEE 1588v2 описано несколько типов устройств. Все они приведены в таблице.
Устройства взаимодействуют друг с другом через ЛВС, используя PTP.
Устройства PTP называются часами. Все часы берут точное время у гроссмейстерских часов.
Есть 5 типов часов:
Ведущие и ведомые часы синхронизируются при помощи меток времени в PTP-сообщениях. Есть два типа сообщений в PTP-протоколе:
Далее будут рассмотрены все типы сообщений более подробно.
Основные проблемы синхронизации
При передаче пакета синхронизации через локальную сеть он задерживается на коммутаторе и в канале передачи данных. Любой коммутатор будет давать задержку около 10 мкс, что недопустимо для PTPv2. Ведь нам на конечном устройстве необходимо получить точность 1 мкс. (Это если речь идет про энергетику. Другие приложения могут требовать и большей точности.)
В IEEE 1588v2 описаны несколько алгоритмов работы, которые позволяют фиксировать задержку времени и корректировать ее.
Алгоритм работы
При нормальной работе протокол работает в две фазы.
Фаза 1 — Установка иерархии «Мастер-Слэйв»
Каждый порт обычных или граничных часов имеет определенное количество состояний (ведомые часы и ведущие часы). Стандарт описывает алгоритм перехода между этими состояниями. В программировании такой алгоритм называется конечным автоматом или машиной состояний (подробнее в Wiki).
Этот конечный автомат использует алгоритм Best Master Clock Algorithm (BMCA) для установки мастера при соединении двух часов.
Данный алгоритм позволяет часам брать на себя обязательства гроссмейстерских часов, когда вышестоящие гроссмейстерские часы теряют сигнал GPS, отключаются от сети и т.д.
Переходы между состояниями в соответствии с BMCA кратко отображены на следующей схеме:
Информация о часах на другом конце «провода» присылается в специальном сообщении (Announce message). Когда эта информация получена, алгоритм машины состояний отрабатывает и выполняется сравнение, какие часы лучше. Порт на лучших часах становится ведущими часами.
Простая иерархия представлена схеме ниже. Пути 1, 2, 3, 4, 5 могут содержать прозрачные часы (Transparent clock), но они не участвуют в установлении иерархии «Ведущие часы – Ведомые часы».
Фаза 2 — Синхронизация обычных и граничных часов
Сразу после установки иерархии «Ведущие часы – Ведомые часы» начинается фаза синхронизации обычных и граничных часов.
Для синхронизации ведущие часы отправляют ведомым часам сообщение, содержащее метку времени.
Ведущие часы могут быть:
Одноступенчатые часы для синхронизации посылают одно сообщение Sync.
Двухступенчатые часы для синхронизации используют два сообщения – Sync и Follow_Up.
Для фазы синхронизации могут быть использованы два механизма:
Для начала рассмотрим эти механизмы в самом простейшем случае – когда не применяются прозрачные часы.
Механизм запроса-ответа задержки (Delay request-response mechanism)
Механизм предполагает два шага:
Измерение задержки
t1 – Время отправки сообщения Sync ведущими часами; t2 – Время приема сообщения Sync ведомыми часами; t3 – Время отправки запроса задержки (Delay_Req) ведомыми часами; t4 – Время приема Delay_Req ведущими часами.
Когда ведомые часы знают время t1, t2, t3 и t4, то они могут рассчитать среднюю задержку при передаче сообщения синхронизации (tmpd). Она рассчитывается следующим образом:
При передаче сообщения Sync и Follow_Up вычисляется задержка времени от мастера к слэйву – t-ms.
При передаче сообщений Delay_Req и Delay_Resp вычисляется задержка времени от слэйва к мастеру – t-sm.
Если между этими двумя значениями возникает какая-то асимметрия, то появляется ошибка коррекции ухода точного времени. Ошибка обуславливается тем, что вычисленная задержка является средним от задержек t-ms и t-sm. Если задержки не равны друг другу, то мы будем корректировать время неточно.
Коррекция сдвига точного времени
После того как задержка между ведущими часами и ведомыми часами известна, ведомые часы выполняют коррекцию времени.
Ведомые часы используют сообщение Sync и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:
Механизм измерения задержки соседнего узла (Peer delay measurement mechanism)
Данный механизм также использует два шага для синхронизации:
Измерение задержки между устройствами, поддерживающих режим Peer-to-Peer
Задержка между портами, поддерживающими механизм peer-to-peer, измеряется при помощи следующих сообщений:
Когда порту 1 известно время t1, t2, t3 и t4, он может рассчитать среднюю задержку (tmld). Она рассчитывается по следующей формуле:
Затем порт использует это значение при расчете поля корректировки для каждого сообщения Sync или опционального сообщения Follow_Up, которые проходят через данное устройство.
Итоговая задержка будет равна сумме задержки при передаче через данное устройство, средней задержке при передаче через канал данных и уже содержащейся задержки в данном сообщении, включенной на вышестоящих устройствах.
Сообщения Pdelay_Req, Pdelay_Resp и опциональное Pdelay_Resp_Follow_Up позволяет получить задержку от мастера к слэйву и от слэйва к мастеру (круговую).
Любая асимметрия между этими двумя значениями привнесет ошибку коррекции сдвига точного времени.
Корректировка сдвига точного времени
Ведомые часы используют Sync-сообщение и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг расcчитывается по следующей формуле:
Преимущества корректировка механизма peer-to-peer – задержка времени каждого сообщения Sync или Follow_Up рассчитывается по ходу его передачи в сети. Следовательно, и изменение пути передачи не повлияет никаким образом на точность корректировки.
При использовании этого механизма синхронизация времени не требует расчета задержки времени на пройденном пакетом синхронизации пути, как это делается при базовом обмене. Т.е. сообщения Delay_Req и Delay_Resp не отправляются. В этом методе задержка между ведущими часами и ведомыми просто суммируется в поле корректировки каждого сообщения Sync или Follow_Up.
Еще одно преимущество – ведущие часы разгружаются от необходимости обрабатывать сообщения Delay_Req.
Режимы работы прозрачных часов
Соответственно, это были разобраны простые примеры. А теперь предположим, что на пути синхронизации появляются коммутаторы.
Если использовать коммутаторы без поддержки PTPv2, то пакет синхронизации будет задерживаться на коммутаторе примерно на 10 мкс.
Коммутаторы с поддержкой PTPv2 в терминологии IEEE 1588v2 называются прозрачными часами (Transparent clock). Прозрачные часы не синхронизируются от ведущих часов и не участвуют в иерархии «Ведущие часы – Ведомые часы», но при передаче сообщений синхронизации запоминают, на сколько сообщение задержалось на них. Это позволяет скорректировать задержку времени.
Прозрачные часы могут работать в двух режимах:
End-to-End (E2E)
Прозрачные часы E2E передают сообщения Sync и сопутствующие сообщения Follow_Up на все порты. Даже на те, которые заблокированы какими-либо протоколами (например, RSTP).
Коммутатор запоминает метку времени, когда пакет Sync (Follow_Up) был принят на порт и когда был отправлен с порта. На основании этих двух меток времени вычисляется время обработки коммутатором сообщения. В стандарте это время называется residence time.
Время обработки добавляется в поле correctionField сообщения Sync (одноступенчатые часы) или Follow_Up (двухступенчатые часы).
Прозрачные часы E2E измеряют время обработки для сообщений Sync и Delay_Req, проходящих через коммутатор. Но при этом важно понимать, что задержка времени между ведущими часами и ведомыми часами вычисляется при помощи механизма запроса-ответа задержки. Если ведущие часы меняются или меняется путь от ведущих часов до ведомых, то задержка измеряется заново. Это увеличивает время переходного состояния в случае изменений сети.
Прозрачные часы P2P, помимо измерения времени обработки сообщения коммутатором, измеряют задержку на канале передачи данных до ближайшего соседа, используя механизм измерения задержки соседнего узла.
Задержка измеряется на каждом канале в обоих направлениях, включая каналы, которые заблокированы каким-либо протоколом (например, RSTP). Это позволяет сразу вычислить новую задержку на пути синхронизации, если изменились гроссмейстерские часы или топология сети.
Время обработки сообщений коммутаторами и время задержки аккумулируются при передачи сообщений Sync или Follow_Up.
Типы поддержки PTPv2 коммутаторами
Коммутаторы могут поддерживать PTPv2:
При программной реализации протокола PTPv2 коммутатор запрашивает метку времени у прошивки. Проблема заключается в том, что прошивка работает циклически, и придется подождать, пока она закончит текущий цикл, возьмет запрос в обработку и по истечению следующего цикла выдаст метку времени. На это все также уйдет время, и мы получим задержку, пусть и не такую существенную как без программной поддержки PTPv2.
Соблюсти необходимую точность позволяет только аппаратная поддержка PTPv2. В этом случае выдача метки времени выполняется специальным ASIC’ом, который установлен на порт.
Формат сообщения
Все сообщения PTP состоят из следующих полей:
Header
Поле Header одинаково для всех сообщений PTP. Его размер – 34 байта.
Формат поля Header:
messageType – содержит тип передаваемого сообщения, например Sync, Delay_Req, PDelay_Req и т.д.
messageLength – содержит полный размер сообщения PTP, включая header, body и suffix (но исключая заполняющие байты).
domainNumber – определяет, к какому домену PTP принадлежит сообщение.
Домен – это несколько разных часов, собранных в одну логическую группу и синхронизированных от одних ведущих часов, но не обязательно синхронизированных с часами, принадлежащими к другому домену.
flags – это поле содержит различные флаги для идентификации статуса сообщения.
correctionField – содержит время задержки в наносекундах. Время задержки включает в себя задержку при передаче через прозрачные часы, а также задержку при передаче через канал при использовании режима Peer-to-Peer.
sourcePortIdentity – данное поле содержит информацию о том, с какого порта было изначально отправлено данное сообщение.
sequenceID – содержит идентификационный номер для индивидуальных сообщений.
controlField – поле-артефакт=) Оно осталось от первой версии стандарта и содержит в себе информацию о типе данного сообщения. По сути, то же самое, что и messageType, но с меньшим количеством опций.
logMessageInterval – данное поле определяется типом сообщения.
Body
Как обсуждалось выше, существует несколько типов сообщений. Эти типы описаны ниже:
Сообщение Announce
Сообщение Announce используется для того, чтобы «рассказать» другим часам внутри одного домена о своих параметрах. Это сообщение позволяет установить иерархию «Ведущие часы – Ведомые часы».
Сообщение Sync
Сообщение синхронизации (Sync) отправляется ведущими часами и содержит время ведущих часов на момент, когда сообщение Sync было создано. Если ведущие часы двухступенчатые, то метка времени в сообщении Sync будет приравнена к 0, а актуальная метка времени будет послана в сопряженном сообщении Follow_Up. Сообщение Sync используется для обоих механизмов измерения задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Delay_Req
Формат сообщения Delay_Req идентичен сообщению Sync. Ведомые часы посылают Delay_Req. Оно содержит время отправки Delay_Req ведомыми часами. Данное сообщение используется только для механизма запроса-ответа задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Follow_Up
Сообщение Follow_Up опционально отправляется ведущими часами и содержит время отправки сообщения Sync мастером. Сообщение Follow_Up отправляют только двухступенчатые ведущие часы.
Сообщение Follow_Up используется для обоих механизмов измерения задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Delay_Resp
Сообщение Delay_Resp отправляется ведущими часами. Оно содержит время приема Delay_Req ведущими часами. Данное сообщение используется только для механизма запроса-ответа задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Pdelay_Req
Сообщение Pdelay_Req отправляется устройством, которое запрашивает задержку. Оно содержит время отправки сообщения с порта этого устройства. Pdelay_Req используется только для механизма измерения задержки соседнего узла.
Сообщение Pdelay_Resp
Сообщение Pdelay_Resp отправляется устройством, которое получило запрос на задержку. Оно содержит время приема собщения Pdelay_Req данным устройством. Сообщения Pdelay_Resp используется только для механизма измерения задержки соседнего узла.
Сообщение Pdelay_Resp_Follow_Up
Сообщение Pdelay_Resp_Follow_Up опционально отправляется устройством, которое получило запрос на задержку. Оно содержит время приема сообщения Pdelay_Req этим устройством. Сообщение Pdelay_Resp_Follow_Up отправляется только двухступенчатыми ведущими часами.
Также это сообщение может использоваться для времени исполнения вместо метки времени. Время исполнения – это время от момента получения Pdelay-Req до отправки Pdelay_Resp.
Pdelay_Resp_Follow_Up используются только для механизма измерения задержки соседнего узла.
Управляющие сообщения (Сообщение Management)
Управляющие сообщения PTP необходимы для передачи информации между одними или несколькими часами и управляющим узлом.
Передача в ЛВ
PTP-сообщение может передаваться на двух уровнях:
Передача сообщения PTP через UDP через IP через Ethernet
PTP через UDP через Ethernet
Профили
PTP имеет достаточно много «гибких» параметров, которые необходимы настроить. Например:
И несмотря на то, что ранее мы говорили, что устройства PTPv2 совместимы между собой, по-хорошему это не так. Устройства должна иметь одинаковые настройки, чтобы взаимодействовать.
Поэтому существуют так называемые профили PTPv2. Профили являются группами сконфигурированных настроек и определенных ограничений протокола, чтобы можно было реализовать синхронизацию времени для определенного приложения.
Сам стандарт IEEE 1588v2 описывает только один профиль – “Default Profile”. Все остальные профили созданы и описаны различными организациями и ассоциациями.
Например, профиль для электроэнергетики или PTPv2 Power Profile был создан комитетом Power Systems Relaying Committee и комитетом Substation Committee общества IEEE Power and Energy Society. Сам профиль носит название IEEE C37.238- 2011.
Профиль описывает, что PTP может передаваться:
Домен по умолчанию – 0, рекомендуемый домен – 93.
В философии создания C37.238- 2011 лежало желание уменьшить количество опциональных характеристик и оставить только необходимые функции для надежного взаимодействия между устройствами и повышения стабильности системы.
Также, определена частота передачи сообщений:
По сути для выбора доступен только один параметр – тип ведущих часов (одноступенчатые или двухступенчатые).
Точность должна быть не более 1 мкс. Другими словами в одном пути синхронизации может содержаться максимально 15 прозрачных часов или трое граничных часов.
Концепция построения «Цифровой подстанции» в электроэнергетике требует синхронизации с точностью 1 мкс. Для проведения финансовых транзакций также требуется точность в мкс. В этих приложениях точности времени NTP уже недостаточно.
Протокол синхронизации PTPv2, описанный стандартом IEEE 1588v2, позволяет добиться точности синхронизации в несколько десятков наносекунд. PTPv2 позволяет отправлять пакеты синхронизации через L2 и L3-сети.
Основными областями, где применяется PTPv2, являются:
- энергетика;
- контрольно-измерительное оборудование;
- оборонно-промышленный комплекс;
- телеком;
- финансовый сектор.
В данном посте разбирается, как работает протокол синхронизации PTPv2.
У нас больше опыта в промышленности и мы часто встречаемся с этим протоколом в энергетических приложениях. Соответственно, и обзор сделаем с оглядкой на энергетику.
Зачем необходим?
На данный момент в СТО 34.01-21-004-2019 ПАО «Россети» и в СТО 56947007-29.240.10.302-2020 ПАО «ФСК ЕЭС» содержатся требования к организации шины процесса с обеспечением синхронизации времени по PTPv2.
Связано это с тем, что к шине процесса подключаются терминалы релейной защиты и устройства измерения, которые через шину процесса, при помощи так называемых SV-потоков (multicast-потоки), передают мгновенные значения тока и напряжения.
Терминалы релейной защиты используют эти значения для реализации защит присоединений. Если точность измерений по времени будет небольшой, то некоторые защиты могут ложно отрабатывать.
Например, жертвой «слабой» синхронизации времени могут стать защиты абсолютной селективности. Часто логика подобных защит строится на сравнении двух величин. Если величины расходятся на достаточно большое значение, то защита срабатывает. Если эти величины измерить с точностью времени 1 мс, то можно получить большую разницу там, где значения на самом деле находятся в норме, если измерить их с точностью 1 мкс.
Версии PTP
Протокол PTP был изначально описан в 2002 году в стандарте IEEE 1588-2002 и имел название «Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems». В 2008 году был выпущен обновленный стандарт IEEE 1588-2008, который описывает PTP Version 2. В этой версии протокола была улучшена точность и стабильность, но не была сохранена обратная совместимость с первой версией протокола. Также, в 2019 году вышла версия стандарта IEEE 1588-2019, описывающая PTP v2.1. Эта версия добавляет небольшие улучшения к PTPv2 и является обратно совместимой с PTPv2.
Другими словами, имеем следующую картину с версиями:
| PTPv1 (IEEE 1588-2002) |
PTPv2 (IEEE 1588-2008) |
PTPv2.1 (IEEE 1588-2019) |
|
| PTPv1 (IEEE 1588-2002) |
— | Несовместимы |
Несовместимы |
| PTPv2 (IEEE 1588-2008) |
Несовместимы |
— | Совместимы |
| PTPv2.1 (IEEE 1588-2019) |
Несовместимы |
Совместимы |
— |
Но, как и всегда, есть нюансы.
Несовместимость между PTPv1 и PTPv2 предполагает, что устройство с поддержкой PTPv1 не сможет синхронизироваться от точных часов, работающих на PTPv2. Для синхронизации они используют разные форматы сообщений.
Но совместить устройства c PTPv1 и устройства с PTPv2 в одной сети все-таки можно. Для этого некоторые производители позволяют на портах граничных часов выбирать версию протокола. То есть, граничные часы могут синхронизироваться по PTPv2 и при этом синхронизировать другие подключенные к ним часы и по PTPv1, и по PTPv2.
Устройства PTP. Какие бывают и чем различаются?
Стандартом IEEE 1588v2 описано несколько типов устройств. Все они приведены в таблице.
Устройства взаимодействуют друг с другом через ЛВС, используя PTP.
Устройства PTP называются часами. Все часы берут точное время у гроссмейстерских часов.
Есть 5 типов часов:
| Grandmaster clock (Гроссмейстерские часы) |
Основной источник точного времени. Часто оснащаются интерфейсом для подключения GPS. |
| Ordinary Clock (Обычные часы) |
Устройство с одним портом, которое может быть мастером (ведущими часами) или слэйвом (ведомыми часами) |
| Ведущие часы (мастер) |
Являются источником точно времени, по которому синхронизируются другие часы |
| Ведомые часы (слэйв) |
Конечное устройство, которое синхронизируется от ведущих часов |
| Boundary Clock (Граничные часы) |
Устройство с несколькими портами, которое может быть мастером или слейвом. То есть эти часы могут синхронизироваться от вышестоящих ведущих часов и синхронизировать нижестоящие ведомые часы. |
| End-to-end Transparent Clock (Прозрачные часы, работающие в режиме End-to-End) |
Устройство с несколькими портами, которое не является ни ведущими часами, ни ведомыми. Оно передает данные PTP между двумя часами. При передачи данных прозрачные часы корректируют все PTP-сообщения. Корректировка происходит за счет добавления времени задержки на этом устройстве в поле коррекции в заголовке передаваемого сообщения. |
| Peer-to-Peer Transparent Clock (Прозрачные часы, работающие в режиме Peer-to-Peer) |
Устройство с несколькими портами, которое не является ни ведущими часами, ни ведомыми. Оно передает данные PTP между двумя часами. При передачи данных прозрачные часы корректируют все PTP-сообщения Sync и Follow_Up (про них подробнее рассказано ниже). Корректировка достигается за счет добавления к полю корректировки передаваемого пакета задержки на передающем устройстве и задержки на канале передачи данных. |
| Management Node (Управляющий узел) |
Устройство, которое конфигурирует и диагностирует другие часы |
Ведущие и ведомые часы синхронизируются при помощи меток времени в PTP-сообщениях. Есть два типа сообщений в PTP-протоколе:
- Event Messages – это синхронизированные сообщения, которые предполагают генерацию метки времени в момент отправки сообщения и в момент его приема
- General Messages – эти сообщения не требуют меток времени, но могут содержать метки времени для связанных сообщений
| Event Messages |
General Messages |
| Sync Delay_Req Pdelay_Req Pdelay_Resp |
Announce Follow_Up Delay_Resp Pdelay_Resp_Follow_Up Management Signaling |
Далее будут рассмотрены все типы сообщений более подробно.
Основные проблемы синхронизации
При передаче пакета синхронизации через локальную сеть он задерживается на коммутаторе и в канале передачи данных. Любой коммутатор будет давать задержку около 10 мкс, что недопустимо для PTPv2. Ведь нам на конечном устройстве необходимо получить точность 1 мкс. (Это если речь идет про энергетику. Другие приложения могут требовать и большей точности.)
В IEEE 1588v2 описаны несколько алгоритмов работы, которые позволяют фиксировать задержку времени и корректировать ее.
Алгоритм работы
При нормальной работе протокол работает в две фазы.
- Фаза 1 — установка иерархии «Ведущие часы – Ведомые часы».
- Фаза 2 — синхронизация часов при помощи механизма End-to-End или Peer-to-Peer.
Фаза 1 — Установка иерархии «Мастер-Слэйв»
Каждый порт обычных или граничных часов имеет определенное количество состояний (ведомые часы и ведущие часы). Стандарт описывает алгоритм перехода между этими состояниями. В программировании такой алгоритм называется конечным автоматом или машиной состояний (подробнее в Wiki).
Этот конечный автомат использует алгоритм Best Master Clock Algorithm (BMCA) для установки мастера при соединении двух часов.
Данный алгоритм позволяет часам брать на себя обязательства гроссмейстерских часов, когда вышестоящие гроссмейстерские часы теряют сигнал GPS, отключаются от сети и т.д.
Переходы между состояниями в соответствии с BMCA кратко отображены на следующей схеме:
Информация о часах на другом конце «провода» присылается в специальном сообщении (Announce message). Когда эта информация получена, алгоритм машины состояний отрабатывает и выполняется сравнение, какие часы лучше. Порт на лучших часах становится ведущими часами.
Простая иерархия представлена схеме ниже. Пути 1, 2, 3, 4, 5 могут содержать прозрачные часы (Transparent clock), но они не участвуют в установлении иерархии «Ведущие часы – Ведомые часы».
Фаза 2 — Синхронизация обычных и граничных часов
Сразу после установки иерархии «Ведущие часы – Ведомые часы» начинается фаза синхронизации обычных и граничных часов.
Для синхронизации ведущие часы отправляют ведомым часам сообщение, содержащее метку времени.
Ведущие часы могут быть:
- одноступенчатые;
- двухступенчатые.
Одноступенчатые часы для синхронизации посылают одно сообщение Sync.
Двухступенчатые часы для синхронизации используют два сообщения – Sync и Follow_Up.
Для фазы синхронизации могут быть использованы два механизма:
- Механизм запроса-ответа задержки (Delay request-response mechanism).
- Механизм измерения задержки соседнего узла (Peer delay measurement mechanism).
Для начала рассмотрим эти механизмы в самом простейшем случае – когда не применяются прозрачные часы.
Механизм запроса-ответа задержки (Delay request-response mechanism)
Механизм предполагает два шага:
- Измерение задержки при передаче сообщения между ведущими часами и ведомыми. Выполняется при помощи механизма запроса-ответа задержки.
- Выполняется коррекция сдвига точного времени.
Измерение задержки
t1 – Время отправки сообщения Sync ведущими часами; t2 – Время приема сообщения Sync ведомыми часами; t3 – Время отправки запроса задержки (Delay_Req) ведомыми часами; t4 – Время приема Delay_Req ведущими часами.
Когда ведомые часы знают время t1, t2, t3 и t4, то они могут рассчитать среднюю задержку при передаче сообщения синхронизации (tmpd). Она рассчитывается следующим образом:
При передаче сообщения Sync и Follow_Up вычисляется задержка времени от мастера к слэйву – t-ms.
При передаче сообщений Delay_Req и Delay_Resp вычисляется задержка времени от слэйва к мастеру – t-sm.
Если между этими двумя значениями возникает какая-то асимметрия, то появляется ошибка коррекции ухода точного времени. Ошибка обуславливается тем, что вычисленная задержка является средним от задержек t-ms и t-sm. Если задержки не равны друг другу, то мы будем корректировать время неточно.
Коррекция сдвига точного времени
После того как задержка между ведущими часами и ведомыми часами известна, ведомые часы выполняют коррекцию времени.
Ведомые часы используют сообщение Sync и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:
Механизм измерения задержки соседнего узла (Peer delay measurement mechanism)
Данный механизм также использует два шага для синхронизации:
- Устройства измеряют задержку времени до всех соседей через все порты. Для этого они используют peer delay mechanism.
- Корректировка сдвига точного времени.
Измерение задержки между устройствами, поддерживающих режим Peer-to-Peer
Задержка между портами, поддерживающими механизм peer-to-peer, измеряется при помощи следующих сообщений:
Когда порту 1 известно время t1, t2, t3 и t4, он может рассчитать среднюю задержку (tmld). Она рассчитывается по следующей формуле:
Затем порт использует это значение при расчете поля корректировки для каждого сообщения Sync или опционального сообщения Follow_Up, которые проходят через данное устройство.
Итоговая задержка будет равна сумме задержки при передаче через данное устройство, средней задержке при передаче через канал данных и уже содержащейся задержки в данном сообщении, включенной на вышестоящих устройствах.
Сообщения Pdelay_Req, Pdelay_Resp и опциональное Pdelay_Resp_Follow_Up позволяет получить задержку от мастера к слэйву и от слэйва к мастеру (круговую).
Любая асимметрия между этими двумя значениями привнесет ошибку коррекции сдвига точного времени.
Корректировка сдвига точного времени
Ведомые часы используют Sync-сообщение и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг расcчитывается по следующей формуле:
Преимущества корректировка механизма peer-to-peer – задержка времени каждого сообщения Sync или Follow_Up рассчитывается по ходу его передачи в сети. Следовательно, и изменение пути передачи не повлияет никаким образом на точность корректировки.
При использовании этого механизма синхронизация времени не требует расчета задержки времени на пройденном пакетом синхронизации пути, как это делается при базовом обмене. Т.е. сообщения Delay_Req и Delay_Resp не отправляются. В этом методе задержка между ведущими часами и ведомыми просто суммируется в поле корректировки каждого сообщения Sync или Follow_Up.
Еще одно преимущество – ведущие часы разгружаются от необходимости обрабатывать сообщения Delay_Req.
Режимы работы прозрачных часов
Соответственно, это были разобраны простые примеры. А теперь предположим, что на пути синхронизации появляются коммутаторы.
Если использовать коммутаторы без поддержки PTPv2, то пакет синхронизации будет задерживаться на коммутаторе примерно на 10 мкс.
Коммутаторы с поддержкой PTPv2 в терминологии IEEE 1588v2 называются прозрачными часами (Transparent clock). Прозрачные часы не синхронизируются от ведущих часов и не участвуют в иерархии «Ведущие часы – Ведомые часы», но при передаче сообщений синхронизации запоминают, на сколько сообщение задержалось на них. Это позволяет скорректировать задержку времени.
Прозрачные часы могут работать в двух режимах:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Прозрачные часы E2E передают сообщения Sync и сопутствующие сообщения Follow_Up на все порты. Даже на те, которые заблокированы какими-либо протоколами (например, RSTP).
Коммутатор запоминает метку времени, когда пакет Sync (Follow_Up) был принят на порт и когда был отправлен с порта. На основании этих двух меток времени вычисляется время обработки коммутатором сообщения. В стандарте это время называется residence time.
Время обработки добавляется в поле correctionField сообщения Sync (одноступенчатые часы) или Follow_Up (двухступенчатые часы).
Прозрачные часы E2E измеряют время обработки для сообщений Sync и Delay_Req, проходящих через коммутатор. Но при этом важно понимать, что задержка времени между ведущими часами и ведомыми часами вычисляется при помощи механизма запроса-ответа задержки. Если ведущие часы меняются или меняется путь от ведущих часов до ведомых, то задержка измеряется заново. Это увеличивает время переходного состояния в случае изменений сети.
Прозрачные часы P2P, помимо измерения времени обработки сообщения коммутатором, измеряют задержку на канале передачи данных до ближайшего соседа, используя механизм измерения задержки соседнего узла.
Задержка измеряется на каждом канале в обоих направлениях, включая каналы, которые заблокированы каким-либо протоколом (например, RSTP). Это позволяет сразу вычислить новую задержку на пути синхронизации, если изменились гроссмейстерские часы или топология сети.
Время обработки сообщений коммутаторами и время задержки аккумулируются при передачи сообщений Sync или Follow_Up.
Типы поддержки PTPv2 коммутаторами
Коммутаторы могут поддерживать PTPv2:
- программно;
- аппаратно.
При программной реализации протокола PTPv2 коммутатор запрашивает метку времени у прошивки. Проблема заключается в том, что прошивка работает циклически, и придется подождать, пока она закончит текущий цикл, возьмет запрос в обработку и по истечению следующего цикла выдаст метку времени. На это все также уйдет время, и мы получим задержку, пусть и не такую существенную как без программной поддержки PTPv2.
Соблюсти необходимую точность позволяет только аппаратная поддержка PTPv2. В этом случае выдача метки времени выполняется специальным ASIC’ом, который установлен на порт.
Формат сообщения
Все сообщения PTP состоят из следующих полей:
- Header – 34 байта.
- Body – размер зависит от типа сообщения.
- Suffix – опционально.
Header
Поле Header одинаково для всех сообщений PTP. Его размер – 34 байта.
Формат поля Header:
messageType – содержит тип передаваемого сообщения, например Sync, Delay_Req, PDelay_Req и т.д.
messageLength – содержит полный размер сообщения PTP, включая header, body и suffix (но исключая заполняющие байты).
domainNumber – определяет, к какому домену PTP принадлежит сообщение.
Домен – это несколько разных часов, собранных в одну логическую группу и синхронизированных от одних ведущих часов, но не обязательно синхронизированных с часами, принадлежащими к другому домену.
flags – это поле содержит различные флаги для идентификации статуса сообщения.
correctionField – содержит время задержки в наносекундах. Время задержки включает в себя задержку при передаче через прозрачные часы, а также задержку при передаче через канал при использовании режима Peer-to-Peer.
sourcePortIdentity – данное поле содержит информацию о том, с какого порта было изначально отправлено данное сообщение.
sequenceID – содержит идентификационный номер для индивидуальных сообщений.
controlField – поле-артефакт=) Оно осталось от первой версии стандарта и содержит в себе информацию о типе данного сообщения. По сути, то же самое, что и messageType, но с меньшим количеством опций.
logMessageInterval – данное поле определяется типом сообщения.
Body
Как обсуждалось выше, существует несколько типов сообщений. Эти типы описаны ниже:
Сообщение Announce
Сообщение Announce используется для того, чтобы «рассказать» другим часам внутри одного домена о своих параметрах. Это сообщение позволяет установить иерархию «Ведущие часы – Ведомые часы».
Сообщение Sync
Сообщение синхронизации (Sync) отправляется ведущими часами и содержит время ведущих часов на момент, когда сообщение Sync было создано. Если ведущие часы двухступенчатые, то метка времени в сообщении Sync будет приравнена к 0, а актуальная метка времени будет послана в сопряженном сообщении Follow_Up. Сообщение Sync используется для обоих механизмов измерения задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Delay_Req
Формат сообщения Delay_Req идентичен сообщению Sync. Ведомые часы посылают Delay_Req. Оно содержит время отправки Delay_Req ведомыми часами. Данное сообщение используется только для механизма запроса-ответа задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Follow_Up
Сообщение Follow_Up опционально отправляется ведущими часами и содержит время отправки сообщения Sync мастером. Сообщение Follow_Up отправляют только двухступенчатые ведущие часы.
Сообщение Follow_Up используется для обоих механизмов измерения задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Delay_Resp
Сообщение Delay_Resp отправляется ведущими часами. Оно содержит время приема Delay_Req ведущими часами. Данное сообщение используется только для механизма запроса-ответа задержки.
Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
Сообщение Pdelay_Req
Сообщение Pdelay_Req отправляется устройством, которое запрашивает задержку. Оно содержит время отправки сообщения с порта этого устройства. Pdelay_Req используется только для механизма измерения задержки соседнего узла.
Сообщение Pdelay_Resp
Сообщение Pdelay_Resp отправляется устройством, которое получило запрос на задержку. Оно содержит время приема собщения Pdelay_Req данным устройством. Сообщения Pdelay_Resp используется только для механизма измерения задержки соседнего узла.
Сообщение Pdelay_Resp_Follow_Up
Сообщение Pdelay_Resp_Follow_Up опционально отправляется устройством, которое получило запрос на задержку. Оно содержит время приема сообщения Pdelay_Req этим устройством. Сообщение Pdelay_Resp_Follow_Up отправляется только двухступенчатыми ведущими часами.
Также это сообщение может использоваться для времени исполнения вместо метки времени. Время исполнения – это время от момента получения Pdelay-Req до отправки Pdelay_Resp.
Pdelay_Resp_Follow_Up используются только для механизма измерения задержки соседнего узла.
Управляющие сообщения (Сообщение Management)
Управляющие сообщения PTP необходимы для передачи информации между одними или несколькими часами и управляющим узлом.
Передача в ЛВ
PTP-сообщение может передаваться на двух уровнях:
- Сетевом – в составе IP-данных.
- Канальном – в составе Ethernet-фрейма.
Передача сообщения PTP через UDP через IP через Ethernet
PTP через UDP через Ethernet
Профили
PTP имеет достаточно много «гибких» параметров, которые необходимы настроить. Например:
- Опции BMCA.
- Механизм измерения задержки.
- Интервалы и начальные значения всех конфигурируемых параметров и т.д.
И несмотря на то, что ранее мы говорили, что устройства PTPv2 совместимы между собой, по-хорошему это не так. Устройства должна иметь одинаковые настройки, чтобы взаимодействовать.
Поэтому существуют так называемые профили PTPv2. Профили являются группами сконфигурированных настроек и определенных ограничений протокола, чтобы можно было реализовать синхронизацию времени для определенного приложения.
Сам стандарт IEEE 1588v2 описывает только один профиль – “Default Profile”. Все остальные профили созданы и описаны различными организациями и ассоциациями.
Например, профиль для электроэнергетики или PTPv2 Power Profile был создан комитетом Power Systems Relaying Committee и комитетом Substation Committee общества IEEE Power and Energy Society. Сам профиль носит название IEEE C37.238- 2011.
Профиль описывает, что PTP может передаваться:
- Только через L2-сети (т.е. Ethernet, HSR, PRP, не IP).
- Сообщения передаются только Multicast-рассылкой.
- В качестве механизма измерения задержки используется Peer delay measurement mechanism.
Домен по умолчанию – 0, рекомендуемый домен – 93.
В философии создания C37.238- 2011 лежало желание уменьшить количество опциональных характеристик и оставить только необходимые функции для надежного взаимодействия между устройствами и повышения стабильности системы.
Также, определена частота передачи сообщений:
По сути для выбора доступен только один параметр – тип ведущих часов (одноступенчатые или двухступенчатые).
Точность должна быть не более 1 мкс. Другими словами в одном пути синхронизации может содержаться максимально 15 прозрачных часов или трое граничных часов.
