I'm not deeply familiar with the topic, but reading along, the below would be my bikeshed feedback =) On Tue, Feb 27, 2024 at 02:38:11PM -0000, Mauro Levra wrote: Just to understand the aim: we can of course fix the wireshark dissector to handle the version properly. The idea to keep v3 backwards compatible is only about making older wireshark installations "magically" compatible with the new gsmtap version? I find that this is just a nice-to-have, and i have often upgraded wireshark in order to support a specific protocol. What makes v3 to v2 compatibility such an important requirement? For me it is "just" a short transition phase until all users have gotten around to upgrade their wireshark installation? (If someone back in 2012 had fixed wireshark to handle the version number properly, then no-one would even mention it today. Seems silly to design a protocol around such a short-lived peculiarity of one specific program.) We already have at least two TLV parsing APIs in osmocom, and having written one of them, I'd like to give this feedback: things become a lot easier when there is no variance in the sizes of the length field. If the aim of this is to save one byte of payload, I find this quite anachronistic. In 2024, we don't need to optimize for network bandwidth, instead we want to optimize for CPU load. It makes for far simpler (optimizable) decoders when T and L have a single fixed size. I guess there is a long history behind this proposal, but the voice in my head says: in 2024, Why not pick 16bit for both T and L from the start and be done with it. Allowing 64k tags of 64k octets without special implications seems more appropriate for the future than still dabbling with designs that have a limit of 256 on a very low protocol level. For example, PFCP is one of the newer 3GPP protocols, and it features a T16L16V. Looking at libosmo-gtlv as an example for a TLV coder, it is of course possible to have an osmo_gtlv_cfg.load_tl() function that knows which tag is longer and which is shorter -- it then will decide on a size for every single tag value that is encountered. Just, it seems to me more desirable that iterating tags should be fast, just copying fixed sizes without code branches. It is then also easier to skip unknown tags. Slight nuance of definition: I would recommend not assigning a specific single bit to a specific vendor, because it is too specific. Instead I'd reserve a tag range for gsmtapv3, and leave the rest "application specific" for any vendors to do what they please. For example, in case of T16, we can reserve 0-0x7fff for future "native" protocol extensions. By defining this way around, instead of having 0x8000 to 0xffff reserved specifically for Osmocom, we have 0x8000-0xffff available to any vendor. The vendors can, within that non-reserved tag range, decide between each other to decide for a vendor specific tag range (or not). It's essentially the same as you suggest, but it unloads the protocol definition from having to coordinate specific vendors' tag ranges. For the record, TLV is excellent for allowing vendor specific extensions, because any parser can trivially skip parts of the message that it doesn't understand, without any prior knowledge. There is still the possibility that two vendors do insufficient research and happen to use the same tag values for distinct meanings; if both vendors gain traction, then at some point wireshark will be confused between them. If we want to guard against this beyond doubt, there could be an officially defined tag indicating the nature of tag extensions. Like a simple string: T: TAG_EXTENSION_VENDOR L: 9 V: "Osmocom-1" For example, an Osmocom vendor could be required to include this TLV, indicating that extension tags should be interpreted as Osmocom version 1. In the lack of such, any parser can skip or error unknown tags. At some point, "Osmocom-2" could reshuffle the used tag values, etc. (This tag could itself be an osmocom specific tag, but it would be much more elegant protocol design if there is one common mechanism across all vendors to define usage of the vendor-specific range.) Finally, I have yet another idea for vendor specific extensions: in PFCP, there is a concept of "grouped IEs". In essence, a nested TLV structure inside an outer V. So we could define a *single* vendor specific extension tag, that can contain within it any number of vendor specific TLVs, like this: T: TAG_EXTENSION L: 456 V: { octet 0: vendor_id_len=9 octet 1..n: "Osmocom-1" octet n+1..456: nested TLV structure T: ... L: ... V: { ... } T: ... L: ... V: { ... } } In this variant, the "TAG_EXTENSION" is a fixed official tag, and it defines that the start of V defines a vendor id string. Any parsers that don't know extensions skip the entire vendor-specific subsection in one jump (in above example, skip 456 octets once instead of each vendor tag one by one). A parser that knows Osmocom extensions will look at the TAG_EXTENSION V, verify that it starts with a supported "Osmocom-1" string, and only then evaluate the TLV within. (For libosmo-gtlv, this is already supported, because we already implemented this for PFCP parsing.) Those are my two cents! Just some ideas from the off. ~N

On Thu, Feb 29, 2024 at 05:16:29PM -0000, Mauro Levra wrote: As I said, an example would be the "Grouped IEs" in PFCP, meaning nested TLV structure inside a V. libosmo-gtlv supports those. But thinking again .. I guess I would do that only in T8. In a T16 range, there are so many T that it's ok to go simpler: let everyone add Ts as they please, pretty much like we deal with TCP and UDP port numbers on our servers... ~N

Dear Harald, Thank you for your reply. There is not need to apologise. For what concerns users with older versions of wireshark, I like your proposal of leveraging the type field to trick the old decoder into doing nothing. This can be achieved by setting type to any usused value, like 255. The fixed header of version 2 is made of 16 octets. For version 3, if we go down the TLV way with Information Elements, we may not need any other information in the header, but I think leaving some important fields in the packet header can help. Example of fields in the header: * Total Length: by adding a field with the total length in octets, it would be possible to transport GSMTAP over stream protocols. * Sequence Number: it exists today as frame_number, it can be useful to keep a way to reorder packets on the receiver. * Timestamp: GSMTAP is built to carry tapped data. It may make sense to record the precise timestamp at the tapping source, encoded as 64-bit unsigned integer (microseconds or nanoseconds since the epoch). The header would become something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | 4 (hdr_len) | 255 (type) | 0 (unused) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After the header, a sequence of Information Elements is present. Good idea, what follows is greatly inspired by IPFIX [RFC7011]. Each Information Element is identified by a unique identifier. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Information Element ident. | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: E Enterprise bit. This is the first bit of the Information Element. If this bit is zero, the Information Element identifier identifies a standard Information Element (defined by Osmocom), and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number field MUST be present. Enterprise Number IANA enterprise number [IANA-PEN] of the authority defining the Information Element identifier. Length Total length of the Information Element. What do you think of this? Also, do we need to keep IEs aligned to 32-bit boundaries? If so, mandatory padding must be added to the IE definition. Regards, Mauro [RFC7011] <https://datatracker.ietf.org/doc/html/rfc7011>. [IANA-PEN] IANA, "Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers/>.

Hello everyone, Do you have any feedback on the proposal I described in my previous message? Thanks, Mauro