Simplifying IEEE 802.11 Addressing Comments
Discussing simplifications in handling frames for IEEE 802.11 addressing to reach consensus and potential barriers to adoption due to variable address sizes.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
July 2015 doc.: IEEE 802.11-15/0791r0 Addressing Simplifications Date: 2012-07-09 Authors: Name David Kloper Affiliations Address Cisco Systems, Inc. Phone 408-526-5041 dakloper@cisco.com email 170 W Tasman Dr San Jose, CA 95134 Submission Slide 1 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Abstract Several addressing-related comments want to make changes in how GLK handles frames, in the interest of simplicity. This submission discusses some of these simplifications and attempts to reach consensus before we close out those comments. Submission Slide 2 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 3 SYNRA formats add complexity Re: CID210/223 802.11 development has had significant focus on high performance (11n->ac->ax) Several chipsets/vendors are adding HW acceleration in DP GLK shouldn t discourage this, or require HW changes as baseline Variable sized addresses have higher complexity SYNRA Types 1&2 are 7-516 bytes long These are not well suited to HW acceleration These are more appropriate in Control Plane vs Data Plane This could be a barrier to adoption GLK may not be supported if T1&2 require HW changes .. or HW acceleration be globally disabled due to single GLK feature? Submission Slide 3 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Straw Poll #1 Would you support biasing SYNRA Type 0 more for the typical case? Replace 8b with 22b AID bitmap No AID offset (limiting to AID 1-22) No I/E subfield (only an explicit inclusion list) Assumption is most AP would support limited number of GLK Clients, and can assign to lower AID (from a reserved range) at association Yes: No: Abstain: Submission Slide 4 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Straw Poll #2 Would you support making SYNRA Type 1 & 2 Optional? Support for Types 1 & 2 would individually be indicated at association time Unsupported types are dropped by receiving Non-AP GLK STA Yes: No: Abstain: Submission Slide 5 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Straw Poll #3 Would you support dropping SYNRA Type 2? Redundant w/ Type 1 Possibly byte savings for atypical case (sparse matrix, typical is mostly all or exclude 1) Yes: No: Abstain: Submission Slide 6 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Usage of FromDS/ToDS bits (1 of 2) Re: CID149/151/218/233 Rational for using all 3 (or 4) combinations of FromDS/ToDS bits is really about saving 6 bytes More appropriate in WG focused/limited to lower speed links Consider Van Jacobson header compression/etc, for bigger savings Savings may be na ve assumption Many bridges run single IP stack over Bridged Virtual Interface (Cisco) or Bridge Net Device (Linux) Which MAC Addr does IP stack use? AP = Ethernet, per Radio, per SSID; Smartphone = WIFI, BlueTooth, Cellular, other; Submission Slide 7 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Usage of FromDS/ToDS bits (2 of 2) Bridging is the purpose that 4 address format was designed for Where is the DS when we are talking From or To? 802.11 has specific filtering rules for ToDS and FromDS data frames Some HW may implement Rx filtering that prohibits a new definition, which GLK makes mandatory Submission Slide 8 David Kloper, Cisco
July 2015 doc.: IEEE 802.11-15/0791r0 Straw Poll #4 Would you support limiting GLK to using 4 address format when sending to associated GLK peers? Other 3 combinations of ToDS/FromDS prohibited Yes: No: Abstain: Submission Slide 9 David Kloper, Cisco
