Subject: RE: [Sigtran] SUA implementor's guide

From: "Coene, Lode" <[email-masked]>
Date: Wed, 11 Oct 2006 17:34:03 +0200

The text Seamus and Barry proposed was included in the new text of
paragraph 4.7.2.1 and 4.7.3.1.

The questions should have been removed so I am going to remove them
now..
That is the paragraphs in the solution description about:
Redundancy
Simplicity
Contradictions  

That should take care of thennings 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-masked]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Oct 2006 10:37:46 -0600

Lode,

If you want to fix it once and for all, work the text with regard
to TID and DLR label from draft-bidulock-sigtran-loadsel-04.txt
into the IG.

--brian

Coene, Lode wrote:                    (Wed, 11 Oct 2006 17:34:03)
> That should take care of the issue I think...
> 
> And I realy hope I have never ever to hear about those DRM/TID label
> thingies ever again...(.. Must have positive thoughts...must have..)
> That has been the main problem point for all those years....
> 
> Yours sincerely,
> Lode 

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 11 Oct 2006 13:07:31 -0400

Works for me.

Regards,
Lincoln 

-----Original Message-----
From: Coene, Lode [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 11:34 AM
To: Barry Nagelberg; [email-masked]; Haresign Lincoln
Subject: RE: [Sigtran] SUA implementor's guide

Yours sincerely,
Lode 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]]
Sent: woensdag 11 oktober 2006 15:34
To: [email-masked]
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-masked]]
Sent: Wednesday, October 11, 2006 9:02 AM
To: [email-masked]
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
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-masked]]
Sent: Tuesday, October 10, 2006 2:17 PM
To: Haresign Lincoln
Cc: Ong, Lyndon; Cullen Jennings; Barry Nagelberg; [email-masked]
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-masked]> 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-masked]]
> Sent: Saturday, October 07, 2006 5:22 PM
> To: [email-masked]; Cullen Jennings
> Cc: Barry Nagelberg; [email-masked]
> 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-masked]]
> Sent: Tuesday, October 03, 2006 9:59 PM
> To: Cullen Jennings
> Cc: [email-masked]; Barry Nagelberg; Ong, Lyndon
> Subject: Re: [Sigtran] SUA implementor's guide
>
> Cullen,
>
> Cullen Jennings wrote:                   (Tue, 03 Oct 2006 21:09:00)
> >
> > this stuff if sufficiently complicated that outside a somewhat small

> 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-masked]
> http://www.openss7.org/
>

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

---

From: <[email-masked]>
Date: Wed, 11 Oct 2006 20:15:42 +0300

Fine with me as well.

John 

>From: ext Haresign Lincoln [mailto:[email-masked]] 
>Sent: 11 October, 2006 20:08
>To: Coene, Lode; Barry Nagelberg; [email-masked]
>The text Seamus and Barry proposed was included in the new 
>text of paragraph 4.7.2.1 and 4.7.3.1.
>
>The questions should have been removed so I am going to remove 
>them now..
>And I realy hope I have never ever to hear about those DRM/TID 
>label thingies ever again...(.. Must have positive 
>thoughts...must have..) That has been the main problem point 
>for all those years....
>
>Yours sincerely,
>Lode 
>
>
>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 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>
>
>   parameter that was sent in the ASPAC message, then the 
>message is sent
>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
>
>
>
>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.
>
>There has been repeated agreement in the WG that the mechanism 
>must either be fixed or removed.  Neither has ocurred.  It 
>will likely be