Протокол сетевого времени: Чем отличается протокол синхронизации времени NTP от SNTP?

• При передаче сообщения 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 для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:

Преимущества корректировка механизма 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

Используется для того, чтобы «рассказать» другим часам внутри одного домена о своих параметрах. Это сообщение позволяет установить иерархию «Ведущие часы — Ведомые часы».

Сообщение Sync

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

Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.

Сообщение Delay_Req

Формат сообщения идентичен сообщению Sync. Ведомые часы посылают Delay_Req. Оно содержит время отправки Delay_Req ведомыми часами. Данное сообщение используется только для механизма запроса-ответа задержки.

Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.

Сообщение Follow_Up

Опционально отправляется ведущими часами и содержит время отправки сообщения Sync мастером. Сообщение Follow_Up отправляют только двухступенчатые ведущие часы. Используется для обоих механизмов измерения задержки и передается при помощи Multicast. Опционально можно использовать Unicast.

Сообщение Delay_Resp

Отправляется ведущими часами. Оно содержит время приема Delay_Req ведущими часами. Данное сообщение используется только для механизма запроса-ответа задержки. Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.

Сообщение Pdelay_Req

Отправляется устройством, которое запрашивает задержку. Оно содержит время отправки сообщения с порта этого устройства. Pdelay_Req используется только для механизма измерения задержки соседнего узла.

Сообщение Pdelay_Resp

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

Сообщение Pdelay_Resp_Follow_Up

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

Также это сообщение может использоваться для времени исполнения вместо метки времени. Время исполнения — это время от момента получения Pdelay-Req до отправки Pdelay_Resp.

Pdelay_Resp_Follow_Up используются только для механизма измерения задержки соседнего узла.

Управляющие сообщения (Сообщение Management)

Необходимы для передачи информации между одними или несколькими часами и управляющим узлом.

Передача в ЛВ

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 прозрачных часов или трое граничных часов.

PTP

Современные системы, такие как системы мониторинга переходных режимов (СМПР), а также релейной защиты и автоматики (РЗА) с применением шины процесса, требуют высокой точности синхронизации времени в пределах 1 мкс. Эти требования являются более жесткими по отношению к требованиям других систем автоматизации подстанций (1-2 мс). Одновременно с этим cегодня в рамках систем автоматизации энергообъектов широкое распространение получают сети Ethernet, по которым осуществляется информационный обмен между SCADA-системами и устройствами РЗА, а также между отдельными устройствами РЗА. Протокол Precision Time Protocol (PTP) является протоколом синхронизации времени, функционирующим по сети Ethernet, не используя выделенные линии связи, и может обеспечить требуемую точность синхронизации времени для устройств РЗА, регистраторов переходных режимов, устройств сопряжения с шиной процесса и других устройств, требующих высокой точности временной синхронизации.

На энергообъектах синхронизация устройств по времени осуществляется уже достаточно много лет. В частности, она необходима для обеспечения возможности соотнесения событий, регистрируемых различными устройствами. При этом наибольшее число способов синхронизации времени обеспечивает точность в пределах 1 мс. С началом внедрения СМПР и систем РЗА с использованием шины процесса возникает необходимость в обеспечении более высокой точности синхронизации устройств по времени – в пределах 1 мкс.

Различают два подхода к выполнению временной синхронизации вторичных устройств:

• Используя независимую систему, включающую в себя выделенные каналы передачи информации и ретрансляторы.
• Используя сеть Ethernet, по которой также производится обмен прикладной информацией между устройствами энергообъекта.

Последующие разделы рассматривают наиболее широко используемые способы синхронизации времени с указанием их достоинств и недостатков.

Исторически системы синхронизации времени на энергообъектах опирались на использование выделенных линий связи (коаксиальных, витой пары, волоконно-оптических линий связи (ВОЛС)). При этом использовались два протокола:

• IRIG-B, предоставляющий информацию о времени и дате наряду с импульсами синхронизации.
• 1-PPS, предоставляющий точный импульс синхронизации времени без информации о времени и дате.

При использовании данных протоколов обмен данными между устройствами РЗА и SCADA-системой, а также между отдельными устройствами РЗА не оказывает влияние на точность синхронизации. Однако стоит отметить, что независимые системы требуют больших затрат при реализации за счет необходимости использования дополнительной кабельной продукции, клеммников, ретрансляторов и др. Также требуется разработка набора соответствующей технической документации. Затраты могут оказаться значительными, в особенности при реализации систем синхронизации времени на объектах высокого напряжения.

Рис. 1 иллюстрирует использование протокола IRIG-B для синхронизации устройств по времени и сети Ethernet для организации информационного обмена между устройствами. Вместо сети Ethernet может быть предусмотрено использование линий связи RS-485, что характерно для более старых энергообъектов.

Наиболее распространённый протокол синхронизации времени, используемый на энергообъектах, – протокол IRIG-B. При реализации систем синхронизации на основе данного протокола требуется использование выделенных линий связи. Протокол может работать в одном из следующих форматов: с передачей информацией в виде импульсов по электрическим связям (коаксиальный кабель или витая пара) или ВОЛС, или с передачей модулированного сигнала с несущей частотой 1 кГц по коаксиальному кабелю. С течением времени протокол IRIG-B расширялся, преимущественно благодаря появлению стандартов IEEE, относящихся к реализации СМПР (IEEE Std 1344-1995, IEEE Std C37.118-2005 и IEEE Std C37.118.1-2011). Данные расширения обеспечивают возможность передачи информации о годе, временном смещении относительно всемирного скоординированного времени (UTC), переходе на летнее время и качестве информации. Вся эта информация используется устройствами систем автоматизации подстанций. Немодулированный сигнал IRIG-B позволяет достичь точности временной синхронизации в микросекундном диапазоне, однако большинство устройств-клиентов не могут обеспечить точность более 1-2 мс в силу своих технических характеристик.

IRIG-B описывает несколько вариантов форматов передачи информации. Однако характеристики интерфейсов синхронизации времени устройств РЗА различных фирм-производителей отличаются, что не позволяет на сервере времени использовать лишь один формат передачи временного кода IRIG-B. Среди наиболее распространенных отличий – использование модулированного/немодулированного сигнала, использование в качестве опорного местного или всемирно скоординированного времени (UTC) и др.

Различные варианты реализации протокола IRIG-B идентифицируются временным кодом. Например:

• B003: немодулированный, без расширений на передачу информации о годе/расширений согласно стандартам IEEE.
• B004: немодулированный, с расширениями на передачу информации о годе/расширениями согласно стандартам IEEE.
• B124: с амплитудной модуляцией, с расширениями на передачу информацию о годе/с расширениями согласно стандарту IEEE.

Рис. 2 демонстрирует сравнение немодулированного и модулированного сигналов, используемых форматами временных кодов (в соответствии со стандартом IRIG Standard 200-04).

Настройки устройств-клиентов, таких как устройств РЗА, должны быть согласованы с настройками ведущих часов: в части всемирно скоординированного времени (UTC)/локального времени, часового пояса и др. Гибкость настройки устройств РЗА значительно различается – даже при использовании устройств одного производителя. Некоторые из устройств РЗА могут быть настроены для приема почти всех форматов временного кода IRIG-B, многие имеют достаточно сильные ограничения в части параметрирования.

Другие проблемы, которые влечет за собой применение протокола IRIG-B, включают в себя: необходимость учета нагрузки на сеть распространения сигналов синхронизации времени, обеспечение защиты от электромагнитных помех, гальваническую развязку цепей и необходимость обслуживания линий связи. Допустимая нагрузка на ведущие часы различается в диапазоне от 18 до 150 мА, при этом устройства РЗА различных фирм-производителей имеют различное потребление (от 5 мА до 10 мА). Указанное усложняет проектирование систем синхронизации времени для большого количества устройств РЗА – например, на распределительных подстанциях (6,6 – 33 кВ).

1-PPS (один импульс в секунду) может использоваться для обеспечения достаточно точной временной синхронизации, однако не предоставляет информацию об астрономическом времени. На сегодняшний день этого достаточно для реализации комплексов РЗА с использованием шины процесса, однако информация о времени, вероятно, потребуется в будущем для проставления меток времени событиям или криптографической аутентификации сообщений.

Использование данного способа синхронизации времени предусмотрено стандартом МЭК 60044-8 и также введено в технических требованиях по реализации цифрового интерфейса для измерительных трансформаторов (известных как МЭК 61850-9-2LE). Разрабатываемый в настоящее время стандарт МЭК 61869-9 также допускает возможность использования данного метода синхронизации устройств по времени по выделенной волоконно-оптической линии связи.

Рис. 3 иллюстрирует требования к импульсу 1PPS. Время изменения сигнала с уровня 10% до уровня 90% мощности (и наоборот) (t_f) сигнала не должно превышать 200 нс. Время существования сигнала на уровне более 50% мощности (t_h) должно находиться в диапазоне от 10 мкс до 500 мс.

1-PPS требует наличие выделенной сети для распространения сигнала. В качестве физической среды передачи данных может использоваться либо электрическая линия связи (коаксиальная/витая пара), либо ВОЛС (многомод/одномод).

Распространение сигналов IRIG-B и 1-PPS организуется значительно проще по электрическим связям, нежели по ВОЛС, поскольку могут предусматриваться многоточечные соединения с учетом допустимой нагрузки на ведущие часы, однако это может приводить к возрастанию потенциала между шкафами. Использование ВОЛС обеспечивает гальваническую развязку и исключает влияние помех, однако в этом случае требуется использование специальных ретрансляторов для распространения сигнала на каждое из устройств РЗА энергообъекта. В частности, МЭК 61850-9-2LE требует использования ВОЛС для передачи сигнала 1-PPS. Указанное, в свою очередь, требует использования либо часов с несколькими выходами, либо разветвителя для передачи сигнала более чем одному устройству сопряжения с шиной процесса.

Задержка распространения сигнала по электрическим связям и ВОЛС составляет приблизительно 5 нс на метр. Результирующее значение может оказаться достаточно большим при протяженных связях и может, в свою очередь, потребовать необходимости компенсации задержки на устройствах-клиентах. МЭК 61850-9-2LE в качестве предельной задержки распространения сигнала устанавливает значение в 2 мкс – при превышении данного значения требуется компенсация. К такой задержке приведет наличие связи около 400 м, и на многих подстанциях высокого напряжения такие расстояния не предел. Компенсация – процесс ручной настройки, при выполнении которой нужно точно учитывать задержку распространения сигнала не только по линии связи, но и через используемые ретрансляторы. Более подробное исследование о задержках распространения сигналов синхронизации по протоколам 1-PPS, IRIG-B и PTP приведены в [1].

Сети Ethernet, которые сегодня все более широко используются в рамках систем автоматизации подстанций, могут также применяться для передачи сигналов синхронизации времени. Указанное позволяет исключить необходимость в прокладке выделенных линий связи, однако требует от устройств РЗА, приборов учета электроэнергии и других вторичных устройств поддержки специальных протоколов.

Наиболее широко распространены два протокола синхронизации времени: Network Time Protocol (NTP) и Precision Time Protocol (PTP). Оба протокола, когда применяются на подстанциях, функционируют, обмениваясь сообщениями по сети Ethernet. Протоколы NTP и PTP обеспечивают компенсацию временных задержек передачи сообщений синхронизации путем двухстороннего информационного обмена. Протокол NTP является более распространённым решением, чем протокол PTP, однако более высокая точность обеспечивается именно при применении последнего за счет использования специального аппаратного обеспечения. На рис. 4 проиллюстрирована топология сети, в рамках которой может применяться как протокол резервирования NTP, так и протокол резервирования PTP.

Механизм функционирования обоих протоколов допускает наличие нескольких ведущих часов, что повышает надежность функционирования системы синхронизации времени на энергообъекте. Кроме этого, наличие нескольких ведущих часов позволяет производить обслуживание одного из них без вывода всей системы из работы.

В течение последних лет протокол NTP широко применяется в рамках энергообъектов. При применении доступных на рынке серверов времени и клиентов (например, устройств РЗА), обладающих поддержкой данного коммуникационного протокола, достижима точность синхронизации времени в диапазоне от 1 до 4 мс. Однако одним из условий обеспечения такой точности является разработка правильной топологии локальной вычислительной сети Ethernet, в которой обеспечивается соответствие и постоянство времен распространения сообщений синхронизации времени от клиента к мастеру и в обратном направлении.

Значительным преимуществом протокола NTP над IRIG-B является то, что передача времени производится в формате UTC. Это удовлетворяет требованиям таких стандартов как МЭК 61850 и IEEE 1815 (DNP), которые требует передачу меток времени событий в формате UTC. При необходимости отображения местного времени на дисплее устройства РЗА требуется ручная установка часового пояса с учетом соответствующего перехода на летнее время. Протокол NTP обеспечивает возможность одновременного использования нескольких серверов времени одним и тем же клиентом для более точной и надежной временной синхронизации. Однако данный протокол не позволяет обеспечить микросекундную точность синхронизации, которая требуется для СМПР и устройств сопряжения с шиной процесса МЭК 61850-9-2.

Стандарт IEEE Std 1588-2008 определяет вторую версию протокола PTP, известную как PTPv2 или 1588v2. Данный протокол обеспечивает высокую точность синхронизации времени, которая достигается путем фиксации меток времени сообщений синхронизации PTP на интерфейсах Ethernet на аппаратном уровне. Использование этих данных позволяет учитывать времена распространения сообщений синхронизации по сети и их обработки серверами времени и клиентами. Процедура проставления меток времени на аппаратном уровне не оказывает влияния на функционирование других коммуникационных протоколов, существующих в рассматриваемой сети Ethernet, поэтому этот же порт может использоваться для трансляции данных согласно протоколам стандарта МЭК 61850, DNP3, МЭК 60870-5-104, Modbus/IP и другим коммуникационным протоколам. Наличие возможности проставлять метки времени на аппаратном уровне приводит к значительному удорожанию коммутаторов Ethernet. Что касается поддержки протокола PTP в устройствах РЗА, то лишь последние модификации устройств некоторых фирм-производителей поддерживают данный протокол, иногда это доступно лишь только в качестве опции.

Протокол PTP обеспечивает возможность наличия в сети нескольких устройств, способных выступать в качестве серверов времени; при этом предполагается, что все они участвуют в голосовании между собой на выбор самых точных часов – гроссмейстерских. Если вдруг гроссмейстерские часы отказывают или же ухудшаются показатели их функционирования, роль гроссмейстерских часов на себя могут взять другие часы, претендующие на эту роль. Количество времени, которое уходит на данную процедуру, может быть различным, однако если настройки протокола PTP (также именуемые профилем) оптимизированы для его применения на объектах электроэнергетики, то на это уходит не более 5 секунд.

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

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

Стандарт IEEE Std 1588-2008 определяет несколько терминов, применимых для систем, функционирующих по условиям протокола PTP. Основными являются следующие термины:

• Гроссмейстерские часы – часы, являющиеся основным источником данных о времени при синхронизации согласно протоколу PTP, которые, как правило, оснащаются встроенным приемником сигналов GPS (или другой системы).
• Ведущие часы – часы, являющиеся источником данных о времени, по которым синхронизируются другие часы в сети.
• Ведомые часы – конечное устройство, которое синхронизируется по протоколу PTP; это может быть устройство РЗА с нативной поддержкой протокола PTP или преобразователь, который с одной стороны получает информацию в формате протокола PTP, а с другой – формирует данные в формате протоколов IRIG-B или 1-PPS.
• Прозрачные часы – коммутатор Ethernet, который измеряет время прохождения сообщения синхронизации через себя и предоставляет измеренное значение часам, получающим сообщение синхронизации далее.
• Граничные часы – часы, которые оснащаются несколькими портами PTP и могут выступать ведущими часами; например, могут быть ведомыми по отношению к вышестоящим источникам сигналов времени и выступать в качестве ведущих по отношению к нижестоящим устройствам.

В сети должны присутствовать, как минимум, одни гроссмейстерские и одни ведомые часы. Однако во многих случаях, учитывая необходимость объединения многих устройств в одну сеть, понадобится использование коммутаторов, которые, в простейшем случае, будут выполнять роль прозрачных часов. Они могут также выполнять роль граничных часов, что в некоторых случаях позволяет достичь более высокой точности синхронизации времени (так это или нет, зависит от конкретного производителя). Рис. 5 иллюстрирует комплекс, в котором реализуется временная синхронизация согласно протоколу PTP. В данном примере гроссмейстерские часы способны получать информацию о точном времени не только от системы глобального позиционирования, но и из внешней сети по протоколу PTP. Указанное решение реализовано для резервирования отказа приемника сигналов точного времени или соответствующих внешних соединительных цепей. В случае перехода на использование сигналов точного времени из внешней сети часы перестают быть гроссмейстерскими и принимают на себя роль граничных часов. В изображенном комплексе также используются два вида ведомых часов: устройства РЗА с нативной поддержкой PTP и преобразователи в формат IRIG-B и 1-PPS, предоставляющие информацию о точном времени для конечных устройств, не поддерживающих протокол PTP.

Принцип функционирования протокола PTP опирается на то, что точно известны время передачи сообщения синхронизации типа Sync (как раз это сообщение передает информацию о времени) и время получения этого сообщения на интерфейсе Ethernet ведомых часов. Точное время передачи данного сообщения неизвестно до тех пор, пока оно не было отправлено. В интерфейсах Ethernet с поддержкой протокола PTP обеспечивается проставление меток времени сообщениям на аппаратном уровне, а затем эта информация передается в центральный процессор гроссмейстерских часов. После этого производится формирование сообщения типа Follow Up, которое и передает эту точную метку времени передачи сообщения типа Sync всем ведомым устройствам. При этом прозрачные часы дополняют это сообщение информацией о задержке передачи данного сообщения по сети (сумма канальной задержки и времени перенаправления сообщения). Использование комбинации сообщений типа Sync и Follow Up и называют двухстадийным режимом работы протокола PTP.

Во второй версии протокола PTP (PTPv2) была введена возможность изменения содержимого сообщения PTP в процессе его передачи на аппаратном уровне. При реализации данного метода исключается необходимость в сообщениях типа Follow Up, данный режим функционирования протокола PTP называется одностадийным. Гроссмейстерские часы с поддержкой данного режима выполняют передачу сообщений типа Sync с информацией о точном времени их формирования, прозрачные часы производят оценку задержек передачи сообщений данного типа (по сети и через себя) и включают данные об измеренных задержках в эти же сообщения типа Sync вместо того, чтобы включать эти данные в сообщения типа Follow Up. Указанный режим работы предполагает меньшую информационную нагрузку на сеть, однако требует использования более сложных и дорогостоящих устройств.

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

Стандарт на протокол PTP предполагает несколько его модификаций, которые являются взаимоисключающими. Вторая версия протокола PTP (PTPv2) предполагает концепцию профилей, которые ограничивают значения ряда параметров и требуют использования отдельных аспектов протокола для различных областей применения.

Профиль для электроэнергетики (Power Profile) описан в документе IEEE Std C37.238-2011, который закрепляет ряд параметров для обеспечения точности синхронизации времени в пределах 1 мкс для топологий, наиболее распространенных в рамках комплексов автоматизации подстанций. Данный профиль также определяет базу управляющей информации (MIB – Management Information Base) для протокола SNMP, которая обеспечивает возможность контроля ключевых параметров устройств при использовании стандартных программ мониторинга. Благодаря этому становится возможным выполнять контроль за функционированием системы синхронизации времени в режиме реального времени с формированием сигнализации в случае возникновения нештатных ситуаций.

Профиль для электроэнергетики требует, чтобы погрешности, вносимые каждыми отдельными прозрачными часами, не превышали 50 нс. Указанное требуется для обеспечения точности синхронизации не более 1 мкс при организации топологии локальной сети, включающей в себя 16 коммутаторов Ethernet (например, в составе кольцевой топологии). При этом допустимая погрешность для GPS часов устанавливается на уровне 200 нс.

Профиль PTP требует использования прозрачных часов, поддерживающих пиринговый механизм определения канальных задержек, и того, чтобы передача всех сообщений протокола PTP производилась на канальном уровне в режиме групповой рассылки (мультикаст). Пиринговый механизм определения задержек подразумевает, что каждое устройство с поддержкой PTP обменивается сообщениями со смежными устройствами для измерения канальных задержек передачи сообщений между ними. Полная временная задержка передачи сообщений синхронизации определяется как сумма канальных задержек и задержек обработки сообщений прозрачными часами, возникающими по маршруту распространения сообщений от гроссмейстерских до ведомых часов. Указанный режим работы имеет два достоинства:

1. Сетевой трафик, видимый гроссмейстерскими часами, не увеличивается с расширением сети. Гроссмейстерские часы обмениваются сообщениями только со смежным Ethernet коммутатором (прозрачными или граничными часами).
2. Производится автоматическая компенсация задержек передачи сообщений, в случае если отказывает основной коммуникационный маршрут и включается резервный. Измерение канальных задержек производится по каждой линии связи, включая те, которые могут быть заблокированы протоколами семейства STP.

Не все производители оборудования с поддержкой протокола PTP поддерживают профиль для электроэнергетики, однако стоит отметить, что и стандартный профиль, описанный в Приложении J.4 стандарта или в документе IEEE Std 1588-2008, может обеспечивать требуемую точность при корректной конфигурации системы. При использовании профиля, отличного от профиля для электроэнергетики, не гарантируется, что информация, необходимая для устройств систем автоматизации подстанций, такая как временная погрешность и применимый часовой пояс, могут быть доступны клиентам. Также не гарантируется соответствие требуемым характеристиками в части производительности функционирования протокола (Приложение J.4 не определяет требования к производительности).

Для преобразования между различными профилями могут использоваться граничные часы. Например, граничные часы могут обеспечивать преобразование между телекоммуникационным профилем (ITU-T Rec. G.82651.1 Telecommunications Profile) и профилем для электроэнергетики (IEEE Std C37.238 Power Profile). Получение информации о точном времени из внешней сети по телекоммуникационному профилю может обеспечивать резервирование отказа приемника сигналов GPS на гроссмейстерских часах. В этом случае, как уже было указано ранее, они будут принимать на себя роль граничных часов.

Профиль протокола PTP для электроэнергетики предусматривает использование 4 классов сообщений:

1. Сообщения типа Sync. Данные сообщения включает информацию о времени, передаваемую от ведущих часов в формате числа секунд и наносекунд с полуночи 1 января 1970 года.
2. Сообщения типа Peer Delay. Обмен этими сообщениями производится между смежными устройствами для оценки задержки распространения сообщений синхронизации по линии связи между ними. Используются два или три отличных типа сообщений для измерения задержки, в зависимости от того, используется ли одно- или двухстадийный режим работы.
3. Сообщения типа Follow Up. Данные сообщения включают точную метку времени отправки предыдущего сообщения типа Sync, а также корректирующее значение. Корректирующее значение – сумма времен обработки сообщений прозрачными часами и канальных задержек на пути распространения сообщений между гроссмейстерскими часами и данной точкой сети. Представляется в формате наносекунд и долей наносекунд.
4. Сообщения типа Announce. Передача данных сообщений  производится гроссмейстерскими часами, которые предоставляют данные о погрешности функционирования источника (например, GPS приемника) и другую служебную информацию протокола PTP.

Рис. 6-8 иллюстрируют, как производится обмен сообщениями в небольшой сети при использовании часов, работающих в двухстадийном режиме (поскольку наибольшее число устройств не поддерживает работу в одностадийном режиме). Сообщения типа Sync передаются прозрачными часами в неизменном виде. t_a – показание времени на гроссмейстерских часах. Таким же образом производится передача и сообщений типа Announce.

Обмен сообщениями типа Peer Delay (Peer Delay Request, Peer Delay Response and Peer Delay Follow Up) производится только между соседними устройствами.

Каждые прозрачные часы определяют канальную задержку передачи сообщений между собой и смежными устройствами. При прохождении сообщений типа Sync через прозрачные часы они выполняют расчет локального корректирующего значения путем суммирования канальной задержки по маршруту поступления сообщения и времени прохождения сообщения типа Sync через них. Затем данное локально вычисленное корректирующее значение добавляется к корректирующему значению соответствующего входящего сообщения типа Follow Up. Когда сообщение типа Follow Up поступает на ведомые часы к корректирующему значению, добавляется определенное ими значение канальной задержки. Результирующее корректирующее значение будет представлять собой суммарное время передачи сообщения типа Sync по сети от ведущего до ведомого устройства.

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

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

На рис. 8 t_b – фактическое время формирования гроссмейстерскими часами сообщения синхронизации, которое по значению близко, но не идентично времени t_a. Каждые ведомые часы фиксируют момент получения сообщений типа Sync и благодаря фиксации времени прохождения сообщений через прозрачные часы и канальных задержек, сумма которых представляет собой корректирующее значение, могут учитывать переменные задержки передачи сообщения Sync.

Использование профиля PTP для электроэнергетики (Power Profile) предоставляет ряд преимуществ:

• Точность синхронизации времени не зависит от объема сетевого трафика. При возникновении перегрузок сетевого оборудования потери сообщений PTP не происходит. Указанное позволяет использовать одну и ту же инфраструктуру локальной сети при реализации СМПР и комплексов РЗА как с использованием шины процесса в соответствии с МЭК 61850-9-2, так и с использованием шины станции в соответствии с МЭК 61850-8-1 (с трафиком GOOSE и/или MMS), а также комплексов, функционирующих на основе других коммуникационных протоколов (DNP3 и др.).
• Частота передачи сообщений PTP была оптимизирована для того, чтобы обеспечить микросекундную точность синхронизации без чрезмерной нагрузки на сеть и без необходимости использования сложных ведомых часов.
• В качестве физической среды передачи данных могут использоваться как оптические, так и электрические (витая пара) линии связи – все зависит от конфигурации выбранных коммутаторов.
• Используется единая система отсчета времени, поэтому отсутствуют сложности настройки устройств относительно всемирного скоординированного времени (UTC)/местного времени. Все устройства с поддержкой профиля для электроэнергетики используют международное атомное время (TAI), для которого не применимы проблемы использования корректировочных секунд и перехода на летнее время.
• Профиль для электроэнергетики обеспечивает передачу местного временного смещения, поэтому отсутствует необходимость настройки местного времени на устройствах РЗА. Помимо этого, любые изменения в части перехода на летнее время достаточно выполнять на гроссмейстерских часах, не изменяя настроек устройств РЗА. Данный механизм определен стандартом IEEE 1588, поэтому обеспечивается совместимость и с устройствами, не поддерживающими профиль PTP для электроэнергетики.
• Может быть предусмотрено использование резервных гроссмейстерских часов c автоматическим переключением на них в случае нарушения связи с действующими гроссмейстерскими часами или при ухудшении показателей их функционирования.
• Для повышения надежности информационного обмена между устройствами с поддержкой протокола PTP могут использоваться такие протоколы как Rapid Spanning Tree Protocol (RSTP), Parallel Redundancy Protocol (PRP) и High-availability Seamless Ring (HSR).
• Может производиться масштабирование сетей без дополнительной нагрузки на гроссмейстерские часы.
• Задержки распространения сообщений синхронизации времени по протяженным линиям связи автоматически компенсируются, что исключает необходимость подстройки устройств сопряжения с шиной процесса и регистраторов переходных режимов.

Более подробная информация о проверках быстродействия переключения на использование резервных гроссмейстерских часов приведена в [2]. Материал рассматривает такие сценарии как потеря сегмента сети Ethernet с действующими гроссмейстерскими часами и потеря ими сигнала GPS.

Протокол PTP является достаточно сложным протоколом, и для того чтобы обеспечить требуемую точность синхронизации времени, должен быть учтен ряд моментов. Кроме этого, в рамках системы автоматизации энергообъекта возникают новые риски. Следует отметить следующие аспекты применения протокола PTP:

• Коммутаторы Ethernet должны поддерживать профиль PTP для электроэнергетики с возможностью сигнализации недопустимой погрешности функционирования. Не все прозрачные часы с поддержкой PTP (и в частности, с поддержкой пирингового механизма определения канальных задержек) способны обеспечивать погрешность менее 50 нс. Также не все прозрачные часы способны производить оценку возникающих погрешностей.
• На рынке существует ограниченное число устройств РЗА с поддержкой профиля PTP для электроэнергетики, однако ситуация улучшается. Ряд производителей выпускает устройства РЗА с поддержкой PTP с 2013 года, но поддержка протокола может являться опциональной, и необходимость в ней определяется при заказе.
• Не каждые гроссмейстерские или ведомые часы (включая преобразователи в формат других протоколов синхронизации времени) предназначены для использования на высоковольтных подстанциях, хотя они и могут поддерживать профиль PTP для электроэнергетики. Оборудование должно быть испытано на устойчивость к электромагнитным помехам в соответствии с определенными степенями жесткости.
• Синхронизация времени имеет большое значение для СМПР и шины процесса МЭК 61850-9-2. Важно, чтобы только специально обученный персонал обладал возможностью изменения конфигурации устройств с поддержкой PTP (либо при использовании специальных конфигураторов, либо при использовании веб-сервера, либо посредством протокола SNMP). Если устройства с поддержкой PTP допускают конфигурирование через лицевую панель, тогда доступ должен быть ограничен паролем.
• Существуют различные профили протокола PTP, каждый из которых оптимизирован для определенных областей применения. Наиболее полно требованиям систем автоматизации энергообъектов удовлетворяет профиль PTP для электроэнергетики (Power Profile), однако может применяться и профиль по умолчанию (Default Profile). При этом не гарантируется обеспечение достаточной точности временной синхронизации для всех систем. Другие специфические профили, такие как телекоммуникационный профиль или профиль для аудио-видео приложений (IEEE 802.1AS), скорее всего не обеспечат требуемых показателей функционирования.

В настоящем разделе рассматриваются два примера использования протокола PTP в рамках систем автоматизации высоковольтных электрических подстанций. Первый пример описывает применение протокола PTP в рамках системы автоматизации подстанции нового строительства, второй – при модернизации существующей подстанции. В рамках примеров также рассматривается структура информационной сети Ethernet. Предполагается, что структура сети не только обеспечивает возможность применения протокола PTP, но также удовлетворяет требованию по сохранению функций при единичном отказе (оборудования или линии связи).

Многие устройства РЗА обладают функцией регистрации переходных режимов в соответствии с IEEE C37.118.1 (или предшествующими стандартами). Практическая реализация данной функциональности требует обеспечения синхронизации устройств по времени с микросекундной точностью. Исторически использовалась синхронизация времени по протоколу IRIG-B, поскольку протокол NTP не удовлетворял требованиям в части точности. Сегодня ряд производителей предлагает решения с поддержкой протокола PTP, что позволяет удовлетворить требованиям в части точности. При этом протокол NTP может также использоваться для синхронизации остальных устройств РЗА энергообъекта, выполняющих функции регистрации аварийных событий.

В настоящем примере рассматривается средняя по величине подстанция 330/132 кВ для демонстрации простоты использования протокола PTP. При этом рассматривается реализация функций регистрации переходных режимов, хотя протокол PTP также может использоваться для синхронизации устройств сопряжения с шиной процесса в рамках того же энергообъекта. Однолинейная схема объекта приведена на рис. 9.

Обычно электросетевые компании принимают один из двух вариантов размещения оборудования: устройства РЗА размещаются в рамках единого помещения или же в рамках нескольких модульных зданий (высокой заводской готовности), которые располагаются на территории объекта. Используемый подход определяет топологию локальной сети Ethernet и требуемый уровень надежности. В настоящем примере топология сети разрабатывается исходя из того, что устройства РЗА элементов 330 кВ и 132 кВ устанавливаются в отдельных зданиях. Для упрощения на рис. 10 показаны лишь некоторые из устройств. Резервные соединения не используются, и изображено только по одному комплекту защит.

Для применения на объекте были выбраны устройства General Electric серии UR, в состав функций которых включена функция регистрации переходных режимов. При этом устройства РЗА поддерживают протокол PTP (вместо наиболее широко распространенного интерфейса IRIG-B). На объекте также предусмотрено использование устройства РЗА батареи конденсаторов ABB серии REV615, которое обладает поддержкой протокола PTP.

Основным источником времени являются гроссмейстерские часы, оснащенные приемником спутникового сигнала. Рекомендуется, чтобы гроссмейстерские PTP также являлись ведущими часами NTP, поскольку протокол NTP может использоваться коммуникационными контроллерами, шлюзами, приборами учета электроэнергии и устройствами РЗА, которые требуют миллисекундной точности синхронизации времени.

Коммутаторы Ethernet используются для распределения сообщений протокола PTP наряду с другим трафиком, таким как МЭК 61850, DNP3, HTTP, SNMP и др. Объем трафика PTP чрезвычайно мал, он составляет приблизительно 420 байт/с и не оказывает влияние на функционирование сети. Рис. 11 иллюстрирует трафик PTP, формируемый гроссмейстерскими часами производства компании Tekron. Из рисунка видно, что гроссмейстерские часы формируют сообщения типа Sync (красное), Follow Up (малиновое), Announce (голубое) и Peer Delay Request (зеленое) один раз в секунду, а также формируют ответы типа Peer Delay Response (желтое) и Peer Delay Response Follow Up (коричневый). Проиллюстрированный режим двухстадийной работы создает наибольший трафик – это наихудший случай.

Корневой коммутатор находится в центре топологии локальной сети Ethernet энергообъекта. К данному коммутатору выполняется подключение коммуникационного сервера и АРМ диспетчера. В приведенной схеме также предусмотрено использование двух других коммутаторов: одного в ОПУ 330 кВ, второго – в ОПУ 132 кВ. Указанное решение позволяет сократить количество кабеля, необходимого для подключения устройств РЗА. Коммутаторы, установленные в каждом из ОПУ, обеспечивают возможность информационного обмена между устройствами РЗА (например, GOOSE-сообщениями с сигналам пуска УРОВ, запрета АПВ  и др.). Указанное обеспечивает работоспособность распределенных функций при отказе связи с центральным коммутатором.

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

• Гибкостью: большее количество коммутаторов означает большее количество портов.
• Надежностью: чем больше в системе коммутаторов, тем больше вероятность отказа единичного коммутатора.
• Эксплуатационная надежность: если коммутатор отказывает, управление сколькими элементами вы потеряете?

Применение PTP хорошо вписывается в традиционные решения по применению локальных сетей электросетевыми компаниями. Профиль PTP для электроэнергетики (Power Profile) допускает функционирование в условиях наличия избыточных каналов связи при использовании протокола резервирования протокола RSTP, поскольку оценка канальных задержек производится, в том числе, по логически заблокированным линиям связи. При распространении сообщений PTP по альтернативным маршрутами сети корректирующее значение в сообщениях PTP типа Follow Up будет определять задержку по новому маршруту.

Одно из решений, которое должно быть принято при создании системы синхронизации времени, – должны ли коммутаторы работать в режиме прозрачных или граничных часов. Наиболее простой режим –прозрачных часов. При использовании данного режима поиск неисправностей в сети при использовании анализаторов трафика (например, приложения Wireshark) значительно проще. Достоинством применения граничных часов является то, что они разделяют действующие гроссмейстерские часы от ведомых часов. Это обеспечивается благодаря тому, что в граничных часах поддерживается актуальное показание часов вместо того, чтобы просто производить оценку времен прохождения сообщений синхронизации.

Рассмотрим сценарий отказа линии связи между корневым коммутатором и коммутатором, установленным в ОПУ 132 кВ, который выполняет роль прозрачных часов. В этом случае будет иметь место отклонение показаний каждых ведомых часов (устройств РЗА) от истинного времени и друг от друга в связи с различием характеристик встроенных генераторов колебаний. Скорость увеличения расхождения показаний будет зависеть от нескольких факторов, включая качество генератора колебаний и изменения температуры. Если нарушение связи будет продолжаться достаточно долго, то отличие показаний времени устройств РЗА элементов уровня напряжения 132 кВ может стать значительным. Указанная ситуация идентична ситуации, когда производится обрыв линии связи, обеспечивающей синхронизацию по IRIG-B при традиционном решении.

Если же коммутатор в ОПУ 132 кВ выполняет роль граничных часов, то ведомые устройства будут синхронизироваться с граничными часами. В нормальном режиме работы граничные часы будут синхронизированы с гроссмейстерскими часами. Если же связь с гроссмейстерскими часами нарушается, тогда устройства РЗА остаются синхронизированными с граничными часами. Локальное время на граничных часах будет медленного отклоняться от показаний времени гроссмейстерских часов – это также будет происходить с ведомыми часами, с той же скоростью. При этом все устройства РЗА будут синхронизированы друг с другом. В этой ситуации качество исполнения внутренних часов в устройствах РЗА не имеет значения.

Могут возникать ситуации, когда требуется выполнение замены существующей системы синхронизации времени, например, при внедрении новых по функциональности комплексов на энергообъекте. Приведенный пример рассматривает сценарий расширения подстанции, при котором возникает требование по возведению отдельного ОПУ. На существующей подстанции сеть Ethernet используется для реализации обмена данными между устройствами РЗА, а для синхронизации устройств по времени используется протокол IRIG-B. В качестве среды передачи данных как для ЛВС Ethernet, так и для системы синхронизации времени используются волоконно-оптические линии связи, поскольку данная среда обеспечивает высокую помехозащищённость и гальваническую развязку. Ретрансляторы используются для преобразования сигналов IRIG-B, передаваемых по оптической линии связи, в электрические сигналы IRIG-B, которые подаются непосредственно на интерфейсы устройств РЗА.

Рис. 12 иллюстрирует однолинейную схему ПС 330/132 кВ, имеющиеся здания ОПУ и коммуникационные связи между зданиями до расширения.

Электросетевая компания реализует проект расширения распределительного устройства 330 кВ с установкой еще одного силового трансформатора 330/132 кВ. Предусматривается сооружение еще одного здания ОПУ, в котором будут установлены устройства РЗА и другое оборудование. Несмотря на то, что представляется возможным провести сигнал IRIG-B из ОПУ 132 кВ, указанное будет сопровождаться дополнительными погрешностями синхронизации времени из-за большой протяженности линии связи. Указанное расширение подстанции предоставляет хорошую возможность получить опыт использования протокола PTP.

При этом количество оборудования, замену которого необходимо произвести, оказывается достаточно мало. Если ведущие часы, подключенные к GPS, не реализуют поддержку протокола PTP, тогда требуется их замена. В данном проекте было выбрано оборудование компании Tekron – модель TCG 01-G, которая поддерживает как протокол PTP, так и протокол NTP. Если корневой коммутатор Ethernet не поддерживает профиль PTP для электроэнергетики (Power Profle), тогда он должен быть заменен на тот, который эту поддержку реализует (в данном проекте была выполнена замена на коммутатор GE Multilink ML3000). При этом должна быть задокументирована конфигурация прежнего коммутатора в части виртуальных локальных сетей, многоадресной фильтрации, конфигурации портов и протокола SNMP для того, чтобы повторить их на новом коммутаторе.

На заключительном этапе предусматривается использование в рамках нового ОПУ преобразователя из формата протокола PTP в формат IRIG-B. Указанный преобразователь обеспечивает возможность подключения устройств РЗА с интерфейсом IRIG-B. Любые коммутаторы Ethernet, установка которых предусматривается в новом ОПУ, должны поддерживать либо роль прозрачных, либо роль граничных часов в соответствии с профилем PTP для электроэнергетики. Рис. 13 иллюстрирует схему подстанции после расширения. При расширении объекта также стоит узнать, могут ли устанавливаемые устройства РЗА поддерживать протокол PTP. Если да, то указанное может исключить необходимость использования преобразователей, а также получить дополнительный опыт использования протокола PTP в конечных устройствах.

В предложенной архитектуре построения системы синхронизации времени не требуется выполнять компенсацию времени распространения сигналов синхронизации для устройств, размещаемых в новом ОПУ, поскольку указанное обеспечивается пиринговым механизмом определения временных задержек профиля PTP для электроэнергетики (Power Profile). Указанное упрощает задачу наладки СМПР и других систем, требующих микросекундной точности синхронизации времени.

В части конструкции шкафов может возникнуть только одно изменение, связанное с необходимостью установки преобразователей PTP (по одному – на каждый шкаф), назначение которых – исключить необходимость прокладки выделенных линий связи для передачи сигналов IRIG-B. Уже сегодня многие электросетевые компании уходят от использования медных кабельных связей между шкафами РЗА, объединяя устройства шкафов в единую сеть Ethernet. В такой ситуации может быть использовано еще одно преимущество данного подхода – использование протокола PTP, сообщения которого передаются по той же сети Ethernet, что и сигналы устройств РЗА.

Рис. 14 иллюстрирует традиционную систему синхронизации времени с использованием IRIG-B (с моделированным/немодулированным сигналом). Все устройства РЗА подключаются к системе АСУ ТП через интерфейсы Ethernet, однако на более старых энергообъектах устройства могут подключаться и через интерфейс RS-485 (при использовании протоколов DNP3 или МЭК 60870-5-101).

При использовании протокола PTP коммуникации между шкафами целесообразно организовывать по волоконно-оптическим линиям связи. Ведомые часы PTP, такие как преобразователь из протокола PTP, используются для преобразования в формат одного из стандартных протоколов синхронизации времени (в приведенном примере –  IRIG-B). Формирование сигналов IRIG-B данными преобразователями в каждом отдельном шкафу дает возможность иметь различный формат времени и отличные временные зоны по сравнению со сценарием использования единого сервера времени, транслирующего данные в формате протокола IRIG-B. Рис. 15 иллюстрирует пример того, как протокол PTP может быть использован для синхронизации по времени существующих устройств РЗА с использованием преобразователя из формата PTP в формат одного из стандартных протоколов и одновременной синхронизации по времени современных устройств РЗА с поддержкой PTP.

Применение протокола PTP при расширении и модернизации существующих энергообъектов предоставляет возможность электросетевым компаниям и интеграторам получить опыт использования протокола PTP. В дальнейшем также может быть получен опыт использования устройств РЗА с нативной поддержкой протокола PTP.

Если электросетевая компания только переходит к внедрению коммуникации по локальной сети Ethernet между устройствами РЗА, то следует обратить внимание на возможность поддержки используемыми коммутаторами протокола PTP. Необходимо убедиться, что коммутаторы поддерживает протокол на аппаратном уровне – поддержка отдельных профилей PTP может быть реализована и на последующих этапах путем изменения базового программного обеспечения коммутаторов Ethernet.

Выше были рассмотрены аспекты использования PTP в рамках нового энергообъекта. В данном разделе рассматриваются основные принципы использования протокола PTP в резервируемых сетях Ethernet. При этом необходимо отметить фундаментальные принципы:

• Отказ любого устройства сети или линии связи не должен приводить к отказу функции защиты и управления более чем одним присоединением распределительного устройства.
• Применяются основные и резервные комплекты РЗА, которые часто называют основной защитой №1/основной защитой №2, комплектами А/Б или X/Y.
• Управляющие воздействия на коммутационное оборудование формируются непосредственно от устройств РЗА, минуя контроллеры/устройства управления.

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

• Протокол Rapid Spanning Tree Protocol (RSTP), обеспечивающий возможность создания кольцевых сетей. Данный протокол поддерживается многими, если не всеми, коммутаторами Ethernet. Время, которое требуется для восстановления связи между устройствами, не постоянно и зависит от ряда факторов.
• Протокол Parallel Redundancy Protocol (PRP). При использовании данного протокола обеспечивается непрерывность информационного обмена в случае нарушения исправности либо отдельной линии связи, либо отдельного коммутатора. Требуется специальная поддержка данного протокола или использование устройств резервирования, а также дублирование инфраструктуры сети Ethernet.
• Протокол High-reliability Seamless Redundancy (HSR). Обеспечивается непрерывность информационного обмена в случае нарушения исправности либо отдельной линии связи, либо отдельного коммутатора. При этом не требуется использование дополнительных коммутаторов. Область применения протокола ограничена кольцевыми топологиями сети Ethernet, и специальная поддержка протокола подключаемыми устройствами (например, часами PTP или устройствами РЗА) или их подключение осуществляются через специальные устройства резервирования.

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

Защита X (или основная защита №1) реализуется при использовании устройств РЗА General Electric серии UR, поскольку данное устройство поддерживает протоколы PTP и PRP. Защита X обеспечивает функции управления и регистрации переходных режимов в дополнение к функциям РЗА. Защита Y (или основная защита №2) реализуются при использовании устройств РЗА другого производителя, которые поддерживают протокол PTP или NTP для временной синхронизации.

Рис. 16 иллюстрирует топологию сети Ethernet. Реализуются две локальные сети, обозначенные как A и В, обе из которых активны в один и тот же момент времени. Протокол RSTP функционирует таким образом, что блокирует избыточные линии связи, которые на рисунке показаны пунктирными линиями. В частности, это связь между корневым коммутатором №2 и коммутатором Y. Некоторые коммуникационные серверы работают в режиме, когда второй их порт Ethernet отключен до тех пор, пока не произошел отказ основной линии связи. Данные связи также показаны пунктирными линиями.

Ожидается, что в ближайшем будущем станут доступны коммуникационные сервера АСУ ТП с нативной поддержкой PRP, что позволит сохранять активными одновременно две линии связи. Коммутатор Y может обеспечивать функциональность устройства резервирования для устройств РЗА Y, обеспечивая обработку дубликатов сообщений.

Коммутаторы Ethernet сегодня доступны с большим количеством портов, что исключает необходимость применения коммутаторов в каждом из шкафов для подключения устройств РЗА. На небольших подстанциях применение коммутаторов X1, X2 и Y для подключения устройств РЗА может не понадобиться и, наоборот, – на подстанциях высокого напряжения может быть целесообразным применение коммутаторов X1, X2 и Y для каждого уровня напряжения. В независимости от топологии сети Ethernet, применение коммутатора Ethernet с поддержкой роли прозрачных или граничных часов позволит обеспечить возможность подключения клиентов в любой точке сети.

Применение протоколов синхронизации времени, функционирующих по сети Ethernet, сокращает затраты на проектирование систем, их реализацию и обслуживание. Протокол PTP, а именно профиль данного протокола для электроэнергетики (Power Profile), решает целый ряд проблем, связанных с системами синхронизации времени для систем автоматизации подстанций, и его применение оптимально вписывается в идеологию построения обмена данными между вторичными устройствами энергообъекта по сети Ethernet.

1. D.M.E. Ingram, P. Schaub, D.A. Campbell & R.R. Taylor, “Evaluation of precision time synchronisation methods for substation applications”, 2012 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS 2012), San Francisco, USA, 23-28 September 2012. Available from http://eprints.qut.edu.au/53218/.
2. D.M.E. Ingram, P. Schaub, D.A. Campbell & R.R. Taylor, “Quantitative assessment of fault tolerant precision timing for electricity substations”, IEEE Transactions on Instrumentation and Measurement, October 2013. Volume 62, Issue 10, pp 2694-2703. Available from http://eprints.qut.edu.au/56835/.

Домашняя страница протокола сетевого времени

Пользователям NTP настоятельно рекомендуется принять немедленные меры, чтобы их демоны NTP не были подвержены использованию в распределенных атаках типа «отказ в обслуживании» (DDoS). Также воспользуйтесь этой возможностью для отражения атак типа «отказ в обслуживании», реализовав фильтрацию входящего и исходящего трафика через BCP38.

ntp-4.2.8p15 был выпущен 23 июня 2020 года.
Он решает 1 проблему безопасности средней степени серьезности в ntpd и предоставляет 13 других улучшений, не связанных с безопасностью, более 4.2.8p14.

Пожалуйста, посетите нашу страницу с уведомлением о безопасности NTP для получения информации об уязвимостях и способах их устранения.

Добро пожаловать на ntp.org, где находится проект Network Time Protocol.

Эта страница является домашней страницей проекта NTP (R&D). Этот веб-сайт и все страницы, непосредственно содержащиеся на нем, находятся в всеобщее достояние. Некоторые части этого сайта могут быть защищены авторскими правами других авторов. С любыми вопросами относительно авторских прав обращайтесь к веб-мастеру. НПТ Распространение программного обеспечения защищено авторским правом, как описано на странице авторских прав NTP.

NTP — это протокол, предназначенный для синхронизации часов компьютеров в сети.

NTP версии 4, значительный пересмотр предыдущего стандарта NTP, является текущей версией разработки. Это формализовано RFC, выпущенным IETF.

Проект НПТ (НИОКР)

Проект NTP проводит исследования и разработки в области NTP и производит Официальная справочная реализация NTP вместе с реализацией Документация. Справочная информация о НПТ, а также брифинги и библиографию доступны на сайте Network Time Synchronization. Страница проекта.

Проект государственных услуг NTP

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

Ресурсы хостинга для проекта государственных служб NTP предоставлены Internet Systems Consortium, Inc.

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

WebHome

Пользователям NTP настоятельно рекомендуется принять немедленные меры, чтобы их демоны NTP не были подвержены использованию в распределенных атаках типа «отказ в обслуживании» (DDoS). Также воспользуйтесь этой возможностью для отражения атак типа «отказ в обслуживании», реализовав фильтрацию входящего и исходящего трафика через BCP38.

ntp-4.2.8p15 был выпущен 23 июня 2020 года. Он решает 1 проблему безопасности средней степени серьезности в ntpd и содержит 13 исправлений, не связанных с безопасностью, более 4.2.8p13.

---

Используете ли вы Autokey в производстве? Если да, пожалуйста, свяжитесь с Харланом — у него есть к вам вопросы.

Стабильный
4.2.8p15
2020.06.23
Разработка
4.3.99
2019.06.07

Новости NTP

Информация о безопасности NTP

Что такое NTP (сетевой протокол времени)?

Почему важен протокол NTP?

Юридические требования

Ограничения на экспорт

Проект НПТ

Рабочая группа IETF NTP

Информация для новых пользователей NTP

• Новые пользователи NTP должны прочитать файл Where-To-Start , включенный в дистрибутив NTP.
• Документация для текущего дистрибутива NTP вместе с дополнительной информацией доступна на странице документации.
• Поддерживаемая сообществом документация доступна на веб-сайте поддержки этого сайта.
• Пользователи NTP, которые не любят читать документацию, могут захотеть обратиться к Краткому руководству.
• Если вы хотите найти сервер, с которого можно узнать время, просмотрите список общедоступных серверов NTP.
• Если вы хотите загрузить программное обеспечение NTP, перейдите на страницу загрузки.
• Если вы хотите найти программное обеспечение NTP, отличное от эталонного дистрибутива, перейдите на страницу со ссылками.

Чем я могу помочь?

Как с нами связаться

Протокол сетевого времени

Протокол сетевого времени (NTP) — это протокол, предназначенный для синхронизации времени в сети машин.NTP работает по протоколу пользовательских дейтаграмм (UDP), который, в свою очередь, работает по IP. NTP версии 3 задокументирован в RFC 1305.

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

NTP использует концепцию страты, чтобы описать, на сколько NTP прыгает машина от авторитетного источника времени.Сервер времени уровня 1 обычно имеет авторитетный источник времени (например, радио или атомные часы или источник времени глобальной системы позиционирования (GPS)), непосредственно подключенный, сервер времени уровня 2 получает свое время через NTP от сервера времени уровня 1. , и так далее.

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

Реализация Cisco NTP не поддерживает службу уровня 1; то есть вы не можете подключиться к радио или атомным часам (однако для некоторых конкретных платформ вы можете подключиться к устройству источника времени GPS). Cisco рекомендует, чтобы служба времени для вашей сети была получена из общедоступных серверов NTP, доступных в IP-Интернете.

Если сеть изолирована от Интернета, реализация Cisco NTP позволяет настроить машину таким образом, чтобы она действовала так, как если бы она была синхронизирована через NTP, хотя на самом деле она определяла время с помощью других средств.Затем другие машины могут синхронизироваться с этой машиной через NTP.

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

Связь между машинами, на которых работает NTP (известная как ассоциации), обычно настраивается статически; каждой машине дается IP-адрес всех машин, с которыми она должна образовывать ассоциации.Точное хронометрирование стало возможным благодаря обмену сообщениями NTP между каждой парой машин с ассоциацией.

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

Время, хранимое на машине, является критическим ресурсом, поэтому Cisco настоятельно рекомендует использовать функции безопасности NTP, чтобы избежать случайной или злонамеренной установки неправильного времени.Доступны два механизма: схема ограничения на основе списка доступа и механизм зашифрованной аутентификации.

Когда доступны несколько источников времени (виртуальная интегрированная сетевая система (VINES), аппаратные часы, ручная настройка), NTP всегда считается более надежным. Время NTP имеет приоритет над временем, установленным любым другим методом.

NTP по умолчанию отключены на всех интерфейсах.

Дополнительные сведения о NTP см. В следующих разделах:

Ассоциации НПТ на основе опросов

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

Ниже приведены два наиболее часто используемых режима ассоциации на основе опроса:

• Клиентский режим

• Симметричный активный режим

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

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

Когда сетевое устройство работает в симметричном активном режиме, оно опрашивает назначенные ему обслуживающие время хосты на текущее время и отвечает на опросы своих хостов. Поскольку это одноранговые отношения, хост также сохранит связанную со временем информацию о локальном сетевом устройстве, с которым он обменивается данными.Этот режим следует использовать, когда несколько взаимно избыточных серверов соединены между собой различными сетевыми путями. Большинство серверов уровня 1 и уровня 2 в Интернете используют эту форму настройки сети. Использовать нтп peer, чтобы индивидуально указать узлы обслуживания времени, с которыми ваше сетевое устройство должно учитывать синхронизацию, и настроить сетевое устройство на работу в симметричном активном режиме.

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

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

Группа доступа NTP

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

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

1. ipv4 — настраивает списки доступа IPv4.

2. ipv6 — настраивает списки доступа IPv6.

3. одноранговый узел — разрешает запросы времени и запросы управления NTP, а также позволяет системе синхронизировать себя с системой, адрес которой соответствует критериям списка доступа.

4. serve — разрешает запросы времени и запросы управления NTP, но не позволяет системе синхронизироваться с системой, адрес которой соответствует критериям списка доступа.

5. serve-only — разрешает только временные запросы от системы, адрес которой соответствует критериям списка доступа.

6. query-only — разрешает только управляющие запросы NTP от системы, адрес которой соответствует критериям списка доступа.

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

Подробные сведения об управляющих запросах NTP см. В RFC 1305 (NTP версии 3).

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

Процесс аутентификации начинается с момента создания пакета NTP.Ключи криптографической контрольной суммы генерируются с использованием алгоритма обзора сообщения 5 (MD5) и встраиваются в пакет синхронизации NTP, который отправляется принимающему клиенту. После получения пакета клиентом его ключ криптографической контрольной суммы расшифровывается и проверяется на соответствие списку доверенных ключей. Если пакет содержит совпадающий ключ аутентификации, информация о отметке времени, содержащаяся в пакете, принимается принимающим клиентом. Пакеты синхронизации NTP, не содержащие совпадающего ключа аутентификатора, игнорируются.

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

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

Что такое протокол сетевого времени (NTP)?

Протокол сетевого времени (NTP) — это протокол, используемый для синхронизации часов компьютера в сети. Он принадлежит и является одной из старейших частей набора протоколов TCP / IP.Термин NTP применяется как к протоколу, так и к программам клиент-сервер, которые выполняются на компьютерах.

NTP, разработанный Дэвидом Миллсом в Университете Делавэра в 1981 году, отличается высокой отказоустойчивостью и масштабируемостью.

Сетевая рабочая группа D.Л. Миллс
Запрос комментариев: 958 M / A-COM Linkabit
                                                          Сентябрь 1985 г.

                      Сетевой протокол времени (NTP)


Статус этого меморандума

   Этот RFC предлагает предлагаемый протокол для ARPA-Internet.
   сообщества, и просит обсуждения и предложений по улучшению.
   Распространение этой памятки не ограничено.

Оглавление

   1. Введение
   2. Модель обслуживания
   3. Обзор протокола
   4.Переменные состояния и форматы
   5. Работа протокола
   5.1. Режимы протокола
   5.2. Обработка сообщений
   5.3. Сетевые соображения
   5.4. Високосные секунды
   6. Ссылки
   Приложение A. Формат заголовка UDP
   Приложение Б. Формат данных NTP

1. Введение

   В этом документе описывается протокол сетевого времени (NTP), протокол
   для синхронизации набора сетевых часов с помощью набора распределенных
   клиенты и серверы. NTP построен на протоколе пользовательских дейтаграмм.
   (UDP) [13], который обеспечивает транспортный механизм без установления соединения.Это
   разработан на основе протокола времени [7] и сообщения отметки времени ICMP.
   [6] и является подходящей заменой для обоих.

   NTP предоставляет механизмы протокола для принципиальной синхронизации времени
   с точностью порядка наносекунд при сохранении
   недвусмысленная дата, по крайней мере, для этого века. Протокол включает
   положения для определения точности и расчетной погрешности местного
   часы и характеристики эталонных часов, к которым они могут
   синхронизироваться. Однако сам протокол определяет только
   представление данных и форматы сообщений и не указывает
   алгоритмы синхронизации или механизмы фильтрации.Другие механизмы были указаны в наборе интернет-протоколов.
   для записи и передачи времени, когда происходит событие,
   включая дневной протокол [8] и опцию IP Timestamp [9]. В
   NTP не предназначен для замены любого из этих механизмов. Дополнительный
   информацию о синхронизации времени в сети можно найти в


Миллс [Страница 1] 

RFC 958 сентябрь
Сетевой протокол времени


   Ссылки в конце этого документа.Более ранняя синхронизация
   протокол обсуждается в [3], а алгоритмы синхронизации в [2],
   [5], [10] и [12]. Экспериментальные результаты по измеренным задержкам в оба конца
   а смещения часов в Интернете обсуждаются в [4] и [11]. А
   всесторонняя математическая обработка синхронизации часов может быть
   найдено в [1].

2. Модель обслуживания

   Цель службы, для которой разработан этот протокол, состоит в том, чтобы
   подключить несколько первичных эталонных часов, синхронизированных по проводам или по радио
   к национальным стандартам, к централизованно доступным ресурсам, таким как
   шлюзы.Эти шлюзы будут использовать NTP между собой для перекрестной проверки
   основные часы и уменьшить ошибки из-за оборудования или
   сбои при распространении. Некоторое количество хостов локальной сети, служащих
   вторичные эталонные часы, будут запускать NTP с одним или несколькими из этих
   шлюзы. Чтобы уменьшить накладные расходы протокола, эти хосты
   перераспределит время между оставшимися узлами локальной сети. в
   интерес к надежности выбранные хосты могут быть оснащены менее
   точные, но менее дорогие радиочасы, используемые для резервного копирования на случай
   отказа основных и / или дополнительных часов или связи
   пути между ними.В нормальной конфигурации подсеть из первичной и вторичной
   часы примут иерархическую организацию с более точной
   часы вверху и менее точные внизу. NTP обеспечивает
   информация, которая может быть использована для организации этой иерархии на основе
   точности или оценочной ошибки и даже служить элементарным
   алгоритм маршрутизации для организации самой подсети. Тем не менее
   Протокол NTP не включает спецификации алгоритмов для
   это остается темой для дальнейшего изучения.3. Обзор протокола

   Нет никаких условий для однорангового обнаружения, приобретения или
   аутентификация в NTP. Целостность данных обеспечивается IP и UDP.
   контрольные суммы. Нет достижимости, управление цепями, обнаружение дубликатов
   или предусмотрены или необходимы средства ретрансляции. Обслуживание
   может работать в симметричном режиме, в котором серверы и клиенты
   неразличимы, но содержат небольшой объем информации о состоянии,
   или в несимметричном режиме, в котором серверы не нуждаются в обслуживании клиентов
   состояние, отличное от того, что содержится в запросе клиента.Более того,
   необходим только один формат сообщения NTP, что упрощает
   реализация и может использоваться в различных запрошенных или
   механизмы незапрашиваемого опроса.

   В наиболее распространенном (несимметричном) режиме клиент отправляет сообщение


Миллс [Страница 2] 

RFC 958 сентябрь
Сетевой протокол времени


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

   Временные метки NTP представлены как 64-битное число с фиксированной точкой, в
   секунд относительно 0000 UT 1 января 1900 года. Целая часть равна
   в первых 32 битах и ​​дробной части в последних 32 битах, как
   показано на следующей диаграмме.

       0 1 2 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
      | Целая часть |
      + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
      | Дробь Часть |
      + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

   Этот формат позволяет выполнять удобную арифметику с высокой точностью и
   преобразование в представление протокола времени (секунды), но делает
   усложняют преобразование в представление сообщения ICMP Timestamp
   (миллисекунды).Бит дроби младшего разряда увеличивается примерно на
   Интервалы в 0,2 наносекунды, так что тактовая частота в одну миллисекунду в автономном режиме
   будет ошибкой лишь небольшую долю одной части на миллион, или
   менее секунды в год.

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



Миллс [Страница 3] 

RFC 958 сентябрь
Сетевой протокол времени


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

   Индикатор прыжка

      Это двухбитное предупреждение кода о приближающейся дополнительной секунде.
      вставлено в международно-скоординированное стандартное время
      трансляции. Иногда добавляется или вычитается дополнительная секунда.
      от Стандартного времени, которое основано на атомных часах, чтобы поддерживать
      согласие с вращением Земли. При необходимости исправления
      уведомляются заранее и выполняются в конце последнего дня
      месяц, в котором отправлено уведомление, обычно июнь или декабрь.Когда
      коррекция выполняется в первую минуту следующего дня.
      есть либо 59, либо 61 секунда.

   Положение дел

      Это шестибитный код, указывающий состояние локальных часов.
      Значения присваиваются, чтобы указать, правильно ли он работает
      или в одном из нескольких состояний ошибки.

   Тип эталонных часов

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

      Это 16-битовое целое число со знаком, указывающее точность
      местные часы в секундах с точностью до двойки. За
      Например, синхросигналу с частотой сети 60 Гц будет присвоено значение
      -6, тогда как кварцевым часам с частотой 1000 Гц будет присвоено значение -10.

   Расчетная ошибка

      Это 32-битное число с фиксированной точкой, указывающее предполагаемую ошибку.
      местных часов на последнее установленное время. Значение в секундах,
      с точкой дроби между битами 15 и 16, и вычисляется
      отправитель на основании сообщения об ошибке эталонных часов,
      точность и скорость дрейфа местных часов и времени местного
      часы были установлены в последний раз.Для статистических целей это количество может быть
      предполагается равным оцененному или вычисленному стандартному отклонению, как
      описан в [12].



Миллс [Страница 4] 

RFC 958 сентябрь
Сетевой протокол времени


   Расчетная скорость дрейфа

      Это 32-битное число с фиксированной точкой со знаком, указывающее
      расчетная скорость дрейфа местных часов. Ценность
      безразмерный, с точкой дроби слева от старшего разряда
      кусочек.Хотя для большинства целей это значение можно оценить на основе
      аппаратные характеристики, вполне возможно вычислить
      точно, как описано в [12].

   Идентификатор эталонных часов

      Это 32-битный код, определяющий конкретную опорную частоту.
      Интерпретация его значения зависит от значения ссылки.
      Тип часов. В случае локально синхронизированных первичных часов
      в стандартное время (тип 1), значение представляет собой строку ASCII
      идентификация часов.В случае вторичных часов удаленно
      синхронизируется с интернет-хостом через NTP (тип 2), значение
      32-битный Интернет-адрес этого хоста. В остальных случаях
      значение не определено.

   Эталонная отметка времени

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

   Создать отметку времени

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

   Получить отметку времени

      Это 64-битная метка времени, установленная хостом сервера и
      с указанием местного времени, в которое поступил запрос от
      клиентский хост. Если от клиента не поступало никаких запросов,
      значение равно нулю.

   Отметка времени передачи

      Это 64-битная метка времени, установленная хостом сервера и
      с указанием местного времени, в которое отправился ответ для
      клиентский хост. Если от клиента не поступало никаких запросов,
      значение равно нулю.Миллс [Страница 5] 

RFC 958 сентябрь
Сетевой протокол времени


5. Работа протокола

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

   5.1. Режимы протокола

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

      В симметричном режиме пропадает различие клиент / сервер.
      Каждый одноранговый узел поддерживает таблицу с таким же количеством записей, как и активные одноранговые узлы,
      каждая запись включает код, однозначно идентифицирующий партнера (например,
      Интернет-адрес) вместе с информацией о статусе и копией
      значения Originate Timestamp и Receive Timestamp были получены в последний раз
      от этого пэра.Одноранговый узел периодически отправляет сообщение NTP каждому
      этих пиров, включая последнюю копию этих отметок времени. В
      интервал между отправкой сообщений NTP регулируется исключительно
      отправляющий одноранговый узел, и на него не влияет прибытие сообщений NTP от
      другие коллеги.

      Режим, принятый партнером, может быть определен путем проверки
      Поля UDP Source Port и Destination Port (см. Приложение A). Если
      оба эти поля содержат номер порта службы NTP 123,
      одноранговый узел работает в симметричном режиме.Если они разные и
      поле Destination Port содержит 123, это запрос клиента
      и ожидается, что получатель ответит описанным образом
      над. Если они разные и поле Source Port содержит
      123, это ответ сервера на ранее отправленный клиентский запрос.






Миллс [Страница 6] 

RFC 958 сентябрь
Сетевой протокол времени


   5.2. Обработка сообщений

      Важные события, представляющие интерес для NTP, обычно происходят вблизи
      раз сообщения NTP отправляются и прибывают на клиент / сервер. В
      для обеспечения максимальной точности важно, чтобы
      временные метки, связанные с этими событиями, вычисляются как можно ближе к
      возможно для аппаратного или программного драйвера, связанного с
      канал связи и, в частности, отметки времени отправления
      пересчитываться для каждой повторной передачи, если используется на канальном уровне.Сообщение NTP строится следующим образом (см. Приложение B). В
      одноранговый узел источника создает заголовок UDP и LI, статус,
      Поля Reference Clock Type и Precision в части данных NTP.
      Затем он определяет текущий источник синхронизации и
      создает поля Type и Reference Clock Identifier. Из
      свой алгоритм хронометража (см. примеры [12]) он определяет
      эталонная временная метка, расчетная ошибка и расчетная скорость дрейфа
      поля. Затем он копирует в метку времени приема и передачи
      Отметка времени поля данных, сохраненных из последнего полученного сообщения
      от конечного партнера и, наконец, вычисляет исходный
      Поле отметки времени.Одноранговый узел назначения вычисляет задержку приема-передачи и часы.
      смещение относительно исходного однорангового узла следующим образом. Пусть t1, t2 и t3
      представляют содержимое метки времени отправления, получения
      Поля Timestamp и Transmit Timestamp и t4 - местное время.
      Получено сообщение NTP. Тогда задержка туда и обратно d и часы
      смещение c:

         d = (t4 - t1) - (t3 - t2) и c = (t2 - t1 + t3 - t4) / 2.

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

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

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


Миллс [Страница 7] 

RFC 958 сентябрь
Сетевой протокол времени


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

      Предполагая симметричный режим, интервал опроса устанавливается для
      каждый одноранговый узел, в зависимости от его обычного источника синхронизации,
      точность и внутренняя точность, которые могут быть определены в
      заранее или даже в результате наблюдения. Задержка и
      полученные отсчеты смещения часов могут быть отфильтрованы с помощью
      методы и алгоритмы максимального правдоподобия, описанные в [12].Время от времени поправка местных часов вычисляется из
      данные смещения, накопленные, как указано выше, возможно, с использованием алгоритмов
      описано в [10] и [12]. Коррекция заставляет местные часы
      бегать немного быстрее или медленнее к исправленному времени или прыгать
      мгновенно до правильного времени, в зависимости от величины
      исправление. См. [5] и [11] для обсуждения местных часов.
      модели реализации и алгоритмы синхронизации. Обратите внимание, что
      здесь ожидается, что все сетевые часы поддерживаются
      эти алгоритмы, так что ручное вмешательство обычно не
      требуется.В качестве побочного продукта вышеупомянутых операций оценка местных часов
      ошибка и скорость дрейфа могут быть вычислены. Обратите внимание, что величина
      оценка ошибки всегда должна быть больше, чем оценка ошибки
      выбранные эталонные часы, по крайней мере, с присущей точностью
      местные часы. Не требуется воображения, чтобы увидеть, что
      предполагаемая ошибка, задержка или точность, или некоторая комбинация
      их, можно использовать в качестве метрики для простой маршрутизации типа min-hop.
      алгоритм организации подсети таким образом, чтобы обеспечить максимальную
      точное время для всех партнеров и для обеспечения автоматического возврата к
      альтернативные источники на случай сбоев.В вышеупомянутые могут быть включены различные конфигурации сети.
      сценарий. В случае сетей, поддерживающих трансляцию
      функция, например, сообщения NTP могут транслироваться с одного или
      больше хостов серверов и захвачено клиентскими хостами, использующими те же самые
      кабель. Поскольку типичные сети этого типа имеют очень низкий
      задержка распространения, расчет задержки туда и обратно можно опустить
      и клиентам не нужно транслировать взамен. Таким образом
      требование сохранять временные метки для одноранговых узлов удалено, так что
      Поля Receive Timestamp и Transmit Timestamp могут быть установлены на ноль
      и смещение локальных часов становится просто разницей между
      Отметка времени отправления и местное время по прибытии.в
      случай спутниковых сетей с большой задержкой и возможностью вещания,


Миллс [Страница 8] 

RFC 958 сентябрь
Сетевой протокол времени


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

   5.4. Високосные секунды

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





































Миллс [Страница 9] 

RFC 958 сентябрь
Сетевой протокол времени


6. Ссылки

   1.Линдси, W.C., и A.V. Кантак. Сетевая синхронизация
       Случайные сигналы. IEEE Trans. Comm. COM-28, 8 (август 1980 г.),
       1260-1266.

   2. Миллс, Д.Л. Синхронизация времени в хостах DCNET. DARPA Интернет
       Отчет о проекте IEN-173, COMSAT Laboratories, февраль 1981 г.

   3. Миллс, Д.Л. Служба Интернет-часов DCNET. Сеть DARPA работает
       Отчет группы RFC-778, COMSAT Laboratories, апрель 1981 г.

   4. Миллс, Д.Л. Интернет-эксперименты с задержкой. Сеть DARPA работает
       Отчет группы RFC-889, M / A-COM Linkabit, декабрь 1983 г.5. Миллс, Д.Л. Протоколы локальной сети DCN. Сеть DARPA работает
       Отчет группы RFC-891, M / A-COM Linkabit, декабрь 1983 г.

   6. Постел Дж. Протокол управляющих сообщений Интернета. Сеть DARPA
       Отчет рабочей группы RFC-792, Институт информационных наук США,
       Сентябрь 1981 г.

   7. Постел Дж. Протокол времени. Отчет рабочей группы сети DARPA
       RFC-868, Институт информационных наук США, май 1983 г.

   8. Постел Дж. Дневной протокол. Отчет рабочей группы сети DARPA
       RFC-867, Институт информационных наук США, май 1983 г.9. Su, Z. Спецификация временной метки интернет-протокола (IP).
       Вариант. Отчет рабочей группы сети DARPA RFC-781. НИИ
       International, май 1981 г.

   10. Марзулло К. и С. Овицки. Сохранение времени в
       Распределенная система. Обзор операционных систем ACM 19, 3 (июль
       1985), 44-54.

   11. Миллс, Д.Л. Эксперименты по синхронизации сетевых часов. DARPA
       Отчет сетевой рабочей группы RFC-957, M / A-COM Linkabit, август
       1985 г.

   12. Миллс, Д.Л.Алгоритмы синхронизации сетевых часов. DARPA
       Отчет сетевой рабочей группы RFC-956, M / A-COM Linkabit, сентябрь
       1985 г.

   13. Постел Дж. Протокол дейтаграмм пользователя. Рабочая группа сети DARPA
       Отчет RFC-768, Институт информационных наук США, август 1980 г.



Миллс [Страница 10] 

RFC 958 сентябрь
Сетевой протокол времени


Приложение A. Формат заголовка UDP

   Пакет NTP состоит из заголовка UDP, за которым следуют данные NTP.
   часть.Формат заголовка UDP и его интерпретация
   поля описаны в [13] и не являются частью NTP
   Технические характеристики. Они показаны ниже для полноты картины.

    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | Исходный порт | Порт назначения |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | Длина | Контрольная сумма |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

   Исходный порт

      Номер порта источника UDP.В случае несимметричного режима и
      клиентский запрос это поле назначается клиентским хостом, в то время как
      для ответа сервера он копируется из поля Destination Port в
      запрос клиента. В случае симметричной моды как
      Полям Source Port и Destination Port назначается NTP.
      номер сервисного порта 123.

   Порт назначения

      Номер порта назначения UDP. В случае несимметричного режима и
      клиентский запрос этому полю присваивается номер сервисного порта NTP
      123, а для ответа сервера он копируется из порта источника.
      поле клиентского запроса.В случае симметричной моды оба
      полям Source Port и Destination Port назначается NTP.
      номер сервисного порта 123.

   Длина

      Длина запроса или ответа, включая заголовок UDP, в октетах.

   Контрольная сумма

      Стандартная контрольная сумма UDP.









Миллс [Страница 11] 

RFC 958 сентябрь
Сетевой протокол времени


Приложение Б. Формат данных NTP

   Формат части данных NTP, которая следует сразу за UDP.
   заголовок показан ниже вместе с описанием его полей.0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | LI | Статус | Тип | Точность |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | Расчетная ошибка |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | Расчетная скорость дрейфа |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | Идентификатор эталонных часов |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | |
   | Эталонная временная метка (64 бита) |
   | |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | |
   | Отметка времени создания (64 бита) |
   | |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | |
   | Отметка времени получения (64 бита) |
   | |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
   | |
   | Отметка времени передачи (64 бита) |
   | |
   + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

   Индикатор прыжка (LI)

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

         00 без предупреждения
         01 +1 секунда (в следующей минуте 61 секунда)
         10-1 секунда (в следующей минуте 59 секунд)
         11 зарезервировано для использования в будущем

   Положение дел

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


Миллс [Страница 12] 

RFC 958 сентябрь
Сетевой протокол времени


         0 часы работают правильно
         1 потеря оператора связи
         2 потеря синхронизации
         3 ошибка формата
         4 сбой интерфейса (тип 1) или звена (тип 2)
         (дополнительные коды зарезервированы для использования в будущем)

   Тип эталонных часов
   (Тип)

      Код, определяющий тип эталонных часов.Ценности определены
      следующее:

         0 не указано
         1 основная ссылка (например, радиочасы)
         2 вторичная ссылка с использованием Интернет-хоста через NTP
         3 вторичная ссылка с использованием другого хоста или протокола
         4 глазных яблока и наручные часы
         (дополнительные коды зарезервированы для использования в будущем)

   Точность

      Целое число со знаком в диапазоне от +32 до -32, указывающее точность
      местные часы в секундах с точностью до двойки.Расчетная ошибка

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

   Расчетная скорость дрейфа

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

   Контрольные часы
   Идентификатор

      Код, идентифицирующий конкретные опорные часы. В случае
      тип 1 (первичная ссылка), это выровненная по левому краю, заполненная нулями
      Строка ASCII, идентифицирующая часы, например:

         WWVB WWVB радио часы (60 кГц)




Миллс [Страница 13] 

RFC 958 сентябрь
Сетевой протокол времени


         Спутниковые часы GOES GOES (468 Гц)
         WWV WWV радио часы (2.5/5/10/15/20 МГц)
         (и другие по мере необходимости)

      В случае типа 2 (вторичная ссылка) это 32-битный
      Интернет-адрес ссылочного хоста. В остальных случаях это поле
      зарезервирован для использования в будущем и должен быть равен нулю.

   Эталонная отметка времени

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

   Создать отметку времени

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

   Получить отметку времени

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

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
























Миллс [стр. 14]