Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components

From: young <[email-masked]>
Date: Sat, 07 Oct 2006 10:23:30 +0530

Dorothy:

Thanks for your comment, it is fine.

Just as you mentioned, WG needs to clarify on the base vs binding
division of labor. Anyway, a clear rule and scope of base protocol should be
there.

Till then, I think discussion on each TLV in detail will be more meaningful.

I thought the scope of CAPWAP base protocol will be two way alternative:

1) Take effort on the control and data tunnel, tunnel related TLV is focus. 

No any wireless related element like Tx power, Channel, wlan and so on.

2) Based on 1), more abstract wireless element put in the base protocol.

For example, radio, Tx power, channel and so on. Also, give a way to
identify 

each wireless binding of 802.11, RFID and so on.

Whether putting TLV in base or wireless binding just follow the rule made 

by WG or mailing list is ok.

Regards

Richard (shiyang)

From: Dorothy Stanley (dstanley1389gmail.com) 

Date: Fri, 6 Oct 2006 10:36:38 -0700 (PDT) 

Richard, 

Notes inline. 

Thanks, 

Dorothy

On 10/5/06, young <young <mailto:young%20%5bat%5d%20huawei-3com.com>  [at]
huawei-3com.com> wrote: 

Hi, Dorothy:
Thanks for your proposed resolutions. 

You're welcome.

In your Proposed Resolution, you mentioned that " 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."
If it is not clear, I suggest that WG or mailing list had better take time 
to make it clear.
Otherwise, how to decide what info should put in the base part if base part
scope is not clear?
I thought a clear and common understanding of base part's rule and scope is
very important for 
base part separation from wireless specific binding.

I completely agree that the WG needs to clarify on the base vs binding
division of labor.
The current draft, with the exception (largely) of  the WTP Radio
information element, puts the 
wireless-technology specific elements in the binding rather than the base
protocol. This is
the approach I followed in developing the proposed resolutions. 
Most of the CAPWAP level message elements are used to establish and manage
the
session between the AC and WTP.  Some message elements, for example
 the WTP radio statistics and Decryption Error Report are borderline and
could arguably
move to the binding; but they are not technology specific - e.g. 802.11 vs
802.16.

I give my comment for the proposed resolutions to issue 204.
1) 4.4.38.  WTP Radio Information 
Sorry for I don't make issue clear in my comment.
I suggest that WTP Radio Information could be kept in the current section
4.4.
While 802.11a/b/g/n these kinds info could be defined by 802.11binding.
We could add a Wireless binding identifier in the WTP Radio Information. 
By this way, we could identify any Wireless binding's radio type definition.
The Wireless binding identifier could be probably eventually managed by
IANA.
No matter what method will by used for Wireless binding identifier, it is a 
key
Point to help base protocol to separate any wireless binding.
I thought that Wireless binding identifier method will be a common issue.

I considered several options on this one. 
(a) Have both a CAPWAP
base element that included the "first level" radio information: 802.11,
802.15,
802.16, 802.22, EPCGlobal, etc, AND specific binding elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first
levels churn internally, the base spec isn't impacted. But if the detailed
level
is provided, is the higher level even needed?

(b) Have  only binding-specific  elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. 
The binding will need to specify that the element must be included in the
control messages that the previous CAPWAP level element was in.

(c) keeping the definition as is. Didn't do this, since the change
did make the CAPWAP base spec even more wireless-technology agnostic.

The WTP Radio information message element includes only 2 fields, the
radio type and the radio information. If we want radio specific info in the
base spec, then we can leave it there, and add the 802.11,15,16,etc values -
and
require that the capwap base spec change as new values are added, or we can
move the radio-type info to the binding, and then as the wireless technology
evolves, only the binding doc has to change.  

2) 11.9.18.  IEEE 802.11 Tx Power
I suggest we could define a "WTP Radio configuration" TLV. 
By using wireless binding identifier, there will be no conflict with
Dot11PhyTxPowerEntry MIB table.
Channel also could be put here.
As AC will configure AP's RF parameter (AC to AP), and AP will report its
current
Configuration to AC, the TLV will be carried in the configuration message in
bi-direction.
More TLV could be added into the TLV if it is required.
|---------|-------------|-----------------------------|--------------|------

---|---------|
| Radio ID| country code| wireless binding identifier | Max Tx Power |Tx
Power | Channel  |
|---------|-------------|-----------------------------|--------------|------
-- |----------|
As Tx power these kind info will not be carried in the discovery phase, I 
suggest that "WTP Radio configuration"
is required instead of extenuation of " WTP Radio Information".

Ok, so the proposal is to have a new base-spec-level message element,
that incorporates a binding-defined-identifier for Radio Configuration.
This would require the TX power fields to have the same units across
wireless types. This level of configuration is currenly in the binding and
my preference would be to leave it there. 

Regards
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

---

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

Again agree with Dorothy.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Friday, October 06, 2006 10:37 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [Capwap] Issue 204 and proposed resolutions to its
components

	Richard, 
	
	Notes inline. 
	
	Thanks, 
	
	Dorothy

	On 10/5/06, young <[email-masked]> wrote: 

		Hi, Dorothy:

	You're welcome.

		In your Proposed Resolution, you mentioned that " 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."
		If it is not clear, I suggest that WG or mailing list
had better take time 
		to make it clear.
		Otherwise, how to decide what info should put in the
base part if base part
		scope is not clear?
		I thought a clear and common understanding of base
part's rule and scope is
		very important for 
		base part separation from wireless specific binding.

	I completely agree that the WG needs to clarify on the base vs
binding
	division of labor.
	The current draft, with the exception (largely) of  the WTP
Radio information element, puts the 
	wireless-technology specific elements in the binding rather than
the base protocol. This is
	the approach I followed in developing the proposed resolutions. 
	Most of the CAPWAP level message elements are used to establish
and manage the
	session between the AC and WTP.  Some message elements, for
example
	 the WTP radio statistics and Decryption Error Report are
borderline and could arguably
	move to the binding; but they are not technology specific - e.g.
802.11 vs 802.16.

		I give my comment for the proposed resolutions to issue
204.
		1) 4.4.38.  WTP Radio Information 
		Sorry for I don't make issue clear in my comment.
		I suggest that WTP Radio Information could be kept in
the current section
		4.4.
		While 802.11a/b/g/n these kinds info could be defined by
802.11binding.
		We could add a Wireless binding identifier in the WTP
Radio Information. 
		By this way, we could identify any Wireless binding's
radio type definition.
		The Wireless binding identifier could be probably
eventually managed by
		IANA.
		No matter what method will by used for Wireless binding
identifier, it is a 
		key
		Point to help base protocol to separate any wireless
binding.
		I thought that Wireless binding identifier method will
be a common issue.

	I considered several options on this one. 
	(a) Have both a CAPWAP
	base element that included the "first level" radio information:
802.11, 802.15,
	802.16, 802.22, EPCGlobal, etc, AND specific binding elements
that
	specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus
as the first
	levels churn internally, the base spec isn't impacted. But if
the detailed level
	is provided, is the higher level even needed?
	
	(b) Have  only binding-specific  elements that
	specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. 
	The binding will need to specify that the element must be
included in the
	control messages that the previous CAPWAP level element was in.
	
	(c) keeping the definition as is. Didn't do this, since the
change
	did make the CAPWAP base spec even more wireless-technology
agnostic.
	
	The WTP Radio information message element includes only 2
fields, the
	radio type and the radio information. If we want radio specific
info in the
	base spec, then we can leave it there, and add the
802.11,15,16,etc values - and
	require that the capwap base spec change as new values are
added, or we can
	move the radio-type info to the binding, and then as the
wireless technology
	evolves, only the binding doc has to change.  

		2) 11.9.18.  IEEE 802.11 Tx Power
		I suggest we could define a "WTP Radio configuration"
TLV. 
		By using wireless binding identifier, there will be no
conflict with
		Dot11PhyTxPowerEntry MIB table.
		Channel also could be put here.
		As AC will configure AP's RF parameter (AC to AP), and
AP will report its
		current
		Configuration to AC, the TLV will be carried in the
configuration message in
		bi-direction.
		More TLV could be added into the TLV if it is required.
	
|---------|-------------|-----------------------------|--------------|--
---- 
		---|---------|
		| Radio ID| country code| wireless binding identifier |
Max Tx Power |Tx
		Power | Channel  |
	
|---------|-------------|-----------------------------|--------------|--
----
		-- |----------|
		As Tx power these kind info will not be carried in the
discovery phase, I 
		suggest that "WTP Radio configuration"
		is required instead of extenuation of " WTP Radio
Information".

	Ok, so the proposal is to have a new base-spec-level message
element,
	that incorporates a binding-defined-identifier for Radio
Configuration.
	This would require the TX power fields to have the same units
across
	wireless types. This level of configuration is currenly in the
binding and
	my preference would be to leave it there. 

		Regards
		Richard (shiyang)

		From: Dorothy Stanley ( dstanley1389gmail.com
<http://dstanley1389gmail.com> )
		Date: Wed, 4 Oct 2006 09:08:21 -0700 (PDT)
		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 <young [at] huawei-3com.com> 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)