Subject: [Capwap] FW: 802.11 Specific - no result code for WLAN config command

From: [email-masked]
Date: Tue, 7 Mar 2006 13:01:22 +0530

Hi,

   1.  I found that in the CAPWAP specification, the WLAN configuration
request sent from the AC to the WTP is acked
by the WLAN Configuration Response. This Message does not have any message
elements.
And I presume it is sent irrespective of success / failure of configuration.

 Can we have the Radio Id , WLAN ID and Success Code Message Elements (tlvs)
to be sent
as part of WLAN Configure Response ? ?If not, is there any other means of
finding out
if my WLAN Configuration (Add / Update / Delete ) succeeded or not?

 2. The WTP Radio Information that lists the Radio type and Id is part of
the Discovery Request.
It is not sent as part of any Message after that.
 But since the AC does not keep any state for a Discovery Request,
the AC does not remember it. I assume that without knowing the Radio type,
the AC would not be able to
configure the WTP. I suggest we add Radio Type TLV to the Configure Request,
to avoid this.

Thanks

Sujatha V

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

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

---

From: sujay <[email-masked]>
Date: Wed, 08 Mar 2006 12:41:04 +0530

Sujatha,
The first point you have mentioned could  be addressed thus;

Send WLAN Configuration reponse only when the operation is 
successful.Using the sequence number in the request packet you should be
able identify
which WLAN configuration request has failed and thus the Radio ID. WLAN
Id etc.

Second point;

(In the expired lwapp-03.txt this message was being sent in the Join
Request Message,
not so in the current.)

It could be handled in two ways;
1. the AC should not send the Discovery Response if it is unable to
configure the WTP
With its given WTP radio information, that automatically means the
ClientHello SHOULD
not be expected from the that non-supported WTP.

2. It could be added as a part of the 802.11 binding message, IEEE
802.11 WTP WLAN Radio Configuration,
message another "Radio Type". 

Any comments?

Regards,
Sujay

My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085
&t=h&hl=en

 Hi,

   1.  I found that in the CAPWAP specification, the WLAN configuration
request sent from the AC to the WTP is acked by the WLAN Configuration
Response. This Message does not have any message elements. And I presume
it is sent irrespective of success / failure of configuration.

 Can we have the Radio Id , WLAN ID and Success Code Message Elements
(tlvs) to be sent as part of WLAN Configure Response ? ?If not, is there
any other means of finding out if my WLAN Configuration (Add / Update /
Delete ) succeeded or not?

 2. The WTP Radio Information that lists the Radio type and Id is part
of the Discovery Request. It is not sent as part of any Message after
that.  But since the AC does not keep any state for a Discovery Request,
the AC does not remember it. I assume that without knowing the Radio
type, the AC would not be able to configure the WTP. I suggest we add
Radio Type TLV to the Configure Request, to avoid this.

Thanks

Sujatha V

---

From: [email-masked]
Date: Wed, 8 Mar 2006 14:59:51 +0530

Sujay
 Thanks a lot  for the response.

I am afraid I still find that point 1  cannot be addressed this way .
If  a WTP  does not send the Wlan configure response because the
Configuration
did not succeed , it would be
mis-construed by the AC , as channel failure to deliver the message after a
few retries.
I am saying this based on my reading of Run To Idle state transition
definition.

As a result, the NeighborDead Activities will start on the AC side. So I
think we will
need to send the response from the WTP irrespective of failure / success.
That is
why I thought we could have the success code TLV added to the WLAN Configure
response.
And just to make an implementation easy, I threw in Radio ID and WLAN ID
also ;-)

Regarding point no 2 , The Radio type cannot be binding specific , in fact
it may be the
one that decides the bindings to be used. So we need a plcae holder for it
in a non-Binding
specific area . Do I make sense ?

Thanks
Sujatha V

-----Original Message-----
From: sujay [mailto:[email-masked]]
Sent: Wednesday, March 08, 2006 12:41 PM
To: [email-masked]; [email-masked]
Subject: RE: [Capwap] FW: 802.11 Specific - no result code for WLAN
configcommand

Sujatha,

Second point;

Any comments?

Regards,
Sujay

My Location;

 Hi,

Thanks

Sujatha V

---

From: sujay <[email-masked]>
Date: Wed, 08 Mar 2006 16:27:04 +0530

Correct ,with the given protocol, yes it will be an issue of non
reception of an ack 
taken as channel down event.
Again you could avoid this for the Add WLAN messages, ie have an
exception.
Else as you suggest add a Status Code! Or a Vendor Specific element.
Then again there is no point of the Radio ID and WLAN ID as the message
sequence number
is intact.
Another way, I recall there was a thread on a "Get WLAN config" ,
message requirement.
It is being tracked at;
http://capwap.org/cgi-bin/roundup/CAPWAP/index Issue no 72.
This message  could be used for verification.

I would recomment both the Get WLAN message as well as the Result Code
Element in the response.
Still better to have a re-usable message type exclusively for Result
Code which 
could be used across.

Radio Type- if getting lost after Discovery Request, should be repeated
in 
the configure request message.
Which doesn't  make sense ! 

One solution is to store the context received in the Discovery Request
message
that again implies some changes in the SM .
Else avoid sending Discovery Response messages if the Radio cannot be
supported.

Request the authors to comment.

Regds,
Sujay
My Location;

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 3:00 PM
To: 'sujay'; [email-masked]
Subject: RE: [Capwap] FW: 802.11 Specific - no result code for WLAN
configcommand

Sujay

I am afraid I still find that point 1  cannot be addressed this way . If
a WTP  does not send the Wlan configure response because the
Configuration did not succeed , it would be mis-construed by the AC , as
channel failure to deliver the message after a few retries. I am saying
this based on my reading of Run To Idle state transition definition.

As a result, the NeighborDead Activities will start on the AC side. So I
think we will need to send the response from the WTP irrespective of
failure / success. That is why I thought we could have the success code
TLV added to the WLAN Configure response. And just to make an
implementation easy, I threw in Radio ID and WLAN ID also ;-)

Regarding point no 2 , The Radio type cannot be binding specific , in
fact it may be the one that decides the bindings to be used. So we need
a plcae holder for it in a non-Binding specific area . Do I make sense ?

Thanks
Sujatha V

-----Original Message-----
From: sujay [mailto:[email-masked]]
Sent: Wednesday, March 08, 2006 12:41 PM
To: [email-masked]; [email-masked]
Subject: RE: [Capwap] FW: 802.11 Specific - no result code for WLAN
configcommand

Sujatha,

Send WLAN Configuration reponse only when the operation is
successful.Using the sequence number in the request packet you should be
able identify which WLAN configuration request has failed and thus the
Radio ID. WLAN Id etc.

Second point;

(In the expired lwapp-03.txt this message was being sent in the Join
Request Message, not so in the current.)

It could be handled in two ways;
1. the AC should not send the Discovery Response if it is unable to
configure the WTP With its given WTP radio information, that
automatically means the ClientHello SHOULD not be expected from the that
non-supported WTP.

2. It could be added as a part of the 802.11 binding message, IEEE
802.11 WTP WLAN Radio Configuration, message another "Radio Type".

Any comments?

Regards,
Sujay

My Location;

 Hi,

Thanks

Sujatha V