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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 17 Aug 2006 10:11:49 -0700

Sujay,

I'm ok with all of your change requests, with the exception of the
following.

> 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.<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.

Actually, this comment is invalid. The WTP indicates its current radio
administrative state during the config phase to the AC. I will add text
to make this clearer.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: sujay [mailto:[email-masked]] 
> Sent: Wednesday, August 16, 2006 11:29 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Issue 182: Change State Event should 
> instead be Radio Admin State.
> 
> 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.72485
2,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.
> 
> 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.<SUJ>The value 0xFF is invalid as it 
> does not indicate
>      any specific radio.</SUJ>
> 
>    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.<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
>       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.
> 
> 
> <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>
> 
>    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.
> <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.
> 
>    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.
> <SUJ>
> I completely agree with Pat's above point...!
> 
> 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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