Subject: Re: [Capwap] vsp definition has no length

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 21 Jun 2006 06:15:23 -0700

I don't think that David's proposal actually changes, in any way, the
number of VSPs we will have to deal with. All he is trying to propose, I
believe, is a consistent message element format, regardless of whether
it is a vsp or not. David, is this correct?

While I'm not thrilled by this proposal as it does increase the length
of the messages, and possibly the parsing processing, albeit not by
much, I do have to admit that there is some elegance in consistency...

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 10:26 AM
> To: David T. Perkins
> Cc: 'capwap'
> Subject: Re: [Capwap] vsp definition has no length
> 
> Hi David
> 
> I think maybe I didn't phrase my concern clearly - sorry 
> about that. I've attempted to clarify below.
> 
> >The proposal to have a single way to encode the type of message type 
> >instead of two ways, adds nothing to the complexity of encoding or 
> >parsing of message elements.
> >In fact it reduces complexity. Likewise, it neither encourages or 
> >discourages use of vendor defined message elements.
> >
> >I believe what is currently in the CAPWAP-01 document will 
> most likely 
> >become a frequently misunderstood and inappropriately implemented 
> >portion of the specification. This was demonstrated by your question 
> >yesterday! And possibly by sujay's question today (but I'm not sure 
> >what sujay meant, and I'm waiting for a response).
> >
> 
> Currently, 01 proposes that we encode message *types* like this:
> 
> -------------------------------
> 4.3.1.1.  Message Type
> 
>    The Message Type field identifies the function of the 
> CAPWAP control
>    message.  The Message Type field is comprised of an IANA Enterprise
>    Number and a message type value field.  The first two byte contain
>    the IANA Enterprise Number (for example, the IEEE 802.11 IANA
>    Enterprise number is 13277), and the second two bytes contain the
>    Message Type value.  The message type field can be expressed as:
> 
>    Message Type = IANA Enterprise Number * 256 + Message Type Value
> 
>    The valid values for base CAPWAP Message Types are given 
> in the table
>    below:
> -----------------------------------
> 
> ...where message types are e.g. discovery req/rsp, join 
> req/rsp, etc.  The text above says you should encode the 
> enterprise number (aka vendor id) into the message type. One 
> question pertains to whether this is required or not, but 
> that's not the question I meant to raise in my email to you. 
> I don't currently have a strong opinion one way or the other 
> on this, though I think we should be clear about why we think 
> this is important. But let's set this aside for the moment. 
> 
> The suggestion I'm concerned with in my previous email in 
> this thread is in your email of June 8, where you proposed 
> extending this concept to include message *element* types:
> 
> -----------------------------
>   Message Elements:
>     The message elements field contains, zero, one, or more message
>     element field, which has the following format:
> 
>     Message Element:
> 
>        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 ....
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>         Message Element Type: This field identifies a message element
>             of a CAPWAP control message.  The Message Element 
> Type field
>             is comprised of an IANA Enterprise Number and an 
> enterprise
>             specific message element type number.  The first 
> three octets
>             is the enterprise number in network byte order, with zero
>             being used for CAPWAP generic message types and the
>             IEEE 802.11 IANA assigned enterprise number 13277 being
>             used for IEEE 802.11 technology specific message element
>             types.  The last octet is the enterprise specific
>             message element type number, which has a range 
> from 0 to 255.
> 
>             The value of the message element type field can
>             be expressed as:
> 
>             Message element type value = IANA Enterprise 
> Number * 256 +
>                       enterprise specific message element type number
> -----------------------------
> 
> I find the idea of dealing with this during message parsing 
> to be a little scary. You mention collapsing 2 types of 
> messages into one, but what this looks like it is doing is 
> creating the potential for combinatorial explosion in the 
> potential message element combinations one might encounter 
> for any given message type. Any message element could have 
> any vendor id, and it's own special value.
> 
> Again, from a practical perspective, how many VSP's would you 
> expect to see in an interoperable protocol? This seems to 
> anticipate many, but shouldn't we be striving to make this 
> rare? Isn't that why we're here?
> 
> Scott
> 
> 
> >Regards,
> >/david t. perkins
> >
> >On Tue, 20 Jun 2006, Scott G Kelly wrote:
> >> I don't know about anyone else, but from an implementor's 
> standpoint, 
> >> I'm a little concerned about this. I know something 
> similar to this 
> >> made it into the 01 draft, but I was petty surprised when I saw it.
> >> 
> >> The proposal is to include a vendor ID in *every* message element. 
> >> That is, the message element type field has some bits 
> which indicate 
> >> vendor id, and some bits which indicate the actual element 
> type. This 
> >> means every message element is a VSP.
> >> 
> >> I'm not sure what functionality this is intended to provide that 
> >> can't be provided by a generic VSP, and the fact that we 
> will have to 
> >> check each and every message element for this condition (and deal 
> >> with unexpected ones) seems pretty painful for 
> functionality I could 
> >> alternatively attain with a generic VSP.
> >> 
> >> Use of VSPs should be relatively rare in a standardized, 
> >> interoperable protocol. Building them right into each and every 
> >> message element seems like an invitation to 
> non-interoperability, not 
> >> to mention a potential explosion in message processing 
> complexity. Am I missing something here?
> >> What is the value in this>
> >> Thanks,
> >> 
> >> Scott
> >> 
> >> sujay wrote:
> >> > Hi,
> >> > Guess, I did..
> >> > 
> >> > I would still prefer to have the flexibility of *my* message 
> >> > element extensions added over any standard control message type, 
> >> > Simply because some extensions  may (and does in my case !) fit 
> >> > best with a specific control message type, and not as a separate 
> >> > msg type altogether.
> >> > 
> >> > Having said that, I see it is a good idea to have v.s.p message 
> >> > type same as any standard control message type, which is 
> what you 
> >> > recommend.
> >> > 
> >> > Of course ,keeping the v.s.p message extension still 
> >> > intact(4.4.32), as it is now.
> >> > 
> >> > Regds,
> >> > Sujay G
> >> > My Location;
> >> > 
> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5
> >> > 25085
> >> > &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:[email-masked]]
> >> > Sent: Tuesday, June 20, 2006 7:18 PM
> >> > To: sujay
> >> > Cc: 'Scott G. Kelly'; 'capwap'
> >> > Subject: RE: [Capwap] vsp definition has no length
> >> > 
> >> > 
> >> > HI,
> >> > 
> >> > Why yes. This was specified in the proposal for CAPWAP 
> data packet 
> >> > formats that I sent June 8th. Did you miss it?
> >> > 
> >> > Regards,
> >> > /david t. perkins
> >> > 
> >> > On Tue, 20 Jun 2006, sujay wrote:
> >> > 
> >> >> 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.
> >> >> 5250
> >> >> 85
> >> >> &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:[email-masked]]
> >> >> 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
> >> >>
> >> > 
> >> > 
> >> 
> >
> >
> 
> _________________________________________________________________
> 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

---

From: Scott G Kelly <[email-masked]>
Date: Wed, 21 Jun 2006 08:40:40 -0700

Just giving this some more thought, and I think you guys are right: this 
adds consistency, and the only real drawback is increased message size. 
Since a VSP could theoretically appear wherever any other message 
element could, I guess the added parsing complexity is not as onerous as 
I first thought.

If we adopt this approach, it obviates the need for an explicitly define 
VSP message element, doesn't it?