RE: [Sigtran] SUA v16: TID and DRM labels

["Barry Nagelberg" <[e-mail]>]

We don't think that it would be wise to remove the label mechanism - it
should be fixed and better documented. There is definitely a need for some
sort of Transaction Id routing mechanism. The existing label mechanism is a
good start - it just needs to be improved upon.

Barry Nagelberg

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[e-mail]]
> Sent: Thursday, February 19, 2004 1:06 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Sigtran] SUA v16: TID and DRM labels
>
>
> Barry,
>
> If you look back to the thread "SUA-09: SCCP Connections and TCAP
> Transactions" from Dec 2001/Jan 2002, you will find that at that
> "late date" it was too late to remove or fix the labels.  In that
> thread there was a proposal for a working solution.  The draft was
> advanced to IESG LC Feb 2002.  Now, two years later, it is neither
> fixed nor removed, and it is still a late date.  At this rate, expect
> corrections some time in 2006, if, of course, it is not still too
> late by then ;)
>
> I am concerned, however, that the approach is not clearly marked as
> optional.  Which it should be and was always intended to be.  That
> change can certainly be made before SUA goes out the door (unless
> the authors have been stripped ala M3UA).
>
> --brian
>
> John Loughney wrote:
>                     (Thu, 19 Feb 2004 06:15:23)
> > It would probably require an implementor's guide or -bis document to
> > make changes at this late date.
> >
> > John
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of
> > > ext Brian F. G. Bidulock
> > > Sent: 19 February, 2004 01:57
> > > To: Barry Nagelberg
> > > Cc: SIGTRAN Mailing List; Seamus Gilchrist
> > > Subject: Re: [Sigtran] SUA v16: TID and DRM labels
> > >
> > >
> > >
> > > Barry,
> > >
> > > I think the decision at last call was that it would neither
> > > be fixed nor
> > > removed.  Perhaps John an Lyndon could shed some light on the
> > > possibility
> > > of doing either at this late date.
> > >
> > > --brian
> > >
> > > Barry Nagelberg wrote:
> > >                        (Wed, 18 Feb 2004 17:21:43)
> > > > Brian,
> > > >
> > > > Thanks for the clarifications. Regarding your comments:
> > > >
> > > > 1. Suggested text - We already provided it. Please see #1 below.
> > > >
> > > > 2. Length of mask - Section 3.10.16 states that the length
> > > of the mask is 16
> > > > bits. No where else in the draft is it mentioned that not
> > > all of the bits
> > > > are significant. If you are contending that not all of the bits are
> > > > significant, then this is another aspect that must be clarified.
> > > >
> > > > 3. I agree with you that the label mechanism, as currently
> > > specified, is
> > > > broken. However it is NOT optional, because there is no
> > > mechanism specified
> > > > through which the SGP can indicate to the ASP that it
> > > doesn't support the
> > > > TID Label parameter in the ASPAC message (there is no "Unsupported
> > > > parameter" error code). Thus SUA itself is also broken. So the label
> > > > mechanism must either be fixed or removed.
> > > >
> > > > Barry Nagelberg
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > > > > Sent: Wednesday, February 18, 2004 4:17 PM
> > > > > To: Barry Nagelberg
> > > > > Cc: SIGTRAN Mailing List; Seamus Gilchrist
> > > > > Subject: Re: [Sigtran] SUA v16: TID and DRM labels
> > > > >
> > > > >
> > > > > Barry,
> > > > >
> > > > > Barry Nagelberg wrote:
> > > > >                    (Wed, 18 Feb 2004 15:26:12)
> > > > > > We have several suggestions for improving the clarity of the
> > > > > definition and
> > > > > > use of the TID and DRM label parameters:
> > > > > >
> > > > > > 1. Clarity - After some head-scratching and detective
> > > work, we think we
> > > > > > understand their purpose. We're assuming that:
> > > > > >
> > > > > > a. These labels are simply 16-bit masks that are logically
> > > > > ANDed onto the
> > > > > > received TCAP transaction ID, starting at the "Start" bit.
> > > > > >
> > > > > > b. If the result of the AND operation exactly matches
> > > the "Label" field,
> > > > > > then the message is sent to the ASP that registered for this
> > > > > label via the
> > > > > > ASPAC msg.
> > > > > >
> > > > > > c. An ASP that registers a label will be sent only
> > > those TID-bearing
> > > > > > messages that match its label.
> > > > > >
> > > > > > d. An ASP that does not register a label may be sent
> > > any TID-bearing
> > > > > > message.
> > > > > >
> > > > > > If these assumptions are correct, please state them
> > > explicitly in the
> > > > > > relevant sections of the draft(3.10.15, 3.10.16, 4.7.2.1 and
> > > > > 4.7.3.1). If
> > > > > > not, please clarify. It's not enough to say, as in 4.7.3.1,
> > > > > "the SG extracts
> > > > > > the label".
> > > > >
> > > > > That's my understanding.  Some clarity would be good.  Can you
> > > > > provide text?
> > > > >
> > > > > >
> > > > > >
> > > > > > 2. 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.
> > > > >
> > > > > The label does not have to be 16 (significant) bits.
> > > > >
> > > > > >
> > > > > > 3. 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?
> > > > >
> > > > > I don't know of any reason not to allow specification of a full
> > > > > 32-bit mask
> > > > > either.
> > > > >
> > > > > >
> > > > > > 4. 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. We're
> > > > > guessing that the
> > > > > > intention here is either:
> > > > > >
> > > > > > a. "If at least one of the ASPs within an AS specifies a label,
> > > > > then all the
> > > > > > ASPs within the AS must specify a unique label at a fixed
> > > > > position in the
> > > > > > TID or DRN parameter."
> > > > > >
> > > > > > or
> > > > > >
> > > > > > b. "All of the labels specified by the ASPs within an
> > > AS must start at a
> > > > > > fixed position in the TID or DRN parameter."
> > > > > >
> > > > > > or maybe
> > > > > >
> > > > > > (a) AND (b). Please clarify.
> > > > >
> > > > > I think we meant, "The ASPs within the AS specifying a label,
> > > > > must specify a
> > > > > unique label at a fixed position in the TID or DRN
> > > parameter."  The point
> > > > > being that no two labels (optionally specified) can overlap.
> > > > >
> > > > > That said, the label mechanism is still broken, as
> > > detailed in previous
> > > > > threads.  As it is an optional procedure, it might get fixed or
> > > > > fall out of
> > > > > use in the future.
> > > > >
> > > > > See draft-bidulock-sigtran-loadsel-02.pdf  I also have a session
> > > > > registration
> > > > > draft (never submitted) that provides a superior approach to the
> > > > > same problem.
> > > > > If someone is interested I will sumbit it.
> > > > >
> > > > > --brian
> > > > >
> > > > > >
> > > > > >
> > > > > > Barry Nagelberg


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