Оглавление
- 1. Введение
- 2. Режимы функционирования
- 3. Разновидности функционирования протокола
- 3.1. Поиск функционирующего сервера
- 4. Определения
- 5. Модель реализации
- 6. Типы данных (логическая харктеристика)
- 7. Структуры данных
- 7.1. Условные обозначения структур данных
- 7.2. Общие параметры
- 7.3. Переменные в заголовке NTP-сообщения
- 7.4. NTP-сообщение «Kiss-o'-Death»
- 7.5. Формат дополнительного поля расширения
- 8. Процедурная характеристика протокола
- 9. Функциональные процедуры удлённого сервера
- 9.1. Переменные, обрабатываемые удалённым сервером
- 9.2. Процедуры, проводимые удалённым сервером
- 10. Процедура (алгоритм) фильтрации времени
- 11. Системный процесс (процедуры)
- 11.1. Переменные системного процесса (процедур)
- 11.2. Процедуры системного процесса
- 11.2.1. Процедура (алгоритм) селекции
- 11.2.2. Процедура (алгоритм) кластеризации
- 11.2.3. Процедура (алгоритм) суммирования
- 11.3. Процедура (алгоритм) корректировки (настройки) времени (часов)
- 12. Процедура корректировки (настройки) времени (часов)
- 13. Процедура опроса
- 13.1. Переменные процедуры опроса
- 13.2. Процессы (операции) процедуры опроса
- 14. Простой протокол сетевого времени (SNTP)
- 15. Проблемы обеспечения безопасности
- 16. Вопросы, решаемые IANA
- 17. Благодарности
- 18. Ссылки
- 18.1. Нормативные документы
- 18.2. Дополнительная литература
1. Введение
Данный стандарт вводит четвёртую версию протокола сетевого времени (Network Time Protocol Version 4 — NTPv4), который широко используется для синхронизации системных часов среди множества распределённых серверов времени и клиентов. Он определяет базовую архитектуру, логическую и процедурную характеристики (протокол, как конечный автомат), структуры данных и алгоритмы. NTPv4-протокол вводит новые функциональные свойства в третью версию NTP-протокола (RFC-1305) и расширяется сам за счёт поглощения функциональных свойств SNTPv4-протокола (RFC-4330). Данный стандарт заменяет предшествующие стандарты RFC-1305 и RFC-4330. Так как в некоторых полях NTPv4-сообщений были сделаны всего лишь незначительные изменения, последние не должны повлиять на качество взаимодействия NTPv4-протокол с предшествующими версиями NTP- и SNTP-протоколов.
Рис.1. Иерархия, структура и топология системы сетевого времени на основе NTP-протокола
Модель NTP-подсети синхронизации представляет собой множество первичных эталонных источников, синхронизируемых по радио- и проводным каналам от национальных стандартов, например, через магистральные шлюзы, соединено с общедоступными ресурсами и функционирует, как первичные серверы времени (рис.1).
Главной целью NTP-протокола является доставка данных для временной синхронизации от одних серверов времени к другим серверам времени через Internet-сеть и частные корпоративные сети, а также сверка времени между серверами. Точно настроенные алгоритмы (процедуры) снижают вероятность ошибок в следствие сбоев программно-аппаратных комплексов или нештатных ситуаций при передаче протокольных данных. Программные модули серверов и клиентов настраиваются так, чтобы поток значений параметров был направлен в сторону клиентов от первичных серверов времени, расположенных в корневых узлах подсети, через вторичные серверы времени. NTPv4-протокол устраняет недостатки предыдущей версии протокола, корректирует имеющиеся в последней ошибки и добавляет новые свойства. Соответственно, определение расширенной NTP-метки времени позволяет использовать удвоенные числа с плавающей запятой во всех без исключения прикладных реализациях протокола. А это в свою очередь, повышает точность времени, которая составляет менее одной наносекунды, а точность частоты — менее одной наносекунды в секунду. Новый стандарт имеет несколько дополнительных преимуществ, среди которых новый алгоритм обслуживания часов, который более чувствителен флуктуациям частоты в аппаратных системных часах. Типовые первичные серверы времени построены на современных вычислительных средствах, обеспечивающих точность в пределах нескольких десятков микросекунд. Типовые вторичные серверы времени и клиенты в составе высокоскоростных ЛВС обеспечивают точность в пределах нескольких сотен микросекунд при интервалах опроса до 1024 секунд (это была максимальная точность для NTPv3-протокола). А при интервалах опроса до 36 часов NTPv4-серверы и клиенты обеспечивают точность в пределах нескольких десятков миллисекунд.
2. Режимы функционирования
Программный NTP-модуль функционирует как первичный сервер, вторичный сервер или клиентский модуль. Первичный сервер синхронизируется от эталонных часов, которые напрямую синхронизируются от глобальных UTC-систем времени (например, GPS, Galileo и т.п.). Клиентский NTP-модуль синхронизируется от одного или более вышележащих серверов, но не синхронизируется от зависимых клиентов. Вторичные серверы связаны с одним или несколькими вышележащими серверами и одним или несколькими нижележащими серверами или клиентами. Все серверы и клиенты, которые полностью соответствуют NTPv4-протоколу, должны применять весь набор алгоритмов, представленный в этом стандарте. С целью поддержания стабильности в больших NTP-подсетях синхронизации, целесообразно, чтобы вторичные серверы полностью соответствовали NTPv4-протоколу. Допускается использование альтернативных алгоритмов, однако, их выходные параметры должны быть идентичны тем, которые имеют алгоритмы, представленные в данном стандарте.
3. Разновидности функционирования протокола
Существует три разновидности функционирования NTPv4-протокола (рис.2):
Симметричное функционирование
В этом варианте удалённый сервер времени функционирует одновременно, и собственно как сервер, и как клиент, используя для этого, либо симметричное активное виртуальное соединение, либо симметричное пассивное виртуальное соединение. При постоянном симметричном активном соединении (режим №1) передаются соответствующие NTP-сообщения на удалённый сервер, также функционирующий в режиме постоянного симметричного соединения. Как альтернатива, после получения NTP-сообщения от сервера, функционирующего в режиме постоянного симметричного соединения, по другому не согласованному виртуальному соединению может быть сформировано временное пассивное виртуальное соединение. По такому соединению передаются соответствующие NTP-сообщения (режим №2), а само виртуальное соединение поддерживается до окончания тайм-аута или возникновения ошибки или сбоя. Удалённые серверы времени как бы «принуждают» друг друга к обоюдной синхронизации. В данном стандарте удалённые серверы функционируют как клиенты, а сами клиенты используют их как источники синхронизации.
Функционирование в режимах «клиент/сервер»
В данном режиме постоянный клиент передает пользовательские NTP-сообщения (режим №3) на сервер времени, который отвечает на них путём передачи своих NTP-сообщений (режим №4). Серверы времени синхронизируют одного или нескольких клиентов, но сами от них не синхронизируются. Сервер может быть также «ретранслятором» эталонного времени, если он получает сигналы времени непосредственно от источника эталонного времени/частоты. В данном варианте клиенты синхронизируются от серверов времени.
Широковещательное функционирование
В данном режиме широковещательный сервер времени, используя постоянное виртуальное соединение периодически передает свои широковещательные NTP-сообщения (режим №5), которые могут принимать несколько клиентов. После приёма широковещательного NTP-сообщения сервера времени по несогласованному виртуальному соединению клиент формируется временное широковещательное виртуальное соединение (режим №6), которое функционирует до окончания тайм-аута или возникновения ошибки или сбоя. Такой режим необходим для начального «импульса», когда клиент, функционирующий в режиме «клиент», обменивается несколькими NTP-сообщениями с сервером времени для того, чтобы точно измерить задержку распространения сигнала, или чтобы активизировать протокол безопасности «Autokey»[?] , после выполнения которого клиент возвращается в широковещательный режим клиента. Широковещательный сервер синхронизирует клиентов и другие серверы времени.
| Режимы функционирования | Кодирование режима | Режим обработки пакетов |
|---|---|---|
| Симметричный активный | 1 | 1 или 2 |
| Симметричный пассивный | 2 | 1 |
| Режим клиента | 3 | 4 |
| Режим сервера | 4 | 3 |
| Широковещательный режим сервера | 5 | 5 |
| Широковещательный режим клиента | 6 | - |
| Рис.2. Режимы функционирования NTPv4-протокола | ||
Необходимо отметить, что постоянные виртуальные соединения после их установления в дальнейшем никогда не прерываются. Временные виртуальные соединения формируются после получения NTP-сообщения и с последующем прерываются, либо по истечении тайм-аута, либо при возникновении ошибки или сбоя.
В телефонной индустрии точность каждого сервера определяется номером «слоем» (числом), при этом самый верхний уровень (первичные серверы) обозначается единицей, а каждый последующий (вниз) уровень (вторичные серверы) в иерархии обозначается числом, которое на единицу больше, по сравнению с предшествующим уровнем. Так как номер «слоя» увеличивается, начиная с единицы, достигнутая при однократном запросе точность времени будет ухудшаться в зависимости от соответствующего маршрута обмена данными и стабильности системных часов. Усреднённые ошибки измерений, вызванные различными расстояниями синхронизации, возрастают пропорционально номеру «слоя» и измеренной задержке петлевого маршрута (roundtrip delay).
На практике, топология подсети синхронизации должна быть такой, чтобы исключить петлевые маршруты и минимизировать расстояния синхронизации. Используемый в NTP-протоколе алгоритм селекции основан одном из вариантов алгоритма распределенной маршрутизации Беллмана-Форда (BellmanFord), предназначенного для расчета связывающих деревьев с минимальными весовыми коэффициентами, которые своими «корнями» замыкаются на первичные серверы. Результатом такого подхода является то, что подсеть перенастраивается автоматически в иерархическую структуру (с ведущими и ведомыми серверами) с целью обеспечения максимально возможных точности и надежности времени, даже когда один или несколько первичных или вторичных серверов или сетевых маршрутов между ними не функционируют по причине сбоя.
3.1. Поиск функционирующего сервера
Существуют два специальных типа виртуальных соединений: многоадресное (manycast) клиента и многоадресное сервера, — которые реализуют процедуру поиска функционирующего сервера. Также существуют два типа многоадресных виртуальных соединения клиента: постоянное и временное. Постоянное многоадресное соединение клиента предназначено для передачи клиентских NTP-сообщений (режим №3) по специализированному широковещательному или групповому IPv4/v6-адресу. Специализированные многоадресные серверы в пределах временного интервала, указанного в поле «time-to-live» (TTL) заголовка IP-пакета, контролируют трафик на предмет обнаружения IP-пакетов с определенным широковещательным или групповым IP-адресом. Если сервер приемлем для синхронизации, то тогда он передаёт своё ответное NTP-сообщение (режим №4), используя для этого IP-пакет, в котором указывает уникальный адрес клиента. После получения этого NTP-сообщения клиент формирует временное виртуальное соединение (режим №3). Временное виртуальное соединение клиента поддерживается до окончания тайм-аута или возникновения ошибки или сбоя.
Клиент, функционирующий в многоадресном режиме, продолжает передавать NTP-сообщения с целью установления минимального числа виртуальных соединений. Клиент начинает поиск со значения TTL, равного единице, и в последующем увеличивает это значение на единицу до тех пор, пока не будет установлено минимальное число виртуальных соединений или пока TTL достигнет своего максимального значения.
Если TTL достигает своего максимального значения, но при этом сформировано не достаточное количество виртуальных соединений, то тогда клиент прекращает передачу на период тайм-аута и разрывает все установленные соединения, а затем повторяет поиск. Если сформировано минимально число виртуальных соединений, то тогда клиент начинает передачу по одному NTP-сообщению через интервал тайм-аута с целью поддержания этих соединений. Поле допускает следующие предельные значения — минимально равно единице, а максимальное — 255. Эти предельные значения могут быть изменены, если это необходимо для конкретных прикладных систем.
Временные виртуальные соединения конкурируют между собой. Как только сформированы новые соединения, клиентский NTP-модуль запускает алгоритмы оптимизации (фильтрации, селекции, кластеризации и суммирования) с целью выбора наилучших претендентов для синхронизации, а оставшиеся соединения прерываются по окончании тайм-аута. Таким образом, группа серверов времени включает только наилучших кандидатов, которые отправили наиболее приемлемые ответные NTP-сообщения для обслуживания системного времени.
4. Определения
Шкала (масштаб) времени (timescale) представляет собой систему отсчёта эталонного источника, в которой время выражается с помощью монотонно возрастающего значения бинарного счётчика с бесконечным числом битов. Он считает секунды и доли секунды, когда используется десятичная дробь. Шкала Всеобщего скоординированного времени (Coordinated Universal Time — UTC) определена Рекомендацией Международного союза электросвязи ITU-R TF.460[?] . Под протекторатом Метрической конвенции 1865 года (Metre Convention of 1865), в 1975 году Международное бюро мер и весов (International Bureau of Weights and Measures — IBWM[?] ) строго рекомендовало использовать UTC-время в качестве основы гражданского времени.
Шкала UTC-времени представляет собой усреднённое значение солнечного времени, распространяемое лабораториями национальных стандартов времени/частоты. Системное время представляет собой показание системных часов, обслуживаемых аппаратно-программным комплексом и операционной системой (ОС). Назначение NTP-алгоритмов состоит в минимизации различий по времени и по частоте между UTC-временем и системным временем. Когда эти различия снижаются до номинальных допустимых значений, то тогда говорят, что системное время синхронно относительно UTC-времени.
Дата события представляет собой значение UTC-времени, когда это событие имело место. Даты являются кратковременными величинами, обозначаемыми символом Т
(в верхнем регистре). Текущее время является иной шкалой времени, которая совпадает с функцией синхронизации программного NTP-модуля.
Метка времени T(t)
представляет собой, либо UTC-дату, либо сдвиг текущего времени t
относительно UTC-времени. Сущность метки времени должна вытекать из содержания NTP-сообщения. Пусть T(t)
— сдвиг времени, R(t)
— сдвиг частоты, D(t)
— скорость ухода частоты (первая производная R(t)
относительно t
). Тогда, если T(t0
)
— сдвиг UTC-времени, определённый в момент времени t = t0
, сдвиг UTC-времени в момент времени t
:
T(t) = T(t0 ) + R(t0 )(t-t0 ) + ½ × D(t0 )(t-t0 )2 + ε
где ε
— стохастическая ошибка. Несмотря на то, что параметр D(t)
очень важен при описании прецизионных генераторов частоты, им, в принципе, можно пренебречь при описании компьютерных генераторов частоты. В данном стандарте все значения времени представляются в секундах, а значения частоты — в секундах за одну секунду (сек/сек). Иногда для описания сдвигов частоты используются промили — число миллионный долей (parts-per-million — PPM), одна промиля равна 10-6
сек/сек.
В прикладных компьютерных системах синхронизации очень важно оценить эффективность функции (процедуры) обеспечения синхронизации. Модель эффективности NTP-протокола включает четыре статистических параметра, которые обновляются при каждом обращении клиента к серверу времени для проведения измерительных процедур. Сдвиг
θ
представляет собой максимально правдоподобный сдвиг времени серверных часов относительно системного времени. Задержка
δ
представляет собой задержку по времени при передачи пакета по замкнутому (петлевому) маршруту между клиентом и сервером времени. Дисперсия
ε
представляет собой максимальную естественную ошибку, возникающую при измерениях времени/частоты. Дисперсия увеличивается до значения, которое равно максимальному допустимому отклонению частоты (φ
) корректируемых системных часов, обычно 15 РРМ. Джиттер
ψ
определяется как среднеквадратическое значение сдвига (отклонение времени/частоты), и представляет собой номинальную ошибку при оценивании сдвига.
Несмотря на то, что все эти четыре параметра представляют собой раздельно измеренные значения системного времени относительно каждого сервера времени, NTP-протокол включает ряд процедур для суммирования этих параметров нескольких серверов с целью более точной коррекции и калибровки системного времени. Системный сдвиг
Θ
представляет собой максимально правдоподобную оценку сдвига всей совокупности серверов времени. Системный джиттер Ψ
представляет собой номинальную ошибку при оценивании системного сдвига. Параметры δ
и ε
накапливаются на каждом уровне (номер слоя
), начиная от эталонных часов, что приводит к образованию корневой задержки Δ
и корневой дисперсии Ε
, также являющимися статистическими параметрами. Расстояние синхронизации Λ
равно: Ε + Λ/2
, — и представляет собой максимальную ошибку, которая является следствием всех возможных причин её возникновения. Эти параметры присущи всем прикладным системам, которые зависят от оценивания эффективности функции (процедуры) обеспечения синхронизации.
5. Модель реализации
На рис.3 представлена структура типовой многоканальной модели прикладного программного модуля NTPv4-протокола. Эта модель включает два процесса, присущие каждому серверу времени:
Процесс удалённого сервера времени, обеспечивающий приём NTP-сообщений от другого сервера времени или источника эталонного времени.
Процесс опроса удалённых серверов времени, обеспечивающий передачу NTP-сообщений другому удалённому серверу времени или источнику эталонного времени.
Эти процессы организуют передачу, приём и обработку NTP-сообщений, представляющих собой единую структуру данных, включающих статистические параметры и другие переменные и константы, и для этого формируют виртуальные соединения. Клиентский программный NTP-модуль передаёт NTP-сообщения одному или нескольким серверам времени, а затем обрабатывает переданные ими ответные NTP-сообщения. Серверный программный NTP-модуль меняет местами IP-адреса и номера UDP-портов отправителя/получателя, заполняет определённые поля в NTP-сообщении и сразу после этого отправляет его источнику запроса, если используется режим функционирования «клиент/сервер», в противном случае, если используется симметричный режим функционирования, NTP-сообщение передается через некоторое время. После каждого приёма NTP-сообщения вычисляется сдвиг θ
между временем удалённого сервера и системными часами, используя для этого соответствующие значения статистических параметров δ
, ε
и ψ
.
..........................................................................................
. Удалённые . Процедуры . Системный . Процесс .
. серверы . опроса удалённых . процесс . настройки .
. . серверов . . времени .
.+---------+. +------------------+. +---------------+ . .
.| Сервер |->| Опрос удаленного |. | | . .
.| времени | | сервера времени |->| | . .
.| 1 |<-| 1 |. | | . .
.+---------+. +------------------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+---------+. +------------------+. | | +--------------+. .
.| Сервер |->| Опрос удаленного |. | Алгоритмы |->| |. +--------+ .
.| времени | | сервера времени |->| селекции | | Алгоритм |--->| Фильтр | .
.| 2 |<-| 2 |. | и | | суммирования |. | ФАПЧ | .
.+---------+. +------------------+. | кластеризации |->| |. +--------+ .
. . ^ . | | +--------------+. | .
. . | . | | . | .
.+---------+. +------------------+. | | . | .
.| Сервер |->| Опрос удаленного |. | | . | .
.| времени | | сервера времени |->| | . | .
.| 3 |<-| 3 |. | | . | .
.+---------+. +------------------+. +---------------+ . | .
........................^.......................................................|.........
| . V .
| . +------------+ .
| . | Генератор | .
+------------------------------------------------| переменной | .
. | частоты | .
. +------------+ .
. Процесс .
. корректировки .
. часов .
...................
Рис.3. Модель прикладного программного модуля NTPv4-протокола
Системный процесс[?] включает процедуры селекции, кластеризации и суммирования на основе соответствующих алгоритмов оптимизации, и осуществляет поиск среди возможных серверов времени наиболее «лучших» кандидатов, с точки зрения их точности и надежности, для последующей синхронизации системных часов. Алгоритм селекции основан на византийских принципах обнаружения неисправностей или отказов и решает задачу по нейтрализации самых некорректных кандидатов, именуемых «ложными часами», и предотвращения их включения в перечень (группу) «надёжных часов». Надёжные часы представляют собой такие часы, которые обеспечивают соответствующую точность синхронизации относительно известного доверенного стандартного источника времени/частоты (синхронизируются от него), в то время как ложные часы представляют собой часы, которые показывают ложное или неточное время. Алгоритм кластеризации основан на статистических принципах и обеспечивает поиск группы часов, включающей наиболее точные надежные часы. Алгоритм суммирования (объединения) решает задачу вычисления финального значения сдвига времени путём статистического усреднения значений наиболее точных надёжных часов, прошедших алгоритм кластеризации.
Процедура корректировки часов представляет собой системный процесс, который управляет временем и частотой системных часов, а в модели реализации он представляет собой генератор переменной частоты (ГПЧ). Метки времени, формируемые ГПЧ, «замыкают» контур ФАПЧ, который управляет временем системных часов. Процесс, обеспечивающий подстройку часов, представляет собой процедуру корректировки времени, которая проводится раз в секунду с целью вставки вычисленного сдвига времени и поддержания постоянной частоты. Среднеквадратическое отклонение (сдвиг) времени представляет собой номинальную ошибку при оценивании сдвига или джиттер системных часов . Среднеквадратическое отклонение (сдвиг) частоты представляет собой стабильность частоты генератора или отклонение частоты .
Клиентский программный NTP-модуль передаёт NTP-сообщения каждому серверу времени с интервалом опроса, равным 2τ
секунд. В NTPv4-стандарте τ
имеет диапазон значений от 4 (16 секунд) до 17 (36 часов). Значение τ
определяется с помощью алгоритма настройки часов целью его совпадения с временной константой контура ФАПЧ Тс
= 2τ
. В режиме «клиент/сервер» сервер времени отвечает незамедлительно. Однако, в симметричном режиме каждый из двух удаленных серверов времени регулируют значение τ
в зависимости от текущего системного сдвига и системного джиттера, и поэтому они могут не согласиться с применением одного и того же значения. Очень важно, чтобы динамическое поведение алгоритма настройки времени было под «чутким» контролем с целью поддержания стабильности в крупных NTP-подсетях. Это требует, чтобы удалённые серверы должны согласовывать единое значение τ
, равное минимальному показателю степени среди двух серверов времени. NTPv4-протокол включает специальные средства для соответствующего согласования этого значения.
Модель реализации NTPv4-протокола включает специализированные средства для установки и корректировки системных часов. Полагается, ОС реализует две функции:
Прямая установка времени (например, ОС-Unix системный процесс
settimeofday).Корректировка времени в пределах небольшого диапазона (с помощью минимальных приращений), путём ускорения или замедления течения времени, с помощью вычисленного корректирующего значения (например, ОС-Unix системный процесс
adjtime).
Системный процесс adjtime
используется при корректировке времени, если корректирующее значение не превосходит предельное значение, а системный процесс settimeofday
— если превосходит предельное значение.
6. Типы данных (логическая харктеристика)
Все значения NTP-времени представляются в бинарном формате (twos-complement format), в котором биты нумеруются, начиная с нуля, слева на право (причём крайний левый бит — бит высшего порядка или старший). В настоящее время существуют три формата NTP-времени:
32-битовый укороченный формат (рис.4,1)
Этот формат используется в полях заголовка NTP-сообщения, содержащих значения задержки и дисперсии, когда использование значений с высокой точностью или в более широком диапазоне не приемлемо. Он включает 16-битовое поле целых секунд и 16-битовое поле долей секунды.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Секунды | Доли секунды | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.4,1. 32-битовый укороченный формат NTP-времени
64-битовый формат метки времени (рис.4,2)
Этот формат используется в заголовках NTP-сообщений или в других полях с ограниченной длиной. Он включает 32-битовое поле целых секунд (136 лет) и 32-битовое поле долей секунды (точность 232 пикосекунды).
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Секунды | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Доли секунды | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.4,2. 64-битовый формат метки времени
128-битовый формат даты (рис.4,3)
Этот формат используется только тогда, когда существует возможность хранения с достаточным объёмом памяти. Он включает 64-битовое поле целых секунд (584 млрд. лет) и 64-битовое поле долей секунды (0,05 аттосекунды или 0,5е-18 ). С целью согласования отображений между форматами поле целых секунд разделено на два субполя: 32-битовое поле номера эпохи и 32-битовое поле сдвига эпохи. Эпохи не могут напрямую формироваться 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Номер эпохи | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Сдвиг относительно точки отсчёта эпохи | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Доли секунды | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.4,3. 128-битовый формат даты
В форматах даты и метки времени точкой отсчёта первичной эпохи, или основной датой нулевой эры (№0), является 0000 часов 1 января 1900 года по UTC-шкале времени, когда все биты нулевые. Необходимо заметить, что строго говоря, UTC-времени не существовало до 1 января 1972 года, но существует договорённость о том, что оно существовало все вечность, и даже в случае, когда вся информация о применении вставочных секунд могла быть потеряна. Все даты определяются относительно первичной эпохи. Если значение даты больше чем нулевой, то она представляется временем после точки отсчёта первичной эпохи, если же — меньше, то она представляется временем до точки отсчёта первичной эпохи.
Замечание. Поле «Сдвиг эпохи» в формате даты и поле «Секунды» в формате метки времени интерпретируются одинаково.
Метки времени представляют собой беззнаковые значения времени, а выполнение операций над ними приводит к результату, который относится к той же самой или смежной эпохе. Нулевая эра включает даты, начиная с точки отсчёта первичной эпохи до определённого момента времени в 2036 году, когда поле метки времени полностью заполниться единицами и в следующий момент времени обнулиться, и после этого начнётся первая эра (№1). В обоих форматах нулевое значение представляет собой особый случай, при котором неизвестно время или отсутствует возможность синхронизировать время. На рис.5 представлено несколько исторических NTP-дат и их значения в соответствие с Модифицированным Юлианским днём (Modified Julian Date — MJD), NTP-эпохой и NTP-меткой времени.
| Дата | MJD | NTP-эпоха (эра) | NTP-метка времени (сдвиг эпохи) | Сдвиг |
|---|---|---|---|---|
| 1 января -4712 года | -2,400,001 | -49 | 1,795,583,104 | 1-ый день Юлианского календаря |
| 1 января -1 года | -679,306 | -14 | 139,775,744 | 2 век до нашей эры |
| 1 января 0 года | -678,491 | -14 | 171,311,744 | 1 век до нашей эры |
| 1 января 1 года | -678,575 | -14 | 202,939,144 | 1 век нашей эры |
| 4 октября 1582 года | -100,851 | -3 | 2,873,647,488 | Последний день Юлианского календаря |
| 15 октября 1582 года | -100,840 | -3 | 2,874,597,888 | 1-ый день Григорианского календаря |
| 31 декабря 1899 года | 15019 | -1 | 4,294,880,896 | Последний день NTP-эпохи -1 (эра № -1) |
| 1 января 1900 года | 15020 | 0 | 0 | Первый день NTP-эпохи 0 (эра № 0) |
| 1 января 1970 года | 40,587 | 0 | 2,208,988,800 | Первый день UNIX-эпохи |
| 1 января 1972 года | 41,317 | 0 | 2,272,060,800 | Первый день UTC-эпохи |
| 31 декабря 1999 года | 51,543 | 0 | 3,155,587,200 | Последний день 20-го века |
| 8 февраля 2036 года | 64,731 | 1 | 63,104 | Первый день NTP-эпохи 1 (эра № 1) |
| Рис.5. Наиболее интересные исторические NTP-даты | ||||
Пусть p
будет число старших битов, отведенных для дробной части секунды. Тогда точность часов определяется выражением 2-p
в секундах. С целью минимизации отклонения и содействия в формировании максимально непредсказуемых для нарушителя значений меток времени младшие биты должны быть установлены в форме реальной случайной последовательности битов. Точность часов представляет собой текущее время для считывания системного времени, в секундах.
Замечание. Точность, определённая таким образом в этом стандарте, может быть больше или меньше, чем разрешение. Параметр ρ
, используемый в данном стандарте для обозначения точности, всегда больше двух.
При обработке значений дат и меток времени допускается только одна арифметическая операция — вычитание по модулю два, в результате которого получается 127- или 63- битовое знаковое значение. Чрезвычайно необходимо, чтобы разности первого порядка между двумя датами сохраняли полную 128-битовую точность, а разности первого порядка между двумя метками времени сохраняли полную 64-битовую точность. Однако, разности обычно представляют собой весьма малые значения, как правило, сравнимые с коротким промежутком времени в несколько секунд, и поэтому они могут быть преобразованы в удвоенный формат с плавающей запятой (точкой) для последующей обработки, причём без снижения точности.
Очень важно, чтобы двоичные арифметические действия не отличались между собой при обработке знаковых и беззнаковых величин (несмотря на то, что их можно сравнивать по знаку в записи), в противном случае необходимо ввести указания по условному обозначению. Таким образом, даже на наличие различий между знаковыми датами и беззнаковыми метками времени, они обрабатываются одинаково. Существует опасность, связанная с вычислением 64-битовых меток времени перекрывающих границы эпох, например, в 2036 году, которая может привести к обнулению всех битов метки времени. Фактически, если клиент синхронизировался от сервера времени за 68 лет до начала действия протокола, то тогда всё равно будут иметь место корректные значения, даже не взирая на то, что клиент и сервер функционируют в граничащих эпохах.
Некоторые значения времени представлены в экспоненциальном формате, это относится к точности значений времени, временным константам и интервалам опроса. Для этого используется 8-битовый знаковый целочисленный формат, в котором секунды выражаются как двоичный логарифм (log2 ). Для обработки значений в этом формате допускается только две арифметических операции: увеличение или уменьшение. Например, если интервал опроса составляет 1024 секунды, то в экспоненциальной форме этот интервал будет равен 10.
Для преобразования системного времени в любой NTP-формат даты и метки времени необходимо, чтобы знать число секунд s
от точки отсчёта первичной эпохи до значения системного времени. Для заданного s
определяем:
era = s / 232 и timestamp = s - era × 232
которые имеют место и при положительных и отрицательных значениях даты. Для заданных значений эпохи (era
) и метки времени (timestamp
) определяем:
s = era × 232 + timestamp
Преобразование NTP-времени и системное время и наоборот может быть с незначительными ошибками, но это не является проблемой данного стандарта.
Замечание. Число дней в нулевой эре (№0) на один больше, чем число дней в большинстве других эпох, и это не произойдет до тех пор, пока не наступит 2400 год эры №3.
7. Структуры данных
Переменные состояния разделены по классам в соответствии с их функциональным предназначением:
Пакетные переменные представляют собой величины, размещаемые в заголовках NTP-сообщений, которые, в свою очередь, содержаться в передаваемых и принимаемых IP-пакетах.
Переменные удаленного сервера и процедуры опроса представляют собой величины, которыми обменивается каждый сервер по отдельному виртуальному соединению.
Системные переменные представляют собой величины, которые описывают состояние сервера времени, то есть как оно понимается зависимыми от него клиентами.
Переменные настройки часов представляют собой величины, которые используются во внутренних процессах обработки параметров при реализации алгоритма настройки часов.
Дополнительные классы параметров и переменных .
| Обозначение | Описание |
|---|---|
| r. | Переменная в заголовке принятого NTP-сообщения |
| x. | Переменная в заголовке переданного NTP-сообщения |
| p. | Переменная удалённого сервера/опроса |
| s. | Системная переменная |
| c. | Переменная настройки часов |
| Рис.6. Условные обозначения префиксов | |
7.1. Условные обозначения структур данных
С целью установления различия между переменными с одним и тем же именем, но используемых в различных процедурах, вводятся их условные обозначения, представленные на рис.6. Переменная в принятом NTP-сообщении v
является составным элементом пакетной структуры r
и имеет полное наименование r.v
. аналогично обозначает переменная в переданном NTP-сообщении — x.v
, переменная удалённого сервера — p.v
, системная переменная — s.v
, и переменная настройки часов — с.v
. Для каждого виртуального соединения устанавливаются переменные удалённого сервера. Системные переменные и переменные часов устанавливаются только один раз.
7.2. Общие параметры
В данном стандарте помимо классов переменных представлены несколько общих параметров, часть которых представлена на рис.7.
| Наименование | Значение параметра | Описание |
|---|---|---|
| PORT | 123 | Номер транспортного порта NTP-протокола |
| VERSION | 4 | Номер версии NTP-протокола |
| TOLERANCE | 15e-6 | Допустимое отклонение частоты φ
(сек/сек) |
| MINPOLL | 4 | Минимальное экспоненциальное значение интервала опроса (16 сек) |
| MAXPOLL | 17 | Максимальная экспоненциальное значение интервала опроса (36 часов) |
| MAXDISP | 16 | Максимальная дисперсия (16 сек) |
| MINDISP | 0,005 | Минимальная дисперсия/приращение (сек) |
| MAXDIST | 1 | Пороговое расстояние (1 сек) |
| MAXSTRAT | 16 | Максимальный номер «слоя» |
| Рис.7. Общие параметры | ||
В любой прикладной системе таких общих параметров гораздо больше, а их число зависит от самой прикладной системы. Некоторые из общих параметров записываются в постоянное запоминающее устройство (ПЗУ), например, номер порта транспортного уровня, утверждённый IANA. Другие общие параметры, например допустимое отклонение частоты (φ
), касаются предположения о наиболее худшем функционировании системных часов после их синхронизации и последующем допустимом дрейфе в условиях потери связи с источниками синхронизации (синхроисточники). В частности, это относится к максимальным и минимальным значениям параметров, определяющих границы переменных состояния.
Некоторые прикладные системы могут настраивать и управлять своими переменными с помощью специализированных команд настройки. Например, прикладной эталонный источник вычисляет значение точности PRECISION
как логарифм двух (log2
) от минимального значения времени за несколько итераций при считывании системного времени.
7.3. Переменные в заголовке NTP-сообщения
Наиболее важными переменными состояния, с объективной точки зрения, являются переменные в заголовке NTP-сообщения (рис.8). Заголовок NTP-сообщения включает целое число 32-битовых (4-октета) слов, расположенных в порядке их последовательной передачи по сети. NTP-сообщение включает три следующих компонента:
- собственно заголовок;
- одно или несколько дополнительных полей расширения;
- дополнительный код аутентификации сообщения (Message Authentication Code — MAC).
| Наименование | Обозначение | Описание |
|---|---|---|
| leap | leap | Индикатор перехода через 0000 часов |
| version | version | Номер версии NTP-протокола |
| mode | mode | Режим функционирования |
| stratum | stratum | Номер «слоя» |
| poll | poll | Экспоненциальное значение интервала опроса |
| precision | ρ | Экспоненциальное значение точности |
| rootdelay | Δr | Коневая задержка |
| rootdisp | Εr | Коневая дисперсия |
| refid | refid | Идентификатор эталонного источника |
| reftime | reftime | Значение (метка) времени эталонного источника |
| org | T1 | Метка времени клиента при отправке NTP-сообщения серверу |
| rec | T2 | Метка времени сервера при получении NTP-сообщения клиента |
| xmt | T3 | Метка времени сервера при отправке NTP-ответа клиенту |
| dst | T4 | Метка времени клиента при получении NTP-ответа сервера |
| keyid | keyid | Идентификатор криптоключа |
| MAC | MAC | Проверочная аутентификационная сумма сообщения |
| Рис.8. Переменные в заголовке NTP-сообщения | ||
|0 7|8 15|16 23|24 31| +-----------+--------+-------+----------+-------------+-----------+ | Индикатор | Номер | | Номер | Интервал | | | перехода | версии | Режим | "слоя" | опроса | Точность | | (2) | (3) | (3) | (8) | (8) | (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Корневая задержка (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Корневая дисперсия (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Идентификатор источника времени (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Метка времени источника эталонного времени (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Метка времени отправки NTP-сообщения серверу (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Метка времени сервера при получении NTP-сообщения клиента (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Метка времени сервера при отправке NTP-ответа клиенту (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Первое поле расширения (переменная длина) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Второе поле расширения (переменная длина) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Идентификатор криптоключа (32) | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | | > MАС-поле | Криптографическая проверочная сумма (128) | / | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.9. Формат заголовка NTP-сообщения
Собственно заголовок идентичен заголовкам NTP-сообщение всех предшествующих версий. Дополнительные поля расширения используются ассиметричными криптоалгоритмами Autokey-протокола. МАС-поле используется совместно Autokey-протоколом и симметричным криптоалгоритмом.
NTP-сообщение размещается в поле полезной нагрузки UDP-блока (RFC-768). Некоторые поля включают несколько 32-битовых слов, а другие размещаются в составе одного 32-битового слова. Заголовок NTP-сообщения представлен на рис.9, он включает двенадцать 32-битовых слов и завершается дополнительными полями расширения и кодом аутентификации сообщения, содержащее поле идентификатора криптоключа и поле проверочной аутентификационной суммы сообщения. Поля расширения используются для обеспечения дополнительных функциональных возможностей (свойств), например, использование Autokey-протокола. Формат поля расширения выбран так, чтобы при анализе содержания сообщения не нужно было бы иметь какую-либо информацию о функциях этого поля.
Основной заголовок NTP-сообщения начинается с первого бита сообщения до конца поля «Метка времени сервера при отправке NTP-ответа клиенту» (Transmit Timestamp).
Назначение и кодирование полей NTP-сообщения следующие:
«Leap Indicator» (LI):
Индикатор перехода — 2-битовый код, указывающий на использование секунд перехода через 0000 часов, которые будут вставлены или удалены на последней минуте текущего дня, и имеющий следующую кодировку:
Код Значение 00 Предупреждение отсутствует 01 Последняя минута содержит 61 секунду 10 Последняя минута содержит 59 секунд 11 Состояние «тревоги» (часы не синхронизированы) «Version Number» (VN):
Номер версии NTP-протокола — 3-битовый целочисленный код. Текущая версия
4.«Mode»:
Режим функционирования — 3-битовый целочисленный код. Имеет следующую кодировку:
Код Значение 0 Зарезервировано 1 Симметричный активный режим 2 Симметричный пассивный режим 3 Клиент 4 Сервер 5 Широковещательный режим 6 Зарезервировано для управляющих NTP-сообщений 7 Зарезервировано для частного использования «Stratum»:
Номер «слоя» — 8-битовый целочисленный код, определяющий уровень иерархии, на котором расположен сервер времени. Имеет следующую кодировку:
Код Значение 0 Не определено или недопустим 1 Первичный сервер (например, через GPS-приёмник) 2-15 Вторичный сервер (через NTP-протокол) 16 Не синхронизировано 17-255 Зарезервировано Обычно, нулевое значение номер «слоя» в принятых NTP-сообщениях отображается в значение
MAXSTRAT (16)переменной удалённого сервераp.stratum, а передаваемых NTP-сообщениях отображается в переменнуюp.stratumсо значениемMAXSTRAT (16)или большим, чем ноль. Это правило позволяет эталонным часам, которые, как правило, расположены на нулевом уровне иерархии, достаточно просто использовать те же алгоритмы, которые используются при работе с внешними источниками;«Poll»:
Интервал опроса — 8-битовый целочисленный знаковый код, определяющий максимальный интервал между успешно переданными NTP-сообщениями (в секундах, как log2 ). Максимальное и минимальное значения интервала, которые предлагаются использовать «по умолчанию», — 6 и 10, соответственно;
«Precision»:
Точность — 8-битовый целочисленный знаковый код, определяющий точность локальных часов (в секундах, как log2 ). Например, значение
-18соответствует точности приблизительно одной микросекунде. Точность может быть определена при первом запуске службы времени, как минимальное время полученное за несколько итераций при считывании системного времени;«Root Delay»:
Корневая задержка определяет общую задержку петлевого маршрута до эталонного источника, 32-битовый укороченный формат NTP-времени (рис.4,1);
«Root Dispersion»:
Корневая дисперсия определяет максимальную ошибку времени относительно эталонного источника, 32-битовый укороченный формат NTP-времени (рис.4,1);
«Reference ID» (refid):
Идентификатор источника времени — 32-битовый код, определяющий эталонные часы или соответствующий сервер времени. Конкретная интерпретация идентификатора зависит от значения в поле «Номер "слоя"». Если в NTP-сообщении указан нулевой номер «слоя» (не определён или не допустим), то тогда идентификатор кодируется как 4-символьная ASCII-последовательность (RFC-1345), именуемая как «the kiss code» (код «помощи»[?] ) и используемая для отладки и мониторинга. Если в NTP-сообщении указан номер «слоя» один (эталонные часы), то тогда идентификатор — 4-октетная ASCII-последовательность, дополняемая нулями слева, и указывающая на конкретные эталонные часы. IANA утвердила официальный перечень идентификаторов источников эталонного времени. Однако, любая символьная последовательность, начинающаяся с символа
Х, зарезервирована для проведения разного рода исследований и дальнейшего совершенствования системы. Далее приводятся наиболее часто используемые ASCII-идентификаторы:ID Источник сигнала времени GOES Геостационарный спутник системы экологического мониторинга и наблюдения GPS Глобальная система местоопределения GAL Система местоопределения «Галилео» PPS Общий радиосигнал с длительностью импульса, равной 1 секунде IRIG Группа стандартизации в телеметрии, США WWVB Низкочастотный радиопередатчик, 60 кГц, Форт Коллинз, Колорадо, США DCF Низкочастотный радиопередатчик, 77.5 кГц, DCF77, Майнфлинген, ФРГ HBG Низкочастотный радиопередатчик, 75 кГц, Прангинс, Швейцария MSF Низкочастотный радиопередатчик, 60 кГц, Антхорн, Великобритания JJY Низкочастотный радиопередатчик, 40 кГц, Фукушима, 60 кГц, Сага, Япония LORC Среднечастотный радиопередатчик, 100 кГц, радионавигация, LORAN-C TDF Среднечастотный радиопередатчик, 162 кГц, Аллоуис, Франция CHU Высокочастотный радиопередатчик, Оттава, Онтарио, Канада WWV Высокочастотный радиопередатчик, Форт Коллинз, шт.Колорадо, США WWVH Высокочастотный радиопередатчик, Кауаи, Гавайи, США NIST Телефонный модем Национального института стандартов и технологий США ACTS Телефонный модем Автоматизированной службы компьютерного времени США USNO Телефонный модем Национальной обсерватории США PTB Телефонный модем Национального метрологического института ФРГ Если номер «слоя» равен двум или больше (вторичные серверы времени и клиенты), то тогда идентификатор обозначает сервер времени и может использоваться для выявления петлевых маршрутов синхронизации. Если используется IPv4-адресация, то тогда идентификатор представляет собой IPv4-адрес. Если используется IPv6-адресация, то тогда идентификатор представляет собой первые четыре октета результата хеширования (MD5-алгоритм, RFC-1321), IPv6-адреса.
Замечание. Когда NTPv4-сервер времени использует IPv6-адресацию, а клиентский программный NTP-модуль — IPv4-адресацию, то тогда поле «Reference ID» может содержать случайную величину, что исключает возможность выявления петлевых маршрутов синхронизации.
«Reference Timestamp»:
время, когда системные часы были установлены или скорректированы в последний раз, в 64-битовом NTP-формате метки времени (рис.4,2);
«Originate Timestamp» (org):
время в программном NTP-модуле клиента, которое определяет время отправки им NTP-запроса на удаленный сервер времени, в 64-битовом NTP-формате метки времени (рис.4,2);
«Receive Timestamp» (rec):
время в программном NTP-модуле сервера, которое определяет время получения им NTP-запроса от клиента, в 64-битовом NTP-формате метки времени (рис.4,2);
«Transmit Timestamp» (xmt):
время в программном NTP-модуле сервера, которое определяет время отправки им NTP-ответа клиенту, в 64-битовом NTP-формате метки времени (рис.4,2);
«Destination Timestamp» (dst):
время в программном NTP-модуле клиента, которое определяет время получения им NTP-ответа от удаленного сервера времени, в 64-битовом NTP-формате метки времени (рис.4,2).
Замечание. Поле «Destination Timestamp» не включается в заголовок NTP-сообщения, так как оно определяется только после приёма NTP-сообщения и становится доступным в соответствующем буфере, в котором временно храниться поступившее NTP-сообщение.
Если программный NTP-модуль имеет доступ к физическому уровню Internet-архитектуры, то тогда метки времени соответствуют началу символов после начала кадра канального уровня. В противном случае, прикладные службы должны попытаться «привязать» метку времени к самой ранней доступной точке кадра канального уровня;
«Extension Field»:
Дополнительное поле расширения, формат которого представлен в разделе 7.5;
«Key Identifier» (keyid):
идентификатор ключа — 32-битовое беззнаковое целочисленный код, используемый клиентом и сервером для указания секретного 128-битового MD5-ключа;
«Message Digest» (digest):
криптографическая проверочная сумма — 128-битовая последовательность, вычисленная с помощью MD5-алгоритма хеширования и секретного криптоключа по всей последовательности NTP-заголовка, включая дополнительные поля расширения, но не включая поля «Key Identifier» и «Message Digest».
7.4. NTP-сообщение «Kiss-o'-Death»
Если имеет место нулевой номер «слоя», который считается не определённым или не допустимым, поле «Reference Identifier» может использоваться для доставки сообщений, которые выполняют роль данных о состоянии системы и управления доступом. Такие сообщения называются «Kiss-o'-Death»[?] (KoD), а доставляемые ими ASCII-данные называются «kiss codes» (коды «помощи»). KoD-сообщения получили своё название потому, что ранее они использовались для информирования клиентов о прекращении передачи сообщений, которые нарушают управление доступом к серверу. Коды «помощи» могут быть весьма полезными, с точки зрения информирования «интеллектуального» программного клиентского NTPv4- или SNTPv4-модуля. Такие коды представляют собой 4-символьные ASCII-последовательности, дополняемые слева нулями. Эти последовательности предназначены для вывода на дисплей и записи в файлы. Перечень принятых в настоящее время кодов «помощи» представлен на рис.10.
Получатели KoD-сообщений обязаны их проверить и выполнить следующие действия:
При получении кодовых комбинаций
DENYиRSTRклиент обязан разорвать виртуальные соединения с данным сервером времени и прекратить передачу сообщений этому серверу.При получении кодовой комбинации
RATEклиент обязан незамедлительно снизить свой интервал опроса этого сервера и продолжать его уменьшать каждый раз при получении этой кодовой комбинации.При получении кодовой комбинации начинающейся с ASCII-символа
Х, предназначенной для проведения экспериментальных исследований и последующих усовершенствований, она должна быть проигнорирована, если она не распознаётся.Все другие кодовые комбинации и KoD-сообщения, не определённые данным протоколом, уничтожаются после их поверки.
| Код | Описание |
|---|---|
| ACST | Виртуальное соединение установлено одноадресным сервером |
| AUTH | Аутентификация сервером завершилась отказом |
| AUTO | Autokey-последовательность некорректна |
| BCST | Виртуальное соединение установлено широковещательным сервером |
| CRYP | Криптографическая аутентификация или идентификация завершились отказом |
| DENY | Удалённый сервер отказал в доступе |
| DROP | Потеря удаленного сервера времени в симметричном режиме |
| RSTR | Отказ в доступе в следствие локальной стратегии безопасности |
| INIT | Виртуальное соединение с первого раза не установлено |
| MCST | Виртуальное синхросоединение установлено динамически обнаруженным сервером |
| NKEY | Ключ не найден (либо он никогда ранее не загружался, либо он является ненадёжным) |
| RATE | Скорость превышена. Сервер временно запретил доступ, так как клиент превысил порог скорости |
| RMOT | Изменение виртуального соединения со стороны удалённого IP-узла, использующего NTP-протокол напрямую |
| STEP | Произошла итерация по изменению системного времени, виртуальное синхросоединение не установлено |
| Рис.10. Описание кодов «помощи» | |
Метки времени «Receive Timestamp» и «Transmit Timestamp», установленные сервером, не обрабатываются, когда они присутствуют в KoD-сообщении, не должны рассматриваться как надёжные значения времени поэтому должны уничтожаться.
7.5. Формат дополнительного поля расширения
В NTPv4-заголовок может быть добавлено одно или несколько поле расширения (между основным заголовком и МАС-полем, которое всегда должно присутствовать при наличии полей расширения). Правила кодирования и семантика этого поля не являются предметом рассмотрения данного стандарта. Формат дополнительного поля расширения представлен на рис.11.
Все поля расширения дополняются нулям до границы 32-битововго слова. Поле «Тип поля расширения» («Field Type») предназначено для указания функции, которую выполняет это поле (в данном стандарте его кодирование не рассматривается). Минимальный размер поля расширения составляет 16 октетов, тогда как максимальный размер — не стандартизован.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Тип поля расширения | Длина поля расширения | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | . . Значение . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Дополнение нулями (если необходимо) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис.11. Формат дополнительного поля расширения
Поле «Размер поля расширения» («Length») представляет собой 16-битовое беззнаковое целое число, которое предназначено для указания размера всего поля расширения включая поле «Дополнение нулями».
8. Процедурная характеристика протокола
Основой процедурной характеристики NTPv4-протокола является процесс (алгоритм), который обеспечивает обмен значениями времени между серверами, удаленными серверами и клиентами. Он обеспечивает защиту от потери или дублирования NTPv4-сообщений. Целостность данных обеспечивается с помощью проверочных сумм IP- и UDP-протоколов. Протокол не обеспечивает управление потоком и процедуру повторной передачи, более того, в этом нет необходимости. Протокол использует метки времени, при этом они, либо извлекаются из заголовка NTPv4-собщения, либо они проставляются системными часами при отправке или сразу после получения NTPv4-собщения. Метки времени это данные о точном времени, и поэтому их целесообразно повторно проставлять в случае повторной передачи на канальном уровне, а также корректировать при вычислении криптографической контрольной суммы при передаче NTPv4-собщения.
NTPv4-собщения используются в двух различных режимах передачи:
Один-одному (one-to-one), то есть однонаправленный.
Один-многим (one-to-many), то есть широковещательный.
При использовании IPv4-адресации — это широковещательный или групповой адрес (Для этого IANA зарегистрировала групповой IPv4-адрес — 224.0.1.1). А при использовании IPv6-адресации — это групповой адрес (Для этого IANA зарегистрировала окончание группового IPv6-адреса — :101).
В процедурной характеристике NTPv4-протокола используются четыре метки времени t1
…t4
и три переменные состояния org
, rec
и xmt
(рис.12).
t2
t3
t6
t7
+---------+ +---------+ +---------+ +---------+
| 0 | | t1
| | t3
| | t5
|
+---------+ +---------+ +---------+ +---------+
| 0 | | t2
| | t4
| | t6
| Метки времени
+---------+ +---------+ +---------+ +---------+ в NTP-сообщении
| t1
| |t3
=clock | | t5
| |t7
=clock |
+---------+ +---------+ +---------+ +---------+
|t2
=clock | |t6
=clock |
+---------+ +---------+
Сервер B
+---------+ +---------+ +---------+ +---------+
org | T1
| | T1
| | t5
<>T1
? | | T5 |
+---------+ +---------+ +---------+ +---------+ Переменные
rec | T2
| | T2
| | T6
| | T6
| состояния
+---------+ +---------+ +---------+ +---------+
xmt | 0 | | T3
| | t3
=T3
? | | T7
|
+---------+ +---------+ +---------+ +---------+
t2
t3
t6
t7
---------------------------------------------------------
Сервер В /\ \ /\ \
/ \ / \
/ \ / \
/ \/ / \/
---------------------------------------------------------
Сервер А t1
t4
t5
t8
t1
t4
t5
t8
+---------+ +---------+ +---------+ +---------+
| 0 | | t1
| | t3
| | t5
|
+---------+ +---------+ +---------+ +---------+
| 0 | | t2
| | t4
| | t6
| Метки времени
+---------+ +---------+ +---------+ +---------+ в NTP-сообщении
|t1
=clock | | t3
| |t5
=clock | | t7
|
+---------+ +---------+ +---------+ +---------+
|t4
=clock | |t8
=clock |
+---------+ +---------+
Сервер A
+---------+ +---------+ +---------+ +---------+
org | 0 | | t3
<>0? | | T3
| | t7
<>T3
? |
+---------+ +---------+ +---------+ +---------+ Переменные
rec | 0 | | T4
| | T4
| | T8
| состояния
+---------+ +---------+ +---------+ +---------+
xmt | T1
| | t1
=T1
? | | T5
| | t5=T5
? |
+---------+ +---------+ +---------+ +---------+
Рис.12. Структурно-временная модель процедурной характеристики NTPv4-протокола
На рис.12 сервер А
передаёт первое NTPv4-сообщение, включающее только время своей отправки t1
, которое затем копируется в значение T1
. Север В
принимает NTPv4-собщение в момент времени t2
и копирует t1
в T1
, а метку времени получения NTPv4-сообщения t2
— в T2
. В это время или несколько позже в момент времени t3
сервер В
передаёт серверу А
NTPv4-сообщение, содержащее t1
, t2
и дополнительно метку времени отправки t3
. Все эти три метки времени копируются в соответствующие переменные состояния. Сервер А
в момент времени t4
принимает NTPv4-собщение, содержащее три метки времени t1
, t2
и t3
, а также дополнительную метку прибытия NTPv4-собщения от сервера В
t4
. Эти четыре метки используются для расчёта сдвига и задержки часов сервера В
относительно сервера А
.
Прежде чем будут обновлены значения переменных состояния xmt
и org
, проводятся две важных контрольных проверки с целью защиты против дубликатов, поддельных или повторно переданных NTPv4-собщений. Из рассмотренного ранее примера, NTPv4-собщение будет являться дубликатом или повторно переданным, если метка времени отправки t3
в NTPv4-собщении совпадёт с переменной состояния org
, равной T3
. NTPv4-собщение будет являться поддельным, если метка времени отправки t1
в NTPv4-собщении не совпадёт с переменной состояния xmt
, равной T1
. Если эти две контрольных проверки прошли успешно, то тогда переменные состояния обновляются, а само NTPv4-собщение уничтожается. Для защиты от повторной передачи последнего переданного NTPv4-собщения, переменная состояния xmt
устанавливается в ноль сразу после успешной проверки NTPv4-сообщения на предмет его фиктивности.
Четыре наиболее важные метки времени, T1 … T4 , используются для вычисления сдвига времени сервера В относительно сервера А :
θ = T(B) - T(A) = ½×[(T2 - T1 ) + (T3 - T4 )]
а задержка петлевого маршрута:
δ = T(ABA) = (T4 - T1 ) - (T3 - T2 )
Необходимо отметить, что значения в круглых скобках вычисляются на основе 64-битовых беззнаковых метках времени и преобразуются в знаковые величины, состоящие из 63 соответствующих битов и знака плюс (один бит). Эти величины могут представлять собой даты, начиная с последних 68 лет и кончая последующими 68 годами. Однако, сдвиг и задержка вычисляются как суммы и разности таких значений, в которых только 62 бита отводятся для числа, а два бита отводятся под знак числа, и поэтому могут представлять собой явные значения, начиная с последних 34 лет и кончая последующими 34 годами. Другими словами, время клиента должно быть синхронизировано от сервера времени не ранее, чем за 34 лет до начала действия протокола. Это фундаментальное ограничение, связанное с 64-битовыми целочисленными арифметическими действиями.
В прикладных программных NTPv4-модулях, в которых возможна арифметическая операция с удвоенными числами с плавающей точкой, разности первого порядка могут быть преобразованы в удвоенные значения с плавающей точкой, а суммы и разности второго порядка вычисляются с использованием этой операции. Так как значения второго порядка, как правило, очень малы относительно отклонений значений, указываемых в метках времени, и в этом смысле потери точности практически нет, и поэтому однозначный временной интервал от 34 до 68 лет может быть восстановлен.
В некоторых случаях, когда начальный сдвиг частоты в клиентском NTP-модуле относительно большой, а реальное время распространения сигнала мало, то тогда при вычислении задержки результат может быть отрицательным. Например, если разность частоты равна 100 промилей, а интервал T4
— T1
— 64 секунды, то тогда мнимая задержка составит -6,4 миллисекунд. Так как отрицательные значения являются «обманчивыми» при последовательном вычислении, значение δ
должно быть ограничено значением не меньшим, чем s.ρ
, где s.ρ
представляет собой точность системы (в секундах).
Представленные выше рассуждения касаются наиболее общего случая, когда два удалённых сервера времени, функционирующих в симметричном режиме, независимо друг от друга измеряют сдвиги и задержки между собой. Если сервер находится в ином режиме, процедурная характеристика протокола может быть упрощена. Сервер времени копирует метки времени T3 и T4 из NTPv4-сообщения клиента в значения T1 и T2 NTPv4-сообщения сервера и добавляет метку времени T3 отправки ответного NTPv4-сообщения перед самой передачей последнего клиенту.
Процедурная характеристика NTPv4-протокола, по определению, способна защитить систему от повторной передачи ответного NTPv4-сообщения сервера. Однако, она не способна предотвратить повторную передачу ответного NTPv4-сообщения клиента, при реализации которой сервер отправит ответное NTPv4-сообщение с новыми значениями T2
и T3
, и после этого будут рассчитаны некорректные значения сдвига и задержки. Эта уязвимость может быть устранена путём обнуления значения переменной состояния xmt
после вычисления значений сдвига и задержки.
9. Функциональные процедуры удлённого сервера
Процедуры удалённого сервера времени инициируются после получения NTPv4-сообщения от клиента или другого удалённого сервера. Эти процедуры, являясь часть процедурной характеристики NTPv4-протокола, позволяют определить сдвиг времени и задержку петлевого маршрута, а также дополнительные статистические параметры, используемые системным процессом и процессом опроса удалённых серверов времени. Переменные удалённого сервера обрабатываются после установления виртуального соединения на основе данных обновления, содержащихся в поступающих NTPv4-сообщениях. Каждый удалённый сервер времени инициирует процедуры установления виртуального соединения, опроса других серверов времени и определения временных параметров и переменных.
9.1. Переменные, обрабатываемые удалённым сервером
На рис.13 … 16 представлены переменные, обрабатываемые удалённым сервером времени (их наименования, обозначения и краткие описания). Имена и обозначения являются взаимозаменяемыми.
| Наименование | Обозначение | Описание |
|---|---|---|
| srcaddr | srcaddr | IP-адрес источника |
| srcport | srcport | Номер транспортного порта источника |
| dstaddr | dstaddr | IP-адрес получателя |
| dstport | destport | Номер транспортного порта получателя |
| keyid | keyid | Идентификатор криптоключа |
| Рис.13. Переменные настройки виртуального соединения | ||
| Наименование | Обозначение | Описание |
|---|---|---|
| leap | leap | Индикатор перехода через 00 00 часов |
| version | version | Номер версии NTP-протокола |
| mode | mode | Режим функционирования |
| stratum | stratum | Номер «слоя» |
| ppoll | ppoll | Экспоненциальное значение интервала опроса |
| rootdelay | Δr | Коневая задержка |
| rootdisp | Εr | Коневая дисперсия |
| refid | refid | Идентификатор эталонного источника |
| reftime | reftime | Метка времени эталонного источника |
| Рис.14. Переменные в заголовке NTP-сообщения, передаваемого удалённым сервером | ||
| Наименование | Обозначение | Описание |
|---|---|---|
| org | T1 | Метка времени источника NTP-сообщения |
| rec | T2 | Метка времени при получении NTP-сообщения |
| xmt | T3 | Метка времени при отправке NTP-ответа |
| t | t | Время счётчика секунд |
| Рис.15. Переменные меток времени | ||
| Наименование | Обозначение | Описание |
|---|---|---|
| offset | θ | Сдвиг времени |
| delay | δ | Задержка петлевого маршрута |
| disp | ε | Дисперсия |
| jitter | ψ | Джиттер |
| filter | filter | Фильтр времени |
| tp | tp | Время фильтрации |
| Рис.16. Статистические параметры и переменные | ||
Переменные настройки обычно запрашиваются при установлении виртуального соединения, либо из файла настройки, либо из первого поступившего NTPv4-сообщения, когда виртуальное соединение неизвестно. К ним относятся:
srcaddrIP-адрес удалённого сервера времени или эталонного источника времени. Он становится IP-адресом получателя в IP-пакете, содержащем ответное NTPv4-сообщение, в данном виртуальном соединении.
srcportНомер UDP-порта удалённого сервера времени или эталонного источника времени. Он становится номером порта получателя в IP-пакете, содержащем ответное NTPv4-сообщение, в данном виртуальном соединении. Когда функциональное взаимодействие осуществляется в симметричных режимах (1, 2), то тогда данное поле должно содержать утверждённый IANA номер NTP-порта — 123. В других режимах оно может содержать любые другие номера в зависимости от правил обеспечения безопасности.
dstaddrIP-адрес клиента. Он становится IP-адресом отправителя (источника) в IP-пакете, содержащем ответное NTPv4-сообщение, в данном виртуальном соединении.
dstportНомер UDP-порта клиент, обычно, это утверждённый IANA номер NTP-порта — 123. Он становится номером порта отправителя (источника) в IP-пакете, содержащем ответное NTPv4-сообщение, в данном виртуальном соединении.
keyidИдентификатор симметричного криптоключа, для определения 128-битового MD5-ключа, который используется для формирования и проверки значений в МАС-поле. Клиент и удалённый сервер могут использовать различные значения идентификатора, но они должны принадлежать одному и тому же криптоключу.
Переменные, представленные на рис.14, обновляются на основании данных, содержащихся в заголовках поступивших NTPv4-сообщений. Они интерпретируются точно также, как и переменные, содержащихся в заголовках NTPv4-сообщений и с аналогичными именами. Для последующей целесообразно преобразовать переменные r.rootdelay
и r.rootdisp
в заголовке NTPv4-сообщения в укороченном формате (рис.4,1) в удвоенный формат с плавающей точкой, аналогично переменным удалённого сервера времени.
Переменные, представленные на рис.15, включают метки времени, которыми обмениваются объекты и субъекты синхронизации на основе процедурной характеристики NTPv4-протокола. Переменная t
представляет собой значение счётчика секунд c.t
, который участвует в формировании меток времени. Переменная c.t
уточняется процессом корректировки времени. Фактически, счётчик считает секунды с момента запуска службы.
Переменные, представленные на рис.16, включают статистические параметры, которые вычисляются с помощью прикладной процедуры фильтрации времени clock_filter()
. Переменная tp
представляет собой значение счётчика секунд, который участвует в формировании этих параметров.
9.2. Процедуры, проводимые удалённым сервером
К таким процедурам относятся процедура приема NTPv4-сообщения и процедура управления доступом на основе списка управления доступом (access control list — ACL). Последняя не требует каких-либо специальных методов по управлению доступом, хотя существует рекомендация, чтобы прикладные программные NTPv4-модули включали такой способ, который подобен многим другим широко используемым способам.
Проверки формата включают контроль корректности длины и дополнения до 32-битовой границы, доступность номера версии протокола (1…4), а также, при наличии, корректность дополнительных полей расширения.
Не существует какого-либо специального требования к процедуре аутентификации. Однако, если процедура аутентификации имеет место, то тогда среди всех реализованных способов должен быть и способ, основанный на MD5-алгоритме хеширования с использование симметричного криптоключа (RFC-1231).
Для поиска и сравнения IP-адресов и номеров портов транспортного уровня отправителей NTPv4-сообщений существует таблица виртуальных соединений, при этом используется специальный прикладной процесс find_assoc()
. На рис.17 представлена диспетчерская таблица, в которой колонки соответствуют номерам форматов пакетов (NTPv4-сообщений), а строки — режимам функционирования виртуальных соединений. Данная таблица позволяет определить необходимую процедуру обработки. Кодировка процедур следующая:
| Режим соединения | Форматы пакетов | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| Отсутствие соединения | 0 | NEWPS | DSCRD | FXMIT | MANY | NEWBC |
| Симметричный активный | 1 | PROC | PROC | DSCRD | DSCRD | DSCRD |
| Симметричный пассивный | 2 | PROC | ERR | DSCRD | DSCRD | DSCRD |
| Режим клиента | 3 | DSCRD | DSCRD | DSCRD | PROC | DSCRD |
| Режим сервера | 4 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Широковещательный | 5 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Широковещательный (клиента) | 6 | DSCRD | DSCRD | DSCRD | DSCRD | PROC |
| Рис.17. Диспетчерская таблица удалённого сервера времени | ||||||
DSCRD(уничтожение)Этот код указывает на несущественную ошибку функционирования NTPv4-протокола, возникшую в следствие программной ошибки, либо это было опоздавшее NTPv4-сообщение, либо оно было повторно передано. Прикладной процесс сервера уничтожает сообщение и завершается.
ERR(ошибка)Этот код указывает на фатальную ошибку функционирования NTPv4-протокола, возникшую в следствие программной ошибки, либо это было опоздавшее NTPv4-сообщение, либо оно было повторно передано. Прикладной процесс сервера уничтожает сообщение, разрывает виртуальное соединение, функционировавшее в симметричном пассивном режиме, и завершается.
FXMITЭтот код указывает на то, что NTPv4-сообщение клиента (режим №3) не соответствует режиму функционирования, то есть виртуальное синхросоединение отсутствует. Если IP-адрес получателя не является широковещательным, то тогда сервер переходит в режим сервера формирует ответное NTPv4-сообщение и отправляет его клиенту без сохранения данного режима. Заголовок NTPv4-сообщения сервера формируется специальным прикладным процессом
fast_xmit()из системных переменных и переменных из принятого NTPv4-сообщения (рис.18). Если системные переменныеs.rootdelayиs.rootdispхраняться в удвоенном формате с плавающей точкой, то тогда они должны быть первыми преобразованы в укороченный 32-битовый NTP-формат.Переменные в NTP-сообщении ⇐ Переменная r.leap ⇐ p.leap r.mode ⇐ p.mode r.stratum ⇐ p.stratum r.poll ⇐ p.ppoll r.rootdelay ⇐ p.rootdelay r.rootdisp ⇐ p.rootdisp r.refid ⇐ p.refid r.reftime ⇐ p.reftime r.keyid ⇐ p.keyid Рис.18. Переменные их принятого NTPv4-сообщения Замечание. Если процедура аутентификации завершилась отказом в доступе, то тогда сервер передает специальное ответное NTPv4-сообщение, именуемое «crypto-NAK». Это сообщение включает данные обычного NTPv4-заголовка (рис.8), но МАС-поле состоит из четырёх нулевых октетов. Клиент, получив это сообщение от сервера, может использовать или уничтожить содержащиеся в нём данные. После этих действий процесс завершается.
Если IP-адрес получателя является групповым IP-адресом, то тогда отправитель функционирует в групповом клиентском режиме. Если NTPv4-сообщение корректно и номер «слоя» сервера меньше, чем номер «слоя» клиента, то тогда сервер передает обычное NTPv4-сообщение сервера (режим №4), но при этом использует однонаправленный IP-адрес получателя. Если процедура аутентификации завершилась отказом в доступе, то тогда ответное NTPv4-сообщение «crypto-NAK» не передаётся. После этих действий процесс завершается.
MANYЭтот код указывает на то, что NTPv4-сообщение сервера (режим №4) не соответствует режиму функционирования, то есть виртуальное синхросоединение отсутствует. Обычно, это может произойти тогда, когда сервер передаёт ответное NTPv4-сообщение в составе IP-пакета с групповым IP-адресом на ранее полученный IP-пакет с групповым IP-адресом, содержащий NTPv4-сообщение клиента. Если NTPv4-сообщение корректно, то тогда устанавливается обычное виртуальное соединение в клиентском режиме (режим №3), а процесс обработки продолжает функционировать, как если бы виртуальное соединение было установлено на основе данных из файла настройки.
NEWBCЭтот код указывает на то, что NTPv4-сообщение (режим №5), содержащееся в IP-пакете с широковещательным IP-адресом, не соответствует режиму функционирования, то есть виртуальное синхросоединение отсутствует. Клиент устанавливает, либо клиентское (режим №3), либо клиентское широковещательное (режим №6) виртуальное соединение с помощью прикладных процессов
mobilize()иclear(). Затем прикладной процессpacket()подтверждает корректность NTPv4-сообщения и обновляет значения переменных прикладного NTPv4-модуля удалённого сервера времени.Если прикладной программный NTPv4-модуль сервера времени не реализует дополнительные функции по обеспечению безопасности или калибровки времени, то тогда виртуальное соединение переходит в широковещательные клиентский режим (режим №6), а процесс обработки завершается. Если же прикладные программные NTPv4-модули серверов времени способны использовать аутентификацию на основе криптографии с открытыми ключами, то тогда они могут применить протокол аутентификации «Autokey» или ему подобный протокол обеспечения безопасности. Для определения задержки, связанной с распространением синхросигнала, целесообразно, чтобы прикладные программные NTPv4-модули серверов времени переустанавливали свои виртуальные соединения «клиент/сервер» в режим№3 и использовали укороченную процедуру информационного обмена. Затем для последующего информационного взаимодействия виртуальное синхросоединение переходит в режим №6, а прикладной процесс удалённого сервера функционирует только в режиме контроля соединения (listen-only mode).
NEWPSЭтот код указывает на то, что принято NTPv4-сообщение (режим №1), указывающее на симметричное активное виртуальное соединение, но виртуальное синхросоединение отсутствует. Клиент формирует виртуальное соединение в симметричном пассивном режиме (режим №2) с помощью прикладных процессов
mobilize()иclear(). Процесс обработки продолжается.PROCЭтот код указывает на то, что принятое NTPv4-сообщение прошло проверку и оно принадлежит существующему виртуальному синхросоединению. Метки времени в этом NTPv4-сообщении тщательно проверены на предмет корректности, дублирования или подмены (фальсификации) NTPv4-сообщений. Дополнительные проверочные процедуры представлены на рис.19.
Замечание. Все NTPv4-сообщения, включая сообщения «crypto-NAK», считаются корректными, если они успешно прошли все, указанные на рис.19, проверочные процедуры.
Тип сообщения Описание 1. Дубликат В лучшем случае, это старое продублированное сообщение, в худшем — атака хакера «повторная передача». Такое событие может произойти в симметричных режимах, если интервалы опроса сбалансированы. 2. Фальсифицированное Одно или несколько полей меток времени некорректны. Такое событие обычно происходит в симметричных режимах, когда один удалённый сервер времени передаёт первое сообщение другому, а перед этим другой сервер принял его первое ответное сообщение. 3. Некорректное 4. Отказ в доступе Источник сообщения числится в «чёрном» списке системы управления доступом 5. Провал аутентификации Криптографическая проверочная сумма не совпадает со значением в МАС-поле. 6. Нет синхронизации Сервер не засинхронизировался от доступного источника. 7. Некорректные данные заголовка Одно или несколько полей заголовка сообщения некорректны. Рис.19. Описание дополнительных проверочных процедур Обработка NTPv4-сообщения продолжается с помощью прикладного процесса
packet(), которые копирует значения переменных из сообщения в значения переменных прикладного программного NTPv4-модуля удалённого сервера (рис.18). Прикладной процессreceive()использует 1…5 дополнительные проверочные процедуры, представленные на рис.19, аpacket()— 6…7 процедуры. Если в процессе проверки NTPv4-сообщения выявляются ошибки, то тогда оно уничтожатся, а процесс обработки завершается.
Процедурная характеристика NTPv4-протокола обеспечивает вычисление сдвига времени θ
и задержку петлевого маршрута δ
с помощью самых «свежих» меток времени (рис.12). Несмотря на то, что, в принципе, существует возможность выполнить все вычисления (кроме разностей значений меток времени первого порядка) с использованием арифметических операций над числами с фиксированной точкой, всё равно гораздо проще преобразовать разности первого порядка в удвоенные значения с плавающей точкой и выполнить остальные вычисления с использованием арифметических операций над такими числами. Все последующие рассуждения будут основаны на этом предположении.
В процедуре опроса участвует 8-битовый регистр сдвига p.reach
, который определяет достижимость удалённого сервера времени, а также являются ли полученные от него данные самыми «свежими». Это регистр сдвигается влево на один бит, когда передано NTPv4-сообщение, а крайний правый бит обнуляется. После получения корректных NTPv4-сообщений прикладной процесс packet()
устанавливает крайний правый бит в 1
. Если в этом регистре содержится любое количество ненулевых битов, то тогда считается, что удалённый сервер времени достижим, в противном случае — нет. Так как интервал опроса в прикладном NTPv4-модуле сервера времени может измениться после получения последнего NTPv4-сообщения, инициализируется прикладной процесс poll_update()
, который выполняет задачу определения нового интервала опроса IP-узла.
Статистическая дисперсия ε(t)
представляет собой максимальную ошибку, являющуюся следствием допустимого отклонения частоты и интервала времени с момента передачи последнего NTPv4-сообщения. В начальный момент дисперсия вычисляется следующим образом:
ε(t0 ) = r.ρ + s.ρ + Φ×(T4 - T1 )
то есть измерение было сделано в момент времени t0
, что соответствовало значению счётчика секунд. Переменная r.ρ
— точность, указанная в NTPv4-сообщении, а s.ρ
— точность системных часов, при этом обе переменные измеряются в секундах. Они необходимы для учёта погрешностей при считывании значений системного времени, и в прикладном NTPv4-модуле сервера, и в прикладном NTPv4-модуле клиента.
Затем дисперсия возрастает с постоянной скоростью Φ
, другими словами, в момент времени t
:
ε(t) = ε(t0 ) + Φ×(t - t0 )
По умолчанию Φ = 15 РРМ
, что составляет примерно 1,3 секунды за сутки. В дальнейшем аргумент t
не будет использоваться, а дисперсия будет обозначаться одним символом ε
. Остальные статистические параметры вычисляются с помощью процедуры фильтрации времени.
10. Процедура (алгоритм) фильтрации времени
Процедура (алгоритм) фильтрации времени является частью процедур, применяемых в прикладном программном NTPv4-модуле удалённого сервера. Эту процедуру реализует прикладной процесс clock_filter()
, который фильтрует поток протокольных данных с целью выбора эталонных источников времени, обеспечивающих наиболее точное время. Данная процедура обеспечивает вычисление значений переменных (рис.16), среди которых сдвиг θ
, задержка δ
, дисперсия ε
, джиттер ψ
и время прибытия NTPv4-сообщения t
. Эти данные используются алгоритмами обработки входного трафика с целью определения наилучшего и окончательного сдвига, который, в свою очередь, используется для корректировки системных часов. Они также используются для определения функционального состояния сервера времени и его пригодности выступать в роли источника синхронизации.
Процедура фильтрации времени сохраняет наборы самых последних значений взаимосвязанных переменных (θ
, δ
, ε
, t
) в схеме фильтра, который функционирует как 8-разрядный регистр сдвига. Наборы значений переменных сохраняются в том порядке, в котором прибыли NTPv4-сообщения. В данном случае, переменная t
— значение счётчика секунд в момент приёма NTPv4-сообщения, и поэтому она отличается от переменой tр
прикладного NTPv4-модуля удалённого сервера.
Используемая схема фильтрации призвана обеспечить достаточное количество источников синхронизации для последующего анализа, а также удаление устаревших данных. В начале, наборы переменных для всех состояний устанавливаются в форме временного (фиктивного) набора (0, MAXDISP, MAXDISP, 0). После поступления корректных NTPv4-сообщений наборы значений переменных записываются в память фильтра, что влечёт за собой удаление наборов устаревших значений, и поэтому в фильтре остаются только разрешённые наборы переменных. Если в регистре достижимости три бита низшего порядка являются нулевыми, указывая на то, что три интервала опроса, в течении которых поступили некорректные NTPv4-сообщения, истекли, то тогда процедура опроса обращается к процедуре фильтрации времени, реализуемая фильтром, в памяти которого записан фиктивный набор переменных, как если бы последний был получен из сети. Если такая ситуация остаётся на протяжении восьми интервалов опрос, то тогда регистр переустанавливается в исходное состояние.
На следующем этапе, состояния регистра сдвига копируются во временный перечень, в котором записи сортируются по мере возрастания значения δ
. Пусть i
будет индексом состояния, начиная с наименьшего значения δ
. Если время фильтрации первого набора переменных t0
не является более поздним, чем время фильтрации самого последнего корректного синхроисточника tp
, то тогда прикладной процесс завершается, сохраняя без изменений текущие значения переменных прикладного NTPv4-модуля сервера. В противном случае, пусть εi
будет дисперсией i-ой записи, тогда
i=n-1
--- εi
ε = \ ----------
/ (i+1)
--- 2
i=0
является дисперсией удалённого сервера p.disp
.
Замечание. При перезагрузке значения ε
, либо на входе фильтра времени, либо она его выходе, это значение должно быть предварительно удалено из набора переменных.
При более внимательном анализе становится очевидным, что:
Если все состояния содержат фиктивный набор переменных со значением дисперсии
MAXDISP, то тогда вычисленное значение дисперсии не на много меньше чем 16 секунд.Каждый раз, когда корректный набор переменных сдвигается в регистре, дисперсия снижается почти на половину, в зависимости от дисперсии в корректных наборах переменных.
После обработки четвёртого корректного NTPv4-сообщения значение дисперсии обычно составляет не многим менее одной секунды, которое является предполагаемым значением параметра
MAXDISP, используемого процедурой селекции для определения приемлемости значений переменных прикладного NTPv4-модуля сервера.
Пусть сдвиг первого состояния регистра, записанного в перечень, будет θ0
, тогда при других состояниях регистра, следующих в произвольном порядке, джиттер представляет собой среднеквадратичное отклонение:
+----- -----+1/2
| n-1 |
| --- |
1 | \ |
ψ = -------- * | / (θ0
-θj
)2
|
(n-1) | --- |
| j=1 |
+----- -----+
где n
— число корректных наборов переменных в памяти фильтра (n > 1). С целью гарантированного обеспечения совместимости и предотвращения каких-либо ограничений в других вычислениях, значение ψ
ограничивается снизу значением системной точности s.ρ
, выраженной в секундах. Несмотря на то, что пока нет согласованного единого критерия классификации серверов времени, с точки зрения их качества, джиттер является очень важным показателем качества обеспечения синхронизации и состояния перегрузки сети. Важное значение для алгоритмов оптимизации имеет расстояние синхронизации удалённого сервера времени, которое вычисляется с помощью задержки и дисперсии:
λ = (δ / 2) + ε
Замечание. Значение ε
и тем более значение λ
увеличиваются со скоростью Φ
.
Переменная λ
не является системным параметром, так как её значение пересчитывается при каждом её использовании. Она является составной частью расстояния синхронизации до корневого сервера времени и используется алгоритмами оптимизации в качестве метрики при определении качества синхросигналов, передаваемых каждым доступным сервером времени.
Очень важно отметить, что в отличие от NTPv3-протокола, виртуальные NTPv4-соединения не оповещают о переходе в режим тайм-аута с помощью установки значения 16
в поле «Номер слоя» («Stratum», рис.9) и значения 3
в поле «Индикатор перехода» («Leap Indicator», рис.9). Переменные виртуального соединения сохраняют свои значения, которые были указаны в последнем поступившем NTPv4-сообщении. В NTPv4-протоколе переменная λ
увеличивается со временем, и в конечном счёте расстояние синхронизации превышает предельное значение расстояния MAXDIST
, а в этом случае, виртуальное соединение считается непригодным для синхронизации.
11. Системный процесс (процедуры)
После того, как алгоритм фильтрации времени вычислит значения переменных (θ
, δ
, ε
, ψ
, t
), все процедуры прикладных NTPv4-модулей сервера опрашиваются алгоритмами оптимизации, включающими алгоритмы селекции, кластеризации, суммирования и корректировки часов в рамках системного процесса. Процедура (алгоритм) селекции опрашивает серверы времени с помощью виртуальных соединений и «отбрасывает» некорректные часы, которые продемонстрировали некорректное время, оставляя в итоге корректные часы.
В течении нескольких циклов процедура (алгоритм) кластеризации удаляет виртуальное соединение, которое являются самым длинным относительно опрашивающего сервера времени или клиента, пока не останется определённое число кандидатов на роль источника синхронизации.
Процедура (алгоритм) суммирования вычисляет наилучшие и заключительные значения статистических параметров/переменных на основе усреднения весовых коэффициентов. Финальное значение сдвига времени далее поступает на вход процедуры (алгоритм) корректировки времени, которая устанавливает правильное значение времени в системных часах.
Процедура (алгоритм) кластеризации выбирает одного из кандидатов в качестве системного сервера времени. Значения взаимосвязанных статистических параметров/переменных (θ
, δ
, ε
, ψ
, t
) используются для формирования системных переменных, которыми пользуются зависящие от них серверы времени и клиенты, и становятся доступными для всех других прикладных и системных процессов, которые функционируют в данном компьютере.
11.1. Переменные системного процесса (процедур)
На рис.20 представлены наименование, обозначение и краткое описание каждой системной переменной. Если не указано обратного, то тогда все переменные записываются с префиксом s
.
За исключением переменных t
, p
, Ψ
, Θ
и констант NMIN
и CMIN
, все переменные имеют одинаковый формат и интерпретируются как переменные прикладного NTPv4-модуля сервера времени с одним и тем же именем. Параметры NMIN
и CMIN
используются в процедурах (алгоритмах) селекции и кластеризации.
| Наименование | Обозначение | Описание |
|---|---|---|
| t | t | Время обновления данных |
| p | p | Идентификатор системного сервера времени |
| leap | leap | Индикатор перехода через 0000 часов |
| stratum | stratum | Номер «слоя» |
| precision | ρ | Значение точности |
| offset | Θ | Суммарный сдвиг времени |
| jitter | Ψ | Суммарный джиттер |
| rootdelay | Δ | Коневая задержка |
| rootdisp | Ε | Коневая дисперсия |
| v | v | Перечень претендентов на роль источника синхронизации |
| refid | refid | Идентификатор эталонного источника |
| reftime | reftime | Значение (метка) времени эталонного источника |
| NMIN | 3 | Минимальное число претендентов на роль источника синхронизации |
| CMIN | 1 | Минимальное число кандидатов на роль системного источника синхронизации |
| Рис.20. Параметры и переменные системного процесса (процедур) | ||
Переменная t
представляет собой значение счётчика секунд с момента последнего обновления данных, определяемого прикладным процессом clock_update()
. Переменная p
является идентификатором системного сервера времени, определённого прикладным процессом cluster()
. Переменная ρ
(точность) имеет точно такой же формат, как и переменная в заголовке NTPv4-сообщения с таким же именем. Под точностью понимается наибольшее значение разрешающей способности (максимальная частота дискретизации), а также время считывания текущего значения часов (в log2
). Например, точность часов на основе промышленной частоты 60 Гц составляет 16 миллисекунд, даже тогда, когда аппаратная реализация системных часов обеспечивает точность одну наносекунду.
Значения сдвига и джиттера определяются прикладным процессом combine()
. Эти значения считаются наилучшими, а финальные значения сдвига и джиттера используются для корректировки системного времени. Первоначально значения всех переменных обнуляются, после этого в поле «Индикатор перехода» («Leap Indicator», рис.9) записывается значение 3
(отсутствие синхронизации), а в поле «Номер слоя» («Stratum», рис.9) — значение MAXSTRAT
(16
). В заголовке передаваемого NTPv4-сообщения значение MAXSTRAT
отображается в последовательность нулевых битов.
11.2. Процедуры системного процесса
На рис.21 представлена структурная блок-схема прикладного процесса clock_select()
, который реализует ряд процедур системного NTPv4-процесса. Процедура (алгоритм) селекции определяет большую группу предполагаемых корректных кандидатов (корректных источников синхронизации) на основе принципов обоюдного согласия. Процедура (алгоритм) кластеризации удаляет «менее достойных кандидатов» с целью формирования подгруппы наиболее точных претендентов на роль синхроисточников. Процедура (алгоритм) суммирования определяет наилучшее и заключительное значение сдвига, которое будет использоваться в процедуре (алгоритме) корректировки времени. Если процедура (алгоритм) селекции не смогла определить достаточно большую группу предполагаемых источников синхронизации, или не смогла определить, по крайней мере, число претендентов, равное значению константы CMIN
, то тогда системный процесс завершается без настройки системных часов. Если же указанные выше процедуры прошли успешно, то тогда процедура (алгоритм) кластеризации выбирает наилучшего, с точки зрения статистических результатов, кандидата в качестве системного сервера времени, а значения его переменных используются как системные переменные.
11.2.1. Процедура (алгоритм) селекции
Процедура (алгоритм) селекции предназначена для поиска интервала перекрытия, содержащего максимальное число корректных часов, на основе принципов византийского соглашения, определённых Марцулло[?] , но сама процедура была изменена с целью повышения точности.
Во-первых, выявляются те серверы времени, которые не пригодны в соответствии с правилами процедурной характеристики NTPv4-протокола, и за тем к ним блокируется доступ, с помощью прикладного процесса accept()
. Далее, для оставшихся претендентов формируется набор переменных (p, type, edge)
. В данном наборе p
— идентификатор виртуального соединения, type
идентифицирует конечные точки интервала корректности (upper (верхняя) +1
, middle (средняя) 0
и lower (нижняя) -1
), который центрирован относительно значения переменной θ
, для конкретного кандидата. С учётом этого имеем три набора: нижняя точка (p, -1, θ - λ)
, средняя точка (p, 0, θ)
и верхняя точка (p, +1, θ + λ)
, где λ
— корневое расстояние синхронизации, вычисляемое при каждом его применении с помощью прикладного процесса rootdist()
. При реализации процедуры (алгоритма) селекции выделяют следующие итерации:
+-----------------+
| clock_select() |
+-----------------+
...................................|.............
. V .
. Да +---------+ +----------------------+ .
. +--|Приемлем?| | Отобранные | .
. | +---------+ | кандидаты | .
. V Нет | | | .
. +---------+ | | | .
. | Добавить| | | | .
. |кандидата| | | | .
. +---------- | | | .
. | V | | .
. +---------->-->| | .
. | | .
. Алгоритм селекции +----------------------+ .
...................................|.............
V
Нет +------------------------+
+-------------| Претендент? |
| +------------------------+
| | Да
| V
| +------------------------+
| | Алгоритм кластеризации |
| +------------------------+
| |
| V
V Да +------------------------+
|<------------| n < CMIN? |
| +------------------------+
V |
+-----------------+ V Нет
| s.p = NULL | +------------------------+
+-----------------+ | s.p = v0
.p |
| +------------------------+
V |
+-------------------+ V
| В начало | +------------------------+
|(без синхронизации)| | В начало |
+-------------------+ | (наличие синхронизации)|
+------------------------+
Рис.21. Прикладной процесс "clock_select()"
Для каждого из m виртуальных соединений, в списке претендентов формируются три набора переменных.
Классификация наборов переменных в списке на основе компонента
edgeв следующем порядке: нижняя точка, средняя точка и верхняя точка этих интервалов, начиная с самого нижнего значения и заканчивая самым верхним значением. Присваиваем нулевое значение числу некорректных источников синхронизации (f = 0).Присваиваем нулевое значение числу средних точек (
d = 0). Присваиваемснулевое значение (с = 0). Проверяем все крайние точки, начиная с самой нижней и заканчивая самой верхней. Прибавляем ксединицу при проверке каждой нижней точки, и вычитаем единицу после каждой верхней точки, добавляем единицу кdпосле каждой средней точки. Еслис ≥ m - f, процедура завершается, а текущему значению числа нижних точек присваивается единица.Присваиваем
снулевое значение (с = 0). Проверяем все крайние точки, начиная с самой верхней и заканчивая самой нижней. Прибавляем ксединицу при проверке каждой верхней точки, и вычитаем единицу после каждой нижней точки, добавляем единицу кdпосле каждой средней точки. Еслис ≥ m - f, процедура завершается, а текущему числу верхних точек присваивается значениеu.Проверяем равенство
d = fи неравенствоl < u. Если они выполняются, то тогда процедур завершилась успешно, а интервал перекрытия составляет [l, u]. Если же нет, то тогда увеличиваем на единицу значениеf. После этого проверяем неравенствоf < m/2. Если оно выполняется, то тогда процедура возвращается на третью итерацию. Если же оно не выполняется, то тогда процедура переходит на шестую итерацию.Процедура завершилась «неудачей». Максимальное число корректных часов не определено. Нет приемлемых кандидатов для корректировки системного времени.
Необходимо отметить, что эта процедура начинается в предположении, что некорректные часы отсутствуют (f = 0
) и она «пытается» найти непустой интервал перекрытия, содержащий средние точки всех корректных серверов времени, то есть надёжных источников синхронизации. Если нельзя найти непустой интервал, то тогда число предполагаемых некорректных источников синхронизации увеличивается на единицу, а попытка отыскания непустого интервала повторяется. Если же непустой интервал найден, а число некорректных источников синхронизации меньше, чем корректных, то тогда считается, что найдена группа основных источников синхронизации и средняя точка каждого такого источника (θ
) представляет собой кандидата, который в дальнейшем обрабатывается процедурой (алгоритмом) кластеризации.
Если же группа основных источников синхронизации не найдена, или если число корректных источников синхронизации меньше, чем значение параметра CMIN
, то тогда для процесса настройки и корректировки системных часов не хватает приемлемых кандидатов. Параметр CMIN
определяет минимальное количество серверов времени, удовлетворяющих требованиям корректности. Более внимательные сетевые администраторы могли бы установить такое значение параметра CMIN
, которое бы гарантировало несколько дополнительных серверов времени, вполне приемлемых для их обработки соответствующими алгоритмами оптимизации. Однако, исторически сложилось так, что значение параметра CMIN
, по-умолчанию, равно единице.
11.2.2. Процедура (алгоритм) кластеризации
Кандидаты из группы основных источников синхронизации помещаются в списке оставшихся претендентов v
в форме наборов параметров (p, θp
, ψp
, λp
), в котором p
— идентификатор виртуального соединения, θp
, ψp
, stratump
— текущие значения сдвига, джиттера и номера «слоя» р-го виртуального соединения, соответственно, а λp
— весовой коэффициент равный выражению stratump
× MAXDIST + λ
, где λ
— корневое расстояние синхронизации для р-го виртуального соединения. Перечень основных источников синхронизации обрабатывается процедурой (алгоритмом) кластеризации, в этой обработке принимает участие вторая часть прикладного процесса clock_select()
:
Пусть набор
p, θp , ψp , λpопределяет кандидат из списка основных источников синхронизации.Классифицируем кандидатов с учётом возрастания
λp. Пустьn— число кандидатов, а параметрNMINопределяет минимально необходимое число кандидатов в списке основных источников синхронизации.Для каждого кандидата определяется селективный джиттер
ψs:+----- -----+1/2 | n-1 | | --- | | 1 \ | ψs = | ---- * / (θs - θj )2 | | n-1 --- | | j=1 | +----- -----+Выбираем кандидата с максимальным значением
ψsи обозначаемψmax.Выбираем кандидата с минимальным значением
ψpи обозначаемψmin.Проверяем неравенства
ψmax < ψminилиn ≤ NMIN. Если они выполняются, то тогда процедура считается выполненной, а оставшиеся кандидаты в списке основных источников синхронизации ранжируются в порядке предпочтения. Первая запись в списке определяет системный удалённый сервер времени, а его переменные в дальнейшем используются для обновления системных переменных. Если неравенства не выполняются, то тогда претендент со значениемψmaxудаляется из списка, значениеnуменьшается на единицу, а процедура переходит на третью итерацию (λ).
Данная процедура (алгоритм) функционирует циклически, и при каждом цикле удаляет из списка основных источников синхронизации одного из кандидатов, имеющего максимальный селективный джиттер ψs
. Однако, если значение ψs
меньше минимального значения джиттера удалённого сервера времени ψp
, то тогда добиться улучшения качества синхронизации путём удаления «бракуемых» серверов времени не возможно. В противном случае (ψs
> ψp
), определяется минимальный состав основных источников синхронизации, что позволяет корректно завершить процедуру. После её завершения регистрируется финальное значение ψmax
, так как оно в последующем используется в качестве системного селективного джиттера Ψs
.
11.2.3. Процедура (алгоритм) суммирования
Оставшиеся претенденты на роль основных источников синхронизации обрабатываются прикладным процессом clock_combine()
с целью определения наилучших и заключительных значений параметров, которые будут в последующем использоваться процедурой (алгоритмом) корректировки (настройки) времени (часов). Прикладной процесс clock_combine()
обрабатывает статистические значения сдвига и джиттера с целью определения суммарного системного значения сдвига Θ
и системного значения джиттера Ψp
удалённого сервера, при этом статистическому параметру каждого сервера времени присваивается весовой коэффициент на основе вычисления значения обратной величины корневого расстояния синхронизации и нормирования результата.
Суммарное значение Θ
используется прикладным процессом clock_update()
. Первый претендент из списка основных источников синхронизации именуется как системный удалённый сервер времени с идентификатором p
. Джиттер системного удалённого сервера времени Ψp
является компонентом системного джиттера Ψ
. Значение Ψp
всё время используется совместно со значением селективного джиттера Ψs
для определения системного джиттера:
Ψ = [(Ψs )2 + (Ψp )2 ]½
Каждый раз обновление данных синхронизации осуществляется с помощью прикладного процесса clock_update()
, к которому происходит обращение после получения соответствующего NTPv4-сообщения от системного сервера времени. В соответствие с существующим правилом, данные обновления времени (синхронизации) уничтожаются, если время их поступления p.t
было не строго более поздним, чем системное время s.t
последнего обновления данных синхронизации. Передаваемые маркеры IGNOR
, PANIC
, ADJ
и STEP
определяют ответную реакцию прикладного процесса local_clock()
и означают следующее:
IGNORДанные обновления времени (синхронизации) были проигнорированы, так как принадлежали «отбракованному» источнику синхронизации.
PANICЗначение сдвига на много превысило критическое пороговое значение
PANICT(1000 сек). В связи с этим целесообразно завершить программу обработки и передать диагностическое сообщение системному администратору сети с последующей регистрацией данного события.STEPЗначение сдвига не превысило критическое пороговое значение
PANICT, но оно значительно больше, чем «пошаговое» пороговое значениеSTEP(125 мсек). В этом случае, часы «пошагово» сдвигаются к корректному значению сдвига, но так как это означает, что данные всех удалённых серверов времени стали неприемлемыми, все виртуальные синхросоединения должны быть переустановлены, а процедура NTPv4-синхронизации стартует с начала, как и в начальный период функционирования.ADJЗначение сдвига не превысило «пошаговое» пороговое значение
STEPи поэтому данные обновления времени (синхронизации) являются корректными. В этом случае, значения системных переменных обновляются на основе значений переменных удалённых серверов времени (рис.22).Системные переменные ⇐ Переменные системного сервера времени s.leap ⇐ p.leap s.stratum ⇐ p.stratum + 1 s.offset ⇐ Θ s.jitter ⇐ Ψ s.rootdelay ⇐ p .δr + δ s.rootdisp ⇐ p.εr + p.ε + p.ψ + Φ×(s.t - p.t) + |Θ| s.refid ⇐ p.refid s.reftime ⇐ p.reftime s.t ⇐ p.t Рис.22. Обновление системных переменных
На рис.22 не показана одна очень важная деталь. Рост дисперсии (p.ε + p.ψ + Φ×(s.t - p.t) + |Θ|
) ограничивается снизу значением параметра MINDISP
. В подсетях синхронизации, в которых используются высокопроизводительные ЛВС и быстродействующие процессоры, и в которых очень малы значения задержки и сдвига, ускоряется монотонный и чётко выраженный рост значения параметра s.rootdisp
(Ε
), что предотвращает образование петлевых синхромаршрутов между удалёнными серверами времени, функционирующими на одном и том же слое иерархии синхросети.
Системные переменные могут зависеть от конкретных прикладных программных NTPv4-модулей, и выступать в роли номинальных эксплуатационных характеристик и параметров. Системный сдвиг Θ
представляет собой сдвиг времени относительно доступных источников синхронизации. Системный джиттер Ψ
представляет собой оценку значения ошибки при определении значения системного сдвига, которая иногда именуется как ожидаемая ошибка. Корневая задержка Δ
представляет собой общую задержку петлевого маршрута относительно первичного сервера времени. Корневая дисперсия Ε
является суммарной дисперсией, накопленной во всей сети относительно первичного сервера времени. И в заключении, корневое расстояние синхронизации определяется следующим выражением:
Λ = Ε + Δ / 2
и представляет собой максимальное значение ошибки в следствие всех возможных нештатных или иных событий в сети.
11.3. Процедура (алгоритм) корректировки (настройки) времени (часов)
В NTPv4-протоколе процедура (алгоритм) корректировки (настройки) времени (часов) несколько упрощена, а именно это касается одновременного использования двух принципиально различных систем управления с обратной связью (СУОС). В СУОС с фазовой автоподстройкой частоты (ФАПЧ) периодически с интервалом μ секунд происходит обновление значения фазы, которое напрямую используется для минимизации ошибки времени, а косвенно — ошибки частоты. В СУОС с частотной автоподстройкой частоты (ЧАПЧ) периодически с интервалом μ секунд происходит обновление значения частоты, которое напрямую используется для минимизации ошибки частоты, а косвенно — ошибки времени. Системы с ФАПЧ обычно более эффективны, когда преобладает сетевой джиттер, в то время как системы с ЧАПЧ более эффективны, когда преобладает отклонение частоты генератора.
θr
+ +---------\ +----------------+
NTP --------->| Фазовый \ Vd
| | Vs
θc
- | детектор ------>| Фильтр времени |----+
+-------->| / | | |
| +---------/ +----------------+ |
| |
----------- |
/ Генератор \ |
| частоты | |
\ / |
----------- ....................................... |
^ . Фильтр с управляющей обратной связью. |
| . +---------+ x +-------------+ . |
| Vс
. | Коррек- |<-----| | . |
+------.-| тировка | y | Предсказание|<---------+
. | времени |<-----| фазы/частоты| .
. | | | | .
. +---------+ +-------------+ .
.......................................
Рис.23. Корректировка времени с помощью СУОС
Процедура корректировки времени основана на СУОС (рис.23). Переменная θr
представляет собой сдвиг, определённый с помощью процедуры (алгоритма) суммирования (фаза эталонного синхроисточника), переменная θс
— сдвиг, формируемый генератором частоты (управляющая фаза). При каждом обновлении данных вырабатывается сигнал Vd
, который представляет собой разность мгновенных значений фаз θr
- θс
. Фильтр времени для каждого анализируемого сервера времени функционирует как линия задержки с отводами, в которой алгоритм фильтра времени выбирает нужный отвод для съёма выходного сигнала. Процедуры (алгоритмы) селекции, кластеризации и суммирования анализируют данные, поступившие от нескольких фильтров, для выработки сигнала Vs
. Фильтр с управляющей обратной связью и импульсной характеристикой F(t)
вырабатывает сигнал Vc
, который управляет генератором частоты, формирующим выходной сигнал с частотой ωc
и окончательным значением фазы θс
, и, таким образом, замыкается цепь обратной связи. Сигнал Vc
генерируется процедурой корректировки времени.
Обычно, псевдолинейная СУОС, рассмотренная выше, выполняет функцию настройки системных часов. Однако, возможны случаи, когда использование нелинейного алгоритма приводит к значительному улучшению характеристик синхронизации. Одним из таких случаев является ситуация при которой, процедура корректировки времени начинается без какой-либо исходной информации о частоте встроенных часов. При использовании псевдолинейной СУОС необходимо несколько часов, чтобы достигнуть высокой точности измерения, и при этом в течении большей части этого периода времени невозможно увеличить интервал опроса. А при использовании нелинейной СУОС этот период времени уменьшается до 15 минут. Другим случаем является ситуация, при которой возникают случайные «всплески» (большие значения) джиттера в следствие сетевых перегрузок. Процедурная характеристика обеспечивает защиту от ошибок, вызванных такими «всплесками» джиттера, продолжающимися в течении менее, чем 15 минут.
На рис.24 представлены переменные (в нижнее регистре) и параметры (в верхнем регистре), используемые в процедуре корректировки времени.
Если не оговорено обратного, то тогда все переменные обозначаются префиксом с
. Переменные t
, tc
, state
, hyster
и count
являются целочисленными величинами, а остальные переменные имеют удвоенные значения с плавающей точкой.
Процедура настройки часов реализуется с помощью прикладного процесса local_clock()
, обращение к которому происходит при функционировании прикладного процесса clock_update()
. Прикладной процесс local_clock()
состоит из двух этапов:
- на первом этапе определяется состояние часов;
- на первом этапе определяется временная константа и, таким образом, интервал опроса.
| Наименование | Значение | Описание |
|---|---|---|
| t | таймер | Счётчик секунд |
| offset | Θ | Суммарный сдвиг времени |
| resid | Θr | Остаточный сдвиг времени |
| freq | φ | Частота генератора часов |
| jitter | ψ | Джиттер сдвига времени |
| wander | ω | Отклонение частоты генератора часов |
| tc | τ | Временная константа (log2 ) |
| state | state | Состояние |
| adj | adj | Корректировка частоты |
| hyster | hyster | Счётчик запаздывания фазы |
| STEPT | 125 | Пошаговое значение сдвига (0,125 сек) |
| WATCH | 900 | Предельное значение сдвига (сек) |
| PANICT | 1000 | Критическое пороговое значение сдвига (сек) |
| LIMIT | 30 | Предел запаздывания фазы |
| PGATE | 4 | Интервал запаздывании фазы |
| TC | 16 | Шкала временной константы |
| AVG | 8 | Постоянная усреднения |
| Рис.24. Параметры и переменные, используемые в процедуре корректировки времени | ||
Прикладной процесс local_clock()
немедленно прекращается, если сдвиг превышает критическое пороговое значение сдвига PANICT
(1000 сек). Функция перехода из одного состояния в другое реализуется с помощью прикладного процесса rstclock()
(рис.25). В представленной на рис.25 таблице имеются четыре колонки, в которых указываются наименование состояния, переход и процедуры, если сдвиг θ
меньше, чем значение STEP
, переход и процедуры, если сдвиг θ
больше, чем значение STEP
, и соответствующие комментарии и пояснения.
В данной таблице переход в другое состояние обозначен стрелкой ("⇒"), после чего приводятся последующие процедуры. Процедуры, такие как корректировка времени и корректировка частоты реализуются с помощью СУОС ФАПЧ/ЧАПЧ в течении прикладного процесса local_clock()
. Процедура ускоренной (пошаговой) корректировки времени реализуется напрямую, то есть с помощью непосредственного управляющего воздействия на часы, но такая корректировка осуществляется только тогда, когда сдвиг не превышает значение WATCH
(900 сек) и больше, чем пошаговое значение сдвига STEP
(0,125 сек). Такая процедура защищает нормальное функционирование часов в условиях экстремальной перегрузки сети.
Статистические переменные джиттер (ψ
) и отклонение (ω
) и вычисляются с помощью экспоненциального усреднения и весового коэффициента AVG
. Экспоненциальная временнáя константа (τ
) определяется путём сравнения значения ψ
с величиной текущего сдвига θ
. Если сдвиг в PGATE
(4) раз больше, чем джиттер часов, то тогда значение счётчика запаздывания фазы hyster
уменьшается на два, в противном случае — увеличивается на единицу. Если значение счётчика hyster
достигло верхнего предела LIMIT
(30), то тогда значение τ
увеличивается на единицу. Если же значение счётчика hyster
достигло нижнего предела -LIMIT
(-30), то тогда значение τ
уменьшается на единицу. Обычно значение τ
колеблется около значения параметра MAXPOLL
, но быстро уменьшается, если температурный всплеск вызвал большие колебания значения частоты.
| Состояние | θ > STEP | θ < STEP | Примечания |
|---|---|---|---|
| NSET | ⇒ FREQ корректировка времени |
⇒ FREQ пошаговая (ускоренная) корректировка времени |
Отсутствует файл со значением частоты |
| FSET | ⇒ SYNC корректировка времени |
⇒ SYNC пошаговая (ускоренная) корректировка времени |
Наличие файла созначением частоты |
| SPIK | ⇒ SYNC корректировка частоты корректировка времени |
if < 900 сек ⇒ SPIK else ⇒ SYNC пошаговая (ускоренная) корректировка частоты пошаговая (ускоренная) корректировка времени |
«Выбраковка» претендента |
| FREQ | if < 900 сек ⇒ FREQ else ⇒ SYNC пошаговая (ускоренная) корректировка частоты корректировка времени |
if < 900 сек ⇒ FREQ else ⇒ SYNC пошаговая (ускоренная) корректировка частоты корректировка времени |
Начальная частота |
| SYNC | ⇒ SYNC корректировка частоты корректировка времени |
if < 900 сек ⇒ SPIK else ⇒ SYNC пошаговая (ускоренная) корректировка частоты пошаговая (ускоренная) корректировка времени |
Нормальная процедура |
| Рис.25. Таблица переходов из одного состояния в другое | |||
12. Процедура корректировки (настройки) времени (часов)
Текущая корректировка времени (настройка часов) реализуется прикладным процессом clock_adjust()
. Такая корректировка происходит один раз в секунду и предусматривает прибавление к значению текущей частоты корректирующего значения, а также фиксированной доли (в процентах) остаточного значения сдвига θr
. Величина θr
, по своей сути, является экспоненциальным показателем затухания значения θ
, обеспечиваемого фильтром с СУОС при каждом обновлении данных синхронизации. Параметр ТС
масштабирует временнỳю константу для удобного сравнения её с интервалом опроса.
Замечание. Дисперсия Ε
возрастает каждую секунду на значение Φ
.
Процедура корректировки времени включает субпроцедуру прерывания таймера для управления счётчиком секунд c.t
. Последний имеет нулевое значение при запуске NTPv4-службы времени, и затем увеличивается на единицу каждую секунду. Во время каждого прерывания происходит обращение к прикладному процессу clock_adjust()
с целью проведения настройки часов с одновременной корректировкой времени и частоты. Затем проверяются все виртуальные соединения с целью определения является ли значение счётчика секунд равным или превышает значение переменной состояния p.next
. Если так, то тогда происходит обращение в прикладному процессу опроса удалённых серверов времени с целью передачи NTPv4-сообщения и вычисления следующего значения p.next
.
13. Процедура опроса
Каждое виртуальное соединение обеспечивает процедуру опроса, которая проводится регулярно через определённый интервал времени с целью формирования и передачи NTPv4-сообщений для различных режимов функционирования виртуальных соединений (симметричном, клиентском и широковещательном сервера). Процедура опроса осуществляется непрерывно, независимо от того являются ли удалённые серверы времени достижимыми или нет. Непрерывность процедуры необходимо для управления фильтром времени и регистром достижимости.
13.1. Переменные процедуры опроса
На рис.26 представлены переменные (в нижнее регистре) и параметры (в верхнем регистре), используемые в процедуре опроса. Если не оговорено обратного, то тогда все переменные обозначаются префиксом p
.
| Наименование | Значение | Описание |
|---|---|---|
| hpoll | hpoll | Экспоненциальное значение времени опроса сервера |
| last | last | Время последнего опроса |
| next | next | Время следующего опроса |
| reach | reach | Регистр достижимости |
| unreach | unreach | Счетчик недостижимых серверов времени |
| UNREACH | 24 | Предельное значение недостижимых серверов |
| BCOUNT | 8 | Количество последовательно передаваемых сообщений |
| BURST | flag | Согласие на восстановление соединения |
| IBURST | flag | Запрос на восстановление соединения |
| Рис.26. Параметры и переменные, используемые в процедуре опроса | ||
Значения переменных опроса передаются с помощью NTPv4-сообщений вместе со значениями переменных обрабатываемых удалённым сервером в период сеанса связи (сессии). Переменные, используемые в процедуре опроса, имеют следующую кодировку:
hpollЗнаковое целое число, представляющее собой экспоненциальное значение, то есть log2 в секундах.
lastЦелое число, представляющее собой значение счётчика секунд с момента передачи самого последнего NTPv4-сообщения.
nextЦелое число, представляющее собой значение счётчика секунд до момента передачи следующего NTPv4-сообщения.
reach8-битовое целое число, определяемое регистром сдвига, который используется совместно процедурой опроса и процедурой удалённого сервера.
unreachЦелое число, представляющее собой количество секунд, прошедших с момента, когда удалённый сервер времени стал недостижимым.
13.2. Процессы (операции) процедуры опроса
Как было указано ранее, каждую секунду в период процедуры корректировки времени происходит обращение к прикладному процессу clock_adjust()
. Этот процесс обращается к другому прикладному процессу poll()
при каждом очередном информационном взаимодействии по конкретному виртуальному соединению. Если время отправки очередного запрашивающего NTPv4-сообщения превысило значение счётчика секунд, то тогда прикладной процесс передаёт такое сообщение незамедлительно. В период функционирования виртуальных соединений в симметричном режиме (режимы 1, 2), в клиентском режиме (режим 3) и в широковещательном режиме сервера (режим 5) регулярно передаются полнофункциональные NTPv4-сообщения, содержащие все требуемые переменные и параметры. В широковещательном режиме клиента (режим 6) полнофункциональные NTPv4-сообщения не передаются, а передаются специализированные NTPv4-сообщения, содержащие только переменные достижимости удалённых серверов времени. Прикладной процесс poll()
, в свою очередь, обращается к процессу peer_xmit()
с целью передачи NTPv4-сообщения. Если флаг BURST
установлен (имеет значение 1
), то тогда никаких последующих операций не проводится, за исключением обращения к прикладному процессу poll_update()
с целью установки значения интервала следующего опроса. Если же флаг BURST
не установлен (равен 0
), то тогда значение переменной достижимости сдвигается влево на один бит, а крайний правый бит обнуляется. Если удалённый сервер времени не был обнаружен в течении последних трёх интервалов опроса, то тогда происходит обращение к прикладному процессу clock_filter()
с целью увеличения значения дисперсии.
Если флаг BURST
установлен, а сервер достижим и может выступать в роли корректного источника синхронизации, то тогда клиентский NTPv4-модуль передает последовательность из восьми (BCOUNT
= 8) NTPv4-сообщений в течение каждого интервала опроса. Интервал между поочерёдной передачей NTPv4-сообщений составляет две секунды. Если флаг IBURST
установлен, а это означает, что это переданное сервером NTPv4-сообщение является первым, причём этот удаленный сервер считался недостижимым, то тогда клиентский NTPv4-модуль передает NTPv4-сообщение с установленным флагом BURST
. Такая операция обмена флагами весьма полезна для ускоренного уменьшения расстояния синхронизации ниже предельного значения и быстрой синхронизации часов.
Если в поле p.flags
(«Флаги опроса») флаг P_MANY
установлен, то такое соединение функционирует многоадресного клиентского соединения. Многоадресные клиентские соединения обеспечивают передачу NTPv4-сообщений в режиме клиента, которые размещаются в IP-пакетах с групповыми адресами, в течении временных интервалов со значением MINPOLL
(минимальное экспоненциальное значение интервала опроса). Виртуальное соединение инициализируется со значения TTL
, равного единице. Если к моменту времени следующего опроса число удалённых серверов, с которыми установлены виртуальные соединения, окажется меньше значения MINCLOCK
, то тогда значение TTL
увеличивается на единицу. Если значение TTL
достигает своего предельного максимального значения TTLMAX
и при этом не найдя минимально необходимое число MINCLOCK
удалённых серверов времени, то тогда интервал опроса будет увеличиваться до тех пор, пока он не достигнет предельного значения BEACON
, а при достижении этого значения процедура опроса стартует с начала.
Прикладной процесс poll()
обладает специфическим свойством, а именно он возвращает значение интервала опроса в первоначальное, если удалённый сервер времени становится недостижимым. Если значение регистра достижимости reach
не нулевое, то тогда сервер считается достижимым, а счётчик недостижимых серверов unreach
устанавливается в нулевое значение. В противном случае, значение счётчика unreach
увеличивается на единицу, причём это увеличение происходит при каждом опросе до максимального значения UNREACH
. С этого момента при каждом опросе значение hpoll
увеличивается на единицу, что означает удвоение интервала опроса до максимального значения MAXPOLL
, которое определяется прикладным процессом poll_update()
. Когда удалённый сервер времени вновь становится достижимым, то тогда значение счётчика unreach
устанавливается в нулевое значение, значение hpoll
переустанавливается в значение системной переменной tc
, а процесс синхронизации начинает функционировать нормально.
Прикладной процесс xmit_packet()
обеспечивает передачу NTPv4-сообщения. Некоторые значения переменных в заголовке нового NTPv4-сообщения копируются из результатов функционирования процедур удалённого сервера, которые содержались в предшествующем сообщении, а другие — из системных переменных. На рис.27 представлены значения переменных, которые отображаются в каждом поле заголовка NTPv4-сообщения.
| Переменные заголовка | ⇐ | Переменные |
|---|---|---|
| x.leap | ⇐ | s.leap |
| x.version | ⇐ | s.version |
| x.mode | ⇐ | s.mode |
| x.stratum | ⇐ | s.stratum |
| x.poll | ⇐ | s.poll |
| x.precision | ⇐ | s.precision |
| x.rootdelay | ⇐ | s.rootdelay |
| x.rootdisp | ⇐ | s.rootdisp |
| x.refid | ⇐ | s.refid |
| x.reftime | ⇐ | s.reftime |
| x.org | ⇐ | p.xmt |
| x.rec | ⇐ | p.dst |
| x.xmt | ⇐ | clock |
| x.keyid | ⇐ | p.keyid |
| x.digest | ⇐ | md5 digest |
| Рис.27. Содержание заголовка передаваемого NTPv4-сообщения "xmit_packet" | ||
В тех прикладных программных реализациях, в которых для обозначения корневой задержки и корневой дисперсии используется удвоенный тип данных с плавающей точкой, необходимо производить конвертирование этих переменных в укороченный NTP-формат. Все другие поля, либо копируются без изменений с системных переменных и переменных, обрабатываемых в удалённом сервере, либо в них проставляются метки времени с использованием системных часов. Обращение к прикладному процессу poll_update()
происходит после получения корректного NTPv4-сообщения и сразу же после того, как было передано NTPv4-сообщение об опросе. Если флаг IBURST
установлен, то тогда интервал опроса является фиксированным и равным 2 секундам. В противном случае, экспоненциальному значению интервала опроса сервера hpoll
присваивается наименьшее значение среди: ppoll
, изъятого из последнего принятого NTPv4-сообщения, или hpoll
, сформированного прикладным процессом poll()
, но это значение не должно быть меньше значения MINPOLL
и больше значения MAXPOLL
. Таким образом, процедура корректировки времени может быть полностью основана на выборках, но не может быть полностью зависима от них. Этот принцип позволяет сохранить динамическое поведение подсети синхронизации и защитить её от протокольных ошибок.
Экспоненциальное значение интервала опроса преобразуется в обычное значение интервала, которое после прибавления самого последнего значения переменной определяет следующую переменную, то есть время следующего интервала опроса. И в заключении, самое последнее значение переменной записывается в текущем счётчике секунд.
14. Простой протокол сетевого времени (SNTP)
Первичные серверы и клиенты, взаимодействующие с NTPv4-подсетью синхронизации, функционируют в соответствие с простым протоколом сетевого времени (Simple Network Time Protocol — SNTPv4, RFC-4330), который не предусматривает использование рассмотренных выше алгоритмов (процедур) оптимизации (рис.28). SNTPv4-протокол предназначен для первичных серверов времени, оснащенных только одними эталонными часами, а также для клиентов, обслуживаемых одним сервером времени (поток пользователь-сервер, upstream), и независимых клиентов. Полнофункциональный программный NTPv4-модуль предназначен для вторичных серверов времени, взаимодействующих с несколькими клиентскими серверами (потоки пользователь-сервер, upstream), а также с несколькими прикладными серверами (потоки сервер-пользователь, downstream) или клиентами. В других случаях, отличающихся от указанных, программные NTPv4-модули и SNTPv4-модули, а также клиентские NTP/SNTPv4-модули полностью функционально совместимы и могут встречаться в любых NTP-подсетях синхронизации.
Рис.28. Иерархия, структура и топология системы сетевого времени на основе SNTP-протокола
Первичный SNTPv4-сервер, реализующий процедурную характеристику, представленную в разделе 8, не взаимодействует с другими серверами (то есть в режиме пользователь-сервер, upstream), за исключением одиночных эталонных часов (сервер, включающий только эталонный источник времени). В принципе, он не отличается от первичного NTPv4-сервера, который реализует алгоритмы оптимизации и, более того, способен «уравновешивать» значения нескольких эталонных источников времени.
После получения SNTPv4-запроса клиента, первичный SNTPv4-сервер (программный SNTPv4-модуль сервера) формирует и передаёт ответное SNTPv4-сообщение, содержащее значения переменных, которые представлены на рис.29.
Замечание. Поле «Дисперсия» в заголовке SNTPv4-сообщения должно обновляться таким же образом, как это представлено в разделе 5.
| Переменные заголовка | ⇐ | Переменные |
|---|---|---|
| x.leap | ⇐ | s.leap |
| x.version | ⇐ | r.version |
| x.mode | ⇐ | 4 |
| x.stratum | ⇐ | s.stratum |
| x.poll | ⇐ | r.poll |
| x.precision | ⇐ | s.precision |
| x.rootdelay | ⇐ | s.rootdelay |
| x.rootdisp | ⇐ | s.rootdisp |
| x.refid | ⇐ | s.refid |
| x.reftime | ⇐ | s.reftime |
| x.org | ⇐ | r.xmt |
| x.rec | ⇐ | r.dst |
| x.xmt | ⇐ | clock |
| x.keyid | ⇐ | r.keyid |
| x.digest | ⇐ | md5 digest |
| Рис.29. Содержание заголовка передаваемого NTPv4-сообщения "fast_xmit" | ||
Программный SNTPv4-модуль клиента, реализующий процедурную характеристику, представленную в разделе 8, размещается в одиночном сервере времени, обслуживающем несколько клиентов, и в персональных компьютерах независимых клиентов. Он может взаимодействовать с любой NTP-подсетью синхронизации в соответствии с процедурной и логической характеристиками NTP-протокола, но по упрощенной процедуре с использованием только поля «Метка времени сервера при отправке NTP-ответа клиенту» в ответном SNTPv4-сообщении сервера и игнорированием всех других полей. Однако, дополнительное усложнение программного SNTPv4-модуля и, таким образом, доведение его до полнофункционального NTPv4-модуля (процедурная и логическая характеристики) является минимальным, и поэтому целесообразно применять полнофункциональный программный NTPv4-модуль.
15. Проблемы обеспечения безопасности
NTPv4-протокол предусматривает использование дополнительной функции аутентификации (специальное поле «Authentication»), которая основана на применении MD5-алгоритма вычисления хэш-функции. Однако, в 2004 году последний был скомпрометирован и его стойкость была существенно понижена, что делает этот алгоритм крайне не эффективным[?] .
В случае реализации NTPv4-протокола, как представлено в данном стандарте, широковещательные NTPv4-клиенты являются уязвимыми к нарушениям, вызываемых некорректным поведением расположенными в Internet-сети широковещательными SNTP/NTP-серверами, среди которых могут быть и серверы нарушителей. В таких случаях целесообразно использовать дополнительные средства обеспечения безопасности, среди которых основными являются управление доступом и аутентификация на основе криптоалгоритмов.
В разделе 8 рассматриваются способы защиты от атак типа «Повторная передача NTPv4-сообщений».
16. Вопросы, решаемые IANA
Для NTP-протокола был утвержден транспортный порт (UDP/TCP) под номером 123
. IANA назначила для NTP-протокола два IP-адреса: 224.0.1.1
для IPv4-адресации и :101
окончание для IPv6-адресации.
17. Благодарности
The editors would like to thank Karen O'Donoghue, Brian Haberman, Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant, and Danny Mayer for technical reviews and specific text contributions to this document.
18. Ссылки
18.1. Нормативные документы
| [RFC-768] | Postel, J., «Протокол датаграмм клиента (UDP)», RFC 768, STD 6, Август 1980. |
| [RFC-791] | Postel, J., «Протокол IP (Internet Protocol)», RFC 791, STD 5, Сентябрь 1981. |
| [RFC-793] | Postel, J., «Протокол управления передачей (TCP)», RFC 793, STD 7, Сентябрь 1981. |
| [RFC-1321] | Rivest, R., «Алгоритм цифровых подписей MD5», RFC 1321, Апрель 1992. |
| [RFC-2119] | Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, BCP 14, Март 1997. |
18.2. Дополнительная литература
| [CGPM] | Bureau International des Poids et Mesures, «Comptes Rendus de la 15e CGPM», 1976. |
| [ITU-R_TF.460] | International Telecommunications Union, «ITU-R TF.460 Standard-frequency and time-signal emissions», Февраль 2002. |
| [RFC-1305] | Mills, D., «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, Март 1992. |
| [RFC-1345] | Simonsen, K., «Character Mnemonics and Character Sets», RFC 1345, Июнь 1992. |
| [RFC-4330] | Mills, D., «Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI», RFC 4330, Январь 2006. |
| [RFC-5226] | Narten, T. и H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, Май 2008. |
| [RFC-5906] | Haberman, B., Ed. и D. Mills, «Network Time Protocol Version 4: Autokey Specification», RFC 5906, Июнь 2010. |
| [ref6] | Marzullo and S. Owicki, «Maintaining the time in a distributed system», ACM Operating Systems Review 19, Июль 1985. |
| [ref7] | Mills, D.L., «Computer Network Time Synchronization — the Network Time Protocol», CRC Press, 304 pp, 2006. |
| [ref9] | Mills, D.L., Electrical and Computer Engineering Technical Report 06-6-1, NDSS, Июнь 2006, «Network Time Protocol Version 4 Reference and Implementation Guide», 2006. |