Clause 7.2.3.6, Page 5, Line 44

Clause 7.2.3.6, Page 5, Line 44

August 2007doc.: IEEE 802.11-07/2351r0

IEEE P802.11
Wireless LANs

FT Resource Request Protocol Removal
Date: 2007-08-23
Author(s):
Name / Company / Address / Phone / email
Kapil Sood / Intel Corp. / 2111 NE 25th Ave JF3-206, HillsboroOR97124 / +1 503 264 3759 /

Clause 7.2.3.6, Page 5, line 44

Change: is true, the FT resource request protocol is not used, the frame is being

Clause 7.2.3.10, Page 7, line 5-12

Change: Remove rows with Order 8 and 9 from Table 7-16

Clause 7.2.3.10, Page 7, line 42-62

Change: Remove rows with Authentication Transaction Sequence number 3 and 4 from Table 7-17

Clause 7.3.2.25.4, Page 9, line 41

Change: Request frame to an AP, and in Fast BSS Transition authentication sequence frames. The PMKID

Clause 7.3.2.45, Page 11, line 4

Change: Remove bit B2 (Resource Request Protocol Capability) fromFig 7-95q

Clause 7.3.2.45, Page 11, line 20

Change: Delete lines 20-22. If Resource request protocol capability is set to one then the STA may perform the FT resource request protocol of 11A.6.

Clause 7.4.7, Page 15, line 14-19

Change: Remove in Table 7-57b the 2 rows with Action Field values 3 and 4. Change “35-255 Reserved”

Delete Clause 7.4.7.3, Page 16-17

Change: Delete the entire clause 7.4.7.3

Delete Clause 7.4.7.4, Page 17-18

Change: Delete the entire clause 7.4.7.4

Clause 8.4.1.1, Page 18, line 52

Change: successful FT protocol or a successful FT resource request protocol.

Clause 8.4.1.1, Page 18, line 55

Change: protocol or a successful FT resource request protocol or a successful FT resource request protocol.

Clause 8.4.1.1, Page 18, line 52

Change: Way Handshake or a successful FT protocol or a successful FT resource request protocol.

Clause 8.4.1.1.2, Page 19, line 52

Change: The PTKSA is a result of the 4-Way Handshake, an FT 4-Way Handshake, or an FT protocol., or an FT resource request protocol.

Delete Clause 10.3.34, Page 37-41

Change: Delete the entire Clause 10.3.34

Clause 11.4.1, Page 46, line 3

Change: In addition, a Traffic Stream could be created if a non-AP STA sends a resource request to an AP in reassociation request during prior to initiating a transition to that AP.

Clause 11.4.3, Page 46, line 16-64

Change: Delete all changes to Clause 11.4.3, including Figure 11-7 on page 46, lines 16-64.

Clause 11.4.3, Page 47, line 6-11

Change: Delete all insertions as indicated on page 47 lines 6-11.

Clause 11.4.4a, Page 47, line 15

Change: A non-AP QoS STA may transmit a TSPEC as part of a RIC-Request in the reassociation requesta resource request message. The SME in the HC decides whether to admit the TSPEC as specified, or refuse the TSPEC, or not admit but suggest an alternative TSPEC, and generates a RIC-Response, according to the procedures given in 11A.11.

Each TS established by this resource request are placed in the Accepted state. This state is an intermediate state between Inactive and Active. In the Accepted state the inactivity and suspension timers shall not be started for the TS. For an HCCA based TS, the HC shall not generate CF-Poll for the TS.

The SME in the HC shall take the resource/timing requirements of the TS in the Accepted state into consideration before assigning any further resources to any other admitted or accepted TS, and in calculating the Available Admission Capacity for the BSS Load information element.

The TS is moved to the Active state if once the AP accepts the reassociation from the non-AP STA.performs a reassociation to the AP (see 11A.11.3). Once the TS becomes Active, the inactivity and suspension timers are started.

If the Reassociation Timer times out and the TS is not yet in the Active state, the TS goes back to the Inactive state.

Clause 11A.1, Page 47, line 61

Change: Delete lines 61-65 on page 47. Delete lines 1-4 on page 48.

Clause 11A.1, Page 48, line 18

Change: APs advertise both capabilities and policies for supporting the FT protocols and methods.

Clause 11A.1, Page 48, line 21-28

Change: NOTE-- Throughout this clause, the notation Authentication-Request refers to an Authentication frame with the Authen-tication Transaction Sequence number set to 1; Authentication-Response refers to an Authentication frame with the Authentication Transaction Sequence number set to 2; Authentication-Confirm refers to an Authentication frame with the Authentication Transaction Sequence number set to 3; Authentication-Ack or Authentication-Acknowledgement refers to an Authentication frame with the Authentication Transaction Sequence number set to 4. The first parameter to the above four two messages is the Authentication Algorithm, such as "Open System Authentication Algorithm" (or short-ened to "Open"), or "Fast BSS Transition Authentication Algorithm" (or shortened to "FT").

Clause 11A.3, Page 51, line 6

Change: policy bits in the MDIE, Fast BSS Transition over air, and Fast BSS Transition over DS, and Resource request protocol capability, shall be set according to the values of the MIB variables dot11FTOverAirEnabled,and dot11FTOverDSEnabled, and dot11FTResourceRequestSupported, respectively.

Clause Annex D, Page 101, line 53-64

Change: Delete the entire definition of the MIB variable dot11FTResourceRequestSupported, which is delete lines 53-64. Change “dot11FTResourceRequestSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When this object is set to TRUE, this shall indicate that the Fast BSS Transition resource request procedures of 11A.10 are supported on this AP entity." ::= { dot11FastBSSTransitionConfigEntry 5 } ”

Clause Annex D, page 100, line 43

Change: Delete line dot11FTResourceRequestSupported. Change “dot11FTResourceRequestSupported TruthValue,”

Clause Annex D, Page 102, line 56

Change: entity shall retain a PTKSA and reserve any specified resources for a non-AP STA

Clause 11A.5.1, Page 55, line 50

Change: The FT protocol supports resource requests as part of the reassociation. The optional FT resource request protocol (see 11A.6) supports resource requests prior to reassociation.

Clause 11A.6, Page 61, line 23

Change: Delete entire Clause 11A.6, 11A.6.1, 11A.6.2, 11A.6.3

Clause 11A.7.1, Page 68, line 31-35

Change: Delete lines 31-35. “If the STA is performing a reassociation exchange as part of the FT resource request protocol, then the STA shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RICResponse in the Reassociation Response frame.”

Clause 11A.7.1, Page 68, line 36

Change: If the STA did not utilize the FT resource request protocol, tThe STA may make a request for resources

Clause 11A.7.2, Page 69, line 25-28

Change: Delete lines 25-28. “If the STA is performing a reassociation exchange as part of the FT resource request protocol, then the STA shall not include the RIC-Request in the Reassociation Request frame, and the AP shall not include the RICResponse in the Reassociation Response frame .”

Clause 11A.7.2, Page 69, line 30

Change: If the STA did not utilize the FT resource request protocol, theThe STA may make a request for resources by

Clause 11A.8.1, Page 69, line 57

Change: These messages are included in the FT protocol frames, or FT resource request protocol frames, to initiate a Fast BSS Transition.

Clause 11A.8.1, Page 69, line 1

Change: onstrate liveness of the peer, and authenticate the information elements. , and enable an authenticated resource request.

Clause 11A.8.1, Page 70, line 11

Change: Delete lines 11-16. Change: “When the STA invokes the FT resource request protocol, then the first four messages of the sequence are all carried in Authentication frames or all carried in Action frames, and are described in 11A.8.2 through 11A.8.5. The fifth and sixth frames of the FT resource request protocol comprise the Reassociation Request frame and Reassociation Response frame, and are described in 11A.8.4 and 11A.8.5 .”

Clause 11A.8.1, Page 70, line 33

Change: Delete the entire row in Table 11A-1 pertaining with Timeout Interval. Change “Timeout Interval (Reassociation Deadline) May optionally appear in the fourth message of the sequence if dot11RSNAEnabled is not set true. 7.3.2.47 ”

Clause 11A.8.1, Page 70, line 64

Change: This also includes a Status Code, and may include a Reassociation deadline.

Clause 11A.8.4, Page 72, line 33

Change: Transaction sequence number (1 octet) which shall be set to the value 5 if this is a Reassociation Request frame, else set to the value 3.

Clause 11A.8.5, Page 73, line 10

Change: When this message of the authentication sequence appears in a Reassociation Response frame, tThe Optional parameters in the FTIE may include a GTK sub-element.

Clause 11A.8.5, Page 73, line 29

Change: Transaction sequence number (1 octet) which shall be set to the value 6 if this is a Reassociation Response frame, else set to the value 4.

Clause 11A.8.5, Page 73, line 40-48

Change: Delete all lines 40-48. Change “If this message is other than a Reassociation Response frame and dot11RSNAEnabled is set false, a Timeout Interval information element may appear. If this message is other than a Reassociation Response frame, includes a RIC-Response, and dot11RSNAEnabled is set false, then a Timeout Interval shall appear. If it appears it shall be set as follows: — Timeout interval type shall be set to 1 (Reassociation deadline) — Timeout interval value shall be set to the reassociation deadline time .”

Clause 11A.9.1, Page 74, line 4

Change: Deleteline 4. Change “- The MLME-RESOURCE_REQUEST primitives for resource request over the air, and ”

Clause 11A.9.3, Page 76, line 48

Change: establishment, FT protocols (including resource requests), and cleanup

Clause 11A.9.3, Page 76, line 50

Change: to get the PMK-R1 Security Association (PMK-R1 PMKSA) for the FT protocols.

Clause 11A.9.3, Page 78, line 28 in Fig 11A-14

Change: Delete arrow “MLME-RESOURCE_REQUEST.indication (ANonce, SNonce, MD-ID, RSNIE, PMKR1Name, RIC-Req) & MIC-Verified” going out of state FT-PMK-R1-SA-RECD. Delete entire state and contents of FT-RV-HANDSHAKE-NEGOTIATING. Delete arrow “MLME-REASSOCIATE.indication(ANonce, SNonce, MD-ID, R0KH-ID, R1KH-ID, PMK-R1Name) & MIC-Verified” going into FT-HANDSHAKE-DONE. Delete from state FT-HANDSHAKE-DONE the following line “(If Resv-Flow, then do not include RIC-Resp in this msg)”

Clause 11A.9.3.1, Page 79, line 31

Change: Delete lines 31-33. Change: “FT-RV-HANDSHAKE-NEGOTIATING: This state is entered when an FT resource request is received. The FT resource response is sent .”

Clause 11A.9.3.2, Page 80, line 1

Change: Delete line 1. Change “Resv-flow - This variable is set to true when an indication of a FT resource request protocol is received .”

Clause 11A.9.5, Page 83, line 30 Fig 11A-17

Change: Delete arrow “Resource-Request & over-the-Air” going out of state FT-PTK-CALC. Delete arrow “Resource-Request & over-the-DS” going out of FT-PTK-CALC”. Delete arrow “Timeoutctr > N” going out of FT-RV-AIR-CONFIRM”. Delete arrow “Timeoutctr > N” going out of FT-RV-DS-CONFIRM”. Delete arrow “TimeoutEvt” going out of states FT-RV-AIR-CONFIRM and out of FT-RV-DS-CONFIRM. Delete arrow “MLME-RESOURCE_REQUEST.confirm (ANonce, SNonce, MDIE, RSNIE, PMK-R1Name, RIC-Resp) & MIC-Verified” going out of state FT-RV-AIR-CONFIRM. Delete arrow “MLME-REMOTE_REQUEST.indication (ANonce, SNonce, MDIE, RSNIE, PMK-R1Name, RIC-Resp) & MIC-Verified” going out of state FT-RV-DS-CONFIRM. Delete arrows “Timeoutctr > N”, “TimeoutEvt”, and “MLME-REASSOCIATE.confirm(ANonce, SNonce, MDID, R0KH-ID, R1KH-ID, PMK-R1Name) & MIC-Verified” going out of state FT-RESERVE-2. Delete “To Disconnect” arrow going out of states FT-RESERVE-2 and FT-RV-DS-CONFIRM. Delete entire states FT-RV-AIR-CONFIRM, FT-RV-DS-CONFIRM, FT-RESERVE, and FT-RESERVE-2. Change “UCT!Resource-Request” going out of FT-PTK-CALC.

Clause 11A.9.5.1, Page 84, line 56

Change: Delete lines 55-65. Change “FT-RESERVE: This state is entered when the over the air FT Authentication Acknowledge is received if an over-the-air FT Authentication Confirm was sent, or, when over-the-DS Fast BSS Transition Acknowledge is received if an over-the-DS Fast BSS Transition Confirm was sent. FT-RESERVE-2: The reassociation request message is sent in this state. FT-RV-AIR-CONFIRM: This state is entered for over-the-air FT resource request protocol processing. The FT Authentication Confirm message containing the FT resource request is sent .”

Clause 11A.9.5.1, Page 85, line 1

Change: Delete lines 1-3. Change “FT-RV-DS-CONFIRM: This state is entered for over-the-DS FT resource request protocol processing. The FT Authentication Confirm message containing the FT resource request is sent .”

Clause 11A.9.5.2, Page 85, line 48

Change: Delete line 48. Change “Resource-request - This variable is set to true when the FT resource request protocol will be executed. ”

Clause 11A.10.1, Page 86, line 9

Change: Change“The current AP encapsulates the FT Action Frame (Request or Confirm) inside a Remote Request, and transmits it to the target AP over the DS. The target AP processes the remote request and responds to the non-AP STA by sending an FT Action Frame (Response or ACK) through the current AP.”

Clause 11A.10.2, Page 87, line 27 Figure 11A-18

Change: Change Figure 11A-18 as follows: Delete the following arrows “FT Action Confirm (Confirm IEs)”, “RemoteRequest (current AP address, FT Action Confirm)”, “RemoteResponse (current AP address, FT Action Acknowledge)”, “FT Action Acknowledge (Acknowledgement IEs)”

Clause 11A.10.2, Page 87, line 36

Change: Change title of Fig 11A-18 “Figure 11A-18—Sample message flow for over-the-DS resource request”

Clause 11A.10.2, Page 87, line 28 Figure 11A-18

Change: Delete the text “Target AP processes confirmation.” Change “Target AP processes confirmation .”

Clause 11A.11.1, Page 88, line 35-41

Change: To request resources the non-AP STA creates a Resource Information Container (RIC) and inserts the RICit in the Reassociation an appropriate rRequest message to the target AP. The request message is sent to the target AP either directly (over-the-air), or via the current AP (over-the-DS), according to the Fast BSS Transition procedures described in 11A.5 and 11A.6. In an RSNA, resource requests and responses are exchanged only after the establishment of the PTK, and are protected by message integrity checks

Clause 11A.11.1, Page 88, line 43-47

Change: An AP that receives a resource request from a STA shall discard any previous resource request from that STA. In an RSN, this resource request shall first be authenticated by the AP through checking of the MIC before the AP discards any previous resource request .

Clause 11A.11.1, Page 88, line 54-59

Change: If the STA is performing a Fast BSS Transition according to the FT Resource Request protocol, described in 11A.6, it shall generate a RIC and process the RIC response according to the procedures of 11A.11.3.1, performing the exchange in the Authentication-Confirm/Authentication-Acknowledgement frames (over the air) or FT Confirm/FT Acknowledgement frames (over the DS).

Clause 11A.11.3.1, Page 91, line 62-65

Change: A response to a successful resource request (other than in a Reassociation Request) may contain a reassociation deadline. If the non-AP STA does not initiate a Reassociation Request with the target AP within the Reassociation deadline (if appropriate), then the AP will release resources held for that non-AP STA.

Clause 11A.11.3.2, Page 93, line 29-42

Change: If the resource request included QoS resources and is successful, then the procedures for handling of TSPEC, TCLAS and TCLAS Processing elements shall be as specified in 11.4, and the AP shall place the Traffic Streams into the "AcceptedActive" state. The response RIC shall contain the updated admitted TSPEC. Each RDIE may also include a Schedule information element (as defined in 7.3.2.34) after the admitted TSPEC. Upon reassociation, AP shall move all of the Traffic Streams from the "Accepted" state into the "Active" state.

If the STA does not invoke a reassociation within the reassociation deadline, then the Traffic Streams that had been "Accepted" shall become "Inactive" and the resources shall be released. At the point that the STA reassociates with the target AP (within the reassociation deadline, if appropriate), the traffic streams are put into the Active state. This may be immediate if the RIC request was part of a Reassociation Request frame.

Clause Annex A A.4.4.1, page 96, line 14-22

Change: Detele rows on lines 14-22. Change “*PC35.11 Fast BSS Transition Resource Request Protocol 11A.6 PC35:O Yes o No o N/A o PC35.11.1 Resource Request protocol overtheair 11A.6.2 PC35.11:M Yes o No o N/A o PC35.11.2 Resource Request protocol overthe- DS 11A.6.3, 11A.10 PC35.11:M Yes o No o N/A o”

Clause X, page Y, line Z

Change:

References:

Submissionpage 1Kapil Sood (Intel)