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
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?
- 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
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
Hi Philipp and Neels,
On Thu, Jul 06, 2017 at 11:31:26AM +0200, Philipp Maier wrote:
(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.
sounds fine.
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:
- 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
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?
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
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
-
Harald Welte -
Neels Hofmeyr -
Philipp Maier