Subject: [Capwap] RE: some suggestion for 802.11 binding TLV (Dorothy Stanley)

From: young <[email-masked]>
Date: Thu, 27 Apr 2006 21:14:47 +0530

Dear All:

I give more detailed suggestion about the following requirement:

1) New TLV "reset IEEE 802.11 Statistics"

a) Why we need it?

Now, the draft defines "IEEE 802.11 Statistics" to report Multicast Tx
Count, Multiple Retry Count and so on. As AP keep updating the statistic
value, after some time, the statistic value will become very great, and it
could not reflect the real state of network. So administrator need a method
to reset IEEE 802.11 Statistics"

b) The TLV could be carried in the "Configure Update request"

c) The TLV format is as follow:

      0 1 2 3 4 5 6 7

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

     |   Radio ID   |

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

   When AP side get radio id from TLV, it will reset the radio as per radio
ID.

d) Other suggestion:

Whether it needs a "Reset interval" element? By this way, user could
configure after how many time (seconds) AP will reset Statistics for a
specific radio.

2) New TLV "Preamble-length"

a) Why we need it?

"Preamble-length" is basic configuration for most vendor's AP product. As
CAPWAP will provide 802.11 binding element, it should support the common
802.11 configuration that most vendor support.

b) The TLV could be carried in the "Configure Update request, configure
request, configure response"

c) The TLV format 

The CAPWAP already has TLV IEEE 802.11 MAC operation, and we could add one
more element named "Preamble-length". The value for it could be:

      1 - short (default)

      2 - long

3) Issues 107

Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP,
while "Supress SSID (section 11.8.1)" is for specific radio.

I suggest we could delete "IEEE 802.11 Broadcast Probe Mode" TLV, and move
this TLV element to "IEEE 802.11 Add WLAN" TLV.

Regards

Richard

-----Original Message----- 

Message: 2

Date: Thu, 20 Apr 2006 09:03:27 -0700

From: "Dorothy Stanley" <[email-masked]>

Subject: Re: [Capwap] some suggestion for 802.11 binding TLV

To: young <[email-masked]>

Cc: [email-masked]

Message-ID:

     <[email-masked]>

Content-Type: text/plain; charset="iso-8859-1"

Richard,

Status and comments inline below.

Thanks,

Dorothy

On 4/19/06, young <[email-masked]> wrote:

>  Dear all:

> I have some suggestion about CAPWAP draft, please kindly discuss it.

> 1) For IEEE 802.11 Statistics

> I suggest we should add new TLV for "reset IEEE 802.11 Statistics"

Issue 105 has been opened for item (1).

Can you provide suggested text for a description of the proposed TLV?  This

will enable a more informed discussion, and

give insight into the problem that is being solved.

Is this a boolean, which when set causes the WTP to reset all of its

statistics collection counters?

Is it included in the statistics message element? A new message element?  In

which message elements and messages would it be included?

2) Because CAPWAP provide the definition of 802.11 binding, the common

> configuration for AP came from different vendors should defined by draft.
I

> felt something like "Preamble-length" configuration need to be added into

> draft.

Issue 106 has been opened for item (2)

Where would you add "pre-amble length"? In the WTP Radio information?

Is this info provided by the WTP to the AC on what is supported?

3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP,

> while Supress SSID (section 11.8.1) is for specific radio.

> I suggest both Broadcast Probe Mode and Supress SSID could be configured

> for a specific radio.

Issue 107 has been opened for item (3).

Regards

> Richard

> _________________________________________________________________

> To unsubscribe or modify your subscription options, please visit:

> http://lists.frascone.com/mailman/listinfo/capwap

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

-------------- next part --------------

An HTML attachment was scrubbed...

URL:
http://lists.tigertech.net/pipermail/capwap/attachments/20060420/2259b68b/at
tachment.htm

> _________________________________________________________________

> To unsubscribe or modify your subscription options, please visit:

> http://lists.frascone.com/mailman/listinfo/capwap

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

-------------- next part --------------

An HTML attachment was scrubbed...

URL:
http://lists.tigertech.net/pipermail/capwap/attachments/20060420/841ac68d/at
tachment.htm

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

Message: 4

Date: Thu, 20 Apr 2006 10:17:25 -0700

From: Puneet <[email-masked]>

Subject: Re: [Capwap] 802.11d / 802.11h support

To: "Partha Narasimhan" <[email-masked]>

Cc: [email-masked]

Message-ID:

     <[email-masked]>

Content-Type: text/plain; charset="iso-8859-1"

Partha,

for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE

is what will finally go out in the beacons/probe-responses. No need for the

WTP to have to translate and construct that IE.

for #2 it might be simpler if the WTP reports radar to the AC, and the AC

makes the decision about what channel to jump to. As David also mentions,

the channel to move to might be determined by policy or by some

channel-selection logic on the AC which takes into account neighbouring

channels etc. A 'future' channel can either be provided to the WTP at

configuration time (if the timing constraints seem so tight), or as soon as

it reports radar.

Thanks,

Puneet

On 4/18/06, Partha Narasimhan <[email-masked]> wrote:

> For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need

> to re-define something that is already defined in 802.11? This is probably

> true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a

> corresponding 802.11 definition. There is code that exists to parse 802.11

> IEs elsewhere in the WTP, so we get code reuse too. :-)

> For #2, my vote would be for the WTP to switch channels on detecting radar

> and notify the AC of the radar detect and the resulting channel change

> events. This keeps it simple and WTPs have the ability to detect radar

> already.

> Thanks

> partha

> On Tue, 18 Apr 2006, Dorothy Stanley wrote:

> > Hi Puneet,

> > This is assigned to a new issue, 104.

> > All- comments, discussion please.

> > Thanks,

> > Dorothy Stanley

> > On 4/14/06, Puneet <[email-masked]> wrote:

> >       1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The

> length of this element is fixed at 8 bytes, but if there are multiple,

> disjoint bands that are supported in the regulatory domain does the AC use

> multiple such elements? It might be cleaner to make the length of this

> element variable, and allow multiple triplets

> <first_channel,num_channel,max_power) to be added one after the other.
(like

> the Country-Information element in 802.11d)

> >       2. How does CAPWAP plan to support 802.11h? Does the WTP handle

> everything on its own or is the channel switching etc controlled by the
AC?

> In either case there might be a need for message elements with which the
WTP

> to report the detection of radar to the AC.

> >       Thanks,

> >       Puneet.

> >       _________________________________________________________________

> >       To unsubscribe or modify your subscription options, please visit:

> >       http://lists.frascone.com/mailman/listinfo/capwap <

> http://lists.frascone.com/mailman/listinfo/capwap>

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

-------------- next part --------------

An HTML attachment was scrubbed...

URL:
http://lists.tigertech.net/pipermail/capwap/attachments/20060420/63cc621b/at
tachment.htm

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

_________________________________________________________________

To unsubscribe or modify your subscription options, please visit:

http://lists.frascone.com/mailman/listinfo/capwap

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

End of Capwap Digest, Vol 6, Issue 47

*************************************

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

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