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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 1 May 2006 22:55:43 -0700

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 2 May 2006 11:14:04 -0700

Hi Pat,

. The inclusion of this message element MUST also
>    containing the following 802.11 IEs:

- should this be
MUST also include IEEE 802.11 Information Element message elements,
containing...

Otherwise, looks good.

Dorothy

---

From: Philip Rakity <[email-masked]>
Date: Tue, 2 May 2006 11:24:14 -0700

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:

> On 5/1/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: All,
>
> >       the Add Mobile (Section 9.1.1 ).
> > [...]
> 2                   3

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.