01-25-2024 06:46 AM
Hi
I'm looking at configuring a Catalyst C9300L-48P-4X running 17.09.04a to support both Dante and AES67.
The switch is L2 with SVIs on upstream switch - all Dante/AES67 devices will connect only to this switch so no configuration is required upstream.
Dante has its own proprietary clocking method and requires only QoS. See link below for QoS requirements:
https://www.audinate.com/learning/technical-documentation/dante-information-for-network-administrators
AES67 requires both a "media profile" configured for clock synchronization and QoS. See link below for Catalyst 9300 AES67 Media Profile:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-10/configuration_guide/lyr2/b_1710_lyr2_9300_cg/configuring_precision_time_protocol__ptp_.html#configure-ptp-using-aes67-media-profile
Using the above links, the configuration I have so far is:
AES67 Media Profile
ptp transport ipv4 udp
ptp mode boundary delay-req
ptp ip dscp 46 message general
ptp ip dscp 56 message event
QoS
class-map match-all DANTE_PTP
match dscp cs7
class-map match-all DANTE_AUDIO_PTPv2
match dscp ef
class-map match-any VOICE
match dscp af41
!
policy-map DANTE-PTP-QOS
class DANTE_PTP
priority level 1 percent 15
class DANTE_AUDIO_PTPv2
bandwidth remaining percent 55
class VOICE
bandwidth remaining percent 10
class class-default
bandwidth remaining percent 20
Access Interface configuration for QoS and AES67:
interface GigabitEthernet1/0/X
...
ptp sync interval -3
ptp delay-req interval -3
service-policy output DANTE-PTP-QOS
...
I don't have any devices to test the above as yet. Has anyone done this kind of work before and can offer any insight or comment please?
Thanks
Andy
02-19-2024 01:18 PM
AES67 uses PTPv2. Dante typically uses PTPv1. Having both versions on the same network can be tricky. Usually I set it up as you have with the switch serving as a PTPv2 boundary clock. ptp delay-req interval 0 (1 per second) is the default specified by the AES67 media profile. The ptp delay-req interval -3 configuration you're using is appropriate for SMPTE ST 2110. If you have AES67 and ST 2110 on the same network, have a look at AES-R16 for PTP profile configurations that can work for both.
You need to make sure the switch forwards the PTPv1 traffic as normal multicast. I'm not sure what the Cisco config statement for that is. For Arista it is ptp forward-v1.
The Dante and default AES67 DSCP values don't line up well. As it looks like you're aware, AES67 PTP and Dante audio both use EF (46). If you're using boundary clock, QoS for PTPv2 is not critical because the switch handles those messages separately. The Dante PTPv1 messages at (CS7) 56 should use the highest priority queue. Dante audio at EF (46) and AES67 audio at AF41 (34) can be assigned to the same queue. Everything else can go into the BE (0) queue.
02-20-2024 06:50 AM
Hi
You mentioned that you usually setup the switch as the PTPv2 boundary clock as I have with "ptp mode boundary delay-req". In this PTP mode, the switch interface Delay Mechanism defaults to "Peer to Peer"
The Audinate link "PTPv2 clocking options for AES67 / SMPTE Interoperability with Dante" below specifies the Delay Mechanism as "End-to-End (E2E)":
The IEEE1588 standard states that boundary/peer-to-peer can preclude the use of end-to-end:
"Ordinary Clocks and Boundary Clocks with PTP Ports implementing only the peer-to-peer delay mechanism, and peer-to-peer Transparent Clocks, can only be connected in topologies where each such PTP Port implementing the peer-to-peer delay mechanism communicates PTP messages to and from a single PTP Port also implementing the peer-to-peer delay mechanism (see 11.4.3).
Except in carefully designed networks, this will preclude the use of end-to-end Transparent Clocks and bridges that do not support PTP, for example, a conventional bridge, when using the peer-to-peer delay mechanism."
Did you run into any issues using Dante with the switch as the PTPv2 boundary clock?
Thanks
Andy
02-20-2024 08:01 AM
I think there is some terminology scramble going on. Network PTP support can operate in boundary clock mode in which case each switch has a boundary clock that maintains time which is served to connected devices. Transparent is the other mode where transparent clocks in each switch touch up timestamps of PTP messages as they pass through. Transparent is rarely used in my experience. Often when people say "transparent" they actually mean the network has no PTP support and PTP messages are passed through as normal multicasts.
When the switch is the boundary clock, the only issue with Dante is that it typically uses PTPv1 and PTPv1 and v2 messages are very similar and Arista swtiches configured with a boundary clock will not, by default, forward the PTPv1 messages so all PTPv1 Dante devices become their own grandmaster.
02-20-2024 08:41 AM
Thanks for that - that's clarified a few things for me.
cheers
Andy
02-20-2024 02:38 AM
Thanks for the response - very interesting!
Still at the development stage with this - I found the following regarding PTP on the Catalyst 9ks:
Q. Do the Catalyst 9000 switch platforms support PTP versions 1 and 2?
A. The switches support PTP version 2 as per the requirements in IEEE 1588v2. They do not support PTP version 1.
Q. Can the Catalyst 9000 switch platforms transparently transit PTP version 1 packets?
A. Yes, the switches can transit PTP version 1 packets transparently.
The AES-R16 standard seems to be behind a paywall - I'll check with colleagues to see if any are members.
Yes, for QoS, I'm changing the Dante DSCP (clocking (CS7) and streaming (EF)) to the AES67 DSCP (clocking (EF) and streaming (AF41)
Also came across this link on Audinate's site which should be helpful for setting Sync and Delay-Req Interval appropriately.
PTPv2 clocking options for AES67 / SMPTE Interoperability with Dante
https://www.audinate.com/learning/faqs/ptpv2-clocking-options-for-aes67-smpte-interoperability-with-dante
Thanks again
Andy
02-20-2024 08:04 AM
That Audinate information appears to have some errors. Best to try to get your hands on AES-R16.
02-20-2024 08:40 AM
Thanks
I'll see if I can get my hands on AES-R16.
I did find the following Cisco link:
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-742142.html#PTPmediaprofiles
It states that AES-R16-2016 prospses the following settings for interoperability (between SMPTE and AES67):
Domain 127
Sync Interval -3 (8 per second)
Announce Interval 0 (1 per second)
Announce Timeout 3
Delay Request Minimum Interval -3 (8 per second)
This Arista link https://www.arista.com/assets/data/pdf/Whitepapers/Arista-PTP-Webinar-2023-Follow-Up.pdf has the following:
Q: What kind of sync/announce interval rates do you recommend ?
A: Message rates will very much depend on your application, and the desired accuracy. The PTP profile in use may well define the
message rate ranges, and their defaults. For example, in the Live Production environment, the industry has settled on a set of rates
described in AES-R16-2016, which provide a good compromise between accuracy and lock speed, without overloading lower
capacity devices:
• 1 Announce message per second
• 8 Sync messages per second
• 8 Delay-Request messages per second
Both suggest a Cisco switchport configuration of:
ptp delay-req interval -3
ptp sync interval -3
Dante's link suggests the following:
ptp delay-req interval 0
ptp sync interval -2
Might just be a case of trying it out and seeing what works.
cheers
Andy
02-20-2024 09:19 AM
All of these should work for a competent PTP implementation. Fields in PTP messages from the grandmaster or boundary clock tell devices what profile parameters to expect. Not all PTP implementations pay attention to these fields
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide