Capwap Mailing List: RE: Bindings issue

[Bob O'Hara (boohara) (boohara]

Dorothy,

The reason I think this should be addressed before the -00 draft is, as
much as we would like to avoid it, people will begin implementing and
claiming conformance (right or wrong) to "CAPWAP".  If the protocol is
later modified to incorporate either of these proposals, it is very
likely to completely change values for all the binding message
identifiers.  This will lead to exactly the opposite of what we are
trying to accomplish with this protocol.  Rather than consolidating
around a single CAPWAP protocol, the market will fragment around
different draft versions of the protocol.  

I don't think that this will take much time to resolve, though it might
take a bit more time to edit into the draft.  It will certainly better
serve our market, if we do this now, rather than later.

 -Bob
 
-----Original Message-----
From: Dorothy.Gellert [at] nokia.com [mailto:Dorothy.Gellert [at] nokia.com] 
Sent: Tuesday, February 21, 2006 2:02 PM
To: Bob O'Hara (boohara); capwap [at] frascone.com
Subject: RE: [Capwap] Bindings issue

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:boohara [at] cisco.com] 
Sent: Tuesday, February 21, 2006 1:32 PM
To: capwap [at] frascone.com
Subject: [Capwap] Bindings issue

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