1 / 23

Management Frame Policy Definition

Management Frame Policy Definition. Date: 2010-05-19. Authors:. Slide 1. Outline. Requirements addressed High level exchange – Association enterprise exchange Policy advertisement Policy request/report Policy change request/response Pre-association/Roaming policy Legacy STA

alika
Download Presentation

Management Frame Policy Definition

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. Management Frame Policy Definition Date: 2010-05-19 Authors: Slide 1 Santosh Pandey, Cisco Systems

  2. Outline • Requirements addressed • High level exchange – Association enterprise exchange • Policy advertisement • Policy request/report • Policy change request/response • Pre-association/Roaming policy • Legacy STA • IBSS – Exchange Unless specified otherwise, all references to AP and STA in this presentation imply 802.11ae capable AP and 802.11ae capable STA respectively

  3. Requirements to be addressed • Management policy definition and advertisement • Allow application of policy to groups of management frames • Advertise management frames’ priorities in beacons concisely • Pre-association policy advertisement and implementation • Post-association policy advertisement and implementation • STAs can exchange policies on demand • STAs can request change in policy • Details • 11-10-0365-03-00ae-proposal-for-prioritization-of-management-frames.doc • 11-10-0295-01-00ae-tech-proposals.doc • 11-10-0093-05-00ae-tgae-requirements-and-use-cases.doc

  4. High level exchange – Association enterprise exchange • Default policy is to send all management frames at highest priority (AC_VO) • Pre-association • Extended Capabilities IE bit will be set to indicate STA is 802.11ae capable. This IE is included in Beacons, Association Request/Response, Reassociation Request/Response and Probe Request/Response • The pre-association policy advertisement and adoption is described later • Association • AP shall include the entire management frame policy in (Re)Association Response • STA shall adopt this policy post-association to send all management frames • Post-Association policy • STA shall request associated AP for changing priority of any management frame if needed • AP shall respond will accept/reject response. The reject response shall include a reason code to indicate if the STA may or may not retry later • Any management frames whose priority is not modified by Management Frame QoS (MFQ) Policy is sent at AC_VO.

  5. Management Frame QoS Policy IE • This IE will be used to advertise and exchange MFQ policy between STAs • This IE is sent in Beacons, (Re)Association Response and Probe Response • Contents of IE in beacon frame should only be for frames which can only be transmitted in state 1 and 2. Pre-association details in later slides. • It will also be used in a new policy report frame and policy change request/response frame describe later • Priority Definition Count field indicates the number of Priorities Definition field included in the IE • List of Priority Definition fields contains one or more Priority Definition fields

  6. Priority Definition Field (PrDf) • This field indicates a group of management frames and their corresponding priority • Guiding principles for this field: • To indicate priority of all management frames efficiently • Allow grouping of management frames having the same priority • Future proof – no change needed when future amendments add new management frames • This is an ordered list as explained in slide 14

  7. Priority Definition Field: Type_PrDf=0 B7 Bits: B0 B3 B4 B7 B0 B3 B4 B0 B1 B2 Bn • Priority Definition Field Type (Type_PrDf) subfield is 2 bits in length and defines the structure of the Priority Definition field. • Unicast bit (U) is set if the management frames priorities defined in PrDf is applicable to unicast management frames • Multicast bit (M) is set if the management frames priorities defined in PrDf is applicable to multicast management frames • Priority Definition Field Length (Length_PrDf) subfield is 4 bits in length and defines the length in octets of the Priority Definition field, excluding the 1 octet used for Type_PrDf , U, M and Length_PrDf subfields. This can support maximum of 15 octets. • TID subfield is 4 bits in length and is defined in 7.1.3.5.1. The management frames indicated in this priority definition field are sent at priority defined by this TID. • Management Frame Subtype (Subtype_PrDf) subfield is 4 bits in length. The values are defined in Table 7-1 for management frame type. For example, • a value of 0000 indicates Association Request management frame • a value of 1101 indicates Action management frame • Category Value (CV_PrDf) subfield is 1 octet in length and is included only for frames of subtype Action and Action No Ack • For example, a Category Value of 10 will indicate WNM category action frame when Subtype_PrDf = Action subtype • Action Value Bitmap (AVB_PrDf) subfield length is variable and it indicates the corresponding Action values • For example, setting Bit 0 and Bit 1 will indicate Event Request/Response when Subtype_PrDf = Action subtype and CV_PrDf = WNM Category

  8. Priority Definition Field: Type_PrDf=0 • Action Value Bitmap subfield may be included for frames of subtype Action and Action No Ack and when the Category subfield is included • Each bit in the Action Value Bitmap subfield is mapped to the corresponding action value. • Multiple Action frames are indicated by setting multiple bits • This subfield is zero padded to complete any incomplete octet Table: Valid combination of optional fields to be included in Priority Definition Field

  9. Example 1 B1 B5 B0 Action Value Bitmap B2 B3 B4 B6 B7 • For example, above frame • TID = 1 (AC_BK) • Subtype = 13 (Action) • Category Value = 0 (Spectrum management) • Action Value Bitmap subfield (B7-B0) = 0000 0011, indicates frames with Action value = 0 and 1 (i.e. Measurement Request/Response respectively) • This indicates that the Measurement Request/Response of Spectrum Measurement Category will be sent at AC_BK priority Priority Definition Field

  10. Example 2 • For example, above frame • TID = 0 (AC_BE) • Subtype = 13 (Action) • Category Value = 11 (unprotected WNM) • This indicates that all unprotected WNM Action frames will be sent at AC_BE priority Priority Definition Field

  11. Example 3: Mgmt Frame Policy IE with 3 priority definitions • The above defines complete management policy IE which includes different priorities defined in examples 1-2 in previous slides Action Value Bitmap

  12. Considering trade offs for priority definition • Brute force – specifying subtype, category, action value for each management frame priority • Pros • Future proof – no change needed for any future amendments • Cons • Requires minimum 3 bytes for each management frame (TID, Subtype, Category, Action) • No grouping possible, each frame has to be individually specified • Very large size (237 octets) considering that 79 of the 140 management frames priority may need to be changed to low priority (from 11-10-0097-02-00ae-management-frame-analysis.xls) • Lookup Table – have a table of bitmap for all the management frames • Pros • Can specify all the management frame for a given priority in a single Priority Definition field • Selectively define management frames in the table (implicitly club request/response to a single priority) • Size can be limited (with current management frames) to 19 octets • Cons • Requires table which needs to be updated for every amendment which introduces management frames • Table may grow too large for future • Extra lookup overheads in STA • Proposed scheme • Continued next slide …

  13. Considering trade offs for priority definition • Proposed scheme • Pros • Provides some level of grouping/aggregation. Logically, priorities would be changed for contiguous set of Action values • Future proof – no change needed for any future amendments • All frame subtypes or categories can be aggregated • Requires minimum 2 octets and maximum 7 octets for all current subtype-category pairs. 52 octets will be required to change priorities of 79 of the 140 management frames (from 11-10-0097-02-00ae-management-frame-analysis.xls) • Cons • A Priority Definition field can support only a single subtype-category pair of management frames. Multiple Priority Definition field is required for unique subtype-category pairs to be defined • Length of the IE may range from 3 to 255. • The priority of all management frames from the doc 10/097 to a single lower priority is 52 bytes • As there are only 3 AC other than AC_VO (the default priority), a maximum of 156 bytes (note we are counting same frames multiple times for this upper bound calculation) may be required for defining all management frame priorities

  14. Optimizations: Policy Definition IE • Contents of IE in beacon frame should only be for frames which can only be transmitted in state 1 or 2 – partial management frame policy • There is an assumption that the number of subtypes that would be specified by priority would be small – from the excel sheet (doc 10/097) it will be 10 bytes. • The complete policy shall be sent to STA in (Re)Association Response • If same management frame is indicated in multiple Priority Definition fields, the management frame is sent at the priority defined in the last Priority Definition field • This can be used to set the priority of the entire category and change only specific action frames • For example, to set the entire WNM category (10) at AC_BE priority with the exception of Event Request/Report (Action value = 0,1), which are to be sent at AC_BK, the following sequence of Priority Definition fields can be used in the Management Frame Policy IE Action Value Bitmap

  15. Management Frame QoS Policy action Table 7-24—Category values • The MFQ policy can be exchanged and changed using the above action frames Table X -- MPE Action field values

  16. MFQ Policy Query Request • This frame is used to request policy from an STA to another • This is not used in infrastructure BSS network • Only used in IBSS (or mesh and 11p cases) • The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in 7.3.1.11. • The Action field is set to the value indicating MFQ Policy Query Request, as specified in Table X • The Dialog Token field is set to a nonzero value chosen by the STA sending the MFQ Policy Query Request to identify the request/response transaction. MFQ Policy Query Request frame body format

  17. MFQ Policy Query Response • This frame is used to indicate the MFQ policy when a MFQ Policy Query Request is received from an STA in an IBSS case • The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in 7.3.1.11. • The Action field is set to the value indicating MFQ Policy Query Response, as specified in Table X • The Dialog Token field is set to the nonzero value of the corresponding MFQ Policy Query Request frame. • MFQ policy element defines the complete MFQ policy MFQ Policy Query Response frame body format

  18. MFQ Policy Config Request • This frame is used to request change in MFQ policy configuration • The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in 7.3.1.11. • The Action field is set to the value indicating MFQ Policy ConfigRequest, as specified in Table X • The Dialog Token field is set to a nonzero value chosen by the STA sending the MFQ Policy Config Request to identify the request/response transaction. • The MFQ Policy element is as define earlier. • When sent by an associated STA, this frame will indicate the new MFQ policy requested by the STA • Management frames not indicated in this request are sent at policy advertised by associated AP – only the delta change of policy is sent in this request • Only unicast allowed • When sent by an AP, this frame will indicate the new MFQ policy that STA associated to this AP shall adopt • Only unicast allowed. Multicast is discussed later MFQ Policy Config Request frame body format

  19. MFQ Policy Config Response • This frame is used to respond to a MFQ Policy Config Request • The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in 7.3.1.11. • The Action field is set to the value indicating MFQ Policy ConfigResponse, as specified in Table X • The Dialog Token field is set to the nonzero value of the corresponding MFQ Policy ConfigRequest frame. • The Status Code field contains status code in response to MFQ Policy ConfigRequest frame as defined in adjacent Table. • Only unicast frames allowed MFQ Policy Config Response frame body format Status Code Definitions

  20. High level management policy exchange • (Re)Association Request/Response will be used to exchange complete MFQ during association • MFQ Policy Query Request/Response can only be unicast • Multicast may lead to response storm in network • MFQ Policy ConfigRequest/Response actions are governed by the adjacent table Policy Config Request/Response combinations for BSS case Policy Config Request/Response combinations for IBSS (11p and mesh) case

  21. MFQ Policy Config Delete • This frame is used to delete the change previously requested in management frame policy configuration using MFQ Policy Config Request • The Category field is set to the value indicating the MFQ category, as specified in Table 7-24 in 7.3.1.11. • The Action field is set to the value indicating MFQ Policy Config Delete, as specified in Table X • The Dialog Token field is set to the dialog token value used in the MFQ Policy Config Request MFQ Policy Config Delete frame body format

  22. Other cases and open issues • Pre-association • In AP beacons, only the policy for pre-association management frames to be sent at non-default priority will be included • All management frames to the AP (by unassociated STAs) shall be sent at the policy advertised in AP beacon • AP may configure priority of STA post-association • Policy Config Request frames will be used • Multicast may induce unreliability – no certainty that the STA received the policy definition or not, which may lead to sequence number issues. So should we only allow unicast configuration? Is there a group address response – can 11aa help? • Roaming • Associated STA shall follow the associated AP management policy to send management frames (e.g. Probe Request) to other APs in the same ESS • If the target AP is in different ESS? • If associated AP is a legacy AP, then should the STA adopt the policy of the target AP if it received the management frame policy in the target AP beacon ? • This will follow the pre-association policy with respect to the destination BSS • Legacy STA • An 11ae capable STA shall associate in 11ae mode to an 11ae capable AP. • An 11ae capable STA shall associate in legacy mode to a non 11ae capable AP. • A non-11ae capable STA shall associate in legacy mode to an 11ae capable AP. • An 11ae capable STA shall adhere to the policy advertised by the 11ae capable AP. • Any management frame not defined in the policy defaults to the AC_VO • Policy exchange in IBSS shall be carried out using Management Policy Exchange Action frames • What action should be taken when a packet is received at incorrect priority?

  23. Meeting discussions • Pre-association • STA shall use MFQ policy from AP Beacon frame (if received) to transmit packet to that AP . If AP Beacon frame is not received then STA shall transmit the management frames at AC_VO priority • Using multicast MFQ Policy Config Request by an AP to change the policy of associated STA may be a problem • Consider a counter to be used by AP to advertise policy and indicate MFQ policy change • STA may drop frames that are not in policy • Group-addressed frames should have consistent policy across the ESS • STA may not be able to detect the transmit priority of the received MFQ management frame • The group discussed default priorities and decided on AC_VO as • It is the legacy priority for management frame so will not cause unfairness for 11aeSTAs • Default priority are very deployment specific and may change with each deployment • Using the mechanism outlined in this presentation, the priority of all management frames can be changed efficiently • Just after MFQ policy is changed, there may be management frames in the transmit queue which may be out of policy and dropped at the receiver • This was discussed and the group concluded that this will have low impact

More Related