Subject: Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 9 Oct 2006 10:42:13 -0700

I personally prefer to start maintaining configuration and status state
on the WTP after the join is complete. Is there a problem that arises
with the current draft? Is this just a personal preference, or is there
a bug?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Friday, September 29, 2006 2:22 PM
	To: Michael Montemurro
	Cc: [email-masked]
	Subject: [Capwap] Proposed resolution to Issue 177 WTP Reboot
Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01
operations

	All,
	 
	Issue 177, "WTP Reboot Statistics belongs in the Join"
	is listed below:
	29) WTP Reboot Statistics belongs in the Join, and the reasons
listed
	are not clear enough.
	
	<PRC> Doesn't really matter whether this is included in the
	configuration or the join, but if the WG agrees to move it. We
can
	clarify some of the reasons, as long as it provides value.
	Believing that there may be times when it is desirable for the
WTP to provide 
	information to the AC about its stability, the proposed
resolution to Issue 177 is 
	to insert the following text at the end of
	Section 6.1 "Join Request":
	 
	The following message element may be included in the Join
Request message:
	- WTP Reboot Statistics, see Section 4.4.44.
	 
	Comments please,
	 
	Thanks,
	 
	Dorothy

	On 6/30/06, Michael Montemurro <[email-masked]>
wrote: 

		David, Pat,
		 
		I created issues 150-198 to deal with the points in
David's email. Happy hunting!
		 
		Mike

		On 6/27/06, Pat Calhoun (pacalhou) <[email-masked] >
wrote: 

			Going through David's lengthy document, he has
raised an interesting
			number of points that I believe require issues
to be created. At one 
			point I'm paraphrasing Dave's comments in order
to be brief, and
			introducing my own numbering scheme.
			
			1) Can message elements be in any order? (I
believe they should be)
			
			<PRC> Yes, and I suspect we need to include text
to make it more 
			obvious.

			2) Are all specified message elements required?
(The obvious answer is
			"yes", but this document doesn't discuss
versioning. For example, what
			if in a new version of CAPWAP an additional
message element was to be 
			added. Would a new message type be created and
the additional message
			element added to it, or the existing type
reused?)
			
			<PRC> This is a great question, and one that
does need to be addressed
			in the spec. In the Diameter protocol we dealt
with this issue by 
			including a "Mandatory to implement" bit. If any
AVP was received, whose
			bit was set, yet was not recognized, then the
request had to be
			rejected.
			
			<PRC> We could consider something similar here,
but I believe with the 
			firmware download component of the protocol it
may be less of an issue -
			although not guaranteed. I would hope (and
expect) that as the CAPWAP
			protocol extends, the AC would push new firmware
to the WTP. This does 
			require that the initial part of the state
machine be fairly static, and
			this could be an area where the "Mandatory to
implement" bit could be
			useful as it would allow the AC to fall back to
older protocol behavior. 
			
			3) CAPWAP-01 doesn't do a good job of indicating
which message elements
			can be repeated.
			
			<PRC> Another good point. When we list the
message elements, we should
			note whether the frequently is 0-1 (meaning
absent or once), 1 (only 
			once) or 0+ (meaning any number of them could be
present.

			4) Can "additional" message elements be added to
a message? (I believe
			so for reporting capabilities, statistics, and
events. For
			configuration, there is nothing in the protocol
that says what happens
			when one end gets an configuration     element
it doesn't know about.
			Should it be ignored, and the other elements
processed, or should the
			complete operation     failed?) 
			
			<PRC> The "Mandatory to implement" bit above
could address this issue.
			If an unrecognized message element is found to
have the bit set, then
			the whole message needs to be rejected. If the
bit is not set, the 
			message element may be safely ignored.

			5) The config has a concept of "default value"
for each configuration
			attribute. However, the default values are not
clearly specified. This
			needs to be resolved to be able to support
"default values". 
			
			<PRC> Another good point raised by David.

			6) the documentation of which "binding specific"
message elements are to
			be included with CAPWAP messages is not
consistent, and is difficult to 
			follow.
			
			<PRC> Has this been addressed in the latest
(-02) document?

			7) There are some message elements that cause
"actions". This approach
			to protocol design is problematic and should be
eliminated. 
			
			<PRC> Could you be more specific as well as
provide guidance on what you
			would like to see?

			8) The message types are inconsistently named,
and do not follow the
			conventions of well designed protocols. Can the
operations be named 
			consistently with the following terminology:
			  1) request/response (used to get/set/perform
action)
			  2) report/ack (use to tell the other side
something)
			
			<PRC> Could you provide your thoughts on which
messages fall within 
			which one of your categories?

			9) Many of the configuration items, and status
items are not listed in
			one section with definitions. (Well make it two
sections - one for
			CAPWAP and the other which is "binding"
specific.) For example, not all 
			of the time period lengths are identified and
specified in section 4.5.
			
			<PRC> Unfortunately, the document has gone back
and forth a few times
			and before we opt to change the structure of the
document, I'd like to 
			ensure that we have broad agreement on what we
want - with the
			understanding that we will never make everyone
happy.

			10) each operation should have listed in which
states it can be sent and
			received
			
			<PRC> I do not understand your comment.

			11) All strings, such as WTP location, should be
changed from US-ASCII
			encoding to UTF-8 encoding.
			
			<PRC> Agreed.
			
			12) The term "mobile" is not really accurate
when describing wireless 
			interfaces, since wireless does not imply
mobile. Can we just use
			the techie term "STA" instead.
			
			<PRC> I agree we should use the term Station, or
STA for short.

			13) The WTP Descriptor message element contains
too much information, 
			lacks clarity on the WTP encryption field and
includes version numbers,
			which should be in string form.
			
			<PRC> To the first point, I disagree. I think
there is value in knowing
			everything about the WTP. The AC vendors can
expose whatever information 
			they want, but I don't believe anything is
unnecessary.
			
			<PRC> To the second point, this is one of those
areas where the concept
			of the technology binding creates complexity.
Given that we cannot
			simply discuss 802.11i at this point, the only
thing we can do is punt
			to another section in the technology binding
section. That said, I agree
			with Dave that the 802.11 binding section is too
light in this area.
			However, I would much prefer that instead of
trying to address this 
			specific issue, we discuss whether we should
even be supporting the mode
			of operation where 802.11i is performed in the
AC - especially with the
			introduction of DTLS to secure the data plane.
Right now, it just feels 
			like we have too many options and I am worried
that interoperability
			will be severely impacted (not to mention
protocol complexity).
			
			<PRC> To the last point, I have no issues with
including text stating 
			that the version numbers should be in string
form.

			14) The WTP Descriptor information is not
required at Join time.
			
			<PRC> Well, as far as I can tell, I think
there's value in knowing
			whether the WTP can even be supported by the AC.
So the more info is 
			provided by the WTP, the better the AC can
determine whether it should
			just ignore the WTP or not. This could be done
because it knows that the
			firmware running on the WTP is not compatible,
and it has no new
			firmware to download.

			15) Are the values in the WTP Frame Encryption a
capabilities bit, or an
			enum?
			
			<PRC> Looks like an enum to me. Not sure what
Dave would prefer the text
			to read. There are various other similar
comments throughout, which I 
			will not repeat here.

			16) The Discovery Response is broken. The AC
SHOULD NOT be providing any
			info to a WTP (or something that claims to be a
WTP). Also, the AC
			should tell the WTP what to do next, with
choices: 1) Ok to try to join, 
			2) don't try to join, 3) try
discover on a list of
			returned ACs)
			
			<PRC> I don't believe there is an issue with
sending the AC's
			information to the WTP, but would solicit input
from the list. That 
			said, some of the information in the AC
Descriptor is required, such as
			the current load on the AC. No point is trying
to join if he AC
			indicates it's already at max capacity.
			<PRC> I believe if the AC does not return the
response, then it implies 
			(2). Otherwise, it is (1). (3) is handled during
the join or configure
			process, which I believe is right.

			17) Is AC Name text?
			
			<PRC> Yes, and same with WTP Name.

			18) Primary Discovery are not required. 
			
			<PRC> Disagree. Required for failover.

			19) The text does not make it clear that the
contents of the WTP
			Location is informative only, and as Dave calls
it, a "scratchpad".
			
			<PRC> Well, to be honest, I thought the example
"next to the fridge" 
			made it clear that the information did not
derive from any scientific
			formula. The description also states this is a
user-defined. I believe
			this should be good enough.

			20) Session is not required
			
			<PRC> I believe you may be correct that with the
transition to DTLS,
			this is no longer required.

			21) need to send "common name" as found in the
WTP CERT so that the AC
			can verify
			
			<PRC> The protocol currently relies on the MAC
address being the key
			that binds the certificate to the WTP. I don't
see a need to change
			this.

			22) Result code in Join Response is not
sufficient, for instance WTP HW 
			not supported.
			
			<PRC> Well, the protocol does not require this
because the Discovery
			Response would never be sent (as the protocol
stands today).

			23) AC IPv4/IPv6 Addr discusses clustering,
which is unnecessary. 
			
			<PRC> Agreed.

			24) Change Echo to Keepalive or heartbeat.
			
			<PRC> I call it potato....

			25) What if all of the message elements do not
fit within a single
			CAPWAP control frame. 
			
			<PRC> We should address this.

			26) AC Name with Index is all messed up...
			
			<PRC> Not really. You simply include more than
one, and the index field
			is clearly the priority. Don't understand the
Multi-AC comment. No 
			inter-AC protocol implied here.

			27) WTP Board Data belongs in the Join, not
configure.
			
			<PRC> Agreed, but wonder even more why we are
duplicating this
			information across both the WTP Descriptor and
the WTP Board Data 
			message elements.

			28) The WTP Static IPv4 Address should not have
the Static bit, but
			instead state that 0.0.0.0 <http://0.0.0.0/>
means a static address is not to be used.
			
			<PRC> I don't have an issue with this request,
but in the end we have 
			the same function. The reason why I state this
is that we can refine
			this protocol until the cows come home, and at
one point we need to draw 
			a line in the sand.

			29) WTP Reboot Statistics belongs in the Join,
and the reasons listed 
			are not clear enough.
			
			<PRC> Doesn't really matter whether this is
included in the
			configuration or the join, but if the WG agrees
to move it. We can 
			clarify some of the reasons, as long as it
provides value. 

			30) The IEEE 802.11 WTP Radio Configuration
message element's BSSID
			field should be an array.
			
			<PRC> Disagree.

			30) The IEEE 802.11 WTP Radio Configuration
message element's Country
			Code is not clear enough.
			
			<PRC> The text points to the actual MIB element
in the 802.11-1999
			standard, which very clearly defines the
contents of the field. I don't 
			think there's value in replicating the format of
this field in the 
			CAPWAP standard.

			31) There seems like an awful lot of additional
configuration message
			elements that need to be specified here!
			
			<PRC> Having built a protocol based on this,
it's not clear to me what's 
			missing. I think it would be useful if you
provided concrete details on
			what's missing.

			32) Configuration Status is just plain broken
because any configuration 
			change operation may fail and there is no
response to the 
			configuration changes specified in this command.
			
			<PRC> There certainly is - I guess I don't
understand the concern.

			33) Use of Change State Event should instead be
Radio Admin State. 
			
			<PRC> Perhaps the two are not described
properly. The first is used by 
			the WTP to inform the AC that something has
occurred with a radio. The
			second is used by the AC to enable/disable a
radio.

			34) Report Timer needs to be in section 4.5 or
11
			
			<PRC> ok

			35) Should Idle Timeout be per radio, or per
WTP, and should the value
			be defined in section 4.5 or 11.
			
			<PRC> Per WTP, and yes. I believe it is fine as
it is. 

			36) WTP Fallback isn't well defined, and should
be removed. 
			
			<PRC> Disagree. I believe it is necessary to
create enough resiliency in
			the protocol/service.

			37) How are the "Rate Set" and "Supported Rates"
encoded. 
			
			<PRC> This was fixed in the -02 

			38) AC Timestamp doesn't belong in the
configuration, but instead in the
			join.
			
			<PRC> Not sure this really matters....

			39) Add MAC ACL Entry - this is so strange and
is being managed like no 
			other configuration data.
			
			<PRC> I do not understand the comment

			40) Decryption Error Report Period is not
defined in section 4.5 or 11
			
			<PRC> ok, and note that the information has been
moved to the IEEE 
			802.11 RSNA Error Report From Mobile

			41) Configuration Update Response. today, there
are primarily two types
			of configuration models. The first is when
config is changed, it is only
			changed in the volatile copy (the memory or
running). An explicit 
			command is needed to save the config to
nonvolatile storage. The second
			model has config both running (volatile) and
saved (nonvolatile) config
			changed when a config change is made. And there
might be a special
			command to have a config change apply to only
one. In this case, there
			is no need for a "save config to nonvolatile"
command. It is not clear
			what is suppose to be supported here in CAPWAP,
and how does CAPWAP 
			support devices with no or very limited
nonvolatile storage for config!
			
			<PRC> CAPWAP does not support WTPs with no
nonvolatile storage. The
			protocol has the AC push configs to the WTP,
which saves them at the 
			time they are received. I do not believe
anything else is required.

			42) Configuration Update Response includes the
Result Code message
			element, which includes values that do not
appear to be relevant for 
			this message, and there are plenty of other
failure cases
			
			<PRC> ok, but note that we are sharing a common
message element. Any
			suggestions on how to address your issue?

			43) Change State Event Report. This seems a
little silly to be sent in 
			the "configure" state. It seems only appropriate
for the "run" state.
			Some might argue that even in the "run" state it
shouldn't be sent after
			a "config update" request that changes the
operational state. However, 
			in the "run" state, it may take a while to have
the operational state
			change to follow the admin state. Thus, I think
it is OK in the "run"
			state after config changes."
			
			<PRC> I believe this was addressed in -02. 

			44) Clear Config Request. this operation has
several problems, which
			include:
			   1) currently, the CAPWAP-01 spec says that
this can only be done in
			the "run" state. This is silly. It should also
be possible in the 
			"configure" state.
			<PRC> I wonder why the AC would even consider
clearing the WTP's state
			before it even knows how it is configured.
			
			   2) the value of "manufacturing defaults" is
not defined, and a poor 
			term to use, since it implies that that each
manufacturer can have
			different values. If so, then the AC will have
no knowledge of the
			config on the WTP! The problem of "default
config values" has already be 
			mentioned above. After each config attribute has
been defined with a
			default value, then the proper term would be
"CAPWAP config defaults".
			<PRC> Yes, you've raised this point already, and
I agree that it does 
			need to be addressed.
			
			   3) This operation is not defined to have a
response. This is broken,
			since any config change can fail. Also, it is
not defined what happens
			next. Does this cause the WTP to reboot an start
a "clean discovery"? 
			<PRC> This was addressed in -02

			45) Image Data Request. Yes, there are actually
three different "Image
			Data Request" messages. Which one is determined
by which of the
			three message elements is contained. This is
completely silly! There 
			should be three separate operations!
Additionally, how does the WTP know
			which image to get? The AC should be making that
decision.
			
			<PRC> I believe the WTP is the only device that
knows what it's filename 
			should be. Why would an AC vendor know about
file naming conventions
			used by the WTP vendors? I believe your other
issues are discussed in
			the next items.

			46) Image Data Response. this is silly. This
operation can fail! There 
			needs to be message element that indicates the
result.
			
			<PRC> How so? This is only used to send firmware
to the WTP. Not clear
			what could fail... Reading the image from flash?

			47) Image Data Request. when starting over again
at the WTP start state, 
			the WTP shouldn't use the "normal" discovery
process, but instead "fast
			track" a connection back to the AC that just
downloaded the image. With
			a little more          work, we could probably
figure out a way to reuse 
			the old DTLS session.
			
			<PRC> To what gain? What is so expensive about
the discovery, and what
			happened if the AC was not longer reachable?

			48) opcode - if this is here, might as well also
have a value that 
			indicates last block of the image file, instead
of looking at the block
			size.
			
			<PRC> But we're just changing for the sake of
changing - the protocol
			works as-is.

			49) since this operation does not have the block
number as a parameter, 
			the WTP must determine the block number via the
CAPWAP message header
			sequence number.  NOTE: DTLS does not provide
in-order delivery of
			packets. Also, this requires the WTP to remember
state. This message
			element should be re-engineered to have the
following subfields: 
			[edited]
			
			<PRC> The control header includes a sequence
number, and while we can
			change the current protocol to match your
recommendations, the protocol
			does work. If it ain't broken...

			50) Image Data Response. this is silly. This
operation can fail!  For 
			example, the WTP can run out of space to store
the block, or
			there could be a failure in writing the block to
storage. (Or as "Image
			Data Request"(9.1a) is presently specified, the
checksum match could 
			fail.) There needs to be message element that
indicates the result.)
			Note: don't need a block number field, since
request and responses are
			paired.
			
			<PRC> We can include a result code

			51) Image Data Request. silly beyond belief 
			
			<PRC> Beauty is in the eye of the beholder ;-).
Seriously, the protocol
			does work, so what exactly are you looking for?

			52) Image Data Response. This is silly. This
operation can fail! There
			needs to be message element that indicates the
result.
			
			<PRC> See above comment.
			
			53) Reset Request. ...
			
			<PRC> The comment is irrelevant now that Clear
Config has changed.

			54) Reset Response. this is silly. This
operation can fail! There needs
			to be message element that indicates the
result.
			
			<PRC> I sense a trend. I will stop including
these messages from now on.

			55)Duplicate IPv4 Address. how often is this
reported if the condition
			remains?
			
			<PRC> Only required once, I think, but we may
want to include some text
			covering that.

			56) the list of events seems understated! 
			
			<PRC> Text and conditions please

			57) Data Transfer Request. Nice to have -
remove.
			
			<PRC> Disagree. Providing diagnostics
capabilities is required.

			58) Mobile Config Request. the actual details of
how this works on both 
			splitMAC and especially localMAC are not well
specified. That is, only
			the figures and text in sections 11.1.1 and
11.1.2 provide any clue as
			to events that would cause an AC to send this
message type. Also, there 
			are restrictions on combinations of parameters
that can be included in
			the message.
			
			<PRC> I wonder whether other folks agree that
more details are required.

			59) it doesn't say if one message can be used to
update more than one 
			STA. It should be able.
			
			<PRC> No, otherwise you end up with the problem
of associating specific
			message elements with a given mobile. One mobile
per request.

			60) IEEE 802.11 Mobile. shouldn't the STA MAC
address be included so 
			this message element can be matched with a
(4.4.8)Add Mobile message
			element?
			
			<PRC> I believe this is to your previous point,
but the protocol assumes
			one mobile per request.

			61) IEEE 802.11 Update Mobile QoS. s this for
data traffic to the AC? If
			so, then why is this an 802.11 message element
			
			<PRC> Intended to be a way to push policies to
the WTP to prioritize
			mobile traffic.

			62) IEEE 802.11 WLAN Config Request. why is a
new message type that is
			802.11 specific needed to modify 802.11 WLANs?
It seems like the
			existing "(8.4)Configuration Update Request"
message could be used.
			
			<PRC> To be more specific only. 

			63) note here there are information elements to
create, delete, and
			modify WLANs. However, for message type
"(10.1)Mobile Config Request",
			there is only add and delete (and the "add" used
to modify). 
			
			<PRC> Correct. The protocol requires the AC to
resend a new add with a
			different policy. No specific reason, but if
this is deemed
			inconsistent, we could change it.

			64) IEEE 802.11 Assigned WTP BSSID. The mapping
of WLAN IDs to BSSIDs 
			seems like it needs a little more work
			
			<PRC> What exactly would you like to see?

			Pat Calhoun
			CTO, Wireless Networking Business Unit
			Cisco Systems

			> -----Original Message----- 
			> From: David T. Perkins
[mailto:[email-masked]]
			> Sent: Thursday, June 22, 2006 4:31 PM 
			> To: [email-masked] 
			> Subject: [Capwap] A commentary on CAPWAP-01
operations
			>
			> HI, 
			>
			> I've attached a long file that summarizes the
operations in
			> CAPWAP-01.
			> Enjoy,
			> /david t. perkins 
	
_________________________________________________________________ 
			To unsubscribe or modify your subscription
options, please visit:
	
http://lists.frascone.com/mailman/listinfo/capwap 
			
			Archives:
http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap
		
		Archives: http://lists.frascone.com/pipermail/capwap 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 12 Oct 2006 06:41:06 -0700

It seems to be an implementers preference, which the
proposed text change accommodates - the message element "may" be included.
The AC may choose to ignore the data that is provided prior to
configuration.

Dorothy

On 10/9/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> on the WTP after the join is complete. Is there a problem that arises with
> the current draft? Is this just a personal preference, or is there a bug?
>
>
> Pat Calhoun
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Friday, September 29, 2006 2:22 PM
> *To:* Michael Montemurro
> *Cc:* [email-masked]
> *Subject:* [Capwap] Proposed resolution to Issue 177 WTP Reboot
> Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations
>
>  All,
>
> *29) WTP Reboot Statistics belongs in the Join, and the reasons listed
> are not clear enough.
>
> configuration or the join, but if the WG agrees to move it. We can
> clarify some of the reasons, as long as it provides value.*
>
> Believing that there may be times when it is desirable for the WTP to
> provide
> information to the AC about its stability, the proposed resolution to
> Issue 177 is
> The following message element may be included in the Join Request message:
> On 6/30/06, Michael Montemurro <[email-masked]> wrote:
> >
> > David, Pat,
> >
> > I created issues 150-198 to deal with the points in David's email. Happy
> > hunting!
> >
> > Mike
> >
> >
> >  On 6/27/06, Pat Calhoun (pacalhou) <[email-masked] > wrote:
> > >
> > > Going through David's lengthy document, he has raised an interesting
> > > number of points that I believe require issues to be created. At one
> > > point I'm paraphrasing Dave's comments in order to be brief, and
> > > 1) Can message elements be in any order? (I believe they should be)
> > >
> > > <PRC> Yes, and I suspect we need to include text to make it more
> > > obvious.
> > >
> > >
> > > 2) Are all specified message elements required? (The obvious answer is
> > > "yes", but this document doesn't discuss versioning. For example, what
> > > if in a new version of CAPWAP an additional message element was to be
> > > added. Would a new message type be created and the additional message
> > > element added to it, or the existing type reused?)
> > >
> > > <PRC> This is a great question, and one that does need to be addressed
> > > in the spec. In the Diameter protocol we dealt with this issue by
> > > including a "Mandatory to implement" bit. If any AVP was received,
> > > whose
> > > bit was set, yet was not recognized, then the request had to be
> > > rejected.
> > >
> > > <PRC> We could consider something similar here, but I believe with the
> > >
> > > firmware download component of the protocol it may be less of an issue
> > > -
> > > although not guaranteed. I would hope (and expect) that as the CAPWAP
> > > protocol extends, the AC would push new firmware to the WTP. This does
> > >
> > > require that the initial part of the state machine be fairly static,
> > > and
> > > this could be an area where the "Mandatory to implement" bit could be
> > > useful as it would allow the AC to fall back to older protocol
> > > behavior.
> > >
> > > 3) CAPWAP-01 doesn't do a good job of indicating which message
> > > elements
> > > can be repeated.
> > >
> > > <PRC> Another good point. When we list the message elements, we should
> > > note whether the frequently is 0-1 (meaning absent or once), 1 (only
> > > once) or 0+ (meaning any number of them could be present.
> > >
> > >
> > > 4) Can "additional" message elements be added to a message? (I believe
> > > so for reporting capabilities, statistics, and     events. For
> > > configuration, there is nothing in the protocol that says what happens
> > > when one end gets an configuration     element it doesn't know about.
> > > Should it be ignored, and the other elements processed, or should the
> > > <PRC> The "Mandatory to implement" bit above could address this issue.
> > > If an unrecognized message element is found to have the bit set, then
> > > the whole message needs to be rejected. If the bit is not set, the
> > > 5) The config has a concept of "default value" for each configuration
> > > attribute. However, the default values are not clearly specified. This
> > > needs to be resolved to be able to support "default values".
> > >
> > > 6) the documentation of which "binding specific" message elements are
> > > to
> > > be included with CAPWAP messages is not consistent, and is difficult
> > > to
> > > follow.
> > >
> > > <PRC> Has this been addressed in the latest (-02) document?
> > >
> > >
> > > 7) There are some message elements that cause "actions". This approach
> > > to protocol design is problematic and should be eliminated.
> > >
> > > <PRC> Could you be more specific as well as provide guidance on what
> > > you
> > > would like to see?
> > >
> > >
> > > 8) The message types are inconsistently named, and do not follow the
> > > conventions of well designed protocols. Can the operations be named
> > >   1) request/response (used to get/set/perform action)
> > >   2) report/ack (use to tell the other side something)
> > >
> > > <PRC> Could you provide your thoughts on which messages fall within
> > > 9) Many of the configuration items, and status items are not listed in
> > > one section with definitions. (Well make it two sections - one for
> > > CAPWAP and the other which is "binding" specific.) For example, not
> > > all
> > > of the time period lengths are identified and specified in section 4.5
> > > .
> > >
> > > <PRC> Unfortunately, the document has gone back and forth a few times
> > > and before we opt to change the structure of the document, I'd like to
> > >
> > > ensure that we have broad agreement on what we want - with the
> > > understanding that we will never make everyone happy.
> > >
> > >
> > > 10) each operation should have listed in which states it can be sent
> > > and
> > > received
> > >
> > > 11) All strings, such as WTP location, should be changed from US-ASCII
> > > 12) The term "mobile" is not really accurate when describing wireless
> > > interfaces, since wireless does not imply      mobile. Can we just use
> > > <PRC> I agree we should use the term Station, or STA for short.
> > >
> > >
> > > 13) The WTP Descriptor message element contains too much information,
> > > lacks clarity on the WTP encryption field and includes version
> > > numbers,
> > > <PRC> To the first point, I disagree. I think there is value in
> > > knowing
> > > everything about the WTP. The AC vendors can expose whatever
> > > information
> > > they want, but I don't believe anything is unnecessary.
> > >
> > > <PRC> To the second point, this is one of those areas where the
> > > concept
> > > of the technology binding creates complexity. Given that we cannot
> > > simply discuss 802.11i at this point, the only thing we can do is punt
> > > to another section in the technology binding section. That said, I
> > > agree
> > > with Dave that the 802.11 binding section is too light in this area.
> > > However, I would much prefer that instead of trying to address this
> > > specific issue, we discuss whether we should even be supporting the
> > > mode
> > > of operation where 802.11i is performed in the AC - especially with
> > > the
> > > introduction of DTLS to secure the data plane. Right now, it just
> > > feels
> > > like we have too many options and I am worried that interoperability
> > > will be severely impacted (not to mention protocol complexity).
> > >
> > > <PRC> To the last point, I have no issues with including text stating
> > > that the version numbers should be in string form.
> > >
> > >
> > > 14) The WTP Descriptor information is not required at Join time.
> > >
> > > <PRC> Well, as far as I can tell, I think there's value in knowing
> > > whether the WTP can even be supported by the AC. So the more info is
> > > provided by the WTP, the better the AC can determine whether it should
> > > just ignore the WTP or not. This could be done because it knows that
> > > the
> > > firmware running on the WTP is not compatible, and it has no new
> > > firmware to download.
> > >
> > >
> > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or
> > > an
> > > enum?
> > >
> > > <PRC> Looks like an enum to me. Not sure what Dave would prefer the
> > > text
> > > to read. There are various other similar comments throughout, which I
> > > will not repeat here.
> > >
> > >
> > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing
> > > any
> > > info to a WTP (or something that claims to be a WTP). Also, the AC
> > > should tell the WTP what to do next, with choices: 1) Ok to try to
> > > join,
> > > 2) don't try to join, 3) try                     discover on a list of
> > > returned ACs)
> > >
> > > <PRC> I don't believe there is an issue with sending the AC's
> > > information to the WTP, but would solicit input from the list. That
> > > said, some of the information in the AC Descriptor is required, such
> > > as
> > > the current load on the AC. No point is trying to join if he AC
> > > <PRC> I believe if the AC does not return the response, then it
> > > implies
> > > (2). Otherwise, it is (1). (3) is handled during the join or configure
> > > 19) The text does not make it clear that the contents of the WTP
> > > Location is informative only, and as Dave calls it, a "scratchpad".
> > >
> > > <PRC> Well, to be honest, I thought the example "next to the fridge"
> > > made it clear that the information did not derive from any scientific
> > > formula. The description also states this is a user-defined. I believe
> > > <PRC> I believe you may be correct that with the transition to DTLS,
> > > 21) need to send "common name" as found in the WTP CERT so that the AC
> > > can verify
> > >
> > > <PRC> The protocol currently relies on the MAC address being the key
> > > that binds the certificate to the WTP. I don't see a need to change
> > > this.
> > >
> > >
> > > 22) Result code in Join Response is not sufficient, for instance WTP
> > > HW
> > > not supported.
> > >
> > > <PRC> Well, the protocol does not require this because the Discovery
> > > Response would never be sent (as the protocol stands today).
> > >
> > >
> > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.
> > >
> > > <PRC> Agreed.
> > >
> > >
> > > 25) What if all of the message elements do not fit within a single
> > > CAPWAP control frame.
> > >
> > > <PRC> Not really. You simply include more than one, and the index
> > > field
> > > is clearly the priority. Don't understand the Multi-AC comment. No
> > > 27) WTP Board Data belongs in the Join, not configure.
> > >
> > > <PRC> Agreed, but wonder even more why we are duplicating this
> > > information across both the WTP Descriptor and the WTP Board Data
> > > message elements.
> > >
> > >
> > > 28) The WTP Static IPv4 Address should not have the Static bit, but
> > > instead state that 0.0.0.0 means a static address is not to be used.
> > >
> > > <PRC> I don't have an issue with this request, but in the end we have
> > > the same function. The reason why I state this is that we can refine
> > > this protocol until the cows come home, and at one point we need to
> > > draw
> > > a line in the sand.
> > >
> > >
> > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed
> > > are not clear enough.
> > >
> > > configuration or the join, but if the WG agrees to move it. We can
> > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
> > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country
> > > <PRC> The text points to the actual MIB element in the 802.11-1999
> > > standard, which very clearly defines the contents of the field. I
> > > don't
> > > think there's value in replicating the format of this field in the
> > > CAPWAP standard.
> > >
> > >
> > > 31) There seems like an awful lot of additional configuration message
> > > <PRC> Having built a protocol based on this, it's not clear to me
> > > what's
> > > missing. I think it would be useful if you provided concrete details
> > > on
> > > what's missing.
> > >
> > >
> > > 32) Configuration Status is just plain broken because any
> > > configuration
> > > change operation may fail and there is no           response to the
> > > <PRC> There certainly is - I guess I don't understand the concern.
> > >
> > >
> > > 33) Use of Change State Event should instead be Radio Admin State.
> > >
> > > <PRC> Perhaps the two are not described properly. The first is used by
> > >
> > > the WTP to inform the AC that something has occurred with a radio. The
> > > second is used by the AC to enable/disable a radio.
> > >
> > >
> > > 34) Report Timer needs to be in section 4.5 or 11
> > >
> > > <PRC> ok
> > >
> > >
> > > 35) Should Idle Timeout be per radio, or per WTP, and should the value
> > > <PRC> Per WTP, and yes. I believe it is fine as it is.
> > >
> > >
> > > 36) WTP Fallback isn't well defined, and should be removed.
> > >
> > > <PRC> Disagree. I believe it is necessary to create enough resiliency
> > > in
> > > the protocol/service.
> > >
> > >
> > > 37) How are the "Rate Set" and "Supported Rates" encoded.
> > >
> > > 38) AC Timestamp doesn't belong in the configuration, but instead in
> > > the
> > > join.
> > >
> > > 39) Add MAC ACL Entry - this is so strange and is being managed like
> > > no
> > > 40) Decryption Error Report Period is not defined in section 4.5 or 11
> > >
> > > <PRC> ok, and note that the information has been moved to the IEEE
> > > 41) Configuration Update Response. today, there are primarily two
> > > types
> > > of configuration models. The first is when config is changed, it is
> > > only
> > > changed in the volatile copy (the memory or running). An explicit
> > > command is needed to save the config to nonvolatile storage. The
> > > second
> > > model has config both running (volatile) and saved (nonvolatile)
> > > config
> > > changed when a config change is made. And there might be a special
> > > command to have a config change apply to only one. In this case, there
> > > is no need for a "save config to nonvolatile" command. It is not clear
> > > what is suppose to be supported here in CAPWAP, and how does CAPWAP
> > > support devices with no or very limited nonvolatile storage for
> > > config!
> > >
> > > <PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
> > > protocol has the AC push configs to the WTP, which saves them at the
> > > time they are received. I do not believe anything else is required.
> > >
> > >
> > > 42) Configuration Update Response includes the Result Code message
> > > element, which includes values that do not appear to be relevant for
> > > this message, and there are plenty of other failure cases
> > >
> > > <PRC> ok, but note that we are sharing a common message element. Any
> > > 43) Change State Event Report. This seems a little silly to be sent in
> > >
> > > the "configure" state. It seems only appropriate for the "run" state.
> > > Some might argue that even in the "run" state it shouldn't be sent
> > > after
> > > a "config update" request that changes the operational state. However,
> > >
> > > in the "run" state, it may take a while to have the operational state
> > > change to follow the admin state. Thus, I think it is OK in the "run"
> > > 44) Clear Config Request. this operation has several problems, which
> > > include:
> > >    1) currently, the CAPWAP-01 spec says that this can only be done in
> > > the "run" state. This is silly. It should also be possible in the
> > > "configure" state.
> > > <PRC> I wonder why the AC would even consider clearing the WTP's state
> > >    2) the value of "manufacturing defaults" is not defined, and a poor
> > >
> > > term to use, since it implies that that each manufacturer can have
> > > different values. If so, then the AC will have no knowledge of the
> > > config on the WTP! The problem of "default config values" has already
> > > be
> > > mentioned above. After each config attribute has been defined with a
> > > default value, then the proper term would be "CAPWAP config defaults".
> > > <PRC> Yes, you've raised this point already, and I agree that it does
> > > need to be addressed.
> > >
> > >    3) This operation is not defined to have a response. This is
> > > broken,
> > > since any config change can fail. Also, it is not defined what happens
> > > next. Does this cause the WTP to reboot an start a "clean discovery"?
> > > 45) Image Data Request. Yes, there are actually three different "Image
> > > Data Request" messages. Which one is determined          by which of
> > > the
> > > three message elements is contained. This is completely silly! There
> > > should be three separate operations! Additionally, how does the WTP
> > > know
> > > which image to get? The AC should be making that decision.
> > >
> > > <PRC> I believe the WTP is the only device that knows what it's
> > > filename
> > > should be. Why would an AC vendor know about file naming conventions
> > > used by the WTP vendors? I believe your other issues are discussed in
> > > the next items.
> > >
> > >
> > > 46) Image Data Response. this is silly. This operation can fail! There
> > >
> > > needs to be message element that indicates the          result.
> > >
> > > <PRC> How so? This is only used to send firmware to the WTP. Not clear
> > > 47) Image Data Request. when starting over again at the WTP start
> > > state,
> > > the WTP shouldn't use the "normal" discovery process, but instead
> > > "fast
> > > track" a connection back to the AC that just downloaded the image.
> > > With
> > > a little more          work, we could probably figure out a way to
> > > reuse
> > > the old DTLS session.
> > >
> > > <PRC> To what gain? What is so expensive about the discovery, and what
> > > 48) opcode - if this is here, might as well also have a value that
> > > indicates last block of the image file, instead of looking at the
> > > block
> > > size.
> > >
> > > <PRC> But we're just changing for the sake of changing - the protocol
> > > works as-is.
> > >
> > >
> > > 49) since this operation does not have the block number as a
> > > parameter,
> > > the WTP must determine the block number via the CAPWAP message header
> > > sequence number.  NOTE: DTLS does not provide in-order delivery of
> > > packets. Also, this requires the WTP to remember state. This message
> > > element should be re-engineered to have the following subfields:
> > > [edited]
> > >
> > > <PRC> The control header includes a sequence number, and while we can
> > > change the current protocol to match your recommendations, the
> > > protocol
> > > 50) Image Data Response. this is silly. This operation can fail!  For
> > > example, the WTP can run out of space to store          the block, or
> > > there could be a failure in writing the block to storage. (Or as
> > > "Image
> > > Data Request"(9.1a) is presently specified, the checksum match could
> > > fail.) There needs to be message element that indicates the result.)
> > > Note: don't need a block number field, since request and responses are
> > > paired.
> > >
> > > <PRC> Beauty is in the eye of the beholder ;-). Seriously, the
> > > protocol
> > > 52) Image Data Response. This is silly. This operation can fail! There
> > > needs to be message element that indicates the          result.
> > >
> > > <PRC> See above comment.
> > >
> > > 53) Reset Request. ...
> > >
> > > <PRC> The comment is irrelevant now that Clear Config has changed.
> > >
> > >
> > > 54) Reset Response. this is silly. This operation can fail! There
> > > needs
> > > to be message element that indicates the          result.
> > >
> > > <PRC> I sense a trend. I will stop including these messages from now
> > > on.
> > >
> > >
> > > 55)Duplicate IPv4 Address. how often is this reported if the condition
> > > remains?
> > >
> > > <PRC> Only required once, I think, but we may want to include some
> > > text
> > > covering that.
> > >
> > >
> > > 57) Data Transfer Request. Nice to have - remove.
> > >
> > > <PRC> Disagree. Providing diagnostics capabilities is required.
> > >
> > >
> > > 58) Mobile Config Request. the actual details of how this works on
> > > both
> > > splitMAC and especially localMAC are not well specified. That is, only
> > > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
> > > to events that would cause an AC to send this message type. Also,
> > > there
> > > are restrictions on combinations of parameters that can be included in
> > > the message.
> > >
> > > <PRC> I wonder whether other folks agree that more details are
> > > required.
> > >
> > >
> > > 59) it doesn't say if one message can be used to update more than one
> > > STA. It should be able.
> > >
> > > <PRC> No, otherwise you end up with the problem of associating
> > > specific
> > > message elements with a given mobile. One mobile per request.
> > >
> > >
> > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
> > > this message element can be matched with a (4.4.8)Add Mobile message
> > > element?
> > >
> > > <PRC> I believe this is to your previous point, but the protocol
> > > assumes
> > > one mobile per request.
> > >
> > >
> > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC?
> > > If
> > > <PRC> Intended to be a way to push policies to the WTP to prioritize
> > > mobile traffic.
> > >
> > >
> > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is
> > > 802.11 specific needed to modify 802.11 WLANs? It seems like the
> > > existing "(8.4)Configuration Update Request" message could be used.
> > >
> > > 63) note here there are information elements to create, delete, and
> > > modify WLANs. However, for message type "(10.1)Mobile Config Request",
> > > there is only add and delete (and the "add" used to modify).
> > >
> > > <PRC> Correct. The protocol requires the AC to resend a new add with a
> > > different policy. No specific reason, but if this is deemed
> > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
> > > > From: David T. Perkins [mailto:[email-masked]]
> > > > Subject: [Capwap] A commentary on CAPWAP-01 operations
> > > >
> > > > HI,
> > > >
> > > > I've attached a long file that summarizes the operations in
> > > > CAPWAP-01.
> > > >
> > > > Enjoy,
> > > > /david t. perkins
> > > >