The IP over ATM Mailing List Archive by date

[Craig Partridge <craig@aland.bbn.com>]

Hi Carl:
    
    Useful note, thanks!  By the way, everyone should understand that Mark
asked me to take a shot at characterizing the fixed-length vs. variable
length approach.  I currently have an implementation that does variable length
and if we stick to that, it is not a problem for me -- though I think it is
a coding style that encourages bugs.

    Generally, with traditional ARP the ar$op field lets you know which
    fields are valid. It would be nice of we could maintain some consistency in
    this regard without introducing any ambiguity.

Good point.

    In the native E.164 case, the Called or Calling Party Number IE 
    (as has been pointed out to me by Bryan Gleeson on several occassions) truly
    supports a variable length format (which could incidently include an odd number
    of address octets). This is certainly one case where a variable length 
    (In)ATMARP packet format would seem to be beneficial. A scheme could be devised
    to compensate for this case in a fixed-length format, however, this could 
    become awkward. 

Actually, it is very trivial.  Addresses always start with the first byte of
the ATM address field, regardless of length.  No problems here.
     
    I believe it is possible, however, to achieve most (but certainly not all) of 
    the benefit of the fixed-length packet format while still retaining the 
    flexibilty offerred by the variable length scheme in accomodating the cases
    discussed above.

As I read your proposal, it is: fields may be present or not, but if present
are fixed size.  Is this right?  (BTW: I don't think allocating packet buffers
is the typical problem -- most buffering systems allocate in fairly big chunks
so there's gonna be space in the request buffer for the reply).

Generally, my view is that the real question is: do we want to do offset
arithmetic (i.e., compute where to find addresses) or not?  Once you buy into
computing offsets, you buy into a larger class of problems -- more range
checking and length checking and more chances for bizzare corrupted packets.
But if we need to do it, then let's do it.  I think all Mark was asking for
was that we make sure we aren't adding complexity unnecessarily.

Craig