1. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: 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

2. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 2 July 2006 Outline Interworking with bridged LANs poses problems with regard to reliable and predictable network operation –We need a simple solution to work well with most of our usage scenarios What cannot we do in TGs –Changing the behavior of 802.1D is out of scope Understanding the root cause helps to find a solution that is flexible as well as open-ended –And so allows future work – e.g by 802.1 – to develop better solutions

3. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 3 July 2006 Interworking with 802.1D Mesh Portal 1Mesh Portal 2 Two different meshes using two different portals for external communication – because the meshes are not connected to each via mesh links – there is no problem with loops etc

4. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 4 July 2006 Interworking with 802.1D Mesh Portal 1Mesh Portal 2 If a node can communicate with both meshes, it will allow BPDU packets to flow across both meshes – 802.1D bridges will shut down one portal

5. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 5 July 2006 What is the root problem? Multiple portals on the same or connected LAN segments –Broadcast loops/storms –portal shutdown by 802.1D because multiple paths to the same node

6. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 6 July 2006 Solutions that do not impact 802.1D 1.Configure only one mesh portal per LAN segment –Not acceptable as a general solution – if only because of back up considerations 2.Configure only one connected mesh portal in any mesh –Not acceptable as a general solution – see above 3.Portal solution - allow multiple mesh portals per LAN segment to be configured and provide protocol to select one of them as the active portal –Requires a portal arbitration protocol for connected portals 4.MP solution: allow multiple mesh portals per LAN segment but partition the mesh such that there is no mesh connection between the partitions (=broadcast domains) –Requires that MPs make use of only one connected portal –Means only one portal per broadcast domain at any time

7. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 7 July 2006 Discussion 1.and 2. solve the problem by eliminating it –By means of configuration settings 3. solves the problem at the portal level and leaves mesh points largely unaffected 4. solves the problem at the mesh point level and leaves the portals largely unaffected 3. and 4. require some means that portals are identifiable as “connected” type –Since multiple LAN segments may have multiple portals, the LAN segments must be identifiable as well –.4 requires that MPs can identify which of their connected neighbours are on the same portal Means adding some identifier to broadcasts of mesh data frames: a 802.1Q TAG or the portal MAC address

8. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 8 July 2006 Implications for the standard For 3. : Define protocol for active portal/root portal selection –Add Portal Type/LAN Segment identifiers Connected / LAN Segment ID Not Connected For 4. : Define “broadcast domain identifier” and how it is used –Allows MPs to ignore broadcasts from outside their “broadcast domain”

9. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 9 July 2006 Choices 1.No provisions in the standard: Declare the problem of loops and portal shutdown to be solved by configuration 2.Dynamically apply portal reduction to one active portal Requires a protocol as well as special configuration Implies reduction in efficiency 3.Partition the mesh such that there is one portal per “broadcast domain” Requires domain identification in broadcast e.g. 802.1Q TAG or Portal Address Provides means for broadcast efficiency, albeit with appropriate configuration

10. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 10 July 2006 Back up

11. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 11 July 2006 Scenario for case 3 Portal 1 DSL/Router Portal 3 will cause problems and should not be allowed to forward broadcasts Since TGs has no brief to solve bridging problems, its only choice is to import a solution from configuration space… PrinterCamera Portal 2 Portal 3

12. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 12 July 2006 Scenario for case 4 Separate broadcast domains can partition a network if portals that are connected are configured as portals. One could argue that the lower portal is not even a portal – it merely is a “connection” between the local devices and the mesh – it is like a MAP PrinterCamera Portal Portal 1 DSL/Router Portal 2 Video Server

13. doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 13 July 2006 Scenario for case 4 The white devices can broadcast their presence and the disconnected portals can pass broadcasts to them without problems Portal 1 DSL/Router Portal 2 Video Server PrinterCamera Portal 3 DVD player Video Portal 4