RE: SUA implementor's guide

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.

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.

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.

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.

Regards,
Lincoln Haresign

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 11, 2006 12:30 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
Subject: Re: [Sigtran] SUA implementor's guide

Haresign,

Haresign Lincoln wrote:                                           (Wed,
11 Oct 2006 11:31:30)
> Brian,
> 
> I certainly don't think we should strike it since it has a valid use 
> for some applications.  We are successfully using this mechanism for a

> number of different applications and it works perfectly for it's 
> intended use.

It cannot be used in a interoperable way as the specification is too
unclear about too many things.  You certainly can't be using it for DRN,
for which it is most broken.

Previous discussion on this list tend to make be believe that you are
only using TID Label for a highly restricted class of transactions and
even then in a non-interoperable way.

> It is part of an already agreed upon RFC.  

Check the archive, we didn't agree on it and wanted to change the
document before it became an RFC but were unable to.  That the TID/DRN
label mechanism was broken was the first documented item in the IG and
it even appeared there before a formal RFC number was assigned to SUA.

You should have known from the start that TID/DRN Label was broken and
thought twice before implementing it so.

> 
> I believe that the TID/DLR is associated with an RC and not a point 
> code.

In SS7, both are assigned locally by a signalling point.  The assignment
for one signalling point might be the same as another.  So, for example,
a Terminating Transaction ID identifies a transaction at the destination
point code.  A Destination Local Reference identifies a connection at
the destination point code.

As an RC can cover multiple point code, your statement is incorrect.

> 
> I think the TID/DLR mechanism should only be used for applications 
> that are working with DLRs or TIDs.  If that is not the type of 
> application, don't use it.

What is your point here?  I did not suggest that an application not
using TID/DLR Label should somehow use it.

Oh, and BTW, it has to be changed to DLR label and not DRN label.  DRN
is arbitrarily assigned by the SG (an assignment of which the other SG
in an associated STP pair cannot have knowledge of).

--brian


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