Subject: [Capwap] Proposed Text for issue 243: Radio Administative and Operational state

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 19 Feb 2007 16:46:58 -0800

As usual, Peter, you have pointed out an issue that does need to be
addressed. I apologize for taking so long in getting back to you, but
here is my proposed text.

First change is to modify the contents of the Radio Administrative State
attribute. You were correct that the Cause shouldn't have been there to
begin with.

<text>
4.5.30.  Radio Administrative State

   The radio administrative state message element is used to communicate
   the state of a particular radio.  The configuration of the Radio
   Administrative State is sent by the AC to change the state of the
   WTP, which saves the value to ensure its effect remains across WTP
   resets.  The WTP communicates this message element during the
   configuration phase, in the Configuration Status, to ensure that AC
   has the WTP radio's current administrative state settings.  The value
   contains the following fields.

         0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |  Admin State  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   30 for Administrative State

[...]
</text> 

The second change is in the description of the Radio Operational State.
The text was confusing, so I hope that the new text is simpler to
understand:
<text>
4.5.31.  Radio Operational State

   The Radio Operational State message element is sent by the WTP to the
   AC to communicate a radio's operational state.  This message element
   is included in the Configuration Update Response by the WTP if it was
   requested to change the state of its radio, via the Radio
   Administrative State, but was unable to comply to the request.
   Further, this message element is included in the Change State Event
   when a WTP's radio state was changed unexpectedly.  This could occur
   due to a hardware failure.  Note that the operational state setting
   is not saved on the WTP, and therefore does not remain across WTP
   resets.  The value contains two fields, as shown.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |     State     |     Cause     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

</text>

Then as you pointed out, the messages in which these two message
elements could be present was confusing, so here is the new text:
<text>
8.2.  Configuration Status
[...]
   The following message elements MUST be included in the Configuration
   Status message.
   o  Radio Administrative State, see Section 4.5.30
[...]

8.4.  Configuration Update Request
[...]
   One or more of the following message elements MAY be included in the
   Configuration Update message.

   o  Radio Administrative State, see Section 4.5.30
[...]

8.5.  Configuration Update Response
[...]
   The following message elements MAY be present in the Configuration
   Update Response message.

   o  Radio Operational State, see Section 4.5.31
[...]

8.6.  Change State Event Request
[...]
   The following message elements MUST be present in the Change State
   Event Request message.

   o  Radio Operational State, see Section 4.5.31
</text>

Finally, as you pointed, there was an inconsistency in how the base
protocol handled radio failures vs. the 802.11 binding. I have made the
necessary change to the 802.11 binding spec to ensure that the IEEE
802.11 WTP Radio Fail Alarm Indication message element is now present in
the Change State Event Request, and not the WTP Event Request.

<text>
5.11.  Change State Event Request

   The following IEEE 802.11 specific message elements MAY included in
   the CAPWAP Station Configuration Request message.

   o  IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
</text>

I believe this should address all of the comments you raised in issue
243. Let me know if you have any questions or comments

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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