1. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 1 Introducing 11r-d0.00 Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-06-02 Authors:

2. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 2 Abstract D0.00: Initial draft of P802.11r, created from 11-05-0362-01

3. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 3 P802.11r-D0.00 Generated from 11-05-0362-01 For now, ignore the Table of Contents For now, ignore all the blank pages at end Note the “NOTE”s

4. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 4 Section mapping, part 1 2.1 BackgroundIntroduction in “frontmatter” 2.2 Definitions3-Definitions and 4-Acronyms 2.3 Architecture5.4.5 (new section) BSS-Transition Services 3 Overview8A.1 (new section) Fast BSS Transition 4.1 Frame Formats - Authentication7.2.3.10 Authentication frame format 4.1.1 FT Auth frame sequence8.5A.9 FT Auth frame sequence 4.2.1 Reassociation Request7.2.3.6 Reassociation Request 4.2.2 Reassociation Response7.2.3.7 Reassociation Response 4.3 FBT Action Frame7.3.1.11 Action field 4.3.1 FBT Action Frame details7.4.3 Action frame details 4.4.1 Count IE7.3.2.38 Count IE 4.4.2 Status codes7.3.1.9 Status code field 4.4.3 Fast Transition Resource IE7.3.2.39 Fast Transition Resource IE 4.4.4 Fast Transition Security IE7.3.2.40 Fast Transition Security IE 4.4.5 Fast Transition Key Holder IE7.3.2.41 Fast Transition Key Holder IE 4.4.6 Time Interval IE7.3.2.42 Time Interval IE

5. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 5 Section mapping, part 2 4.4.7 Resource Information Container7.3.2.43 Resource Information Container IEs 4.4.8 AKM suites7.3.2.25.2 AKM suites 4.4.9 EAPOL-Key IE7.3.2.44 EAPOL-Key IE 5.1 Frame notation8A.1.4 Notation 5.2 EAPOL-Key frame notation8A.1.4 Notation 5.3 First Contact8A.2 First Contact 5.4 Base Mechanism8A.3 Base Mechanism 5.5 Pre-Reservation Mechanism8A.4 Pre-Reservation Mechanism 5.6.1 QoS-Traffic Stream Operation11.3A.1 and 11.3A.3 TS Lifecycle 5.6.2-6 QoS procedures8A.5.4-8 QoS procedures 5.7 RIC Usage8A.5.1-3 RIC 6.1 MLME Resource Reservation10.3.31 MLME Resource Reservation 6.1.5 MLME-Reassociate10.3.7 MLME Reassociate 6.2 Broker Function8A.6 Broker Function 7 Security8.5A.1-8 Key Distr for Fast BSS Transition 8 Informative AnnexO Informative Annex

6. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 6 Section mapping - issues New section with Fast BSS Transition Procedures –8A, after Security Procedures –9A, after MAC procedures, before layer mgmt –Subsection in 11, as part of MLME –11A, after MAC and layer mgmt, before PHY –20, at end For now its section 8A

7. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 7 Proposed Changes to D0.00 Numerous re-wordings need to increase clarity of the text. Level numbers of keys: –PMK-R0 is top level, PMK-R1 is second level, PMK- R2 is third level, PTK is fourth level. Description of Count Information Element –The number of IEs protected by the MIC in the EAPKIE (this IE, and succeeding IEs up through and including the EAPKIE). –See 7.3.2.28 for definition, and Table 9 in 7.2.3.6 for sample usage

8. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 8 Proposed Changes to D0.00, cont. TGr Key Hierarchy replaced by FBT Key Hierarchy Uses of “over-the-wire” replaced by “over-the- DS” Noted in frame definitions that a RIC is a variable number of information elements. Capability advertisement made consistent with frame definitions (but may change with additions to those definitions).

9. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 9 Proposed Changes to D0.00, cont. Definition of “Security Domain” changed to be based on “holders of keys derived from PMK-R0” instead of “R0 key holder children” (which was never defined). Security Domain “contained within” a Security Mobility Domain, and not “a member of” a Security Mobility Domain. A SMD being “a set of sets” adds only confusion, and is not consistent with 8A.5.7. (Possibly(?) technical) qualified a statement that a QSTA must associate with a new AP prior to requesting resources (Section 5.4.5.1.2) with “In a non-FBT environment”. After the FBT sequence, and before reassociation, resources are reserved for a “limited” but not a “fixed” length of time.

10. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 10 Proposed Changes to D0.00, cont. Communication between Current AP and Target AP consistently “out of scope” (as in the majority of cases) and not TBD (as in some cases). Text referring to “Action messages” generalized to “Request messages”, since not all FBT sequences will be using the FT-Action messages. In following the lead of Supplicant/Authenticator instead of STA/AP, made several refs for QoS to “Resource Requestor” instead of STA. More needed. Algorithm for RIC processing by AP changed to note success and failure status.

11. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 11 Proposed Changes to D0.00, cont. Added 11p (in addition to 11e and 11k) as specs we will be following to revcom Re-checked section numbering, figure numbering, table numbering “a STA” and “an RSN” and “an RSNA”

12. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 12 Numerous Further Editorial changes needed to D0.00 See changebar file (double-click on the icon to right):

13. doc.: IEEE 802.11-05/0538r4 Submission July 2005 Bill Marshall, TGr EditorSlide 13 Motion Motion to accept the changes proposed in this contribution, and instruct the editor to generate a new draft with these changes incorporated.