GSUP: E-interface messages for inter-MSC HO

historical

Many thanks for your input!

I don't really have strong opinions about any of these design questions. When
extending the GSUP protocol I am mainly carrying out other people's ideas...

On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote:
> * Why should this message router/server be part of the HLR? IMO these
> are completely separate things. So I'd rather put this functionality
> into a separate program/process.

So far osmo-hlr is the GSUP server. We've already introduced the concept of
osmo-hlr as a router-thing concerning USSD services, towards external USSD
providers. Adding a router in-between would change the topology, sort of like
we added the osmo-stp for the A and Iu interfaces. osmo-hlr would then also be
a GSUP client to the router instance, and osmo-msc and osmo-sgsn would have to
add routing information to reach the HLR... That's (probably) backwards
incompatible, not sure if we want to open that box now.

> * What about adding a separate IPA protocol id for routing (proxying
> might came closer for the case given), that itself just carries other
> IPA messages of a different type along with source/destination_name and
> This could then be
> used with every IPA protocol and won't mess with the application layer.

Ok, that sounds like a sane idea. I wonder whether such a concept is already in
use somewhere on the IPA protocol?

A drawback I see is that we currently have numerous IPA implementations flying
around, IIRC in libosmocore, libosmo-netif, libosmo-sccp; and at least two in
python... extending the libosmocore one would probably be enough.

> possibly other IEs that just relate to proxying (and possibly the
> session stuff, unless that went to another layer)?
> 
> * What about security? Proxying will prevent conventional network
> monitoring tools and firewalls from working properly. Will it be
> possible to limit proxying to certain peers e.g. via configuration?

I don't fully get the proxying idea. What's the purpose, to bridge messages for
specific recipients through a NAT sort of thing?

> BTW, the source and destination name IEs correspond to the global titles
> in the SCCP layer of SS7. There also exist means to address a
> destination logically (e.g. send this to the HLR that is responsible for
> that IMSI, see the E.214 numbering plan).

This is the first time I'm thinking about more than one HLR in Osmocom. I'm
out of my depth here...

> > - The session_id/session_state: we still need to figure out how to avoid
> >   collisions in session_id numbers, as any peer may at any point re-use the
> >   same session_id. Vadim suggested using a TI flag that gets flipped between
> >   sender and receiver, but since there are more than two peers, I guess we
> >   should treat each session_id as subordinate to a Request's source_name. IOW,
> >   any peer owns the entire session_id number space itself for sending out
> >   Request message types, and a Response or Error message type echos this
> >   session_id back with the source_name then having become the destination_name;
> >   it is perfectly legal for two peers to use the same session_id and collisions
> >   are avoided by Request vs. Response/Error. Something like...
> 
> To me this really sounds like re-implementing (parts of) TCAP (ITU T
> Q.770-779) . TCAP use transaction ids, one for every end of the
> 'connection' (origin and destination) where each tuple (origin, OTID) or
> (dest, DTID) identifies the transaction (note that in certain cases a

Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning
to have just one ID sent back and forth, which the first Request specifies, and
then remains the same from both sides.

> peer can reply with a different origin, e.g. by replacing a E.214 by a
> E.164 GT). But TCAP is properly separated from the application layer
> stuff (MAP in that case).
> While I like the idea to extend GSUP/IPA, I'm wondering whether at some
> point in the future it was better to just use the standard protocols
> (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA
> possibly combined with some restrictions concerning segmentation etc)
> instead of partly reimplementing all of them.

IIUC the standard stack has quite a lot of duplicated information and is a lot
more complex than GSUP/IPA, and that is precisely the idea: implement a simpler
protocol with sufficient information to still allow translating into the more
complex standard stack, but saving us all the gory details that we would need
for the full stack.

I did not make this decision, which is probably also made on the grounds of
getting something done in a reasonable time frame (this is work for a sysmocom
customer).

Well, personally, I would enjoy myself more when staying with GSUP for now and
keeping things as simple as possible :)
(because I would rather concentrate on osmo-msc's handover code)

> At least I'd rather
> properly separate the session/proxying stuff from GSUP (still being a
> simplified MAP replacement).

The session_id IE was already added for USSD. Proxying doesn't seem to be a
goal at this point.

Routing messages between GSUP clients could be changed into routing messages
between IPA clients. That would match well in the sense that we already send
the MSC's name via IPA during the initial IPA ID exchange.

However, keeping routing within GSUP would make operations a bit simpler now,
since all our patches modify just one protocol layer, and we have only one GSUP
server implementation vs. the various IPA ones.

My first and final word on this is that I don't worry/care much about which way
we do these things, because I personally don't have a larger scheming plan for
IPA and GSUP, so I would like to hear other opinions.

Thanks again for your very interesting input!

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190115/906be5c0/attachment.bin>