Upload
vernon-hawkins
View
217
Download
2
Embed Size (px)
Citation preview
March 2007
Zhao and Walker, Intel Corp
Slide 1
doc.: IEEE 802.11-07/0358r0
Submission
Thoughts on Peer Capacity
Date: 2007-03-15
Name Company Address Phone email
Meiyuan Zhao Intel Corporation RNB-6-61, 2200 Mission College Blvd, Santa Clara, CA 95052
+1-408-653-5517 [email protected]
Jesse Walker Intel Corporation JF3-206, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
+1-503-712-1849 [email protected]
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 <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]>.
March 2007
Zhao and Walker, Intel Corp
Slide 2
doc.: IEEE 802.11-07/0358r0
Submission
Abstract
This present discusses the issues with “Peer Capacity” field and its implications to PLM and routing
March 2007
Zhao and Walker, Intel Corp
Slide 3
doc.: IEEE 802.11-07/0358r0
Submission
Comments on Peer Capacity
• General comments: CIDs 2299, 4336, 471, 1158, 1918, 7, 337, 2130, 2132, 3954
• Security comments: CID 5860
• Issues– What’s the meaning of peer capacity or peer link available field?
– Suggest peer link establishment protocol handles the usage of it
– Can it be removed completely?
March 2007
Zhao and Walker, Intel Corp
Slide 4
doc.: IEEE 802.11-07/0358r0
Submission
General Usage
• Peer Capacity is used to control the maximum number of peer links allowed by the MP
• The MP– Announce peer capacity in beacons/probe responses
– Set the value to (capacity - # current peer links)
• The neighboring MP– Decide to initiate the peer link management protocol if the “mesh
capacity” field is non-zero in the received beacons/probe responses
March 2007
Zhao and Walker, Intel Corp
Slide 5
doc.: IEEE 802.11-07/0358r0
Submission
Basic Problem: Unrealiable Announcement
MP A
Peer Capacity = 2
MP BPeer Link Open
MP A
Peer Capacity = 0
MP BPeer Link Open
Peer Capacity = 0
Peer Capacity = 2
March 2007
Zhao and Walker, Intel Corp
Slide 6
doc.: IEEE 802.11-07/0358r0
Submission
Concerns
• Beacon is an unreliable announcement for making decision on PLM protocol initiation
• Protocol can fail (and delayed) when peer capacity > 0
• Protocol could succeed when peer capacity = 0
• In addition, the peer capacity field is the utility enabling DoS
• Question:– Does “peer capacity” field serve the purpose?
– Can we remove this field?
– Should there be a capacity limit at all?
March 2007
Zhao and Walker, Intel Corp
Slide 7
doc.: IEEE 802.11-07/0358r0
Submission
Further Implication: Delayed Procedure
• If MP A is still capable of respond– Either silently discard the
request
– Or send Peer Link Close to reject
• If MP A is not capable of respond (e.g., not allowed to generate more FSM)– Have to silently ignore the
request
MP A
Peer Capacity = 0Peer Link Open
Ignore?Peer Link Close?
March 2007
Zhao and Walker, Intel Corp
Slide 8
doc.: IEEE 802.11-07/0358r0
Submission
Further Implication: Cycles
MP A Peer Capacity = 1
MP C MP B
Peer Capacity = 1
Peer Capacity = 1
• MPs should have at least one spare link instance to reject link establishment requests
• More robust to support simultaneous attempts
• Example:– Resource supports 10 link
instances
– MP uses 9 (established and pending)
– MP reserves 1 link instance to send “peer link close”
March 2007
Zhao and Walker, Intel Corp
Slide 9
doc.: IEEE 802.11-07/0358r0
Submission
Even More: Network Partition• Connected network of n MPs ≥ n-1 links
• Hard to use local operation (e.g., peer capacity) to control the global network topology
• Implications– Tree-based routing vulnerable to
topology changes
– MPs should be able to support at least 2 links
– Peer Link Establishment be aware of tree topology?• Either allow RANN without link
• Or remember previous RANN?
• Policy violation? Feasibility? Complexity?
AB
Root
March 2007
Zhao and Walker, Intel Corp
Slide 10
doc.: IEEE 802.11-07/0358r0
Submission
Implications
• Suggest several system requirements– Each MP supports at least two peer links
– Each MP supports at least one spare link instance to reject Peer Link Open requests
– Mesh supports at least n-1 peer links
• For global view of routing– Need more understanding of PLE implications to routing
– Construct PLM and routing interaction?• New link metric: routing connectivity
– Modify tree-based routing?
• Should MPs simply just support n–1 links, where n = number of MPs in the mesh?
March 2007
Zhao and Walker, Intel Corp
Slide 11
doc.: IEEE 802.11-07/0358r0
Submission
Conclusions
• “Peer Capacity” field is less useful than we thought
• Inefficiency in PLM and routing– Due to lack of system requirements
– Global view of network topology (routing topology)
• Call for more discussions on peer capacity– Necessary?
– System requirements?
– Routing implication?
– Interaction between routing and PLM