IEEE 1722.1 Agenda 20200318 AVBTP-DECC@LISTSERV.IEEE.ORG IEEE 1722.1 Work Group ONLINE Meeting Wednesday, March 18, 2020 Meeting time is 9AM Pacific Daylight Time Zoom Meeting Address: https://zoom.us/j/2268818568 One tap mobile +14086380968,,2268818568# US (San Jose) +16699006833,,2268818568# US (San Jose) Dial by your location +1 408 638 0968 US (San Jose) +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 226 881 8568 Find your local number: https://zoom.us/u/adrxJ5pYQ1 ATDECC web page shows the Zoom numbers. http://grouper.ieee.org/groups/1722/1/web/index.html# In advance of joining the meeting, please review: Essential Patent Claims https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf IEEE SA Copyright Policy https://standards.ieee.org/faqs/copyrights.html Working Group policies and procedures http://grouper.ieee.org/groups/1722/1/web/P1722_1_WG_PP.pdf NOTICE: Extended Deadline for proposals with draft text for this REV: March 25, 2020. This is to accommodate the open items from Jeff Koftinoff. Agenda: A. Minor changes to the description of the ACMP Listener state machine. PDF of proposed new state machine diagram attached. -- Rimas Avizienis ----- need second part of state machine diagram 802.1Qcc (SRPv2) -- Kieran Tyrrell proposed text ----- Kieran not present, discussion moved back to reflector - - - - - - - - - - - - - - - - - - - - - - - - - - - - B. Next Face-to-Face meeting implemented virtually: Does scheduling this on a Wednesday around our normal meeting time work? It could move to 8AM Pacific. Session 1 9AM to 9:55AM Pacific 5 minute break Session 2 10:00AM to 11:00AM Pacific 30 minute break Session 3 11:30AM to 12:05PM Pacific 5 minute break Session 4 12:10PM to 13:00PM Pacific The Virtual Link would be up during all breaks so that “side” conversations may be held. Should the breaks be equal allocations of 12 minutes, or does the asymmetry work out better? What date would work best for this meeting. Assuming we stay with a Wednesday, the potential dates are: April 8th April 15th April 29th thanks Richard attending: Richard Bugg Rimas Avizienis Tom Thompson Jeff Koftinoff Marc Illouz ////////////////////////////////////////////////////////////////////////// 20200316 from Kieran Tyrrell Hi all, Having checked 802.1Qcc more thoroughly I see that there is not so much directly related to endpoints, and thus to 1722.1. However: 12.32.2 Propagation Delay This IS relevant for endpoints. We can add an AECP command to get the ptp prop delay from this "managed object". 12.20.4 SR Class to Priority Mapping Table This is NOT relevant for endpoints: - The table states that it's optional for bridges only, and the note explicitly states: "NOTE 1 - This managed object is not needed for an end station, since according to the requirements of 35.2.2.9.3, an end station uses the SR class to priority mapping that the neighboring Bridge provides in SRP’s Domain attribute." - Section 35 also adds a paragraph that clarifies that with Centralized network/distributed user model the endpoints don't have their SRP classes/priorities twiddled directly, but rather via the nearest bridge. - finally 35.2.2.9.3 SRclassPriority - An end station cannot change its default mapping of SR class to priority (see 12.20.4). - Do we care about endpoints with integrated bridges? Or do we assume these will implement a bridge control protocol? - there is no way to set the rank/emergency bit in the priority. Should SET_STREAM_INFO be modified to enable setting the rank/emergency bit? - there is no way to explicitly set the priority of a stream. Should SET_STREAM_INFO be modified to enable setting the stream priority (and thus indirectly the class)? Probably not as this should be changed via MSRP domain, unless we want to support fully centralized model. (see below) Of the three different SRP models now available with Qcc: 46.1.3.1 Fully distributed model No changes are required to avdecc to support this. This is what we currently have in 802.1Q. 46.1.3.2 Centralized network/distributed user model No changes required to avdecc because as far as the endpoint is concerned nothing has changed. 46.1.3.3 Fully centralized model This can actually be supported without huge changes but probably requires some thought! AVDECC already has everything required to configure and start/stop streams etc. In 46.1.3.3 Avdecc is the protocol 'outside scope' of Q. For fully centralised model to work we could: - add AECP commands to disable/enable MSRP and MAAP. (And add flags to show if MSRP and MAAP are supported). - SET_STREAM_INFO could be modified to allow setting of priority and rank. - A new AECP command could be added to allow configuration of the traffic shaper, class interval etc. I will attempt to provide text for the prop delay getter for the wednesday call. Do we want to add the features to support the fully centralized model at this stage? Cheers, Kieran.