Re: Clarification on TID

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

Brian F. G. Bidulock wrote:

>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
>>    
>>
>
>  
>