Guenael Strutt, Jan KruysSlide 1
doc.: IEEE 802.11-06/1091-r0
Submission
July 2006
Interworking ConsiderationsDate: 2006-07-19
Authors:Name Company Address Phone email
Guenael Strutt Motorola 485 Keller Rd. Maitland, FL 32771 +1–407–659–5350 [email protected]
Jan Kruys Cisco Systems Cisco Way Bld 14 San Jose, CA
+ 31 348 453719 [email protected]
?
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 <[email protected]> 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 <[email protected]>.
Guenael Strutt, Jan KruysSlide 2
doc.: IEEE 802.11-06/1091-r0
Submission
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
Guenael Strutt, Jan KruysSlide 3
doc.: IEEE 802.11-06/1091-r0
Submission
July 2006
Interworking with 802.1D
Mesh Portal 1 Mesh 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
Guenael Strutt, Jan KruysSlide 4
doc.: IEEE 802.11-06/1091-r0
Submission
July 2006
Interworking with 802.1D
Mesh Portal 1 Mesh 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
Guenael Strutt, Jan KruysSlide 5
doc.: IEEE 802.11-06/1091-r0
Submission
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
Guenael Strutt, Jan KruysSlide 6
doc.: IEEE 802.11-06/1091-r0
Submission
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
Guenael Strutt, Jan KruysSlide 7
doc.: IEEE 802.11-06/1091-r0
Submission
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
Guenael Strutt, Jan KruysSlide 8
doc.: IEEE 802.11-06/1091-r0
Submission
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”
Guenael Strutt, Jan KruysSlide 9
doc.: IEEE 802.11-06/1091-r0
Submission
July 2006
Choices1. 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
Guenael Strutt, Jan KruysSlide 10
doc.: IEEE 802.11-06/1091-r0
Submission
July 2006
Back up
Guenael Strutt, Jan KruysSlide 11
doc.: IEEE 802.11-06/1091-r0
Submission
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…
Printer Camera
Portal 2
Portal 3
Guenael Strutt, Jan KruysSlide 12
doc.: IEEE 802.11-06/1091-r0
Submission
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
Printer Camera
Portal
Portal 1
DSL/Router
Portal 2
Video Server
Guenael Strutt, Jan KruysSlide 13
doc.: IEEE 802.11-06/1091-r0
Submission
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
Printer Camera
Portal 3
DVD player Video
Portal 4