Feature #2905

implement proper/generic mandatory IE validation

Added by laforge almost 3 years ago. Updated about 2 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


In almost all of the TLV based protocols we deal with (OML, RSL, BSSAP, RR/CC/MM/...) the specification of the individual messages alwys includes a statement on which IEs are mandatory, which are conditional and which optional.

In some of our later protocol implementations such as sua/m3ua in libosmo-sigtran, I have introduces some data structures which are basically constant arrays of integers, listing all mandatory IEs for each message type.

Such data structures should be created for our earlier protocol implementations (particularly RR/CC/MM), and some generic function should be added next to our TLV parser to determine if all mandatory IEs for a given message exist. This step would then be done as a separate function call by the library user, after having called tlv_parse.

The callers must then make sure to take the appropriate action, such as informing the sender with the proper cause (such as "invalid/missing mandatory information".

We don't need the same information for optional IEs, as unknown optional IEs are typically silently ignored to ensure future compatibility.

So the general policy would then be:
  • call tlv_decode()
  • call the new "verify if all manatory IEs present" function
    • if some are missing, return protocol-specific error
  • "manual" check if all conditional IEs present (not possible in generic verifyer)
  • ignore any unknown/unhandled optional IEs


#1 Updated by fixeria over 2 years ago

  • Project changed from Cellular Network Infrastructure to libosmocore
  • Category set to libosmogsm
  • Status changed from New to In Progress
  • Assignee changed from sysmocom to fixeria

#2 Updated by fixeria over 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 30

A conceptual implementation has been sent for review:

There is no actual verification logic (yet), but there are basic structures
and some examples of their usage (see tests/tlv/tlv_msg_def_test.c).

Before implementing it, I need to know whether the proposed API is good,
or should I change / extend it. Any ideas are welcome!

#3 Updated by laforge about 2 months ago

  • Assignee changed from fixeria to laforge
  • % Done changed from 30 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)