March 2007 doc IEEE 802 11 070358 r

  • Slides: 11
Download presentation
March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Thoughts on Peer Capacity

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Thoughts on Peer Capacity Authors: Date: 2007 -03 -15 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: // ieee 802. 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 <stuart. kerry@philips. com> 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 <patcom@ieee. org>. Submission 1 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Abstract This present discusses

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Abstract This present discusses the issues with “Peer Capacity” field and its implications to PLM and routing Submission 2 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Comments on Peer Capacity

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Comments on Peer Capacity • General comments: CIDs 2299, 4336, 471, 1158, 1918, 7, 337, 2130, 2132, 3954 • Security comments: CID 5860, 1302 • Issues – What’s the meaning of peer capacity or peer link available field? – Suggest peer link management protocol handles the usage of it – Can it be removed completely? Submission 3 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 General Usage • Peer

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 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 C − l • 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 Submission 4 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Basic Problem: Unrealiable Announcement

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Basic Problem: Unrealiable Announcement Peer Capacity = 2 0 MP A Peer Link Open MP B Peer Capacity = 2 0 MP A Submission Peer Link Open 5 MP B Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Concerns • Beacon is

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 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 Do. S • Question: – Does “peer capacity” field serve the purpose? – Can we remove this field? – Should there be a capacity limit at all? Submission 6 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Further Implication: Delayed Procedure

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Further Implication: Delayed Procedure Peer Capacity = 0 Peer Link Open MP A Peer Link Close? Ignore? • If MP A is still capable of respond • If MP A is not capable of respond (e. g. , not allowed to generate more FSM) – Either silently discard the request – Or send Peer Link Close to reject Submission – Have to silently ignore the request 7 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Further Implication: Cycles •

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Further Implication: Cycles • MPs should have at least one spare link instance to reject link establishment requests • More robust to support simultaneous attempts • Example: Peer Capacity = 1 MP C – Resource supports 10 link instances – MP uses 9 (established and pending) – MP reserves 1 link instance to send “peer link close” Submission Peer Capacity = 1 MP A MP B Peer Capacity = 1 8 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Even More: Network Partition

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 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 Root – 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? A B • Higher priority to MPs who sent routing messages? • Feasibility? Complexity? Submission 9 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Implications • Peer capacity

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Implications • Peer capacity implies 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 – Entire 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 • Should MPs simply just support n– 1 links, where n = number of MPs in the mesh? Submission 10 Zhao and Walker, Intel Corp

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Conclusions • Peer capacity

March 2007 doc. : IEEE 802. 11 -07/0358 r 1 Conclusions • Peer capacity is used for limit number of supported links • It is useful for reserving link instance to reject requests • Inefficiency in PLM and routing – Due to lack of system requirements – Global view of network topology and routing topology • Call for more discussions on peer capacity – – – Submission Useful? System requirements? Routing implication? Interaction between routing and PLM? And more? 11 Zhao and Walker, Intel Corp