Subject: [Capwap] Bindings issue

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 21 Feb 2006 13:32:18 -0800

I believe there is an issue we need to address before the -00 draft is
produced.  This relates to the decision by the working group that the
original CAPWAP protocol would restrict itself to supporting only
802.11, but would provide extensibility to support other wireless
protocols.  This support for extensibility is insufficient in the LWAPP
draft and, without direction from the working group, from the -00 CAPWAP
draft as well.

In the current draft of the LWAPP proposal, all message element
identifiers in the protocol are drawn from a single, 16-bit, number
space.  This does not provide for parallel development of bindings for
different protocols or an unambiguous way to allocate these identifiers
without some central administration of the entire message identifier
number space.

I propose that we add a binding identifier to each message element.
This identifier would, in the -00 draft, place each message element into
either the "base protocol" number space or the "IEEE 802.11" number
space.  It would also allow for reuse of the values in the message
identifier field.  

Alternatively, we could create a "Binding Separator" message element.
This element would separate message elements in the base portion of the
protocol from those defined in a binding.  The value carried by the
separator would identify the specific binding for the elements that
follow the separator, either to the next separator element or to the end
of the packet.

Either alternative for this proposal would require administration of the
binding identifier number space.  But, that number space would most
likely last much longer than the message identifier space, itself, if
left as a single common number space for all bindings to share.

 -Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025
 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: <[email-masked]>
Date: Tue, 21 Feb 2006 14:02:08 -0800

I don't see why this issue needs to hold up the CAPWAP -00 draft.  I
don't expect the -00 draft to solve all open issues.

At this point, its sufficient to add this to the issues database and
address the WG as you have done.

Thanks,
Dorothy

-----Original Message-----
From: ext Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2006 1:32 PM
To: [email-masked]
Subject: [Capwap] Bindings issue

 -Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 21 Feb 2006 14:22:43 -0800 (PST)

HI,

Glad to see you bring up this topic. The eval report suggested
that the numbering space of the attributes (called information
elements in the LWAPP spec) be increased from 8 bits
(see section 9.1.1). Note that also that it appears
to me that numbering space for message types is limited
to 8 bits and there is not a way to add vendor extensions.
(And it looks to be an oversight that there was no mention
of who (such as IANA) that manages this space.) The LWAPP
spec for attributes does allow vendor additions (see section
4.2.2.1.1). However, it is quite wasteful of space, and
suprisingly has a 16-bit space for vendor attributes
(element IDs). Note LWAPP identifies vendors by the
IANA enterprise number, which is also used by SNMP.
In the SNMPv3 RFCs, the enterprise number is used
in one case for a security model identifier, which
is a 32-bit integer in range (0 .. 2147483647). 
(See RFC 3411, section 5, discussion of textual
convention SnmpSecurityModel). The identifier is the
enterprise number multiplied by 256 (that is, shifted
left by 8 bits), plus an enterprise specific value.
Since there is no assignment of 0 as an enterprise
number, values less than 256 are IANA controlled.
This scheme supports enterprise number of upto
23 bits (that is values upto 8,388,608 enterprises).

Given the suggestion of the eval team, and Bob's
input below, I suggest that the number space for
message types and information element types
be encoded as the following:
 1) it be a 32 bit unsigned number
 2) it is encoded as enterprise number times 256
    plus enterprise value.
 3) the values less than 256 be managed by IANA
 4) an appropriate enterprise value be choosen
    for each technology and managed either
    by an IEEE group (or IANA)

> left as a single common number space for all bindings to share.
Regards,
/david t. perkins