RE: SUA implementor's guide

Barry,

This all looks fine with me.

Regards,
Lincoln 

-----Original Message-----
From: Barry Nagelberg [mailto:[email protected]] 
Sent: Wednesday, October 11, 2006 9:34 AM
To: [email protected]
Subject: RE: [Sigtran] SUA implementor's guide

Lincoln,

Seamus Gilchrist and I asked some questions, and made some suggested
solutions regarding TID and DRM labels back in Feb-Apr of 2004, but they
weren't limited only to the ASP_ACK msg. I am equally puzzled as to why
the questions were put in the IG. I agree that the solutions should have
been inserted instead of the questions.

After some email exchanges on the mailing list, I made the following
proposal for the IG on Apr 27, 2004:

<snip>
Here is some updated suggested text for the SUA IG, regarding the usage
of TID labels.

I suggest that we have some mailing list discussion, or poll, or
something on this issue, even prior to publication of the SUA IG. In
spite of the fact that SUA v16 is very unclear on the use of these
labels, we're apparently moving towards the RFC stage, and companies are
moving ahead on SUA implementation. If we're not careful, we run the
risk of ending up with incompatible implementations.

In section 4.7.2.1 (Association Setup, ASP going active):

<snip>
In the ASPAC message, the ASP optionally includes a TID and/or DRN Label
Parameter for each AS. If more than one ASP in a given AS includes a TID
and/or DRN Label Parameter, then these ASPs must specify a unique label
at a fixed position in the TID or DRN parameter. The same ASPAC message
is sent to each SG used for interworking with the SS7 network.

If an ASP does not include a TID and/or DRN Label Parameter in the ASPAC
message, then the SG MAY send a TCAP message with any TID or DRN to this
ASP.
<snip>

In section 4.7.3.1 (Routing and message distribution at the SG - TCAP
traffic):

<snip>
   a. The SG examines the bits between the 'Start' bit and the 'End' bit
   of the received TCAP transaction ID (TID). The 'Start' and 'End' bits
   are defined in the 'TID Label' parameter that was sent in the ASPAC
   message for this AS.

   b. If these bits exactly match the 'Label' field of the 'TID Label'
   parameter that was sent in the ASPAC message, then the message is
sent
   to the ASP that registered for this label via the ASPAC msg.

   c. If these bits do not match the label field of any ASP in this AS,
   then the SG may discard the message.
<snip>

Barry Nagelberg

-----Original Message-----
From: Haresign Lincoln [mailto:[email protected]]
Sent: Wednesday, October 11, 2006 9:02 AM
To: [email protected]
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email protected]
Subject: RE: [Sigtran] SUA implementor's guide


Brian,

With regards to Barry's comments.  If I'm reading this correctly, Barry
seemed to be concerned that the ASP would send a TID range in the
ASP_ACK message and, if the SG did not support this optional parameter,
then there would be no way of handling this.  (Barry/Brian, please
correct me if I have not interpretted your concern correctly).

I would suggest that in this case, the SG should send an error with
"Unsupported Traffic Handling Mode".  This error is sent in response to
an ASP Active message with a Traffic Mode Type that is not supported.
We can update the SUA text to indicate this.  If this is acceptable,
then I will propose some text.  If this is unacceptable, then we can
create a new error code and I will propose some text.  In any case, I
don't see this as a big problem that can't be solved.

With regards to the "SUA-09:..." thread, I don't see the problem.  You
seem to be saying that the ASP has no control over what TID is assigned.
If that is the case, then I agree that this won't work.  But if the ASP
does have control (and I don't see why it wouldn't), then the ASP can
send TIDs that match the range that it has specified.  It should send
the same TID value in the ASP_ACTIVE message to all SGPs in the SG that
it is connecting to.

Regards,
Lincoln



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Tuesday, October 10, 2006 2:17 PM
To: Haresign Lincoln
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email protected]
Subject: Re: [Sigtran] SUA implementor's guide

Lincoln,

These questions come directly from Barry Nagleberg's note of Feb 18,
2004: "SUA v16: TID and DRM labels".  In fact, see that thread for more
information in the issues.  And for the general agreement that the
mechanism must be fixed or removed.

Also see the thread, "SUA-09: SCCP Connections and TCAP Transactions"
from Dec 2001/Jan 2002.

There has been repeated agreement in the WG that the mechanism must
either be fixed or removed.  Neither has ocurred.  It will likely be
2008 before a fix is made.  Or perhaps my prediction of 2006 from
Message-ID: <[email protected]> will be correct.

--brian

Haresign Lincoln wrote:                            (Tue, 10 Oct 2006
11:29:26)
> I'm curious about this section in the Implementor's Guide:
>
>
> 2.10.3.  Solution description
>
> .........
>
>    Improving the clarity of the use of the TID and DRM label
parameters:
>    Redundancy - The label values are fixed length (16 bits).  So why
do
>    we need both a "Start" and an "End" position for applying the mask?
>    One or the other would seem to be enough.
>
>    Simplicity - Why bother with a partial-sized mask at a specified
>    "start" bit.  Why not just specify a "full-sized" 32-bit (TID) or
23-
>    bit (DRM) mask?  Then we do not need a "start" and "end" position.
>
>    Contradictions - Section 4.7.2.1 states that "All the ASPs within
the
>    AS _must_ specify a unique label at a fixed position in the TID or
>    DRN parameter."  The "must" here contradicts that fact the the TID
>    and DRM parameters are listed as Optional in the ASPAC msg.  Thus
if
>    a label is present, then all ASP's belonging to that AS, must
>    specifiy a label in the ASPAC msg.
>
>
>
> Should the implementor's Guide being asking questions?  I thought this

> was an attempt to clarify, not to ask questions.  I would answer the 
> questions as follows:
>
>
> So why do we need both a "Start" and an "End" position for applying 
> the mask?
>
> You don't need to use all 16 bits.  So in that case, the start and end

> give some flexibility as to how you want to use the TID.
>
> Why bother with a partial-sized mask at a specified "start" bit.  Why 
> not just specify a "full-sized" 32-bit (TID) or 23-bit (DRM) mask?
>
> Again...flexibility.
>
>
> With regards to the contradictions, I imagine this could be clarified 
> with something like "If the ASPs are using the TID parameter, then....
>
> Regards,
> Lincoln
>
>
>
> -----Original Message-----
> From: Ong, Lyndon [mailto:[email protected]]
> Sent: Saturday, October 07, 2006 5:22 PM
> To: [email protected]; Cullen Jennings
> Cc: Barry Nagelberg; [email protected]
> Subject: RE: [Sigtran] SUA implementor's guide
>
> Hi Folks,
>
> Now that the SUA Implementor's Guide has been reissued, I'd like to 
> see if people are ready to do a WG Last Call on it.  If so, we can 
> start this up next week.
>
> Cheers,
>
> L. Ong
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Tuesday, October 03, 2006 9:59 PM
> To: Cullen Jennings
> Cc: [email protected]; Barry Nagelberg; Ong, Lyndon
> Subject: Re: [Sigtran] SUA implementor's guide
>
> Cullen,
>
> Cullen Jennings wrote:                   (Tue, 03 Oct 2006 21:09:00)
> >
> > More importantly, I think some of
> > this stuff if sufficiently complicated that outside a somewhat small

> > group of folks, an implementor guide will really help this work be 
> > successful.
>
> Well, the implementor's guide is really a specification errata 
> document and not a guide to the uninitiated.  It assumes, as does the 
> specification, that the reader has a very solid understanding of the 
> thing being transported.
>
> --brian
>
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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


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