Re: SUA implementor's guide

Haresign,

Haresign Lincoln wrote:                                           (Wed, 11 Oct 2006 14:18:52)
> Bidulock,
> 
> With regards to TID, I think we are only talking the locally assigned
> TID for continuation of a dialog.  For example, when a BEGIN arrives at
> the SG, there is yet no locally assigned TID, so the message can be sent
> to any ASP in the AS (if loadsharing is being used).  When a CONTINUE,
> END, or ABORT arrives, it has a locally assigned TID as part of the
> complete Transaction ID and the message can be routed to the correct ASP
> that is handling the dialog.  In this way, we can receive two BEGINs
> with the exact same "originating TID from two different point codes".
> The originating TID is irrelevant.  The Destination TID (as is the DRN)
> is used determine which application (which ASP) to route to.

And for linked transactions?

> I would assume the same logic would be applied for the reference number
> when working with Class 2 messages.  The SG would want to examine the
> locally assigned reference number, not the number assigned by a remote
> switch.

DRNs are assigned by the SG not the ASP.

> We are not currently using the DRN Label.  We are successfully using the
> TID label and don't find it broken at all for the applications in which
> we are both initiating BEGINS/QUERYs and responding to them.  You keep
> saying that things are broken or won't work.  I'm not sure why.  I
> examined the references you gave in an earlier email and responded to
> them.  If you have some specific points that you'd like to bring
> forward, I believe that they can be resolved and/or clarified through
> the IG.  If not, then the consensus seems to move forward with what we
> have as it seems to work for everyone else.

Lets start with one.  Transaction ID in ITU is a Universal Integer.
This is a number of arbitrary length.  It has no maximum.  Unlike ANSI,
it is not a number that has bits from 0 to 31.

Which bits is the SG to match and mask?

> And I'm not really sure what your last paragraph is referring to.  The
> locally assigned reference number in a class 2 connection is like the
> locally assigned transaction ID.  When the ASP sends the ASP_ACTIVE
> message, it tells the SG what value (range) of TIDs/Reference Numbers
> should be routed to that ASP.  If the ASP is connecting to multiple SGs,
> it should provide the same parameter value.

When a connection is made through one SG, the other SG in an STP pair
has no knowledge of the DRN assigned by the ASP.

The DRN is a 32-bit field.  DLR is a 24-bit field.  The ASP is not
restricted in its assignment of DRNs and can assign any 32-bit value.
The SG must make a 24-bit value out of this.  How the SG does this is
not specified.  One SG can do it differently than another.

When an SG in a mated STP pair receives a DLR for a connection that
it is not privy to (it was made through the opposite SG), it has no
mapping of DLR to DRN and therefore has no mechanism to determine to
which ASP it should be passed.

I can go on.  Perhaps you can solve those two to being with.

--brian

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