1. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 1 Wireless Bridge Common Practices 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@ok-brit.compatcom@ieee.org Date: 2007-07-18 Authors:

2. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 2 Abstract The submission describes how to properly use existing mechanisms within 802.11 to implement devices that include bridging capability (both within the wireless network and between the wireless network and a non- wireless network).

3. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 3 Introduction 802.11 includes a four-address frame format (4AFF) that can be used for indirect, or relayed, communications. 4AFF is also intended for use in devices that include bridging capability. However, descriptions and definitions of exactly how to use 4AFF to perform these functions were not allowed to be included in the 802.11 Std. The implementation scheme is fairly straightforward and this paper seeks to document those procedures in order to ease development of such devices and perhaps support improved interoperability.

4. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 4 Specific Actions Needed Actions required in bridges Actions required in 802.11 APs Actions required in 802.11 STA that include bridging capability

5. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 5 Terminology Reference See slide 9 from [1] Title = “Large scale 802.11 access LAN with 4A mode STA with bridging” Establishes the term “station with bridging capability”

6. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 6 Large scale 802.11 access LAN with 4A mode STA with bridging DS non 802.11 LAN Infra mode STA AP ACM_STA B/C Infra mode STA AP ACM_STA B/C 4A STA 4A mode STA with bridging D Portal Bridge non-802.11 STA Slide 9 from 11-05-0710-00

7. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 7 Challenge refer to slide 9 in [2] [2] ponders how to deal with link change for the TV device As noted, an unacceptable solution is to send Topology Change Notification (TCN) packets, which causes massive unlearning and subsequent flooding Alternately (as cited on [2] slide 14) sending bcsts or mcsts is also problematic an hence ineffective.

8. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 8 Slide 9 from avb-nfinn-wireless-bridges-071307.pdf

9. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 9 Instead the solution lies elsewhere First let’s look at how the STAs got connected in the first place and what data paths exist between the STAs.

10. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 10 Initial Link Establishment When SR initially associates to AP A it uses a normal association process. When DVD1 is attached to the SR, the SR associates the DVD1 with AP A using an indirect association process, i.e. an associate request constructed using the 4AFF, indicating to AP A that STA SR is the relay point for packets destined for DVD1. AP A also now knows that STA SR is a bridging STA and so all future bcst/ mcst packets are delivered from AP A to STA SR as unicast packets using the 4AFF. A similar process is used to indirectly associate the TV with AP A. So AP A now knows the path to STAs SR, DVD1 and TV. AP A uses the “infrastructure update packet” to inform bridge B of the presence of STAs SR, DVD1 and TV.

11. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 11 Link Re-establishment When the TV disconnects from DVD1 and establishes a direct link with bridge B then Bridge B sends to bridge A an “infrastructure update packet” (for example as defined in 802.11F). Bridge A updates its memory of the location of the TV and in turn forwards the “infrastructure update packet” to other devices to which it is connected (but not the source port). In particular the update packet is sent to “station bridge SR”. Since station SR is known to be a STA with bridging capability all packets are sent using the 4AFF. STA SR now learns the new location in the network of the TV. Since STA SR also includes a bridge it forwards the “infrastructure update packet” to DVD1 and DVD1 learns the new path to the TV. Result = instantly all devices in the local area network learn the new location of the relinked device (the TV in this case).

12. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 12 Summary Actions required in bridges –send out “infrastructure update packet” when a new device is detected, or a known device is detected on a different port. Actions required in 802.11 APs –detect indirect associations forwarded by associated STAs –mark those STAs as being of type “STA with bridging” –thereafter apply 4AFF for all frame exchanges with those STAs Actions required in 802.11 STA that include bridging capability –use 4AFF for all frame exchanges with the AP –send out “infrastructure update packet” when a new device is detected, or a known device is detected on a different port.

13. doc.: IEEE 802.11-07/2233r0 Submission July 2007 Darwin Engwer, Nortel NetworksSlide 13 References 1. 11-05-0710-00-000m-wds-clarifications.doc 2. http://www.ieee802.org/1/files/public/docs2007/avb- nfinn-wireless-bridges-071307.pdf 3. IEEE 802.11F-2003.pdf