RE: Clarification on TID

I'll ship out the new SUA IG tomorrow to the ietf draft editor 
In it, you'll find the following:
- Typos.
- Paragraph 2.17 Filler/padding in Global title parameter: new
- Paragraph 2.18 Inclusion of routing context in the Routing key
parameter: new
- Paragraph 2.8 TID label parameter:Changed: Another attempt at
clarifying what a SG could be doing with TID label.
- Paragraph 2.9 DRM label parameter:Changed: Another attempt at
clarifying what a SG could be doing with DRM label.
- Paragraph 2.10 Usage of TID and DRM label parameter:Changed:
Another attempt at clarifying what a SG could be doing with TID and
DRM labels.

Concerning the last 2 chnages, I've gone back to the original
description of the TID and DRN label and added some text that would made
it easier to interpret the parameter at the SG. Let me know what you
think about it...

About the SCON issue: The main change seems to be that including the PC
should no longer be mandatory. It seems that there was no consensus on
the list yet. So I did not include it in the IG. As some folks will
write a ID of their own on this issue, I'll wait and see what the result
is...

Yours sincerely,
Lode Coene

Siemens COM
atealaan 34          2200 Herentals, Belgium
E-mail: [email protected]
Tel: +32-14-252081
Fax: +32-14-253212

 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Haresign Lincoln
> Sent: dinsdag 18 oktober 2005 20:58
> To: [email protected]
> Subject: [Sigtran] Clarification on TID
> 
> 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
>