Subject: RE: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 2 May 2006 13:37:47 -0700

These are not MIB elements, but actual information elements that are
contained in the MAC management frames. Or are you raising a different
point, which I believe is already captured in issue 18?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Philip Rakity [mailto:[email-masked]] 
> Sent: Tuesday, May 02, 2006 11:24 AM
> To: Dorothy Stanley
> Cc: Pat Calhoun (pacalhou); capwap
> Subject: Re: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11
> 
> 
> The information in the capwap messages that refer (indirectly to
> 802.11 mib elements) now be expressed in terms of this IE.  Eg DTIM,  
> 802.11 country codes etc.   Makes things much cleaner.
> 
> Philip
> 
> 
> On May 2, 2006, at 11:14 AM, Dorothy Stanley wrote:
> 
> > Hi Pat,
> >
> > . The inclusion of this message element MUST also
> > >    include the IEEE 802.11 Information Element message element,
> > >    containing the following 802.11 IEs:
> > >       Capability
> > >       WPA IE
> > >       RSN IE
> > >       EDCA Parameter Set IE
> > >       QoS Capability IE
> > >       WMM IE
> >
> > - should this be
> > MUST also include IEEE 802.11 Information Element message elements, 
> > containing...
> >
> > Otherwise, looks good.
> >
> > Dorothy
> >
> > On 5/1/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: All,
> >
> > I've been thinking about my earlier proposed change for 
> issue 101 and 
> > would like to change the new Information Element data structure to 
> > include flags. See below.
> >
> > 11.8.1.4.  IEEE 802.11 Information Element
> >
> >   The IEEE 802.11 Information Element is used to communicate any IE
> >   defined in the IEEE 802.11 protocol.  The data field contains the 
> > raw
> >   IE as it would be included within an IEEE 802.11 MAC management
> >   message.
> >
> >        0                   1
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> >       |B|P|   Flags   | Info Element
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> >
> >   Type:  TBD for IEEE 802.11 Information Element
> >
> >   Length:  >= 2
> >
> >   B:  When set, the WTP is to include the information element in
> >      beacons associated with the WLAN.
> >
> >   P:  When set, the WTP is to include the information 
> element in probe
> >      responses associated with the WLAN.
> >
> >   Flags:  Reserved field and MUST be set to zero.
> >
> >   Info Element:  The IEEE 802.11 Information Element, which includes
> >      the type, length and value field.
> >
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou)
> > > Sent: Friday, April 28, 2006 11:49 AM
> > > To: Puneet; [email-masked]
> > > Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use
> > > 802.11 Informationelement definitions
> > >
> > > I believe there are many issues in issue 101, some of which were
> > > introduced by Dorothy. I believe that my proposal
> > > (below) covers all sections. Comments most welcomed!
> > >
> > >       1. does the encryption policy refer to broadcast traffic or
> > unicast
> > > too? If its also unicast, then there could be multiple encryption
> > > types enabled at the same type on the WLAN, in that case 
> how is the
> > > encryption-policy field filled in?
> > >
> > > <PRC>
> > > This is a good question as the text is obviously not 
> clear enough. I
> > > am proposing the following text (as well as for the Update WLAN
> > > section):
> > >
> > >    Encryption Policy:  A 32-bit value specifying the encryption  
> > scheme
> > >       to apply to traffic to and from the mobile station.  The
> > >       applicability of the encryption policy depends upon the  
> > security
> > >       policy.  For static WEP keys, which is true when the 'Shared
> > > Key'
> > >       bit is set, this encryption policy is relevant for both  
> > unicast
> > >       and multicast traffic.  For encryption schemes that employ a
> > >       separate encryption key for unicast and multicast 
> traffic, the
> > >       encryption policy defined here only applies to 
> multicast data.
> > > In
> > >       these scenarios, the unicast encryption policy is 
> communicated
> > > via
> > >       the Add Mobile (Section 9.1.1 ).
> > > [...]
> > >    Shared Key:  A 1 byte boolean that specifies whether the key
> > > included
> > >       in the Key field is a shared WEP key.  When set to 
> one, the  
> > WLAN
> > >       employs a shared WEP key, also known as a static 
> WEP key, and
> > > uses
> > >       the encryption key for both unicast and multicast 
> traffic for
> > > all
> > >       stations.  A value of zero, with the 'Encryption 
> Policy' field
> > > set
> > >       to any value other than 'Clear Text' means that the 
> WLAN uses
> > > per-
> > >       station encryption keys, and therefore the key in the 'Key'
> > > field
> > >       is only used for multicast traffic.
> > > </PRC>
> > >
> > >       2. for the encryption policies we could use the 
> format used in
> > the
> > > RSN IEs (OUI + encryption_type); that allows support for different
> > > vendor specific encryption types in a clean manner (CKIP 
> for example
> > > would then use the Cisco OUI, instead of being clubbed 
> together with
> > > the other 'standard'
> > > encryption types; and it makes it easier for vendors to 
> not step on
> > > each others toes).
> > >
> > > <PRC>
> > > Based on Dorothy's e-mail and recommendation, I would propose the
> > > following new section:
> > >
> > > 11.8.1.4.  IEEE 802.11 Information Element
> > >
> > >    The IEEE 802.11 Information Element is used to 
> communicate any IE
> > >    defined in the IEEE 802.11 protocol.  The data field 
> contains the
> > > raw
> > >    IE as it would be included within an IEEE 802.11 MAC management
> > >    message.
> > >
> > >       0
> > >       0 1 2 3 4 5 6 7
> > >      +-+-+-+-+-+-+-+-
> > >      | Info Element
> > >      +-+-+-+-+-+-+-+-
> > >
> > >    Type:  TBD for IEEE 802.11 Information Element
> > >
> > >    Length:  >= 1
> > >
> > >    Info Element:  The IEEE 802.11 Information Element, which  
> > includes
> > >       the type, length and value field.
> > >
> > > However, I do not believe that everything can be moved out at this
> > > point. So I would propose changing the Add WLAN to be the 
> following:
> > >
> > > 11.8.1.1.  IEEE 802.11 Add WLAN
> > >
> > >    The Add WLAN message element is used by the AC to define a  
> > wireless
> > >    LAN on the WTP.  The inclusion of this message element 
> MUST also
> > >    include the IEEE 802.11 Information Element message element,
> > >    containing the following 802.11 IEs:
> > >       Capability
> > >       WPA IE
> > >       RSN IE
> > >       EDCA Parameter Set IE
> > >       QoS Capability IE
> > >       WMM IE
> > >
> > >    The value contains the following format:
> > >
> > >         0                   1                    
> > 2                   3
> > >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> > > 7 8 9 0 1
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |    Radio ID   |    WLAN ID    |            Reserved
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                      Encryption Policy
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |                               Key
> > >          |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |   Key Index   |   Shared Key  |      QoS      |
> > > Auth Type   |
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >        |   MAC Mode    |  Tunnel Mode  | Suppress SSID |  
>   SSID ...
> > >
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > </PRC>
> > >
> > >       3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32
> > bytes?
> > > If each of those IEs is preceded by an element that 
> specifies their
> > > lengths, then the IEs could be made variable length.
> > >
> > > <PRC> Thanks, that has been fixed</PRC>
> > >
> > >       4. Does the 'Suppress SSID' field also disable the 
> use of that
> > SSID
> > > in broadcast probe responses? If so, why do we also need the 'IEEE
> > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is  
> > this IE
> > > global for the WTP? The AC might configure the WTP with 
> 10 WLANs,  
> > but
> > > it may want probe responses generated for only four of 
> those when a
> > > broadcast probe request comes in.
> > >
> > > <PRC> Section 11.9.12 deals with the changing of the mode of  
> > operation
> >
> > > after the WLAN is already operational.</PRC>
> > >
> > >       5. maybe rename WME to WMM?
> > >
> > > <PRC> No longer relevant </PRC>
> > >
> > > 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
> 
> Philip Rakity
> [email-masked]
> 
> 
> This message is hereby marked U4EA CONFIDENTIAL, is intended 
> only for  
> the use of the individual or individuals to which it is 
> addressed and  
> shall notbe disclose or made available to any other party 
> except with  
> the prior written consent of the sender. If the reader of this  
> message is not the intended recipient, you are hereby notified that  
> any dissemination, distribution or copying of this message is  
> strictly prohibited. If you have received this communication in  
> error, please notify us immediately by replying to the sender 
> of this  
> E-Mail.
> 
> 
> 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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