Capwap Mailing List: RE: Bindings issue

[Bob O'Hara (boohara) (boohara]

David,

I agree with your points about how this might be addressed.  However, I
have just looked at eh issue tracker and find that the editors have not
added this as an issue.  Would the editors please add this as an issue
in the "bug" category?

 -Bob
 
-----Original Message-----
From: David T. Perkins [mailto:dperkins [at] dsperkins.com] 
Sent: Tuesday, February 21, 2006 2:23 PM
To: Bob O'Hara (boohara)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Bindings issue

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)

On Tue, 21 Feb 2006, Bob O'Hara (boohara) wrote:
> 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
Regards,
/david t. perkins