4.4.16 Протокол SNTP

Протокол SNTP V 4 отличается от предыдущей версии NTP и SNTP (Simple Network Time Protocol (SNTP) V.4 for IPv4, IPv6 and OSI, D. Mills, RFC-2030) модификацией интерпретации заголовка с целью осуществления совместимости адресации с IPv6 [DEE96] и OSI [COL94].

Протокол сетевого времени (NTP v3), описанный в документе RFC-1305 [MIL92], широко используется для синхронизации часов ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным системам точного времени. В большинстве мест Интернет протокол гарантирует точность синхронизации с точностью 1-50 мс, в зависимости от свойств источника синхронизации и сетевых задержек.

RFC-1305 специфицирует машину протокола NTP v3 в терминах событий, состояний, функций перехода и действий. Кроме того, там определены инженерные алгоритмы улучшения точности синхронизации и выбора из списка эталонных источников, некоторые из которых могут быть неисправны. Эти алгоритмы необходимы для компенсации влияния вариаций задержки пакетов в сети Интернет. Однако, во многих обстоятельствах приемлемы точности порядка доли секунды. В таких случаях используется более простые протоколы времени [POS83]. Эти протоколы обычно использует RPC-обмен, где клиент запрашивает время дня, а сервер присылает его значение в секундах после некоторого известного эталонного момента.

NTP создан для использования клиентами и серверами с широким диапазоном возможностей для широкого интервала сетевых задержек и большого временного разброса. Большинство пользователей NTP синхронизации используют программное обеспечение с полным набором опций и алгоритмов (смотри http://www.eecis.udel.edu/~ntp).

SNTP v 4 предполагает совместимость с NTP и SNTP v 3 как для клиентов так и для серверов. Кроме того, клиенты и серверы SNTP v.4 могут реализовывать расширения для работы в эникаст режиме.

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

SNTP v.4 может работать в уникастном (точка-точка), мультикастном (один передатчик – много приемников) или эникаст (несколько передатчиков - один приемник). Уникастный клиент посылает запросы специально выделенному серверу по его уникастному адресу и ожидает отклика, из которого он может определить время и опционно RTT, а также сдвижку временной шкалы местных часов по отношению к шкале сервера. Мультикастный сервер периодически посылает сообщения по локальному мультикаст-адресу (IPv4 или IPv6). Мультикастный клиент воспринимает получаемые данные и не посылает никаких запросов. Эникастный клиент посылает запрос по локальному специально выделенному мультикастному (IPv4 или IPv6) адресу, при этом один или более эникатных серверов отправляют клиенту отклик. Клиент связывается с первым из них и в дальнейшем продолжает работу уже в уникастном режиме адресации.

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

В уникастном режиме адреса клиенту и серверу присваиваются согласно обычной схеме IPv4, IPv6 или OSI. В мультикастном режиме сервер использует локальный широковещательный адрес или мультикастный групповой адрес. Локальный широковещательный IP-адрес имеет область действия, ограниченную субсетью, так как маршрутизаторы не ретранслируют широковещательные IP-дейтограммы. С другой стороны IP-адрес мультикастинг-группы имеет область действия, распространяющуюся потенциально на весь Интернет. Для IPv4 iana для целей NTP выделила мультикастный групповой адрес 224.0.1.1, который используется как для мультикаст серверов, так и для эникаст клиентов.

Мультикастные клиенты прослушивают выделенный локальный широковещательный адрес или мультикастный групповой адрес. В случае мультикастного IP-адреса, мультикастный клиент и эникастный сервер должны реализовать протокол IGMP (Internet Group Management Protocol) [DEE89], для того чтобы местный маршрутизатор подключился к мультикаст-группе и ретранслировал сообщения, направленные по IPv4 или IPv6 мультикастным групповым адресам, присвоенным IANA.

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

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

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

Протокол SNTP использует стандартный формат временных меток NTP, описанный в документе RFC-1305 и в предыдущих версиях стандарта. Для согласования со стандартной практикой в Интернет данные NTP характеризуются целыми числами с фиксированной запятой. Биты нумеруются так, что нулевой (старший) разряд размещается слева. Если не оговорено обратного, все числа не имеют знака и занимают все выделенное для них поле.

Так как временная метка NTP представляет собой наиважнейшую часть протокола, для нее разработан специальный формат. Временные метки NTP характеризуются 64-битным числом без знака с фиксированной запятой, которое равно количеству секунд с 0 часов 1 января 1900. Для целочисленной части выделено 32 бита и столько же для дробной части.

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

Максимальное число, которое может быть представлено в данном формате равно 4,294,967,295 секунд с точностью порядка 200 пикосекунд, что может удовлетворить самым экзотическим требованиям.

Рис. 4.4.16.1. Формат представления временной метки

Заметим что с некоторого времени в 1968 (2,147,483,648 секунда) старший бит (бит 0 целочисленной части) стал равным 1 и 64-битовое поле переполнится в 2036 году. Если NTP или SNTP будут использоваться в 2036 г, будут необходимы некоторые внешние по отношению к данному протоколу меры для определения того относительно 1900 или 2036 года отсчитана приведенная дата (это справедливо и для других дат, кратных 136 годам).

Так как формат временных меток NTP использовался в течение последних 17 лет, остается возможность того, что он будет использоваться еще 40 лет. Так как временных меток NTP до 1968 не существует, можно считать приемлемым, что при бите 0 равном 1, UTC-время лежит в диапазоне 1968-2036 с началом отсчета 0 час. 0 мин. 0 сек. 1 января 1900 г. Если же бит 0 равен нулю, время лежит в диапазоне 2036-2104 г., а UTC-время отсчитывается от 6 час. 28 мин. 16 сек. 7 февраля 2036. Заметим, что при этом вычислении 2000 год не считался високосным.

Протоколы NTP и SNTP используют в качестве транспортного протокол UDP. При этом работает UDP-порт 123 (NTP), который проставляется как в поле порта отправителя, так и получателя UDP-заголовка.

Ниже приводится описание формата сообщений NTP/SNTP v.4, которые размещаются после UDP-заголовка. Этот формат идентичен описанному в RFC-1305, за исключением содержимого поля идентификатора эталона (reference identifier). Поля заголовка представлены на рис. 4.4.16.2:

Поле LI (Leap Indicator) содержит два бита кода предупреждения о добавлении/удалении секунды в последней минуте текущего дня. Значения кодов поля LI приведены в таблице 4.4.16.1:

LI	Величина	Значение
00	0	предупреждения нет
01	1	последняя минута содержит 61 секунду
10	2	последняя минута содержит 59 секунд
11	3	аварийный сигнал (часы не синхронизованы)

Поле VN (Version Number – номер версии) имеет длину три бита и содержит номер версии протокола NTP/SNTP. Это поле содержит 3 для V.3 (только IPv4) и 4 для V.4 (IPv4, IPv6 и OSI).

Поле режим также содержит три бита и указывает на код режима. Значения кодов режима представлены в таблице 4.4.16.2.

Режим	Значение
0	зарезервировано
1	симметричный активный
2	симметричный пассивный
3	клиент
4	сервер
5	широковещательный
6	для управляющих сообщений NTP
7	зарезервировано для частного использования

В уникастном и эникастном режиме клиент при запросе устанавливает это поле равным 3 (клиент), а сервер в отклике устанавливает его равным 4. В мультикастном режиме сервер записывает в данное поле код 5 (широковещательный).

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

Таблица 4.4.16.3. Значения кодов поля слой (stratum)

Поле интервал запросов (Poll Interval - регистрация) содержит 8 бит и указывает на максимальный интервал между последовательными сообщениями. Код (k) характеризует показатель степени 2. Интервал между запросами равен 2^k секунд. Значения, которые могут появиться в этом поле лежат в диапазоне от 4 (16 сек) до 14 (16284 сек); однако большинство приложений использует субдиапазон от 6 (64 сек.) до 10 (1024 сек).

Поле точность содержит 8 бит и характеризует точность локальных часов, в секундах (показатель степени 2, как и в предыдущем поле). Значения кодов в этом поле лежат в диапазоне -6 для частоты сети переменного тока до -20 для микросекундных часов.

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

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

Поле идентификатор эталона представляет собой 32-битовую строку, которая позволяет однозначно идентифицировать эталон времени. В случае первичных серверов (слой 0 или 1) NTP V.3 или V.4, идентификатор представляет собой четырех символьную ASCII-строку, размещенную в левой части поля. Свободная часть поля заполняется нулями. Для вторичных серверов NTP V.3, идентификатор равен 32-битовому адресу эталонного источника (IPv4). Для вторичных серверов NTP V.4, в качестве идентификатора используются младшие 32 бита последней временной метки эталонного источника. Первичные серверы NTP (слой 1) должны заносить в это поле коды, идентифицирующие внешние эталоны согласно таблице 4.4.16.4. Если код в таблице отсутствует, допускаются и другие коды.

ID-код	Внешний эталонный источник
LOCL	В качестве первичного эталона для субсети используются некалиброванные внутренние часы, которые не имеют внешнего источника синхронизации
PPS	Атомные часы или другой источник, выдающий импульс каждую секунду и индивидуально калиброванный с использованием национального стандарта времени
ACTS	Модемная служба NIST (работает через коммутируемую телефонную сеть)
USNO	Модемная служба USNO
PTB	Модемная служба PTB (Германия)
TDF	Радио 164 кГц (Allouis Франция)
DCF	Радио 77.5 кГц (Mainflingen, Германия)
MSF	Радио 60 кГц (Rugby, Англия)
WWV	Радио 2.5, 5, 10, 15, 20 МГц (Ft. Collins, США)
WWVB	Радио 60 кГц (Boulder, US)
WWVH	Радио 2.5, 5, 10, 15 МГц (Кауи Гавайи, США)
CHU	Радио 3330, 7335, 14670 кГц (Оттава, Канада)
LORC	Радионавигационная система LORAN-C
OMEG	Радионавигационная система OMEGA
GPS	Глобальная служба определения местоположения
GOES	Геостационарный спутник контроля за окружающей средой

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

Поле Originate Timestamp (исходная временная метка) соответствует времени, когда клиент направил запрос серверу (64-битовый формат временной метки).

Поле Receive Timestamp характеризует время, когда запрос пришел на сервер (64-битовый формат временной метки).

Поле Transmit Timestamp соответствует времени, когда сервер послал отклик клиенту (64-битовый формат временной метки).

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

Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code).

Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.

Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp. В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.

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

Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.

Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток.

Имя временной метки	ID	Когда генерируется
Originate Timestamp (исходная метка)	T1	Время отправки запроса клиента
Receive Timestamp (метка получения)	T2	Время получения запроса сервером
Transmit Timestamp (метка посылки)	T3	Время посылки отклика сервером
Destination Timestamp (метка назначения)	T4	Время получения отклика клиентом

Циклическая (roundtrip) задержка d и смещение локальных часов t определяются как:

В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы “Отклик” и “Мультикаст”. Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой “Игнорируется”, зависит от конкретной реализации программы.

Таблица 4.4.16.6. Операции клиента и значения полей заголовка

Имя поля	Уникаст/Эникаст		Мультикаст
Имя поля	Запрос	Отклик	Мультикаст
LI	0	0-2	0-2
VN (номер версии)	1-4	копируется из запроса	1-4
Режим	3	4	5
Слой	0	1-14	1-14
Запрос	0	Игнорируется	Игнорируется
Точность	0	Игнорируется	Игнорируется
Root Delay	0	Игнорируется	Игнорируется
Root Dispersion	0	Игнорируется	Игнорируется
Reference Identifier	0	Игнорируется	Игнорируется
Reference Timestamp	0	Игнорируется	Игнорируется
Originate Timestamp	0	(смотри текст)	Игнорируется
Receive Timestamp	0	(смотри текст)	Игнорируется
Transmit Timestamp	(смотри текст)	не равно нулю	не равно нулю
Аутентификатор	опционно	опционно	опционно

Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.

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

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

Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой – 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.

Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса. В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.

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

Исходная конфигурация SNTP серверов и клиентов может быть произведена на основе конфигурационного файла, если такой файл имеется, или через последовательный порт. Предполагается, что SNTP серверы и клиенты практически не требуют какого-то конфигурирования, специфического для данного узла (помимо IP-адреса, маски субсети или адреса OSI NSAP).

Уникастные клиенты должны быть снабжены именем сервера или его адресом. Если используется имя сервера, то необходим один или несколько адресов ближайших DNS-серверов. Мультикастные серверы и эникастные клиенты должны снабжаться значением TTL, а также местным широковещательным или групповым мультикастным адресом. Эникастные серверы и мультикастные клиенты могут конфигурироваться с привлечением списков пар адрес-маска. Это обеспечивает контроль доступа, так что операции будут производиться только с известными клиентами или серверами. Эти серверы и клиенты должны поддерживать протокол IGMP, а также знать местный широковещательный или групповой мультикастный адрес.

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

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

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