| Newsgroups |
gmane.ietf.sigtran |
| Message-ID |
<[email protected]> |
Fine with me as well.
John
>-----Original Message-----
>From: ext Haresign Lincoln [mailto:[email protected]]
>Sent: 11 October, 2006 20:08
>To: Coene, Lode; Barry Nagelberg; [email protected]
>Subject: RE: [Sigtran] SUA implementor's guide
>
>Works for me.
>
>Regards,
>Lincoln
>
>-----Original Message-----
>From: Coene, Lode [mailto:[email protected]]
>Sent: Wednesday, October 11, 2006 11:34 AM
>To: Barry Nagelberg; [email protected]; Haresign Lincoln
>Subject: RE: [Sigtran] SUA implementor's guide
>
>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 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
>
>
>-----Original Message-----
>From: Barry Nagelberg [mailto:[email protected]]
>Sent: woensdag 11 oktober 2006 15:34
>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
>
>_______________________________________________
>Sigtran mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/sigtran
>