Re: Question related with DAUD Message
"Ankit Kumar Sharma" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Brian, On 2/1/07, Brian F. G. Bidulock <[email protected]> wrote: > > Ankit, > > Ankit Kumar Sharma > wrote: (Thu, 01 > Feb 2007 09:43:08) > > > > On 1/31/07, Barry Nagelberg <[1][email protected]> wrote: > > > > Oscar, > > There is nothing in the RFC which states that "there is no limit to > > the number of point codes in the DAUD (or DUNA or > > DAVA)". > > > > Max limit could be calculated from the max value of > 'length' > > parameter > > > > This is an interoperability bug in the RFC, because obviously there > > must be some limit - an SGP could run out of > > resources if the ASP sends it a DAUD msg with a billion point > > codes. A limit of 1024 sounds reasonable to me. > > > > Not billion...we could send maximum 16382 point codes in a DAUD > > > > The main point facing us now is that the size of the limit is an > > implementation decision for each vendor. I suggest that > > the RFC be updated to state explicity what the limit is - otherwise > > this will continue to cause interoperability > > problems. > > > > I agree with you... > > > > And so, to conform nicely to your limit, the ASP sends 1 billion DAUDs > with > 1 point code in each... (Perhaps each with an all-ones mask.) How can > your limit help this poorly designed SG? Blacklist the vendor who fails in above scenario....;-)...but here, if I am not wrong, we are discussing about resource exhaution of SG when it has recieved a big DAUD message with thousands of Point codes in it. Most of the vendors limit the maxmimum buffer length in which they receive lower layer indication. On the basis of buffer length they advertise in their release that we support only xxx point codes in a DAUD. Although a well designed SG should be able to handle this situation but still I think, there should be some 'sensible' upper limit on the number of point codes in such messages. An SG design that cannot handle an ASP with the "Babbling Idiot" syndrome > will always be vulnerable in such situations. A more robust design would > not allow an ASP to usurp resources critical to other tasks. > > --brian > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ cheers, Ankit _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran