AES67 and Dante on Catlayst 9300 query

[andrewswanson]

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

[kevingrss]

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.

[andrewswanson]

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)":

https://www.audinate.com/learning/faqs/ptpv2-clocking-options-for-aes67-smpte-interoperability-with-dante

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

[kevingrss]

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.

[andrewswanson]

Thanks for that - that's clarified a few things for me.

cheers

Andy

[andrewswanson]

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

[kevingrss]

That Audinate information appears to have some errors. Best to try to get your hands on AES-R16.

[andrewswanson]

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

[kevingrss]

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 With the boundary clock, you're free to use different profile parameters on different ports if you find it necessary.