Projekt stosu IEEE1588/White Rabbit

 Wstęp

W ramach tego zadania został określony i stworzony zbiór warstw kombinacji protokołów IEEE1588 oraz White Rabbit uwzględniających fizyczne i logiczne aspekty komunikacji sieciowej, jednocześnie zapewniające dwukierunkową transmisję oraz wysoką precyzję synchronizacji.

Wynikiem prac jest projekt stosu protokołu IEEE1588-2008 wraz z rozszerzeniami specyficznymi dla protokołu White Rabbit oraz odpowiadająca dokumentacja techniczna zawierająca ogólne założenia, charakterystykę zależności poszczególnych warstw stosu oraz opis narzędzi używanych do jego dystrybucji, które zostały przedstawione dalej.

Projekt stosu IEEE1588/White Rabbit

Synchronizacja odbywa się na bazie protokołu IEEE1588-2008. Rozszerzenia tego standardu składają się z dodatkowych wiadomości PTP używanych do zestawienia połączenia synchronizacji o wysokiej dokładności; dodatkowych stanów w maszynie stanów PTP; zmodyfikowanego algorytmu Best Master Clock (BMC). Pomimo tych modyfikacji protokół jest kompatybilny wstecz, tzn. urządzenie pracujące w klasycznym protokole IEEE1588-2008 może synchronizować się do urządzenia Run Rabbit. Modyfikacje protokołu wykorzystują wbudowany mechanizm TLV (Type-Length-Value) pozwalający rozszerzać jego funkcjonalność przez dodawanie nowych ramek Ethernetowych wymienianych pomiędzy urządzeniami.

Aby synchronizacja mogła odbywać się między dwoma urządzeniami, muszą one w pierwszej kolejności ustanowić połączenie pomiędzy sobą. Etap ten składa się z wzajemnej identyfikacji (w celu upewnienia się, że druga strona jest również w stanie synchronizować się z dokładnością poniżej 1 nanosekundy), syntonizacji lokalnych oscylatorów, pomiaru (jeśli istnieje taka potrzeba) i przesłania parametrów urządzenia (np. opóźnień wprowadzanych przez obwody nadawcze/odbiorcze danego urządzenia). Rysunek 1 przedstawia przykład takiej komunikacji. Kolejne etapy wyglądają następująco:

  • Początkowo oba urządzenia znajdują się w stanie bezczynności (Idle). Master okresowo nadaje ramkę Announce do wszystkich urządzeń w sieci. Zawiera ona m.in. informacje o adresie sieciowym urządzenia Master a także parametry określające, jakość jego wewnętrznego zegara, np. jego dokładność, czy jest on zsynchronizowany z zewnętrznym zegarem atomowym, itd. Slave natomiast stale nasłuchuje ruch sieciowy w poszukiwaniu ramek Announce od ewentualnych urządzeń Master obecnych w tej samej sieci.
  • Urządzenie Slave odbiera ramkę Announce od jednego lub kilku urządzeń Master. Parametry odczytane z tej wiadomości używane są przez algorytm BMC do wybrania najlepszego z dostępnych źródeł synchronizacji.
  • Slave odpowiada do urządzenia Master wysyłając ramkę Slave Present powiadamiającą go, że jest urządzeniem zdolnym synchronizować się z sub-nanosekundową dokładnością.
  • Master otrzymując wiadomość Slave Present inicjuje proces syntonizacji lokalnego oscylatora urządzenia Slave. W tym celu przesyła pakiet Lock oznaczający, że zegar Master jest ustabilizowany i może zostać użyty przez Slave do syntonizacji.
  • Slave otrzymując ramkę Lock używa sygnału zegarowego odzyskanego ze strumienia danych wysyłanego przez Master do syntonizacji własnego oscylatora. Gdy proces ten jest zakończony i oba zegary mają tę samą częstotliwość, Slave oznajmia to urządzeniu Master wysyłając pakiet Locked.

r3

Kolejnym etapem jest wykonanie pomiaru opóźnień wprowadzanych przez układy nadawcze i odbiorcze obu urządzeń, jeśli jest taka potrzeba. W przypadku, gdy wartości te są stałe dla każdego połączenia, następuje jedynie ich wymiana pomiędzy dwoma urządzeniami (pakiety Calibrate oraz Calibrated).

Po wykonaniu powyższych czynności, połączenie synchronizacji zostaje ustanowione, co jest sygnalizowane przez urządzenie Master za pomocą pakietu WR MODE ON.

Następuje po tym wymiana ramek Ethernet charakterystycznych dla standardowego protokołu PTP (IEEE1588-2008). Jedyna różnica jest taka, że stemple czasowe generowane są z wyższą niż normalnie rozdzielczością – z udziałem pomiaru fazy używając detektora DMTD:

  • Master przesyła ramkę Sync do urządzenia Slave. Moment wysłania jest dokładnie oznakowany, co określa stempel czasowy t1.
  • W momencie odebrania ramki Sync przez Slave generowany jest stempel czasowy t2.
  • Generacja stempla czasowego musi odbywać się w warstwie fizycznej sieci (jak najbliżej medium transmisyjnego) tak, aby moduły realizujące przesyłanie ramek Ethernetowych wprowadzały jak najmniejszy jitter. Z tego względu niemożliwe jest dołączenie wartości t1 do ramki Sync. Wartość ta zostaje przesłana do urządzenia Slave w kolejnym pakiecie – FollowUP – wysłanym przez Master zaraz po Sync.
  • Następnie sytuacja ulega odwróceniu i to Slave inicjuje przesłanie wiadomości Delay_Req do urządzenia Master. Moment wysłania w Slave oznaczony jest stemplem t3.
  • Master odbierając ramkę Delay_Req generuje stempel czasowy t4 i przesyła jego wartość do urządzenia slave wewnątrz ramki Delay_Resp.

Po skompletowaniu wszystkich wartości stempli czasowych (t1, t2, t3, t4) Slave może przystąpić do oszacowania o ile jego lokalny zegar jest opóźniony lub przyspieszony w stosunku do urządzenia Master w tym celu oblicza:

  • całkowite opóźnienie transmisji (suma czasu przelotu ramki Ethernetowej z urządzenia Master do Slave i Slave do Master) jako: delayMM = (t4 – t1) – (t3 – t2)
  • opóźnienie transmisji w jedną stronę (od Master do Slave) jako:
    delayMS =(1+α)/(1-α)*(delayMM – Δ),
    gdzie α jest parametrem charakteryzującym asymetrię światłowodu, natomiast Δ to suma opóźnień toru transmisyjnego, których wartość jest stała dla danego połączenia oraz nie zmianie się dla każdego nowo-ustanowionego połączenia (opóźnienia toru nadawczego/odbiorczego obu urządzeń).
  • estymację różnicy czasu pomiędzy zegarami Slave i Master: offsetMS = t1 – t2p – delayMS
  • Wartość offsetMS jest następnie użyta, jako parametr korygujący działanie lokalnego zegara urządzenia Slave. Następuje przestawienie zegara (synchronizacja do zegara Master) i cały proces wymiany ramek Ethernetowych (Sync, FollowUP, Delay_Req, Delqy_Resp) powtarza się.