AVB with TC

[jagmeethanspal]

With the OpenAvnu stack on the end-points what about the network-bridge (non end-points, non-talker, non-listener) do they require an Boundary clock or Transparent clock with H/w time-stamping will suffice? Given that the .AS standard talks about the gPTP and time-sync, I am wondering (assuming the availability of QoS shaping and SRP), what limited-functionality can be achieved (or remain unsupported) with only transparent clock type on the transit n/w node?

[jdkoftinoff]

The bridges in an AVB/TSN networks are also required to support 802.1AS. Note that 802.1AS is a different profile of PTPv2 which requires each side of each ethernet cable to run the various state machines in order to achieve the tight timing requirements. End stations running 802.1AS through a bridge which does not actively participate in the 802.1AS protocol is guaranteed to not work.

[jagmeethanspal]

thanks Jeff...

I looked at the http://www.ieee802.org/1/files/public/docs2008/as-kbstanton-8021AS-overview-for-dot11aa-1108.pdf

And, generally looking at the calculation of propagation time (I guess that is by the way of correction field in the PTP packets) to derive link-delay as well as neighbor-rate-ratio.

For the end-to-end synchronization between the talker/listener end-points, considering the intermediate nodes (n/w bridges, APs etc) only updating the correction field (through egress time-stamp - ingress timestamp at hardware level) for supporting the .1AS That is to say that the N/w bridge is neither the GM, nor the PTP Master or Slave, but a transparent clock that has H/w time-stamping capability to update the PTP correction field, so that the PTP slave (end-point talker/listener) can derive accurate link-delay and rate-ratio etc for the AVB timesync purpose?

My doubt is, would that not suffice instead of the N/w bridge also having a capability to act as a PTP Master/Slave (or optionally as GM in case it has the best clock quality). {not talking of other requirements like priority scheduling etc}

On Wed, Aug 21, 2019 at 9:28 AM Jeff Koftinoff notifications@github.com wrote:

The bridges in an AVB/TSN networks are also required to support 802.1AS. Note that 802.1AS is a different profile of PTPv2 which requires each side of each ethernet cable to run the various state machines in order to achieve the tight timing requirements. End stations running 802.1AS through a bridge which does not actively participate in the 802.1AS protocol is guaranteed to not work.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AVnu/OpenAvnu/issues/878?email_source=notifications&email_token=AEIYKMJ6RUOBWVUV5ZK23ATQFS4N7A5CNFSM4INPH2IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YLH5I#issuecomment-523285493, or mute the thread https://github.com/notifications/unsubscribe-auth/AEIYKMI6ZJLUUFC6SJWMA7LQFS4N7ANCNFSM4INPH2IA .

--

Best Regards, ~ Jagmeet Singh Hanspal ~

[pinealservo]

If you read the specifications more closely, you'll find that you cannot create a compliant AVB implementation without implementing real 802.1AS in your network switches. Sure, you could maybe make something AVB-like, but it won't work with standard AVB endpoints, and I don't think anyone here is very interested in helping to bring more non-standard AVB-like things into the world. We do like helping people bring actual AVB-compliant things into the world though, especially when it involves people using and contributing back to this project, which is aiming at AVB and to some degree TSN compliance.

[jagmeethanspal]

Well, definitely not that intention. Only trying to figure out which use-case/topology might not be met. Like the n/w bridge "may" be a PTP master but that is not mandatory. If it does not have that capability, it can still be part of the chain. The chip that we use (in-house and some third-party) support transparent clocking and evaluating what kind of replacement and upgrade is needed based on what the current one cannot be expected to do.

On Thu, Aug 22, 2019, 11:42 Levi Pearson notifications@github.com wrote:

If you read the specifications more closely, you'll find that you cannot create a compliant AVB implementation without implementing real 802.1AS in your network switches. Sure, you could maybe make something AVB-like, but it won't work with standard AVB endpoints, and I don't think anyone here is very interested in helping to bring more non-standard AVB-like things into the world. We do like helping people bring actual AVB-compliant things into the world though, especially when it involves people using and contributing back to this project, which is aiming at AVB and to some degree TSN compliance.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AVnu/OpenAvnu/issues/878?email_source=notifications&email_token=AEIYKMIB5F3AVZDJBF7FS3TQFYU6RA5CNFSM4INPH2IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44AB5I#issuecomment-523763957, or mute the thread https://github.com/notifications/unsubscribe-auth/AEIYKMLEZSPYK2M37RQJW33QFYU6RANCNFSM4INPH2IA .

[pinealservo]

The problem is that gPTP is not only used for time sync, but also for admission control. The Wikipedia overview of AVB has a fairly good overview of the various protocol interactions and which standards define them: https://en.wikipedia.org/wiki/Audio_Video_Bridging

If you control the firmware for your switches, it may be possible to make them run the AVB protocols; if they have the hardware timestamping capability for PTPv2 operation then it's possible that they can do gPTP with the right software. They will also need to be able to do credit-based traffic shaping, which must be configured via SRP. Some of these requirements are different for automotive profile use of AVB, which can use static stream reservations in some cases, but they still generally have to do traffic shaping.

It's challenging enough to develop good AVB endpoints when you have well-tested AVB-compliant switches, as they play a central role in how all the AVB protocols work. I'd definitely recommend getting some experience with known-good equipment and software before making big decisions.

[jagmeethanspal]

Thank-you Levi... I would think that the traffic-shaper would do good with frequency synchronization (whether configured via SRP or anything else), but you gave me a good point. The time-sync itself has different aspects ToD, Phase and Frequency syntonization. I came across a good source to find some answers to my query on TC here: http://www.ieee802.org/1/files/public/docs2006/as-garner-use-of-p2p-tc-in-avb-v2p0-060512.pdf It may not be perfect (or latest) but will help me clarify some aspects, like an AVB n/w node is actually an OC + P2P TC combo.

On Thu, Aug 22, 2019 at 2:48 PM Levi Pearson notifications@github.com wrote:

The problem is that gPTP is not only used for time sync, but also for admission control. The Wikipedia overview of AVB has a fairly good overview of the various protocol interactions and which standards define them: https://en.wikipedia.org/wiki/Audio_Video_Bridging

If you control the firmware for your switches, it may be possible to make them run the AVB protocols; if they have the hardware timestamping capability for PTPv2 operation then it's possible that they can do gPTP with the right software. They will also need to be able to do credit-based traffic shaping, which must be configured via SRP. Some of these requirements are different for automotive profile use of AVB, which can use static stream reservations in some cases, but they still generally have to do traffic shaping.

It's challenging enough to develop good AVB endpoints when you have well-tested AVB-compliant switches, as they play a central role in how all the AVB protocols work. I'd definitely recommend getting some experience with known-good equipment and software before making big decisions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AVnu/OpenAvnu/issues/878?email_source=notifications&email_token=AEIYKMMIALEEBX3B4LHI753QFZKW7A5CNFSM4INPH2IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD44OSQI#issuecomment-523823425, or mute the thread https://github.com/notifications/unsubscribe-auth/AEIYKMOZJY32WPF5J4FOFC3QFZKW7ANCNFSM4INPH2IA .

--

Best Regards, ~ Jagmeet Singh Hanspal ~

[andrew-elder]

This is a good background paper https://avnu.org/wp-content/uploads/2014/05/AVnu_SWAPIs-v1.3-SWAVI-Updates_Final_Approved_Clean.pdf

[jagmeethanspal]

This was indeed helpful. Thanks!

On Thu, Aug 22, 2019 at 6:07 PM andrew-elder notifications@github.com wrote:

This is a good background paper https://avnu.org/wp-content/uploads/2014/05/AVnu_SWAPIs-v1.3-SWAVI-Updates_Final_Approved_Clean.pdf

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AVnu/OpenAvnu/issues/878?email_source=notifications&email_token=AEIYKMOQJ2F3MWF33ICJVYLQF2CAPA5CNFSM4INPH2IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD446EDQ#issuecomment-523887118, or mute the thread https://github.com/notifications/unsubscribe-auth/AEIYKMLMONFXY4TPC33YOU3QF2CAPANCNFSM4INPH2IA .

--

Best Regards, ~ Jagmeet Singh Hanspal ~