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

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 4 Oct 2006 09:07:47 -0700

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