Capwap Mailing List: Re: vsp definition has no length

[sujay (sujayg]

Hi David,

Are you suggesting to remove the vsp element(as in section 4.4.32) ,
which could be carried 
in any control message(as in 4.3.1.1 ), and instead have a generic vsp
control message type ???

Please correct me.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085
&t=h&hl=en


This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it! 

-----Original Message-----
From: David T. Perkins [mailto:dperkins [at] dsperkins.com] 
Sent: Tuesday, June 20, 2006 5:04 AM
To: Scott G. Kelly
Cc: capwap
Subject: Re: [Capwap] vsp definition has no length


HI,

You left off the outside wrapper as is specified in CAPWAP-01.

Thus, you currently have, as defined in section 4.4,
"CAPWAP Protocol Message Elements", and section 4.4.32,
"Vendor Specific Payload" for vendor message elements:

   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 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type=43          |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Vendor Identifier                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Element ID           |   Value...    |                
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                
                                  ^-don't need length here Thus, you
don't need an additional "length".

In the CAPWAP packet formats that I sent out some time ago,
I proposed that there be no difference in format between 
"CAPWAP STD message elements" and "CAPWAP vendor specific message
elements". Both would have the following format:

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Message Element Type                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |  Value ....                    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-                   

Where the encoding of "message element type" is
   Message element type value = IANA Enterprise Number * 4096 +
                     enterprise specific message element type number
 
   (and for CAPWAP standard, zero is used for the value 
    IANA Enterprise number)

This results in 12 bits (0-4095) for element types, and 20 bits
(0-1048575) for Enterprise numbers. If you look at OUI assignments,
which have been around a lot longer than enterprise numbers, they have
approximately 52K allocated. Thus, 64k (16 bits), is probably not
enough, and 1M (20 bits) looks big enough.

Regards,
/david t. perkins

On Mon, 19 Jun 2006, Scott G. Kelly wrote:
> Here's the current vendor-specific payload definition:
> 
>    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                       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |          Element ID           |   Value...    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> Wouldn't something like this make more sense?
> 
>    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                       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           Length              |          Element ID           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Value....
>   +-+-+-+-+-+-+-
> 
> 
> --Scott
> 
> _________________________________________________________________
> 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