Subject: Re: [Capwap] Proposed Resolution for Issue 204: More General wirelesssupport /was Re: suggestion for Issue # 204, "More general wireless support"

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

I agree with Dorothy's recommendations.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Wednesday, October 04, 2006 9:08 AM
	To: capwap
	Subject: [Capwap] Proposed Resolution for Issue 204: More
General wirelesssupport /was Re: suggestion for Issue # 204,"More
general wireless support"

	All,
	
	Issue 204 and proposed resolutions to its components are 
	listed below.
	
	Comments please.
	
	Thanks,
	
	Dorothy

------------------------------------------------------------------------
-------------------------------------------------
	
	1) 4.4.38.  WTP Radio Information
	
	Comment: As the section should be work for any wireless
implement, I suggest the 
	
	following value
	
	 should be moved to 802.11 binding. The value should be defined
by wireless 
	
	technology binding.
	
	      1 - 802.11b:  An IEEE 802.11b radio.

	      2 - 802.11a:  An IEEE 802.11a radio.
	
	      4 - 
	802.11g:  An IEEE 802.11g radio.
	
	      8 - 802.11n:  An IEEE 802.11n radio.
	
	Proposed Resolution: Move the "need to know" the 
	802.11 technology specific
	radio types to the 802.11 binding, modifying the WTP Radio
Information element
	as follows:
	
	IEEE 802.11 Radio Information
	
	   The IEEE 802.11 radio information message element is used to
communicate the
	
	   radio information for each IEEE 802.11 radio on the WTP.  The
Discovery Request message MUST
	   include one such message element per radio in the WTP.  The
Radio-
	   Type field is used by the AC to determine which 
	802.11 technology
	   specific binding is to be used with the WTP.
	
	   The value contains two fields, as shown.
	
	      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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	     |   Radio ID    |           Radio Type
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	
	     | Radio Type    |
	     +-+-+-+-+-+-+-+-+
	
	   Type:  38 for WTP Radio Information
	
	   Length:  5
	
	   Radio ID:  The Radio Identifier, which typically refers to an
	      interface index on the WTP

	   Radio Type:  The type of IEEE 802.11 radio present.  
	      The following values are supported:
	
	      1 - 802.11b:  An IEEE 802.11b radio.
	
	      2 - 802.11a:  An IEEE 802.11a radio.
	
	      4 - 
	802.11g:  An IEEE 802.11g radio.
	
	      8 - 802.11n:  An IEEE 802.11n radio.
	
	      0xOF - 802.11b, 802.11a, 802.11g and 802.11n:  The 4 radio
types
	         indicated are supported in the WTP.

------------------------------------------------------------------------
-------------------
	
	2) 11.9.18.  IEEE 802.11 Tx Power
	
	Comment: I think it could be moved to the section 4.4, as
channel and Tx power are 
	common parameters for RF management.
	
	Proposed Resolution: No change to the draft. Agree with the
commenter
	
	that TX power level is a common parameter for RF management;
however the
	IEEE 802.11 TX Power field values are defined as being the
values
	defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus
are not
	
	extensible to other bindings. Expect that each binding will
define
	values relative to its definitions.
	
------------------------------------------------------------------------
---
	3)  Add "WTP radio channel"

	Comment: As per 2), we could define a TLV to report current
channel (AP to AC) or to 
	
	configure channel (AC to AP).
	
	Now,. 11.9.12.  IEEE 802.11 OFDM Control and 11.9.5.  IEEE
802.11 Direct 
	
	Sequence Control
	
	has channel configuration information. 

	But I think that a specific TLV for it is better. By this way,
4.4 will provide

	more common parameter for any wireless technology.
	
	     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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	
	       |    Radio ID   |    Reserved   |        Current Channel
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	The commenter suggests the following:

	3)      Add "WTP RF Radio configuration" in the section 4.4 

	The Tx power, radio type, channel assignment and so on these
kind parameter are common for any kind wireless binding.

	I suggest CAPWAP define it in the base protocol part.

	Although the protocol already has "WTP Radio Information", while
Tx power these kind Info should not be sent 

	during discovery and join phase. So the separated "WTP RF Radio
configuration" is better.

	If keep them in one, which element will be mandatory in what
kind message should be suggested by protocol.

	The TLV of "WTP RF Radio configuration" will include radio ID,
radio type, Tx power, Channel, country code and so on. 

	For any binding, we use Wireless binding identifier to suggest
them.

	The "WTP RF Radio configuration" could be sent by bi-direction,
by this way, AC could configure WTP's RF parameter

	and know current configuration on the WTP radio.

	If this way, current "11.9.18.  IEEE 802.11 Tx Power", "11.9.12.
IEEE 802.11 OFDM Control "and "11.9.5.  

	IEEE 802.11 Direct Sequence Control" and so on will merely keep
the IEEE 802.11 related element.

	 Proposed Resolution: No change to the draft.  While there may
be common elements, it's not clear that the 
	CAPWAP base specification should take on the task of
extracting/unifying the common elements
	across wireless systems. 

	
------------------------------------------------------------------------
------------
	4) 11.9.24.  IEEE 802.11 WTP Radio Fail Alarm Indications
	
	Comment: I think it could be moved to the section 4.4, it could
be a common event for 
	
	any wireless technology.
	
	 Proposed Resolution: No change to the draft. Agree with the
commmenter
	that a fail alarm indication could be a common event for
	any wireless technology. Each radio technology may want to
	
	have additional information reported with the event however. Not
	sure there is sufficient benefit shown for a common defintiion
at this point.
	
------------------------------------------------------------------------
---------------
	
	5) 11.9.1.  IEEE 802.11 Add WLAN
	
	How about we rename "WLAN" as wireless service? By this way, we
could achieve 
	
	abstract while make it work
	
	for most wireless technology.

	If it is ok, we could define "add wireless service, delete
wireless service, 
	update wireless service" in the section 
	4.4.
	
	Any wireless technology could add its specific parameter in the
binding 
	
	section.

	The commenter suggests a solution:

	1)       Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless
service", and put it in the section 4.4

	The glossary "wireless service" will be more abstract than
"WLAN".

	Refer to current "IEEE 802.11 add WLAN" format, we could keep 

	Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel
mode

	these kinds common element (more element maybe put here). 

	While for any specific wireless binding could follow the
Wireless binding identifier.

	The Wireless binding identifier will identify what kinds binding
are using

	( Probably eventually managed by IANA)

	Proposed resolution: Close, no change to the draft.
	The IEEE 802.11 Add WLAN message element is 802.11 specific and
used
	together with several other message elements to define a WLAN
service.

	The intent of the comment seems to be to have the ability in the

	CAPWAP protocol to add a generic wireless service. It's not
clear that
	there are enough additional elements common to multiple wireless
	services to have a separate CAPWAP level element at this at this
time.

------------------------------------------------------------------------
--------
	6) 11.9.22.  IEEE 802.11 WTP Quality of Service
	
	As per 5), I think we could define "WTP Quality of Service"in
the section 
	4.4.
	
	Radio ID, Tag Packets and Queue Depth could be defined in the
"WTP Quality of 
	
	Service".
	
	While CWMin and so on could be defined in the IEEE 802.11 WTP
Quality of 
	
	Service.

	The commenter suggests the following solution:

	2) Rename "11.9.22.  IEEE 802.11 WTP Quality of Service" as
"WTP Quality of Service"

	Same idea, we could keep the radio ID, Tag Packets, Queue Depth
in the "WTP Quality of Service".

	For any binding, we use Wireless binding identifier to suggest
them.

	For Tag Packets, if IANA already have some kind assignment, it
will be great.

	Proposed resolution: Close, no change to the draft.
	The IEEE 802.11 WTP QOS message element is 802.11 specific and
is needed
	to convey the CWMin , CWMax and other very specific 802.11 data.

	The intent of the comment seems to be to have the ability in the

	CAPWAP protocol to include a "generic QOS" message element. It's
not clear that
	there are enough elements common to multiple wireless
	services to have a separate CAPWAP level element at this at this
time.
	There is at least 1 - the Tag packets type, which each binding
can inlcude if
	desired.

------------------------------------------------------------------------
----------------------------------------------------------

	7. Redefine "IEEE 802.11 Statistics" as  "WTP Statistics" in the
section 4.4 

	Comment: Most case, the wireless binding will be link layer
protocol, I think most the element in the "IEEE 802.11 Statistics" 

	could be put on the section 4.4, except the element like "RTS
Success Count" and so on.

	For any binding, we use Wireless binding identifier to suggest
them.

	Proposed resolution: No change to the draft. Agree with the
commenter
	that many of the statistics are common across wireless
technologies.
	However the IEEE 802.11 Statistics values are defined as being
the values
	defined in various IEEE 802.11 MIB variables and thus are not
extensible to
	other bindings. Expect that each binding will define values
relative to its definitions.

	On 9/28/06, young <[email-masked]> wrote: 

		Hi Pat and all,

		I used to raise issue #204, and here intend to give
solution.

		1)       Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add
wireless service", and put it in the section 4.4

		The glossary "wireless service" will be more abstract
than "WLAN".

		Refer to current "IEEE 802.11 add WLAN" format, we could
keep 

		Radio ID, service ID (rename "WLAN ID" to it), MAC Mode,
tunnel mode

		these kinds common element (more element maybe put
here). 

		While for any specific wireless binding could follow the
Wireless binding identifier.

		The Wireless binding identifier will identify what kinds
binding are using

		( Probably eventually managed by IANA)

		        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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		       |    Radio ID   |    WLAN ID    |        MAC Mode
| Tunnel Mode
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		       |             Wireless binding identifier
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

		       |         Type                  |
Length            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

		       |                          Value...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

		It is similar for "IEEE 802.11 deletes WLAN" and "IEEE
802.11 Update WLAN".

		2) Rename "11.9.22.  IEEE 802.11 WTP Quality of Service"
as  "WTP Quality of Service"

		Same idea, we could keep the radio ID, Tag Packets,
Queue Depth in the "WTP Quality of Service".

		For any binding, we use Wireless binding identifier to
suggest them.

		For Tag Packets, if IANA already have some kind
assignment, it will be great.

		3)      Add "WTP RF Radio configuration" in the section
4.4 

		The Tx power, radio type, channel assignment and so on
these kind parameter are common for any kind wireless binding.

		I suggest CAPWAP define it in the base protocol part.

		Although the protocol already has "WTP Radio
Information", while Tx power these kind Info should not be sent 

		during discovery and join phase. So the separated "WTP
RF Radio configuration" is better.

		If keep them in one, which element will be mandatory in
what kind message should be suggested by protocol.

		The TLV of "WTP RF Radio configuration" will include
radio ID, radio type, Tx power, Channel, country code and so on. 

		For any binding, we use Wireless binding identifier to
suggest them.

		The "WTP RF Radio configuration" could be sent by
bi-direction, by this way, AC could configure WTP's RF parameter

		and know current configuration on the WTP radio.

		If this way, current "11.9.18.  IEEE 802.11 Tx Power",
"11.9.12.  IEEE 802.11 OFDM Control "and "11.9.5.  

		IEEE 802.11 Direct Sequence Control" and so on will
merely keep the IEEE 802.11 related element.

		4)      Redefine "IEEE 802.11 Statistics" as  "WTP
Statistics" in the section 4.4 

		Most case, the wireless binding will be link layer
protocol, I think most the element in the "IEEE 802.11 Statistics" 

		could be put on the section 4.4, except the element like
"RTS Success Count" and so on.

		For any binding, we use Wireless binding identifier to
suggest them.

		Any way, I thought many TLV will change their location
as new CAPWAP will be divided into two parts.

		Cheers

		Richard  (Shiyang)

_________________________________________________________________
		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