Clarification on TID

"Haresign Lincoln" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <849535E338E99741B7F7413F73253EDB025E1112@us-nj-mail1.comverse.com>
To whom it may concern:

I'd like some clarification on the use of TID.  I've included the text
from the SUA IG-01 at the bottom for reference.

I'm assuming that the purpose of this field is to allow various ASPs
within an AS to specify a SET of (destination or "responding")
transaction Ids that the SG will use to route the messages to the
appropriate ASP for continuing an ongoing dialog.

In the new text, it is specifying a bit mask.  In the original RFC,
section 4.7.2.1, it specified that the SG need to verify there were no
conflicts in the TID against previously sent TID values from other ASPs
in the same RC.  If we are adapting the new text, I would assume that
this section needs to be updated also.  

Actually, I think the old method was a better method, but just need to
be clarified.  With the old method, it is very easy for the SG to
determine if there are any conflicts on the TID ranges.  And I'm
assuming that this Value is being configured on the ASP.  It is very
easy to configure this value as it is simply a number.  For example, one
could use the ASPID.  If it is just a matter of clarifying the old
method (I believe it needs some clarification), I'd be happy to propose
some text.

With the new method of a bit mask, whenever the SG receives an ASP
ACTIVE with the TID, it must logically AND the mask against all existing
masks to make sure there is no conflict.  While this isn't necessarily
any more work as doing a table lookup on a number, it is my opinion that
it is not as easy to configure the values on the ASP.  

Why is the change in methodology being proposed anyway?

Regards,
Lincoln







2.8.2  Text changes to the document

   ---------
   Old text: (Section 3.10.16)
   ---------
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0110         |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     start     |      end      |         label value           |
      +---------------+---------------+-------------------------------+

      The Start parameter is the start position of label, between 0
(LSB)
      and 31 (MSB).

      The End parameter is the end position of label, between 0 (LSB)
and
      31 (MSB).

      Label value is a 16-bit integer, which is unique across an AS.



   ---------
   New text: (Section 3.10.16)
   ---------
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0110         |            Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          label mask                           |
      +---------------------------------------------------------------+

      Label mask value is a 32-bit integer. The mask is logically
      ANDed onto the received TCAP transaction ID. And if the result
      of the AND operation exactly matches the "Label mask" field,
      then the message is sent to the ASP that registered for this
      label via the ASPAC msg.
      An ASP that registers a label will be sent only those TID-bearing
      messages that match its label.
      An ASP that does not register a label may be sent any TID-bearing
      message.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.