Subject: [Capwap] Issue 182: Change State Event should instead be Radio Admin State.

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 16 Aug 2006 17:45:19 -0700

This issue really contains two parts:

33) Use of Change State Event should instead be Radio Admin State.
No. However, I do agree that there is some confusion around the
difference
between both. So I am proposing two things; add clarification language
to
both message elements, and rename the Change State Event message element
to
instead be called Radio Operational State.

Note that the primary difference between both is that the Radio Admin
State
is saved on the WTP, and therefore takes effect across reboots. The
operational
state does not.

<revised text>
4.4.11.  Radio Operational State

   The Radio Operational State message element is sent by the WTP to the
   AC to communicate a change in the operational state of a radio.  For
   instance, if the WTP were to detect that a hardware failure existed
   with a radio, which caused the radio to be taken offline, the WTP
   would indicate this event to the AC via the message element.  The AC
   MAY also send this message element to change the operational state of
   a specific radio.  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     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   11 for Radio Operational State

   Length:   3

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP.

   State:   An 8-bit boolean value representing the state of the radio.
      A value of one disables the radio, while a value of two enables
      it.

   Cause:   In the event of a radio being inoperable, the cause field
      would contain the reason the radio is out of service.  The
      following values are supported:

      0 -  Normal
      1 -  Radio Failure
      2 -  Software Failure
      3 -  Administratively Set

4.4.28.  Radio Administrative State

   The Radio Administrative State message element is used to communicate
   the state the WTP, or of a particular radio.  The configuration of
   the Radio Administrative State is saved on the WTP, and its effect
   remains across WTP resets.  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:   28 for Radio Administrative State

   Length:   2

   Radio ID:   An 8-bit value representing the radio to configure.  The
      Radio ID field may also include the value of 0xff, which is used
      to identify the WTP itself.  Therefore, if an AC wishes to change
      the administrative state of a WTP, it would include 0xff in the
      Radio ID field.

   Admin State:   An 8-bit value representing the administrative state
      of the radio.  The following values are supported:
      1 -  Enabled
      2 -  Disabled

8.6.  Change State Event Request

   The Change State Event Request message is used by the WTP to inform
   the AC of a change in the operational state.

   The Change State Event Request message is sent by the WTP when it
   receives a Configuration Response message that includes a Change
   State Event message element.  It is also sent when the WTP detects an
   operational failure with a radio.  The Change State Event Request
   message may be sent in either the Configure or Run state (see
   Section 2.3.

   When an AC receives a Change State Event message it will respond with
   a Change State Event Response message and make any necessary
   modifications to internal WTP data structures.

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

   o  Radio Operational State message element, see Section 4.4.11

8.7.  Change State Event Response

   The Change State Event Response message acknowledges the Change State
   Event Request message.

   A Change State Event Response message is by a WTP after receiving a
   Change State Event Request message.

   The Change State Event Response message carries no message elements.
   Its purpose is to acknowledge the receipt of the Change State Event
   Request message.

   The WTP does not need to perform any special processing of the Change
   State Event Response message.

</revised text>

43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I disagree. Once the config exchanges have occurred, the WTP needs
to
configure its radios, and then send an update to the AC when this is
done.
This message is used to inform the AC of the final state of the radios
on
the WTP. I therefore believe that the state machine is fine as is as it 
provides a nice transition between unconfigured and configured.

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

---

From: sujay <[email-masked]>
Date: Thu, 17 Aug 2006 11:58:54 +0530

Hi Pat,
You did address some of my concerns.
I have some comments inline.

The other changes suits me.
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h
&hl=en

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it! 
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 6:15 AM
To: [email-masked]
Subject: [Capwap] Issue 182: Change State Event should instead be Radio
Admin State.

33) Use of Change State Event should instead be Radio Admin State.
No. However, I do agree that there is some confusion around the difference
between both. So I am proposing two things; add clarification language to
both message elements, and rename the Change State Event message element to
instead be called Radio Operational State.

Note that the primary difference between both is that the Radio Admin State
is saved on the WTP, and therefore takes effect across reboots. The
operational state does not.

<revised text>

      0                   1                   2

   Length:   3

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP.<SUJ>The value 0xFF is invalid as it does not
indicate
     any specific radio.</SUJ>

      0 -  Normal
      1 -  Radio Failure
      2 -  Software Failure
      3 -  Administratively Set

   The Radio Administrative State message element is used to communicate
   the state the WTP, or of a particular radio.<SUJ> It is sent from the AC
to the 
   WTP </SUJ>   The configuration of
   the Radio Administrative State is saved on the WTP, and its effect
   remains across WTP resets.  The value contains the following fields.

      0                   1

   Length:   2

<SUJ>
Change above para to;
"
   The Change State Event Request message MUST be sent by the WTP when it
   receives a Configuration Status Response  message which includes a  Radio
Administrative State message element.
    It is also sent when the WTP detects an operational failure with a
radio.  The Change State Event Request
   message may be sent in either the Configure or Run state (see   Section
2.3.). 
"
- the "MUST" is needed as it helps the state machine transition.
</SUJ>

   A Change State Event Response message is by a WTP after receiving a
   Change State Event Request message.
<SUJ>
For above para;
   A Change State Event Response message is received by a WTP after sending
  the  Change State Event Request message.
</SUJ>
   The Change State Event Response message carries no message elements.
   Its purpose is to acknowledge the receipt of the Change State Event
   Request message.

</revised text>

43) Change State Event Report. This seems a little silly to be sent in the
"configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after a
"config update" request that changes the operational state. However, in the
"run" state, it may take a while to have the operational state change to
follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I disagree. Once the config exchanges have occurred, the WTP needs to
configure its radios, and then send an update to the AC when this is done.
This message is used to inform the AC of the final state of the radios on
the WTP. I therefore believe that the state machine is fine as is as it
provides a nice transition between unconfigured and configured.
<SUJ>
I completely agree with Pat's above point...!

Pat Calhoun