PTP-Designempfehlungen für R-PHY-Netzwerke
Inhalt
Einführung
Dieses Dokument beschreibt das Precision Time Protocol (PTP), das in Kabelnetzwerken mit cBR-8- und Remote PHY-Netzwerken (R-PHY) verwendet wird. Ziel ist es, ein globales Verständnis des Protokolls und dessen Konfiguration in cBR-8- und RPHY-Bereitstellungen zu vermitteln.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
- R-PHY.
- cBR-8 Converged Cable Access Platform (CCAP)
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
- cBR-8 läuft ab Version 16.6.1.
- Cisco RPD (Remote PHY Device), 1 x 2.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Hintergrund
Um Modems die Zeitschlitze (Minislots) für die Übertragung auf einem Upstream-Kanal zu gewähren, ordnet CCAP Upstream-Minislot-Zuweisungen mittels Upstream-MAP-Nachrichten (Bandbreitenzuweisung) zu. Diese MAP-Nachrichten werden im Downstream gesendet und von allen Modems empfangen.
Die Modems sehen sich diese Meldungen an, um zu ermitteln, welche Minislots welchen Modems zugewiesen sind und welche für konfliktbasierte Aktivitäten. Ein Modem überträgt Datenverkehr nur über einen ihm zugewiesenen Minislot (oder über einen Konfliktplatz, wenn es eine Bandbreitenanforderung oder eine andere Station-Wartungsaktivität sendet).
Die MAP-Nachrichten des CCAP weisen etwa 2 Millisekunden (ms) Zeit zu. DOCSIS (LLD) mit niedriger Latenz bietet Optionen zur Reduzierung dieses Werts unter 2 ms.
Um Überschneidungen zu vermeiden, müssen CCAP und jedes Modem das gleiche Zeitkonzept haben.
Die CCAP muss sicherstellen, dass sie einem Modem nach einer Anfrage nicht zu schnell einen Zeitschlitz zuweist, um zu verhindern, dass das Modem keine Zeit hat, die MAP-Nachricht zu empfangen und zu verarbeiten, und dass die Möglichkeit zur Verwendung dieses Minislots verpasst wird.
Um diese Situation zu vermeiden, verwendet der CCAP einen Timer für die vorzeitige MAP-Verarbeitung, bei dem der Datenverkehr für ein Modem erst zu einem Zeitpunkt nach dem vorzeitigen MAP-Timer geplant wird.
Das für die vorgelagerte Planung erforderliche Zeitelement des DOCSIS ist in R-PHY noch vorhanden. Zur Verbindung der RPDs mit dem CCAP wird ein Converged Interconnect Network (CIN) verwendet, das IP-basiert ist und für den Kabelzugriff reserviert oder von anderen Anwendungen gemeinsam genutzt werden kann.
Der CCAP-Core übernimmt die vorgelagerte Planung und Generierung von MAP-Nachrichten. Die Downstream- und Upstream-Signale beginnen und enden nun physisch auf der RPD, daher muss die RPD das gleiche Zeitkonzept haben wie der CCAP-Core.
Die Remote DOCSIS Timing Interface Specification (R-DTI) ist die Spezifikation von CableLabs, in der beschrieben wird, wie dieses Timing abläuft. Für Ethernet-basierte Netzwerke wird PTP verwendet, um dieses Timing zu erreichen.
In der aktuellen Implementierung von Cisco fungieren sowohl der cBR-8 als auch der RPD als Slave-Gerät für eine PTP-Referenzuhr.
Precision Time Protocol (PTP)
Einführung
PTP ermöglicht es einer Slave-Uhr, den Zeitversatz von einer Referenzuhr (Zeitdifferenz zwischen den Uhren) sowie die Übertragungsverzögerung im Transportnetzwerk zwischen den beiden Uhren zu bestimmen.
Die Master- und Slave-Geräte tauschen Nachrichten aus, die Zeitstempel enthalten, bevor der Slave einen Algorithmus zur Bestimmung dieser Werte ausführt.
Die Formeln für diese Berechnung gehen von einer symmetrischen Verbindung zwischen den beiden Uhren aus.
Nicht symmetrische Verbindungen wie das Ethernet Passive Optical Network (EPON) sind in der R-DTI-Spezifikation für die Verwendung als CIN aufgeführt, basieren jedoch auf einer anderen Zeitsteuerungsmethode, die derzeit von Cisco nicht unterstützt wird.
Die RPD-Funktion sollte die Referenzuhr über das CIN erreichen. Der cBR-8 kann über WAN-Schnittstellen (Wide Area Network) auf der Physical Interface Card (PIC) des Supervisors oder über Digital PIC (DPIC)-Schnittstellen auf der Line Card des Kabels auf die Referenzuhr zugreifen (die DPIC-Option wurde in Version 16.8.1 hinzugefügt). Es wird empfohlen, dass die RPD nicht den cBR-8 durchläuft, um auf die Referenzuhr zuzugreifen.
RPD und cBR-8 können in der aktuellen Software nur als Slave-Uhren funktionieren, obwohl die cBR-8 Roadmap die Unterstützung als primäre Referenzuhr und Boundle-Uhr bietet.
Dies bedeutet, dass sich Probleme mit der PTP-Uhrenstabilität auf alle Modems in einem Chassis auswirken, auch auf Integrated CCAP (I-CCAP) Line Cards, wenn Sie eine Kombination von Karten in einem Chassis verwenden.
Protokoll
PTP ist gemäß IEEE-Standard 1588-2008 definiert.
Die vollständigen Spezifikationen finden Sie hier: 1588-2008 - IEEE Standard für ein Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.
PTP ermöglicht die Verteilung von Zeit und Frequenz über ein Netzwerk:
- Zeit (Synchronisierung): Synchronisiert die Zeit zwischen Geräten in einem Netzwerk.
- Häufigkeit (Synchronisierung): Synchronisiert die Frequenz.
PTP verwendet Multicast- oder Unicast-Nachrichten und Ports UDP 319 (Für Ereignisse)- und UDP 320 (für allgemeine Meldungen).
Bei der CMTS-Implementierung verwendet PTP IPv4-Unicast.
Das Protokoll erstellt eine Master-Slave-Beziehung zwischen einer Großmaster-Uhr und Client-Geräten über das Netzwerk. PTP wählt eine Uhr für die Verteilung in einem Netzwerk mithilfe eines Algorithmus aus, der als Best Master Clock Algorithm (BCMA) bezeichnet wird.
Der Algorithmus bestimmt die beste Uhr in einem Netzwerk mit den folgenden Eigenschaften:
- Kennung (Nummer, die aus der MAC-Adresse des Geräts erstellt wurde, sieht in der Regel aus wie das Format EUI-64 (xxxx:xxFF:FExx:xxxx).
- Qualität.
- clockGenauigkeit: Bestimmt, wie genau die Uhr ist. Je geringer die Zeit, desto besser (desto genauer).
Value (hex) Specification
00-1F Reserved
20 The time is accurate to within 25 ns
21 The time is accurate to within 100 ns
22 The time is accurate to within 250 ns
23 The time is accurate to within 1 µs
24 The time is accurate to within 2.5 µs
25 The time is accurate to within 10 µs
26 The time is accurate to within 25 µs
27 The time is accurate to within 100 µs
28 The time is accurate to within 250 µs
29 The time is accurate to within 1 ms
2A The time is accurate to within 2.5 ms
2B The time is accurate to within 10 ms
2C The time is accurate to within 25 ms
2D The time is accurate to within 100 ms
2E The time is accurate to within 250 ms
2F The time is accurate to within 1 s
30 The time is accurate to within 10 s
31 The time is accurate to >10 s
32–7F Reserved
80–FD For use by alternate PTP profiles
FE Unknown
FF Reserved
-
clockClass:Gibt die Nachvollziehbarkeit der Uhrzeit und Frequenz an, die von der GrandMaster-Uhr verteilt werden.
Uhrenklassen sind in den Spezifikationen IEEE 1588-2008 als solche definiert:
clockClass (decimal)-Spezifikation
0 Reserved to enable compatibility with future versions.
1–5 Reserved.
6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be PTP. A clockClass 6 clock shall not be a slave to another clock in the domain.
7 Shall designate a clock that has previously been designated as clockClass 6 but that has lost the ability to synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The timescale distributed shall be PTP. A clockClass 7 clock shall not be a slave to another clock in the domain.
8 Reserved.
9–10 Reserved to enable compatibility with future versions.
11–12 Reserved.
13 Shall designate a clock that is synchronized to an application-specific source of time. The timescale distributed shall be ARB. A clockClass 13 clock shall not be a slave to another clock in the domain.
14 Shall designate a clock that has previously been designated as clockClass 13 but that has lost the ability to synchronize to an application-specific source of time and is in holdover mode and within holdover specifications. The timescale distributed shall be ARB. A clockClass 14 clock shall not be a slave to another clock in the domain.
15–51 Reserved.
52 Degradation alternative A for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 52 shall not be a slave to another clock in the domain.
53–57 Reserved.
58 Degradation alternative A for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 58 shall not be a slave to another clock in the domain.
59–67 Reserved.
68–122 For use by alternate PTP profiles.
123–127 Reserved.
128–132 Reserved.
133–170 For use by alternate PTP profiles.
171–186 Reserved.
187 Degradation alternative B for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 187 may be a slave to another clock in the domain.
188–192 Reserved.
193 Degradation alternative B for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 193 may be a slave to another clock in the domain.
194–215 Reserved.
216–232 For use by alternate PTP profiles.
233–247 Reserved.
248 Default. This clockClass shall be used if none of the other clockClass definitions apply.
249–250 Reserved.
251 Reserved for version 1 compatibility; see Clause 18.
252–254 Reserved.
255 Shall be the clockClass of a slave-only clock; see 9.2.2.
- Priorität - Ein administrativ zugewiesener Wert (zwischen 0 und 255)
- Abweichung - Die geschätzte Stabilität der Uhr
Master- und Slave-Timestamp-Exchange-Prozess
- Der Master sendet eine Synchronisierungsnachricht an den Slave und notiert die Uhrzeit (t1), zu der er gesendet wurde.
- Der Slave empfängt die Synchronisierungsmeldung und notiert die Uhrzeit des Empfangs (t2).
- Der Master überträgt dem Slave den Zeitstempel t1. es fügt den Timestamp t1 in eine Follow_Up-Meldung ein.
- Der Slave sendet eine Delay_Req-Nachricht an den Master und notiert die Uhrzeit (t3), zu der er gesendet wurde.
- Der Master empfängt die Nachricht Delay_Req und notiert die Uhrzeit des Empfangs (t4).
- Der Master überträgt dem Slave den Zeitstempel t4. sie wird in eine Delay_Resp-Nachricht eingebettet.
Dieser Prozess wird mehrmals pro Sekunde wiederholt (in der Regel 16 bis 32 Mal pro Sekunde), um eine schnelle Anpassung bei kleinen Offset-Änderungen zu gewährleisten.
GrandMaster-Uhr
Der GrandMaster kommuniziert mit den Sklaven, die Sitzungen mit dem Großmeister aufgebaut haben, um die Synchronisierungs- (Zeit) und Synchronisierungsinformationen an diese Slaves auszutauschen. Ein GrandMaster muss theoretisch mit einem PRTC (Prime Reference Time Clock) verbunden werden, wie z.B. über eine GPS-Antenne. Wenn ein GrandMaster ausfällt und ein anderer GrandMaster übernimmt, da beide die gleiche Zeitreferenz verwenden, verwenden die Slaves weiterhin die gleiche Zeitreferenz. Wenn Sie kein PRTC verwenden, führt der Ausfall einer GrandMaster-Uhr dazu, dass die Slaves die Zeitreferenz ändern, was in CMTS-Szenarien dazu führt, dass die Modems offline gehen.
Slave-Uhr
Der Slave initiiert die Verbindung mit der GrandMaster-Uhr. Sowohl Slave als auch Master tauschen ihre Konfigurationseinstellungen und Uhreneinstellungen aus, um die Aushandlung zu starten. In diesem Fall sind cBR-8 und RPD beide Slave zu einem externen PTP GrandMaster.
Grenzuhr
Die Boundary Clock synchronisiert zwei Netzwerksegmente miteinander. Funktioniert als Slave zu einer GM-Uhr auf Segment 1 und fungiert dann als GM-Uhr auf Segment 2. Nicht grenzübergreifende Uhren werden als "normale Uhren" bezeichnet.
Uhrenklassen
Uhrenklassen sind einer der Werte, die während der Aushandlung verwendet werden, um die Uhr in einem Netzwerk mit mehreren Uhren die genaueste zu finden.
Uhrenklassen sind durch IEEE 1588-2008 definiert.
Uhrstatus
- FREERUN: Keine Verbindung mit Remote-GM, verwendet lokalen Oszillator.
- HALBER: Verbindung mit einem Remote-GM verloren, versuchen Sie, diese wiederherzustellen, und versuchen Sie, die vorherige Uhr beizubehalten. Während des HOLDOVER-Zustands kann die Uhr anfangen zu driften, und wenn sie außerhalb der Spezifikationen treibt, geht sie zurück in den FREERUN-Modus.
- ERWERB: Verhandlung mit GM gestartet und Nachrichten mit dem GM ausgetauscht, um die vom Netzwerk verursachte Verzögerung zu ermitteln und eine Synchronisierung mit der GM-Uhr zu versuchen.
- FREQ_LOCKED: Das Slave-Gerät ist hinsichtlich der Frequenz auf den Master beschränkt, jedoch nicht phasengesteuert.
- PHASE_ALIGNED: An den Kapitän in Bezug auf Häufigkeit und Phase verriegelt.
Statusmaschine für RPD:
PTP-Domänen
Die PTP-Domäne ist eine Zahl, die eine Gruppe von Geräten identifiziert, die miteinander kommunizieren. Slave- und Master-Geräte müssen sich in derselben PTP-Domäne befinden, damit sie miteinander synchronisiert werden können. Domäne 0 ist die Standarddomäne, und die Domänen 1-2-3 sind pro Spezifikation reserviert. Andere Domänennummern können 4-255 sein,
Beachten Sie, dass bei einigen PTP-Varianten wie G.8275.2 die PTP-Domäne im Bereich 44-63 liegen muss. Wenn Sie diese Variante nicht verwenden, vermeiden Sie die Verwendung dieses Bereichs von PTP-Domänen, da dies sowohl den Benutzer als auch das Gerät verwirren könnte.
PTP-Profile
PTP-Profile wurden in den IEEE-Standard 1588-2008 eingeführt und bestehen aus einer Reihe von Konfigurationsoptionen, die ausgewählt werden können, um die Anforderungen verschiedener Anwendungen zu erfüllen. Es ist möglich, separate Profile zu definieren, um PTP an verschiedene Szenarien anzupassen.
Beispiele für gängige PTP-Profile:
- Telecom-2008 Profil: Generisches Profil, das vor den Spezifikationen von G.8265.1 verwendet wurde. Dieses Profil verwendet die Domänennummern 0-4. Dieses Profil wird auf cBR-8 und RPD unterstützt, G.8275.2 wird jedoch dringend empfohlen, da es ausfallsicherer ist.
- G.8265.1: Precision Time Protocol Telecom-Profil für die Frequenzsynchronisierung
Dieses Profil ist für Anwendungen vorgesehen, die nur über Telekommunikationsnetzwerke eine Frequenzsynchronisierung erfordern. Die Phasenausrichtung und/oder Tageszeit werden nicht berücksichtigt.
Der Anwendungsfall wäre für PTP-Master und Slaves in Netzwerken, in denen die Zwischenknoten keine PTP-Unterstützung bieten.
- G.8275.1: Precision Time Protocol Telecom-Profil für Phase-/Zeitsynchronisierung mit voller Timing-Unterstützung durch das Netzwerk
Dieses Profil wird bei Systemen verwendet, die eine genaue Synchronisierung der Zeit und Phase in Telekommunikationsnetzen erfordern (z. B. 4G-Mobilfunknetz oder RPD-Netzwerk), bei denen eine Phasensynchronisierung und/oder eine Synchronisierung der Tageszeit erforderlich ist.
Bei diesem Profil ist jedes Netzwerkgerät am PTP-Protokoll beteiligt. An jedem Knoten in der Kette zwischen PTP Grandmaster und PTP Slave wird eine Grenzuhr verwendet, was die Akkumulation von Zeitfehlern im Netzwerk reduziert.
- G.8275.2 : Precision Time Protocol Telecom-Profil für die Zeitsynchronisierung mit partieller Timing-Unterstützung aus dem Netzwerk
Dieses Profil basiert auf teilweiser Timing-Unterstützung durch das Netzwerk. Das bedeutet, dass die Knoten der PTP-Domäne nicht direkt verbunden werden müssen.
Wie G.8275.1 wird es in Systemen verwendet, die eine präzise Synchronisierung von Zeit und Phase erfordern, jedoch die Synchronisierung von Zeit und Phase über vorhandene Netzwerke ermöglichen. Bei Bedarf werden Grenzwertuhren verwendet, um das Zeitsignal im gesamten Netzwerk anzupassen.
Weitere Informationen zu G.8275.1 und G.8275.2 für die ASR900-Plattform finden Sie hier: Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)
Definition von Basisnachrichten
- Sync, Follow_up, Delay_req, Delay_resp sind Nachrichten, die von der Grenze und normalen Uhren verwendet werden, um Zeitinformationen an Slaves im Netzwerk zu übermitteln.
- Ankündigungsnachrichten werden von Slaves und Master ausgetauscht, um die beste Uhr im Netzwerk mithilfe des Best Master Clock Algorithm zu identifizieren (siehe die Images 26, 27, 28 der IEEE-Spezifikationen für den detaillierten Mechanismus).
- Signalisierungsnachrichten werden für nicht zeitkritische Informationen verwendet.
Anforderungen
Diese Anforderungen müssen erfüllt sein, damit PTP in cBR-8 und R-PHY in einem Produktionsnetzwerk korrekt bereitgestellt werden kann:
- Verwenden Sie das PTP-Profil G.8275.2, um sicherzustellen, dass PTP auch dann funktioniert, wenn einige Netzwerkelemente im Pfad PTP nicht unterstützen.
- Keine Equal Cost Multi Path (ECMP), Load Balancing oder asymmetrischen Pfade: PTP geht immer davon aus, dass die Verzögerung vom Master zum Slave und umgekehrt gleich ist und innerhalb von 500 Mikrosekunden (µs)
- Konfigurieren Sie Verzögerungs-Aufgaben und Synchronisierungsintervalle mit den Werten -4 oder -5 (weitere Informationen finden Sie im Kapitel Konfiguration). Werte größer als -4 (-3, ...) bieten möglicherweise nicht genügend Genauigkeit, um kleine Offset-Änderungen zu erkennen. Werte unter -5 (-6, ...) haben eine höhere Auswirkung auf die Netzwerknutzung, aber keine signifikante Präzisionszunahme.
- Stellen Sie sicher, dass PTP-Pakete für RPD nicht durch cBR-8 geleitet werden.
- Stellen Sie einen minimalen Jitter im IP-Netzwerk (max. 1 ms) sicher. Auf allen Routern muss die richtige PTP-QoS angewendet werden: cBR-8 und RPD senden alle mit Differentiated Services Code Point (DSCP) 46 markierten PTP-Pakete (Express Forwarding - EF). Stellen Sie sicher, dass die PTP Grand Master-Uhr auch Pakete mit demselben DSCP-Wert markiert.
- Die PTP Grand Master-Uhr muss mit GPS synchronisiert sein und die Uhr-Klasse 6 melden, damit sie in einem Produktionsnetzwerk verwendet werden kann. Laborumgebungen können mit einem eigenständigen, kostenlosen PTP Grand Master (Takt-Klasse 58) ausgeführt werden.
- Die PTP Grand Master-Uhr muss eine Uhrengenauigkeit von 100 Nanosekunden aufweisen.
- Wenn zwei PTP Grand Master-Uhren verwendet werden, müssen Sie GPS verwenden, um die Synchronisierungszeit zwischen ihnen zu synchronisieren. Beide PTP Grand Masters müssen ihre Uhren innerhalb von 500 Mikrosekunden (µs) haben.
Konfiguration
In diesem Abschnitt wird beschrieben, wie Sie eine PTP-Referenzuhr auf einem Cisco ASR900-Router konfigurieren, die Slave-Uhr auf cBR-8 für cBR-8 selbst und RPD sowie eine Grenzuhr auf dem ASR900.
PTP Master Clock für ASR900
Es gibt unter Linux eine PTP-Protokoll-Basisimplementierung mit dem Namen "ptpd". Da es jedoch softwarebasiert ist, bietet es nicht genügend Präzision für die Arbeit mit cBR-8 und RPD, daher werden die Modems nicht online gehen können und auch die PTP-Synchronisierung wird nicht stattfinden. Darüber hinaus erfordert die PTPd-Linux-Implementierung eine Hardware-Zeitstempel durch die Netzwerkkarte, um die Genauigkeit zu erhöhen. Das bedeutet, dass PTPd bei Verwendung eines virtuellen Systems oder einer Netzwerkkarte, die keine Hardware-Zeitstempel unterstützt, unter Linux möglicherweise überhaupt nicht gestartet wird.
Je nach verwendetem ASR900-Modell verfügt das Gerät möglicherweise über eine GPS-Antenne. Wenn der ASR900 keine GPS-Antenne hat, haben Sie kein PRTC, aber Sie können den ASR900 weiterhin als Grandmaster mit einem lokalen PRTC (interner Oszillator) ausführen. Wenn dieser ASR900 ausfällt und ein anderer ASR900 den Betrieb übernimmt, verlieren cBR-8 und RPD die Zeitreferenz, da beide Uhren nicht wirklich synchronisiert sind.
Schritt 1: Konfigurieren des lokalen internen Oszillators
network-clock source quality-level QL-PRC tx
network-clock synchronization automatic
network-clock synchronization mode QL-enabled
network-clock synchronization squelch-threshold QL-PRC
network-clock quality-level tx QL-PRC ptp domain 0
network-clock input-source 1 External R0 10m
Schritt 2: Konfigurieren Sie PTP als Master auf dem ASR900.
ptp clock ordinary domain 0 <<< DOMAIN 0 or DOMAIN 44 for G.8275.2
clock-port MASTER master [profile g8275.2] <<< EITHER DEFAULT OR G.8275.2 PROFILE
sync interval -4
sync one-step
transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface
interface Loopback1588
ip address 15.88.15.88 255.255.255.255
end
Wenn Sie das G.8275.2-Profil in Ihrer Umgebung anstelle des Standardprofils verwenden, müssen Sie es in der Konfiguration des Uhrenports angeben (für die G.8275.2-Profilkonfiguration auf dem cBR-8 siehe Abschnitt: Das G.8275.2-Profil).
Beachten Sie, dass selbst wenn IOS-XE die Konfiguration des G.8265.1-Profils ermöglicht, dies in der DOCSIS-Umgebung mit cBR-8 und RPD nicht unterstützt wird.
Weitere Informationen zum G.8275.2-Profil auf dem ASR900 finden Sie in diesem Handbuch: Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)
Überprüfung
Dieser Abschnitt enthält Informationen, mit denen Sie überprüfen können, ob Ihre Konfiguration ordnungsgemäß funktioniert.
ASR900#show ptp clock running
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
FREQ_LOCKED 1 86307034 36108234 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
MASTER unicast master Lo1588 Master 1 -
ASR900#show ptp clock dataset parent
CLOCK [Ordinary Clock, domain 0]
Parent Clock Identity: 0x34:6F:90:FF:FE:C1:66:3F
Parent Port Number: 0
Parent Stats: No
Observed Parent Offset (log variance): 0
Observed Parent Clock Phase Change Rate: 0
Grandmaster Clock:
Identity: 0x34:6F:90:FF:FE:C1:66:3F
Priority1: 128
Priority2: 128
Clock Quality:
Class: 58
Accuracy: Within 1s
Offset (log variance): 52592
ASR900#show platform software ptpd stat stream 0
LOCK STATUS : FREERUN
SYNC Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval 0
Tx packets : 5577, Rx Packets : 0
Last Seq Number : 5577, Error Packets : 0
Delay Req Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 0, Rx Packets : 5353
Last Seq Number : 0, Error Packets : 0
Delay Response Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 5353, Rx Packets : 0
Last Seq Number : 0, Error Packets : 0
Announce Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 1904, Rx Packets : 0
Last Seq Number 1904 Error Packets 0
Signalling Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : 0, Acting Interval : 0
Tx packets : 1, Rx Packets : 1
Last Seq Number : 1, Error Packets : 0
Current Data Set
Offset from master : +0.0
Mean Path Delay : +0.0
Forward Path Delay : +0.0
Reverse Path Delay : +0.0
Steps Removed 0
General Stats about this stream
Packet rate : 0, Packet Delta (ns) : 0
Clock Stream handle : 0, Index : 0
Oper State : 0, Sub oper State : 6
Log mean sync Interval : 0, log mean delay req int : 0
Slave Clock auf cBR-8
Der cBR-8 fungiert als CCAP-Core für das RPD und ist daher für die PTP-Konfiguration sowohl der eigenen als auch der zugehörigen RPDs verantwortlich.
Der cBR-8 verwendet Profile, um diese PTP-Informationen an die RPDs zu übertragen. Für PTP stehen mehrere konfigurierbare Optionen zur Verfügung:
- Der Servoortyp für den cBR-8 muss auf R-DTI gesetzt werden, um die Uhrensynchronisierung zu beschleunigen.
- Der cBR-8 verwendet eine benutzerdefinierte Loopback-Adresse als Quelle seiner PTP-Pakete. Vergewissern Sie sich, dass ein ordnungsgemäßes Routing für die Referenzuhr vorhanden ist, um die Loopback-Schnittstelle zu erreichen. Wenn Sie nicht in der Lage sind, einen Ping an die Referenzuhr zu senden, wenn ein Paket von der Loopback-Adresse stammt, ist das PTP nicht betriebsbereit.
- Das G.8275.2-Telekommunikationsprofil wird empfohlen, da es IPv4 und IPv6 unterstützt. Zwischengeschaltete Switching-Geräte im CIN müssen nicht PTP-fähig sein.
- Die PTP-Domänennummer wird vom Benutzer gewählt, muss jedoch für cBR-8 und die RPDs identisch sein.
PTP-Pakete werden mit einer höheren QoS sowohl von der RPD als auch von der cBR-8 für die Priorität auf der CIN markiert. In beiden wird standardmäßig der DSCP-Wert 46/EF verwendet.
ptp clock ordinary domain 0
servo tracking-type R-DTI
clock-port TOMASTER slave
announce interval -3
announce timeout 10
delay-req interval -4 <<< RECOMMENDED VALUE
sync interval -4 <<< RECOMMENDED VALUE
transport ipv4 unicast interface Lo1588 negotiation <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface
clock source 15.88.15.88 <<< THIS IS YOUR PTP MASTER
clock source 15.88.2.8 1 <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)
In diesem Beispiel ist der Uhrenport so konfiguriert, dass er das Standard-PTP-Profil verwendet. Die Konfiguration des G.8275.2-Profils finden Sie im Abschnitt: Das G.8275.2-Profil.
Bei der PTP-Redundanzkonfiguration können die cBR-8-Switches bei einem nicht erreichbaren Master an die alternative Quelle weitergeleitet werden. Sobald der Master wieder verfügbar ist, kehrt cBR-8 zur Master-Quelle zurück.
Überprüfung
Überprüfen Sie mit diesem Befehl, ob der Status PHASE_ALIGNED lautet und die Anzahl der gesendeten und empfangenen Pakete erhöht ist:
cBR-8#show ptp clock running domain 0
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
PHASE_ALIGNED 1 462249 1104590 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
TOMASTER unicast slave Lo1588 Slave 1 15.88.15.88
SESSION INFORMATION
TOMASTER [Lo1588] [Sessions 1]
Peer addr Pkts in Pkts out In Errs Out Errs
15.88.15.88 1104590 462249 0 0
Einschränkungen
- Derzeit unterstützt cBR-8 kein PTP über MPLS. Wenn die PTP-Pakete also mit MPLS-Tags versehen sind, wird die Uhr nicht synchronisiert. Es besteht eine Verbesserungsanfrage, dass diese Funktion unterstützt wird. Sie können die folgenden Aktualisierungen möglicherweise über den folgenden Link durchführen: CSCvj02809.
- Als PTP-Profil können Sie entweder das Standardprofil verwenden (wie bisher) oder das G.8275.2-Profil angeben (empfohlen), wie im nächsten Abschnitt beschrieben. Beachten Sie, dass selbst wenn IOS-XE die Konfiguration des G.8265.1-Profils ermöglicht, dies in der DOCSIS-Umgebung mit cBR-8 und RPD nicht unterstützt wird.
Das G.8275.2-Profil
Sie können das G.8275.2-Profil auf dem cBR-8-Slave mit einer GM-Quelle konfigurieren:
ptp clock ordinary domain 44 servo tracking-type R-DTI clock-port TOMASTER slave profile g8275.2 <<<<<<<<<< announce interval -3
announce timeout 10
delay-req interval -4
sync interval -4 transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.15.88
Wie bereits in diesem Artikel erwähnt, wird die PTP-Grenze auf cBR-8 noch nicht unterstützt. Wenn Sie jedoch das G.8275.2-Profil auf dem cBR-8-Slave mit zwei GM-Quellen konfigurieren möchten, müssen Sie die Randdomänendefinition auf diese Weise verwenden:
ptp clock boundary domain 44 servo tracking-type R-DTI clock-port slave1 profile g8275.2 <...> transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.15.88 <<< THIS IS YOUR PTP MASTER clock-port slave2 profile g8275.2 <...> transport ipv4 unicast interface Lo1588 negotiation clock source 15.88.2.8 <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY
Slave-Uhr auf RPD
Trotzdem muss die RPD-Konfiguration in cBR-8 selbst eingegeben werden, da cBR-8 das Remote Phy-Gerät bereitstellt.
ptp r-dti 1
[profile G.8275.2] <-- ONLY IF SPECIFIED IN THE cBR-8 PTP CONFIGURATION
ptp-domain 0
clock-port 1
clock source ip 15.88.15.88 <-- THIS IS YOUR PTP MASTER
clock source ip 15.88.2.8 alternate <-- THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)
sync interval -4
announce interval -3
Value Log calculation Value in seconds
-5 2^-5 1/32s
-4 2^-4 1/16s
-3 2^-3 1/8s
-2 2^-2 1/4s
-1 2ˆ-1 1/2s
0 2^0 1s
1 2^1 2s
2 2^2 4s
3 2^3 8s
4 2^4 16s
5 2^5 32s
Überprüfung
Diese Befehle, die von der RPD-Konsole ausgegeben werden, können verwendet werden, um den PTP-Status zu überprüfen, der in PHASE_LOCK und SUB_SYNC enthalten sein muss, sowie die Synchronisierungs-, Verzögerungs- und Verzögerungsantwortindikatoren, die erhöht werden müssen:
# ssh 10.6.17.9 -l admin
R-PHY>ena
R-PHY#show ptp clock 0 state
apr state : PHASE_LOCK <<<
clock state : SUB_SYNC <<<
current tod : 1506419132 Tue Sep 26 09:45:32 2017
active stream : 0
==stream 0 :
port id : 0
master ip : 15.88.15.88
stream state : PHASE_LOCK <<< Stream state must be PHASE_LOCK
Master offset : 1212 <<< Master offset (in ns) must be as close to 0 as possible
Path delay : -81553
Forward delay : -80341 <<< Forward delay and reverse delay must be within 500us of each other
Reverse delay : -77791 <<< Forward delay and reverse delay must be within 500us of each other
Freq offset : -86279
1Hz offset : -615
R-PHY#show ptp clock 0 statistics <output omitted> streamId msgType rx rxProcessed lost tx 0 SYNC 8585001 8584995 0 0 <<<<<< 0 DELAY REQUEST 0 0 0 8585000 <<<<<< 0 P-DELAY REQUEST 0 0 0 0 0 P-DELAY RESPONSE 0 0 0 0 0 FOLLOW UP 0 0 0 0 0 DELAY RESPONSE 8584998 8584998 5 0 <<<<<< 0 P-DELAY FOLLOWUP 0 0 0 0 0 ANNOUNCE 536571 536571 0 0 0 SIGNALING 5593 5593 0 5591 0 MANAGEMENT 0 0 0 0 TOTAL 17712163 17712157 5 8590591
Grenzuhr auf ASR900
Angenommen, Sie möchten eine Grenzwertuhr als alternativen Master für cBR-8 und RPD konfigurieren, falls die Referenzuhr ausfällt oder nicht erreichbar ist. Diese Grenzwertuhr verwendet aus Redundanzgründen eine andere Masterquelle (in diesem Beispiel 15.88.200.8). Die Konfiguration der Referenzuhr in diesem Szenario unterscheidet sich nicht von der zuvor beschriebenen, wird daher in diesem Abschnitt ausgelassen.
ptp clock boundary domain 0 clock-port TO-MASTER slave sync interval -5 transport ipv4 unicast interface Lo2008 negotiation clock source 15.88.200.8 <<< THE PTP MASTER (Different from PTP master described above) clock source 15.88.20.8 1 <<< AN ALTERNATE MASTER USED FOR REDUNDANCY (OPTIONAL) clock-port TO-SLAVE master transport ipv4 unicast interface Lo1588 negotiation interface Loopback1588 ip address 15.88.2.9 255.255.255.255 end
Überwachen mit SNMP
Um die Anzahl der ptp-Sitzungen auf dem ASR900 und cBR-8 mit SNMP zu überwachen, können Sie Folgendes verwenden:
Object - cPtpClockPortNumOfAssociatedPorts
OID - 1.3.6.1.4.1.9.9.760.1.2.7.1.10
Fehlerbehebung
Dieser Abschnitt enthält Informationen, die Sie zur Fehlerbehebung in Ihrer Konfiguration verwenden können.
Fehlerbehebung beim PTP-Master (ASR900)
Auf dem Master ist es am wichtigsten, sicherzustellen, dass PTP eine Netzwerkuhr-Quelle für die Taktgebung hat, entweder eine GPS-Antenne (bevorzugt) oder einen lokalen Oszillator.
Um sicherzustellen, dass die Netzwerkuhr wie erwartet funktioniert, können Sie den folgenden Befehl verwenden:
ASR900#show network-clocks synchronization
Symbols: En - Enable, Dis - Disable, Adis - Admin Disable
NA - Not Applicable
* - Synchronization source selected
# - Synchronization source force selected
& - Synchronization source manually switched
Automatic selection process : Enable
Equipment Clock : 2048 (EEC-Option1)
Clock Mode : QL-Enable
ESMC : Enabled
SSM Option : 1
T0 : Internal
Hold-off (global) : 300 ms
Wait-to-restore (global) : 300 sec
Tsm Delay : 180 ms
Revertive : No
Nominated Interfaces
Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx
*Internal NA NA/Dis 251 QL-SEC NA NA <<<<<
External R0 10M NA/Dis 1 QL-FAILED NA NA
Gi0/2/5 NA Sync/En 1 QL-FAILED QL-PRC -
Fehlerbehebung beim PTP-Slave (cBR-8)
Auf der cBR-8 als Slave ist zu beachten, dass die Schnittstelle nur die SUP-DPIC-Schnittstellen unterstützt, um (ab jetzt) eine Verbindung zum PTP-Master herzustellen. Daher wird die Gig0-Schnittstelle oder die RPHY PIC-Schnittstellen nicht verwendet, da PTP möglicherweise nicht über diese Schnittstellen funktioniert.
Während der ersten PTP-Aushandlung kann es bis zu 35 Minuten dauern, bis der cBR-8 seine Uhr an der Uhr des PTP-Masters anpasst und ausrichtet. Während dieser Zeit wird die Uhr auf cBR-8 im AKQUIRING-Status angezeigt:
cBR-8#show ptp clock running
PTP Ordinary Clock [Domain 0]
State Ports Pkts sent Pkts rcvd Redundancy Mode
ACQUIRING 1 687 1995 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
TOMASTER unicast slave Lo1588 Uncalibrated 1 15.88.15.88
Wenn der ACQUIRING-Status länger als 35 Minuten dort bleibt, kann dies darauf hindeuten, dass die PTP-Referenzuhr nicht sehr genau ist und sich hin und her bewegt, wodurch der cBR nicht in der Lage ist, die CQUIRE-Nummer richtig zu erfassen. Dies kann beispielsweise bei einem Linux-Server mit PTPd auftreten.
Die PTP-Uhr sowohl auf dem cBR-8 als auch auf dem RPD muss vor der Behebung von DOCSIS-Problemen eine Phasensynchronisierung mit dem Master durchführen. Es gibt eine Reihe von Befehlen, die diesen Zustand zusammen mit der Anzahl der Pakete anzeigen können. In dieser Ausgabe soll die Paketinkrementierung für die Synchronisierung, die Verzögerungsanforderung und die Verzögerungsantwort angezeigt werden:
cBR-8#show platform software ptpd stat stream 0 LOCK STATUS : PHASE LOCKED <<<<<<< must be PHASE LOCKED SYNC Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -5, Acting Interval -5 Tx packets : 0, Rx Packets : 24074045 <<<<<<< Rx Packets must increase Last Seq Number : 42454, Error Packets : 0 <<<<<<< Last Seq Number must increase Delay Req Packet Stats Time elapsed since last packet: 0.0 Configured Interval : 0, Acting Interval : -5 Tx packets : 24077289, Rx Packets : 0 <<<<<<< Tx Packets must increase Last Seq Number : 0, Error Packets : 0 Delay Response Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -5, Acting Interval : -5 Tx packets : 0, Rx Packets : 23983049 <<<<<<< Rx Packets must increase Last Seq Number : 31420, Error Packets : 0 <<<<<<< Last Seq Number must increase Announce Packet Stats Time elapsed since last packet: 0.0 Configured Interval : -3, Acting Interval : -3 Tx packets : 0, Rx Packets : 6030915 <<<<<<< Rx Packets must increase Last Seq Number 44276 Error Packets 0 <<<<<<< Last Seq Number must increase Signalling Packet Stats Time elapsed since last packet: 0.0 Configured Interval : 0, Acting Interval : 0 Tx packets : 9944, Rx Packets : 9521 <<<<<<< Tx Packets and Rx Packets must increase Last Seq Number : 0, Error Packets : 0 <output omitted>
Die Streamnummer kann unter dem bereits eingeführten Befehl show ptp clock running domain 0 im Abschnitt SESSION INFORMATION überprüft werden. Die erste aufgeführte Sitzung ist Stream 0, die zweite Stream 1 usw.
Wenn einige der Zähler nicht ansteigen, besteht die Möglichkeit eines Netzwerkproblems. Es wird empfohlen, den Paketverlust zu überprüfen.
DTI und PTP
Um PTP auf dem cBR-8 zu konfigurieren, muss die DTI-Kabeluhr deaktiviert sein. Andernfalls wird folgende Meldung angezeigt:
%[PTP]: NetSync source already configured. PTP slave configuration not allowed.
Auch wenn die I-CMTS-Linecard schließlich im selben Chassis eingesetzt wird, ist PTP-Taktgebung erforderlich. Daher kann ein potenzieller Ausfall der PTP GM-Uhr auch die Modems hinter einer I-CMTS-Linecard beeinträchtigen.
Uhrzeitverzögerungen und Offset
Um den Offset von der Referenzuhr zu überprüfen und zu erfahren, welche Verzögerungen beim Weiterleitungspfad zum Master und im umgekehrten Pfad auftreten, können Sie diesen Befehl verwenden, der zuvor eingeführt wurde, und durch den Abschnitt Aktuelles Datensatz filtern.
Der Offset-Wert vom Master muss so nahe wie möglich bei 0 liegen, und die Verzögerung des Weiterleitungspfads muss der Verzögerung des umgekehrten Pfads so weit wie möglich entsprechen.
Im folgenden Beispiel werden gute Werte verglichen mit schlechten Werten, die während einer problematischen Bedingung erfasst wurden:
----------------- GOOD -----------------
cBR-8#show platform software ptpd stat stream 0 | s Current Data Set
Current Data Set
Offset from master : -0.000000313
Mean Path Delay : +0.000025042
Forward Path Delay : +0.000024729
Reverse Path Delay : +0.000024660
--------------- NOT GOOD ---------------
cBR-8#show platform software ptpd stat stream 0 | s Current Data Set Current Data Set Offset from master : +0.002812485 Mean Path Delay : +0.000022503 Forward Path Delay : +0.002834302 Reverse Path Delay : -0.002789295
Die Werte werden in Sekunden ausgedrückt (daher ist die niedrigste signifikante Ziffer, die rechte Ziffer, Nanosekunde), und der Offset vom Master wird als mittlere Pfadverzögerung abzüglich der Verzögerung des Weiterleitungspfads berechnet.
Die mittlere Pfadverzögerung wird als Durchschnitt zwischen Vor- und Rückwärts berechnet: (Verzögerung für den Vorwärtsweg + Verzögerung für den umgekehrten Pfad) / 2.
In der idealen Welt wäre der Ausgleich vom Master 0, da die Verzögerung des Weiterleitungspfads der Verzögerung des umgekehrten Pfads entspricht, wodurch beide gleich der mittleren Pfadverzögerung sind.
Abhängig von der Asymmetrie zwischen dem Vorwärtspfad und dem Rückwärtspfad kann ein negativer Offset vom Master (wenn die Verzögerung des umgekehrten Pfads größer als die Verzögerung des Vorwärtspfads ist) oder ein positiver Offset (wenn die Verzögerung des umgekehrten Pfads kleiner als die Verzögerung des Vorwärtspfads ist) vorhanden sein.
Wenn der Offset-Wert zu groß ist oder man sehr schwankende Werte beobachtet, ist dies möglicherweise ein Jitter-Problem oder eine nicht genaue Referenzuhr.
Je höher der Jitter, desto länger dauert die RPD oder cBR-8 in den PHASE_ALIGNED-Zustand, und desto länger dauert es, sich von einer HOLDOVER-Situation zu erholen.
Mehrere Pfadkonfigurationen wirken sich stark auf Jitter aus (da einige Pakete Pfad A verwenden und einige Pakete Pfad B mit unterschiedlichen Verzögerungen verwenden, was für cBR-8 und RPD als Jitter gilt). Daher muss der PTP-Datenverkehr einen Pfad verwenden (kein Load Balancing zwischen mehreren Verbindungen).
Fehlerbehebung beim PTP-Slave (RPD)
Auf der RPD-Seite finden Sie alle interessanten Befehle unter dem Schirm show ptp:
R-PHY#show ptp clock 0 state
apr state : PHASE_LOCK
clock state : SUB_SYNC
current tod : 1506426304 Tue Sep 26 11:45:04 2017
active stream : 0
==stream 0 :
port id : 0
master ip : 15.88.15.88
stream state : PHASE_LOCK
Master offset : 6010
Path delay : -78442
Forward delay : -72432
Reverse delay : -81353
Freq offset : -86206
1Hz offset : -830
R-PHY#show ptp clock 0 statistics
AprState 6 :
2@0-00:14:54.347 3@0-00:14:15.945 2@0-00:06:24.766
1@0-00:06:15.128 0@0-00:03:59.982 4@0-00:03:40.782
ClockState 5 :
5@0-00:06:49.252 4@0-00:06:46.863 3@0-00:06:43.016
2@0-00:06:25.017 1@0-00:06:24.728
BstPktStrm 3 :
0@0-00:14:45.560 4294967295@0-00:14:07.272 0@0-00:06:15.160
StepTime 1 :
406874666@0-00:05:46.080
AdjustTime 99 :
427@0-02:05:11.705 -414@0-02:04:10.705 -396@0-02:03:09.705
145@0-02:02:08.705 -157@0-02:00:06.705 327@0-01:58:04.705
-195@0-01:57:03.705 -46@0-01:56:02.705 744@0-01:55:01.705
streamId msgType rx rxProcessed lost tx
0 SYNC 246417 246417 4294770689 0
0 DELAY REQUEST 0 0 0 118272
0 P-DELAY REQUEST 0 0 0 0
0 P-DELAY RESPONSE 0 0 0 0
0 FOLLOW UP 0 0 0 0
0 DELAY RESPONSE 117165 117165 4294902867 0
0 P-DELAY FOLLOWUP 0 0 0 0
0 ANNOUNCE 82185 82184 4294901761 0
0 SIGNALING 78 78 0 78
0 MANAGEMENT 0 0 0 0
TOTAL 445845 445844 12884575317 118350
R-PHY#show ptp clock 0 config
Domain/Mode : 0/OC_SLAVE
Priority 1/2/local : 128/255/128
Profile : 001b19000100-000000 E2E
Total Ports/Streams : 1 /1
--PTP Port 1, Enet Port 1 ----
Port local Address :10.6.17.9
Unicast Duration :300 Sync Interval : -5
Announce Interval : -3 Timeout : 11
Delay-Req Intreval : -4 Pdelay-req : -4
Priority local :128 COS: 6 DSCP: 47
==Stream 0 : Port 1 Master IP: 15.88.15.88
Zugehörige Informationen
- Precision Time Protocol - Wikipedia
- 1588-2008 - IEEE-Standard für ein Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
- G.8265.1: Precision Time Protocol Telecom-Profil für die Frequenzsynchronisierung
- G.8275.1 : Precision Time Protocol Telecom-Profil für Phase-/Zeitsynchronisierung mit vollständiger Timing-Unterstützung durch das Netzwerk
- G.8275.2 : Precision Time Protocol Telecom-Profil für die Zeitsynchronisierung mit partieller Timing-Unterstützung aus dem Netzwerk
- Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)
- Cisco Remote PHY Device Software Configuration Guide Cisco 1x2 RPD Software 1.1
- Fehlerbehebung bei RPD DOCSIS-Durchsatzproblemen
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)