doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 1 A Routing Protocol for WLAN Mesh 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 /0174r2 Submission Hang Liu, et al. March 2005 Slide 2 Abstract This presentation will outline a hybrid mesh routing protocol –Support unicast and multicast –Support on-demand routing and proactive routing –Support QoS

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 3 Outline Introducing the Hybrid Mesh Routing Protocol (HMRP) Unicast Route Establishment and Maintenance Multicast Route Establishment and Maintenance QoS Support

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 4 Introducing the Hybrid Mesh Routing Protocol (HMRP) Based on the well-studied IP layer Ad Hoc On-Demand Distance- Vector (AODV) protocol Modified for automatic topology learning and dynamic path selection in WLAN mesh networks based on MAC addresses Modified to simultaneously support on-demand and proactive routing Support unicast and multicast Support QoS

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 5 On-demand Routing vs. Proactive Routing On-demand Routing: discovers and maintains routes only when they are needed. –Pros Reduce the effects of stale routes due to topology changes (mobility, mesh point failures or powerdown, etc.) No need to maintain unused routes –Cons Extra route discovery delay and data buffering Excessive control traffic if each of mesh points individually discovers the route to a special mesh point (e.g. a mesh portal) Proactive Routing: each node maintains routes to all reachable destinations at all times, whether or not there is current need to deliver data to those destinations. –Pros Little delay –Cons High routing overhead to keep the routing information current –especially when network topology changes frequently Solution: a hybrid on-demand/proactive routing protocol

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 6 On-demand Route Establishment for Unicast On-demand routing based on Route Request/Route Reply messages, similar to AODV When a mesh point wants to send a frame to some destination mesh point, it checks its routing table for a path. –If there is a path, it forwards the frame to the next hop. –If no path, it initiates a route discovery by broadcasting a RouteRequest (RREQ) message Information in RREQ –Originator MAC address, current sequence number, optional layer 3 info –Destination MAC address, last known destination sequence number, optional layer 3 info –Message ID –Metric –Time-to-Live (TTL) –Route Lifetime

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 7 On-demand Route Discovery A mesh point receives a RREQ, –Update the metric field to the originator of the RREQ –If this is the first RREQ Establish a reverse route to this originator in its routing table. If the mesh point is the destination, –responds by unicasting a Route Reply (RREP) back to the originator. If the mesh point has a valid route for the destination and the sequence number for that destination is at least as great as that indicated in the RREQ – responds by unicasting a Route Reply (RREP) back to the originator. If the mesh point is not able to satisfy the above conditions, broadcasts the RREQ with the new metric. –If this is not the first RREQ If the new metric is better –Updates the reverse route –Replies RREP to the originator if the above conditions for replying is satisfied, or broadcast the RREQ with the new metric. Otherwise, discards the RREQ

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 8 Forward Path Setup in On-demand Routing If the mesh point is the destination or if the mesh point has a valid route for the destination and the sequence number for that destination is at least as great as that indicated in the RREQ, –Responds by unicasting a RouteReply (RREP) back to the originator. –RREP message contains Originator MAC address Destination MAC address, destination sequence number and optional layer 3 information of this destination. Metric Route Lifetime Time-to-live

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 9 Receiving RREP When an intermediate mesh point receives the RREP, –Updates the metric –Sets up a forward path in its routing table. –Forwards the RREP to the originator of the RREQ If a mesh point receives more than one RREP, –Forwards the first RREP –Updates the routing table and forwards the new RREP only if the new RREP contains a greater destination sequence number or the same destination sequence number with a better metric. Otherwise discards the new RREP. The originator can start data transmission as soon as the first RREP is received and can later update its routing information if a better route is discovered.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 10 On-demand Unicast Route Establishment Source Destination Reverse Route RREQ flooding Flooding of the route request (RREQ) message and reverse path establishment. Source Destination Forward Route RREP unicast Unicast of the route reply (RREP) message and forward path establishment.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 11 Mesh Point with Multiple Interfaces A mesh point may have multiple IEEE wireless interfaces. A unique mesh point ID –Can be one of its interface’s MAC addresses Each interface also has its own MAC address. The mesh point ID is used in the RREQ and RREP messages and other routing control messages. When a multi-interface mesh point broadcasts the RREQ message, it may broadcast the RREQ message on all its interfaces. When a multi-interface mesh point responds a RREQ message by unicasting a RREP message, it sends the RREP message on the interface on which it received the corresponding RREQ message.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 12 Routing table Routing table contains an entry for a destination. Each entry includes –Destination MAC address, destination sequence number and optional layer 3 information (supported layer 3 protocol and address, e.g. the IP address of destination mesh point)) –Next hop MAC address –Interface to the next hop –List of upstream mesh points and interfaces using this route –State and routing flags (e.g. valid, invalid) –Metric to the destination –Route Lifetime: updated each time when the route is used. The route becomes invalid if it is not used within the specified route lifetime.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 13 Proactive Routing Reduce the route discovery delay. Reduce the routing control traffic for many to one communications If a mesh point wants to advertise the route to it –Broadcasts unsolicited Route Announcement (RANN) messages Originator MAC address, destination sequence number, optional layer 3 info Route Lifetime Metric Time-to-Live (TTL) A mesh point receives a RANN, –Updates the metric field to the originator of the RANN –If no route to the originator of the RANN Creates the route in its routing table and broadcasts the RANN with the new metric. –If already has a valid route to the originator of the RANN Updates its routing table and broadcasts the RANN with the new metric only if the RANN contains a greater destination sequence number or the same destination sequence number with a better metric.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 14 Proactive Routing (Cont.) When a source wants to transmit frames to a destination, it may already have a forward path to this destination obtained from the route announcement. –It can transmit the frame immediately. –However it is possible that there is no reverse path from the destination to the source. –If bi-directional communications are needed, the source can send a gratuitous RREP in unicast to this destination. The gratuitous RREP is routed through the forward path. –Establishes a reverse path to the source.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 15 Proactive Routing (Cont.) Originator of the RANN Route to the RANN Originator RANN flooding A mesh point initiates flooding of the route announcement (RANN) messages to proactively establish the routes to it in the mesh network. Source Destination (Originator of RANN) Reverse Route to the Source Gratuitous RREP unicast A source mesh point unicasts a gratuitous route reply (RREP) to the originator of the RANN (the destination) for establishing a reverse route to the source.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 16 Route Maintenance If a link breaks, the Route Error (RERR) messages is sent to the affected originator of the active paths. –Initiated by the upstream mesh point of the broken link. –List all the unreachable destinations due to this link failure and their destination sequence number. The destination sequence number is incremented. –Transmit the RERR to its one or more upstream neighbors –When a neighbor receives a RERR from its downstream mesh point, Marks the route to the destination as invalid Propagates the RERR to its upstream mesh points –When a originator receives the RERR Re-initiates the route discovery. If a mesh point receives a data frame with a destination address for which it does not have an active route –Send a RERR message

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 17 Local Connectivity Management Send beacons (Hello message) periodically Update the route lifetime associated with the neighbor in the route table after receiving a beacon from it. If a mesh point fails to receive any beacon from a neighbor for a given hello_life. –Link to this neighbor broken. –Updates the route information for this neighbor.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 18 Non-forwarding mesh points –Some mesh points may joint the mesh only as the source or destination, i.e. not forwarding data originated from other mesh points due to process and battery limitation or other reasons. –A non-forwarding mesh point sends the RREQ when it wants to transmit frames. –A non-forwarding mesh point replies the RREQ if it is the destination. –A non-forwarding mesh point does not reply the RREQ if it is not the destination. –A non-forwarding mesh point does not forward any routing control message (RREQ, RREP, RERR, RANN).

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 19 Mesh AP with Multiple Associated Stations Multiple stations may associate a mesh AP Mesh AP acts as their proxy. Routing is transparent to the non-mesh stations. The mesh AP discovers the route to the destination when it forwards frames originated by an associated station. It also responds a RREQ for its associated stations by unicasting a RREP to the RREQ originator. The mesh AP may proactively advertise the route for its associated stations by broadcasting the RANN in the mesh network. A RANN may contain routing information for multiple destinations –Destination’s address, metric, sequence number, etc. –Each corresponds to a station.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 20 Mesh AP with Multiple Associated Stations (Cont.) Mesh AP with Proxy Station WLAN Mesh Network Infrastructure Based WLAN

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 21 Multicast Routing The same protocol supports unicast and multicast A separate multicast routing table is maintained in a mesh point. Multicast on-demand route discovery is based on route request (RREQ) and route reply (RREP), similar to unicast on-demand route discovery. A mesh point can dynamically join or leave a group at any time. Each multicast group has a group leader. The group leader maintains the multicast group sequence number. New group leader is created once the current group leader fails.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 22 Multicast Route Discovery When a mesh point wants to join a multicast group, it broadcasts a RREQ When a mesh point receives a join RREQ for a multicast group, –Updates the metric field and sets up an inactivated route for the originator of the RREQ in the multicast routing table. No data frames will be forwarded along the inactive link for the multicast group. –Establish a unicast reverse route to the originator A member of the multicast tree may reply to a join RREQ, if its recorded group sequence number is at least as great as that carried in the RREQ. The group leader shall always reply to a join RREQ. Non-multicast-tree member does not reply, but propagates the RREQ with new metric

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 23 Multicast Forward Path Establish The responding mesh point unicasts the RREP back to the originator of the RREQ along the reverse route. Intermediate mesh point receives the RREP, –Update the metric, –Set up an inactivated forward path –Forward the RREP to the next hop.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 24 Multicast Route Activation The originator may receive multiple RREPs from different members on the multicast group tree, each sets up a potential branch. The originator waits for the length of a route discovery interval and tracks the received RREP messages. It selects a path with the greatest multicast group sequence number and the best metric to the multicast tree. It activates the path to the tree at the end of the route discovery interval – Unicast a Multicast Activation (MACT) message with the join flag set along the selected path.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 25 Join the Multicast Group Flooding of RREQ message RREPs sent back to the originator of RREQ Group Leader N Unicast the MACT message with join flag set to activate the path to the multicast tree F N F Group Leader F The new branch is added F New mesh point Multicast group member Forwarding mesh point for the multicast tree Non-tree member Multicast tree link Group Leader N F N F

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 26 Leave a Multicast Group A leaf mesh point revokes its member status –Unicast a MACT with the prune flag set to its next hop –Once the next mesh point receives the prune message, it deletes the routing information for the sender. If the mesh point is not a group member and becomes a leaf –prunes itself and unicasts a prune message to its next hop. If the mesh point is a group member or it is not a leaf mesh point –Does not prune itself Unicast the MACT with prune flag set to leave the group Group Leader F F A B C F Multicast tree after pruning

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 27 Broken Tree Branch Repair When a link break occurs, the mesh point downstream of the break (i.e. the mesh point farther from the multicast group leader) repairs it. –Send a join RREQ for the multicast group with an extension field indicating the sending mesh point’s metric to the group leader. –A mesh point can respond to the RREQ by sending a RREP if it satisfies the conditions Part of the multicast tree With a group sequence number at least as great as the one in the RREQ The metric to the group leader is better than the one indicated in the RREQ –At the end of the discovery period, the repair mesh point selects its path Unicast a MACT message to activate the path.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 28 Repair of Broken Tree Link Initiate repair with RREQ A link is broken Reply RREP by the qualified tree members Activate the new links with MACT Repaired multicast tree A B Group Leader F F A B Group Leader F F A B Group Leader F F A B Group Leader F F A B Group Leader F F F

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 29 Quality of Service Support It is necessary to support QoS in WLAN mesh networks, e.g. for multimedia and voice/video applications. QoS requirements, for example, maximum delay and minimum bandwidth requirements for a data flow can be carried in the optional fields of an extended RREQ message. To respond to a RREQ with QoS extensions, a mesh point must be able to satisfy the QoS constraints. Otherwise, it discards this QoS RREQ message. After the route is established, if any mesh point along the path detects that it no longer satisfies the requested QoS parameters –Sends a route error message to the originator. –The RERR message may also carry the currently measured bandwidth and delay parameters.

doc.: IEEE /0174r2 Submission Hang Liu, et al. March 2005 Slide 30 Summary Hybrid mesh routing protocol –Based on the well-studied AODV –Support unicast and multicast –Support on-demand routing and proactive routing –Support QoS