Добавил:
Да поможет вам Котельников Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
20
Добавлен:
23.06.2024
Размер:
15.29 Mб
Скачать

Механизмы передачи

Режим Unicast

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

Режим Broadcast

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

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

Режим Multicast

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

Режим Manycast

Этот режим является нововведением последней версии (v4) протокола NTP. Режим Manycast функционирует как режим Multicast только с неизвестными IP-адресами серверов NTP. Путем рассылки Multicast-сообщений клиент ищет в сети Manycast- сервера, получает от каждого из них образцы времени и производит выбор трех «лучших», с которыми будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

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

Типовая схема системы синхронизации и ее недостатки

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

PTP (Precision Time protocol)

Для систем, которым не хватает точности синхронизации, предоставляемой протоколами NTP/SNTP, был разработан стандарт IEEE 1588 (IEEE 1588-2019) Протокол точного времени - https://ru.qaz.wiki/wiki/Precision_Time_Protocol

. Данный стандарт описывает протокол точного времени - PTP (Precision Time protocol). PTP предназначен для использования в сетях связи и гарантирует высокую точность синхронизации.

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

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

Версии PTP

Протокол PTP был изначально описан в 2002 году

в стандарте IEEE 1588-2002 и имел название «Standard for a Precision Clock Synchronization Protocol for Networked

Measurement and Control Systems». В 2008 году был выпущен обновленный стандарт IEEE 1588-2008, который описывает PTP Version 2. В этой версии протокола была улучшена точность и стабильность, но не была сохранена обратная совместимость с первой версией протокола. Также, в 2019 году вышла версия стандарта IEEE 1588-2019, описывающая PTP v2.1. Эта версия добавляет небольшие улучшения

к PTPv2 и является обратно совместимой с PTPv2.

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

Гроссмейстерские часы (Grandmaster) – основные часы, по которым синхронизируется время в системе

Ведущие часы (Master) – часы, которые выступают в качестве источников точного времени для конечных устройств

Ведомые часы (Slave)– конечные устройства, на которых необходимо осуществить синхронизацию времени по протоколу PTP

Граничные часы (Boundary Clock)– сетевое оборудование (коммутаторы), которое будет выступать в качестве ведомого устройства для гроссмейстерских часов, и источником точного времени для конечных устройств. При этом коммутаторы также должны поддерживать РТР

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

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

Event Messages

General Messages

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

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

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

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

Фаза 1 — установка иерархии «Ведущие часы — Ведомые часы».

Фаза 2 — синхронизация часов при помощи механизма End-to-End или Peer- to-Peer.

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

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

В программировании такой алгоритм называется конечным автоматом или машиной состояний (подробнее в Wiki).

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

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

Соседние файлы в папке Специализированные ЦСП и ОСП