Capwap Mailing List: Re: IESG Review Comment T24

[Margaret Wasserman (margaret]

I just spoke with Dan Romascanu on the phone (for a previously  
scheduled CAPWAP status call), and I realized that my message about  
this issue may have been unnecessarily terse...

It is my understanding that we will always know the length of the  
packet received at the CAPWAP layer, because it will be passed up to  
us from the lower layer.  Effectively, we will get a buffer and a  
data length from the lower layer.  I don't know of any system that  
wouldn't provide that information.

If we add a CAPWAP data length, we must always compare the CAPWAP  
data length to the buffer length we received.  This comparison could  
theoretically result in one of three answers:

(1) The CAPWAP data length indicates that the data ends at the end of  
the lower-layer buffer.  This is the expected case, and the only case  
supported by the -10 version of the spec.  In this case the CAPWAP  
data length adds no value.

(2) The CAPWAP data length indicates that the data ends before the  
end of the lower-layer buffer.  I don't believe that this should ever  
happen because the other side should have passed its the correct  
amount of CAPWAP data (and only that data) through DTLS and that's  
what we should have recieved.  I'm not sure whether we should accept  
the data in this case or return an error.

(3) The CAPWAP data length indicates that the data ends after the end  
of the lower-layer buffer.  In this case, we definitely have to  
return an error, because we don't want to read off of the end of the  
lower layer buffer.

So, having a CAPWAP data length adds processing (to do this  
comparison), and I don't see that it adds any value.  It also breaks  
compatibility with previous versions of CAPWAP (such as -10), so I  
don't personally think we should add it.

Margaret



On Jun 17, 2008, at 11:51 AM, Margaret Wasserman wrote:

> I'm personally not wild about changing the packet formats at this
> point, but there does appear to be a technical justification for this
> change...
>
> Are there actually systems on which you wouldn't know the packet size
> at this layer, though?  Or is this just a theoretical technical
> justification?
>
> Margaret
>
>
>
> On Jun 16, 2008, at 11:35 AM, Pat Calhoun (pacalhou) wrote:
>
> > All,
> >
> > Here is the IESG Review Comment:
> >
> >    T24 - Sections 4.6.27, 4.6.28 - should not these two messages
> > include
> > length of the
> >    Value fields?
> >
> > Originally, this was not included, because it could be inferred.
> > However, I can imagine a software architecture where the packet
> > size is
> > not known when the message elements are parsed. So I have added them:
> >
> > <text>
> > 4.6.27.  Image Data
> > [...]
> >
> >    0                   1                   2                   3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |   Data Type   |      Data Length      |        Data ....
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [...]
> >
> >    Data: Length of data field, with a maximum size of 1024.
> >
> >    Data:   The Image Data field contains up to 1024 characters.  If
> > the
> >       block being sent is the last one, the Opcode is set to 2.
> > The AC
> >       MAY opt to abort the data transfer by setting the Opcode to 5.
> >       When the Opcode is 5, the Value field has a zero length.
> >
> > 4.6.28.  Image Identifier
> > [...]
> >    0                   1                   2                   3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                       Vendor Identifier                       |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |         Value Length          |           Data...
> >
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > [...]
> >
> >    Data: Length of data field, with a maximum size of 65535.
> >
> >    Data:   A variable length UTF-8 encoded string containing the
> > firmware
> >       identifier to be run on the WTP.
> > </text>
> >
> > PatC
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap