1. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 1 802.11 facilitation for 802 Architecture Group meeting in San Francisco in July 2005 Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-05-16 Authors:

2. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 2 802.11 need to get ready for the next meeting of the 802 Architecture SC in San Francisco in July 2005 Situation An 802 Standing Committee has been created to improve alignment between WG projects & the 802 architecture The 802 Architecture SC is currently trolling (slowly) for “architectural issues” related to each WG Complication Despite 802.11 being “allocated” issues by the other WGs, they might not be our issues Key line 802.11 need to develop a list to be ready for the next meeting of the 802 Architecture SC ← this is why we are here now

3. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 3 An SEC SC has been created to improve alignment between WG projects & the 802 architecture What does the SC do? Identifies issues & potential solutions to maintain the existing 802 architecture Identifies potential refinements or changes to the existing 802 architecture What are the SC outputs? It does not generate detailed documents It does aim to raise consciousness for feeding back to WGs It may document thoughts in slide-ware How does the SC operate? Meets on Sunday before each plenary session Consists of appointees from each WG; in case of 802.11 the reps are; –Andrew Myles –Roger Durand Where is info on the SC kept? A website is maintained at www.ieee802.org/1/files/public/8 02_architecture_group/ You can join the email exploder at www.ieee802.org/1/email- pages/joining.html

4. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 4 The SC is currently trolling (slowly) for architectural “issues” related to each WG At previous meetings reps of each WG generated a list of “issues”, which have been refined by some WGs in the meantime There were no 802.11 reps at the time and so we were “allocated” issues by the other WGs Before the Atlanta meeting the 802.11 reps made a request for issues from the WG via the reflector with little response The Atlanta meeting made an attempt to review the lists but much work is still required –Only 802.22 to 802.15 lists were reviewed in Atlanta –Many of the “issues” turned out not to be issues –The issues generally need far more description

5. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 5 Despite 802.11 being “allocated” issues by the other WGs, they might not be our issues Other group allocated 802.11 some issues “QoS/class of service” “Protocol definition vs scope” “Security” “Bridging compatibility” “LLC” “Mesh” “What is the future.11 architecture” “Power/channel management” These “allocated” issues might not be 802.11’s issues At least some of the issues are not really issues for the 802 architecture group It is not clear what some of the “issues” actually are

6. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 6 802.11 need to develop a list to be ready for the next meeting of the 802 Architecture SC in San Francisco Why? The current list is almost useless –There is no 802.11 “ownership” of the current list –The issues are not sufficiently described –The issues are almost certainly incorrect/incomplete There is value in talking to the other groups –Many in 802.1 complain that we did not ask for help architecting the AP How? Members of 802.11 actually think about the problem between now and Cairns The “thinkers” summarise their ideas in some form and send the reflector The 802.11 reps to the SC will pull together a summary and lead a discussion in Cairns The 802.11 reps to the SC will feed the results into the SC in San Francisco

7. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 7 This is the part of the presentation where audience participation is required The goal Agree on a list of “802.11 issues” for submission to the 802 Architecture SC in San Francisco –What is the situation? –What is the problem? –What should we do about it? The process Discuss a number of issues submitted by e-mail Explore the issues that have been “allocated” to 802.11 Discover new issues –From additional presentations? –Stephen McCann –…? –From the audience?

8. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 8 Mike Moreton asks whether we need a standard bridge table updating mechanism What is the situation? STA roaming to a new AP is a normal part of 802.11 operation Ideally, it should be achieved without disruption to QoS on the STA This requires frames destined to the STA to be redirected to the new AP What is the problem? A network using 802.1D bridges, will not update the forwarding tables until a frame is sent in the opposite direction What should we do about it? We need is a standard method for updating the bridge forwarding tables when a STA roams that will take effect within the sort of timescales needed to maintain QoS (<30ms?) Mike believes, “properly designed network should be capable of updating its own forwarding tables without help from external devices.”

9. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 9 Mike Moreton asks whether 802.1X needs to be modified to reflect realities of broadcast media What is the situation? 802.1X was designed for situations where there was one end station per port What is the problem? 802.11i can have multiple end- stations per port because its a broadcast medium 802.11i overcomes the problem using virtual ports by having each STA's data encrypted with a different pair-wise key –… and you thought that was to stop eavesdropping –See last part of 04/1191r5 However, there are still some aspects of 802.1X that are limited to the physical port –eg authenticating through one port (we're talking an AP working on different channels here) shouldn't allow you to send data via a different port, because the keys may well not have been programmed in on that port. What should we do about it? 802.1 need to have some reflection in 802.1X of how it works with broadcast media where traffic is segmented by separate keys.

10. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 10 We need to explore the “QoS/class of service” architecture issue Background The “QoS/class of service” issue was allocated to 802.11 It has been interpreted to mean, “How do you map QoS between different networks?” Questions Is the issue interpretation correct and complete? Is this an architecture issue? Is it relevant to 802.11? What should be done?

11. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 11 We need to explore the “Protocol definition vs scope” architecture issue Background The “protocol definition vs scope” issue was allocated to 802.11 It is not clear what the issue is Questions What is the issue? Is this an architecture issue? Is it relevant to 802.11? What should be done?

12. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 12 We need to explore the “security” architecture issue Background The “security” issue was allocated to 802.11 It is not clear what the issue is Questions What is the issue? Is this an architecture issue? Is it relevant to 802.11? What should be done?

13. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 13 We need to explore the “Bridging compatibility – handling of multicasts” architecture issue Background The “Bridging compatibility – handling of multicasts” issue was allocated to 802.11 It is not clear what the issue is Questions What is the issue? Is this an architecture issue? Is it relevant to 802.11? What should be done?

14. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 14 We need to explore the “LLC” architecture issue Background The “LLC” issue was allocated to 802.11 The issue has been interpreted as meaning: –The LLC provides no mechanism for passing additional (e.g., QoS) parameters –This means that it is difficult to up set up a QoS connection across multiple radio links Questions What is the issue? Is this an architecture issue? Is it relevant to 802.11? What should be done?

15. doc.: IEEE 802.11-05/0407r0 Submission May 2005 Andrew Myles, CiscoSlide 15 Are there any additional issues?