doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 1 Thoughts on Peer Capacity Date: Authors: Notice: This document has been prepared to assist IEEE 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 2 Abstract This present discusses the issues with “Peer Capacity” field and its implications to PLM and routing

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 3 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?

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 4 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

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 5 Basic Problem: Unrealiable Announcement MP A Peer Capacity = 2 MP B Peer Link Open MP A Peer Capacity = 0 MP B Peer Link Open Peer Capacity = 0 Peer Capacity = 2

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 6 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?

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 7 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 = 0 Peer Link Open Ignore? Peer Link Close?

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 8 Further Implication: Cycles MP A Peer Capacity = 1 MP C MP B 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”

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 9 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? A B Root

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 10 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?

doc.: IEEE /0358r0 Submission March 2007 Zhao and Walker, Intel CorpSlide 11 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