Re: message distribution at ASP

Dario,

Dario wrote:                                    (Wed, 30 May 2007 15:05:59)
> 
> Hi Brian,
> thanks a lot. what I had in mind is that for distribution, routing label of
> outgoing message should match the Routing Key,and then the message should ne
> sent to the remote M3UA peer where related AS is active
> (if LSH applies, implementation dependent function, usually based on SLS
> will distribute the message among active peers).
> hope I got it right.
> best regards, Dario
> 

Yes, matching against the SGP Routing Key with PC fields reversed is one
way to go about routing messages from the ASP.  For some
implementations, however, messages generated by the process associated
with the ASP on a handle (e.g. file descriptor) associated with the AS
inherently implies (by MTP-SAP) a routing key match of this form.  For
example, if at the ASP your AS2 is associated with a file descriptor
associated with trunk groups between X and Y, and the AS application
(ISUP) only sends messages associated with circuits in that trunks group
on that file descriptor, then there is no need to introduce an
extraneous and additional match against the RK.  We took some care in
the preparation of the M3UA approach to equally allow both of these
valid implementation approaches: one requiring a handle for each AS, the
other needing only one handle for all AS, and then matching reverse-RKs
within the M3UA layer at the ASP.  In the first case, consider it as
though the RC is bound to the handle.  In the second case, it is not.
Of course, both approaches have their advantages and disadvantages in
real implementations.  (Q.701 too discusses both approaces to the MTP
MTP/User interface.)

In allowing the designer this freedom, in some places the language
might appear vauge, or at least to skirt the matter of RK matching or
RC binding at the ASP.  It helps to bear in mind that the is a 1:1:1
replationship between AS:RC:RK.  That is, given the RC, the RK is known;
given the RK, the RC is known.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/