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

["Brian F. G. Bidulock" <[e-mail]>]

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
> > 
> > -- 
> > Brian F. G. Bidulock
> > [e-mail]
> > http://www.openss7.org/
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 

-- 
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/

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