Dear Harald,
Thank you for your reply. There is not need to apologise.
> 2) 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/>.
