Re: 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/