Разное

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

06.05.2021

Содержание

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

Основные теги


Каталог устойств мониторинг серверных комнат и шкафов

Все устройства

Устройство UniPing v3

Устройство UniPing server solution v3/SMS

Устройство NetPing 2/PWR-220 v1/SMS

Устройство NetPing IO v2

Устройства NetPing

Каталог датчиков для устройств NetPing

Устройство NetPing 8/PWR-220 v3/SMS

Устройство NetPing 2/PWR-220 v3/ETH

Устройство NetPing 2/PWR-220 v2/SMS

Устройство NetPing 4/PWR-220 v3/SMS

Устройство NetPing SMS

Устройство NetPing /PWR-220 v3/ETH

Адаптер WiFi VAP11N

Коммутатор PS104GT

Устройство NetPing Mini-UPS

Коммутатор NP-SM4

Сплиттер POE 12В (стандарта 802.3af)

IRC-TR v2 (ИК модуль расширения)

Каталог устройств удалённого управления и распределения электропитания NetPing

Устройство UniPing server solution

Устройство UniPing server solution v3

Датчик разбития стекла (Стекло-3 ИО 329-4), 2м

Переходник для NetPing IO v2

Блок питания 48В 1,5А (мод.HRS20005)

Датчик температуры TS, 1м

Датчик температуры, (T811), 2м

Датчик температуры WT, 1м

Датчик протечки, модель 2605, 2м

Датчик протечки h3О

Датчик температуры 1-wire, (THS), 2м

МАЯК-12-СТ

Датчик движения (PYRONIX COLT QUAD PI ПИК детектор), 2м

Датчик движения (SWAN-QUAD ИК детектор квадросенсор), (2м)

BM8070D Силовое реле 16А/250В на DIN-рейку

MP701 Исполнительный элемент (4 независимых канала по 2 кВт 10А)

Датчик дыма комбинированный (дым/тепло) ИП 212/101-2М-A1R с базой Е412NL

МОЛЛЮСК-12/1,5

Внешний ИБП SKAT-12DC-1.0 Li-ion

ИКС-1 извещатель охранный инфракрасный активный однолучевой

Датчик охранный (Извещатель охранный ИО102-20/Б2П, 2м)

Блок розеток SNR-PDU-08S-1

Устройство NetPing 2/PWR-220 v4/SMS

Устройство UniPing server solution v4/SMS

Устройство NetPing 8/PWR-220 v4/SMS

VT592 кабельный датчик протечки

WLC10 кабель протечки

NetPing Connection board v2 (коммутационная плата для UniPing v3)

Инжектор питания POE (стандарта 802.3af)

NetPing датчик наличия электропитания 995S1

Устройство NetPing 2/PWR-220 v12/ETH

Устройство NetPing 2/PWR-220 v13/GSM3G

Датчик наличия 220В (мод. HRS05005), 1.5м

NetPing удлинитель-разветвитель 1-wire на 5 портов, модель R912R1

NetPing датчик качества электропитания 1-wire 910S20

PLController BM8070D силовое реле 15A/250В на DIN-рейку

▼ Все теги

Синхронизация точного времени. Стандарт IEEE 1588.

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

В зависимости от решаемых задач, могут потребоваться разные уровни точности синхронизации времени. Так одной из наиболее чувствительных к точности времени систем является система автоматизации на энергетических подстанциях. Современная система автоматизации подстанции описана в стандарте МЭК 61850, в котором указано, что точность синхронизации времени на шине процессов должна быть не хуже 1 мкс.

Существует несколько методов синхронизации времени.

1. Односторонний метод

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

2. Двусторонний метод

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

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

 Выделенная и конвергентная сети

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

В конвергентной сети синхронизация времени происходит по тем же каналам, по которым передается весь остальной трафик системы. Для подобных систем используют протоколы синхронизации времени NTP, SNTP и PTP.

Кроме того, в отдельную группу можно отнести системы синхронизации от орбитальных спутников – например, GPS/ГЛОНАС.

Точность Метод синхронизации Сеть
GPS < 1 мкс Односторонний Беспроводная
1PPS < 1 мкс Односторонний Отдельная проводная
IRIG-B 10 мкс – 1 мс Односторонний Отдельная проводная
NTP 0,5 — 100 мс Двусторонний Сеть Интернет
SNTP 1 – 50 мс Двусторонний Локальная сеть
PTP < 1 мкс Двусторонний Локальная сеть

Технологии синхронизации времени

Рассмотрим, что представляет собой каждый из способов синхронизации времени.

  • GPS (Global Positioning System) – Глобальная система позиционирования. Синхронизация времени осуществляется во время определения местонахождения устройства, оснащенного GPS-приёмником. Для этого устройство ловит сигнал со спутников, установленных на околоземной орбите. Каждый из спутников имеет атомные часы, за счет чего система GPS обеспечивает хорошую точность. Минусом данного метода является необходимость в GPS-антенне, сигнал от которой может быть нестабильным.
  • 1PPS (1 pulse per second) – Сигнал 1PPS не содержит метки времени. Master-устройство посылает 1 импульс в секунду по отдельной сети: оптоволоконной линии, витой паре или коаксиальному кабелю. Часы Slave используют этот импульс только для синхронизации начала каждой секунды. Устройства не могут с помощью 1PPS получить информацию по дате и времени, поэтому его чаще всего используют совместно с другими протоколами синхронизации, например NTP.
  • NTP (Network Time protocol) – Протокол сетевого времени широко распространен в сетях Ethernet и Интернет. Принцип работы NTP основан на многоуровневой системе с множеством источников времени.
  • IRIG-B (Inter Range Instrumentation Group) – С помощью данной технологии передается информация о дате и времени вместе с импульсным сигналом синхронизации. IRIG-B используют выделенную сеть для передачи информации. Сеть может быть построена на оптическом волокне, витой паре или коаксиальном кабеле.

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

  • Слой 0 — Эталонные часы (например, атомные часы или часы GPS)
  • Слой 1 — Серверы времени, подключённые напрямую к эталонным часам. Часы этого слоя считаются лучшими источниками времени в системе
  • Слой 2 — Серверы времени, которые синхронизируются с часами слоя 1

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

  • SNTP (Simple Network Time Protocol) – Простой протокол сетевого времени. Применяется в локальных сетях для некритичных ко времени приложений. Формат сообщений, которыми между собой обмениваются устройства в системах SNTP и NTP, идентичен, поэтому протоколы совместимы друг с другом. В отличии от NTP, у SNTP нет сложных алгоритмов сравнения и выбора наилучшего сервера времени, поэтому устройство может быть синхронизировано только с одним сервером времени, и, если данные на сервере ошибочные, то конечное устройство не узнает об этом.

Более подробно познакомимся с протоколом синхронизации точного времени — PTP.

Стандарт IEEE 1588 v2

Для систем, которым не хватает точности синхронизации, предоставляемой протоколами NTP/SNTP, был разработан стандарт IEEE 1588 v2. Данный стандарт описывает протокол точного времени — PTP (Precision Time protocol). PTP предназначен для использования в локальных сетях и гарантирует высокую точность синхронизации.

Протокол PTP может быть реализован на программном или аппаратном уровне устройства. Наиболее точной является реализация на аппаратном уровне. Точность достигается за счет проставления меток времени сообщений PTP на аппаратном уровне интерфейсов Ethernet.

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

Типы устройств в системе РТР:

  • Гроссмейстерские часы (Grandmaster) – основные часы, по которым синхронизируется время в системе
  • Ведущие часы (Master) – часы, которые выступают в качестве источников точного времени для конечных устройств
  • Ведомые часы (Slave)– конечные устройства, на которых необходимо осуществить синхронизацию времени по протоколу PTP
  • Граничные часы (Boundary Clock)– сетевое оборудование (коммутаторы), которое будет выступать в качестве ведомого устройства для гроссмейстерских часов, и источником точного времени для конечных устройств. При этом коммутаторы также должны поддерживать РТР
  • Прозрачные часы (Transparent Clock) – коммутатор, который только измеряет время прохождения сообщений синхронизации сквозь себя и предоставляет информацию устройствам, которые участвуют в процессе синхронизации времени

Выбор Гроссмейстера

В системе PTP может быть несколько источников точного времени, но активным может быть только один. Для выбора гроссмейстера у PTP есть специальный механизм — Best Master Clock Algorithm (BMCA), который гарантирует отказоустойчивость системы PTP. Как только предыдущий гроссмейстер не может выполнять свою роль (например, потеря связи по GPS, сбой в работе самого мастера или потеря связи с системой PTP), то следующие часы, претендующие на роль основного мастера по критериям BMCA, автоматически станут источником точного времени для конечных устройств. Для этого все ведущие часы системы постоянно находятся в режиме прослушивания сообщений, отправленных на широковещательный адрес PTP, и, в случае необходимости, присваивают себе роль гроссмейстера.

Критерии BMCA

  • Priority 1 Field – поле первого приоритета. Значения от 0 до 255, устанавливается пользователем. Мастер выбирается по наиболее низкому приоритету (обычно ведущим часам присваивается приоритет ниже 128, а 255 для ведомых устройств)
  • Clock Class — класс часов. Например, часы с GPS-приемником имеют лучший приоритет в сравнении с часами, выставленными вручную
  • Clock Accuracy – точность синхронизации.
  • Clock Variance – изменения часов (джиттер и отклонения, определяются сложным логарифмическим путем)
  • Source Port ID – идентификатор порта источника (обычно МАС-адрес)
  • Priority 2 Field – поле второго приоритета. Также устанавливается пользователем

Диаграмма состояний часов в системе

Механизмы обмена сообщениями в PTP

Основные типы сообщений PTP

  • Announce – сообщения содержащие параметры для определения основного мастера системы по алгоритму BMCA
  • Sync — сообщения от ведущих часов, которые передают информацию о времени
  • Follow Up – отправляются ведущими часами сразу после отправки сообщения типа sync. Данные сообщения содержат метку времени отправки сообщения sync и корректирующее значение. Используются для корректировки значения времени.
  • Delay – сообщения, которыми обмениваются ведомые и ведущие устройства, для определения задержки распространения сообщений синхронизации по линиям связи между ними

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

PTP может рассчитывать задержку двумя методами:

1. Метод one step (одношаговый)

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

Метка времени t2 – это время получения сообщения ведомым устройством.

Данный режим работы позволяет уменьшить трафик PTP системы за счет отсутствия сообщений типа follow up.

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

2. Метод two step (двухшаговый)

Механизм работы такой же как одношаговый, но метка времени t1 отправляется вторым сообщением follow up сразу после сообщения синхронизации.

Режимы работы PTP

Есть два режима вычисления задержек в системе PTP: End-to-End и Peer-to-Peer. В одной системе лучше использовать одинаковый режим работы для более корректной синхронизации устройств.

1. End-to-End

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

+ В топологии могут принимать участия коммутаторы без поддержки PTP.
Большая нагрузка на основного мастера
2. Peer-to-peer

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

+ Быстрая адаптация PTP при перестроении топологии
Малая нагрузка на основного мастера
В топологии могут принимать участия только коммутаторы с поддержкой PTP

Power профиль PTP

В стандарте IEEE 1588 v2 описано очень много параметров для системы PTP. Чтобы было проще ориентироваться в них и понимать, какие именно настройки необходимы для той или иной системы, были созданы профили PTP.

Существует отдельный профиль, определяющий синхронизацию PTP для энергетических объектов. Данный профиль гарантирует точность синхронизации до 1 мкс в топологиях с радиусом не более 16 узлов от основного мастера точного времени.

Основные параметры профиля можно увидеть в таблице:

Power профиль PTP
Время синхронизации 1 мкс
Сеть Только сеть 2 уровня модели OSI
Адресация Multicast
Роли устройств Все, кроме Граничных часов
Метод расчета задержки Одношаговый или двухшаговый
Режим работы Peer-to-Peer
Устройства в топологии Только с поддержкой PTP

Использование профиля Power Profile на энергетических подстанциях гарантирует полное соответствие требованиям стандарта МЭК 61850 в разрезе синхронизации времени.

Многие управляемые коммутаторы Moxa поддерживают синхронизацию по протоколу PTP. Аппаратную реализацию PTP и возможность выбора Power профиля поддерживают коммутаторы серий PT-G503, PT-7728-PTP и PT-G7728/7828.

Сетевой протокол времени — Network Time Protocol

Стандартный протокол для синхронизации времени между устройствами

Протокол сетевого времени ( NTP ) является сетевым протоколом для синхронизации часов между компьютерными системами по коммутации пакеты , с переменной латентностью сетей передачи данных. В действии с 1985 года, NTP является одним из старейших Интернет-протоколов, используемых в настоящее время. NTP был разработан Дэвидом Л. Миллсом из Университета Делавэра .

NTP предназначен для синхронизации всех участвующих компьютеров с точностью до нескольких миллисекунд по всемирному координированному времени (UTC). Он использует алгоритм пересечения , модифицированную версию алгоритма Марзулло , для выбора серверов точного времени и предназначен для смягчения эффектов переменной задержки в сети . NTP обычно может поддерживать время с точностью до десятков миллисекунд в общедоступном Интернете и может достигать точности выше одной миллисекунды в локальных сетях в идеальных условиях. Асимметричные маршруты и перегрузка сети могут вызывать ошибки в 100 мс и более.

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

Текущий протокол — это версия 4 (NTPv4), которая является предлагаемым стандартом, как описано в RFC   5905 . Он обратно совместим с версией 3, указанной в RFC   1305 .

История

Эволюция RFC для NTP

1980 —

1985 —

1990 —

1995 —

2000 —

2005 —

2010 —

2015 —

2020 —

Служба интернет-часов DCNET

В 1979 году технология сетевой синхронизации времени была использована в, возможно, первой публичной демонстрации Интернет- сервисов, работающих через трансатлантическую спутниковую сеть, на Национальной компьютерной конференции в Нью-Йорке. Позднее технология была описана в Инженерном примечании к Интернету (IEN) 173 1981 года, и на ее основе был разработан общедоступный протокол, который был задокументирован в RFC   778 . Технология была впервые развернута в локальной сети как часть протокола маршрутизации Hello и реализована в маршрутизаторе Fuzzball , экспериментальной операционной системе, используемой для создания прототипов сети, где она работала в течение многих лет.

Другие связанные сетевые инструменты были доступны и тогда, и сейчас. Они включают дневные и временные протоколы для записи времени событий, а также сообщения ICMP Timestamp и опцию IP Timestamp ( RFC   781 ). Более полные системы синхронизации, хотя и не имеют алгоритмов анализа данных и контроля часов NTP, включают в себя демон Unix timed , который использует алгоритм выбора для назначения сервера для всех клиентов; и служба цифровой синхронизации времени (DTSS), которая использует иерархию серверов, аналогичную модели слоя NTP.

В 1985 году версия NTP 0 (NTPv0) была реализована как в Fuzzball, так и в Unix, а заголовок пакета NTP, а также вычисления задержки и смещения туда и обратно, которые сохранились в NTPv4, были задокументированы в RFC   958 . Несмотря на относительно медленные компьютеры и сети, доступные в то время, точность, превышающая 100 миллисекунд, обычно достигалась на переходных каналах Атлантики с точностью до десятков миллисекунд в сетях Ethernet .

В 1988 году гораздо более полная спецификация протокола NTPv1 с соответствующими алгоритмами была опубликована в RFC   1059 . Он основывался на результатах экспериментов и алгоритме тактовой фильтрации, описанном в RFC   956, и был первой версией, описывающей режимы клиент-сервер и одноранговые сети . В 1991 году архитектура, протокол и алгоритмы NTPv1 были доведены до сведения более широкого инженерного сообщества после публикации статьи Дэвида Л. Миллса в IEEE Transactions on Communications .

В 1989 году был опубликован RFC   1119, определяющий NTPv2 с помощью конечного автомата с псевдокодом для описания его работы. Он представил протокол управления и схему криптографической аутентификации , которые пережили NTPv4 вместе с основной частью алгоритма. Однако дизайн NTPv2 подвергся критике со стороны сообщества DTSS за отсутствие формальной корректности , и процедура выбора часов была изменена, чтобы включить алгоритм Марзулло для NTPv3 и далее.

В 1992 году RFC   1305 определил NTPv3. RFC включал анализ всех источников ошибок, от эталонных часов до конечного клиента, что позволило вычислить метрику, помогающую выбрать лучший сервер, на котором несколько кандидатов не согласны. Введен широковещательный режим.

В последующие годы, когда были добавлены новые функции и усовершенствованы алгоритмы, стало очевидно, что требуется новая версия протокола. В 2010 году был опубликован RFC   5905, содержащий предлагаемую спецификацию для NTPv4. С тех пор протокол значительно продвинулся вперед, и по состоянию на 2014 год обновленный RFC еще не опубликован. После выхода на пенсию Миллса из Университета Делавэра эталонная реализация в настоящее время поддерживается как проект с открытым исходным кодом, возглавляемый Харланом Стенном.

Слои часов

Желтые стрелки указывают на прямое соединение; красные стрелки указывают на сетевое соединение.

NTP использует иерархическую полууровневую систему источников времени. Каждый уровень этой иерархии называется стратой, и наверху ему присваивается номер, начинающийся с нуля для эталонных часов. Сервер, синхронизированный с сервером уровня n, работает на уровне n + 1. Число представляет собой расстояние от эталонных часов и используется для предотвращения циклических зависимостей в иерархии. Stratum не всегда является показателем качества или надежности; часто находят источники времени слоя 3, которые более высокого качества, чем другие источники времени слоя 2. Краткое описание пластов 0, 1, 2 и 3 приводится ниже.

Уровень 0
Это высокоточные устройства для измерения времени, такие как атомные часы , GPS или другие радиочасы . Они генерируют очень точный импульсный сигнал в секунду, который запускает прерывание и временную метку на подключенном компьютере. Устройства Stratum 0 также известны как эталонные часы. Серверы NTP не могут объявлять себя слоем 0. Поле страты, установленное в 0 в пакете NTP, указывает на неопределенный слой.
Уровень 1
Это компьютеры, системное время которых синхронизировано с точностью до нескольких микросекунд по сравнению с подключенными к ним устройствами уровня 0. Серверы уровня 1 могут взаимодействовать с другими серверами уровня 1 для проверки работоспособности и резервного копирования. Их также называют первичными серверами времени.
Уровень 2
Это компьютеры, которые синхронизируются по сети с серверами уровня 1. Часто компьютер уровня 2 запрашивает несколько серверов уровня 1. Компьютеры уровня 2 могут также взаимодействовать с другими компьютерами уровня 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых устройств.
Уровень 3
Это компьютеры, которые синхронизированы с серверами уровня 2. Они используют те же алгоритмы для пиринга и выборки данных, что и для уровня 2, и сами могут выступать в качестве серверов для компьютеров уровня 4 и т. Д.

Верхний предел для страты — 15; stratum 16 используется, чтобы указать, что устройство не синхронизировано. Алгоритмы NTP на каждом компьютере взаимодействуют, чтобы построить связующее дерево кратчайшего пути Беллмана-Форда , чтобы минимизировать накопленную задержку приема-передачи к серверам страты 1 для всех клиентов.

Помимо страты, протокол может идентифицировать источник синхронизации для каждого сервера с помощью ссылочного идентификатора (refid).

Коды общих справочных идентификаторов (refid)
Идентификатор ссылки (refid) Источник часов
ИДЕТ Спутник на геостационарной орбите
GPS спутниковая система навигации
GAL Система позиционирования Галилео
PPS Общая частота импульсов в секунду
ИРИГ Группа межрайонного приборостроения
WWVB LF Radio WWVB Форт-Коллинз, Колорадо, 60 кГц
DCF LF Radio DCF77 Mainflingen, DE 77,5 кГц
HBG LF Radio HBG Prangins, HB 75 кГц (работа прекращена)
MSF LF Radio MSF Anthorn, Великобритания 60 кГц
JJY LF Radio JJY Фукусима, JP 40 кГц, Сага, JP 60 кГц
LORC МФ Радио Лоран-С , 100
TDF MF Radio Allouis, FR 162 кГц
CHU HF Radio CHU Оттава, Онтарио
WWV HF Radio WWV Форт-Коллинз, Колорадо
WWVH ВЧ радио WWVH Кауаи, Гавайи
NIST Телефонный модем NIST
ДЕЙСТВИЯ Телефонный модем NIST
USNO Телефонный модем USNO
PTB Немецкий телефонный модем стандарта времени PTB
Г-ЖА Множественные справочные источники
XFAC Inter Face Association Changed (IP-адрес изменен или утерян)
ШАГ Изменение времени шага, смещение меньше порога паники (1000 с), но больше порога шага (125 мс)

Отметки времени

64-битные временные метки, используемые NTP, состоят из 32-битной части для секунд и 32-битной части для дробной секунды, что дает шкалу времени, которая перемещается каждые 2 32 секунды (136 лет) и теоретическое разрешение 2-32 секунды (233 пикосекунды). NTP использует эпоху 1 января 1900 года. Таким образом, первое обновление происходит 7 февраля 2036 года.

NTPv4 вводит 128-битный формат даты: 64 бита для второй и 64 бита для дробной секунды. Наиболее важные 32 бита этого формата — это номер эры, который в большинстве случаев устраняет неоднозначность при опрокидывании. По словам Миллса, «64-битного значения дроби достаточно, чтобы определить количество времени, необходимое фотону для прохождения электрона со скоростью света. 64-битного значения секунды достаточно, чтобы обеспечить однозначное представление времени до тех пор, пока Вселенная тускнеет «.

Алгоритм синхронизации часов

Время задержки туда и обратно δ

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

θ знак равно | ( т 1 — т 0 ) + ( т 2 — т 3 ) 2 | {\ displaystyle \ theta = \ left \ vert {\ frac {(t_ {1} -t_ {0}) + (t_ {2} -t_ {3})} {2}} \ right \ vert} ,

и задержку приема -передачи δ на

δ знак равно ( т 3 — т 0 ) — ( т 2 — т 1 ) {\ displaystyle \ delta = {(t_ {3} -t_ {0}) — (t_ {2} -t_ {1})}} ,

куда

t 0 — метка времени клиента передачи пакета запроса,
t 1 — временная метка сервера приема пакета запроса,
t 2 — временная метка сервера передачи пакета ответа и
t 3 — метка времени клиентом получения пакета ответа.

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

т 0 + θ + δ / 2 знак равно т 1 {\ displaystyle t_ {0} + \ theta + \ delta / 2 = t_ {1}}

а для ответного пакета

т 3 + θ — δ / 2 знак равно т 2 {\ displaystyle t_ {3} + \ theta — \ delta / 2 = t_ {2}}

Решение для θ дает определение смещения по времени.

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

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

Программные реализации

Утилита протокола управления NTP ntpq используется для запроса состояния сервера уровня 2.

Эталонная реализация

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

SNTP

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

Время Windows

Все версии Microsoft Windows, начиная с Windows 2000, включают службу времени Windows (W32Time), которая может синхронизировать часы компьютера с сервером NTP.

W32Time изначально был реализован для протокола проверки подлинности Kerberos версии 5, который требовал, чтобы время находилось в пределах 5 минут от правильного значения для предотвращения атак повторного воспроизведения . Версия для Windows 2000 и Windows XP реализует только SNTP и нарушает некоторые аспекты стандарта NTP версии 3.

Начиная с Windows Server 2003 и Windows Vista , включена соответствующая реализация NTP. Microsoft заявляет, что W32Time не может надежно поддерживать синхронизацию времени с точностью до одной секунды. Если требуется более высокая точность, Microsoft рекомендует использовать более новую версию Windows или другую реализацию NTP.

Windows 10 и Windows Server 2016 поддерживают точность времени 1 мс при определенных условиях эксплуатации.

OpenNTPD

В 2004 году Хеннинг Брауэр представил OpenNTPD , реализацию NTP с упором на безопасность и охватывающую дизайн с разделением привилегий. Хотя он нацелен на более простые общие потребности пользователей OpenBSD , он также включает некоторые улучшения безопасности протокола, при этом оставаясь совместимым с существующими серверами NTP. Переносимая версия доступна в репозиториях пакетов Linux.

Нтимед

Новый клиент NTP, ntimed , был запущен Полом-Хеннингом Кампом в 2014 году. Новая реализация спонсируется Linux Foundation в качестве замены эталонной реализации, поскольку было определено, что проще написать новую реализацию с нуля, чем уменьшить размер эталонной реализации. Хотя он не был официально выпущен, ntimed может надежно синхронизировать часы.

NTPsec

NTPsec является вилка эталонной реализации , которая была систематически безопасности закаленные . Точка разветвления пришлась на июнь 2015 года и возникла в ответ на серию компромиссов в 2014 году. Первый производственный выпуск был выпущен в октябре 2017 года. Между удалением небезопасных функций, удалением поддержки устаревшего оборудования и удалением поддержки устаревших вариантов Unix, NTPsec удалось сократить 75% исходной кодовой базы, сделав оставшуюся более доступной для аудита. Аудит кода 2017 года показал восемь проблем безопасности, в том числе две, которых не было в исходной эталонной реализации, но NTPsec не пострадал от восьми других проблем, которые остались в эталонной реализации.

хрония

chrony по умолчанию входит в дистрибутивы Red Hat и доступен в репозиториях Ubuntu . chrony нацелен на обычные компьютеры, которые нестабильны, переходят в спящий режим или имеют прерывистое подключение к Интернету. chrony также разработан для виртуальных машин, гораздо более нестабильной среды. Он отличается низким потреблением ресурсов (стоимостью) и поддерживает оборудование протокола точного времени для большей точности временных меток. Он состоит из двух основных компонентов: chronyd, демона, который запускается при запуске компьютера, и chronyc, интерфейса командной строки для пользователя для его настройки. Он был оценен как очень безопасный и с небольшим количеством инцидентов, его преимуществом является универсальность кода, написанного с нуля, чтобы избежать ненужной сложности. chrony доступен под лицензией GNU General Public License версии 2 , был создан Ричардом Курноу в 1997 году и в настоящее время поддерживается Мирославом Личваром .

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

В день события секунды координации ntpd получает уведомление либо от файла конфигурации, либо от прикрепленных эталонных часов, либо от удаленного сервера. Хотя часы NTP фактически останавливаются во время события, из-за требования о том, что время должно казаться монотонно увеличивающимся , любые процессы , запрашивающие системное время, вызывают его небольшое увеличение, сохраняя порядок событий. Если когда-либо возникнет необходимость в отрицательной дополнительной секунде, она будет удалена с последовательностью 23:59:58, 00:00:00, пропуская 23:59:59.

Альтернативная реализация, называемая сглаживанием скачка, заключается во введении дополнительной секунды постепенно в течение 24 часов, с полудня до полудня по всемирному координированному времени. Эта реализация используется Google (как внутри компании, так и на их общедоступных серверах NTP) и Amazon AWS.

Проблемы безопасности

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

Переполнение стека эксплуатируют был обнаружен и исправлен в 2014 году компании Apple был обеспокоен достаточно об этом vulerability , что он использовал свои возможности автоматического обновления в первый раз. Некоторые ошибки реализации являются простыми, например, отсутствующий оператор возврата в подпрограмме, что может привести к неограниченному доступу к системам, в которых запущены некоторые версии NTP в корневом демоне. Системы, в которых не используется корневой демон, например BSD, не подвержены этому недостатку.

Аудит безопасности трех реализаций NTP в 2017 году, проведенный от имени Linux Foundation Core Infrastructure Initiative, показал, что и NTP, и NTPsec были более проблематичными, чем Chrony с точки зрения безопасности.

Серверы NTP могут быть уязвимы для атак типа « злоумышленник в середине», если пакеты не подписаны криптографически для аутентификации. Связанные с этим вычислительные затраты могут сделать это непрактичным на загруженных серверах, особенно во время атак типа «отказ в обслуживании» . Подмена сообщений NTP в результате атаки «злоумышленник-посередине» может использоваться для перемещения часов на клиентских компьютерах и обеспечения ряда атак, основанных на обходе истечения срока действия криптографического ключа. Некоторые из выявленных поддельных сообщений NTP затрагивают такие службы, как TLS , DNSSEC , различные схемы кэширования (например, DNS-кеш), BGP, биткойн и ряд постоянных схем входа в систему.

NTP использовался в распределенных атаках типа «отказ в обслуживании» . На сервер NTP отправляется небольшой запрос с подмененным адресом возврата, который является целевым адресом. Подобно атаке с усилением DNS , сервер отвечает гораздо большим ответом, который позволяет злоумышленнику существенно увеличить объем данных, отправляемых цели. Чтобы избежать участия в атаке, можно обновить программное обеспечение сервера NTP или настроить серверы на игнорирование внешних запросов.

Смотрите также

Примечания

Рекомендации

дальнейшее чтение

внешняя ссылка

Как работает протокол сетевого времени?



Запись в Википедии не дает подробностей, а RFC слишком плотная. Кто-нибудь здесь вообще знает, как работает NTP?

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

time synchronization ntp
Поделиться Источник Waylon Flinn     04 августа 2009 в 15:13

4 ответа


  • двоичный протокол-трюк с подкачкой байтов

    допустим, у нас есть двоичный протокол с упорядоченной сетью полей (big endian). struct msg1 { int32 a; int16 b; uint32 c } если вместо копирования сетевого буфера в мой msg1, а затем использовать функции networkToHost для чтения msg1 Я переставляю / переворачиваю msg1 на struct msg1 { uint32 c…

  • Протокол сетевого времени для iPhone

    Я пишу заявление, которое требует точного времени. Задав этот вопрос , я решил исследовать его с помощью NTP или, может быть, простого NTP. Существует ли какая-либо реализация этих протоколов с открытым исходным кодом для iPhone? До сих пор мне удавалось найти неработающую ссылку . Я также знаю ,…



95

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

Во-первых, NTP временных меток хранятся в секундах с 1 января 1900 г. 32 бита для числа секунд и 32 бита для долей секунды.

Синхронизация сложна. Клиент сохраняет timestamp (скажем, A) (все эти значения находятся в секундах), когда он отправляет запрос. Сервер отправляет ответ, состоящий из «true» времени, когда он получил пакет (назовите это X), и «true» времени, когда он передаст пакет (Y). Клиент получит этот пакет и зарегистрирует время его получения (B).

NTP предполагает, что время, проведенное в сети, одинаково для отправки и получения. Через достаточные промежутки времени по вменяемым сетям это должно быть в среднем так. Мы знаем, что общее транзитное время от отправки запроса до получения ответа составило B-A секунду. Мы хотим удалить время, которое сервер потратил на обработку запроса (Y-X), оставив только время обхода сети, так что это B-A-(Y-X). Поскольку мы предполагаем, что время обхода сети симметрично, количество времени, которое потребовалось ответу от сервера к клиенту, равно [B-A-(Y-X)]/2. Итак, мы знаем, что сервер отправил свой ответ в момент времени Y, и нам потребовалось [B-A-(Y-X)]/2 секунды, чтобы этот ответ дошел до нас.

Таким образом, истинное время, когда мы получили ответ, — Это Y+[B-A-(Y-X)]/2 секунды. И вот как работает NTP.

Пример (в целых секундах, чтобы сделать математику легкой):

  • Клиент отправляет запрос в «wrong» время 100. А=100.
  • Сервер получает запрос в «true» времени 150. X=150.
  • Сервер работает медленно, поэтому он не отправляет ответ до «true» времени 160. Y=160.
  • Клиент получает запрос в «wrong» время 120. B=120.
  • Клиент определяет, сколько времени он проводит в сети. B-A-(Y-X)=120-100-(160-150)=10 секунды
  • Клиент предполагает, что время, необходимое для получения ответа от сервера к клиенту, составляет 10/2=5 секунд.
  • Клиент добавляет это время к «true» времени, когда сервер отправил ответ, чтобы оценить, что он получил ответ в «true» времени 165 секунд.
  • Теперь клиент знает, что ему нужно добавить 45 секунд к своим часам.

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

Конечно, для правильной реализации требуется нечто большее, но суть именно в этом.

Поделиться David     05 августа 2009 в 02:02



7

  1. Клиент NTP спрашивает у всех своих серверов NTP, который час.
  2. Разные серверы будут давать разные ответы, с разными уровнями доверия, потому что запросы будут занимать разное количество времени, чтобы пройти от клиента к серверу и обратно.
  3. Алгоритм марзулло найдет наименьший диапазон значений времени, согласующийся со всеми предоставленными ответами.
  4. Вы можете быть более уверены в точности ответа от этого алгоритма, чем от любого отдельного сервера времени, потому что пересечение нескольких наборов, скорее всего, будет содержать меньше элементов, чем любой отдельный набор.
  5. Чем больше серверов вы запросите, тем больше ограничений у вас будет на возможный ответ, и тем точнее будут ваши часы.

Поделиться nont     05 августа 2009 в 01:20



0

Если вы используете временные метки для принятия решения о заказе, конкретное время может быть несущественным. Вместо этого вы можете использовать часы lamport , которые менее болезненны, чем сетевая синхронизация. Он может сказать вам, что произошло «first», но не точную разницу во времени. Ему все равно, что на самом деле говорят часы компьютера.

Поделиться Ape-inago     05 августа 2009 в 02:44


  • Класс отметок времени в пакете org.apache.commons.net

    Я хочу использовать отметку времени как часть моего приложения (я использую JAVA).Меня попросили использовать протокол сетевого времени (NTP).Я искал в google, и мне удалось найти пакет org.apache.commons.net, где есть класс TimeStamp. Я прошел по этой ссылке , чтобы узнать больше об этом классе….

  • Автомобиль OBDII протокол подключения

    В настоящее время я ищу спецификацию протокола WLAN, чтобы получить данные OBDII. На рынке есть несколько аналогичных адаптеров ELM327, которые позволяют iPhone подключаться к интерфейсу OBDII с WLAN. Это потому, что последовательный порт Bluetooth скремблирован из-за интерфейса аксессуаров….



-2

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

Поделиться starblue     04 августа 2009 в 17:55


Похожие вопросы:


Захват сетевого трафика на Linux

Вопрос: у меня есть один ноутбук Windows, один ноутбук Linux и беспроводной маршрутизатор. Теперь я хочу investigate протокол hotmail/windows live. Я хочу направить сетевой трафик с ноутбука windows…


Синхронизация сетевого времени с Java

Я создаю потоковое приложение p2p audio-midi с использованием Java (к сожалению) и ищу способ обеспечить синхронизацию сетевого времени между определенными одноранговыми узлами (источниками) с…


Разработка протокола сетевого уровня в C

Я хочу разработать собственный протокол сетевого уровня. Я полагаю, что это можно сделать с помощью C. Может ли кто-нибудь подсказать, с чего начать? Любые ссылки или примеры кода были бы очень…


двоичный протокол-трюк с подкачкой байтов

допустим, у нас есть двоичный протокол с упорядоченной сетью полей (big endian). struct msg1 { int32 a; int16 b; uint32 c } если вместо копирования сетевого буфера в мой msg1, а затем использовать…


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

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


Класс отметок времени в пакете org.apache.commons.net

Я хочу использовать отметку времени как часть моего приложения (я использую JAVA).Меня попросили использовать протокол сетевого времени (NTP).Я искал в google, и мне удалось найти пакет…


Автомобиль OBDII протокол подключения

В настоящее время я ищу спецификацию протокола WLAN, чтобы получить данные OBDII. На рынке есть несколько аналогичных адаптеров ELM327, которые позволяют iPhone подключаться к интерфейсу OBDII с…


Получение метки времени сетевого протокола времени (NTP)

gcc (GCC) 4.6.1 Я создаю некоторый sdp, используя RTF 4566, и я хочу получить отметку времени NTP, чтобы использовать ее для сеанса ID. Для обеспечения уникальности рекомендуется использовать…


ipsec — (шифрование сетевого трафика) на SDN

Протокол OpenFlow (1.0 и 1.1) не определяет никакого механизма шифрования сетевого трафика (трафика между коммутаторами).. Возможно ли шифровать сетевой трафик в сетях SDN.. (например, запустить…


Где лежит протокол http в рамках rails?

Я просто хотел знать, где находится фреймворк HTTP в rails и как реализовать другой протокол для связи клиент-сервер с использованием другого сетевого уровня? Есть новый протокол под названием QUIC…

Введение в протокол сетевого времени и синхронизацию сетевого времени сервера

Протокол сетевого времени (англ. Network Time Protocol, аббревиатура: NTP) — это сетевой протокол для синхронизации часов между компьютерными системами с переменной задержкой в ​​сети передачи данных посредством коммутации пакетов, расположенный на прикладном уровне модели OSI. С 1985 года NTP является одним из старейших Интернет-протоколов, которые все еще используются. NTP был разработан Дэвидом Л. Миллсом из Университета Делавэра.
NTP намеревается синхронизировать время всемирного координированного времени (UTC) всех участвующих компьютеров с точностью до нескольких миллисекунд. Он использует модифицированную версию алгоритма Марзулло для выбора точного сервера времени и предназначен для смягчения последствий переменных сетевых задержек. NTP обычно может поддерживать ошибку в десятки миллисекунд в общедоступном Интернете и может достигать точности более 1 миллисекунды в идеальной среде локальной сети. Асимметричная маршрутизация и контроль перегрузки могут вызывать ошибки в 100 миллисекунд (или больше).
Этот протокол обычно описывается как архитектура ведущий-ведомый, но его также можно использовать в одноранговой сети, где оба узла могут идентифицировать другой конец как потенциальный источник времени. Временные метки отправки и получения реализуются с использованием порта 123 протокола пользовательских дейтаграмм (UDP). Это также может использовать широковещательную или многоадресную рассылку, когда клиент пассивно прослушивает обновления времени после первоначального обмена калибровкой в ​​оба конца. NTP выдает предупреждение о предстоящей корректировке секунды координации, но не передает информацию о местном часовом поясе или переходе на летнее время.
Текущий протокол — версия 4 (NTPv4), который является рекомендованным стандартом в документе RFC 5905. Он обратно совместим с версией 3, указанной в RFC 1305.

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

DNS настроен

Сервер имеет доступ к внешней сети и настроен с помощью DNS, напрямую

ntpdate 0.cn.pool.ntp.org 或 nptdate ntp1.aliyun.com

Вы можете синхронизировать время внешней сети.

DNS не настроен

Из соображений безопасности некоторые серверы подключены к внешней сети, но DNS не настроен.В этом случае время необходимо синхронизировать непосредственно с IP-адреса сервера времени. Вы можете использовать IP-адрес сервера времени Aliyun (ntp1.aliyun.com) для прямой синхронизации,

ntpdate 120.24.81.91  或者 清华的时间服务器ntpdate 84.16.73.33

Предполагая, что в локальной сети есть сервер (IP-адрес — IP_TIME), время правильное, настройте этот сервер как локальный сервер времени ntp, и другие серверы будут выполнять

ntpdate IP_TIME

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

Предположим, что есть два Linux-сервера A и B, и оба они должны быть синхронизированы с сетевым временем.
A подключен к внешней сети. Хотя DNS-сервер не настроен, он может пинговать 120.24.81.91 (сервер облачного времени Alibaba). Вы можете синхронизировать время напрямую.
B не открывает внешнюю сеть, и ping 120.24.81.91 сообщит о подключении: сеть недоступна, что определенно не может синхронизировать время с внешним сетевым сервером. Запустите ntpdate 120.24.81.91, он сообщит, что сервер, подходящий для синхронизации, не найден, или серверы не могут быть использованы, и завершится.

Решение разделено на три этапа: брандмауэры A и B закрыты, и весь процесс управляется учетной записью root.

  1. A синхронизировать время из внешней сети,
  2. Настройте A как сервер ntp (сервер NTP),
  3. B синхронизирует время с A.

Сетевое время ASync

Время первой синхронизации сервера отображается следующим образом

[[email protected] ~]# ntpdate 120.24.81.91
10 Aug 09:46:07 ntpdate[15071]: step time server 120.24.81.91 offset 1.423469 sec

2-й раз отображается следующим образом

[[email protected] ~]# ntpdate 120.24.81.91
10 Aug 14:16:14 ntpdate[12150]: adjust time server 120.24.81.91 offset -0.030012 sec

Каждый раз, когда он выполняется, ошибка за смещением будет меняться, и тренд будет все более и более точным.#/) {print $0}}’ restrict default ignore //#设置默认策略为允许任何主机进行时间同步 restrict 127.0.0.1 //给于本机所有权限 restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap //给于局域网机的机器有同步时间的权限 server 0.127.127.1.0 //设置时间服务器为本机,可以设为120.24.81.91外网服务器 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys

Затем выполните

# /etc/init.d/ntpd start 或 #service ntpd start

Будет отображаться OK, что означает успешное выполнение. Устройство уже является сервером NTP.

Если файл конфигурации неоднократно изменяется, выполните

# /etc/init.d/ntpd restart

Перезагрузите файл конфигурации.

B и A синхронизируют время

После того, как A запускает службу сервера NTP, он должен подождать 5 минут перед выполнением команды времени синхронизации на B. Это время используется сервером NTP для синхронизации местного времени.
Выполнить на B через 5 минут

[[email protected] ~]# ntpdate AIP (AIP是A的内网IP地址)
10 Aug 13:35:59 ntpdate[10737]: adjust time server AIP offset 0.004937 sec

, Вы можете синхронизировать системное время A и B, что эквивалентно синхронизации времени внешней сети.

Поскольку время самого NTP-сервера не было синхронизировано с операционной системой, будет возвращена ошибка

no server suitable for synchronization found

Для просмотра можно использовать команду ntpdate -d AIP.

[[email protected] ~]# ntpdate -d AIP
10 Aug 13:28:07 ntpdate[10719]: ntpdate [email protected] Thu Oct  5 04:11:32 EDT 2006 (1)
Looking for host 192.168.2.10 and service ntp
host found : 192.168.2.10
transmit(192.168.2.10)
receive(192.168.2.10)
省略
192.168.2.10: Server dropped: strata too high
server 192.168.2.10, port 123
stratum 16, precision -20, leap 11, trust 000
refid [192.168.2.10], delay 0.02573, dispersion 0.00000
省略  

Появляется подсказка «Сервер упал: слишком высокий уровень» и «Уровень 16».
Нормальный диапазон слоев составляет «0 ~ 15».
Вам не нужно ничего делать, подождите немного и попробуйте выполнить команду, она станет стратой 11, точностью -20, прыжком 00, доверием 000. Уровень 11 — это нормальный диапазон, и время успешно синхронизируется путем выполнения ntpdate AIP.

B. Если вам нужно часто корректировать время, crontab настраивает команду ntpdate для достижения цели.

crontab -e  
9 7 * * * /usr/sbin/ntpdate  AIP

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

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

1. ntpdate 外网时间服务器ip
2. service ntpd start
3. 间隔一段可接受的时间,间隔约长,和网络时间的误差越大。
   此时B可同步到A的时间
4. service ntpd stop
下面循环回第一步
1. ntpdate 外网时间服务器ip

Как работает протокол синхронизации PTPv2 / Статьи и обзоры / Элек.ру

Введение


Концепция построения «Цифровой подстанции» в электроэнергетике требует синхронизации с точностью 1 мкс. Для проведения финансовых транзакций также требуется точность в мкс. В этих приложениях точности времени NTP уже недостаточно.

Протокол синхронизации PTPv2, описанный стандартом IEEE 1588v2, позволяет добиться точности синхронизации в несколько десятков наносекунд. PTPv2 позволяет отправлять пакеты синхронизации через L2 и L3-сети.

Основными областями, где применяется PTPv2, являются:

  • энергетика;
  • контрольно-измерительное оборудование;
  • оборонно-промышленный комплекс;
  • телеком;
  • финансовый сектор.

В статье разбирается, как работает протокол синхронизации PTPv2.

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

Зачем необходим

На данный момент в СТО 34.01-21-004-2019 ПАО «Россети» и в СТО 56947007-29.240.10.302-2020 ПАО «ФСК ЕЭС» содержатся требования к организации шины процесса с обеспечением синхронизации времени по PTPv2.

Связано это с тем, что к шине процесса подключаются терминалы релейной защиты и устройства измерения, которые через шину процесса, при помощи так называемых SV-потоков (multicast-потоки), передают мгновенные значения тока и напряжения.

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

Например, жертвой «слабой» синхронизации времени могут стать защиты абсолютной селективности. Часто логика подобных защит строится на сравнении двух величин. Если величины расходятся на достаточно большое значение, то защита срабатывает. Если эти величины измерить с точностью времени 1 мс, то можно получить большую разницу там, где значения на самом деле находятся в норме, если измерить их с точностью 1 мкс.

Версии PTP

Протокол PTP был изначально описан в 2002 году в стандарте IEEE 1588-2002 и имел название «Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems». В 2008 году был выпущен обновленный стандарт IEEE 1588-2008, который описывает PTP Version 2. В этой версии протокола была улучшена точность и стабильность, но не была сохранена обратная совместимость с первой версией протокола. Также, в 2019 году вышла версия стандарта IEEE 1588-2019, описывающая PTP v2.1. Эта версия добавляет небольшие улучшения к PTPv2 и является обратно совместимой с PTPv2.

Другими словами, имеем следующую картину с версиями:

PTPv1 (IEEE 1588-2002) PTPv2 (IEEE 1588-2008) PTPv2.1 (IEEE 1588-2019)
PTPv1 (IEEE 1588-2002) Несовместимы Несовместимы
PTPv2 (IEEE 1588-2008) Несовместимы Совместимы
PTPv2.1 (IEEE 1588-2019) Несовместимы Совместимы

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

Но совместить устройства c PTPv1 и устройства с PTPv2 в одной сети все-таки можно. Для этого некоторые производители позволяют на портах граничных часов выбирать версию протокола. То есть, граничные часы могут синхронизироваться по PTPv2 и при этом синхронизировать другие подключенные к ним часы и по PTPv1, и по PTPv2.

Устройства PTP. Какие бывают и чем различаются

Стандартом IEEE 1588v2 описано несколько типов устройств. Все они приведены в таблице. Устройства взаимодействуют друг с другом через ЛВС, используя PTP. Устройства PTP называются часами. Все часы берут точное время у гроссмейстерских часов.

Есть 5 типов часов:

Grandmaster clock (Гроссмейстерские часы) Основной источник точного времени. Часто оснащаются интерфейсом для подключения GPS.
Ordinary Clock (Обычные часы) Устройство с одним портом, которое может быть мастером (ведущими часами) или слэйвом (ведомыми часами)
Ведущие часы (мастер) Являются источником точно времени, по которому синхронизируются другие часы
Ведомые часы (слэйв) Конечное устройство, которое синхронизируется от ведущих часов
Boundary Clock (Граничные часы) Устройство с несколькими портами, которое может быть мастером или слейвом. То есть эти часы могут синхронизироваться от вышестоящих ведущих часов и синхронизировать нижестоящие ведомые часы.
End-to-end Transparent Clock (Прозрачные часы, работающие в режиме End-to-End) Устройство с несколькими портами, которое не является ни ведущими часами, ни ведомыми. Оно передает данные PTP между двумя часами. При передачи данных прозрачные часы корректируют все PTP-сообщения. Корректировка происходит за счет добавления времени задержки на этом устройстве в поле коррекции в заголовке передаваемого сообщения.
Peer-to-Peer Transparent Clock (Прозрачные часы, работающие в режиме Peer-to-Peer) Устройство с несколькими портами, которое не является ни ведущими часами, ни ведомыми. Оно передает данные PTP между двумя часами. При передачи данных прозрачные часы корректируют все PTP-сообщения Sync и Follow_Up (про них подробнее рассказано ниже). Корректировка достигается за счет добавления к полю корректировки передаваемого пакета задержки на передающем устройстве и задержки на канале передачи данных.
Management Node (Управляющий узел) Устройство, которое конфигурирует и диагностирует другие часы

Ведущие и ведомые часы синхронизируются при помощи меток времени в PTP-сообщениях. Есть два типа сообщений в PTP-протоколе:

  • Event Messages — это синхронизированные сообщения, которые предполагают генерацию метки времени в момент отправки сообщения и в момент его приема.
  • General Messages — эти сообщения не требуют меток времени, но могут содержать метки времени для связанных сообщений.
Event Messages General Messages
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

Далее будут рассмотрены все типы сообщений более подробно.

Основные проблемы синхронизации

При передаче пакета синхронизации через локальную сеть он задерживается на коммутаторе и в канале передачи данных. Любой коммутатор будет давать задержку около 10 мкс, что недопустимо для PTPv2. Ведь нам на конечном устройстве необходимо получить точность 1 мкс. (Это если речь идет про энергетику. Другие приложения могут требовать и большей точности.)

В IEEE 1588v2 описаны несколько алгоритмов работы, которые позволяют фиксировать задержку времени и корректировать ее.

Алгоритм работы. При нормальной работе протокол работает в две фазы:

  • Фаза 1 — установка иерархии «Ведущие часы — Ведомые часы».
  • Фаза 2 — синхронизация часов при помощи механизма End-to-End или Peer-to-Peer.

Фаза 1 — Установка иерархии «мастер-слэйв»

Каждый порт обычных или граничных часов имеет определенное количество состояний (ведомые часы и ведущие часы). Стандарт описывает алгоритм перехода между этими состояниями. В программировании такой алгоритм называется конечным автоматом или машиной состояний (подробнее в Wiki).

Этот конечный автомат использует алгоритм Best Master Clock Algorithm (BMCA) для установки мастера при соединении двух часов. Данный алгоритм позволяет часам брать на себя обязательства гроссмейстерских часов, когда вышестоящие гроссмейстерские часы теряют сигнал GPS, отключаются от сети и т.д.

Переходы между состояниями в соответствии с BMCA кратко отображены на следующей схеме:

Информация о часах на другом конце «провода» присылается в специальном сообщении (Announce message). Когда эта информация получена, алгоритм машины состояний отрабатывает и выполняется сравнение, какие часы лучше. Порт на лучших часах становится ведущими часами.

Простая иерархия представлена схеме ниже. Пути 1, 2, 3, 4, 5 могут содержать прозрачные часы (Transparent clock), но они не участвуют в установлении иерархии «Ведущие часы — Ведомые часы».

Фаза 2 — Синхронизация обычных и граничных часов

Сразу после установки иерархии «Ведущие часы — Ведомые часы» начинается фаза синхронизации обычных и граничных часов. Для синхронизации ведущие часы отправляют ведомым часам сообщение, содержащее метку времени.

Ведущие часы могут быть:

  • одноступенчатые;
  • двухступенчатые.

Одноступенчатые часы для синхронизации посылают одно сообщение Sync. Двухступенчатые часы для синхронизации используют два сообщения — Sync и Follow_Up.

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

  • Механизм запроса-ответа задержки (Delay request-response mechanism).
  • Механизм измерения задержки соседнего узла (Peer delay measurement mechanism).

Для начала рассмотрим эти механизмы в самом простейшем случае — когда не применяются прозрачные часы. Механизм запроса-ответа задержки (Delay request-response mechanism).

Механизм предполагает два шага:

  1. Измерение задержки при передаче сообщения между ведущими часами и ведомыми. Выполняется при помощи механизма запроса-ответа задержки.
  2. Выполняется коррекция сдвига точного времени.

Измерение задержки

Когда ведомые часы знают время t1, t2, t3 и t4, то они могут рассчитать среднюю задержку при передаче сообщения синхронизации (tmpd). Она рассчитывается следующим образом:

  • При передаче сообщения Sync и Follow_Up вычисляется задержка времени от мастера к слэйву — t-ms.
  • При передаче сообщений Delay_Req и Delay_Resp вычисляется задержка времени от слэйва к мастеру — t-sm.

Если между этими двумя значениями возникает какая-то асимметрия, то появляется ошибка коррекции ухода точного времени. Ошибка обуславливается тем, что вычисленная задержка является средним от задержек t-ms и t-sm. Если задержки не равны друг другу, то мы будем корректировать время неточно.

Коррекция сдвига точного времени

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

Ведомые часы используют сообщение Sync и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:

Механизм измерения задержки соседнего узла (Peer delay measurement mechanism). Данный механизм также использует два шага для синхронизации:

  • Устройства измеряют задержку времени до всех соседей через все порты. Для этого они используют peer delay mechanism.
  • Корректировка сдвига точного времени.

Измерение задержки между устройствами, поддерживающих режим Peer-to-Peer

Задержка между портами, поддерживающими механизм peer-to-peer, измеряется при помощи следующих сообщений:

Когда порту 1 известно время t1, t2, t3 и t4, он может рассчитать среднюю задержку (tmld). Она рассчитывается по следующей формуле:

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

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

Сообщения Pdelay_Req, Pdelay_Resp и опциональное Pdelay_Resp_Follow_Up позволяет получить задержку от мастера к слэйву и от слэйва к мастеру (круговую).

Любая асимметрия между этими двумя значениями привнесет ошибку коррекции сдвига точного времени.

Корректировка сдвига точного времени

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

Преимущества корректировка механизма 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, что характерно для более старых энергообъектов.

Рис. 1. Иллюстрация разделения систем синхронизации времени и обмена данными в рамках системы автоматизации подстанции.

Протокол IRIGB

Наиболее распространённый протокол синхронизации времени, используемый на энергообъектах, – протокол 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).

Рис. 2. Форма модулированного и немодулированного сигнала IRIG-B.

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

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

1-PPS (один импульс в секунду)

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

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

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

Рис. 3. Графическое представление сигнала 1-PPS.

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

Задержка передачи сигналов синхронизации

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

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

Синхронизация времени по сети Ethernet

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

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

Рис. 4. Топология сети Ethernet, в которой могут применяться протоколы NTP и PTP. При использовании протокола PTP требуется применение специальных коммутаторов.

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

Протокол NTP

В течение последних лет протокол 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.

Рис. 5. Система, функционирующая по условиям протокола 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 для электроэнергетики (Power Profile)

Стандарт на протокол 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

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

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

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

Рис. 6. Графическое представление маршрута распространения сообщения типа Sync по сети.

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

Рис. 7. Обмен сообщениями типа Peer Delay производится только между соседними устройствами.

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

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

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

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

Рис. 8. Сообщения типа Follow Up содержат корректирующее значение, которое обновляется каждыми прозрачными часами на пути его распространения.

Использование профиля 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, но также удовлетворяет требованию по сохранению функций при единичном отказе (оборудования или линии связи).

Применение протокола PTP на энергообъектах нового строительства

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

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

Рис. 9. Однолинейная схема ПС 330/132 кВ c полуторной схемой РУ 330 кВ и одиночной секционированной системой шин РУ 132 кВ.

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

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

Рис. 10. Топология локальной сети Ethernet подстанции 330/132 кВ с двумя зданиями, в которых размещается оборудование РЗА, и одним зданием, в котором размещается АРМ диспетчера и коммуникационное оборудование для передачи данных на верхний уровень

Основным источником времени являются гроссмейстерские часы, оснащенные приемником спутникового сигнала. Рекомендуется, чтобы гроссмейстерские 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 (коричневый). Проиллюстрированный режим двухстадийной работы создает наибольший трафик – это наихудший случай.

Рис. 11. Трафик PTP, формируемый двухстадийными гроссмейстерскими часами.

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

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

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

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

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

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

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

Замена системы синхронизации времени: IRIGB на PTP

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

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

Рис. 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 в конечных устройствах.

Рис. 13. Схема подстанции после расширения (установки дополнительного силового трансформатора, расширения распределительного устройства 330 кВ и строительства нового ОПУ).

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

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

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

Рис. 14. Традиционная система синхронизации времени и коммуникационные связи между устройствами.

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

Рис. 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 отключен до тех пор, пока не произошел отказ основной линии связи. Данные связи также показаны пунктирными линиями.

Рис. 16. Локальная сеть Ethernet, реализованная с использованием протокола PRP.

Ожидается, что в ближайшем будущем станут доступны коммуникационные сервера АСУ ТП с нативной поддержкой 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 Network Time Foundation и размещение рабочей группы IETF NTP. Авторские права на материалы на этом веб-сайте принадлежат авторам.Пожалуйста, свяжитесь с веб-мастером и / или соавтором с любыми вопросами относительно авторских прав.

Новости NTP

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

Подтвержденные или предполагаемые ошибки, связанные с безопасностью, следует сообщать по электронной почте [email protected] Используйте наш ключ сотрудника службы безопасности, чтобы сообщать о проблемах. Пожалуйста, воздержитесь от обсуждения потенциальных проблем безопасности на публичных форумах, таких как группа новостей comp.protocols.time.ntp Usenet, наша система отслеживания ошибок, [email protected] или любой другой список рассылки.Пожалуйста, ознакомьтесь с нашим Уведомлением о безопасности для получения последней информации о проблемах, связанных с безопасностью, относящихся к эталонной реализации NTP. CodeAudit описывает некоторые процедуры и усилия, необходимые для аудита кодовой базы NTP и обеспечения ее безопасности.

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

NTP — это протокол, предназначенный для синхронизации часов компьютеров в сети с общей временной разверткой (обычно UTC). NTP версии 4 — это значительный пересмотр предыдущего стандарта NTP и текущая разрабатываемая версия.Это указано в следующих документах: NTP версии 3 представлял собой черновик Интернет-стандарта, формализованный в RFC 1305.

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

В коммерческой среде точные отметки времени необходимы для всего, от обслуживания и устранения неполадок оборудования и криминалистического анализа распределенных атак до разрешения споров между сторонами, оспаривающими коммерчески ценную временную транзакцию. В среде программирования временные метки обычно используются для определения того, какие биты кода необходимо перестроить как часть процесса проверки зависимостей, поскольку они относятся к другим битам кода и отметкам времени на них, и без хороших временных меток вся ваша разработка процесс может быть полностью остановлен.В правоохранительных органах они необходимы для корреляции распределенных коммуникационных событий, судебно-медицинской экспертизы и потенциального использования доказательств в уголовном судопроизводстве. По сути, вся отладка, безопасность, аудит и аутентификация основаны на корреляции событий (точное знание того, что произошло, в каком порядке и с какой стороны), и это зависит от хорошей синхронизации времени. Еще одно хорошее объяснение этой проблемы дает Томас Акин в главе 10 своей книги «Повышение безопасности маршрутизаторов Cisco»: Время по своей сути важно для работы маршрутизаторов и сетей.Он обеспечивает единственную систему координат между всеми устройствами в сети. Это делает синхронизацию времени чрезвычайно важной. Без синхронизации времени точное сопоставление информации между устройствами становится трудным, если не невозможным. Когда дело доходит до безопасности, если вы не можете успешно сравнить журналы между каждым из ваших маршрутизаторов и всеми вашими сетевыми серверами, вам будет очень сложно составить надежную картину инцидента. Наконец, даже если вы можете собрать все воедино, несинхронизированное время, особенно между файлами журналов, может дать злоумышленнику с хорошим поверенным достаточно места для маневра, чтобы избежать судебного преследования. Дополнительную информацию по этому вопросу можно найти в Калифорнийском университете в Беркли, Университет Вайоминга, в колонках Network Defense Рика Фэрроу для Network Magazine и в Руководстве для системных администраторов Linux в Linux Documentation Project.

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

Обратите внимание, мы не юристы, и ничто из того, что мы здесь говорим, не может быть истолковано как юридическая консультация. Тем не менее, мы считаем, что можем выявить потенциальные проблемы, которые могут вас заинтересовать, хотя вам нужно будет поговорить со своими юристами, чтобы получить их официальное юридическое заключение по этим вопросам.Как в США, так и за рубежом существуют юридические требования для хорошей синхронизации времени. В США юридические требования CALEA, Министерства юстиции, ФБР и FCC в настоящее время установлены на минимальную точность 200 мс (двести миллисекунд), а в 2006 году это было расширено, чтобы охватить связь, которая происходит через протоколы на основе IP, особенно включая сети, использующие технологию VOIP или VOIP-подобную технологию (где вас будут рассматривать как эквивалент телекоммуникационной компании), а также могут быть истолкованы как включающие чат, irc или любой другой протокол связи на основе IP.В Европе есть предложения по ужесточению этого требования до десяти миллисекунд (см. Agentschap Telecom, Формат даты и времени, ETSI / TC LI Rap # 16, Гронинген, 27-28 июня 2007 г., Док. ETSI / LI- rap16-td12), и частично это используется как обоснование того же уровня стандартов в США Министерством юстиции, ФБР и FCC в уведомлении FCC RM-11376. Кроме того, существуют Федеральные правила доказывания, которые регулируют представление доказательств в разбирательствах, как гражданских, так и уголовных, в федеральных судах США.Хотя они не применяются к искам в судах штатов, правила многих штатов основаны на этих положениях. Конечно, эти правила не могут быть полностью перенесены в другие юридические юрисдикции других стран, но они должны служить хорошим исходным ориентиром.

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

Обратите внимание, мы не юристы, и нижеследующее не может быть истолковано как юридическая консультация. Перед отправкой любого продукта, который может подпадать под экспортные ограничения США, вы и ваши юристы должны ознакомиться со всеми документами Бюро промышленности и безопасности США по Правилам экспортного контроля и самостоятельно определить, какие вопросы относятся к вам и какие руководящие принципы вы нужно придерживаться.При этом ни проект NTP, ни проект общественных служб NTP не подали заявку на получение идентификатора CCATS (Автоматизированная система отслеживания классификации товаров) или классификационного номера экспортного контроля для протокола, алгоритмов или исходного кода NTP. Это проект с открытым исходным кодом, доступный для всего мира, и поэтому мы считаем, что он не подлежит никакому экспортному контролю. Кроме того, мы не выполняем никакого внутреннего шифрования нашего кода, хотя мы используем библиотеки из проекта OpenSSL для генерации ключей и проверки ключей в процессе аутентификации сервера для одного или нескольких клиентов.Обратите внимание, что OpenSSL также является еще одним проектом с открытым исходным кодом и разработан полностью за пределами США специально для того, чтобы избежать каких-либо затруднений с экспортными ограничениями. Таким образом, он должен подпадать под стандартные положения о реэкспорте и как исключение TSU в соответствии с разделом 740.13 (e) EAR.

Проект НПТ

Проект NTP создает эталонную реализацию протокола NTP и документацию по реализации, в основном благодаря усилиям добровольцев. Более подробная информация об этом доступна на странице SoftwareDevelopment.Распространение программного обеспечения NTP защищено авторским правом, как описано на странице авторских прав NTP. Список эталонных часов, документация ntp, станции эталонов времени и частоты, а также данные передачи станций эталонов времени и частоты поддерживаются на странице «Информация о службах времени и частоты». Справочная информация о NTP, а также брифинги и библиография доступны на странице Network Time Synchronization Project.

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

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

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

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

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

Если вы хотите помочь проекту NTP и / или сообществу, которое он обслуживает, есть несколько способов сделать это. Вот несколько:

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

Чтобы связаться с разработчиком веб-поддержки NTP или любым из разработчиков NTP, перейдите на страницу контактов. Пожалуйста, направляйте комментарии и вопросы об этом веб-сайте по адресу [email protected]

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

Протокол сетевого времени (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 году, отличается высокой отказоустойчивостью и масштабируемостью.

Как работает NTP?

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

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

Особенности NTP

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

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

Иерархия серверов времени

Уровни слоя

Градусы отделения от источника UTC определены как страты . Эталонные часы, принимающие истинное время от специального передатчика или спутниковой навигационной системы, относятся к категории stratum-0 ; компьютер, который напрямую связан с эталонными часами, — это stratum-1 ; компьютер, который получает свое время от компьютера уровня 1, — это уровень 2, и так далее.Точность снижается с каждой дополнительной степенью разделения.

Что касается безопасности, NTP имеет известные уязвимости. Протокол может быть использован в атаках типа «отказ в обслуживании» по двум причинам: во-первых, он будет отвечать на пакет с поддельным IP-адресом источника; во-вторых, по крайней мере одна из его встроенных команд отправит длинный ответ на короткий запрос.

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

Точное время в сети важно по многим причинам; расхождения даже в долях секунды могут вызвать проблемы.Например, распределенные процедуры зависят от согласованного времени, чтобы гарантировать соблюдение правильной последовательности. Механизмы безопасности зависят от согласованного хронометража в сети. Обновления файловой системы, выполняемые на нескольких компьютерах, также зависят от синхронизированного времени часов.

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

RFC 958 — протокол сетевого времени (NTP)

[Документы] [txt | pdf] [Tracker] [IPR]

Устарело: 1059, 1119, 1305
Сетевая рабочая группа 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]

 

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу https://tools.ietf.org/tools/rfcmarkup/ Сервер NTP

(протокол сетевого времени) Общие вопросы и справка

Что такое NTP-сервер?

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

Зачем мне синхронизировать мою сеть?

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

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

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

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

Что важно при выборе сетевого сервера времени?

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

Клавиатуры
Важные особенности, которые следует учитывать:
Несколько портов NTP Наличие сервера времени, который поддерживает несколько портов NTP, подходит как для современных сетей, так и для тех, которые будут обновлены в будущем.Если ваша сеть будет расти или безопасность важна, вам нужно, чтобы ваш сервер времени шел в ногу с ней.
Обновление атомных часов Обновление до внутреннего атомного генератора рубидия, чтобы сервер времени оставался точным в случае потери или помехи сигнала GPS. Это позволяет серверу времени предоставлять чрезвычайно точное время, пока проблема, связанная с GPS, решена.
Резервные источники времени Выделенный сетевой сервер времени поддерживает синхронизацию сети с источником опорных часов.Избыточность обеспечивает уверенность в том, что ваша сеть имеет точное время.
Перекрестный контроль времени Нет альтернативы автоматической сверки системных часов с часами сторонних производителей. Если время выходит за допустимые пределы, NTP перейдет к следующему лучшему эталону. (Вы, конечно же, получаете уведомление через SNMP).
Пропускная способность и точность запросов NTP Хотя возможность синхронизации многих сотен тысяч клиентов полезна в очень больших сетях, настоящее испытание заключается в способности сервера времени обрабатывать случайную пиковую нагрузку запросов NTP.Ключевым моментом является производительность или способность обслуживать большой объем запросов NTP и поддерживать очень высокую точность и доступность.
Простота использования: клавиатуры, SNMP, интерфейс браузера обеспечивают быструю и легкую настройку.
SNMP обеспечивает спокойствие.
Интерфейс браузера делает удаленный доступ интуитивно понятным.
Оконная антенна / синхронизация с одним спутником В условиях городского ущелья, где видимость спутников может быть ограничена или когда доступ к крыше ограничен, автоматический режим синхронизации с одним спутником обеспечивает точное время с прерывистым спутниковым покрытием, а также может отслеживать спутники с помощью антенны, установленной на окне.

Что такое ACTS?

Расшифровывается как «Автоматизированная компьютерная служба времени». Это услуга, предоставляемая Национальным институтом стандартов и технологий (NIST) в Боулдере, штат Колорадо. С помощью этой службы NTP-сервер выполняет передачу времени по коммутируемой телефонной линии в UTC (NIST).
Служба времени дозвона также доступна в европейских странах, а также в Японии. Встроенный модем S300 / S350 совместим со всеми этими услугами.

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

Протокол сетевого времени (NTP) — это протокол UDP для IP-сетей.Он был разработан для синхронизации часов на клиентских машинах с часами на сетевых серверах времени. Но NTP — это всего лишь протокол. Реализация NTP требует отдельных клиентских и серверных приложений. Серверы времени Symmetricom — отличные примеры серверной реализации NTP. Клиентское приложение работает на таких рабочих станциях, как Windows или Linux. Используя пакеты NTP, клиент и сервер обмениваются данными отметок времени, в конечном итоге очень точно устанавливая часы на клиентском компьютере в соответствии с часами сервера времени.

Является ли NTP протоколом с открытым исходным кодом?
Да. Он был разработан в Университете Делавэра доктором Дэвидом Миллсом по контракту с DARPA. Версия 1 была распространена в 1985 году. Текущую версию можно найти здесь: http: /www.ntp.org/

Как работает NTP?
На первый взгляд, NTP — это программный демон, работающий в клиентском, серверном или обоих режимах.

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

Предоставляет ли NTP время компьютеру или серверу?
Технически нет. Цель NTP — выявить смещение часов клиента; не доставить время.Операционная система (ОС) доставляет время. Процессы в прикладной программе NTP вычисляют смещение для настройки часов клиента. Поскольку аппаратная реализация компьютерных часов и протокол для управления ими варьируются от компьютера к компьютеру; необходимо загрузить специальное программное обеспечение для управления часами компьютера. Если NTP входит в комплект операционной системы вашего компьютера, это уже было сделано. Если вы загружаете и устанавливаете NTP на ОС, не поддерживающую NTP; вам нужно будет внимательно прочитать инструкции по установке относительно этого момента.На самом деле это относится только к установке NTP UNIX. Различные сторонние клиенты NTP имеют встроенное управление часами.

Насколько точен NTP?
Это зависит от количества переходов между клиентом и сервером, а также от других факторов, вызывающих задержку в сети. В глобальных сетях, глобальных сетях обычно от 1 до 10 миллисекунд. В локальной сети, LAN, обычно от 0,5 до двух миллисекунд. Однако при работе с моделями SyncServer ® с GPS точность внутренних часов составляет менее 50 наносекунд, а точность отметки времени NTP на порте NTP составляет менее 14 микросекунд.

Каковы основные различия между клиентами SNTP и NTP?
SNTP — это простой протокол сетевого времени. Он основан на RFC 1361/2030: он получает свое время с указанных серверов времени компьютера, на котором он установлен. Этот протокол нельзя настроить для получения времени от альтернативного сервера времени, если основной сервер не работает. Это можно назвать короткой версией клиентского программного обеспечения NTP.

Сетевой протокол времени может быть настроен для получения и распределения времени в сети с помощью встроенных алгоритмов, которые вычисляют время с точностью до 0.Обычно от 5 до 3 миллисекунд. Алгоритмы могут быть настроены на получение времени из альтернативного источника в случае отказа исходного сервера времени или выхода из синхронизации.

Где взять демонов NTP?
Определите, есть ли в вашей операционной системе встроенный протокол NTP. Если это так, то это просто вопрос включения возможности NTP или ее использования.

Демон NTP для систем * nix можно найти по адресу http: /www.ntp.org.

Сколько клиентов я могу обслужить?
Серверы времени NTP от Symmetricom продемонстрировали способность обрабатывать многие сотни тысяч клиентов и при этом поддерживать точность отметок времени на уровне микросекунд.

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

Нужно ли мне запускать компьютеры * NIX, чтобы использовать NTP-сервер?
Вам не нужно запускать компьютеры NIX. Но вам понадобится клиентское программное обеспечение NTP на машинах, которые хотят синхронизироваться с сервером времени. Мы предлагаем программное обеспечение Domain Time II для синхронизации, мониторинга и управления клиентом времени.Многие операционные системы включают встроенный клиент NTP.

Я уже использую NTP на сервере общего назначения Linux. Зачем мне нужно ваше сетевое устройство?
Короче говоря, все сводится к точности, надежности, безопасности и простоте использования выделенного сетевого сервера времени. Вы не можете позволить себе оставить синхронизацию времени в руках общего сервера или часы вне вашего контроля в Интернете, если ваша сеть полагается на точные отметки времени. Существует риск того, что время будет недействительным и будет отказано в доступе к времени либо намеренно оператором удаленного сервера, либо нарушением работы сети.

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

.

SyncServer S600

Вопросы по синхронизации сети

Значение сетевого протокола времени (NTP) для кибербезопасности

Network Time Protocol (NTP) — это сетевой протокол, используемый для синхронизации часов сетевых вычислительных устройств.Хотя это один из старейших сетевых протоколов, созданный еще в 1985 году, он остается краеугольным камнем современной вычислительной синхронизации и имеет решающее значение для поддержания надлежащей работы и безопасности вычислительных устройств.

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

Решение

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

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

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

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

Несмотря на то, что протоколу NTP 34 года, нельзя упускать из виду фундамент, обеспечивающий фундаментальную гигиену кибербезопасности.

Как вы можете гарантировать, что ваша организация не поддастся опасностям неправильного выбора времени?

Убедитесь, что ваши ресурсы используют сервер синхронизации часов, и что он безопасен и точен.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *