July 2007

Darwin Engwer, Nortel Networks

Slide 1

doc.: IEEE 802.11-07/2233r0

Submission

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 <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 <stuart.kerry@ok-brit.com> 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 <patcom@ieee.org>.

Date: 2007-07-18

Name Company Address Phone email Darwin Engwer Nortel

Networks 4655 Great America Pkwy

1-408-495-2588

dengwer@nortel.com

Authors:

July 2007

Darwin Engwer, Nortel Networks

Slide 2

doc.: IEEE 802.11-07/2233r0

Submission

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).

July 2007

Darwin Engwer, Nortel Networks

Slide 3

doc.: IEEE 802.11-07/2233r0

Submission

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.

July 2007

Darwin Engwer, Nortel Networks

Slide 4

doc.: IEEE 802.11-07/2233r0

Submission

Specific Actions Needed

• Actions required in bridges

• Actions required in 802.11 APs

• Actions required in 802.11 STA that include bridging capability

July 2007

Darwin Engwer, Nortel Networks

Slide 5

doc.: IEEE 802.11-07/2233r0

Submission

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”

July 2007

Darwin Engwer, Nortel Networks

Slide 6

doc.: IEEE 802.11-07/2233r0

Submission

Large scale 802.11 access LANwith 4A mode STA with bridging

DS

non 802.11 LAN

Infra modeSTA

AP

ACM_STA

B/C

Infra modeSTA

AP

ACM_STA

B/C4A STA

4A modeSTA withbridging

D

Portal

Bridge

non-802.11STA

non-802.11STA

non-802.11STA

Slide 9 from 11-05-0710-00

July 2007

Darwin Engwer, Nortel Networks

Slide 7

doc.: IEEE 802.11-07/2233r0

Submission

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.

July 2007

Darwin Engwer, Nortel Networks

Slide 8

doc.: IEEE 802.11-07/2233r0

Submission

Slide 9 from avb-nfinn-wireless-bridges-071307.pdf

July 2007

Darwin Engwer, Nortel Networks

Slide 9

doc.: IEEE 802.11-07/2233r0

Submission

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.

July 2007

Darwin Engwer, Nortel Networks

Slide 10

doc.: IEEE 802.11-07/2233r0

Submission

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.

July 2007

Darwin Engwer, Nortel Networks

Slide 11

doc.: IEEE 802.11-07/2233r0

Submission

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).

July 2007

Darwin Engwer, Nortel Networks

Slide 12

doc.: IEEE 802.11-07/2233r0

Submission

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.

July 2007

Darwin Engwer, Nortel Networks

Slide 13

doc.: IEEE 802.11-07/2233r0

Submission

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