Subject: [Sigtran] Clarification on TID

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 18 Oct 2005 14:58:08 -0400

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.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Oct 2005 17:33:21 -0600

Lincoln,

I don't think it is any easier either.  Also, the mask is not a mask:
it is both a mask and a match and therefore it defines a range of
values that have 1's in precisely the same positions as the the value
being examined.  For example, a "mask" of "1010" defines the range
"1X1X" or 1010, 1011, 1110, 1111.  The problem with this is that it is
impossible to define ranges that do not overlap.  Try it.

I was waiting for someone to discover this.  Obviously noone uses this
approach to TID and DRN labels.  You came close.

I think that what was intended was something more like:

       |                          label match                          |
   
(like programming an old C1EAX switch ;)

The TID or DRN is masked with a logical AND with the mask and then matched
against the match value.

Then four non-overlapping ranges could be defined like:

  "1100/0000"
  "1100/0100"
  "1100/1000"
  "1100/1100"

Unfortunately this limits ranges to fractions of the power of 2.  The old
method placed no restictions on ranges.

So, I agree, the IG methods need to be scrapped.

--brian

Haresign Lincoln wrote:                                                            (Tue, 18 Oct 2005 14:58:08)

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

---

From: Warren Anthony Briggs <[email-masked]>
Date: Wed, 19 Oct 2005 09:43:09 -0400

Hi Brian,

I posted questions to the group relating to the problems associated with 
the IG descriptiuon of TID loadshare procedures many moons ago. 
Unfortunately I did not recieve a response at that time. The same 
questions were raised again during the recent  plug test. I believe 
Lode  Coene has  clarified descriptions of TID loadshare procedures.  I 
would not want to see TID loadshare scrapped altogether. I think it 
could provide an efficient mechanism for the loadsharing TCAP dialogues 
"in progress".

regards,
Warren Briggs