PTP- und SyncE-Grundlagen bei der Cisco IOS XR-Konfiguration

Einleitung

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

Hintergrundinformationen

Eine Uhr ist für uns eine Wanduhr oder eine Armbanduhr, aber für Netzwerkgeräte ist es ein periodisches Signal der abwechselnden 0 und 1, das zum Abtasten der Datenbits verwendet wird. Ebenso wie ein Sekundenzeiger im Takt eine Winkelbewegung zur Darstellung einer Sekunde aufweist, stellt ein Paar von 0 und 1 T dar (Zeitperiode [T=1/Frequenz]). Zur Erzeugung dieses Taktes verwenden Netzwerkgeräte einen Quarzoszillator, der einen ±100 ppm-Fehler aufweist (z.B. ein Takt mit der Frequenz von 250 MHz und 100 ppm hat einen Frequenzbereich von 249,975 MHz bis 250,025 MHz) bei der Erzeugung des Taktsignals. Idealerweise ist der Takt also nicht vollständig periodisch, sondern reicht aus, um die Datensignale aus den Schnittstellen abzutasten.

Telekommunikationsnetze (3G/4G/5G) verwenden eine sehr hohe Qualität (Schicht) und alle Basisstationen (NodeBs/eNodeBs usw.) sollten mit möglichst wenig Fehler/Verzögerung (ca. 1µs) auf diese Uhr synchronisiert werden.

• Eine Möglichkeit ist, ein GPS an allen Basisstationen zu installieren, was ziemlich teuer und weniger sicher ist, da GPS auf Satellitensystemen arbeitet.
• Die zweite Möglichkeit besteht darin, die vorhandene Netzwerkausrüstung (NE) zu verwenden, um die Taktinformationen zusammen mit dem Datensignal zu übertragen. Diese Option ist sehr kostengünstig, da die Daten bereits von den NE übertragen werden und die Verwendung von NE für die Taktsignalübertragung sie billiger und sicherer machen wird. Die Uhrenqualität ist jedoch möglicherweise nicht so gut wie bei der früheren GPS-Option und variiert je nach Profil/Protokoll, das in den Netzwerkelementen verwendet wird, sowie je nach Netzwerküberlastung.

Bedeutung der Phasen-/Frequenzsynchronisierung

Ein sendeseitig mit einer hochfrequenten Welle (Trägersignal) moduliertes Nachrichtensignal (z.B. Sprachsignal) muss empfängerseitig mit dem gleichen senderseitig verwendeten Trägersignal demoduliert werden. Wenn am Empfänger eine Änderung/Verschiebung der Frequenz oder Phase der Trägerwelle erfolgt, wird das Nachrichtensignal beschädigt. Zwischen der Rx-Trägerwelle und der Tx-Trägerwelle ist jedoch immer ein kleiner Offset zu erwarten.

Eine Analogie besteht darin, eine Nachricht über ein sicheres Feld zu senden und mit einem Schlüssel zu verriegeln. Wenn jemand die Nachricht im Safe lesen möchte, muss der gleiche Schlüssel verwendet werden, um die Box auf der Empfängerseite zu entsperren. Wenn der Replikatschlüssel Verzerrungen/Deformationen aufweist, kann die Nachricht nicht gelesen werden.

Zulässige Ausgleichsbeträge für verschiedene Telekommunikationsdienste:

Synchronisierung der Netzwerkzeit

Synchronisation ist die Ausrichtung von Uhren auf die gleiche Zeit/Phase und Frequenz.

Synchronisation für die Taktung kann in Frequenzsynchronisation (erreicht = / = wo = auch als gleiche Rate aufgerufen), Phasensynchronisation (zur gleichen Zeit) und Zeitsynchronisation (Uhrzeit) kategorisiert werden.

Frequenzsynchronisierung

Alle Netzwerkelemente müssen die Frequenz ihrer Uhr mit einer Quell-Uhr (abgeleitet von einer MasterClock) abgleichen.

Die Frequenzsynchronisierung für NE kann mit SyncE oder PTPv2 durchgeführt werden, die in diesem Abschnitt weiter unten beschrieben werden.

SyncE leitet die Frequenz aus Datenpaketen ab, die an der Schnittstelle empfangen werden (funktioniert auf der physischen Schicht), sowie aus ESMC-Paketen, die an der Schnittstelle empfangen werden (ungefähr ein Paket pro Sekunde), das die Qualität der Uhr beschreibt. Es fügt also keine Steuerungspakete hinzu und wird nicht durch Datenverkehrsengpässe beeinträchtigt, was der beste Aspekt von SyncE ist.

PTP wird auf Paketen ausgeführt, sodass Kontrollpakete fließen und die Pakete durch Überlastungen beeinträchtigt werden, was die Verzögerung erhöht.

Phasensynchronisierung

Bei der Phasensynchronisierung geht es um die Ausrichtung dieser Taktsignale. Man erkennt, dass die oben genannten frequenzsynchronisierten Signale noch nicht ausgerichtet sind, sodass sie einen Phasenversatz aufweisen.

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

Zeitsynchronisierung

Die Zeitsynchronisierung, die auch als "Time of Day" (Tageszeit) bezeichnet wird, hat in allen NEs einfach dieselbe Zeit. D.h. t₁=t_2^.

NTP und PTP werden zur Übertragung von Zeitinformationen im Netzwerk verwendet. Während NTP eine Genauigkeit im Millisekundenbereich bietet, kann PTP eine Genauigkeit von bis zu einer Mikrosekunde bieten.

Zeitsynchronisierung und Phasensynchronisierung werden im Netzwerk häufig synonym verwendet, da die Phasensynchronisierung über PTP erfolgt.

NTP wird jetzt nicht Gegenstand unserer Diskussion sein.

SynchronisierenE

Grundprinzip von SyncE

SyncE arbeitet nach dem Grundprinzip, die Taktfrequenz aus den an einem Port empfangenen Daten zu extrahieren.

Ein einfaches Beispiel ist hier dargestellt. Das Datensignal wird mit dem Lokaloszillator verarbeitet und die Ausgangsdaten werden aus dem Tx-Anschluss ausgesendet. 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 Signals, das auf dem Rx-Port empfangen wurde, und dem Abrufen der Frequenzinformationen des übertragenen Taktes.

SyncE ist eine Empfehlung von ITU-T zur Bereitstellung einer Frequenz in einem Netzwerk. Gemäß der Empfehlung wird die Frequenz aus dem Bitstrom in der physikalischen Schicht wiederhergestellt werden, wie bereits erwähnt. Die in der Kette verteilte Uhr wird als primäre Referenzuhr (PRC) bezeichnet, und alle Uhren im Netzwerk müssen auf diese Uhr zurückführbar sein. Um eine nachvollziehbare Uhr zu erhalten, müssen alle Knoten in einer Kette zwischen MasterClock und Endgerät mit einer synchronen Ethernet Equipment Clock (EEC) gemäß den SyncE-Empfehlungen implementiert werden. Die Leistung der wiederhergestellten Uhr ist nicht von der Netzwerkauslastung abhängig, da sie nicht mit einem bestimmten Paket synchronisiert wird.

Die MasterClock-NE verwendet externe Eingangs-Timing-Referenzen, die von der Netzwerkuhr (SSU oder BITS) kommen. Diese Referenzen werden dann als Eingabe für den EEC-Takt verwendet, der sich typischerweise auf der zentralen Timing-Karte des NE befindet. Die EEC-Ausgabezeitreferenz wird dann verwendet, um Daten abzutasten und den Datenverkehr über den SyncE-Tx-Port zu senden.

Bei der SlaveClock NE wird die Uhr innerhalb der Transceiver-Taktdatenwiederherstellung (CDR) wiederhergestellt. In einigen Fällen, in denen die RX-Uhr am Transceiver nicht verfügbar ist, kann die Verwendung eines externen CDR erforderlich sein, um die Uhr wiederherzustellen. Die Uhr wird dann über die Rückwandplatine gesendet, um die zentrale Zeitgeberkarte des SlaveClock zu erreichen. Diese Zeitreferenz wird dann zur EWG-Referenz (auch als "line-timing reference" bezeichnet). Wie in der SlaveClock NE gezeigt, kann ein EEC Linien- und externe Referenzen sowie den Eingang eines ±4,6 ppm Lokaloszillators akzeptieren (wird in Situationen verwendet, in denen keine Linien- oder externen Referenzen verfügbar sind). Von diesem Punkt an wird das SlaveClock NE dann zum MasterClock NE für das nächste nachgeschaltete NE, und die Synchronisation wird auf Node-to-Node-Basis übertragen, wobei jeder Node an der Wiederherstellung und Verteilung beteiligt ist.

Messaging-Channel für Ethernet-Synchronisierung

Der Ethernet Synchronization Messaging Channel (ESMC) ist ein ITU-T-definiertes langsames Ethernet-Protokoll (d. h. die Nachrichten werden an die Multicast-Ethernet-Zieladresse 01-80-C2-00-00-02 gesendet und verwenden den Ether-Typ 88-09), um zu verhindern, dass die Nachrichten von einer synchronisierten Verbindung zu einer anderen Verbindung durchsickern.

Er überträgt die Informationen der Synchronization Status Message (SSM), die dem Qualitätsniveau (QL) des sendenden Takts entsprechen. Beispiel: Wenn das Upstream-Gerät mit einer PRC-Uhr synchronisiert ist, lautet der empfangene QL-Wert "QL-PRC", und der entsprechende SSM-Wert ist "0010".

ESMC-Informations-PDUs werden periodisch mit einer Geschwindigkeit von einer PDU pro Sekunde gesendet. Der fehlende Empfang einer ESMC PDU innerhalb von fünf Sekunden führt zu SSF=true (QL=QL-FAILED). Der (anfängliche) Standardwert für die QL ist DNU (SSM=1111) und muss sich nur ändern, wenn eine gültige QL TLV empfangen wird.

Wenn ein Gerät Dual-Homed ist und die Signalquelle für beide Upstream-Geräte PRC ist, dann ist die von beiden Verbindungen auf dem Gerät empfangene QL QL-PRC. Daher müssen wir die Links entsprechend priorisieren, um das richtige Upstream-Gerät im Hinblick auf Hops, Links usw. zu wählen.

Die MasterClock-SlaveClock-Synchronisierung über mehrere NEs mit mehreren möglichen Synchronisationseingängen zum Schutz der Synchronisation könnte zu Timing-Schleifen zwischen NEs führen. Um Zeitschleifen zu vermeiden, sollte ein NE einen SSM-Wert von DNU in Richtung des NE einfügen, der als eigentliche Synchronisationsquelle für den NE-Takt verwendet wird.

SyncE mit LAG

SyncE funktioniert auf der physischen Ebene, und die ESMC-Pakete werden ebenfalls vom Ethernet-Slow-Protokoll übertragen. Die LAG ist eine weitere Funktion, die langsame Protokolle verwendet und oberhalb von ESMC betrieben wird. Daher ist auf jeder synchronen Ethernet-fähigen Verbindung in der LAG-Gruppe die Verarbeitung von ESMC-Meldungen erforderlich.

Außerdem ist darauf hinzuweisen, dass die Nutzung paralleler Verbindungen, wie im Falle der LAG, aufgrund des Potenzials für die Schaffung von Zeitschleifen sorgfältig geprüft werden muss.

 Im Idealfall ist es ausreichend, um es auf der Single-Member-Verbindung des Pakets auszuführen. Andernfalls bleibt es den Betreibern überlassen, mehrere synchrone Ethernet-fähige Ports zu konfigurieren.

PTPv2/1588v2

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

IEEE 1588v1 gilt für die industrielle Automatisierung sowie für Prüf- und Messfelder. Mit der Entwicklung von IP-Netzen und der Popularisierung von 3G-Netzen ist der Bedarf an Zeitsynchronisation in Telekommunikationsnetzen gestiegen. Um diese Anforderung zu erfüllen, hat IEEE im Juni 2006 IEEE 1588v2 auf der Basis von IEEE 1588v1 entworfen, 2007 IEEE 1588v2 überarbeitet und Ende 2008 IEEE 1588v2 veröffentlicht.

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

Dieser paketbasierte Synchronisierungsmechanismus kombiniert Frequenz- und Phasensynchronisierung auf Submikrosekundenebene mit ToD-Verteilungsfunktionen über den effizienten Mechanismus von Paketvermittlungen

Die größte Schwäche von PTP liegt auch in seiner Paketart, da die vom PTP verwendeten Synchronisationspakete im Netzwerk zwischen MasterClock und Hosts weitergeleitet werden, die allen Netzwerkereignissen wie Frame-Verzögerung (Latenz), Frame-Verzögerungsvariation (Paket-Jitter) und Frame-Verlust unterliegen. Selbst wenn man den Synchronisierungspaketen stets die höchste Priorität einräumt, treten bei diesen Synchronisierungspaketen immer noch Überlastungen und mögliche Routing- und Weiterleitungsprobleme wie Out-of-Sequence- und Route-Flaps auf.

Grundlegendes Funktionsprinzip von PTP

Wir senden die Zeit (hh:mm:ss) in einem Paket und verwenden die Paketfluss-Round-Trip-Zeit, 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 Uhrenverteilung.

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

PTP wurde unter Verwendung eines Multicast-Kommunikationsmodells entwickelt. Das PTP unterstützt auch ein Unicast-Kommunikationsmodell, solange das Verhalten des Protokolls erhalten bleibt. PTP geht davon aus, dass Announce-Nachrichten periodisch von einem Port gesendet und an alle anderen Ports der normalen oder Boundary Clock innerhalb eines Kommunikationspfades übertragen werden. Wenn der Kommunikationspfad aus mehr als zwei Ports besteht, wird davon ausgegangen, dass Announce-Nachrichten entweder in Multicast gesendet werden oder dass die Announce-Informationen mithilfe von Unicast-Nachrichten auf alle Ports im Kommunikationspfad repliziert werden. PTP-Ports erkennen andere Ports innerhalb eines Kommunikationspfads 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-Nachrichten. Ereignismeldungen sind zeitlich abgestimmte Meldungen, d.h. es wird sowohl bei der Übertragung als auch beim Empfang ein genauer Zeitstempel (am Ein-/Ausspeisepunkt auf dem Gerät aufgezeichnete Zeit, die aber nicht zwingend die Zeit t trägt) erzeugt. Allgemeine Meldungen 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 mit einer Domäne verknüpft und daher ist das PTP-Protokoll für verschiedene Domänen unabhängig.

Nachrichtenaustauschmuster

1. Die MasterClock sendet eine Synchronisierungsnachricht an die SlaveClock und notiert die Uhrzeit, zu der sie gesendet wurde.
2. Die SlaveClock empfängt die Synchronisierungsnachricht und notiert die Empfangszeit.
3. Die MasterClock übermittelt dem SlaveClock den Zeitstempel wie folgt:
   • 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. SlaveClock sendet eine Delay_Req-Nachricht an MasterClock und notiert die Uhrzeit, zu der sie gesendet wurde.
5. Die MasterClock empfängt die Delay_Req-Nachricht und notiert den Zeitpunkt des Empfangs.
6. Der MasterClock übermittelt dem SlaveClock den Zeitstempel, indem er ihn in eine Delay_Resp-Nachricht einbettet.

Die PTP-Zeitgenauigkeit wird durch die Asymmetrie in den Pfaden beeinträchtigt, die von den Ereignisnachrichten verwendet wird. Insbesondere beträgt der Zeitversatzfehler 1/2 der Asymmetrie.

PTP kann keine Asymmetrie feststellen. Falls bekannt, korrigiert PTP die Asymmetrie. Asymmetrien können in der physischen Schicht, z. B. über Übertragungsmedien-Asymmetrien, durch Brücken und Router und in großen Systemen durch die Vorwärts- und Rückwärtspfade, die von Ereignismeldungen durchlaufen werden, die unterschiedliche Routen durch das Netzwerk nehmen, eingeführt werden. Die Systeme sollten so konfiguriert und die Komponenten so ausgewählt werden, dass diese Effekte durch die erforderliche Timing-Genauigkeit minimiert werden. In Einzel-Subnetz-Systemen mit Entfernungen von wenigen Metern ist Asymmetrie in der Regel kein Problem für Zeitgenauigkeiten über einigen 10s ns.

Verschiedene Pakettypen

Die Ereignisnachrichten bestehen aus:

1. Synchronisierung - Wird für die Synchronisierung der Zeit zwischen MasterClock und SlaveClock verwendet. In der zweistufigen Synchronisierungsnachricht wird keine Zeit übertragen, aber die Zeit wird mit einem Zeitstempel auf der MasterClock angezeigt und in der Follow_Up-Nachricht übertragen. In einem Schritt überträgt die Synchronisierungsnachricht die Zeit. Alte Geräte/Hardware konnten den Zeitpunkt des Versands einer Nachricht über einen Port nicht messen und übertragen. Der Grund hierfür waren Hardware-Einschränkungen. Heutzutage kann die Hardware den Zeitpunkt des Verlassens aufzeichnen und in der Sync-Nachricht versenden. Ein Schritt ist abwärtskompatibel mit zwei Schritten.

   

2. Delay_Req - Eine Delay_Req-Nachricht ist eine Anforderung des empfangenden/SlaveClock-Knotens, den Zeitpunkt zurückzugeben, zu dem die Delay_Req-Nachricht empfangen wurde. Hierzu wird eine Delay_Req-Nachricht verwendet. Er wird zur Berechnung der Laufzeit zwischen SlaveClock und MasterClock verwendet. Diese Nachricht wird mit dem Zeitstempel der SlaveClock versehen.
3. Pdelay_Req - Eine Pdelay_Req-Nachricht wird von einem PTP-Port an einen anderen PTP-Port als Teil der Messung der Port-zu-Port-Laufzeit übertragen, um die Verzögerung der Verbindung zwischen ihnen zu bestimmen. Sie wird von einer transparenten P2P-Uhr verwendet, um die Verzögerung der Verbindung pro Hop zu berechnen.
4. Pdelay_Resp - Eine Pdelay_Resp-Nachricht wird von einem PTP-Port als Antwort auf den Empfang einer Pdelay_Req-Nachricht übertragen.

Die Gruppe allgemeiner Meldungen besteht aus:

• Announce (Ankündigung): Diese Nachricht wird vom Best MasterClock Algorithm (BMCA) zum Generieren der MasterClock-SlaveClock-Topologie verwendet. Es wird verwendet, um die beste MasterClock auszuwählen und zu behalten.
• Follow_Up - Dieser Meldungstyp wird im zweistufigen Modus verwendet. Es trägt die Zeit. (Sync exit time on MasterClock node) in der Nachricht.
• Delay_Resp - Diese Eigenschaft dient zum Berechnen der Laufzeit von MasterClock zu SlaveClock. Es trägt die Zeit (Beendigungszeit der Delay_Resp-Nachricht) in der Nachricht.
• Pdelay_Resp_Follow_Up - Diese Meldung ähnelt der Follow_Up-Meldung, wird jedoch von einer transparenten P2P-Uhr generiert.
• Management: Nicht Teil unserer Diskussion.
• Signalisierung - für die Kommunikation zwischen Uhren für alle anderen Zwecke. Signalisierungsnachrichten können beispielsweise für die Aushandlung der Rate von Unicast-Nachrichten zwischen einer MasterClock und ihren SlaveClocks verwendet werden.

Die Nachrichten 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 und Grenzuhren mithilfe des Verzögerungsanforderungs-Antwort-Mechanismus erforderlich sind.

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

Normale Uhren und Grenzuhren, die den Peer-Verzögerungsmechanismus implementieren, können mithilfe der gemessenen Verbindungsverzögerungen und der Informationen in den Sync-Meldungen und Follow_Up-Meldungen synchronisiert werden. Die Announce-Nachricht wird verwendet, um die Synchronisationshierarchie festzulegen. Die Managementmeldungen dienen dazu, die von den Uhren verwalteten PTP-Datensätze abzufragen und zu aktualisieren. Diese Meldungen werden auch zur Anpassung eines PTP-Systems sowie für die Initialisierung und das Fehlermanagement verwendet. Management-Nachrichten werden zwischen Management-Knoten und Uhren verwendet (wird nicht Gegenstand unserer Diskussion sein).

Die Signalisierungsnachrichten werden für die Kommunikation zwischen Uhren zu allen anderen Zwecken verwendet. Signalisierungsnachrichten können beispielsweise für die Aushandlung der Rate von Unicast-Nachrichten zwischen einer MasterClock und ihren SlaveClocks verwendet werden.

PTP-Gerätetypen

Es gibt fünf grundlegende Arten von PTP-Geräten:

1. Normale Uhr - Kann nur eine Großmeisteruhr (GM) oder nur eine SlaveClock sein.
2. Boundary Clock - Kann sowohl SlaveClock als auch GM sein
3. Durchgängige transparente Uhr: Die durchgängige transparente Uhr leitet alle Nachrichten wie eine normale Bridge, einen Router oder einen Repeater weiter. Bei PTP-Ereignismeldungen misst die Verweilzeitbrücke (siehe Abbildung unten) die Verweilzeit (die Zeit, die die Nachricht benötigt, um die transparente Uhr zu durchlaufen) von PTP-Ereignismeldungen. Diese Verweilzeiten werden in einem speziellen Feld, dem Korrekturfeld, der PTP-Ereignismeldung bzw. der zugehörigen Nachfolgemeldung akkumuliert. Diese Korrektur basiert auf der Differenz des Zeitstempels, der erzeugt wird, wenn die Ereignisnachricht in die transparente Uhr eintritt und diese verlässt.

   

   

   

4. Transparente Peer-to-Peer-Uhr - Fügt die Verweilzeit sowie die Verbindungstransit-Verzögerungszeit mithilfe des Peer-Verzögerungsmechanismus zu PTP-Nachrichten hinzu (generiert eigene Delay-Req-Resp-Pakete, um die Verzögerung der Peer-Verbindung zu berechnen).

   

   

5. Management-Knoten (nicht Teil unserer Diskussion).

Festlegen der MasterClock−SlaveClock-Hierarchie

Innerhalb einer Domäne führt jeder Port einer normalen Uhr und einer Boundary Clock eine unabhängige Kopie des Protokollstatuscomputers aus. Bei "Statusentscheidungsereignissen" untersucht jeder Port den Inhalt aller auf dem Port empfangenen Announce-Nachrichten. Mithilfe des besten MasterClock-Algorithmus werden der Nachrichteninhalt Announce und der Inhalt der Datensätze, die der normalen Uhr oder der Boundary Clock zugeordnet sind, analysiert, um den Zustand jedes Ports der Uhr zu bestimmen.

PTP-Statuscomputer

Jeder Port einer normalen Uhr und einer Boundary Clock unterhält eine separate Kopie des PTP-Statuscomputers. Dieser Statuscomputer definiert die zulässigen Status des Ports und die Übergangsregeln zwischen den Status. Die wichtigsten "Zustandsentscheidungsereignisse", die die MasterClock−SlaveClock-Hierarchie bestimmen, sind der Empfang einer Announce-Nachricht und das Ende eines Announce-Intervalls (das Intervall zwischen Announce-Nachrichten). Die Port-Status, die die MasterClock−SlaveClock-Hierarchie bestimmen, sind wie folgt:

• INIT - Port kann noch nicht am PTP teilnehmen.
• LISTENING - Erster Status, wenn ein Port für die Teilnahme am PTP bereit ist: Port hört PTP MasterClocks für einen (konfigurierbaren) Zeitraum ab.
• PRE-MasterClock - Der Port wechselt in den MasterClock-Status.
• MasterClock - Der Port stellt Zeitstempel für alle überwachenden SlaveClock-/Boundary-Uhren bereit.
• UNCALIBRATED - Der Port empfängt Zeitstempel von einer MasterClock, aber die Uhr des Routers ist noch nicht mit dieser MasterClock synchronisiert
• SLAVE: Der Port empfängt Zeitstempel von einer MasterClock, und die Uhr des Routers wird mit dieser MasterClock synchronisiert.
• PASSIVE: Der Port erkennt eine bessere Uhr als die, die er ankündigen würde, wenn er sich im MasterClock-Status befände, übernimmt diese Uhr jedoch nicht.

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 Takte, die in mehreren Announce-Nachrichten beschrieben werden, die von einem lokalen Uhrport empfangen werden, die beste Uhr ist. Es wird auch verwendet, um zu bestimmen, ob eine neu entdeckte Uhr - eine fremde MasterClock - besser ist als die lokale Uhr selbst. Die Daten, die eine fremde MasterClock beschreiben, sind in den grandMasterClock-Feldern einer Announce-Nachricht enthalten.

Der Vergleichsalgorithmus für Datensätze basiert auf paarweisen Vergleichen von Attributen mit der folgenden Rangfolge:

1. priority1 - Eine vom Benutzer konfigurierbare Bezeichnung dafür, 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 Bezeichnung, die eine detailliertere Sortierung zwischen ansonsten gleichwertigen Uhren ermöglicht
6. clockIdentity - A tie-breaker based on unique identifiers

Zusätzlich zu dieser Rangfolge wird der "Abstand", der durch die Anzahl der Grenzuhren zwischen der lokalen Uhr und der ausländischen MasterClock gemessen wird, verwendet, wenn zwei Announce-Nachrichten dieselbe ausländische MasterClock wiedergeben. Die Distanz wird im Feld "stepsRemoved" der Announce-Nachrichten angegeben. Diese Bedingung kann in PTP-Systemen auftreten, deren zyklische Pfade nicht von einem Protokoll außerhalb von PTP entfernt wurden. Der Datensatzvergleichsalgorithmus wählt eindeutig eine der beiden Uhren als "besser" oder als "topologisch besser".

Profile

Der Zweck eines PTP-Profils besteht darin, Organisationen die Möglichkeit zu geben, bestimmte Attributwerte und optionale PTP-Funktionen anzugeben, die bei Verwendung desselben Transportprotokolls zusammenarbeiten und eine Leistung erzielen, die den Anforderungen einer bestimmten Anwendung entspricht.

Ein PTP-Profil muss Folgendes definieren:

• Beste MasterClock-Algorithmusoptionen
• Konfigurationsmanagement-Optionen
• Mechanismen zur Pfadverzögerung (Peer-Delay oder Delay Request-Response)
• Bereich und Standardwerte aller PTP-konfigurierbaren Attribute und Datensätze
• Erforderliche, zulässige oder verbotene Transportmechanismen
• Die erforderlichen, zulässigen oder unzulässigen Knotentypen
• Erforderliche, zulässige oder verbotene Optionen

Verschiedene Profile für Paketnetzwerke mit PTP werden wie folgt definiert:

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

8275.x wird für die Tageszeit-/Phasensynchronisierung 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-Takten verwendet, während 8275.x jetzt für 5G verwendet wird, da bei 5G-Netzwerken eine höhere Genauigkeit erforderlich ist.

8275.1

Dieser Anhang enthält das PTP-Telekomprofil für die Phasen-/Zeitverteilung mit vollständiger Zeitsteuerung durch das Netzwerk.

Synchronisationsmodell:

Das G.8275.1-Profil übernimmt das Hop-by-Hop-Synchronisationsmodell. Jedes Netzwerkgerät im Pfad von Server zu Client synchronisiert seine lokale Uhr mit den Upstream-Geräten und ermöglicht die Synchronisierung mit den Downstream-Geräten.

Knotentypen:

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

In diesem Profil sind die unzulässigen Knotentypen transparente Peer-to-Peer-Uhren.

Domänen:

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

Uhrenmodus:

Es sind sowohl Ein- als auch Zweistufenuhren zulässig. Eine Uhr muss in der Lage sein, Nachrichten zu empfangen und zu verarbeiten, die sowohl von einstufigen als auch von zweistufigen Uhren gesendet werden. Eine Uhr ist nicht erforderlich, um sowohl den Ein- als auch den Zwei-Schritt-Modus zum Übertragen von Nachrichten zu unterstützen.

Transportmechanismen erforderlich, zulässig 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 den Transport ü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, damit die Einhaltung dieses Profils gewährleistet ist.

Unicast-/Multicast-Nachrichten:

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

Beste MasterClock-Algorithmusoptionen:

In diesem Profil wird die alternative BMCA verwendet.

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

Tabelle 1. Telcom-Profil BMCA-Hierarchie

Parameter	Beschreibung
Priorität 1	Wird in Telekom-Profilen NICHT verwendet
Uhrenklasse	Maß für die Rückverfolgbarkeit der Uhr. Ob die Frequenz/Zeit der MasterClock auf eine GNSS-Referenz zurückverfolgt werden kann (A, B besser als C)
Taktgenauigkeit	Wie genau wird die Uhr des GM an die primäre Referenz ausgegeben? z. B. auf eine exakte Zeit von 25 ns.
Offset Scaled Log Variance (OSLV)	Maß für die Taktgenauigkeit. Wie stark die Taktausgabe variiert, wenn sie nicht mit einer anderen Quelle synchronisiert wird.
Schwerpunkt 2	Benutzerdefinierte Priorität auf dem MasterClock-Knoten, wenn alle obigen Parameter übereinstimmen
Lokale Port-Priorität	Benutzerdefinierte Port-Priorität auf dem DUT
GM-Uhrenidentität	GrandMasterClock's Uhr-ID als Krawattenbrecher verwendet
Entfernte Schritte	Kürzester Pfad, falls grandMasterClock über mehrere Ports erreichbar ist (A besser als B)

Messoption für die Pfadverzögerung (Delay Request/Delay Response):

In diesem Profil wird der Mechanismus für die Verzögerungsanforderung/Verzögerungsantwort verwendet. Der Peer-Delay-Mechanismus darf in diesem Profil nicht verwendet werden. Es muss die delay_req-response-Methode verwendet werden.

Dieses PTP-Telekomprofil definiert eine alternative BMCA, die die Einrichtung der Topologie des Phasen-/Zeitsynchronisierungsnetzwerks anhand von zwei Hauptansätzen ermöglicht:

Automatische Topologieerstellung:

Wenn die in dieser Empfehlung definierten localPriority-Attribute auf ihren Standardwert konfiguriert werden, wird die PTP-Topologie automatisch von der alternativen BMCA auf Basis der von den PTP-Uhren ausgetauschten Announce-Nachrichten erstellt. Nach diesem Vorgang wird ein Synchronisierungsbaum mit den kürzesten Pfaden zu den T-GMs erstellt. In diesem Modus wird bei Ausfallereignissen und der Topologieumkonfiguration die alternative BMCA erneut ausgeführt, sodass ein neuer Synchronisierungsbaum entsteht. Dieser alternative BMCA-Vorgang stellt sicher, dass kein Timing-Loop ohne manuellen Eingriff oder vorherige Analyse des Netzwerks erstellt wird. Die Konvergenzzeit zur neuen PTP-Topologie hängt von der Größe des Netzwerks und der spezifischen Konfiguration der PTP-Parameter ab.

Manuelle Netzwerkplanung: Die Verwendung der in dieser Empfehlung definierten localPriority-Attribute mit anderen Werten als ihrem Standardwert ermöglicht die manuelle Erstellung der Synchronisierungsnetzwerktopologie. Dies geschieht in ähnlicher Weise, wie SDH-Netzwerke (Synchronous Digital Hierarchy) in der Regel auf Basis der Synchronisierungsstatusmeldung (SSM) betrieben werden. Diese Option ermöglicht die vollständige Kontrolle der Aktionen bei Ausfallereignissen und der Topologieneukonfiguration auf Basis der konfigurierten lokalen Prioritäten des Systems. Vor der Bereitstellung ist jedoch eine sorgfältige Netzwerkplanung erforderlich, um Timing-Schleifen zu vermeiden.

Überlegungen zur Verwendung von Priorität2:

Das PTP-Attribut priority2 kann in diesem Profil konfiguriert werden. In besonderen Fällen kann die Verwendung des priority2-Attributs die Netzwerkverwaltung vereinfachen. In diesem Abschnitt werden zwei Anwendungsfälle beschrieben; weitere mögliche Fälle sind für die weitere Untersuchung vorgesehen.

• Fall 1:

Betreiber können die PTP-Attributpriorität2 so konfigurieren, dass alle Telecom Boundary Clock (T-BCs) entweder auf eine Telecom Grand Master Clock (T-GM) oder auf zwei verschiedene T-GMs gleichzeitig rückverfolgbar sind.

Wenn in diesem Bild beispielsweise alle anderen PTP-Attribute der beiden T-GMs identisch sind und die beiden T-GMs mit demselben priority2-Wert konfiguriert sind, wählt jeder T-BC das T-GM mit dem kürzesten Pfad aus. Wenn die beiden T-GMs mit unterschiedlichen priority2-Werten konfiguriert werden, werden alle T-BCs mit dem T-GM mit dem kleinsten priority2-Wert synchronisiert.

• Fall 2:

Operatoren können das PTP-Attribut priority2 konfigurieren, um zu verhindern, dass sich die T-BCs eines Upstream-Netzwerks mit den T-BCs eines Downstream-Netzwerks synchronisieren, wenn das T-GM ausfällt.

Wenn z. B. in Abbildung alle anderen PTP-Attribute aller T-BCs gleich sind und die PTP-Attributpriorität2 aller T-BCs mit dem gleichen Wert konfiguriert sind, können sich die T-BCs im Upstream-Netzwerk bei einem Ausfall des T-GM mit den T-BCs im Downstream-Netzwerk synchronisieren, abhängig von den clockIdentity-Werten aller T-BCs. Wenn die T-BCs im Upstream-Netzwerk mit einem kleineren Priority2-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, in die PTP-Uhren integriert sind, die mit diesem Profil kompatibel sind, über eine Link Aggregation (LAG) verbunden sind, muss auf jede physische Verbindung direkt zugegriffen werden, um PTP-Nachrichten zu übertragen und die LAG zu umgehen. Dieses Verfahren verhindert potenzielle Asymmetrien, die auftreten können, wenn der Vorwärts- und der Rückweg über verschiedene zur LAG gehörende Verbindungen geführt werden.

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

Dieses PTP-Profil unterstützt bei Verwendung der PTP-Zuordnung die nicht weiterleitbare Multicast-Adresse 01-80-C2-00-00-0E und die weiterleitbare Multicast-Adresse 01-1B-19-00-00-00.

Die zu verwendende Ethernet-Multicast-Adresse hängt von der Operatorrichtlinie ab. Weitere Überlegungen werden im Folgenden erläutert.

Die mit dem PTP-Port eines T-BC oder T-TC verknüpfte Layer-2-Bridging-Funktion sollte keinen Frame mit der MAC-Zieladresse 01-1B-19-00-00-00 weiterleiten. Dies kann durch eine 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 PTP-Nachrichten niemals über PTP-unfähige Netzwerkgeräte weitergeleitet werden dürfen.

Die Verwendung der nicht weiterleitbaren Multicast-Adresse 01-80-C2-00-00-0E garantiert diese Eigenschaft in den meisten Fällen (Ausnahmen bestehen für einige ältere Ethernet-Geräte).

Daher verhindert die Verwendung dieser Multicast-Adresse im Falle einer fehlerhaften Konfiguration der Netzwerkgeräte (z. B. wenn die PTP-Funktionen in PTP-fähigen Netzwerkgeräten nicht aktiviert sind) eine falsche Verteilung der Synchronisierung, da die PTP-Nachrichten von den PTP-unfähigen Netzwerkgeräten blockiert werden.

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

Einige Netzwerkbetreiber sind der Ansicht, dass die Verwendung einer weiterleitbaren Multicast-Adresse flexibler ist und dass es besser ist, die PTP-Nachrichten weiterzuleiten, um die Synchronisierungsverbindung aufrechtzuerhalten, falls einige Geräte als Nicht-PTP-Knoten falsch konfiguriert sind, obwohl ein potenzielles Risiko von Leistungseinbußen besteht. Das Netzwerkmanagementsystem (NMS) erkennt auf einfache Weise die fehlerhafte Konfiguration und sendet Warnmeldungen.

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

8275.2

In dieser Empfehlung wird ein weiteres PTP-Profil definiert, das die Verteilung von Phase und Zeit mit Partial Timing Support (PTS) über das Netzwerk ermöglicht (d. h., nicht jedes Gerät muss PPP im Netzwerk ausführen). Der Hauptunterschied zwischen 8275.2 und 8275.1 besteht darin, dass es auf IPv4-Unicast ausgeführt wird und nicht alle Knoten im Netzwerk PTP ausführen müssen.

Transportmechanismen:

In diesem Profil ist UDP/IPv4 der erforderliche Transportmechanismus.

Unicast-Nachrichten:

Alle Nachrichten werden als Unicast gesendet.

In diesem Telekommunikationsprofil ist Unicast-Aushandlung standardmäßig aktiviert.

SlaveClock initiiert die Sitzung mithilfe des Unicast-Nachrichtenaushandlungsverfahrens.

Domänen:

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

Beste MasterClock-Algorithmusoptionen:

In diesem Profil wird die alternative BMCA verwendet.

Eigenschaften Option zur Messung der Verzögerung (Verzögerungsanforderung/Verzögerungsantwort), automatische Topologieerstellung und Überlegungen zur Verwendung der Priorität2 sind identisch mit Telekomprofil 8275.1

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

Wenn PTP-Messaging über eine IP-Transportschicht verwendet wird, müssen einige Aspekte des Layer-3-Protokolls berücksichtigt werden. Die PTP-Schicht sendet Nachrichten mit einer Ziel-IP-Adresse an die IP-Schicht. 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 umfasst 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 eingenommene Pfad nicht der vom Synchronisationsplaner 'erwartete' Pfad ist. Die Anwendung einiger Einschränkungen in der IP-Transportschicht zur Steuerung suboptimaler Pfade für PTP-Nachrichten kann von Vorteil sein. Dies ist wahrscheinlich bei Ringtopologien der Fall.

Ausgehend von der in der folgenden Abbildung gezeigten Topologie ist SlaveClock so konfiguriert, dass Unicast-Services sowohl von BC3 als auch von BC4 angefordert werden. Nachdem der SlaveClock die Announce-Nachrichten von BC3 und BC4 empfangen hat, führt er die BMCA aus und wählt BC4 als übergeordnete Uhr aus, basierend auf der Tatsache, dass die Schritte - der entfernte Wert von BC4 1 ist, verglichen mit einem schrittweisen entfernten Wert von 3 für BC3. Der SlaveClock fordert dann Synchronisierungsnachrichten von BC4 an.

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

Es ist sehr wahrscheinlich, dass die gewünschte Operation ist, dass die SlaveClock BC3 für eine bessere Leistung wechseln sollte.

Es gibt einige Techniken, die verwendet werden können, um sicherzustellen, dass in dem oben beschriebenen Fehlerszenario der SlaveClock BC3 als seine übergeordnete Uhr auswählt. Sie basieren auf der Blockierung der PTP-IP-Nachrichten von BC4 an SlaveClock, wenn diese Nachrichten im Uhrzeigersinn um den Ring gesendet werden. Die Lösung basiert auf dem Blockieren von PTP-Nachrichten und nicht von Nachrichten anderer Protokolle, die möglicherweise die gleichen IP-Adressen verwenden.

Option 1: eindeutige IP-Adressen und statische Routen:

In einigen Bereitstellungsmodellen ist es möglicherweise möglich, eindeutige IP-Adressen nur für die Verwendung von PTP zuzuweisen. Dies ermöglicht die Verwendung statischer Routen, um die Richtung der PTP-Flüsse zwischen den Knoten zu steuern. BC4 wird so konfiguriert, dass der einzige Pfad zum Erreichen von 11.x.x.141 (SlaveClock) die Verbindung zwischen BC4 und R6 ist. Außerdem könnte R6 so konfiguriert werden, dass der einzige Pfad zum Erreichen von 11.y.y.104(BC4) die Verbindung zwischen R6 und BC4 wäre. Wenn die Verbindung zwischen R6 und BC4 ausfällt, steht keine Route zum Abrufen der IP-Pakete zwischen 11.x.x.141 und 11.y.y.104 zur Verfügung, sodass die SlaveClock keine Announces von BC4 empfängt und die BMCA BC3 als übergeordnete Uhr auswählt. Siehe dieses Bild.

Option 2: IP-Filter

Alle Router unterstützen eine gewisse Stufe der IP-Filterung. Filter können verwendet werden, um die Kontrollebene des Routers vor unerwünschten Nachrichten zu schützen. Sie können in diesem Fall verwendet werden, um die Akzeptanz von PTP-Nachrichten auf einer Teilmenge der Routing-Schnittstellen zu steuern.

In diesem Fall wird R6 so konfiguriert, dass SlaveClock vor PTP-Nachrichten geschützt wird, die die falsche Route nehmen. An der Schnittstelle von R6 zu BC3 konnte ein Filter angewendet werden, um Nachrichten nur an den UDP-Port 319 oder 320 zuzulassen, wenn die Quelladresse mit der des PTP-Prozesses auf BC3 übereinstimmt. Alle von BC4 stammenden Nachrichten, die auf dieser Schnittstelle empfangen werden, werden verworfen. Siehe dieses Bild.

Option 3. BC-Verarbeitung aller PTP-Nachrichten

Ein BC könnte alle PTP-Nachrichten beenden, die er an einem seiner Ports für alle vom BC verwendeten Domänen empfängt. Anschließend können die PTP-Nachrichten entweder verworfen oder weitergeleitet werden, basierend auf Entscheidungen innerhalb des PTP-Prozesses selbst. Sie können wählen, ob die Nachricht verworfen wird, wenn die Zieladresse der PTP-Nachricht keine Adresse des BC ist, oder ob sie an die Weiterleitungs-Engine gesendet wird, um an das Ziel weitergeleitet zu werden. Der zweite Fall kann verwendet werden, wenn die PTP-Nachricht für eine andere Domäne als den BC bestimmt ist. Auch in letzterem Fall könnte das den BC enthaltende Netzelement das Korrekturfeld etwaiger weitergeleiteter Ereignismeldungen auch aktualisieren, um die PTP-Nachrichtenextraktion und -verarbeitung zu kompensieren, d.h. die transparente Taktfunktion für diese Nachrichten zu unterstützen. Die Nachrichtenextraktion von der IP-Ebene kann erreicht werden, wenn der Router das richtlinienbasierte Routing von IP-Paketen unterstützt.

Dieses Beispiel ist in diesem Bild dargestellt.

Option 4: Nutzung des TTL-Mechanismus (Time to Live) von IP-Transport:

Ein PTP-Knoten kann PTP-Pakete senden, wobei der IP-/Transport-Header ein TTL-Feld enthält, das auf die Mindestanzahl von Routing-Hops festgelegt ist, die erforderlich sind, um den Peer-PTP-Port zu erreichen, mit dem ein PTP-Vertrag besteht. In einem typischen PTP-unbewussten Netzwerk mit Routern ohne Erkennung zwischen MasterClock und SlaveClock wird die PTP-Nachricht von einem der Router ohne Erkennung verworfen, wenn die Anzahl der Router ohne PTP-Erkennung größer ist als der TTL-Wert der PTP-Nachricht. Auf diese Weise kann die Anzahl der IP-Hops, die von PTP-Paketen zwischen benachbarten Routern durchlaufen werden, begrenzt und die Kommunikation über unerwünschte längere Pfade vermieden werden.

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

Wenn beispielsweise ein SlaveClock über einen direkt verbundenen MasterClock verfügt, der auch über einen längeren Pfad erreichbar ist, kann der TTL-Wert 1 verwendet werden, um sicherzustellen, dass PTP-Pakete den MasterClock nur über den direkt verbundenen Pfad erreichen, und nicht über den längeren Pfad um den Ring.

Servo-Algorithmus

Beschreibung der Modi:

• Free-Run-Modus:

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

• Erfassungsmodus:

Die PTP-Uhr wird mit einer Zeitquelle synchronisiert. Dauer und Funktionalität dieses Modus sind implementierungsspezifisch. Dieser Modus ist für die Implementierung nicht erforderlich.

• Freq/Phase-Locked-Modus:

Phasensperre - Die PTP-Uhr ist phasensynchron mit einer Zeitquelle und liegt innerhalb einer akzeptablen internen Genauigkeit.

Frequency Lock - Die Uhr ist mit einer Zeitquelle frequenzsynchronisiert und liegt innerhalb einer akzeptablen internen Genauigkeit.

In Bezug auf den in [IEEE 1588] definierten PTP-Portstatus befindet sich eine Uhr im Sperrmodus, wenn sich ein PTP-Port im SLAVE-Status befindet.

• Holdover-Modus:

Die PTP-Uhr ist nicht mehr mit einer Zeitquelle synchronisiert und verwendet Informationen, die während der vorherigen Synchronisierung gewonnen wurden oder andere Informationsquellen noch verfügbar waren, um die Leistung innerhalb der gewünschten Spezifikation aufrechtzuerhalten oder um die Leistung innerhalb der gewünschten Spezifikation nicht aufrechtzuerhalten. Der Knoten verlässt sich möglicherweise allein auf seine eigenen Einrichtungen zur Überbrückung oder verwendet eine Art Frequenzeingang des Netzwerks, um eine Überbrückung von Zeit und/oder Phase zu erreichen.

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

Der Router ermöglicht die Auswahl separater Quellen für die Frequenz und die Tageszeit. Die Frequenzauswahl kann zwischen einer beliebigen Frequenzquelle erfolgen, die dem Router zur Verfügung steht, z. B. BITS, GPS, SyncE oder IEEE 1588 PTP. Die ToD-Auswahl erfolgt zwischen der für die Frequenz ausgewählten Quelle und PTP, sofern verfügbar (ToD-Auswahl aus GPS, DTI oder PTP). Dies wird als Hybridmodus bezeichnet, bei dem eine physische Frequenzquelle (BITS oder SyncE) für die Frequenzsynchronisierung und PTP für die ToD-Synchronisierung verwendet wird.

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

Das lokale Prioritätsattribut wird in Announce-Nachrichten nicht übertragen. Dieses Attribut wird im Vergleichsalgorithmus des Datensatzes als Zeittrenner verwendet, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind

8275.1:

	Grenzuhr
	Konfiguration	Erläuterung
PPTP	PPTP
	Clock
	Bereich 24
	Profil g.8275.1 Taktart T-BC	Profil 8275.1 wird mit Uhrenrolle als T-BC-Telekom-Grenzuhr verwendet
	!
	Profil T-BC-MasterClock	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-Ethernet	Ethernet-Transport wird verwendet
	Portstatus MasterClock-only	Der zu verwendende Port-Status ist nur MasterClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	Profil T-BC-SLAVE	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-Ethernet	Ethernet-Transport wird verwendet
	Portstatus SlaveNur Uhr	Der zu verwendende Port-Status lautet nur SlaveClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-BC-MasterClock	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	!
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-BC-SLAVE	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 130
	!
	!
SynchronisierenE	Frequenzsynchronisation	Globale Unterstützung
	Qualität itu-t Option 1	QL der empfangenen Uhr entspricht der Option 1 für "itu-t"
	Änderung der Logauswahl
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	Frequenzsynchronisation	SyncE an Schnittstelle aktivieren
	Auswahleingabe	Schnittstelle im SlaveClock-Status für SyncE
	Priorität 15	lokal von Bedeutung. Verwaltung der Uhrenauswahl durch Ändern der Priorität der Uhrenquellen
	wait-to-restore 0	Der Zeitraum, den der Router wartet, bevor eine neu aktive synchrone Ethernet-Taktquelle in die Uhrenauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	Frequenzsynchronisation	SyncE an Schnittstelle aktivieren
	wait-to-restore 0	Der Zeitraum, den der Router wartet, bevor eine neu aktive synchrone Ethernet-Taktquelle in die Uhrenauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.
	Großmeisteruhr
	Konfiguration	Erläuterung
PPTP	PPTP	Globale Aktivierung von PPP
	clock
	Bereich 24
	Profil g.8275.1 Taktart T-GM	Profile 8275.1 wird mit Uhrenrolle für T-GM Telecom Grand MasterClock verwendet
	!
	Profil T-MasterClock	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-Ethernet	Ethernet-Transport wird verwendet
	Portstatus MasterClock-only	Der zu verwendende Port-Status ist nur MasterClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-MasterClock	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	!
	!
	!
SynchronisierenE	Frequenzsynchronisation	Globale Unterstützung
	Qualität itu-t Option 1	Zum Konfigurieren der ITU-T-QL-Optionen ITU-T Option 1 ist auch die Standardeinstellung
	Änderung der Logauswahl	Protokollierung aktivieren
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	Frequenzsynchronisation	SyncE an Schnittstelle aktivieren
	wait-to-restore 0	Der Zeitraum, den der Router wartet, bevor eine neu aktive synchrone Ethernet-Taktquelle in die Uhrenauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.
	SlaveClock
	Konfiguration	Erläuterung
PPTP	PPTP	Globale Aktivierung von PPP
	clock
	Bereich 24
	Profil g.8275.1 Taktart T-TSC	Profile 8275.1 wird mit Uhrenrolle für T-TSC Telecom SlaveClock verwendet
	!
	Profil T-SLAVE	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-Ethernet	Ethernet-Transport wird verwendet
	Portstatus SlaveNur Uhr	Der zu verwendende Port-Status lautet nur SlaveClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-SLAVE	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	!
	!
	!
SynchronisierenE	Frequenzsynchronisation	Globale Unterstützung
	Qualität itu-t Option 1	Zum Konfigurieren der ITU-T-QL-Optionen ITU-T Option 1 ist auch die Standardeinstellung
	Änderung der Logauswahl	Protokollierung aktivieren
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	Frequenzsynchronisation	SyncE an Schnittstelle aktivieren
	Auswahleingabe	Schnittstelle im SlaveClock-Status für SyncE
	Priorität 15	lokal von Bedeutung. Verwaltung der Uhrenauswahl durch Ändern der Priorität der Uhrenquellen
	wait-to-restore 0	Der Zeitraum, den der Router wartet, bevor eine neu aktive synchrone Ethernet-Taktquelle in die Uhrenauswahl aufgenommen wird. Der Standardwert ist 300 Sekunden.
	!

8275.2:

	Grenzuhr
	Konfiguration	Erläuterung
PPTP	PPTP
	clock
	Bereich 44
	Profil g.8275.2 Taktart T-BC	Profil 8275.2 wird mit Uhrenrolle als T-BC-Telekom-Grenzuhr verwendet
	!
	Profil T-BC-MasterClock	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-IPv4	Ethernet-Transport wird verwendet
	Portstatus MasterClock-only	Der zu verwendende Port-Status ist nur MasterClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	Profil T-BC-SLAVE	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-IPv4	Ethernet-Transport wird verwendet
	Portstatus SlaveNur Uhr	Der zu verwendende Port-Status lautet nur SlaveClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-BC-MasterClock	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	!
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	ip address 10.0.0.0.1 255.255.255.252
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-BC-SLAVE	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 130
	MasterClock ipv4 10,0.0,2 255,255,255,252	expliziter Verweis auf die MasterClock-IP
	!
	Großmeisteruhr
	Konfiguration	Erläuterung
PPTP	PPTP	Globale Aktivierung von PPP
	clock
	Bereich 44
	Profil g.8275.2 Taktart T-GM	Profile 8275.1 wird mit Uhrenrolle für T-GM Telecom Grand MasterClock verwendet
	!
	Profil T-MasterClock	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-IPv4	Ethernet-Transport wird verwendet
	Portstatus MasterClock-only	Der zu verwendende Port-Status ist nur MasterClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/18	MasterClock-Schnittstelle. Mit nachgeschaltetem SlaveClock verbunden
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-MasterClock	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	!
	!
	!
	SlaveClock
	Konfiguration	Erläuterung
PPTP	PPTP	Globale Aktivierung von PPP
	clock
	Bereich 44
	Profil g.8275.2 Uhrentyp T-TSC	Profile 8275.1 wird mit Uhrenrolle für T-TSC Telecom SlaveClock verwendet
	!
	Profil T-SLAVE	Definieren Sie eine Rolle für den PPP-Port.
	Multicast Zieladressen-Ethernet 01-80-C2-00-00-0E	Es wird eine nicht weiterleitbare Multicast-Adresse verwendet (optional)
	Transport-IPv4	Ethernet-Transport wird verwendet
	Portstatus SlaveNur Uhr	Der zu verwendende Port-Status lautet nur SlaveClock.
	Synchronisierungsfrequenz 16	Synchronisierungspakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	Ankündigungsfrequenz 8	Mitteilen von Paketen mit einer Paketfrequenz pro Sekunde
	Frequenz der Verzögerungsanforderung 16	Delay_Req-Pakete werden mit einer Paketfrequenz pro Sekunde gesendet.
	!
	!
	interface TenGigE0/0/0/19	SlaveClock-Schnittstelle. Mit Upstream-MasterClock verbundener Port
	ip address 10.0.0.0.1 255.255.255.252
	PPTP	Für diesen Port aktiviertes PPP
	Profil T-SLAVE	Benutzerdefinierte Rolle unter diesem PPTP-Port
	Lokale Priorität 120	localPriority-Attribut, das im Vergleichsalgorithmus für Datensätze als Trennzeichen verwendet wird, wenn alle anderen vorherigen Attribute der zu vergleichenden Datensätze gleich sind
	MasterClock ipv4 10,0.0,2 255,255,255,252	die MasterClock-IP explizit erwähnen
	!
	!
	!

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

SynchronisierenE	Frequenzsynchronisation
	Qualität itu-t Option 1
	Änderung der Logauswahl
	!
	interface TenGigE0/0/0/19
	Frequenzsynchronisation
	SSM deaktivieren
	quality receive exact itu-t option 1 PRC
	Auswahleingabe
	Priorität 15
	wait-to-restore 0
	!

Um den Hybridmodus mit 8275.2 zu verwenden, verwenden Sie "Physical Layer Frequency" unter der Schnittstelle. Dadurch wird SyncE für die Frequenz und ptp für die Phase aktiviert.

Um den Hybridmodus mit 8275.2 zu aktivieren, muss "physical-layer-frequency" (Frequenz der physischen Schicht) unter "global ptp" konfiguriert werden.

PPTP

clock

Bereich 44

Profil g.8275.2 Taktart T-BC

!

Profil 82752

Transport-IPv4

Synchronisierungsfrequenz 16

Ankündigungsfrequenz 8

Frequenz der Verzögerungsanforderung 16

!

Frequenz der physikalischen Schicht

Logbuch

Servoereignisse

!

!

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

 !

!

Fehlerbehebung bei PTP

Einige zeigen Befehle an und beschreiben ihre Ausgaben.

1. Der Servostatus am Ende des Servoalgorithmus muss Phase_Locked (Phase_Gesperrt) lauten. Sie können den Status-Fluss für das Servo sehen. Wenn der Servomodus Hybrid ist, muss auch der SyncE-Fluss beachtet werden, da die Phasensperre nur nach Freq_Lock erfolgt. Wenn das PTP-Gerät ein gewöhnlicher MasterClock ist, ist die obige Ausgabe möglicherweise nicht gültig, da der Servo-Algorithmus nicht ausgeführt wird und er nicht von einer anderen MasterClock-Quelle synchronisiert werden muss.

Der Gerätestatus wechselt nur dann zu LOCK, wenn der Offset innerhalb eines akzeptablen Bereichs liegt. Überprüfen Sie auch den ‘Offset von MasterClock’.

Gerätestatus:

FREE-RUN/HOLDOVER: Nicht an eine Taktquelle gebunden. 
FREQ_LOCKED: Frequenz mit MasterClock synchronisiert

PHASE_LOCKED: Synchronisierung von Frequenz und Phase mit MasterClock

Servomodus:

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

Standard: PTP zum Synchronisieren von Frequenz und Phase verwenden

Zeitdifferenz beobachtet durch Servoalgorithmus b/w SlaveClock und MasterClock.

Zähler für Zeitstempel, die aus PTP-Paketen extrahiert wurden. Sollte weiter zunehmen.

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

T1/T4: Gesendet von MasterClock, T2/T3: Berechnet bei SlaveClock

Offset berechnet auf Basis von PTP-Zeitstempeln.

Grobe (setTime, stepTime) und feine (adjustFreq) Einstellungen durch ein Servo, um sich mit der MasterClock auszurichten.

3. show ptp interfaces brief zeigt den Zustand des Ausgangsports. Der Status sollte "MasterClock/SlaveClock" lauten.

4. Die Paketverluste durch ptp müssen signifikant gering sein.

5. Überprüfen Sie den Grund für das Verwerfen des Pakets:

6. Pakete erreichen PTP nicht.

Erreichen die Pakete NPU?

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>

Verwerfungen bei SPP überprüfen:

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 befolgt wird (und Follow_Up, wenn es sich um eine 2-Schritt-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 ist QLsnd DNU, um Schleifen zu vermeiden. Um Ihre Schnittstelleneinstellungen zu ändern, können Sie das Prioritätsattribut ändern, das standardmäßig 100 ist.

10. Stellen Sie sicher, dass die gewählte SyncE-Schnittstelle die Option "Output Driven by" ist.

11. show ptp foreign-MasterClocks kurze Ausgabe ist die Liste der PPP-Geräte, die an der BMCA teilnehmen, um MasterClocks zu werden. Markieren Sie die entsprechenden Flags, um die ausgewählte MasterClock anzuzeigen. Meldungen, die von diesen Ports empfangen wurden, können über show ptp packet-counters <interface-id> angezeigt werden. Das Gerät mit den besten Eigenschaften gewinnt die BMCA. Wenn mehrere Ports über die gleichen Attribute verfügen, ist "local-priority" der letzte Timer. Die automatische Topologieerstellung ist jedoch mit ptp auch ohne Verwendung von local-priority möglich.

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

Vom Remote-Knoten angekündigte Uhr überprüfen:

show ptp foreign-MasterClocks 

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

  IPv4, Address X.X.X.X, 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 der qualifizierten und ausgewählten MasterClocks:

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 bei 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 wird nicht mit MasterClock synchronisiert:

•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 flapping:

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 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 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 Sync-, Announce-, Delay_Req- und Delay_Resp-Nachrichten

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

Die Erfassung der Synchronisierungsnachricht zeigt die Zeitstempelgenerierung (ein Schritt) an.

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
• IEEE-Standard 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