Dear Osmocom developers,
In our project we have been using the gsmtap pseudo-header to store UMTS and LTE signalling traces in pcapng format. This is very efficient compared to our previous implementation based on DLT_USER, and thanks to the gsmtap dissector, it allows any *shark app to read our output file.
When looking for the proper type and sub_type for NR signalling traces, I discovered they are not yet part of the standard. I found several threads of discussion about this, from about 2017 onwards, and I understand it is a matter of time and resources if the version 3 of GSMTAP has not been released.
The most interesting feature I have read about is the ability to extend the header with a TLV approach. EARFCN, eNodeB-ID, PCI, are useful metadata we would like to add to our traces.
In an ideal world, I would like things to be put in motion so that a new version of GSMTAP could see the light. More humbly, I ask you what kind of help is needed. Are you waiting for a draft specification? Are all requirements well known?
I suppose that LTE and NR are not the main focus today for liboscmocore development, but there are many projects out there waiting for the GSMTAP format to be updated.
Thanks!
Mauro
Hi,
Since no one has replied to my previous very generic message, I come forward with a proposal hoping to trigger a discussion.
As you know, the current definition of the GSMTAP header has a version field that could enable new versions to be safely introduced. Unfortunately, Wireshark decoder does not check the value of the version field, it just presents the value in the decoded output. It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
This is the current gsmtap_hdr definition. Some fields are only relevant in the context of a GSM capture, while the meaning of others (notably type, sub_type) has changed over time to describe a payload of a newer technology.
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 | hdr_len | type | timeslot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | arfcn | signal_dbm | snr_db | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | frame_number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub_type | antenna_nr | sub_slot | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When hdr_len is greater than 4 (the length is 4 * 4 = 16 octets), it is possible to store additional information in the header, without breaking any compliant decoder implementation. This new header section could contain a sequence of TLV entries with a 2 octet tag, a 2 octet length field, and a value field padded to the nearest 32 bit boundary.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field allows decoders to skip unknown tags. To improve storage performance, a subset of tags for values with a length less or equal to 2 octets can be defined (something like this was proposed in 2012 during the GSMTAPv3 session). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tag | value (padded to 16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| tag | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this last variant, we have 32k tags for "small" values and 32k tags for full TLV entries.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
What are your thoughts about this?
Mauro
Hello Mauro,
Thanks for this message. I was preparing my suggestion at https:// gist.github.com/peremen/f8f199bf89e8f4c3e0b5e3f9e141b275#file-gsmtapv3-md which I targeted to migrate to the Osmocom's gitea some time ago.
It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
That was open also in my suggestion, but if older Wireshark will continue to parse the GSMTAP header for the whole 16 octets when the type is unknown, then I am also aligning towards this idea. I was thinking allocating a "protective type" on GSMTAPv2 to not parse GSMTAPv3 packets by GSMTAPv2-only implementation.
This new header section could contain a sequence of TLV entries with a 2 octet tag, a 2 octet length field, and a value field padded to the nearest 32 bit boundary.
What I was thinking is defining a new data structure for each payload type and optionally extend them in the future using TLV entries. See my proposal for the type-specific data structure.
The compact storage format to cover both TV and TLV entries sounds also good. Given that 1) existing GSM applications can still use GSMTAPv2 (correct me if I am wrong - whether GSMTAPv2 and v3 will be coexisting) and 2) for 4G and 5G RRC/NAS, payloads could be longer than 1000 octets, where 2 additional length octets may not actually be relevant at all, using TLV exclusively might not be so problematic regarding the performance.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
I was thinking similar usage by reserving a range of types for this purpose. Tags should be also included too.
In addition, I will going to present a talk in this OsmoDevCon [1], and I am currently planning to finalize the proposal before the conference.
[1] https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2024
Shinjo
2024년 2월 27일 화요일 오후 3시 38분 11초 CET에 Mauro Levra 님이 쓴 글:
Hi,
Since no one has replied to my previous very generic message, I come forward with a proposal hoping to trigger a discussion.
As you know, the current definition of the GSMTAP header has a version field that could enable new versions to be safely introduced. Unfortunately, Wireshark decoder does not check the value of the version field, it just presents the value in the decoded output. It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
This is the current gsmtap_hdr definition. Some fields are only relevant in the context of a GSM capture, while the meaning of others (notably type, sub_type) has changed over time to describe a payload of a newer technology.
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 | hdr_len | type | timeslot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| arfcn | signal_dbm | snr_db |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| frame_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub_type | antenna_nr | sub_slot | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When hdr_len is greater than 4 (the length is 4 * 4 = 16 octets), it is possible to store additional information in the header, without breaking any compliant decoder implementation. This new header section could contain a sequence of TLV entries with a 2 octet tag, a 2 octet length field, and a value field padded to the nearest 32 bit boundary.
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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tag | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value |
~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field allows decoders to skip unknown tags. To improve storage performance, a subset of tags for values with a length less or equal to 2 octets can be defined (something like this was proposed in 2012 during the GSMTAPv3 session). 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| tag | value (padded to 16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| tag | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value |
~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this last variant, we have 32k tags for "small" values and 32k tags for full TLV entries.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
What are your thoughts about this?
Mauro
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:
As you know, the current definition of the GSMTAP header has a version field that could enable new versions to be safely introduced. Unfortunately, Wireshark decoder does not check the value of the version field, it just presents the value in the decoded output. It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
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.)
The length field allows decoders to skip unknown tags. To improve storage performance, a subset of tags for values with a length less or equal to 2 octets can be defined (something like this was proposed in 2012 during the GSMTAPv3 session). 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tag | value (padded to 16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| tag | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
In this last variant, we have 32k tags for "small" values and 32k tags for full TLV entries.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
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
Thank you, Neels and Shinjo, for your insights.
What I was thinking is defining a new data structure for each payload type and optionally extend them in the future using TLV entries. See my proposal for the type-specific data structure.
@Shinjo, I did not know about your existing proposal. I understand the idea about type specific headers, but I think it may lead to problems and increased compatibility issues in the future, as more types are added. I would suggest to use TLV exclusively.
In addition, I will going to present a talk in this OsmoDevCon, and I am currently planning to finalize the proposal before the conference.
That is good news, good luck for your proposal.
---
@Neels, do not say you are bikeshedding, because your comments are not trivial at all... :D
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?
Yes, it is only about that. For me it is not a strong requirement, just a nice-to-have, as you say.
What makes v3 to v2 compatibility such an important requirement?
It can be a design constraint, or not. In my initial message I tried to lay down the most safe and backward compatibile proposal possible.
(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.)
I can send a merge request to Wireshark team to address this. The sooner we add this version check the better.
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.
From the notes of the 2012 talk, I understood that someone would be happy with this level of optimization. Having a single format (T16L16V) will of course be the most simple and efficient (CPU wise) solution. Also, 12 years have passed.
It's essentially the same as you suggest, but it unloads the protocol definition from having to coordinate specific vendors' tag ranges.
I agree, it is a nice change of perspective.
The final part of your email about extensions and vendor specific tags is really interesting, but I do not have enough experience to give you a useful feedback. I wonder if we can copy this mechanism from an existing protocol definition.
Thanks,
Mauro
On Thu, Feb 29, 2024 at 05:16:29PM -0000, Mauro Levra wrote:
The final part of your email about extensions and vendor specific tags is really interesting, but I do not have enough experience to give you a useful feedback. I wonder if we can copy this mechanism from an existing protocol definition.
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 Mauro,
my apologies for not following-up sooner. Seems like my workload at the moment doesn't permit me to participate effectively in detail :/
On Tue, Feb 27, 2024 at 02:38:11PM -0000, Mauro Levra wrote:
As you know, the current definition of the GSMTAP header has a version field that could enable new versions to be safely introduced. Unfortunately, Wireshark decoder does not check the value of the version field, it just presents the value in the decoded output. It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
First of all: My apologies for not making things more future-proof in the beginning. GSMTAP initially was just a local hack for use within a very small group of people around open source GSM; it was not clear at the time we'd be looking at a more frequently used things. So a lot of it happened very ad-hoc.
As the patch for just decoding v2 has now been merged to wireshark, I think we could deviate from that.
However, there will always be people with older versions of wireshark for years to come, so having some kind of user experience that avoids giving them completely garbled output.
I guess we can achieve that two ways:
1) by keeping the full header as you suggest here, or
2) by making sure that the version and type fields retain teir position, where version would be '3' and the type would use something that is not defined for GSMTAPv2, resulting in none of the existing decoders being called for a GSMTAPv3 packet arriving at an old wireshark version
When hdr_len is greater than 4 (the length is 4 * 4 = 16 octets), it is possible to store additional information in the header, without breaking any compliant decoder implementation.
the maximum size would be 255 * 4 = 1020 bytes. This would only work if the combination of all hypothetical future additional header fields will always be below that limit. It would also mean that the actual payload data cannot be encoded in the TLV structure itself, but would come after the TLV section.
So while that doesn't sound like much of a constraint now, I'd like to prevent creating yet the next limitation that we have to work around later.
The length field allows decoders to skip unknown tags. To improve storage performance, a subset of tags for values with a length less or equal to 2 octets can be defined (something like this was proposed in 2012 during the GSMTAPv3 session). Like this:
Sure, it can be done - but I'm not sure this is worth the effort.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
This is of course a bit of a difficult topic. In general we'd want to avoid vendor-specific stuff as it adds incompatibilities with other implementations, which will fragment the tools that can work with a given capture file, etc.
In general, there's multiple ways of addressing that:
1) splitting the entire range by one bit. I think that's too many vendor-specific fields.
2) having few 'reserved for local use' values, like DLT_USER in pcap
3) having a full-blown mechanism for any vendor to add their own tag definitions, like for example in the IPFIX/NETFLOW format.
4) having some kind of registry or fast enough process where vendors can register/allocate tags for their use cases. Similar to how IANA operates for registering port numbers or other fields in other protocols.
I'd personally prefer '3' or '4' in that those approaches at least avoid multiple different vendors from allocating the same tag for different purpose.
It's been decades sicne I looked at it, but AFAIR the IPFIX works in a way that there are universal tags, and there are enterprise-specific tags. The latter are prefixed with the enterprise number allocated at https://www.iana.org/assignments/enterprise-numbers/
The universal tags can be short, and the enterprise-specific tags are longer. This means that standard messages are more efficient, whcich is good.
The alternative to such a scheme would be '3': To operate a git repository like we do for the Openmoko OUI/MAC and USB Product ID ranges [1] with a set of guidelienes. Eveyone could then file a pull request to allocate some new field if they fulfill the conditions (which should include some kind of specification as to the name, purpose and encoding of the field).
Regards, Harald
[1] https://github.com/openmoko/openmoko-usb-oui
Dear Harald,
Thank you for your reply. There is not need to apologise.
- by making sure that the version and type fields retain their position, where version would be '3' and the type would use something that is not defined for GSMTAPv2, resulting in none of the existing decoders being called for a GSMTAPv3 packet arriving at an old wireshark version
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.
It's been decades since I looked at it, but AFAIR the IPFIX works in a way that there are universal tags, and there are enterprise-specific tags.
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/.
Sorry, the hdr_len value is wrong in the packet definition shown in my previous message. It should be 5.
Mauro
Hello everyone,
Do you have any feedback on the proposal I described in my previous message? Thanks,
Mauro
Hi Mauro [and list],
as you may know, we've had a GSMTAPv3 session planned for OsmoDevCon 2024 for quite some time. Usually we only have video recordings *after* the event, but this time we actually also have real-time streaming at https://streaming.media.ccc.de/osmodevcon24/osmodevcon
So in the odd chance that you may be available at the time slot when that happens (scheduled for 3:10pm CEST today), you can watch in real time at https://pretalx.sysmocom.de/osmodevcon2024/schedule/
We didn't really have prepared any facility for interactive remote participation, but we can certainly watch the #osmocom IRC channel during the session and take questions that way, or I could open a temporary call / jitsi meeting room that would allow you to make remote comments also via audio.
I realize this is on very short notice, but nevertheless I wanted to offer it, just in case.
In any case, I'd expect results of our session today would end up in some kind of draft spec, so both you and the wider community certainly still has a chance to comment on it.
Regards, Harald
Thank you, Harald.
I saw your email in time, but it was not possible for me to connect and follow Saturday talk. I am going to watch the recording.
Regards,
Mauro
-
Harald Welte -
Mauro Levra -
Mauro Levra
-
Neels Hofmeyr -
Shinjo Park