[Feature request] TTDP support (Railways protocol)

[jp-t]

Hello,
The standard IEC 61375-2-5 defines the TTDP protocol. It uses 2 types of frames, one of which is an LLDP frame with one custom TLV with OUI 200E95 (the other frame is somewhat unrelated).

There is already some support for custom TLVs in lldpd. What is missing AFAICT is

• ability to use milliseconds periodicity for sending
• ability to detect that a neighbour stopped transmission, and change the sending periodicity based on this
• ability to generate and check a frame counter inside the custom TLV
• ability to detect important changes (e.g. death of a neighbour) and signal it outside.

Question 1
I am willing to implement this but I wonder what is the best way ?
Can I achieve this in form of a plugin for example ?

Question 2
I had no difficulty to make periodicity work in milliseconds, but, for compatibility, I guess I should add a configuration parameter to indicate the time unit, how can I do this ?

Question 3
Is it worth considering to process the other TTDP frame inside lldpd, or is it completely out of the scope of this software ?

[vincentbernat]

About milliseconds periodicity, I don't know if lldpd is optimized enough to be able to do that. The frame is always rebuilt from scratch. This will incur high CPU usage. Moreover, without realtime, Linux won't schedule lldpd often enough to achieve such a periodicity.

As for the ability to detect changes, it's already implemented. If you use lldpcli watch, you will receive a notice when a LLDPDU expires. Using liblldpctl, you can get this information into another program.

Question 1: lldpd doesn't have a plugin system. But you can enable/disable part of the code at compile time. This is done for the various third-party protocols (CDP, NDP, EDP). You can do the same. As you will reuse mostly the same code for TTDP and LLDP, just look at how this is done for CDPv1/CDPv2. You can either define a new protocol or just make src/daemon/protocols/lldp.c able to generate TTDP frames.

Question 2: I think that you can just specify add a unit to tx-interval: tx-interval 20 means 20 seconds but tx-interval 20ms means 20 milliseconds.

Question 3: if the information of the other TTDP frame can be built from the information in lldpd_chassis and lldpd_interface, I have no problem if you add this new frame format.

[jp-t]

Indeed on my platform, there seems to be a bottom limit of 125 ms under which lldpd eats all the CPU, which is strange because above this limit (say, 126ms) the CPU consomption is very low. I am searching through libevent to understand this. Any better idea ?

[vincentbernat]

Maybe try to do a CPU flamegraph. Look at http://www.brendangregg.com/flamegraphs.html. You need debug symbols to make it meaningful.

[jp-t]

Ok thanks. In the meantime I found a side effect of using ms timers: TTL becomes 0 which is wrong.
It makes the cleanup function to be rescheduled as soon as it executes. By rounding up the TTL to 1s the CPU overload problem goes away.
Now with tx-interval=15 ms lldpd consumes about 4% CPU on my ar71xx platform, while with tx-interval=2s (2000 ms) it consumes about 1% CPU. So it looks useable.

[jp-t]

Question 2: I think that you can just specify add a unit to tx-interval: tx-interval 20 means 20 seconds but tx-interval 20ms means 20 milliseconds.

Well, command parsing is not easy in lldpd, and there are 2 issues here: parsing and transmitting.

1. transmitting.
   It looks like tx-interval is defined somewhere to be an integer that can be either positive or -1.
   I could either :

• transmit a separate flag for the unit (requires understanding the marshaling stuff),
• always transmit in ms even when configured in seconds (cleaner but would break ABI),
• transmit a negative value for ms (I could not transmit 1ms because -1 is reserved, but I do not really care).

What would you prefer ?

2. parsing:
   I cannot just append 'ms' because tx_interval is an integer.
   I guess it's strtonum() in lldpctl_atom_set_str() that checks that. I could hack this function to check for "ms" and turn to a negative value, or change the syntax to make "ms" a separate token.
   What do you think ?

[vincentbernat]

There is no ABI between lldpd and liblldpctl. We can manage an ABI change inside liblldpctl, but it should be easier to not. We cannot break the API in a backward-incompatible way. What I propose:

• we store the tx interval in milliseconds in lldpd
• in lldpctl.h, you add lldpctl_k_config_tx_interval_ms which will handle the case where the users want to use milliseconds. The lib will always transmit in milliseconds to lldpd but will convert to seconds when requesting lldpctl_k_config_tx_interval.
• you update the client lldpcli to use the new "method"
• you add parsing of "ms" suffix in conf-lldp.c (and in display.c to only use ms if its not divisible by 1000 to not break users parsing lldpcli output).

[fernandojiang]

hi MR Tosoni,
Sorry to bother you, I am a chinese,
when I search some informations about TTDP, I saw this request "
[Feature request] TTDP support (Railways protocol) #378"

now , I want to learn the TTDP， could you help me, Have you completed the code for the TTDP protocol?
Can you send it to me for learning?
thank you very much.

Apologize again for my audacity!