Subject: [Capwap] vsp definition has no length

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

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

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 19 Jun 2006 16:33:42 -0700 (PDT)

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   
  |              Type=43          |             Length            |
                                  ^-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

---

From: sujay <[email-masked]>
Date: Tue, 20 Jun 2006 12:08:41 +0530

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:[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,

   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   

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

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 20 Jun 2006 06:47:59 -0700 (PDT)

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

---

From: sujay <[email-masked]>
Date: Tue, 20 Jun 2006 19:43:45 +0530

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;

-----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,

Regards,
/david t. perkins

On Tue, 20 Jun 2006, sujay wrote:

> 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; 
> 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, 
> recipient's) is prohibited. If you receive this e-mail in error, 
> please notify the sender by phone or email immediately and delete it!
> 
> "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor 
> Specific Payload" for vendor message elements:
> 
>    0                   1                   2                   3

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 20 Jun 2006 07:31:16 -0700 (PDT)

HI,

I'm having a difficult time understanding what you are saying.

What do you mean by "I would still prefer to have the flexibility
of *my* message element extensions added over any standard
control message type"?

Would you provide some examples to illustrate what you mean.

Thanks,
/david t. perkins

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 20 Jun 2006 07:32:15 -0700

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

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 20 Jun 2006 07:59:10 -0700 (PDT)

HI,

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

Regards,
/david t. perkins

On Tue, 20 Jun 2006, Scott G Kelly wrote:
> What is the value in this> 
> Thanks,
> 
> Scott
> 
> sujay wrote:
> > Hi,
> > Guess, I did..
> >

---

From: sujay <[email-masked]>
Date: Tue, 20 Jun 2006 21:41:48 +0530

Hi,
By encoding the Vendor ID in every message makes all category ,'VSP'. 
It does look good but MAY cause implementation complexity, may not be 
required for all messages, may be unnecessary altogether
if the intention of the vsp element is made clear in the draft.

David;
My usage of the vsp element is thus;

    0                   1                   2                   3   
   |              Type=32          |             Length            |

Where the above can be added to any of the Control message types;
(say a Discovery message !) .  And assume the information
carried in this message makes best sense and usage when send along with 
other message elements in the Discovery message i.e. Discovery Type, WTP
Descriptor etc..

So in case if your proposal includes removal of this vsp element, I
wouldn't suggest.

Kindly correct me.

Regds,
Sujay G
My Location;

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 8:29 PM
To: scott G Kelly
Cc: 'capwap'; sujay
Subject: Re: [Capwap] vsp definition has no length

HI,

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

Regards,
/david t. perkins

> > 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.
> > 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
please
> >> instead have a generic vsp control message type ???
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250
> >> 85

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

> >>>   |                       Vendor Identifier
|
> >>>   |                       Vendor Identifier
|
> >>>   |           Length              |          Element ID
|

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 20 Jun 2006 12:02:00 -0400

I've captured this discussion as issue 144.

Cheers,

Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 20 Jun 2006 09:30:51 -0700 (PDT)

HI,

Thanks for the response.

Again, all I'm proposing is that a single syntax be used for
encoding standard and vendor defined message elements.

See inline below.

> My usage of the vsp element is thus;
Again, I'm suggesting that the above (and standard message
elements) be encoded as:
      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 ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

> So in case if your proposal includes removal of this vsp element, I
The proposal that I sent to the list on June 8th simply changes
the syntax of encoding the standard and vendor defined message
types. It says NOTHING about where they can be used.