SCCP connection identifiers vs. local references

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Mar 20 07:22:35 UTC 2019


Hi Neels,

> 21:14 < neeels> LaF0rge, I need a solution for picking a conn_id as an SCCP SAP user. The way osmo-bsc
>                 does it isn't much good either. There has to be some way to obtain an unused local
>                 reference without running into potential collisions
> 21:16 < neeels> (I submitted the patch expecting your -1, but just to make sure that I understood
>                 correctly I wanted to submit as code that has no room for misunderstandings)
> 21:18 < neeels> if I can't use the internal "next_id" thing, then what I would have to do is mimick the
>                 exact same in osmo-msc by looking up what conn_ids are already in use and pick an unused
>                 one. That's quite brain damaged IMHO, it's the same thing as that layer violation patch,
>                 only with much more effort and more chances for id collisions.

Nobody is suggesting that.

> 21:21 < neeels> ideas: add some primitive to hand out a local reference -- but that would be non-standard
>                 IIUC

I had mentioned and discarded that option in Message-ID: <20190311204817.GA725 at nataraja>
here on this list.  The reason is not that it's non-standard, but that it again wouldn't
work over any type of asynchronous / message based SAP [and that's how a SAP is conceptualized].

> 21:21 < neeels> give each application some unique number space for local references, like the highest
>                 byte is configured in .cfg file, and then each SCCP user cycles through its own number
>                 space of local references
> 21:23 < neeels> ...and libosmo-sccp would have to be constrain-able to its own number space for incoming
>                 connections

I was quite sure we've had that discussion before.  Unfortuantely it doesn't
seem to be on this mailing list or in gerrit.  It may have been on IRC or I am
starting to be delusional :/

The correct solution from the spec / SCCP architecutre point of view is rather clear, I think:

* don't recycle the SCCP local reference (protocol) from the SCCP connection ID (SAP),
  but use distinct number spaces for that.  It was an oversimplification to do that
  in the original implementation.  I simply missed the different scoping of those
  two identifiers.  The scoping is the root of our problems here.

* only once we have distinct identifiers, we can fix the scope: One of
  the two identifiers has a per-SCCP-user scope, while the other has a
  per-SCCP-instance scope

* this way, every SCCP user knows exactly which SCCP connection identifiers are
  currently in use between this specific user and the SCCP provider, and it hence
  can choose any unused ID for a new connection

* right now, the primitive exchange across the SCCP user SAP is synchronous,
  so there can be no races where the SCCP provider and the SCCP user could
  chose the same connection ID at the same time.   If you want to prepare for
  some kind of possible future asynchronous, message-queue based SAP, then you
  could use the highest bit as "allocation flag", e.g. highest bit = 0, allocated
  by the SCCP provider and highest bit = 1, allocated by SCCP user.

Let me know if you see any problem with above proposal.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list