1 / 11

Discussion of Action frame proposals

Discussion of Action frame proposals. Andrew Myles, Cisco Systems December 2001. The 802.11e Action frame method to extend the management sub-code space should be changed to use the 01-664r0 solution . Basic problem.

juniper
Download Presentation

Discussion of Action frame proposals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Discussion of Action frame proposals Andrew Myles, Cisco Systems December 2001 Andrew Myles, Cisco Systems

  2. The 802.11e Action frame method to extend the management sub-code space should be changed to use the 01-664r0 solution Basicproblem 802.11e and 802.11h need to define more management frames than there are sub-types available Proposed802.11e solution The 802.11e draft includes a facility called the Action frame that effectively extends the sub-type code space Issues with 802.11e solution The Action frame included in the 802.11e draft is overly prescriptive and thus restricts functionality Proposed802.11h solution 802.11e should consider the less prescriptive version of the Action frame described in 01-664r0 Summary Andrew Myles, Cisco Systems

  3. The 802.11e draft includes a facility called the Action frame that effectively extends the sub-type code space Action Request frame (used as request or advisory frame) Category Code ActionCode(even) Activation Delay Dialog Token Action specific field and elements 1 1 1 1 0-2300 Action Response frame received with: • Category Code that is not understood is ignored • Action Code that is not understood is ignored Action Request frame received with: • Category Code that is not understood is ignored • Action Code that is not understood causes an Action Response frame to be returned with Action Code incremented, and Action-specific Status of 1 Action Request 1 STA 1 STA 2 Action Response(optional) 2 Action Response frame (used as response frame) Category Code Action Code(odd) Action- specific Status Dialog Token Action specific field and elements 1 1 1 1 0-2300 802.11e solution Andrew Myles, Cisco Systems

  4. The 802.11e draft includes a facility called the Action frame that effectively extends the sub-type code space Field Semantics Category Code • Identifies a group of actions ActionCode • Identifies a particular action within a category • Even Action Code indicates an Action Request (or an advisory fame) • Odd Action Code code indicates an Action Response ActivationDelay • Only valid in an Action Request • Specifies when the Action Request should be carried out • Must be zero if activation delay not meaningful for a particular Action Request Action-specific Status • Only valid in an Action Response • Indicates completion status of corresponding Action Request • Predefined status = 0 means Action Request completed successfully • Predefined status = 1 means unrecognised Action Code in Action Request Dialog Token • Copied from Action Request to Action Response to indicate association • Remains constant during repetition of same Action Request 802.11e solution Andrew Myles, Cisco Systems

  5. The Action frame included in the 802.11e draft is overly prescriptive and thus restricts functionality • The Action frame included in the 802.11e draft: • Treats unrecognised codes inconsistently and incompletely • Forces the specification of separate advisory and report frames that look exactly the same • Does not allow multiple Action Responses to an Action Request • Is very “wordy” 802.11e solution issues - Summary Andrew Myles, Cisco Systems

  6. 802.11e Action frame proposal When an STA receives a Action Request with an unrecognised Action Code an Action Response is returned with an Action-specific Status indicating an error When an STA receives a Action Request with an unrecognised Category Code the Action Request is dropped When an STA receives a Action Response with an unrecognised Category Code or an unrecognised Action Code the Action Response is dropped Issues Why is an unrecognised Action Code in an Action Request frame more important than an unrecognised Category Code? Is an error status also sent when the Action Request frame was a broadcast or multi-cast frame? Why not have a general method for treating unrecognised Category and Action Codes that applies to Actions Requests and Action Responses uniformly? The Action frame included in the 802.11e draft treats unrecognised codes inconsistently and incompletely 802.11e solution issues – Unrecognised codes Andrew Myles, Cisco Systems

  7. 802.11e Action frame proposal An Action Request frame is used to send an advisory frame that does not need a response Issues In 802.11h, an advisory frame containing a measurement report looks more like an Action Response frame containing a measurement report rather than a Action Request frame containing the request for a measurement report The prescriptive and inflexible nature of the 802.11e Action fame definition means that 802.11h would be forced to define two frames (measurement report as the result of a request and an advisory measurement report) that look exactly the same The Action frame included in the 802.11e draft forces the specification of separate advisory and report frames that look exactly the same 802.11e solution issues – Advisory <> report Andrew Myles, Cisco Systems

  8. 802.11e Action frame proposal It appears only a single Action Response frame may be sent in response to an Action Request frame Issues Given the potential length of measurement reports in 802.11h it would be useful to split them across multiple Action Response frames that are associated together by a single Dialog Token The Action frame included in the 802.11e draft does not allow multiple Action Responses to an Action Request 802.11e solution issues – Multiple responses Andrew Myles, Cisco Systems

  9. 802.11e and 802.11h should consider the less prescriptive version of the Action frame described in 01-664r0 • Main features of 01-664r0 Action frame proposal • Treats the Action request frame and the Action response frame uniformly • Provides feedback to the source of all unicast Action frames with unrecognised Category and Action codes • Allows Action responses (or requests) to be split into multiple Action frames, each containing one or more elements or fixed fields • Allows the semantics of Action-specific and Dialog Token fields to be specified by each application • Less wordy! 664r0 for 802.11h solution – Summary Andrew Myles, Cisco Systems

  10. 01-664r0 uses a single Action frame for requests, responses and advisories, with uniform error reporting and the possibility of frame splitting Action frame (used as request, response or advisory frame) Category Action Action Specific Dialog Token Action specific field and elements 1 1 1 1 0-2300 Action frame (uni-cast) received with: • Category, Action (with msb clear), Action Specific or Dialog Token field that is not understood causes the same Action frame to be returned with msb of Action field set • msb of Action field set is used to indicate an problem with a previous request Action 1 STA 1 STA 2 Can be split intomultiple frames Action(zero or more optional) 2 664r0 for 802.11h solution – Features 1 Andrew Myles, Cisco Systems

  11. 01-664r0 uses a generic frame structure in which the semantics of the Action-specific and Dialog Token fields can be specified separately for each application Field Semantics Category Code • Identifies a group of actions ActionCode • Identifies a particular action within a category • msb indicates if this is an error response Action-specific Status • Semantics are undefined • Normally used as activation delay in a request • Normally used as status in a response Dialog Token • Semantics are undefined • Normally copied from Action request to Action response(s) to indicate transaction • Normally remains constant during repetition of same Action request 664r0 for 802.11h solution – Features 2 Andrew Myles, Cisco Systems

More Related