RE: 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/