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

From: young <[email-masked]>
Date: Fri, 06 Oct 2006 11:52:50 +0530

Hi, Dorothy:
Thanks for your proposed resolutions.

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 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.
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".

Regards
Richard (shiyang)

From: Dorothy Stanley (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)

_________________________________________________________________
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: Fri, 6 Oct 2006 10:36:31 -0700

Richard,

Notes inline.

Thanks,

Dorothy

> Thanks for your proposed resolutions.

You're welcome.

> 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 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.

> I suggest we could define a "WTP Radio configuration" TLV.
> suggest that "WTP Radio configuration"

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