Re: Clarification on TID

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:

        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 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)
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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