[TSN feature] GCL capacity in GateScheduleConfiguratorBase or PeriodicGate

[yue2388253]

Hi all,

The number of a gate control list is limited in a real TSN switch (e.g., 1024 gate control entries).
Current implementation does not take this limitation into consideration.
Is it possible to implement this feature?

Best regards,

Lam

[levy]

The gate schedule configurator modules configure all existing gates in the network. Obviously, there's no way to configure a gate that doesn't exist, so all it could do perhaps is not to configure some of the gates which are there. I don't know if that makes sense, because then how could the configurator make sure that the jitter and latency limits are met.

This feature doesn't make too much sense to me. Can you describe the use case you are trying to solve?

[yue2388253]

The gate state is controlled by a gate control list (GCL) according to IEEE 802.1Qbv standard[1], as shown below.

The length of a GCL is not inifinte, due to the limited hardware capacity. In fact, a typical TSN switch can only support 1024 gate control entries. Therefore, a GateConfigurator should take this GCL limitation into consideration, otherwise the calculated schedule would be impractical.

I think it would be great to set a upper bound for the GCL length and verify whether the output of a GateConfigurator is feasible.

Reference:
[1] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic," in IEEE Std 802.1Qbv-2015 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, and IEEE Std 802.1Q-2014/Cor 1-2015) , vol., no., pp.1-57, 18 March 2016, doi: 10.1109/IEEESTD.2016.8613095.

[levy]

Ah, I see. I misunderstood what kind of limit you are talking about. Yes, this makes sense, although it's not trivial to implement.

…

On Mon, Jun 20, 2022 at 2:10 PM Jiashuo Lin ***@***.***> wrote: The gate state is controlled by a gate control list (GCL) according to IEEE 802.1Qbv standard[1], as shown below. [image: image] <https://user-images.githubusercontent.com/33801130/174596646-09e7cb3f-f735-4f7e-b3b8-d847b51c03bd.png> The length of a GCL is not inifinte, due to the limited hardware capacity. In fact, a typical TSN switch can only support 1024 gate control entries. Therefore, a GateConfigurator should take this GCL limitation into consideration, otherwise the calculated schedule would be impractical. I think it would be great to set a upper bound for the GCL length and verify whether the output of a GateConfigurator is feasible. Reference: [1] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic," in IEEE Std 802.1Qbv-2015 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, and IEEE Std 802.1Q-2014/Cor 1-2015) , vol., no., pp.1-57, 18 March 2016, doi: 10.1109/IEEESTD.2016.8613095. — Reply to this email directly, view it on GitHub <#771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3OTJLHEWEUE43QQSDDY3VQBNURANCNFSM5ZHI7TYA> . You are receiving this because you commented.Message ID: ***@***.***>

[yue2388253]

Currently the time aware shaper is implemented via PeriodicGate, which is configured individually, and is different from the IEEE 802.1Qbv standard where gates are configured by a GCL.
Is there any plan to re-implement it?
I am currently doing some research on the GCL synthesis problem, and maybe I can be of some help.

[levy]

I don't think that really matters and no there are no plans to change this. In principle, you could convert the data from one representation to the other in both directions. It is done this way because it is easier with the modular omnetpp architecture. Basically, you could have a GCL module which extracts this data from the underlying PeriodicGate modules. The other direction is also possible but it's even less appealing because the current modular architecture allows to create designs that go beyond what's in the standard. Best regards, levy

…

On Wed, Jun 22, 2022 at 3:18 PM Jiashuo Lin ***@***.***> wrote: Currently the time aware shaper is implemented via PeriodicGate, which is configured individually, and is different from the IEEE 802.1Qbv standard where gates are configured by a GCL. Is there any plan to re-implement it? I am currently doing some research on the GCL synthesis problem, and maybe I can be of soem help. — Reply to this email directly, view it on GitHub <#771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3OTPZB4PV2LCV5RTU6U3VQMHD7ANCNFSM5ZHI7TYA> . You are receiving this because you commented.Message ID: ***@***.***>

[levy]

So I thought about this problem a little bit more, and I think this could be solved the following way. The constraint model of the SAT solver has to be extended with separate variables for each slot that is available in the hardware GCL (e.g. 1024 variables per gate). Each variable would represent a moment in time when the gate opens or closes. Additional constraints have to be added to ensure that the values of these variables monotonically increase in time, and also that no transmission start/end happens outside a gate open period (defined by the values of two subsequent variables). The final result should be extracted using these new variables instead of the current approach where the transmission start/end variables are used. This change guarantees that the queues still keep the packet ordering, the traffic class priorities are still taken into consideration, etc. To further optimize the results, all gate open periods can be omitted which don't contain at least one transmission start/end pair. I don't think I'm going to do this in the near future but you could give it a try by changing the Z3GateScheduleConfigurator::computeGateScheduling method. Best regards, levy

…

On Mon, Jun 20, 2022 at 2:10 PM Jiashuo Lin ***@***.***> wrote: The gate state is controlled by a gate control list (GCL) according to IEEE 802.1Qbv standard[1], as shown below. [image: image] <https://user-images.githubusercontent.com/33801130/174596646-09e7cb3f-f735-4f7e-b3b8-d847b51c03bd.png> The length of a GCL is not inifinte, due to the limited hardware capacity. In fact, a typical TSN switch can only support 1024 gate control entries. Therefore, a GateConfigurator should take this GCL limitation into consideration, otherwise the calculated schedule would be impractical. I think it would be great to set a upper bound for the GCL length and verify whether the output of a GateConfigurator is feasible. Reference: [1] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic," in IEEE Std 802.1Qbv-2015 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, and IEEE Std 802.1Q-2014/Cor 1-2015) , vol., no., pp.1-57, 18 March 2016, doi: 10.1109/IEEESTD.2016.8613095. — Reply to this email directly, view it on GitHub <#771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3OTJLHEWEUE43QQSDDY3VQBNURANCNFSM5ZHI7TYA> . You are receiving this because you commented.Message ID: ***@***.***>

[yue2388253]

Hi levy, I think having a GCL module to convert data from PeriodicGate to GCL format and vice versa is appealing, since it would be helpful for a user who has some GCL format data and wants to verify the result via Omnet. These GCL data may be generated by the user's own scheduling algorithm which may be written in other languages and cannot be changed to a GateScheduleConfigurator easily. Best regards, Lin

---- Replied Message ---- | From | Levente ***@***.***> | | Date | 06/22/2022 22:52 | | To | ***@***.***> | | Cc | Jiashuo ***@***.******@***.***> | | Subject | Re: [inet-framework/inet] [TSN feature] GCL capacity in GateScheduleConfiguratorBase or PeriodicGate (Issue #771) | So I thought about this problem a little bit more, and I think this could be solved the following way. The constraint model of the SAT solver has to be extended with separate variables for each slot that is available in the hardware GCL (e.g. 1024 variables per gate). Each variable would represent a moment in time when the gate opens or closes. Additional constraints have to be added to ensure that the values of these variables monotonically increase in time, and also that no transmission start/end happens outside a gate open period (defined by the values of two subsequent variables). The final result should be extracted using these new variables instead of the current approach where the transmission start/end variables are used. This change guarantees that the queues still keep the packet ordering, the traffic class priorities are still taken into consideration, etc. To further optimize the results, all gate open periods can be omitted which don't contain at least one transmission start/end pair. I don't think I'm going to do this in the near future but you could give it a try by changing the Z3GateScheduleConfigurator::computeGateScheduling method. Best regards, levy

On Mon, Jun 20, 2022 at 2:10 PM Jiashuo Lin ***@***.***> wrote: The gate state is controlled by a gate control list (GCL) according to IEEE 802.1Qbv standard[1], as shown below. [image: image] <https://user-images.githubusercontent.com/33801130/174596646-09e7cb3f-f735-4f7e-b3b8-d847b51c03bd.png> The length of a GCL is not inifinte, due to the limited hardware capacity. In fact, a typical TSN switch can only support 1024 gate control entries. Therefore, a GateConfigurator should take this GCL limitation into consideration, otherwise the calculated schedule would be impractical. I think it would be great to set a upper bound for the GCL length and verify whether the output of a GateConfigurator is feasible. Reference: [1] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic," in IEEE Std 802.1Qbv-2015 (Amendment to IEEE Std 802.1Q-2014 as amended by IEEE Std 802.1Qca-2015, IEEE Std 802.1Qcd-2015, and IEEE Std 802.1Q-2014/Cor 1-2015) , vol., no., pp.1-57, 18 March 2016, doi: 10.1109/IEEESTD.2016.8613095. — Reply to this email directly, view it on GitHub <#771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3OTJLHEWEUE43QQSDDY3VQBNURANCNFSM5ZHI7TYA> . You are receiving this because you commented.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[yue2388253]

Hi Levy,

In the TSN TAS showcase ("showcases/tsn/trafficshaping/timeawareshaper/omnetpp.ini"), the gates are configured as follows:

*.switch.eth[*].macLayer.queue.transmissionGate[0].offset = 0ms
*.switch.eth[*].macLayer.queue.transmissionGate[0].durations = [4ms, 6ms] # period is 10 # length of periods
*.switch.eth[*].macLayer.queue.transmissionGate[1].offset = 6ms
*.switch.eth[*].macLayer.queue.transmissionGate[1].durations = [2ms, 8ms]

I'd like to implement a GCL module so that one can configure the gate states as follows, which is totally the same as the configuration above.

*.switch.eth[*].macLayer.queue.gateControlList.offset = 0ms
*.switch.eth[*].macLayer.queue.gateControlList.entries = ["01", "00", "10", "00"] // Or may be ["11111101", "11111100", "11111110", "11111100"]
*.switch.eth[*].macLayer.queue.gateControlList.durations = [4ms, 2ms, 2ms, 2ms]

Could you give me some advices that how to implement such a module? Thanks.

Best regards,
Lin

[levy]

You just need to create a module which processes its parameters in the initialize method and looks up the individual gate modules and sets their parameters. The auto configurators essentially do the same, they start from a different set of parameters and process then differently.

…

On Fri, 24 Jun 2022, 08:53 Jiashuo Lin, ***@***.***> wrote: Hi Levy, In the TSN TAS showcase ("showcases/tsn/trafficshaping/timeawareshaper/omnetpp.ini"), the gates are configured as follows: *.switch.eth[*].macLayer.queue.transmissionGate[0].offset = 0ms *.switch.eth[*].macLayer.queue.transmissionGate[0].durations = [4ms, 6ms] # period is 10 # length of periods *.switch.eth[*].macLayer.queue.transmissionGate[1].offset = 6ms *.switch.eth[*].macLayer.queue.transmissionGate[1].durations = [2ms, 8ms] I'd like to implement a GCL module so that one can configure the gate states as follows, which is totally the same as the configuration above. *.switch.eth[*].macLayer.queue.gateControlList.offset = 0ms *.switch.eth[*].macLayer.queue.gateControlList.entries = ["01", "00", "10", "00"] // Or may be ["11111101", "11111100", "11111110", "11111100"] *.switch.eth[*].macLayer.queue.gateControlList.durations = [4ms, 2ms, 2ms, 2ms] Could you give me some advices that how to implement such a module? Thanks. Best regards, Lin — Reply to this email directly, view it on GitHub <#771 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3OTOYVQ2XKE2FAJVEWUDVQVLORANCNFSM5ZHI7TYA> . You are receiving this because you commented.Message ID: ***@***.***>

[levy]

The GateControlList module that was submitted in a pull request has already been merged into INET and it is part of INET 4.5. So I guess I can close this issue.