GSUP: E-interface messages for inter-MSC HO

[Jacob]

Hi Neels,

> Anyone else is also more than welcome to take a look and remark on anything
> that might seem a bad idea, etc.
I had a brief look on your draft and have some remarks and thoughts
about it (see below).
> This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC
> handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to
> freely share the trace, let me know if you need details.
>
> The most interesting bits in the draft are
>
> - the new message types

I briefly checked the operations in 29.002 (mainly whether they provide
a result or not) and they seem to match your message types.

> - the newly added IEs (see "Of which are newly added...")
>
[...]

>
> Also interesting to figure out: Implement the IPA routing for which I added the
> source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr
> forward messages to each other via GSUP.
>
> - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and
>   to extend the gsup_server so that we can use the source_name/destination_name
>   IEs to forward GSUP messages between the two clients. (I added these because
>   I'm fairly certain there is no existing in-band IPA protocol bits that would
>   allow such routing; but I only briefly skimmed it, wouldn't hurt if you could
>   verify that again.) The aim is to have plain gsup_client API to allow me to
>   "just send messages back and fort".

The following questions come to my mind while reading this:

* 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.

* 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
possibly other IEs that just relate to proxying (and possibly the
session stuff, unless that went to another layer)? This could then be
used with every IPA protocol and won't mess with the application 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?

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).

>
> - 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
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. At least I'd rather
properly separate the session/proxying stuff from GSUP (still being a
simplified MAP replacement).

Jacob