Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking...

13
Guenael Strutt, Jan Kruys Slide 1 doc.: IEEE 802.11-06/1091-r0 Submission July 2006 Interworking Considerations Date: 2006-07-19 Authors: N am e C om pany A ddress Phone em ail G uenaelStrutt Motorola 485 K ellerRd. M aitland, FL 32771 +1–407–659–5350 Guenael.Strutt@ m otorola.com Jan K ruys Cisco System s Cisco W ay 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

description

doc.: IEEE /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

Transcript of Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking...

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

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

Page 2: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 3: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 4: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 5: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 6: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 7: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 8: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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”

Page 9: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 10: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

Guenael Strutt, Jan KruysSlide 10

doc.: IEEE 802.11-06/1091-r0

Submission

July 2006

Back up

Page 11: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 12: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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

Page 13: Doc.: IEEE 802.11-06/1091-r0 SubmissionGuenael Strutt, Jan KruysSlide 1 July 2006 Interworking Considerations Date: 2006-07-19 Authors: Notice: This document.

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