1. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 1 Tree Based Routing Protocol 2005-07-11 NOTE: this document replaces document 11-05-0607-00-000s wstp-mesh-presentation 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org

2. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 2 Agenda Introduction Baseline for TGs: tree based routing Description Message formats Summary

3. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 3 Introduction STP is a standard "routing" mechanism in layer 2 networks However, STP cannot yet be considered as part of 802.11s because: It has not been optimized for a wireless environment It will take some time for 801.1 to make the optimizations What "routing" protocol should be used in 802.11s? A simple version of STP designed for a broad range of wireless environments Extensibility of the standard allows a wireless version of STP to be incorporated as it is developed by 802.1 - as well as application specific routing protocols

4. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 4 Baseline solution for TGs: Tree based routing Aimed at the typical access network: “fixed” installations but that also works well for small, flat meshes Organises mesh points into tree structures rooted in major information sources/sinks: –Portals to other (sub)networks - in any scenario –Local Servers - in the office –Screens, DVDs, PCs at home Applications with more demanding requirements are better served by routing schemes that focus on mobility and frequent configuration change

5. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 5 Tree Construction Trees are easy to construct and maintain: - N sends out a request and gets responses - N learns the path to the root (distance vector, link metrics) - N picks the best and links up Pre-conditions: - Roots announce themselves - Mesh points recognize roots (like STA’s recognize IBSS’ses Root N 4 7 5

6. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 6 State Machine (per tree) Seek Potential Upstream neighbour More candidates All good neighbours associated Associate Monitor Activate back-up in case a link fails Lost path to root

7. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 7 Link Metrics The question is: “will my packet make it quickly to the root” Factors that play a role: net link rate, current load uplink and hop count to root Further (radio metric) detail data is overkill SNR is a good predictor of net link rate Going down link is easy: traffic fans out Routing metric data reported by neighbours: upstream SNR and load, hops Supports simple distributed congestion control Processing and decision making is a local matter and outside scope

8. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 8 Security and Maintenance Security: - node authentication per 802.11i with AAA server based or PSK/ certificate based - data security by link level encryption Maintenance: - regular neighbor status checks Recovery: - re-do construction but only towards the root Root N 4 7 5

9. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 9 Internal Addressing Each root (portal, server, etc) has its own tree = its own subnet. It may have more than one. Each mesh access point advertises the subnets it is on to STAs (e.g. by different SSIDs) ARP broadcasts from STAs are sent on the subnet chosen by the STA Intermediate mesh points learn end node addresses from unicasts – see next slide -Portals learn STA addresses and the path they are on – if the path changes, the portal updates the path Loops are prevented by ignoring downstream broadcasts that carry the own source address

10. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 10 Forwarding and Interworking Edge nodes encapsulate STA packets, add a “mesh” header and transmit the packet up the tree Mesh points that receive such a packet pass it on and update the “down path” if necessary A portal updates its local routing tables and passes the de- capsulated packet to the wire Unicast packets from the wire are encapsulated sent down the tree -Portals may perform proxy ARP and proxy DHCP to avoid forwarding broadcasts between inside and outside

11. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 11 Multiple Trees Multiple portals = multiple roots A root can be any node that is a source or sink of information One node can be on two trees: e.g. B7 has a path to A and to B. No coupling between trees Root A A4 A7 A5 Root B B3 B7 B5

12. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 12 QoS/Overlapping trees Basic QoS through use of 802.11e More advanced QoS: use multiple trees for multiple service levels Traffic classes are mapped to trees as required No special protocol needed Root A A7 A5 Root B B7 B5

13. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 13 MP and STA Mobility Mesh points: Mesh point mobility is handled by hooking up to another node 802.11 STAs: Mesh (access) points, and portals learn addresses and keep routing tables Root A A7 A5 STA A2

14. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 14 Scalability Replication allows scaling to almost any size network Root/Bridge Mesh 1 Root/Bridge Mesh 2 Root/Bridge Mesh 4 Root/Bridge Mesh 3 RSTP /MST

15. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 15 Other aspects Quick to configure/recover (see next slide) Transparent to the use of single or multiple radios Compatible with any security scheme Orthogonal to power save modes, lightweight binding, etc.

16. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 16 Configuration time - example No Flooding: One hop Neighbour Requests drive the process A node keeps “polling” until it finds a suitable path Assuming a 50msec poll cycle, it takes 3 to 5 cycles to get the tree mapped = < 250msec The medium load is in the range of 84 to 140 packets = <50msec or < 20% 8 Requests, 8 Responses 4 Requests, 4 Responses 2 Requests, 2 Responses

17. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 17 Message Formats Neighbour Request Neighbour Response MAC HDR (Mesh type) Mesh ID Request Code Candidate Address FCS MAC HDR (Mesh Type) Mesh ID Response Code # of Uplinks For each Uplink Root IDFor each Root Root Info Path cost FCS

18. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 18 Message Formats Data transmission & management MAC HDR (Mesh Type) Mesh ID Flow control Payload (source packet) FCS

19. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 19 TGs Mesh Requirements covered MAC-based protocol and algorithm Dynamic auto-configuration Support unicast, broadcast, multicast Transparent for existing 802.11 implementations Alternative path selection metrics and/or protocols Support for single or multiple radios on mesh points Scalable to 32 mesh points and beyond At least one radio-aware routing metric

20. doc.: IEEE 802.11-05/0641r0 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 20 Summary The tree based routing protocol proposed here meets all basic requirements It is extremely simple to implement and effective in practical use It would serve nicely as a low cost baseline for the TGs standard Tree based routing is an easy first step towards a full blown wireless bridging protocol that we can leave to 802.1 to develop Other routing protocols that meet the specific needs of selected applications can be detailed and specified separately – possibly as options in annexes to the standard