RE: SUA implementor's guide

Brian,

I certainly don't think we should strike it since it has a valid use for
some applications.  We are successfully using this mechanism for a
number of different applications and it works perfectly for it's
intended use.  It is part of an already agreed upon RFC.  

I believe that the TID/DLR is associated with an RC and not a point
code.

I think the TID/DLR mechanism should only be used for applications that
are working with DLRs or TIDs.  If that is not the type of application,
don't use it.

Regards,
Lincoln
 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 11, 2006 11:22 AM
To: Barry Nagelberg
Cc: [email protected]
Subject: Re: [Sigtran] SUA implementor's guide

Barry,

Yes that went some ways; however, it does not address the conflict
between Traffic Mode Type and DRN/TID label.  It seems that when DRN/TID
label is used, that the traffic mode for the AS is somehow overridden by
the label.  Now, while traffic modes are well defined as to how traffic
is distributed over the available ASPs, and what to do when an ASP
fails, the same is not true for DRN/TID labels.

To get this clear, one needs to modify ASP Up, ASP Down, ASP Active, ASP
Inactive, Notify and even Registration procedures.

Also, DLR and TID only uniquely identify a connection or transaction
within the scope of a point code.  Unlike M3UA, SUA supports relay and
can support multiple point code per AS.  Therefore, an address must be
associated with the labels.

Also, the current document is unclear as to how to handle messages with
no DLR and no TID.

The list goes on.

This is the reason that I wrote the draft:

 
ftp://ftp.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

If you look at the draft, you will see that these issues and more, as
well as a more general mechanism to handle CIC Ranges for M3UA, SLS
Ranges for M2UA, and address/DLR/TID labels for SUA with a general
purpose load selector are addressed.

Changes necessary to get the SUA label mechanism working in a proper
fashion requires changes to the RFC that are likely outside the scope of
the IG, which should really just be Errata.

It would probably be better to strike DRN/TID Labels from the RFC with
the IG and follow along with an extension draft such as the LOADSEL
draft to put a proper mechanism in place.

--brian

Barry Nagelberg wrote:                        (Wed, 11 Oct 2006
09:34:03)
> 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

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

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