1. doc.: IEEE 802.11-05/0641r1 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/0641r1 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/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 3 Introduction Mesh is way of putting networks together – not a technology IEEE standards are intended to have broad applicability Taking a step back Networks are used for many purposes There is no single best “way” TGs has to address many ways of using mesh networks

4. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 4 Main dimensions of (mesh) networking These four dimensions are actually two pairs of opposing dimensions Having your cake and eating it does not go together We have to make choices or offer alternatives The users will decide whether we did the right thing mobility simplicity functionality Network size

5. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 5 The focus of this proposal Simplicity and the ability to handle large scale networks is a key to major market segments like municipal and enterprises networks Home and small business are implicitly supported (Mesh) functionality and mobility not maximized mobility simplicity functionality Network size

6. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 6 Basic Requirements Connectivity – hooking nodes together Security – protect data and the network QoS – to meet the needs of users Management – to control the network Discovery, binding and routing – new work 802.11i/w/r – with minimal adaptations 802.11e – possibly without adaptations 802.11 base + exten- sions for mesh services What How

7. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 7 Basic Services Connectivity Security QoS Management Category Specifics Mesh Topology Discovery Probing/Beaconing Modes of binding Data Routing/Forwarding Interworking Support Node Authentication Intra-mesh Key Management Traffic classes Intra-Mesh Congestion Control RF channels Binding Criteria Master Key and Credentials QoS Management

8. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 8 Optional Services ?? Connectivity Security QoS Management Category Specifics

9. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 9 Routing/Forwarding at Layer 2 Todate, the wired world relies on STP – which is still developing and improving But STP is not “wireless aware” Changing that takes time Little experience with wireless Layer 2 routing Most work is concentrating on Layer 3 solutions –Many products combine Layer 2 and Layer 3 — which improves flexibility “down porting” of Layer 3 solutions to Layer 2 risks mixing incompatible designs and functions Issues with IP and 802 LAN Interworking

10. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 10 Our proposal: Use a simplified version of STP as baseline –Serves a broad range of wireless environments Rely on extensibility of the standard to allow –A wireless version of STP to be incorporated as it is developed by 802.1 –Other, application specific routing protocols

11. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 11 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

12. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 12 TBR Example: Home 6 devices from two simple trees with a number of back-up paths CABLE HDTV PC3 PC2 PC1 ENT. Srvr ENT.SVR HDTV PC1 CABLE PC3 PC2

13. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 13 TBR Example: wireless LAN in an SMB APs in the workshops and offices are connected by two trees, both rooted in the same fibre feedpoint AP Fibre feedpoint

14. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 14 active links alternate/backup links Root (Portal) Branch Node Leaf Node TBR Example: Hotspot/Municipal Six trees of Access Points, all rooted in one portal Any of the “cells” can be the root of a back-up tree

15. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 15 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

16. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 16 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

17. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 17 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 easier: 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

18. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 18 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

19. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 19 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 mesh node addresses from unicasts 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

20. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 20 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

21. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 21 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. B9 has a path to A and to B. No coupling between trees at common nodes Root A A4 A9 A5 Root B B3 B9 B5 B6 B4 A8 A7

22. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 22 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

23. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 23 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

24. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 24 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

25. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 25 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.

26. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 26 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

27. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 27 Message Formats - general Define new Type/Subtype for mesh specifics like topology functions Subtypes for control, data, management Minimize new message definitions – encapsulate existing ones Mesh header can provide additional context – if needed Maximizes re-use of exiting functions Would allow – but not require – transparent tunneling within the mesh

28. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 28 Message Formats - topology discovery and maintenance Neighbour Request (broadcast and unicast) Neighbour Response (unicast, periodic broadcast optional) MAC HDR (Mesh type) Mesh ID Request Code Candidate Address FCS MAC HDR (Mesh Type) Mesh ID Response Code Mesh Info # of Uplinks Per uplink Root IDRoot Info Path cost FCS

29. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 29 Message Formats - binding Binding Request (unicast) Binding Response (unicast) MAC HDR (Mesh type) Mesh ID Binding Request Code Payload = 802.11 Ass. Req. FCS MAC HDR (Mesh type) Mesh ID Binding Response Code Payload = 802.11 Ass. Resp. FCS

30. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 30 Message Formats - data transmission & management MAC HDR (Mesh Type) Mesh IDData or Man’t encap Flow control = up (down) Payload (source packet) FCS Unicast Broadcast MAC HDR (Mesh Type) Mesh IDData or Man’t encap Flow control = up (down) Payload (source packet) FCS

31. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 31 Summary The tree based routing protocol proposed here meets all basic requirements It is very 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 specific applications or market segments, can be detailed and specified separately – possibly as options in annexes to the standard or as open, published specifications

32. doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 32 What the standard has to contain All information needed for baseline interoperability Message formats Behaviour associated with message processing and generation Baseline interoperability Mesh discovery –Including routing scheme resolution and optional feature detection/exchange Mesh binding – minimum subset –802.11i based binding –Extension by options Data forwarding – by encapsulation –Extension by options Basic management functions –Extension by options

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