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

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 19 Jun 2006 16:59:15 -0700 (GMT-07:00)

Hi David,

>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".

Doh! Okay, I get it now - a little slow this afternoon....

--Scott

_________________________________________________________________
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: Tue, 20 Jun 2006 13:26:05 -0400 (EDT)

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.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:[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,
>> >>
>> >> "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor 
>> >> Specific Payload" for vendor message elements:
>> >>
>> >>    0                   1                   2                   3   
>> >>                                   ^-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   
>> >>    |              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
>> >>> Wouldn't something like this make more sense?
>> >>>
>> >>>    0                   1                   2                   3
>> >>>   |           Length              |          Element ID           |
>> >>>   |   Value....
>> >>>   +-+-+-+-+-+-+-

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 21 Jun 2006 10:25:48 -0700

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

Yes it would.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap