AVB with TC #878
Comments
|
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. |
|
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 ***@***.***> 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
<#878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIYKMI6ZJLUUFC6SJWMA7LQFS4N7ANCNFSM4INPH2IA>
.
--
Best Regards,
~
Jagmeet Singh Hanspal
~
|
|
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. |
|
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 ***@***.***> 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
<#878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIYKMLEZSPYK2M37RQJW33QFYU6RANCNFSM4INPH2IA>
.
|
|
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. |
|
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 ***@***.***> 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
<#878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIYKMOZJY32WPF5J4FOFC3QFZKW7ANCNFSM4INPH2IA>
.
--
Best Regards,
~
Jagmeet Singh Hanspal
~
|
|
This is a good background paper https://avnu.org/wp-content/uploads/2014/05/AVnu_SWAPIs-v1.3-SWAVI-Updates_Final_Approved_Clean.pdf |
|
This was indeed helpful. Thanks!
…On Thu, Aug 22, 2019 at 6:07 PM andrew-elder ***@***.***> 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
<#878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEIYKMLMONFXY4TPC33YOU3QF2CAPANCNFSM4INPH2IA>
.
--
Best Regards,
~
Jagmeet Singh Hanspal
~
|
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?
The text was updated successfully, but these errors were encountered: