PTP – Precision Time Protocol (IEEE 1588 standard)

Wstęp

Akronim PTP oznacza Precision Time Protocol i jest to protokół sieciowy synchronizacji zegarów komputerów na poziomie systemu operacyjnego Windows/Linux/Unix.

Rys. Dataflow PTP (Precision Time Protocol) synchronizującego zegary PC

Działanie protokołu polega na wymianie wiadomości (message) siecią Ethernet TCP/IP między poszczególnymi komputerami (PC) na poziomie systemu operacyjnego (OS). Synchronizowane są zegary programowe poziomu OS, z ewentualnym zapisem wskazań do sprzętu PC odpowiedzialnego za podtrzymanie czasu podczas gdy komputer pozostaje wyłączony.

W roku 2015 ustanowiono dwa standardy protokołu:

IEEE 1588 v1 => z roku 2002, określany nazwą IEEE 1588:2002
IEEE 1588 v2 => z roku 2008, określany nazwą IEEE 1588:2008, niezgodny z v1

a w roku 2020 rozszerzono go o standaryzację protokołu White Rabbit:

IEEE 1588 v2.1 => z roku 2019, określany nazwą IEEE 1588:2019

Lata 2002, 2008, 2019 przypominają rok przygotowania RFC standaryzacji, podczas gdy rzeczywiste istnienie poszczególnych wersji protokołu jest znacznie starsze. Np. protokóół White Rabbit (WR) istniał w laboratorium polskiej Elpromy już w 2010 roku.

Właściwości protokołu PTP:

W przeciwieństwie do NTP używającego jednej skali UTC, protokół PTP transportuje skalę UTC w formie 2-ch składowych: TAI + liczba sekund przestępnych. Umożliwia też transport dowolnych skal czasu ARB, również zdefiniowanych przez użytkownika
Protokół PTP działa wyłącznie w sieciach lokalnych LAN i nie może być bezpośrednio używany w sieciach rozległy WAN oraz nie może działać poprzez Internet.
Został zaprojektowany dla zastosowań przemysłowych. Jest używany do celów pomiarowo-kontrolnych i sterowania automatyką przemysłową. Odgrywa ważną rolę w rozproszonych architektach teleinformatycznych (IT) i przemysłowych sieciach infrastrukturalnych (OT – Operational Technology).
Służy do synchronizacji zróżnicowanych jakość zegarów (dokładność i stabilność pracy). Zawsze synchronizowane są zegary programowe na poziomie OS.
Pracuje w warstwie logicznej (wymiana wiadomości UDP) sieci Ethernet TCP/IP. Znane się implementacje protokołu PTP również w innych standardach komunikacji.
Nie wymaga administrowania i działa automatycznie. Rola administratorów ogranicza się do początkowej konfiguracji PTP (protokół wymaga pewnych zgodności konfiguracyjnych wszystkich uczestników, tzn. zegarów synchronizujących jak i synchronizowanych urządzeń sieciowych i końcowych). Inicjuje się automatycznie, a jego działanie jest bezobsługowe.
Nie wymaga dużych zasobów PC i nie obciąża pracy procesorów (CPU). Istnieją implementacje zarówno na duże serwery Windows/Linux jak i na silnie zminiaturyzowane kontrolery przemysłowe o bardzo skromnych zasobach pamięci i niewielkiej mocy CPU.
Nie obciąża sieci komputerowej, ale duży ruch innych pakietów TCP/IP w sieci Ethernet może destabilizować (zaszumić) pracę PTP zwiększając błąd synchronizacji PC, a nawet uniemożliwić go. Dlatego wszędzie tam, gdzie w grę wchodzą duże dokładności synchronizacji, przydziela się dla PTP dedykowane łącza elektryczne Ethernet lub światłowody. W przypadku światłowodów najczęściej stosuje się tzw. ciemne włókna (ang. Dark Fiber).
Standardowa dokładność PTP jest taka sama jak NTP i osiąga rząd stu mikrosekund. Możliwe jest znaczące podwyższenie dokładności do nanosekund. Wymaga to używania specjalnego sprzętu (kart sieciowych LAN i switchy/routerów Ethernet) z tzw. znakowaniem sprzętowym (ang. hardware timestamping) korygującym wewnętrzne opóźnienia pomiędzy zegarem jądra OS a układem kolejkowania karty sieciowej LAN. W celu zapewnienia wydajności i minimalizacji błędów synchronizacji, taka realizacja wymaga używania układów FPGA/ASIC. W ostatnich latach rozwijane są specjalistyczne profile (konfiguracje PTP) dedykowane do obsługi infrastruktur krytycznych telekomunikacji, energetyki, broadcastingu audio-video, automatyki Przemysłu 40, infrastruktur wewnętrznych chmury i centrów danych. Rekordowe dokładności należą do polskich inżynierów i pozwalają osiągnąć poziom pojedynczych pikosekund.
Od 2020 roku, synchronizacja jest ważnym elementem cyberbezpieczeństwa. Protokół PTP jest wymieniany jako środek zapobiegawczy zagrożeń TSA (Time Synchronisation Attack) i TDA (Time Delay Attack) na rozproszoną infrastrukturę krytyczną.

Terminologia i akronimy PTP

Protokół rozróżnia dwa rodzaje urządzeń klasyfikowanych umownie na urządzenia:

końcowe (PC, kontrolery przemysłowe) – mają jedno wejście sieciowe LAN
sieciowe (SW, przełączniki i routery) wielowejściowe realizujące połączenia sieci LAN

dzielące się na:

urządzenia sieciowe z wbudowanymi zegarami i synchronizowane PTP
urządzenia sieciowe bez zegarów i mierzące oraz aktualizujące jedynie własną latencję (opóźnienie jakie wnoszą) do przechodzących przez nie pakietów PTP

Rys. Klasyfikacja urządzeń obsługiwanych przez PTP (Precision Time Protocol)

Poruszając się w świecie czasu i synchronizacji przyjęto, że zarówno urządzenia końcowe jak i sieciowe zawierające obsługę PTP i zegar nazywane są potocznie CLOCK lub Clock Devices.

Aby rozróżnić urządzenia końcowe od sieciowych przyjęto terminologię w grupie CLOCK:

Ordinary Clock (OC) – urządzenie końcowe zawierające zegar i obsługujące PTP
Boundary Clock (BC) – urządzenie sieciowe zawierające zegar i obsługujące PTP
Transparent Clock (TC) – urządzenie sieciowe kompensujące własną latencję

Rys. Symbole graficzne używane do oznaczeń rodzajów zegarów

Wszystkie pozostałe urządzenia końcowe i sieciowe, inne niż w/w (nie obsługujące protokołu PTP) nie są zegarem. Dlatego nie są one wyróżnianie i nie mają przydzielanej nazwy ani symbolu graficznego. W graficznej reprezentacji topologii sieci są one pomijane.

Hierarchia drzewa PTP i relacje Master – Submaster

Trzecia dekada milenium wprowadziła zmianę w terminologii, gdzie używany od blisko pół wieku termin Master-Slave zastąpiono frazą Master-Submaster po to, aby technika nie promowała nazw relacji, które można interpretować jako element dyskryminacji społecznej.

Akronimy:

GM – Grandmaster, zegar główny dostarczający czas do systemu

M – Master, zegar nadrzędny dla Submaster, przekazuje czas główny

S – Sumbmaster, zegar podrzędny urządzenia synchronizowany do Master

Rys. Hierarchiczna wielopoziomowa struktura drzewa przekazywania informacji o czasie

(lewa strona: drzewo relacji master-submaster; prawa strona symboliczne oznaczenie)

Zasady:

Wszystkie zegary w drzewie są synchronizowane do GM bezpośrednio lub pośrednio
Liście drzewa S są zawsze zegarami OC
Węzły drzewa M-S są zawsze zegarami BC
Na szyczycie hierarchii jest szczególny rodzaj M nazywany GM
W sieci może być wiele M, ale tylko jeden w danej chwili może pełnić funkcje GM
GM może być zegarem OC lub BC
Wybór GM jest negocjacyjny i automatyczny – decydują lepsze parametry zegara M
S synchronizuje się względem M (GM)
Protokół PTP może mieć nieograniczoną liczbę poziomów hierarchii (LEVEL) i może ona się zmieniać w zależności włączania/wyłączania (link+/link-) urządzeń – zegarów

Topologia sieci fizycznej sieci LAN vs. topologia sieci zegarów PTP

Synchronizacja PTP IEEE1588 bazuje na sieci fizycznej LAN, w której ulokowane są:

urządzenia końcowe (komputery, serwery, kontrolery itp.)
urządzenia sieciowe (routery, switche, repeatery itp.)

Wykonują one różne, często złożone i poufne zadania, które nie muszą być znane projektantowi systemu synchronizacji PTP. Spostrzega on topologie sieci fizycznej LAN jako sieć połączonych zegarów. Poszukuje on optymalnej drogi połączeń zegarów, tak aby projektowany system zapewniał domenę czasu z określoną dokładnością. Niezbędne dane struktury połączeń, odległości, rodzaju sprzętu uzyskuje się z baz danych systemu paszportyzacji sieci Network Inventory. W dużych infrastrukturach krytycznych takich jak telecom czy smart-grid dane uzyskuje się z systemów klasy OSS (ang. Operation Support Systems) oraz Asset Management.

Rys. Faza1. Naniesienie zegarów na fizyczną topologię sieci LAN

Rys. Faza 2. Pozostawienie wyłącznie zegarów i usunięcie pozostałych urządzeń

Rys. Faza3. Usunięcie urządzeń z zegarem TC (auto-kompensuje wnoszone opóźnienie)

Planowanie optymalizacji połączeń w sieci fizycznej (obszar szary)

Rzeczywista topologia fizycznej sieci LAN często wymaga od analityka projektującego system synchronizacji IEEE1588, rozwiązania kwestii optymalizacji połączeń (minimalizacji latencji i doboru parametrów zegarów pośredniczących), którymi ma się odbywać synchronizacja PTP IEEE1588. Realizację routingu można przeprowadzić w zależności od posiadanego sprzętu na dwa sposoby:

Urządzenia sieciowe (switche/routery) obsługujące PTP automatycznie zakrywają fizyczną topologię sieci LAN pozostawiając widoczną strukturę logiczną dla synchronizacji.

Urządzenia sieciowe (switche/routery) obsługujące PTP wymagają ręcznego ustawienia w tryb pasywny I/O połączenia fizyczne blokując ruch pakietów sync PTP

Rys. Faza4. Na lewo: urządzenia sieciowe udostępniają strukturę logiczną dla PTP;

Na prawo: Nieużywane I/O są ustawiane w tryb pasywny

Rys. Ta sama sieć logiczna widziana po przekształceniu w strukturze pionowego drzewa.

Rys. Agregacja – technika wzmacniająca inercje czasową zegarów (np. dłuższy holdover)

Rys. Redundancja – technika wzmacniająca pewność dostaw wzorca UTC

Ustanawianie hierarchii M-S połączeń portów PTP – podstawowe stany portów

Podczas pracy protokołu PTP ustanawiana jest hierarchia połączeń portów LAN urządzeń, które nawiązują między sobą relację wymiany wiadomości synchronizacyjnych.

Poniższy przykład ustanowia relacje par M-S dla portów w hierarchii grafu węzłów ABCDEF

Rys. Zegar „A” staje się M (Master) dla zegara „B” który przyjmuje stan S (Submaster). Następnie zegar „B” ustawia stan M dla zegarów „C” i „D”, które przyjmują stan S. W kolejnym kroku zegary „C” i „D” przyjmują stan M i synchronizują „E” i „F”, które przyjmując stan S. Natomiast link pomiędzy zegarami „C” i „D” zostanie zdezaktywowany, a odpowiednim portom zegarów zostanie przypisany stan pasywny (brak synchronizacji PTP).

Automat stanów PTP – Stos IEEE1588 na poziomie LAN

Rys. Uproszony automat stanów pojedynczego portu LAN obsługującego IEEE1588

Rys Pełny automat stanów pojedynczego portu LAN obsługującego IEEE1588

Po zainicjalizowaniu port 1 górnego zegara OC (Rys) przechodzi do stanu LISTENING nasłuchując wiadomości SYNC w lokalnym segmencie sieci Network. Są to specjalne sygnały synchronizacyjne emitowane regularnie w formie wyróżnionej budową wiadomości. Są rozgłaszane przez inne zegary, których porty znajdują się stanie MASTER. Wiadomości SYNC nie mogą być przenoszone za pośrednictwem między różnymi segmentami sieci. Nasłuch jest ograniczony czasowo interwałem PTP_SYNC_RECEIPT_TIMEOUT mierzonym przez port.

Rys. Zegar OC po zainicjowaniu portu 1 przechodzi do stanu nasłuchu sygnału SYNC

W naszym przykładzie port 1 zegara OC może otrzymać SYNC-message jedynie w przypadku, gdy emitują go porty 2 (OC) lub 3 (BC). Nie otrzyma on nigdy sygnału SYNC z portu 4 (BC).

Jeżeli port1 zegara OC nie otrzyma sygnału SYNC po upływie interwału czasu PTP_SYNC_RECEIPT_TIMEOUT, to domniema on, że w segmencie nie ma innych portów (zegarów) MASTER i zadecyduje autodeklaracją, aby przenieść port1 OC do stanu MASTER.

Rys. Zegar OC port 1 przechodzi do stanu MASTER przy braku SYNC i upływie TIMEOUT

Od tego momentu zegar OC port 1 zaczyna regularnie emitować wiadomości (sygnały) SYNC-message, które są nadawane okresowo ze stałym interwałem SYNC_INTERVAL, a zegar OC port 1 jest od tej pory zegarem MASTER.

Jeżeli rozważymy sytuację, w której drugi zegar OC port 2 (lub BC port 3) jest w tym czasie w stanie nasłuch LISTENING to zacznie on odbierać emitowane przez OC port 1 wiadomości SYNC-message stwierdzając, że w segmencie Network pracuje już MASTER (w naszym przypadku OC port 1). Wtenczas OC port 2 (lub BC port 3) porówna jakość własnego zegara do parametrów zegara OC port 1. Tu możliwe są dwa przypadki.

Przypadek 1. Porównywany zegar OC port 2 jest dokładniejszy niż OC port 1. Wtenczas OC port 2 przejdzie do stanu MASTER i zacznie emitować sygnały SYNC-message.

Przypadek 2. Porównywany zegar OC port 2 jest mniej dokładny niż OC port 1. Wtenczas OC port 2 przejdzie do stanu SLAVE tworząc relację hierarchii M-S z zegarem port1 OC master.

Rys. Po lewej stronie „Przypadek 1” (konflikt M-M); po prawej „Przypadek 2” relacji M-S

Przyjrzyjmy się bliżej „Przypadkowi 1” w którym mamy przez moment konflikt dwóch zegarów MASTER (OC port 1, OC port 2). W takim przypadku OC port 1 MASTER zaczyna również odbierać sygnały SYNC-message z zegara OC port 2. Porównuje parametry obu zegarów i uznaje własne parametry zegara za gorsze zmieniając swój stan na SUBMASTER.

Rys. Zegar OC port 1 zmienia stan na SUBMASTER. Ma gorsze parametry niż OC port 2

Kolejne przejście to powrót zegara OC port 1 ze stanu z SUBMASTER do MASTER. Zdarzenie takie może mieć miejsce, wjeżeli np. zegar OC port 2 ulegnie uszkodzeniu lub zostanie odłączony (link-) z sieci. Wtenczas w segmencie sieci „Network” pozostaną dwa zegary SUBMASTER i wystąpi „konflikt” relacji S-S, który musi być szybko rozwiązany, ponieważ oba zegary SUBASTER (OC port 1 i BC port 3) pracują w trybie holdover własnego podtrzymywania czasu (bez synchronizacji), aż do czasu rozwiązania „konfliktu relacji S-S” uwarunkowanego interwałem czasu TIMEOUT wymiany pakietów SYNC-message (Rys).

Rys. Zegar OC port 2 link (-). W sieci pozostają 2x SUBMASTER (OC port 1 BC port 3).

Rys. Zegar OC port 1 wraca do stanu MASTER. Powstaje relacja M-S z BC port 3

W naszym uproszonym modelu automatów stanu PTP portów zegarów OC/BC brakuje przejścia od tanu nasłuch LISTENING do SUBMASTER. Oczywiście, taki stan istnieje i mogliśmy go wskazać już na początku, gdyby włączając OC port 1 do sieci działał w niej MASTER o lepszych parametrach zegara. Rzeczywisty automat stanów jest bardziej złożony

Parametry określające jakość zegara PTP

Następujące parametry określają jakość zegara IEEE1588 ustanawiającą kryterium doboru relacji M-S w hierarchicznej strukturze drzewa synchronizacji:

Na wybór mają wpływ w uzupełnianiu również parametry błędów jakie wnoszą opóźnienia w sieci TCP/IP oraz parametry oscylatorów kwarcowych w zegarach OC/BC, takich jak precyzja i niestabilności częstotliwości (wpływ Dt temperatury wzmacniana procesami starzenia):

Warto zwrócić uwagę, że rzeczywiste wskazanie zegara PTP zawiera się w nieznanym miejscu przedziału reprezentowanego polem prostokąta (Rys niżej). Dyspersja reprezentuje maksymalny błąd pomiaru OFFSET zegara PTP względem referencji UTC. Zawiera ona sumę wszystkich błędów, włączając statystyczne opóźnienie jakie wnosi sieć komputerowa, asymetria API systemu operacyjnego oraz pozostałe błędy związane z układami I/O i oscylatorami kwarcowymi. Im wymóg większych dokładności synchronizacji tym większa liczba składowych błędu pomiaru musi być brana pod uwagę.

W przypadku protokołu PTP IEEE1588 najczęściej używaną skalą czasu odniesienia jest skala czasu UTC. W przeciwieństwie do protokołu NTP również używającego UTC, w protokole PTP skala ta jest rozbijana na składowe TAI – #LICZBA_SEKUND_PRZESTĘPNYCH. W przypadku takim czas UTC jest ponownie składany po stronie SUBMASTER do UTC. Protokół IEEE1588 może używać również inne skale czasu jako referencje odniesienia.

Zasada synchronizacji zegarów PTP

Zasada synchronizacji dwóch zegarów PTP oparta jest na teorii sygnałów. Po ustanowieniu relacji portów M-S, rozpoczyna się proces wymiany wiadomości nazywanych sygnałami między zegarami. Synchronizacja polega zawsze na porównaniu wskazań zegarów M i S oraz wyznaczeniu parametrów strojenia zegara S względem zegara M. Są cztery rodzaje wiadomości (sygnałów) przesyłanych między zegarami M i S:

SYNC message => służy do wstępnego wyliczania różnicy wskazań M i S
FOLLOW_UP message => służy do precyzyjnej korekty wskazań M i S
DELAY_REQ message => służy do określania round-trip opóźnienia sieci M-S
DELAY_RES message => służy do określania round-trip opóźnienia sieci M-S

W celu ilustracji procesu, użyjemy umownej skali czasu ARB (ang. arbitrary) liczonej w sekundach i zaczynającej się od wartości zero stanowiącej umowną północ naszej skali czasu. Pomiar zaczyna się w momencie, gdy zegar M wskazuje wartość 200 sekund po północy, a zegar S jest rozsynchronizowany względem M i wskazuje 180 sekund po północy, a więc różnicę 20 sekund.

Zegar M wysyła do zegara S wiadomość (sygnał) SYNC ze znacznikiem czasu zegara M o wartości 200 sekund. Odbierając wiadomość zegar S, koryguje do wartości 200s swoje wskazanie i oba zegary M i S są zsynchronizowane.

Powyższy przykład jest teoretycznym, ponieważ wysłana z M wiadomość dociera do S w tej samej chwili co M ją wysyła, a to pozostaje w sprzeczności z prawami fizyki. W rzeczywistej sieci istnieją opóźnienia ruchu pakietów (DELAY). Dlatego nasz przykład wymaga nieznacznej korekty i pochylenia w dół wszystkich sygnałów (SYNC)) w kierunku pionowych osi „strzałki czasu”.

Rzeczywista symulacja procesu synchronizacji przebiega następująco:

Krok 1. Zegar M wysyła do zegara S wiadomość (sygnał) SYNC ze znacznikiem własnego czasu zegara M o wartości 200 sekund po północy umownej skali ARB. Wiadomość ta przesyłana jest siecią do S, który odbierając ją znakuje moment odbioru znacznikiem własnego zegara o wartości 182 sekundy po północy umownej skali czasu ARB.

W kolejnej sekundzie zegar M wysyła do zegara S sygnał FOLLOW_UP.