Inhalt

Einleitung

Hintergrundinformationen

Wichtigkeit der Phase-/Frequenzsynchronisierung

Synchronisierung der Netzwerkuhr

Frequenzsynchronisierung

Phasensynchronisierung

Zeitsynchronisierung

SynchronisierungE

Grundprinzip der Synchronisierung

Messaging-Channel für Ethernet-Synchronisierung

Synchronisierung mit LAG

PTPv2/1588v2

Grundlegendes Prinzip von PTP

Arbeiten mit PTP

PTP-Domänen

Nachrichtenaustauschmuster

Verschiedene Pakettypen

PTP-Gerätetypen

Festlegen der MasterClock-SlaveClock-Hierarchie

Profile

8275.1

8275.2

Servo-Algorithmus

Konfigurationsbeispiel für 8275.1/8275.2 auf NCS 540 (Cisco IOS XR)

PTP-Fehlerbehebung

Beispielpaketaufzeichnungen für Nachrichten für Synchronisierung, Ankündigung, Verzögerung_Req und Verzögerung_Resp

Zugehörige Informationen

Einleitung

Dieses Dokument beschreibt die Arbeit von Precision Time Protocol (PTP) und Synchronous Ethernet (SyncE) mit Beispielkonfigurationen, Beispielen und Befehlen zur Fehlerbehebung für Cisco IOS® XR-Geräte in den 8275.1- und 8275.2-Telekommunikationsprofilen.

Hintergrundinformationen

Eine Uhr für uns ist eine Wanduhr oder eine Armbanduhr, aber bei Netzwerkgeräten ist es ein periodisches Signal von "0" und "1", mit dem die Datenbits abgetastet werden. Genau wie eine Sekunde Hand in der Uhr eine Winkelbewegung zur Darstellung einer Sekunde hat, repräsentiert ein Paar von 0 und 1 T (Zeitraum [T=1/Frequenz]). Um diese Uhr zu erzeugen, verwenden Netzwerkgeräte einen KristallOszillator, der einen ±100 ppm-Fehler (Teile pro Million) aufweist. Beispielsweise hat eine Uhr mit einer Frequenz von 250 MHz und 100 ppm einen Frequenzbereich von 249,975 MHz bis 250,025 MHz.), um das Taktsignal zu erzeugen. Idealerweise ist die Uhr also nicht vollständig periodisch, reicht aber aus, um die Datensignale aus den Schnittstellen abzutasten.

Telekommunikationsnetze (3G/4G/5G) verwenden eine sehr hochwertige (stratum-)Uhr, und alle Basisstationen (NodeB/eNodeBs usw.) sollten mit dieser Uhr so wenig Fehler/Verzögerung (ca. 1 µs) wie möglich synchronisiert werden.

- Eine Möglichkeit ist die Installation eines GPS an allen Basisstationen, was sehr teuer und weniger sicher ist, da GPS auf Satellitensystemen funktioniert.

- Die zweite Option besteht in der Verwendung der vorhandenen Netzwerkgeräte (NE), um die Uhreninformationen zusammen mit dem Datensignal zu übertragen. Diese Option ist sehr kosteneffektiv, da die Daten bereits von den NEs übertragen werden und die Verwendung von NEs für die Übertragung von Uhren diese kostengünstiger und sicherer machen wird. Die Uhrenqualität ist jedoch möglicherweise nicht so gut wie die frühere GPS-Option und hängt von dem Profil und dem Protokoll ab, das bzw. das in NEs verwendet wird, sowie von der Überlastung im Netzwerk.

Wichtigkeit der Phase-/Frequenzsynchronisierung

Ein Nachrichtensignal (z. B. Sprachsignal), das mit einer Hochfrequenz- (Trägersignal-) Welle am Senderende moduliert wird, muss am Receiver mit demselben Trägersignal demoduliert werden, das am Senderende verwendet wird. Wenn eine Änderung/Offset in der Frequenz oder Phase der Trägerwelle am Empfänger erfolgt, wird das Nachrichtensignal beschädigt. Zwischen der Rx Carrier-Welle und der Tx Carrier-Welle wird jedoch immer ein kleiner Offset erwartet.

Eine Analogie besteht darin, eine Nachricht mithilfe eines sicheren Felds zu senden und mit einem Schlüssel zu sperren. Wenn jemand die Nachricht im Safe-Feld lesen möchte, muss derselbe Schlüssel zum Entsperren der Box am Empfängerende verwendet werden. Wenn die Replikationstaste verzerrt/verschleiert ist, kann die Meldung nicht gelesen werden.

Folgende Offsets sind für verschiedene Telekommunikationsdienste akzeptabel:

Synchronisierung der Netzwerkuhr

Synchronisierung ist die Abstimmung von Uhren auf die gleiche Zeit/Phase und Frequenz.

Die Synchronisierung für die Taktgebung kann in die Frequenzsynchronisierung (Erreichen = / = wobei = auch dieselbe Geschwindigkeit genannt wird), Phasensynchronisierung (zur gleichen Zeit) und Zeitsynchronisierung (Uhrzeit) eingeteilt werden.

Frequenzsynchronisierung

Alle NEs müssen die Taktfrequenz ihrer Uhr mit der Quelluhr (abgeleitet von einer MasterClock) abgleichen.

Die Synchronisierung der Frequenz für NE kann mit SyncE oder PTPv2 erfolgen, die in diesem Abschnitt weiter erläutert werden.

SyncE leitet die Frequenz von Datenpaketen ab, die auf der Schnittstelle (auf der physischen Ebene) empfangen wurden, sowie von ESMC-Paketen, die auf der Schnittstelle empfangen wurden (etwa ein Paket pro Sekunde), die die Qualität der Uhr beschreiben. Daher werden keine Kontrollpakete hinzugefügt, und der Datenverkehr ist nicht überlastet, was der beste Aspekt von SyncE ist.

PTP wird auf Paketen ausgeführt, sodass ein Kontrollpaketfluss vorhanden ist und die Pakete von Überlastungen betroffen sind, was die Verzögerung noch erhöht.

Phasensynchronisierung

Bei der Phasensynchronisierung geht es um die Ausrichtung dieser Taktsignale. Wir sehen, dass die oben genannten Frequenzsynchronisierungssignale noch nicht ausgerichtet sind, sodass sie einen Phasenversatz haben.

PTPv2 wird verwendet, um Phaseninformationen über das Netzwerk zu übertragen.

Zeitsynchronisierung

Die Zeitsynchronisierung wird auch als "Time of Day" (Tageszeit) bezeichnet und findet in allen Netzwerkeinheiten einfach zur gleichen Zeit statt. Das heißt, t_1=t2.

NTP und PTP werden zum Übertragen von Zeitinformationen im Netzwerk verwendet. Während NTP eine Genauigkeit von bis zu Millisekunden bietet, kann PTP eine Genauigkeit von bis zu weniger als Mikrosekunden bieten.

Zeitsynchronisierung und Phasensynchronisierung werden häufig synonym im Netzwerk verwendet, da PTP zur Phasensynchronisierung verwendet wird, um die Zeitsynchronisierung zu ermöglichen.

NTP ist derzeit nicht Teil unserer Diskussion.

SynchronisierungE

Grundprinzip der Synchronisierung

SyncE arbeitet nach dem Prinzip, die Taktfrequenz aus den Daten zu extrahieren, die auf einem Port empfangen werden.

Ein einfaches Beispiel wird hier veranschaulicht. Das Datensignal wird mit dem lokalen Oszillator verarbeitet und die Ausgangsdaten werden über den Tx-Port gesendet. Sie können beobachten, dass die Taktfrequenz im Datensignal vorhanden ist, das auf dem Port übertragen wird. SyncE arbeitet nach dem Prinzip der umgekehrten Verarbeitung des auf dem Rx-Port empfangenen Signals und Abruf der Frequenzinformationen der übertragenen Uhr.

SyncE ist eine Empfehlung der ITU-T zur Bereitstellung einer Frequenz in einem Netzwerk. Gemäß der Empfehlung wird die Frequenz vom Bitstream in der physischen Schicht wiederhergestellt, wie bereits erwähnt. Die Uhr, die in der Kette verteilt wird, wird als primäre Referenzuhr (PRC) bezeichnet, und alle Uhren im Netzwerk müssen auf diese Uhr zurückverfolgt werden können. Um eine nachvollziehbare Uhr zu erhalten, müssen alle Knoten in einer Kette zwischen der MasterClock und dem Endgerät mit einer synchronen Ethernet-Geräte-Uhr (EEC) gemäß den SyncE-Empfehlungen implementiert werden. Die Leistung der wiederhergestellten Uhr hängt nicht von der Netzwerkauslastung ab, da sie nicht mit einem bestimmten Paket synchronisiert wird.

Die MasterClock NE verwendet externe Timing-Referenzen, die von der Netzwerkuhr (SSU oder BITS) stammen. Diese Referenzen werden dann als Eingabe für die EWG-Uhr verwendet, die sich normalerweise auf der zentralen Zeitkarte des NE befindet. Die EWG-Ausgangszeitreferenz dient dann zum Abtasten von Daten und zum Senden des Datenverkehrs auf dem SyncE-Aktivierungs-Tx-Port.

Bei der SlaveClock NE wird die Uhr innerhalb der Transceiver Clock Data Recovery (CDR) wiederhergestellt. In einigen Fällen, in denen die RX-Uhr am Transceiver nicht verfügbar ist, kann die Verwendung eines externen CDRs erforderlich sein, um die Uhr wiederherzustellen. Die Uhr wird dann über die Rückwandplatine gesendet, um die zentrale Zeitkarte der SlaveClock zu erreichen. Diese Zeitangabe wird dann zu einem Verweis auf die EWG (auch als Leitzeitreferenz bezeichnet). Wie in der SlaveClock NE gezeigt, kann eine EWG Line- und externe Referenzen sowie die Eingabe eines ±4,6 ppm Local Oszillators (verwendet in Situationen, in denen keine Leitung oder externe Referenzen verfügbar sind) akzeptieren. Ab diesem Zeitpunkt wird die SlaveClock NE dann zur MasterClock NE für das nächste nachgeschaltete NE, und die Synchronisierung wird auf Knoten-zu-Knoten-Basis übertragen, wobei jeder Knoten an der Wiederherstellung und Verteilung beteiligt ist.

Messaging-Channel für Ethernet-Synchronisierung

Der Ethernet Sychronization Messaging Channel (ESMC) ist ein ITU-T definiertes Ethernet Slow Protocol (d. h. die Nachrichten werden an die Multicast Ethernet-Zieladresse 01-80-C2-00-00-02 gesendet und verwenden die Ether Type 88-09), um das Auslaufen der Nachrichten von einer synchronisierten Verbindung zu einer anderen Verbindung zu verhindern.

Er enthält die SSM-Informationen (Synchronization Status Message), die die QL (Quality Level) der Sendeuhr darstellen. Beispiele: Wenn das Upstream-Gerät mit einer VRC-Uhr synchronisiert ist, erhält das Gerät QL-PRC, und der entsprechende SSM-Wert ist 0010.

ESMC-Daten-PDUs werden regelmäßig mit einer Stromverteilereinheit pro Sekunde gesendet. Wenn innerhalb von fünf Sekunden keine ESMC PDU empfangen wird, wird SSF=true (QL=QL-FAILED) angezeigt. Der Standardwert (erster Wert) für die QL ist DNU (SSM=1111) und darf nur geändert werden, wenn eine gültige QL TLV empfangen wird.

Wenn ein Gerät Dual-Homed ist und die Signalquelle für beide Upstream-Geräte die VRC ist, ist die QL, die von beiden Verbindungen auf dem Gerät empfangen wird, QL-PRC. Daher müssen die Links entsprechend priorisiert werden, um das richtige Upstream-Gerät in Bezug auf Hops, Links usw. auszuwählen.

Die MasterClock-SlaveClock-Synchronisierung über mehrere NEs mit mehreren möglichen Synchronisierungseingaben zum Schutz der Synchronisierung könnte zu Timing-Loops zwischen NEs führen. Um Zeitschleifen zu vermeiden, sollte ein NE einen SSM-Wert von DNU in Richtung des NE einfügen, der als tatsächliche Synchronisierungsquelle für die NE-Uhr verwendet wird.

Synchronisierung mit LAG

SyncE funktioniert auf der physischen Ebene, und die ESMC-Pakete werden auch über das langsame Ethernet-Protokoll übertragen. LAG ist eine weitere Funktion, die langsame Protokolle verwendet und LAG über ESMC arbeitet. Daher ist die Verarbeitung von ESMC-Nachrichten für jede synchrone Ethernet-fähige Verbindung in der LAG-Gruppe erforderlich.

Außerdem ist zu beachten, dass die Verwendung paralleler Verbindungen, wie z. B. bei LAG, aufgrund des Potenzials zur Schaffung von Timing-Loops sorgfältig geprüft werden muss.

Im Idealfall reicht es aus, das Paket auf der Verbindung mit einem Mitglied des Pakets auszuführen. Ansonsten bleibt es den Operatoren überlassen, mehrere synchrone Ethernet-fähige Ports zu konfigurieren.

PTPv2/1588v2

IEEE 1588 wurde 2002 vom Institute of Electrical and Electronics Engineers (IEEE) als Precision Clock Synchronization Protocol (PTP) für vernetzte Mess- und Steuerungssysteme definiert. Sie wird kurz als Precision Time Protocol (PTP) bezeichnet.

IEEE 1588v1 gilt für industrielle Automatisierungs- sowie Test- und Messfelder. Mit der Entwicklung von IP-Netzwerken und der Popularisierung von 3G-Netzwerken ist der Bedarf an Zeitsynchronisierung in Telekommunikationsnetzen gestiegen. Um diese Anforderungen zu erfüllen, entwarf IEEE 1588v2 auf der Grundlage von IEEE 1588v1 im Juni 2006, überarbeitete IEEE 1588v2 im Jahr 2007 und veröffentlichte Ende 2008 IEEE 1588v2.

1588v2 ist ein Zeitsynchronisierungsprotokoll, das eine extrem genaue Zeitsynchronisierung zwischen Geräten ermöglicht. Es wird auch verwendet, um die Frequenzsynchronisierung zwischen Geräten zu implementieren.

Dieser paketbasierte Synchronisierungsmechanismus kombiniert die Frequenz- und Phasensynchronisierung auf Ebene unter Mikrosekunden mit den ToD-Verteilungsfunktionen über den effizienten Mechanismus des Paketaustauschs.

Die größte Schwäche von PTP besteht auch in der Paketnatur, da die vom PTP verwendeten Synchronisierungspakete im Netzwerk zwischen MasterClock und Hosts weitergeleitet werden. Diese werden allen Netzwerkereignissen wie Frame-Verzögerung (Latenz), Frame-Verzögerungsschwankung (Packet Jitter) und Frame-Verlust ausgesetzt. Selbst bei der Anwendung einer hohen Priorität auf Synchronisierungsdatenflüsse treten bei diesen Synchronisierungspaketen weiterhin Überlastungen auf, und es können Probleme beim Routing und bei der Weiterleitung auftreten, wie z. B. Out-of-Sequence und Route Flaps.

Grundlegendes Prinzip von PTP

Wir senden die Uhrzeit (hh:mm:ss) in ein Paket und verwenden die Round-Trip-Zeit des Paketflusses, um die Verzögerung bei der Übertragung eines Pakets zu ermitteln und die Uhrzeit durch Anpassung an die Hälfte der Round-Trip-Verzögerung zu korrigieren.

Arbeiten mit PTP

PTP verwendet eine hierarchische MasterClock-SlaveClock-Architektur für die Taktverteilung.

Es legt fest, wie die Echtzeit-Uhren im System miteinander synchronisiert werden. Diese Uhren sind in einer MasterClock-SlaveClock-Synchronisierungshierarchie organisiert, wobei die Uhr oben in der Hierarchie die Referenzuhr für das gesamte System bestimmt. Die Synchronisierung wird durch den Austausch von PTP-Timing-Meldungen erreicht, wobei die SlaveClocks die Timing-Informationen verwenden, um ihre Uhren an die Zeit ihrer MasterClock in der Hierarchie anzupassen.

PTP wurde unter der Annahme eines Multicast-Kommunikationsmodells entwickelt. PTP unterstützt auch ein Unicast-Kommunikationsmodell, solange das Verhalten des Protokolls erhalten bleibt. PTP geht davon aus, dass Announce-Nachrichten regelmäßig von einem Port gesendet und an alle anderen Ports der normalen oder Begrenzungsuhren innerhalb eines Kommunikationspfads gesendet werden. Wenn der Kommunikationspfad mehr als zwei Ports umfasst, wird davon ausgegangen, dass Announce-Nachrichten entweder in Multicast gesendet werden oder die Announce-Informationen mithilfe von Unicast-Nachrichten an alle Ports im Kommunikationspfad repliziert werden. PTP-Ports erkennen andere Ports in einem Kommunikationspfad durch den Empfang von Multicast Announce-Nachrichten.

Das Protokoll wird innerhalb eines logischen Bereichs ausgeführt, der als Domäne bezeichnet wird. Alle PTP-Nachrichten, Datensätze, Statuscomputer und alle anderen PTP-Einheiten sind immer einer bestimmten Domänen-ID zugeordnet.

Das Protokoll definiert das Ereignis und allgemeine PTP-Meldungen. Ereignismeldungen sind Zeitnachrichten, d. h. ein genauer Zeitstempel (die auf dem Gerät am Ein-/Ausstiegspunkt aufgezeichnete Zeit, aber es ist nicht erforderlich, dass die Nachricht die Zeit t überträgt) wird sowohl bei der Übertragung als auch beim Empfang generiert. Allgemeine Nachrichten erfordern keine genauen Zeitstempel.

PTP-Domänen

Eine Domäne besteht aus einer logischen Gruppierung von Uhren, die mithilfe des PTP-Protokolls miteinander kommunizieren.

PTP-Domänen werden verwendet, um ein Netzwerk innerhalb einer administrativen Einheit zu partitionieren. Die PTP-Nachrichten und -Datensätze sind einer Domäne zugeordnet. Daher ist das PTP-Protokoll für verschiedene Domänen unabhängig.

Nachrichtenaustauschmuster

1. Die MasterClock sendet eine Synchronisierungsmeldung an die SlaveClock und notiert die Uhrzeit, zu der sie gesendet wurde.

2. Die SlaveClock empfängt die Synchronisierungsmeldung und notiert die Uhrzeit des Empfangs.

3. Die MasterClock übermittelt der SlaveClock den Zeitstempel durch:

- Einbetten des Zeitstempels in die Synchronisierungsnachricht. Dies erfordert eine Art Hardware-Verarbeitung für höchste Genauigkeit und Präzision.

- Einbetten des Zeitstempels in eine Follow_Up-Nachricht.

4. Die SlaveClock sendet eine Delay_Req-Nachricht an die MasterClock und notiert die Uhrzeit, zu der sie gesendet wurde.

5. Die MasterClock empfängt die Nachricht Delay_Req und notiert die Uhrzeit des Empfangs.

6. Die MasterClock überträgt den Zeitstempel der SlaveClock, indem sie ihn in eine Delay_Resp-Nachricht einbettet.

Die PTP-Zeitgenauigkeit wird durch Asymmetrie in den Pfaden von Ereignismeldungen herabgesetzt. Insbesondere beträgt der Zeitversatz-Fehler 1/2 der Asymmetrie.

Asymmetrie lässt sich durch PTP nicht erkennen. Wenn jedoch bekannt, korrigiert PTP die Asymmetrie. Asymmetrie kann in der physischen Ebene eingeführt werden, z. B. über asymmetrische Übertragungsmedien, über Brücken und Router, und in großen Systemen über die vorwärts- und umgekehrten Pfade, die von Ereignismeldungen übertragen werden, die verschiedene Routen durch das Netzwerk führen. Systeme sollten konfiguriert und Komponenten ausgewählt werden, um diese Auswirkungen zu minimieren. Die Auswahl sollte sich nach der erforderlichen Zeitgenauigkeit richten. Bei Einzelnetzsystemen mit Entfernungen von wenigen Metern ist Asymmetrie in der Regel kein Problem für Zeitgenauigkeiten über ein paar 10 ns.

Verschiedene Pakettypen

Die Ereignismeldungen bestehen aus:

1. Synchronisierung - Wird für die Synchronisierung der Zeit zwischen MasterClock und SlaveClock verwendet. In zwei Schritten werden Synchronisierungsnachrichten nicht mit Zeitstempeln versehen, sondern mit Zeitstempeln in der MasterClock-Uhr und in der Follow_Up-Meldung übertragen. In einem Schritt wird die Synchronisierungsmeldung die Zeit in Anspruch nehmen. Alte Geräte/Hardware konnten die Messung und Übertragung des Ablaufdatums nicht unterstützen, wenn eine Nachricht an einen Port gesendet wurde. Aus diesem Grund waren die Hardware-Beschränkungen in zwei Schritten erforderlich. Jetzt kann die Hardware einen Tag lang den Exit Time Point aufzeichnen und ihn in der Synchronisierungsnachricht senden. Ein Schritt ist abwärtskompatibel mit zwei Schritten.

2. Delay_Req - Eine Delay_Req-Nachricht ist eine Anforderung des empfangenden/SlaveClock-Knotens, die Uhrzeit, zu der die Delay_Req-Nachricht empfangen wurde, mithilfe einer Delay_Resp-Nachricht zurückzugeben. Sie wird verwendet, um die Übertragungszeit zwischen SlaveClock und MasterClock zu berechnen. Diese Nachricht wird auf der SlaveClock mit einem Zeitstempel versehen.

3. Pdelay_Req: Eine Pdelay_Req-Nachricht wird von einem PTP-Port an einen anderen PTP-Port übertragen, um die Weiterleitungszeit zwischen Ports zu messen, um die Verzögerung der Verbindung zwischen diesen zu ermitteln. Er wird von der P2P-transparenten Uhr verwendet, um die Per-Hop-Link-Verzögerung zu berechnen.

4. Pdelay_Resp - Eine Pdelay_Resp-Nachricht wird als Antwort auf den Empfang einer Pdelay_Req-Nachricht von einem PTP-Port übertragen.

Der Satz allgemeiner Meldungen besteht aus:

- Announce - Diese Nachricht wird von BMCA (Best MasterClock Algorithm) zum Generieren der MasterClock-SlaveClock-Topologie verwendet. Früher wählte er die beste MasterClock und hielt sie an ihrem Platz.

- Follow_Up - Dieser Meldungstyp wird im zweistufigen Modus verwendet. Es ist Zeit. (Synchronisierung der Beendigungszeit auf dem MasterClock-Knoten) in der Nachricht.

- Delay_Resp - Mit dieser Eigenschaft wird die Transitzeit von MasterClock zu SlaveClock berechnet. Sie überträgt die Uhrzeit (Beendigungszeit der Meldung Delay_Resp) in der Nachricht.

- Pdelay_Resp_Follow_Up - Dies ähnelt der Follow_Up-Meldung, wird aber von einer P2P-transparenten Uhr generiert.

- Management: Nicht Teil unserer Diskussion.

- Signalisierung - Für die Kommunikation zwischen Uhren für alle anderen Zwecke. Beispielsweise können Signalisierungsnachrichten für die Aushandlung der Rate von Unicast-Nachrichten zwischen einer MasterClock und seinen SlaveClocks verwendet werden.

Die Meldungen Sync, Delay_Req, Follow_Up und Delay_Resp werden verwendet, um die Zeitinformationen zu generieren und zu übermitteln, die für die Synchronisierung von normalen Uhren und Begrenzungsuhren mithilfe des Verzögerungsmechanismus für das Anfrageantwort erforderlich sind.

Die Meldungen Pdelay_Req, Pdelay_Resp und Pdelay_Resp_Follow_Up werden verwendet, um die Verbindungsverzögerung zwischen zwei Uhren-Ports zu messen, die den Peer-Verzögerungsmechanismus implementieren. Die Link-Verzögerung wird verwendet, um Timing-Informationen in Sync- und Follow_Up-Meldungen in Systemen zu korrigieren, die aus Peer-to-Peer-transparenten Uhren bestehen.

Normale und Begrenzungsuhren, die den Peer-Verzögerungsmechanismus implementieren, können mithilfe der gemessenen Verbindungsverzögerungen und der Informationen in den Sync-Nachrichten und den Follow_Up-Meldungen synchronisiert werden. Die Announce-Nachricht wird verwendet, um die Synchronisierungshierarchie einzurichten. Die Verwaltungsmeldungen dienen dazu, die von Uhren verwalteten PTP-Datensätze abzufragen und zu aktualisieren. Diese Meldungen dienen auch zum Anpassen eines PTP-Systems sowie zur Initialisierung und Fehlerverwaltung. Managementnachrichten werden zwischen Managementknoten und Uhren verwendet (werden nicht Teil unserer Diskussion sein).

Die Signalisierungsnachrichten werden für die Kommunikation zwischen Uhren für alle anderen Zwecke verwendet. Beispielsweise können Signalisierungsnachrichten für die Aushandlung der Rate von Unicast-Nachrichten zwischen einer MasterClock und seinen SlaveClocks verwendet werden.

PTP-Gerätetypen

Es gibt fünf grundlegende PTP-Gerätetypen:

1. Normale Uhr - Kann nur eine Grand MasterClock (GM) oder nur eine SlaveClock sein.

2. Grenzuhr - kann sowohl SlaveClock als auch GM sein

3. Durchgehende transparente Uhr - Die durchgehende transparente Uhr leitet alle Nachrichten genau wie eine normale Bridge, ein Router oder ein Repeater weiter. Bei PTP-Ereignismeldungen misst die in Abbildung unten dargestellte Haltezeitbrücke jedoch die Aufenthaltszeit (die Zeit, die die Nachricht benötigt, um die transparente Uhr zu durchlaufen) von PTP-Ereignismeldungen. Diese Aufenthaltszeiten werden in einem speziellen Feld, dem Korrekturfeld, der PTP-Ereignismeldung oder der zugehörigen Follow-up-Meldung zusammengefasst. Diese Korrektur basiert auf der Differenz des Zeitstempels, der beim Eingeben der Ereignismeldung und beim Verlassen der transparenten Uhr generiert wird.

4. Peer-to-Peer-transparente Uhr - Fügt die Verweilzeit sowie die Transitverzögerungszeit für Verbindungen hinzu, um Nachrichten mithilfe des Peer-Verzögerungsmechanismus zu senden (erzeugt eigene Delay-Req-Resp-Pakete, um die Peer-Link-Verzögerung zu berechnen).

5. Managementknoten (nicht Teil unserer Diskussion).

Festlegen der MasterClock-SlaveClock-Hierarchie

Innerhalb einer Domäne führt jeder Port einer normalen Uhr und einer Begrenzungsuhr eine unabhängige Kopie des Protokollzustandscomputers aus. Bei "Zustandsentscheidungsereignissen" überprüft jeder Port den Inhalt aller Announce-Nachrichten, die auf dem Port empfangen wurden. Mithilfe des besten MasterClock-Algorithmus werden der Nachrichteninhalt Announce und der Inhalt der Datensätze analysiert, die der normalen Uhr oder der Begrenzungsuhr zugeordnet sind, um den Zustand jedes Ports der Uhr zu bestimmen.

PTP-Zustandsrechner

Jeder Port einer normalen Uhr und einer Begrenzungsuhr unterhält eine separate Kopie des PTP-Zustandscomputers. Dieser Statuscomputer definiert die zulässigen Zustände des Ports und die Übergangsregeln zwischen Zuständen. Die wichtigsten "Zustandsentscheidungsereignisse", die die MasterClock-SlaveClock-Hierarchie bestimmen, sind der Empfang einer Announce-Nachricht und das Ende eines Ankündigungsintervalls (das Intervall zwischen Announce-Nachrichten). Die Port-Zustände, die die MasterClock-SlaveClock-Hierarchie bestimmen, sind wie folgt:

- INIT - Port ist noch nicht bereit, am PTP teilzunehmen.

- LISTENING - Erster Status, wenn ein Port für die Teilnahme am PTP bereit ist: Der Port überwacht PTP MasterClocks für einen (konfigurierbaren) Zeitraum.

- PRE-MasterClock - Der Port wird in den MasterClock-Status übergehen.

- MasterClock - Der Port stellt Zeitstempel für alle zuhörenden SlaveClock/Boundary Uhren bereit.

- UNCALIBRATED - Der Port empfängt Zeitstempel von einer MasterClock-Uhr, aber die Uhr des Routers ist noch nicht mit dieser MasterClock synchronisiert

- SLAVE: Der Port empfängt Zeitstempel von einer MasterClock-Uhr, und die Uhr des Routers wird mit dieser MasterClock synchronisiert.

- PASSIVE - Der Port hat zwar eine bessere Uhr als die, die er ankündigen würde, wenn er sich im MasterClock-Zustand befand, aber er lässt diese Uhr nicht zu.

Bester MasterClock-Algorithmus

Der beste MasterClock-Algorithmus vergleicht Daten, die zwei Uhren beschreiben, um zu bestimmen, welche Daten die bessere Uhr beschreiben. Dieser Algorithmus wird verwendet, um zu bestimmen, welche der Uhren, die in mehreren Announce-Nachrichten beschrieben werden, die von einem lokalen Uhrenport empfangen werden, die beste Uhr ist. Sie wird auch verwendet, um festzustellen, ob eine neu entdeckte Uhr - eine ausländische MasterClock - besser ist als die lokale Uhr selbst. Die Daten, die eine ausländische MasterClock beschreiben, sind in den Feldern "grandMasterClock" einer Announce-Nachricht enthalten.

Der Algorithmus zum Vergleich von Datensätzen basiert auf paarweisen Vergleichen von Attributen mit der folgenden Rangfolge:

1. priority1 - Ein vom Benutzer konfigurierbarer Status, dass eine Uhr zu einer geordneten Gruppe von Uhren gehört, aus denen eine MasterClock ausgewählt wird.

2. clockClass - Ein Attribut, das die TAI-Nachverfolgbarkeit einer Uhr definiert

3. clockAccuracy - Ein Attribut, das die Genauigkeit einer Uhr definiert.

4. offsetScaledLogVariance - Ein Attribut, das die Stabilität einer Uhr definiert

5. priority2 - Eine vom Benutzer konfigurierbare Benennung, die eine feinere gestaffelte Bestellung bei anderen gleichwertigen Uhren ermöglicht.

6. clockIdentity - Ein Zeitbegrenzer auf der Grundlage eindeutiger Bezeichner

Zusätzlich zu dieser Rangfolge wird die "Entfernung", gemessen durch die Anzahl der Grenzwertuhren zwischen der lokalen Uhr und der ausländischen MasterClock, verwendet, wenn zwei Announce-Nachrichten dieselbe ausländische MasterClock widerspiegeln. Die Entfernung wird im Feld "StepRemoved" (Entfernt) der Ankündigungsnachrichten angezeigt. Diese Bedingung kann bei PTP-Systemen auftreten, bei denen zyklische Pfade nicht von einem Protokoll außerhalb von PTP entfernt werden. Der Algorithmus zum Vergleich von Datensätzen wählt eine der beiden Uhren eindeutig als "besser" oder "topologisch besser" aus.

Profile

Ein PTP-Profil soll es Organisationen ermöglichen, eine bestimmte Auswahl von Attributwerten und optionalen Funktionen von PTP anzugeben, die bei Verwendung desselben Transportprotokolls eine Leistung bereitstellen, die die Anforderungen einer bestimmten Anwendung erfüllt.

Ein PTP-Profil sollte definieren:

- Beste MasterClock-Algorithmus-Optionen

- Konfigurationsmanagement-Optionen

- Pfadverzögerungsmechanismen (Peer-Delay oder Verzögerungs-Request-Response)

- Bereich und Standardwerte aller konfigurierbaren PTP-Attribute und Datensätze-Member

- Erforderliche, zulässige oder verbotene Transportmechanismen

- Die erforderlichen, zulässigen oder verbotenen Knotentypen

- Erforderliche, Zulässige oder Verbotene Optionen

Für die Paketvernetzung mit PTP werden folgende Profile definiert:

8265.x-Profile werden für die Frequenzsynchronisierung mit PTP verwendet.

8275.x wird für die Synchronisierung von Tageszeit und Phase mithilfe von PTP verwendet.  NCS5xx/55xx unterstützt derzeit 8265.1, 8275.1, 8275.2 und 8273.2.

8265.1 wurde früher für die Synchronisierung von 3G/4G-Uhren verwendet, während 8275.x jetzt für 5G verwendet wird, da die Nachfrage nach Genauigkeit bei 5G-Netzwerken steigt.

8275.1

Dieser Anhang enthält das PTP-Telekom-Profil für die Phase/Zeit-Verteilung mit voller Timing-Unterstützung vom Netzwerk.

Synchronisierungsmodell:

Das G.8275.1-Profil verwendet das Hop-by-Hop-Synchronisierungsmodell. Jedes Netzwerkgerät im Pfad von der Server- zur Client-Uhr synchronisiert seine lokale Uhr mit Upstream-Geräten und synchronisiert das Downstream-Gerät.

Knotentypen:

In diesem Profil sind die zulässigen Knotentypen normale Uhren, Grenzuhren und durchgängige transparente Uhren.

In diesem Profil sind die verbotenen Knotentypen Peer-to-Peer-transparente Uhren.

Domänen:

Domänen-IDs von 24 bis 43 können verwendet werden. Die Standard-Domänen-ID ist 24.

Uhrmodus:

Es sind sowohl ein- als auch zweistufige Uhren zulässig. Eine Uhr muss in der Lage sein, Nachrichten zu empfangen und zu verarbeiten, die sowohl von einer Uhr als auch von einer Uhr in zwei Schritten gesendet werden. Eine Uhr ist nicht erforderlich, um sowohl den einstufigen als auch den zweistufigen Modus für die Nachrichtenübertragung zu unterstützen.

Transportmechanismen erforderlich, zugelassen oder verboten

In diesem Profil sind folgende Transportmechanismen zulässig:

- IEEE 802.3/Ethernet und

- OTN

Mindestens einer der beiden Transportmechanismen muss unterstützt werden. Für die Übertragung über IEEE 802.3/Ethernet müssen sowohl die nicht weiterleitbare Multicast-Adresse 01-80-C2-00-00-0E als auch die weiterleitbare Multicast-Adresse 01-1B-19-00-00-00 unterstützt werden, um dieses Profil zu erfüllen.

Unicast-/Multicast-Nachrichten:

Alle Nachrichten werden mithilfe einer der beiden Multicast-Adressen gesendet (01-80-C2-00-00-0E/01-1B-19-00-00-00). Der Unicast-Modus ist in dieser Profilversion nicht zulässig.

Beste MasterClock Algorithm-Optionen:

Dieses Profil verwendet das Alternate BMCA.

Die folgenden Uhrenparameter werden (in der Reihenfolge) von jedem verfügbaren Knoten verglichen, um die beste MasterClock auszuwählen:

Tabelle 1: Telcom Profile BMCA Hierarchie

Parameter

Beschreibung

Priorität 1

NICHT in Telekommunikationsprofilen verwendet

Uhrenklasse

Messung der Nachvollziehbarkeit von Uhren.

Legt fest, ob die Frequenz/Zeit der MasterClock auf eine GNSS-Referenz zurückverfolgt werden kann (A,B besser als C).

Genauigkeit der Uhr

Wie genau ist die Uhrzeit von GM auf die primäre Referenz?

Beispiel: Zeit genau bis maximal 25 ns.

OSLV (Offset Scaled Log Variance)

Messung der Uhrengenauigkeit. Wie viel Uhr-Ausgabe variiert, wenn sie nicht mit einer anderen Quelle synchronisiert wird?

Priorität 2

Benutzerdefinierte Priorität auf dem MasterClock-Knoten, wenn alle oben genannten Parameter übereinstimmen

Lokale Portpriorität

Benutzerdefinierte Port-spezifische Priorität auf DUT

GM-Uhrenidentität

Takt-ID von GrandMasterClock als Zeitschalter

Schritte entfernt

Der kürzeste Pfad, der gewählt wird, wenn GRANDMasterClock über mehrere Ports erreichbar ist (A besser als B)

Option zur Messung der Pfadverzögerung (Verzögerungsanfrage/Verzögerungsantwort):

In diesem Profil wird der Verzögerungsreaktionsmechanismus verwendet. Der Peer-Verzögerungsmechanismus darf in diesem Profil nicht verwendet werden. Die delay_req-Response-Methode muss verwendet werden.

Dieses PTP-Telekom-Profil definiert eine alternative BMCA, die die Verwendung von zwei Hauptansätzen für die Einrichtung der Topologie des Phasenschieberetzwerks ermöglicht:

Automatische Topologieerstellung:

Wenn die in dieser Empfehlung definierten lokalenPriority-Attribute auf ihren Standardwert konfiguriert werden, wird die PTP-Topologie automatisch von der Alternate BMCA auf der Grundlage der Announce-Nachrichten erstellt, die von den PTP-Uhren ausgetauscht werden. Nach diesem Vorgang wird ein Synchronisierungsbaum mit kürzesten Pfaden zu den T-GMs erstellt. In diesem Modus wird bei Ausfällen und Neukonfigurationen der Topologie das Alternate BMCA erneut ausgeführt und eine neue Synchronisierungsstruktur erstellt. Dieser alternative BMCA-Vorgang gewährleistet, dass keine Zeitschleife erstellt wird, ohne dass ein manueller Eingriff oder eine vorherige Netzanalyse erforderlich sind. Die Konvergenzzeit zur neuen PTP-Topologie hängt von der Netzwerkgröße und der spezifischen Konfiguration der PTP-Parameter ab.

Manuelle Netzwerkplanung: Die Verwendung der in dieser Empfehlung definierten lokalenPriority-Attribute mit anderen Werten als ihrem Standardwert ermöglicht das manuelle Erstellen der Synchronisierungs-Netzwerktopologie, ähnlich wie SDH-Netzwerke (Synchronous Digital Hierarchy) normalerweise auf Basis der Synchronisierungsstatusmeldung (SSM) betrieben werden. Diese Option ermöglicht eine vollständige Kontrolle der Aktionen während Fehlerereignissen und Neukonfigurationen der Topologie, basierend auf den konfigurierten lokalen Prioritäten des Systems. Vor der Bereitstellung ist jedoch eine sorgfältige Netzwerkplanung erforderlich, um Zeitschleifen zu vermeiden.

Überlegungen zur Verwendung von Prioritätsachse 2:

Die PTP-Attributpriorität2 ist in diesem Profil konfigurierbar. Unter bestimmten Umständen kann die Verwendung des priority2-Attributs das Netzwerkmanagement vereinfachen. In diesem Abschnitt werden zwei Anwendungsfälle beschrieben: Weitere mögliche Fälle sind für eine weitere Untersuchung vorgesehen.

Fall 1.

Betreiber können die PTP-Attributpriorität2 so konfigurieren, dass alle T-BCs entweder auf eine Telecom Grand MasterClock (T-GM) zurückverfolgt oder gleichzeitig auf zwei verschiedene T-GMs zurückverfolgt werden können.

Beispiel: Wenn in Abbildung 26 alle anderen PTP-Attribute der beiden T-GMs identisch sind und die beiden T-GMs mit demselben Prioritätswert2 konfiguriert sind, wählt jeder T-BC die T-GM mit dem kürzesten Pfad aus. Wenn die beiden T-GMs mit unterschiedlichen Prioritätswerten2 konfiguriert sind, werden alle T-BCs mit dem T-GM mit dem Wert der kleinsten Priorität2 synchronisiert.

Fall 2.

Operatoren können die PTP-Attributpriorität2 konfigurieren, um zu verhindern, dass die T-BCs eines Upstream-Netzwerks mit den T-BCs eines Downstream-Netzwerks synchronisiert werden, wenn der T-GM ausfällt.

Wenn beispielsweise in Abbildung 27 alle anderen PTP-Attribute aller T-BCs identisch sind und die PTP-Attributpriorität2 aller T-BCs mit demselben Wert konfiguriert ist, können die T-BCs im Upstream-Netzwerk, wenn der T-GM ausfällt, mit den T-BCs im Downstream-Netzwerk synchronisiert werden, je nach den clockIdentity-Werten aller T-BCs s. Wenn die T-BCs im Upstream-Netzwerk mit einem geringeren Priorität2-Wert konfiguriert werden als die T-BCs im Downstream-Netzwerk, werden die T-BCs im Downstream-Netzwerk bei einem Ausfall des T-GM mit den T-BCs im Upstream-Netzwerk synchronisiert.

Betrieb über Link-Aggregation:

Wenn zwei Geräte, die PTP-Uhren einbetten, die mit diesem Profil kompatibel sind, über eine Link Aggregation (LAG) verbunden sind, sollte auf jede physische Verbindung direkt zugegriffen werden, um PTP-Nachrichten zu übertragen, wobei die LAG umgangen wird. Diese Methode verhindert potenzielle Asymmetrien, die auftreten können, wenn die Vor- und Rückwärtswege über verschiedene Verbindungen der LAG bereitgestellt werden.

Überlegungen zur Auswahl der PTP-Ethernet-Multicast-Zieladresse:

Dieses PTP-Profil unterstützt sowohl die nicht weiterleitbare Multicast-Adresse 01-80-C2-00-00-0E als auch die weiterleitbare Multicast-Adresse 01-1B-19-00-00-00, wenn die PTP-Zuordnung verwendet wird.

Die zu verwendende Ethernet-Multicast-Adresse hängt von der Operatorrichtlinie ab. Weitere Überlegungen sind im Folgenden aufgeführt.

Die Layer-2-Bridging-Funktion, die dem PTP-Port eines T-BC- oder T-TC-Geräts zugeordnet ist, darf keinen Frame mit der MAC-Zieladresse 01-1B-19-00-00-00 weiterleiten. Dies kann durch die ordnungsgemäße Bereitstellung dieser Multicast-Adresse in der Filterdatenbank erfolgen.

Option 1 - Verwendung der nicht weiterleitbaren Multicast-Adresse 01-80-C2-00-00-0E

Einige Netzwerkbetreiber sind der Ansicht, dass die PTP-Nachrichten niemals über PTP-unbewusste Netzwerkgeräte weitergeleitet werden dürfen.

Die Verwendung der nicht weiterleitbaren Multicast-Adresse 01-80-C2-00-00-0E garantiert diese Eigenschaft meistens (es gibt Ausnahmen für einige ältere Ethernet-Geräte).

Daher verhindert die Verwendung dieser Multicast-Adresse bei Fehlkonfigurationen von Netzwerkgeräten (z. B. wenn die PTP-Funktionen in PTP-fähigen Netzwerkgeräten nicht aktiviert sind) eine falsche Synchronisierung, da die PTP-Nachrichten von der PTP-unwissenden Netzwerkausrüstung blockiert werden.

Option 2 - Verwendung der weiterleitbaren Multicast-Adresse 01-1B-19-00-00-00

Einige Netzwerkbetreiber halten die Nutzung einer weiterleitbaren Multicast-Adresse für flexibler und empfehlen, die PTP-Nachrichten weiterzuleiten, um die Synchronisierungsverbindung aufrechtzuerhalten, falls einige Geräte als Nicht-PTP-Knoten falsch konfiguriert sind. Es besteht jedoch das Risiko einer Leistungsminderung. Das Netzwerkmanagementsystem (NMS) findet die Fehlkonfiguration leicht und sendet Alarme.

Es ist jedoch möglich, die PTP-Nachrichten zu blockieren, indem diese Multicast-Adresse in der Filterdatenbank der einzelnen Ethernet-Geräte ordnungsgemäß bereitgestellt wird.

8275.2

In dieser Empfehlung wird ein anderes PTP-Profil definiert, um die Verteilung von Phase und Zeit mit teilweiser Timing-Unterstützung (PTS) aus dem Netzwerk zu ermöglichen (d. h., dass nicht jedes Gerät im Netzwerk betrieben werden muss). Der Hauptunterschied zwischen 8275.2 und 8275.1 besteht darin, dass 8275.1 auf IPv4-Unicast ausgeführt wird und nicht alle Knoten im Netzwerk PTP ausführen müssen.

Transportmechanismen:

In diesem Profil ist der erforderliche Transportmechanismus UDP/IPv4.

Unicast-Nachrichten:

Alle Nachrichten werden als Unicast gesendet.

In diesem Telekom-Profil ist die Unicast-Aushandlung standardmäßig aktiviert.

Die SlaveClock initiiert die Sitzung, indem sie das Verfahren zur Aushandlung von Unicast-Nachrichten befolgt.

Domänen:

Domänen-IDs von 44 bis 63 können verwendet werden. Die Standard-Domänen-ID ist 44.

Beste MasterClock Algorithm-Optionen:

Dieses Profil verwendet das Alternate BMCA.

Die Eigenschaften 4.3.1.6-4.3.1.9 gelten auch für 8275.2.

Überlegungen zum PTP-over-IP-Transport in Ringtopologien:

Bei der Verwendung von PTP-Messaging über eine IP-Transportschicht sind einige Aspekte des Layer-3-Protokolls zu berücksichtigen. Die PTP-Ebene übermittelt Nachrichten mit einer Ziel-IP-Adresse an die IP-Ebene. Die IP-Schicht stellt dann sicher, dass die Nachricht an das Ziel übermittelt wird, solange es einen Pfad durch das IP-Transportnetzwerk vom Quellknoten zur Zieladresse gibt. Die IP-Schicht enthält dynamische Routing-Protokolle, die den Pfad durch das Netzwerk auf der Grundlage der verfügbaren Verbindungen zwischen den IP-Routern anpassen können. Es kann vorkommen, dass der von der IP-Transportschicht verwendete Pfad nicht der vom Synchronisierungsplaner erwartete Pfad ist. Die Anwendung einiger Einschränkungen in der IP-Transportschicht zur Kontrolle suboptimaler Pfade für PTP-Nachrichten kann von Vorteil sein. Dies ist bei Ringtopologien wahrscheinlich der Fall.

Ausgehend von der in Abbildung 29 gezeigten Topologie ist die SlaveClock so konfiguriert, dass sie Unicast-Dienste sowohl von BC3 als auch von BC4 anfordert. Nachdem die Announce-Nachrichten sowohl von BC3 als auch von BC4 empfangen wurden, führt die SlaveClock die BMCA aus und wählt BC4 als übergeordnete Uhr aus, basierend darauf, dass die Schritte - der entfernte Wert von BC4 ist 1, verglichen mit einem stufenweise entfernten Wert von 3 für BC3. Die SlaveClock fordert dann Synchronisierungsmeldungen von BC4 an.

Wenn die Verbindung zwischen BC4 und R6 unterbrochen wird (siehe Abbildung 30), wird BC4 nicht über den erwarteten Pfad erreicht. Sie ist jedoch weiterhin erreichbar, da Routing-Protokolle die Verbindung beibehalten, indem die IP-Pakete um den Ring geroutet werden. BC4 wird als übergeordnete Uhr beibehalten, da sie von der BMCA immer noch als besser angesehen wird.

Es ist sehr wahrscheinlich, dass der gewünschte Vorgang darin besteht, dass die SlaveClock zu BC3 wechselt, um die Leistung zu verbessern.

Es gibt einige Techniken, mit denen sichergestellt werden kann, dass im oben identifizierten Fehlerszenario die SlaveClock BC3 als übergeordnete Uhr auswählt. Sie basieren auf der Blockierung der PTP-IP-Nachrichten von BC4 zur SlaveClock, wenn diese Nachrichten im Uhrzeigersinn durch den Ring gesendet werden. Die Lösung basiert auf der Blockierung nur der PTP-Nachrichten und nicht der Nachrichten anderer Protokolle, die möglicherweise dieselben IP-Adressen verwenden.

Option 1: Eindeutige IP-Adressen und statische Routen:

In einigen Bereitstellungsmodellen kann es möglich sein, eindeutige IP-Adressen für die Verwendung von PTP allein zuzuweisen. Auf diese Weise können statische Routen verwendet werden, um die Richtung der PTP-Flüsse zwischen den Knoten zu steuern. BC4 würde so konfiguriert, dass der einzige Pfad, der zum Erreichen von 11.5.100.141 (SlaveClock) verwendet wird, die Verbindung zwischen BC4 und R6 wäre. Außerdem könnte R6 so konfiguriert werden, dass der einzige Pfad, der für die Erreichung des Standards 11.5.100.104(BC4) verwendet wird, die Verbindung zwischen R6 und BC4 wäre. Wenn die Verbindung zwischen R6 und BC4 fehlschlägt, ist keine Route zum Abrufen der IP-Pakete zwischen 11.5.100.141 und 11.5.100.104 verfügbar, sodass die SlaveClock keine Ankündigungen von BC4 erhält und die BMCA BC3 als übergeordnete Uhr wählt. Dies ist in Abbildung 31 dargestellt.

Option 2: IP-Filter

Alle Router unterstützen IP-Filterung auf einer bestimmten Ebene. Mithilfe von Filtern kann die Kontrollebene des Routers vor unerwünschten Nachrichten geschützt werden. Sie können in diesem Fall verwendet werden, um die Annahme von PTP-Nachrichten auf einer Teilmenge der Routing-Schnittstellen zu steuern.

In diesem Fall würde R6 so konfiguriert, dass die SlaveClock vor PTP-Nachrichten geschützt wird, die die falsche Route verwenden. Auf der Schnittstelle an der R6-Schnittstelle zu BC3 konnte ein Filter angewendet werden, um nur Nachrichten an den UDP-Port 319 oder 320 zuzulassen, wenn die Quelladresse mit der des PTP-Prozesses auf BC3 übereinstimmt. Alle Nachrichten, die von BC4 stammen und auf dieser Schnittstelle empfangen werden, werden verworfen. Dies ist in den Abbildungen 32 und 33 dargestellt.

Option 3: BC Verarbeitung aller PTP-Nachrichten

Ein BC kann alle empfangenen PTP-Nachrichten für alle vom BC verwendeten Domänen auf einem seiner Ports terminieren. Anschließend können die PTP-Nachrichten entweder aufgrund von Entscheidungen im PTP-Prozess selbst verworfen oder weitergeleitet werden. Sie können die Nachricht verwerfen, wenn die Zieladresse der PTP-Nachricht keine Adresse des BC war, oder sie an die Weiterleitungs-Engine weiterleiten, die an das Ziel weitergeleitet werden soll. Der zweite Fall kann verwendet werden, wenn die PTP-Nachricht für eine andere Domäne als die BC bestimmt ist. Im letzteren Fall kann das Netzwerkelement, das den BC enthält, auch das Korrekturfeld aller weitergeleiteten Ereignismeldungen aktualisieren, um die PTP-Nachrichtenextraktion und -verarbeitung auszugleichen, d. h. die transparente Uhrenfunktion für diese Nachrichten zu unterstützen. Die Nachrichtenextraktion von der IP-Ebene kann durchgeführt werden, wenn der Router das richtlinienbasierte Routing von IP-Paketen unterstützt.

Dieses Beispiel ist in Abbildung 34 dargestellt.

Option 4: Verwendung des TTL-Mechanismus (Time to Live) vom IP-Transport:

Ein PTP-Knoten sendet möglicherweise PTP-Pakete, deren IP/Transport-Header ein Time to Live (TTL)-Feld enthält, das auf die Mindestanzahl an Routing-Hops festgelegt ist, die erforderlich sind, um den Peer-PTP-Port zu erreichen, mit dem er einen PTP-Vertrag hat. Wenn in einem typischen PTP-unwissenden Netzwerk mit unwissenden Routern zwischen MasterClock und SlaveClock die Anzahl der PTP-Router ohne Erkennung größer ist als der TTL-Wert der PTP-Nachricht, wird die PTP-Nachricht von einem der PTP-unwissenden Router verworfen. Diese Funktion kann verwendet werden, um die Anzahl der IP-Hops zu begrenzen, die durch PTP-Pakete zwischen benachbarten Routern übertragen werden, und um die Kommunikation durch unerwünschte längere Pfade zu vermeiden.

Dieses Verhalten kann pro PTP-Port oder pro PTP-Uhr sein und ist implementierungsspezifisch. In einer solchen Ringtopologie wird davon ausgegangen, dass das IP-Routing sicherstellt, dass ein kürzerer Pfad zur PTP MasterClock als bessere Route gilt als der längere Pfad um den Ring.

Wenn beispielsweise eine SlaveClock-Uhr über eine direkt verbundene MasterClock verfügt, die auch über einen längeren Pfad erreichbar ist, kann sie den TTL-Wert 1 verwenden, um sicherzustellen, dass PTP-Pakete die MasterClock nur über den direkt verbundenen Pfad und nicht über den längeren Pfad um den Ring erreichen.

Servo-Algorithmus

Beschreibung der Modi:

- Modus "Freier Betrieb"

Die PTP-Uhr wurde noch nie mit einer Zeitquelle synchronisiert und wird derzeit nicht mit einer Zeitquelle synchronisiert.

- Akquise-Modus

Die PTP-Uhr wird gerade mit einer Zeitquelle synchronisiert. Dauer und Funktionalität dieses Modus sind implementierungsspezifisch. Dieser Modus ist in der Implementierung nicht erforderlich.

- Freq/Phase-Locked-Modus

Phasensperre - Die PTP-Uhr wird phasensynchronisiert mit einer Zeitquelle und liegt innerhalb einer akzeptablen internen Genauigkeit.

Frequenzsperre - Die Taktfrequenz wird mit einer Zeitquelle synchronisiert und entspricht einer akzeptablen internen Genauigkeit.

Wenn es sich um einen PTP-Port-Status handelt, der in [IEEE 1588] definiert ist, befindet sich eine Uhr im Locked-Modus, wenn sich ein PTP-Port im SLAVE-Status befindet.

- Holdover-Modus

Die PTP-Uhr ist nicht mehr mit einer Zeitquelle synchronisiert und nutzt Informationen, die bei der vorherigen Synchronisierung oder der Verfügbarkeit anderer Informationsquellen gesammelt wurden, um die Leistung innerhalb der gewünschten Spezifikation aufrechtzuerhalten oder die Leistung innerhalb der gewünschten Spezifikation nicht aufrechtzuerhalten. Der Knoten kann sich ausschließlich auf seine eigenen Einrichtungen für den Holder verlassen oder eine Art Frequenzeingang des Netzwerks verwenden, um einen Zeit- und/oder Phasenholer zu erreichen.

Konfigurationsbeispiel für 8275.1/8275.2 auf NCS 540 (Cisco IOS XR)

Router ermöglichen die Auswahl separater Quellen für Häufigkeit und Tageszeit (Time of Day, ToD). Die Frequenzauswahl kann zwischen jeder für den Router verfügbaren Frequenzquelle erfolgen, z. B. BITS, GPS, SyncE oder IEEE 1588 PTP. Die ToD-Auswahl liegt zwischen der für die Frequenz ausgewählten Quelle und, falls verfügbar, PTP (ToD-Auswahl erfolgt über GPS, DTI oder PTP). Dieser Modus wird als Hybridmodus bezeichnet, bei dem eine physische Frequenzquelle (BITS oder SyncE) für die Frequenzsynchronisierung verwendet wird, während PTP für die ToD-Synchronisierung verwendet wird.

SyncE (für Frequenzumübertragung) und ptp (Phase/Uhrzeit-Übertragung) können zusammen im Netzwerk verwendet werden, wenn 8275.1 implementiert wird, um eine höhere Genauigkeit zu erreichen (dies wird als Hybridmodus bezeichnet und ist der einzige unterstützte Modus für NCS ab Version 7.3.x).

Das lokale Prioritätsattribut wird nicht in Announce-Nachrichten übertragen. Dieses Attribut wird im Datensatzvergleichsalgorithmus als Zeitsynchroner verwendet, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind.

8275.1:

Grenzuhr

Konfiguration

Erläuterung

ptp

ptp

Uhr

Domäne 24

Profil g.8275.1 Takttyp T-BC

Profil 8275.1 wird mit Taktfunktion als "T-BC Telecom Boundary"-Uhr verwendet.

!

Profil T-BC-MasterClock

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transportnetz

Ethernet-Transport wird verwendet

Port-Status MasterClock-only

Zu verwendender Port-Status ist nur MasterClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

Profil T-BC-SLAVE

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transportnetz

Ethernet-Transport wird verwendet

Port-Status SlaveNur Uhr

Zu verwendender Port-Status ist nur SlaveClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

ptp

ptp aktiviert für diesen Port

Profil T-BC-MasterClock

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

!

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

ptp

ptp aktiviert für diesen Port

Profil T-BC-SLAVE

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 130

!

!

SynchronisierungE

Frequenzsynchronisation

Global möglich

Quality ITU-T Option 1

Die erhaltene QL-Taktfrequenz entspricht Option 1 für ITU-t.

Protokollselektion

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

Frequenzsynchronisation

Aktivieren von SyncE auf der Schnittstelle

Auswahleingabe

Schnittstelle im SlaveClock-Status für SyncE

Priorität 15

lokal von Bedeutung.

Verwaltung der Uhrenauswahl durch Ändern der Priorität der Uhrenquellen

Wiederherstellen 0

Die Zeitdauer, die der Router wartet, bevor eine neu aktive synchrone Ethernet-Uhrenquelle in die Zeitauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

Frequenzsynchronisation

Aktivieren von SyncE auf der Schnittstelle

Wiederherstellen 0

Die Zeitdauer, die der Router wartet, bevor eine neu aktive synchrone Ethernet-Uhrenquelle in die Zeitauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.

GrandMasterClock-Uhr

Konfiguration

Erläuterung

ptp

ptp

Globale Aktivierung von ptp

Uhr

Domäne 24

Profil g.8275.1 Takttyp T-GM

Profil 8275.1 wird mit der Taktfunktion als T-GM Telekom-Großuhr verwendet

!

Profil T-MasterClock

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transportnetz

Ethernet-Transport wird verwendet

Port-Status MasterClock-only

Zu verwendender Port-Status ist nur MasterClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

ptp

ptp aktiviert für diesen Port

Profil T-MasterClock

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

!

!

!

SynchronisierungE

Frequenzsynchronisation

Global möglich

Quality ITU-T Option 1

So konfigurieren Sie die ITU-T Quality Level (QL)-Optionen. Die ITU-T-Option 1 ist ebenfalls die Standardeinstellung.

Protokollselektion

Aktivieren der Protokollierung

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

Frequenzsynchronisation

Aktivieren von SyncE auf der Schnittstelle

Wiederherstellen 0

Die Zeitdauer, die der Router wartet, bevor eine neu aktive synchrone Ethernet-Uhrenquelle in die Zeitauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.

SlaveClock-Uhr

Konfiguration

Erläuterung

ptp

ptp

Globale Aktivierung von ptp

Uhr

Domäne 24

Profil g.8275.1 Uhrentyp T-TSC

Profile 8275.1 wird mit Taktfunktion als T-TSC-Telekom-SlaveClock-Uhr verwendet

!

Profil T-SLAVE

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transportnetz

Ethernet-Transport wird verwendet

Port-Status SlaveNur Uhr

Zu verwendender Port-Status ist nur SlaveClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

ptp

ptp aktiviert für diesen Port

Profil T-SLAVE

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

!

!

!

SynchronisierungE

Frequenzsynchronisation

Global möglich

Quality ITU-T Option 1

So konfigurieren Sie die ITU-T Quality Level (QL)-Optionen. Die ITU-T-Option 1 ist ebenfalls die Standardeinstellung.

Protokollselektion

Aktivieren der Protokollierung

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

Frequenzsynchronisation

Aktivieren von SyncE auf der Schnittstelle

Auswahleingabe

Schnittstelle im SlaveClock-Status für SyncE

Priorität 15

lokal von Bedeutung.

Verwaltung der Uhrenauswahl durch Ändern der Priorität der Uhrenquellen

Wiederherstellen 0

Die Zeitdauer, die der Router wartet, bevor eine neu aktive synchrone Ethernet-Uhrenquelle in die Zeitauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.

!

8275.2:

Grenzuhr

Konfiguration

Erläuterung

ptp

ptp

Uhr

Domäne 44

Profil g.8275.2 Takttyp T-BC

Profil 8275.2 wird mit Taktfunktion als "T-BC Telecom Boundary"-Uhr verwendet.

!

Profil T-BC-MasterClock

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transport IPv4

Ethernet-Transport wird verwendet

Port-Status MasterClock-only

Zu verwendender Port-Status ist nur MasterClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

Profil T-BC-SLAVE

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transport IPv4

Ethernet-Transport wird verwendet

Port-Status SlaveNur Uhr

Zu verwendender Port-Status ist nur SlaveClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

ptp

ptp aktiviert für diesen Port

Profil T-BC-MasterClock

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

!

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

ip address 10.0.0.0.1 255.255.255.252

ptp

ptp aktiviert für diesen Port

Profil T-BC-SLAVE

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 130

MasterClock IPv4 10.0.0.2 255.255.255.252

explizite Erwähnung der MasterClock-IP

!

GrandMasterClock-Uhr

Konfiguration

Erläuterung

ptp

ptp

Globale Aktivierung von ptp

Uhr

Domäne 44

Profil g.8275.2 Takttyp T-GM

Profil 8275.1 wird mit der Taktfunktion als T-GM Telekom-Großuhr verwendet

!

Profil T-MasterClock

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transport IPv4

Ethernet-Transport wird verwendet

Port-Status MasterClock-only

Zu verwendender Port-Status ist nur MasterClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/18

MasterClock-Schnittstelle. Anschluss an Downstream-SlaveClock

ptp

ptp aktiviert für diesen Port

Profil T-MasterClock

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

!

!

!

SlaveClock-Uhr

Konfiguration

Erläuterung

ptp

ptp

Globale Aktivierung von ptp

Uhr

Domäne 44

Profil g.8275.2 Uhrentyp T-TSC

Profile 8275.1 wird mit Taktfunktion als T-TSC-Telekom-SlaveClock-Uhr verwendet

!

Profil T-SLAVE

Definieren Sie eine Rolle für den Port "ptp".

Multicast-Zieladressen-Ethernet 01-80-C2-00-00-0E

Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)

Transport IPv4

Ethernet-Transport wird verwendet

Port-Status SlaveNur Uhr

Zu verwendender Port-Status ist nur SlaveClock

Synchronfrequenz 16

Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Ankündigungsfrequenz 8

Ankündigungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.

Verzögerungsfrequenz 16

Delay_Req-Pakete werden mit einer Frequenz von Paketen pro Sekunde gesendet.

!

!

Schnittstelle TenGigE0/0/0/19

SlaveClock-Schnittstelle. Anschluss an Upstream MasterClock

ip address 10.0.0.0.1 255.255.255.252

ptp

ptp aktiviert für diesen Port

Profil T-SLAVE

Benutzerdefinierte Rolle wird unter diesem Port aufgerufen

Lokale Priorität 120

LocalPriority-Attribut, das als Timer-Breaker im Data Set-Vergleichsalgorithmus verwendet wird, falls alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

MasterClock IPv4 10.0.0.2 255.255.255.252

explizite Erwähnung der MasterClock-IP

!

!

!

Wenn Sie auf der Schnittstelle keine ESMC-Pakete empfangen oder wenn am Ende des Ports kein SyncE konfiguriert ist, Sie aber trotzdem syncE aktivieren möchten. Sie können dies tun, indem Sie den QL-Wert auf der Schnittstelle statisch definieren und SSM deaktivieren.

SynchronisierungE

Frequenzsynchronisation

Quality ITU-T Option 1

Protokollselektion

!

Schnittstelle TenGigE0/0/0/19

Frequenzsynchronisation

SSM deaktivieren

Qualität erhalten exakte itu-t-Option 1 VR China

Auswahleingabe

Priorität 15

Wiederherstellen 0

!

Um den Hybrid-Modus mit 8275.2 zu verwenden, verwenden Sie "Physical-Layer-Frequency" unter der Schnittstelle. Dies ermöglicht SyncE für die Frequenz und ptp für die Phase.

Um den Hybridmodus mit 8275.2 zu aktivieren, muss die "physische Layer-Frequenz" unter dem globalen ptp konfiguriert werden.

ptp

Uhr

Domäne 44

Profil g.8275.2 Takttyp T-BC

!

Profil 82752

Transport IPv4

Synchronfrequenz 16

Ankündigungsfrequenz 8

Verzögerungsfrequenz 16

!

Physical Layer Frequency

Protokoll

Servo-Veranstaltungen

!

!

Beispieltopologie 8275.1:

Gerät A:

ptp

clock

domain 24

profile g.8275.1 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

frequency synchronization

quality itu-t option 1

log selection changes

!

interface TenGigE0/0/0/23

description ***to PTP GM***

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

priority 10

wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ptp

profile T-BC-MasterClock

!

frequency synchronization

wait-to-restore 0

!

!

Gerät B:

ptp

clock

domain 24

profile g.8275.1 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

interface TenGigE0/0/0/23

ptp

profile T-BC-MasterClock

!

!

interface TenGigE0/0/0/19

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

!

!

Beispieltopologie 8275.2:

Gerät A:

ptp

clock

domain 44

profile g.8275.2 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state SlaveClock-only

sync frequency 16

clock operation one-step

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

frequency synchronization

quality itu-t option 1

log selection changes

!

interface TenGigE0/0/0/23

description ***to PTP GM***

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

priority 10

wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ip address 10.0.0.1 255.255.255.252

ptp

profile T-BC-MasterClock

MasterClock ipv4 10.0.0.2 255.255.255.252

!

frequency synchronization

wait-to-restore 0

!

!

Gerät B:

ptp

clock

domain 44

profile g.8275.2 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

interface TenGigE0/0/0/19

mtu 9216

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

!

!

PTP-Fehlerbehebung

Einige zeigen Befehle und beschreiben ihre Ausgaben.

1. Der Servo-Status am Ende des Servoalgorithmus muss "Phase_Locked" (Phase_Gesperrt) lauten. Sie können Abschnitt 4.3.3 zum Servostatusfluss sehen. Wenn der Servo-Modus Hybrid ist, muss auch der SyncE-Fluss überwacht werden, da die Phasensperre nur Post von Freq_Lock erfolgt. Wenn das PTP-laufende Gerät eine normale MasterClock-Uhr ist, ist die oben angegebene Ausgabe möglicherweise ungültig, da der Servo-Algorithmus nicht ausgeführt wird und keine Phase/Frequenz-Synchronisierung von einer anderen MasterClock-Quelle erforderlich ist.

Der Gerätestatus wechselt nur dann zu SPERREN, wenn der Offset in einem akzeptablen Bereich liegt. Überprüfen Sie auch das Offset von MasterClock.

Gerätestatus:

FREE AUSFÜHRUNG/HOLDOVER: Nicht an eine Taktquelle gebunden.

FREQ_LOCKED: Synchronisierung der Frequenz mit MasterClock

PHASE_LOCKED: Synchronisierung von Frequenz und Phase mit MasterClock

Servo-Modus:

Hybrid: Verwenden Sie SyncE für die Frequenzsynchronisierung. PTP wird nur für die Phasensynchronisierung verwendet.

Standard: PTP für die Synchronisierung von Frequenz und Phase verwenden

Zeitdifferenz beobachtet durch Servoalgorithmus b/w SlaveClock und MasterClock.

Zähler für aus PTP-Paketen extrahierte Zeitstempel. Sollte weiter steigen.

Letzte T1/T2/T3/T4-Zeitstempel (sec.nanosec), die aus PTP-Paketen extrahiert wurden. Sollte nahe beieinander liegen und gleichmäßig ansteigen.

T1/T4: Gesendet von MasterClock, T2/T3 : Bei SlaveClock berechnet

Offset basierend auf PTP-Zeitstempeln berechnet

Große (setTime, stepTime) und Feineinstellungen (adjustFreq), die von servo vorgenommen wurden, um sich an der MasterClock auszurichten.

3. show ptp interfaces brief zeigt den Status des Ausgabeports an. Der Status sollte MasterClock/SlaveClock lauten.

4. Die Paketverluste bei "ptp by ptp" müssen deutlich gering sein.

5. Überprüfen Sie den Grund für den Paketverlust:

6. Pakete erreichen PTP nicht.

Abbildung 42: PTP-Paketfluss

Werden Pakete NPU erreicht?

NCS (DNX) platforms: show controllers npu stats traps-all instance all location 0/0/CPU0  | inc 1588

RxTrap1588                                    0    71   0x47        32040   7148566              0

ASR9000 platform: show controller np counters <np> location 0/0/cpu0 | inc PTP

Check for PTP_ETHERNET / PTP_IPV4 counters

Packet drops at NPU (not specific to PTP)

NCS (DNX) platforms: show controllers fia diagshell <np> "diag counters g" location 0/0/cpu0

Shows Rx/TX path statistics along with any drops happening in the NPU

ASR9000 platform: show drops all location <LC>

Check Drop bei SPP:

show spp node-counters location 0/0/cpu0

# Check for any drop-counters incrementing

NCS (DNX) platforms: show spp trace platform common error last 20 location 0/0/cpu0

Dec 10 02:29:38.322 spp/fretta/err 0/0/CPU0 t2902 FRETTA SPP classify RX:

Failed in dpa_punt_mapper; ssp: 0x1e, inlif: 0x2000, rif: 0x11;

trap_code:FLP_IEEE_1588_PREFIX punt_reason:PTP-PKT pkt_type:L2_LOCALSWITCH rc:

'ixdb' detected the 'fatal' condition 'Not found in database': No such file or directory

ASR9000 platforms:

SPP punt path is simpler in ASR9000 with no risk of a lookup failure.

Drops not expected during packet classification.

7. show ptp Packet-Counters <interface-id> zeigt den Paketfluss an. Stellen Sie sicher, dass syncàDelay_ReqàDelay_Resp gefolgt wird (und Follow_Up, wenn es sich um eine zweistufige Uhr handelt).

8. Markieren Sie das Flag (S) für die ausgewählte Schnittstelle.

9. Prüfen Sie die erhaltene QL. Auf der ausgewählten Schnittstelle wird QLsnd DNU sein, um Schleifen zu vermeiden. Um die Schnittstellenvoreinstellung zu ändern, können Sie das Priority-Attribut (Priorität), das standardmäßig 100 lautet, ändern.

10. Stellen Sie sicher, dass die ausgewählte SyncE-Schnittstelle "Output Driven by" (Von Ausgabe angetrieben) lautet.

11. show ptp Foreign-MasterClocks kurze Ausgabe ist die Liste der ptp-Geräte, die am BMCA teilnehmen, um MasterClocks zu werden. Aktivieren Sie die entsprechenden Flags, um die gewählte MasterClock anzuzeigen. Sie können Ankündigungsnachrichten sehen, die von diesen Ports über show ptp packet-counter <interface-id> empfangen wurden. Das Gerät mit den besten Eigenschaften (siehe 4.2.5) gewinnt die BMCA. Wenn mehrere Ports die gleichen Attribute haben, wird die lokale Priorität der letzte Grenzwert sein. Die automatische Topologieeinrichtung ist jedoch auch mit ptp möglich, ohne dass die lokale Priorität verwendet wird (siehe Abschnitt 4.3.1.8).

12. Ptp wählt die vorgesehene MasterClock (BMCA) nicht aus.

Überprüfen Sie die Uhr, die vom Remote-Knoten angekündigt wird:

show ptp foreign-MasterClocks

Interface TenGigE0/9/0/2 (PTP port number 1)

IPv4, Address 21.0.0.2, Unicast

Configured priority: None (128)

Configured clock class: None

Configured delay asymmetry: None

Announce granted:   every 16 seconds,  1000 seconds

Sync granted:       every 16 seconds,  1000 seconds

Delay-resp granted: 64 per-second,     1000 seconds

Qualified for 4 hours, 50 minutes, 6 seconds

Clock ID: 1

Received clock properties:

Domain: 44, Priority1: 128, Priority2: 128, Class: 6

Accuracy: 0x21, Offset scaled log variance: 0x4e5d

Steps-removed: 1, Time source: Atomic, Timescale: PTP

Frequency-traceable, Time-traceable

Current UTC offset: 38 seconds (valid)

Parent properties:

Clock ID: 1

Port number: 1

Liste qualifizierter und ausgewählter MasterUhren:

show ptp foreign-MasterClocks brief

M=Multicast,X=Mixed-mode,Q=Qualified,D=QL-DNU,

GM=GrandMasterClock,LA=PTSF_lossAnnounce,LS=PTSF_lossSync

Interface         Transport Address                   Cfg-Pri  Pri1   State

----------------------------------------------------------------------------

Te0/0/0/12        Ethernet  008a.9691.3830            None     128    M,Q,GM

Überprüfen Sie die an der MasterClock angekündigte Uhr:

show ptp advertised-clock

Clock ID: 8a96fffe9138d8

Clock properties:

Domain: 24, Priority1: 128, Priority2: 128, Class: 6

Accuracy: 0xfe, Offset scaled log variance: 0xffff

Time Source: Internal (configured, overrides Internal)

Timescale: PTP (configured, overrides PTP)

No frequency or time traceability

Current UTC offset: 0 seconds

13. PTP synchronisiert nicht mit der MasterClock:

•Intended PTP MasterClock selected.

•PTP session established

•But not able to synchronize with the MasterClock

show ptp interface brief

Intf                    Port              Port            Line

Name              Number       State          Encap       State         Mechanism

--------------------------------------------------------------------------------

Te0/0/0/12        1            Uncalibrated Ethernet   up            1-step DRRM

OR occasional PTP flap in the field

Jul 31 09:29:43.114 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state PHASE_LOCKED to state HOLDOVER

Jul 31 09:30:23.116 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state HOLDOVER to state FREQ_LOCKED

ul 31 09:35:28.134 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state FREQ_LOCKED to state PHASE_LOCKED

14. Überprüfen Sie, ob PTP aufgrund von Paketverlust geflapst ist:

show ptp trace last 100 location 0/rp0/cpu0

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Updated checkpoint record for clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0): Checkpoint ID 0x40002f60

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Inserted clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) into BMC list at position 0

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Comms] Received BMC message from node 0/0/CPU0. Comms is active

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] GrandMasterClock clock removed, local clock better than foreign MasterClock(s)

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Leap Seconds] GrandMasterClock lost

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Stopping servo

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] BMC servo stopped, BMC servo not synced

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [Comms] Started grandMasterClock clock message damping timer

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Sending SlaveClock update to platform. No grandMasterClock available

Aug  1 02:35:46.059 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Received clock update from the platform. Clock active, not using PTP for frequency, using PTP for time. Current local clock is not a primary ref, sync state is 'Sync' and QL is 'Opt-I/PRC'

15. Überprüfen Sie die Ausgabe von show ptp configuration-errors auf Konfigurationsfehler.

Beispielpaketaufzeichnungen für Nachrichten für Synchronisierung, Ankündigung, Verzögerung_Req und Verzögerung_Resp

Die Erfassung der Announce-Nachricht (8275.1) zeigt die Merkmale der übertragenen Uhr:

Die Erfassung der Sync-Nachricht zeigt die Generierung des Zeitstempels an (ein Schritt).

Zugehörige Informationen

- https://www.itu.int/rec/T-REC-G.8275.1/en

- https://www.itu.int/rec/T-REC-G.8275.2/en

- Listenstandard für 1588v2

- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/sysman/configuration/guide/b-sysman-cg-53xasr9k/b-sysman-cg-53xasr9k_chapter_01100.html

- Technischer Support und Dokumentation für Cisco Systeme