4.4.16. Протокол SNTP

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Протокол 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].

1. Введение

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

2. Рабочие режимы и адресация

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.

3. Формат временных меток NTP

Протокол 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 год не считался високосным.

4. Формат сообщений NTP

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

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

Рис. 4.4.16.2. Формат заголовка SNTP-пакета

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

Таблица 4.4.16.1 Значения кодов поля LI

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

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

Таблица 4.4.16.2. Значение кодов поля режим

В уникастном и эникастном режиме клиент при запросе устанавливает это поле равным 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. Если код в таблице отсутствует, допускаются и другие коды.

Таблица 4.4.16.4. Коды идентификатора эталона

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

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

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

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

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

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

5. Операции клиента SNTP

Клиент 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 типа временных меток.

Таблица 4.4.16.5. Типы временных меток

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

d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.

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

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

6. Операции сервера SNTP

Сервер 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 представлены все перечисленные операции.

Таблица 4.4.16.7

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

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

7. Конфигурация и управление

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

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

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

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

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

8. Ссылки

[COL94]	Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
[DAR81]	Postel, J., "Internet Protocol", STD 5, RFC 791, USC Information Sciences Institute, September 1981.
[DEE89]	Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[DEE96]	Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox and Ipsilon, January 1996.
[DOB91]	Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, Open Software Foundation, June 1991.
[EAS95]	Eastlake, D., 3rd., and C. Kaufman, "Domain Name System Security Extensions", Work in Progress.
[FUR94]	Furniss, P., "Octet sequences for upper-layer OSI to support basic communications applications", RFC 1698, Consultant, October 1994.
[HIN96]	Hinden, R., and S. Deering, "IP Version 6 addressing Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
[ISO86]	International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.
[MIL92]	Mills, D., "Network Time Protocol (V.3) specification, implementation and analysis", RFC 1305, University of Delaware, March 1992.
[PAR93]	Partridge, C., T. Mendez and W. Milliken, "Host anycasting service", RFC 1546, Bolt Beranek Newman, November 1993.
[POS80]	Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC Information Sciences Institute, August 1980.
[POS83]	Postel, J., "Time Protocol", STD 26, RFC 868, USC Information Sciences Institute, May 1983.

Назад: 4.4.15. Сетевой протокол времени NTP
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.17. Введение в MPLS, TE и QoS