Subject: Re: [Capwap] Issue 182: Change State Event should instead beRadioAdmin State.

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 31 Aug 2006 16:26:53 -0700

Sujay, are you happy with the current agreement? can I assume this issue
is closed?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Friday, August 18, 2006 8:50 AM
> To: sujay; [email-masked]
> Subject: Re: [Capwap] Issue 182: Change State Event should 
> instead beRadioAdmin State.
> 
> I think it gets really ugly when we start mixing these schemes.
> 
> Remember that radio admin state is saved across reboots, so 
> the AC wants to represent to the network administrator the 
> fact that the radios have been permanently disabled. If the 
> operational state was used to communicate this to the AC, 
> then it would be very difficult for the AC to know whether 
> the configuration is permanent or not.
> 
> I would prefer we maintain strict usage of the message elements.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
> > -----Original Message-----
> > From: sujay [mailto:[email-masked]]
> > Sent: Thursday, August 17, 2006 10:58 PM
> > To: Pat Calhoun (pacalhou); [email-masked]
> > Subject: RE: [Capwap] Issue 182: Change State Event should 
> instead be 
> > RadioAdmin State.
> > 
> > Hi,
> > 
> > I would propose using Radio Operational State for the 
> purpose defined 
> > and not Radio Administrative State message element.
> > If the WTP has to communicate its previous saved config,  it could 
> > indicate it well enough using Radio Operational State element with; 
> > State-> En/Dis And Cause->Administratively Set.
> > This is more flexible, consider a case it was enabled 
> > administratively, saved, but due to some reason radio is 
> not up. Radio 
> > Op State TLV is better equipped to say this and more.
> > 
> > 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 10:46 PM
> > To: sujay; [email-masked]
> > Subject: RE: [Capwap] Issue 182: Change State Event should 
> instead be 
> > RadioAdmin State.
> > 
> > In re-reading the text, I would propose:
> > 
> >    The Radio Administrative State message element is used to 
> > communicate
> >    the state of the WTP, or 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 to ensure that AC has the WTP radio's current 
> administrative 
> > state
> >    settings. The value contains the following fields.</t>
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou)
> > > Sent: Thursday, August 17, 2006 10:12 AM
> > > To: sujay; [email-masked]
> > > Subject: Re: [Capwap] Issue 182: Change State Event should
> > instead be
> > > RadioAdmin State.
> > > 
> > > 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
> > > 
> > 
> _________________________________________________________________
> 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