25 Mar
2019
25 Mar
'19
4:27 p.m.
Hi Neels,
On Mon, Mar 25, 2019 at 01:58:21AM +0100, Neels Hofmeyr wrote:
The templates for GSUP in GSUP_Types.ttcn seem to
expect the GSUP IEs in a
specific order, which shouldn't be required.
It shouldn't be required like in any of the protocols we deal with. The
reality is different, at least for the 3GPP defined specs: Order is strictly
required. You may not change the order of IEs, even though there are IEIs in
the TLV structure that would allow for it.
In Osmocom C language (and likely other implementations) we don't care
on the receiver side, but to be a compliant transmitter, we must use the
correct order.
For GSUP now we can of course do something completely different, if we want to.
I'm not sure what the GSUP specification document which we publish says
about it.
I would personally argue in favor of not permitting any random order of
IEs.
If you look at the various protocol Modules that Ericsson wrote for TTCN3,
they all require the spec-mandated fixed order, contary to those "possibly more
elgant/generic" protocol implementations that we added but which don't enforce
any order.
Also I cannot easily define certain GSUP IEs as not
mattering.
Particularly, I added Source Entity and Destination Entity IEs, and now I would
have liked to just add some source_entity := *, destination_entity := *, to
trivially make all tr_GSUP() pass, whether these IEs are present or not.
Instead I have to now add them to a listing of IEs everywhere.
That means the test suite will only work with the new osmo-msc and even if
"nightly" works out, we will see "latest" failing, etc.
why is that? You can easily have a "*" inside the list of IE templates to
allow
for zero or more additional IEs of any kind.
The GSUP IEs are defined as "type record of GSUP_IE GSUP_IEs;" which enforces
strict ordering. One could theoretically use "type set of GSUP_IE GSUP_IEs"
which is an unordered set allowing any order. However, a "set of" also
permits for duplicate elements. Not sure if that's what you want.
An alternative is the "permutation" qualifier for a "record of"
template, which basically says "all of those elements must be present
exactly once, in any order possible". See slide 176 of TTCN3_P.pdf
So something like the combination of the change "record of" -> "set
of"
and the addition of a single '*' to the list of IEs should turn a receive
template into what you'd like.
There's also the "superset" qualifier. So if you define a set of IE
templates
and state you want to permit any superset on that set, then also any additional
attributes
beyond those minimally requierd ones in the set are accepted. See slide 175
of the "TTCN3_P.pdf" presentation.
I'd like to use the semantics I am used to in e.g.
BSSMAP messages:
- order doesn't matter
This is wrong. The BSSMAP dissector does not permit any order except the one
specified in the specs!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)