11 Mar
2019
11 Mar
'19
9:48 p.m.
Hi Neels, from your IRC question today:
when opening a new conn on SCCP, what's the proper
way to get a
conn_id? I want to feed OSMO_SCU_PRIM_N_CONNECT into
osmo_sccp_user_sap_down(), but it seems the caller needs to pick a
conn_id??
Whatever way you can think of to cough up a unique identifer for that connection.
I assumed that libosmo-sccp implicitly picks an unused
local conn
reference, but that's not the case.
Note that in this sentence you're now talking about the "SCCP local
reference", which is something communicated on the wire between two SCCP
providers (implementations). Hence, it is managed inside the
SCCP provider[s] and can be seen in the source local reference /
destination local reference field of the SCCP messages.
That's *not strictly* the SCCP connection identifier which has
significance only across the SCCP User SAP (i.e. between SCCP User and
SCCP Provider on the same system), and which never is visible on any
SCCP message on the wire. It's just an implementation shortcut of the
Osmocom implementation that uses the same identifiers on both sides,
rather than allocating separate ones.
But getting back to your question: If the SCCP provider was to receive
a N-CONNECT.req without some kind of identifier, and simply allocate
one, how would that identifier be communicated back to the user? Those
primitives work asynchronosuly. You'd have to come up with
yet-another-identifier, like a "primitive tag" where that tag then would
be eacho'ed back in the N-CONNECT.resp - and you end up again having to
allocate some unique identifier :P
sccp_scoc.c has conn_create() which seems to pick an
unused id, but
that part is static in a .c file
hnbgw just uses 1:1 the same conn_id from RUA to RANAP
and thus doesn't invent new ones
Now I'm confused. RUA isn't running over SCCP, right?
osmo-bsc goes through its list of
&bsc_gsmnet->subscr_conns to pick an unused id
I can do that in osmo-msc, but it seems to me libosmo-sccp should have common API for
that
The SCCP User SAP is modelled strictly after the ITU specs. Always
imagine yourself in a situation where the SCCP user and SCCP provider
are running in different processes and they don't have access to each
others's state - and all they can exchange are the SCCP User SAP
primitives in some serialized form. While libosmo-sccp doesn't work
like this (so far), we should always keep that in mind and keep the SAP
boundary clean.
As there's no primitive in ITU-T Q.7xx for "allocate me a local
reference", we don't have one :/
I'm not sure what we should do here. If we introduce that kind of SCU
primitive, then the questions is how are they allocated/released? Who
is in charge of that? What kind of object would the SCCP provider use
to keep track of allocated IDs for which there is no connection yet, as
the N-CONNECT.req was not yet received?
The current situation is not great. After all, theoretically there
could be an incoming new SCCP connection for which the provider choses
the same ID that the user at the same time choses for a new outbound
connection -> boom. One could use something like the highest-order bit
to distinguish between user-allocated and provider-allocated
identifiers.
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)
12 Mar
12 Mar
7:36 a.m.
On Mon, Mar 11, 2019 at 09:48:17PM +0100, Harald Welte wrote:
Either way there is some RUA id and hnbgw just uses that 1:1 for outgoing RANAP
connections. There aren't any incoming ones from RANAP, at least yet. So when I
tried to copy hngbw's way of coughing up an id I was disappointed.
~N
The SCCP User SAP is modelled strictly after the ITU
specs. Always
imagine yourself in a situation where the SCCP user and SCCP provider
are running in different processes and they don't have access to each
others's state - and all they can exchange are the SCCP User SAP
primitives in some serialized form.
So the point is that this next_id used in below patch could be in a different
process than the one composing the N_CONNECT prim in need to invent the
conn_id?
How can individual users then possibly avoid treading all over each others
scu_prim.u.*.conn_id numbers?? Assign a unique part of the number space to each
user or something?
So as long as we don't separate into different processes we're fine?
To me personally, it feels like we should be done separating by now :P
Using the current single-process status quo, I wrote in code what I mean.
Is this bad in any way?
http://git.osmocom.org/libosmo-sccp/commit/?h=neels/conn_id&id=9e735cc5…
The point is that when a CONNECT comes in from the remote side, this bit of
code picks a conn_id that becomes visible in the scu_prim.u.connect.conn_id.
The reverse way, sending a CONNECT from here to the remote side, why not use
the exact same mechanism to cough up a prim.u.connect.conn_id?
BTW, what osmo-bsc does (picking any conn_id it isn't currently using) also
wouldn't work if there were multiple users for an SCCP provider in separate
processes. How does existing separate-process software solve this?
(In above patch I also introduced the possibility to exhaust the conn_id number
space gracefully, however far fetched and completely unrealistic that may be.)
This patch works for osmo-msc in ttcn3-msc-test for inter-BSC Handover.
What kind of object would the SCCP provider use
to keep track of allocated IDs
The one in above patch is struct sccp_connection from sccp_scoc.c
for which there is no connection yet, as
the N-CONNECT.req was not yet received?
(yes, also a tricky one in allocating a new RAN connection in osmo-msc.)
In current single-process mode, sccp_scoc.c just inst->next_id++ and hence will
only deal out the same ID 0xffffffff times later, regardless of the caller
actually using them / of struct sccp_connection created or not.
The current situation is not great. After all,
theoretically there
could be an incoming new SCCP connection for which the provider choses
the same ID that the user at the same time choses for a new outbound
connection -> boom.
Currently, in a single process, sccp_scoc.c increases the inst->next_id for
outgoing and for incoming requests, which is synchronous, and there is no
problem. Would be if becoming asynchronous though.
BTW, again looking at current osmo-bsc: since osmo-bsc invents its own new IDs
without doing inst->next_id++, the next_id doesn't cycle so nicely, so possibly
an outgoing conn_id that has just this instant stopped being used might be used
right away again for an incoming N_CONNECT, because osmo-bsc didn't increment
the inst->next_id. Or in other words, every Handover Request from the MSC will
start from id 0 while Complete-L3 from BSC have already moved up past 0 before.
Not illegal as such, but still would be nicer to have some grace period before
re-using existing numbers, if for nothing else then for reading log files. So
while we're having the provider in the same process, it might be nicer to also
use above patch in osmo-bsc, to ensure the next id is always larger than the
previous ones.
...unless you're completely against this kind of thing.
Though there isn't really an alternative solution right now AFAICT.
hnbgw just
uses 1:1 the same conn_id from RUA to RANAP and thus doesn't invent new ones
Now I'm confused. RUA isn't running over SCCP, right?
1895
days inactive
1896
days old
1 comments
2 participants
participants (2)
-
Harald Welte -
Neels Hofmeyr