6 Jul
2017
6 Jul
'17
11:31 a.m.
Hello Neels,
(any reason to not discuss this on openbsc@?)
I
put it on CC.
Still missing in this proposal: how do you tell e.g.
the MSC's A and
IuCS code
to use a given SCCP instance, local SSN and remote
SCCP address?
I would add a VTY command where the user has to tell on which ss7 instance
the A or IuCS interface should bind. When the IDs for both match up, we know
that we use the same SCCP instance, but I think we do not even have to check
that. Its implicit by the pointers. If the numbers are the same we will end
up with the same sccp instance pointer for both.
The SCCP-Addresses are defined by the addressbook. Which one is used will be
configured via a VTY command seperately. The SSNs are hardcoded, so this is
not a problem currently. If someone wants configurable SSNs and wants two
users with different SSNs but same local point codes (which is mandatory in
this case), then the user would have to define two addressbook entries where
only the SSN is different. Logically this is then a different address
and look
at postal addresses, there its the same. Two different houses next to each
other will have different addresses. The only difference is the number
(SSN).
At some point we have to make the cut.
We could think about unifying the osmo_sccp_user_bind() function as
well, so we
would get pointers for ready-to-go sccp-users as well, but I think this
is out
of scope right now. The solution would be similar to the addressbook. We
would
just define nodes which hold the parameters. The results end up in a
list and
after parsing is done. The user can call a function that only gets the
ID that
references the parameter set, the pointer to the sscp instance and the
function pointer for the SAP. e.g.:
osmo_sccp_user_bind_id(sscp,2,sccp_sap_up)
A much simpler soultion to the problem would be to
pack the configuration
options into struct osmo_ss7_instance. Then when the config file parsing
is done, the user must call a function e.g. "osmo_sscp_init()" or so to
trigger the call to osmo_sccp_simple_client().
In struct osmo_ss7_instance we already have the .cfg sub struct. I think we
should add the items there instead of introducing something new. Also if
we do
so we would have to change it for the existing code too to have it
consistent.
Lets do some practical examples:
1) A and IuCS use the same sscp/ss7 instance
cs7 instance 1
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs_and_a
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 1
local-addr msc_local
1) A and IuCS use separate sscp/ss7 instances
cs7 instance 1
sccp-address msc_local
point-code 0.0.1
routing-indicator PC
sccp
name a
pc msc_local
prot M3UA
local-port 1230
remote-port 5670
local-ip 1.1.1.4
remote-ip 2.2.2.4
cs7 instance 2
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 2
local-addr msc_local
regards.
Philipp
--
Philipp Maier <pmaier(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
6 Jul
6 Jul
3:10 p.m.
New subject: sscp-context initalization via VTY
In struct osmo_ss7_instance we already have the .cfg
sub struct. I think we
should add the items there instead of introducing something new. Also if we
My concern was that we might mix scopes that should rather remain independent.
I don't know any details or reasons though. Now I noticed that struct
osmo_ss7_instance does contain an osmo_sccp_instance pointer as well as the
sccp_address_book, i.e. they are already intimately related. So that seems to
be the right place after all.
These being so closely tied brings me to a simplification of the VTY I'll get
to at the end of this mail.
Will we ever use osmo_ss7_instance for anything else than SCCP?
1) A and IuCS use the same sscp/ss7 instance
cs7 instance 1
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs_and_a
pc msc_local
so this takes just the PC from the msc_local address, ok. Techincally we don't
even need to define a separate address, but give only a PC:
pc 0.0.2
This is much shorter; should be easy to allow both.
(That's because osmo_sccp_simple_client() accepts a PC argument that is set as
ss7->cfg.primary_pc. I wonder whether we use a routing indicator of PC in a
hardcoded way then? Future plans?)
prot M3UA
local-port 1234
remote-port 5678
For prot M3UA, the ports should be M3UA_PORT by default, if the port commands
are omitted.
msc
cs7-inst-a 1
cs7-inst-iucs 1
local-addr msc_local
[...]
msc
cs7-inst-a 1
cs7-inst-iucs 2
local-addr msc_local
Let's allow two separate local SCCP addresses as well. Actually, I think we can
drop the local-addr completely:
It doesn't make sense to have the same ss7 instance wih two distinct local
addresses; at least in the current code state, we can handle only one local PC
per ss7 instance.
And actually you already define a local PC in 'sccp' above with 'pc
msc_local'.
All that we need for osmo_sccp_user_bind() is an sccp instance pointer (taken
from the osmo_ss7_instance) and an SSN (hardcoded).
So this is sufficient:
msc
cs7-inst-a 1
cs7-inst-iucs 1
or
msc
cs7-inst-a 1
cs7-inst-iucs 2
One more thing: each ss7_instance will only find those address book entries
defined in its own address book list, right? For example this won't work?
cs7 instance 1
sccp-address address_on_instance_1
point-code 0.0.2
routing-indicator PC
cs7 instance 2
sccp
pc address_on_instance_1
That could be a reason to keep the address book separate from osmo_ss7_instance
structs, as one global list usable everywhere, and also to place the address
book vty commands on its own VTY scope.
Can we make 'pc' rather 'local-pc'?
If I explore the case of passing the PC directly and using a global SCCP
address book, the VTY becomes simpler. We don't actually need an cs7-instance
scope anymore, since all we do in it would be defining an SCCP instance:
! global address book would look something like this
sccp-address msc_local
point-code 0.0.2
sccp-address another_one
point-code 0.0.3
! The number '1' passed as the ss7 instance id. VTY shall disallow passing the
! same id another time.
sccp-inst 1
name OsmoMSC
local-pc msc_local ! or maybe just 'local-pc 0.0.2'
prot M3UA
local-ip 1.1.1.4
! local-port 1230
remote-ip 2.2.2.4
! remote-port 5670
msc
iface-a sccp-inst 1
iface-iucs sccp-inst 1
OR even not needing any address book entries:
sccp-inst 1
name OsmoMSC-A
local-pc 0.0.2
prot M3UA
local-ip 1.1.1.4
remote-ip 2.2.2.4
sccp-inst 2
name OsmoMSC-IuCS
local-pc 0.23.0
prot M3UA
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
iface-a sccp-inst 1
iface-iucs sccp-inst 2
I like this better because it hides the unneeded duality of ss7-instance and
sccp-instance from the config file, and it keeps the address book feature
separate and optional. Does this make sense to you?
~N
7 Jul
7 Jul
1:12 a.m.
New subject: sscp-context initalization via VTY
Hi Philipp and Neels,
On Thu, Jul 06, 2017 at 11:31:26AM +0200, Philipp Maier wrote:
sounds fine.
No, this looks wrong. Why are we inventing new VTY configuration for
anything below the SCCP protocol layer? This is all already present in
libosmo-sigtran?
The application *only* cares about using the SCCP User SAP. It does not
care about what happens below that SAP, and who and how it is
configured. What signalling links exist, and which protocol (M3UA) they
use, etc. is all out of scope/concern here. This is done by the existing
'cs7 as' and 'cs7 asp' and friends. The only difference between STP and
ASP side configuration in all of the related data structures is a single
flag. So whether you configure an AS/ASP on the STP, or you do that on
the ASP side (e.g. OsmoMSC) is not different.
I'm not entirely happy about the amount of discussion this entire topic
is drawing up, for several weeks. IMHO it should in fact be very
straight forward and simple:
* osmo_ss7 code handles M3UA + related config/vty (99.9% exists for months)
* osmo_sccp code handles SCCP address book
* application simply uses adresses from SCCP address book. By the
addresses being each part of a ss7 instance, it is well-defined via
which SCCP-instance communication to the respective peer should
happen, and that SCCP instance is bound to the respective SS7
instacne.
Please let me know which particular part I am missing here?
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
(any reason to
not discuss this on openbsc@?)
I put it on CC.
Still missing in this proposal: how do you tell
e.g. the MSC's A and IuCS
code
to use a given SCCP instance, local SSN and
remote SCCP address?
I would add a VTY command where the user has to tell on which ss7 instance
the A or IuCS interface should bind. When the IDs for both match up, we know
that we use the same SCCP instance, but I think we do not even have to check
that. Its implicit by the pointers. If the numbers are the same we will end
up with the same sccp instance pointer for both. A much simpler
soultion to the problem would be to pack the configuration
options into struct osmo_ss7_instance. Then when the config file parsing
is done, the user must call a function e.g. "osmo_sscp_init()" or so to
trigger the call to osmo_sccp_simple_client().
In struct osmo_ss7_instance we already have the .cfg sub struct. I think we
should add the items there instead of introducing something new. Also if we
do
so we would have to change it for the existing code too to have it
consistent.
Lets do some practical examples:
1) A and IuCS use the same sscp/ss7 instance
cs7 instance 1
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs_and_a
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
1:22 a.m.
New subject: sscp-context initalization via VTY
Hi Neels and Philipp,
On Thu, Jul 06, 2017 at 03:10:37PM +0200, Neels Hofmeyr wrote:
Will we ever use osmo_ss7_instance for anything else
than SCCP?
no current plans, but completely likely for e.g. ISUP.
(That's because osmo_sccp_simple_client() accepts
a PC argument that is set as
ss7->cfg.primary_pc. I wonder whether we use a routing indicator of PC in a
hardcoded way then? Future plans?)
Can you please all get detached from what simple_client() currently
does? It is nothing less than a crude hack that I introduced so we
(and particularly Philipp) can make quick progress on the higher layers
without having to wait for the then-non-existant ss7 vty code in
libosmo-sccp and the related full configuration, using OsmoSTP, etc.
So whatever that API hack does or doesn't do is not really relevant in
the bigger picture.
So this is sufficient:
msc
cs7-inst-a 1
cs7-inst-iucs 1
The MSC should point to the address book (by name) and the address book
contains the point code and/or global title, etc. (i.e. the local sccp
address) that it should use, together with the ss7 instance number.
anything else is determined by configuration of the lower layer in
osmo_ss7 vty.
One more thing: each ss7_instance will only find those
address book entries
defined in its own address book list, right?
yes.
If I explore the case of passing the PC directly and
using a global SCCP
address book, the VTY becomes simpler. We don't actually need an cs7-instance
scope anymore, since all we do in it would be defining an SCCP instance:
Configuration of the SCCP instance and anything below it are not the
concern of the MSC. Please do not mix the layers.
As analogy: You also don't configure the MAC address and the IP
address, netmask, IP routes, etc. in the system when you crate a TCP socket.
The Ethernet and IP layer configuration (e.g.
MTP/M3UA/ASP/links/linksets/routes/...) is independent of the
application layer, where when you bind a socket, you simply specify one
of many local IP addresses + the respective port number.
The fact that various layers are running within one process, or the fact
that they share one config file / vty doesn't mean those parts are not
separate and have a *very* thin line of interaction: The SCCP-User-SAP
only.
Regards,
Harald
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
4:04 a.m.
New subject: sscp-context initalization via VTY
On Fri, Jul 07, 2017 at 12:12:04AM +0100, Harald Welte wrote:
I'm not entirely happy about the amount of
discussion this entire topic
is drawing up, for several weeks. IMHO it should in fact be very
straight forward and simple:
"All" that we need is a blueprint of what the OsmoMSC's VTY configuration
should look like, the rest would fall into place. It would be quite helpful if
you could provide us with that so that we can see it in a straight forward way.
Can you re-arrange this (or any other suggestion) to match your expectations:
sccp-inst 1
name OsmoMSC-A
local-pc 0.0.2
prot M3UA
local-ip 1.1.1.4
remote-ip 2.2.2.4
sccp-inst 2
name OsmoMSC-IuCS
local-pc 0.23.0
prot M3UA
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
iface-a sccp-inst 1
iface-iucs sccp-inst 2
The bounds are...
I cannot use two distinct local SCCP addresses with one osmo_ss7_instance;
current code dictates a single local PC. If I configure A and IuCS on the same
SS7 instance but use distinct addresses, it will silently not work.
There can be only one SCCP client tied to a given osmo_ss7_instance, the
osmo_ss7_instance->sccp pointer is a 1:1 relation. (Shouldn't it be the other
way, the sccp instance having a pointer to an ss7?)
Address names are scoped per osmo_ss7_instance, so I can easily have the same
name in two separate ss7 instances. Hence the application needs to be aware of
which instance it should take the address from. Why not one global name scope?
It is also conceivable that I want to use the same SCCP address in two distinct
SS7+SCCP instances, e.g. using the same PC in distinct STP spheres.
The application dictates an SSN, which is technically part of the SCCP address,
but nevertheless should not be VTY configurable. Basically all that we want to
configure of the local SCCP address *is* a local PC.
Each single SCCP client will connect to one OsmoSTP remote. We need to bind to
a local IP address and contact a remote one. It makes sense to write that VTY
once and re-use in every application.
We can run both A and IuCS on the same SCCP instance using an identical local
PC and connecting to the same STP;
Or we can have each on its own SCCP instance with distinct PCs and STPs.
This should be cast into a plain VTY structure that is helpful in avoiding
mistakes.
~N
10 Jul
10 Jul
12:20 p.m.
New subject: sscp-context initalization via VTY
On Fri, Jul 07, 2017 at 12:12:04AM +0100, Harald Welte wrote:
No, this looks wrong. Why are we inventing new VTY
configuration for
anything below the SCCP protocol layer? This is all already present in
libosmo-sigtran?
Argh, missed this one. I now see that there are VTY commands for local and
remote IPs, we'll take looks.
~N
2499
days inactive
2503
days old
5 comments
3 participants
participants (3)
-
Harald Welte -
Neels Hofmeyr -
Philipp Maier