Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Santosh Pandey, Cisco SystemsSlide 1 Management Frame Policy Definition Authors: Date: 2010-04-20.

Similar presentations


Presentation on theme: "Doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Santosh Pandey, Cisco SystemsSlide 1 Management Frame Policy Definition Authors: Date: 2010-04-20."— Presentation transcript:

1 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Santosh Pandey, Cisco SystemsSlide 1 Management Frame Policy Definition Authors: Date: 2010-04-20

2 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 2Santosh Pandey, Cisco Systems 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 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 3Santosh Pandey, Cisco Systems Requirements to be addressed 1.Management policy definition and advertisement a)Allow application of policy to groups of management frames b)Advertise management frames’ priorities in beacons concisely c)Pre-association policy advertisement and implementation d)Post-association policy advertisement and implementation 2.STAs can exchange policies on demand 3.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 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 4Santosh Pandey, Cisco Systems 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 Policy is sent at AC_VO.

5 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 5Santosh Pandey, Cisco Systems Management Frame Policy IE This IE will be used to advertise and exchange management frame 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 Element ID LengthPriority Definition Count Priority definition field #1 Priority definition field #2 (optional) …Priority Definition field #n (optional) Octets:111 variable

6 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 6Santosh Pandey, Cisco Systems 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

7 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 7Santosh Pandey, Cisco Systems Priority Definition Field: Type_PrDf=0 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 Priority Definitio n Field Type 0 UMPriority Definition Field Length TID Mgmt Frame Subtype Category Value (optional) Action Value Bitmap (optional) Octets:1 1 1variable B0B3B4B7 Bits: B0B3 B7 B4B0 Bn B1B2

8 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 8Santosh Pandey, Cisco Systems Priority Definition Field: Type_PrDf=0 Table: Valid combination of optional fields to be included in Priority Definition Field Length_ PrDf (octet(s)) Subtype_ PrDf CV_ PrDf AVB_ PrDf Description 1  Policy to be applied to all management frames of the corresponding subtype 2  Policy to be applied to all action frames of corresponding category value belonging to the management subtype frames >= 3 Policy to be applied to only Action frames indicated via the action value bitmap for corresponding category value and management subtype frames 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

9 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 9Santosh Pandey, Cisco Systems Example 1 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 Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 31 13 011000000 Octets:1 1 11 B0 B1 B2B3B4 B5 B6B7 Action Value Bitmap

10 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 10Santosh Pandey, Cisco Systems 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 Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 20 13 11 Octets:1 1 1

11 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 11Santosh Pandey, Cisco Systems Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 31 13 011000000 Octets:1 1 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 Element ID Length 8 Priority Definition Count 2 Octets:11 1 Action Value Bitmap Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 20 13 11 Octets:1 1 1

12 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 12Santosh Pandey, Cisco Systems 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 –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

13 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 13Santosh Pandey, Cisco Systems 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. –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 Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 20 13 10 Octets:1 1 1 Typ e_P rDf UM Length_ PrDf TIDSubtype_ PrDf Category Value 010 31 13 1011000000 Octets:1 1 11 Action Value Bitmap

14 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 14Santosh Pandey, Cisco Systems Management Policy Exchange action The management policy can be exchanged and changed using the above action frames CodeMeaning Management Policy Exchange (MPE) Table 7-24—Category values Action field value Description 0Policy Query 1Policy Response 2Policy Config Request 3Policy Config Response 4Policy Config Delete Table X -- MPE Action field values

15 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 15Santosh Pandey, Cisco Systems Policy Query This frame is used to request policy from an STA to another The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Request, as specified in Table X The Dialog Token field is set to a nonzero value chosen by the STA sending the policy request to identify the request/report transaction. CategoryAction Dialog Token Octets:11 1 Policy Request frame body format

16 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 16Santosh Pandey, Cisco Systems Policy Response This frame is used to indicate the policy when a policy request is received from an STA The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Report, as specified in Table X The Dialog Token field is set to the nonzero value of the corresponding Policy Request frame. CategoryAction Dialog TokenManagement Frame Policy element Octets:11 1 variable Policy Report frame body format

17 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 17Santosh Pandey, Cisco Systems Policy Config Request This frame is used to request change in management frame policy configuration The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Change Request, as specified in Table X The Dialog Token field is set to a nonzero value chosen by the STA sending the policy request to identify the request/response transaction. The Management Frame Policy element is as define earlier. When sent by an associated STA, this frame will indicate the new management frame policy requested by the STA –Management frames not indicated in this request are sent at policy advertised by associated AP –Only unicast allowed When sent by an AP, this frame will indicate the new management frame policy that STA associated to this AP shall adopt –Only unicast allowed. Multicast is discussed later CategoryAction Dialog TokenManagement Frame Policy element Octets:11 1 variable Policy Change Request frame body format

18 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 18Santosh Pandey, Cisco Systems Policy Config Response This frame is used to respond to a policy config change request The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Change Response, as specified in Table X The Dialog Token field is set to the nonzero value of the corresponding Policy Change Request frame. The Status Code field contains status code in response to Policy Change Request frame as defined in adjacent Table. Only unicast frames allowed CategoryAction Dialog Token Status Code Octets:11 11 Policy Change Response frame body format Status CodeStatus code description 0Accept 1Reject – don’t retry 2Reject – may retry Status Code Definitions

19 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 19Santosh Pandey, Cisco Systems High level management policy exchange (Re)Association Request/Response will be used to exchange complete management policy during association Policy Query/Response can only be unicast –Multicast may lead to response storm in network Policy Config Request/Response actions are governed by the adjacent table Policy Config Request RequestorResponder Action Policy Config Response UnicastAPSTASTA adopts policy Sends response UnicastSTAAPAP may or may not allow STA to change policy Sends response UnicastNon-AP STA STA may or may not adopt policy Sends response Policy Config Request/Response combinations

20 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 20Santosh Pandey, Cisco Systems Policy Config Delete This frame is used to delete the change previously requested in management frame policy configuration using Policy Config Request The Category field is set to the value indicating the MPE category, as specified in Table 7-24 in 7.3.1.11. The Action field is set to the value indicating Policy Config Delete, as specified in Table X The Dialog Token field is set to the dialog token value used in the Policy Config Request CategoryAction Dialog Token Octets:11 1 Policy Change Request frame body format

21 doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Slide 21Santosh Pandey, Cisco Systems 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 unicast management frames to the AP (by unassociated STAs) shall be sent at the policy advertised in AP beacon –Multicast management frames? Frames to other APs? Default priority? 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 ? 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?


Download ppt "Doc.:IEEE 802.11-10/0476r1 Submission Apr. 2010 Santosh Pandey, Cisco SystemsSlide 1 Management Frame Policy Definition Authors: Date: 2010-04-20."

Similar presentations


Ads by Google