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