1. A Hybrid Mesh Routing Protocol
July 2005
A Hybrid Mesh Routing Protocol
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 < ieee802.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 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

2. Abstract Our proposal (doc.: IEEE 802.11-05/0590r0) describes
July 2005
Abstract
Our proposal (doc.: IEEE /0590r0) describes
an extensible mesh routing architecture
a hybrid mesh routing protocol
Simultaneously support reactive routing and proactive routing
Support unicast and multicast routing

3. Extensible mesh routing architecture
July 2005
Outline
Extensible mesh routing architecture
Introducing the Hybrid Mesh Routing Protocol (HMRP)
Unicast Route Establishment and Maintenance
Multicast Route Establishment and Maintenance

4. Extensible Mesh Routing Architecture
July 2005
Extensible Mesh Routing Architecture
Flexible and extensible protocol architecture to allow for alternative routing protocols and/or path selection metrics to meet different application requirements and optimize the performance.
In beacon and probe response messages, advertise
the routing protocol and metric used by the mesh network

5. On-demand Routing vs. Proactive Routing
July 2005
On-demand Routing vs. Proactive Routing
On-demand (reactive) Routing: discovers and maintains routes only when they are needed.
Pros
Reduce the effects of stale routes and overhead 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
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

6. Introducing the Hybrid Mesh Routing Protocol (HMRP)
July 2005
Introducing the Hybrid Mesh Routing Protocol (HMRP)
Simultaneously support on-demand and proactive routing
Proactively establish and maintain the route to one or more mesh portals (or other major data sources or sinks) via route announcement
On-demand (reactive) routing between MPs for peer-to-peer communications using modified AODV
Modified for MAC address-based routing
Support QoS/radio/power-aware metric

7. On-demand Route Establishment for Unicast
July 2005
On-demand Route Establishment for Unicast
On-demand routing based on AODV (RFC 3561) using Route Request/Route Reply messages
When a mesh point wants to send a frame to some destination mesh point, it checks its routing table for a valid path.
If there is a valid path, it forwards the frame to the next hop.
If no valid 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
RREQ ID, Hop count, Metric, Time-to-Live (TTL), Flags

8. AODV-Based On-demand Unicast Route Establishment
July 2005
AODV-Based 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.

9. Routing table Routing table contains an entry for a destination.
July 2005
Routing table
Routing table contains an entry for a destination.
Each entry includes
Destination MAC address, destination sequence number and optional layer 3 information (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)
Hop count to the destination
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.

10. Proactive Route Establishment
July 2005
Proactive Route Establishment
Reduce the route discovery delay and buffer requirement.
Reduce the routing overhead for many to one communications
A mesh portal (or other special node) can optionally advertise the route to it
Broadcasts unsolicited Route Announcement (RANN) messages
Establish a route to the mesh portal (the originator of the RANN) in the mesh network
If bi-directional communications are needed, the MP can send a gratuitous RREP in unicast to the mesh portal (if the corresponding flag is set in the RANN).
The gratuitous RREP is routed to the mesh portal through the forward path.
Establishes a reverse path to the RREP originator.
Support multiple mesh portals and other special nodes (servers, major data sinks/sources) in a mesh network

11. Proactive Route Establishment to Mesh Portal
July 2005
Proactive Route Establishment to Mesh Portal
RANN flooding
Route to the RANN Originator
Mesh portal
initiates RANNs
A mesh portal initiates flooding of the route announcement (RANN) messages to
proactively establish the routes to it in the mesh network.
Gratuitous RREP unicast
Reverse Route
A mesh point unicasts a gratuitous route reply (RREP) to the mesh portal to establish a reverse route from the mesh portal to the mesh point for bi-directional path.

12. July 2005
Route Maintenance
If a link breaks, the Route Error (RERR) messages is sent to the affected source 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.
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 the source of the route 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

13. Non-forwarding Mesh Points
July 2005
Non-forwarding Mesh Points
Non-forwarding mesh points
Some mesh points may join the mesh only as the source or destination, i.e. not forwarding data originated from other mesh points due to processing 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).

14. Mesh AP with Multiple Associated Stations
July 2005
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 for the associated STAs
Mesh AP
with
Proxy
Station
WLAN Mesh Network
Infrastructure
Based WLAN

15. QoS, Radio and Power-Aware Routing Metric Support
July 2005
QoS, Radio and Power-Aware Routing Metric Support
The proposed routing protocol allows using/optimizing QoS, radio and battery power aware metric
The metric used by the mesh network is advertised in beacon and probe response.
Carried in the routing messages to discover the path with the best metric.
QoS and radio aware metrics include all aspects of MAC/PHY statistics such as latency, link rate, link available capacity, PER, noise, etc.
Power aware metrics include available battery power/energy, power consumption, etc.

16. Multicast Routing Efficient multicast support is important
July 2005
Multicast Routing
Efficient multicast support is important
Application examples: network games, IPTV
Our multicast tree establishment is based on multicast AODV with modifications
A mesh point can dynamically join or leave a multicast 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.

17. Join the Multicast Group
July 2005
Join the Multicast Group
Group Leader N F N
New mesh point
Multicast group member
Forwarding mesh point for the multicast tree F
Non-tree member
RREPs sent back to the originator of
RREQ
Flooding of RREQ message
Multicast tree link
Group Leader
Group Leader F
The new branch is added F N
Unicast the MACT message with join flag
set to activate the path to the multicast tree

18. Leave a Multicast Group
July 2005
Leave a Multicast Group
A leaf mesh point leaves its multicast group
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 in its multicast routing table.
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
Group Leader F A B C
Group Leader F
Unicast the MACT with prune flag
set to leave the group
Multicast tree after pruning

19. Repair of Broken Tree Link
July 2005
Repair of Broken Tree Link A B
Group
Leader F A B
Group
Leader F A B
Group
Leader F
A link is broken
Initiate repair with RREQ
Reply RREP by the qualified
tree members A B
Group
Leader F A B
Group
Leader F
Activate the new route with MACT
Repaired multicast tree

20. Summary Extensible mesh routing architecture
July 2005
Summary
Extensible mesh routing architecture
Allow for alternative routing protocols/path selection metrics based on deployment scenarios and application requirements.
Hybrid mesh routing protocol
Support on-demand (reactive) routing and proactive routing
Combine the advantages of these two types of routing mechanisms
Proactively establish and maintain the route to one or more mesh portals (or other major data sources or sinks) via route announcement
On-demand routing between MPs for peer-to-peer communications using the modified AODV
Support QoS/radio/power-aware metric
Support unicast and multicast routing

21. Thank You! Any suggestions or comments?
July 2005
Thank You! Any suggestions or comments?

22. July 2005
Backup Slides

23. On-demand Route Discovery
July 2005
On-demand Route Discovery
A mesh point receives a RREQ,
Update the hop count and metric field to the originator in the RREQ
If this is the first RREQ
Establish a reverse route to this originator in its routing table with the MP from which the RREQ is received as the next hop.
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 destination sequence number for that destination is at least as great as that indicated in the RREQ
If the mesh point is not able to satisfy the above conditions, broadcasts the RREQ with the new hop count and metric.
If this is not the first RREQ
If the sequence number for the originator in the received RREQ is higher or the sequence number is equal but the new metric is better than the one maintained in the routing table
Updates the reverse route with the MP from which the RREQ is received as the next hop.
Replies RREP to the originator if the above conditions for replying is satisfied, or broadcast the RREQ with the new hop count and metric.
Otherwise, discards the RREQ

24. Forward Path Setup in On-demand Routing
July 2005
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.
Hop count
Metric
Flags
Route Lifetime
Time-to-live

25. July 2005
Receiving RREP
When an intermediate mesh point receives the RREP,
Updates the hop count and metric
Sets up a forward path to the destination in its routing table with the MP from which the RREP is received as the next hop.
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.

26. July 2005
Proactive Routing
When a source wants to transmit frames to a destination, it may already have a forward path to this destination established from the route announcement of the destination.
It can transmit the frame immediately.
However it is possible that there is no reverse path from the destination to the source.
If the 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 originator of the RREP.

27. Proactive Route Establishment
July 2005
Proactive Route Establishment
Reduce the route discovery delay and buffer requirement.
Reduce the routing control overhead for many to one communications
A mesh portal (or other special node) can optionally advertise the route to it
Broadcasts unsolicited Route Announcement (RANN) messages
Originator MAC address, originator’s sequence number, optional layer 3 info, Route Lifetime, Hop Count, Metric, Flags, Time-to-Live (TTL).
A mesh point receives a RANN,
Updates the hop count and metric field to the originator in the RANN
If no route to the originator of the RANN
Creates the route to the RANN originator in the routing table with the MP from which the RANN is received as the next hop
broadcasts the RANN with the new hop count and metric.
If already has a valid route to the originator of the RANN
Updates its routing table and broadcasts the RANN with the new hop count and metric only if the RANN contains a greater destination sequence number or the same destination sequence number with a better metric.
If bi-directional communications are needed, the MP can send a gratuitous RREP in unicast to the mesh portal (if the corresponding flag is set in the RANN).
The gratuitous RREP is routed to the mesh portal through the forward path.
Establishes a reverse path to the RREP originator.

28. Mesh AP with Multiple Associated Stations
July 2005
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 one of its associated stations.
The MAP also responds a RREQ for its associated stations by unicasting a RREP to the RREQ originator.
The mesh AP/portal 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, hop count, metric, sequence number, etc.
Each corresponds to a destination.
When a STA moves from one MAP to another, the new MAP rediscovers the route to the destination by sending a RREQ
The old MAP would respond the RREQ with RREP since it has a route to the destination.
The new MAP would use this route to send the data frames to the destination.
The old MAP would use this route to forward the data frames destined for the moved STA to the new MAP.
A better route may be discovered between the new MAP and the destination later, the new MAP would be switched to the better route if this happens.

29. Multicast Route Discovery
July 2005
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 hop count and metric fields and sets up an inactivated route to the originator of the RREQ in the multicast routing table with the MP from which it received the RREQ as the next hop.
No data frames will be forwarded along the inactive link for the multicast group.
Establish a unicast reverse route to the originator with the MP from which it received the RREQ as the next hop.
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 the new hop count and metric

30. Multicast Forward Path Establish
July 2005
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 hop count and metric,
Set up an inactivated forward path with the MP from which the RREP is received as the next hop.
Forward the RREP to the next hop.

31. Multicast Route Activation
July 2005
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.

32. Broken Tree Branch Repair
July 2005
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.

33. QoS and Power Aware Path Selection
July 2005
QoS and Power Aware Path Selection
QoS, Radio and Power Aware Metrics can also be carried in the extended route request and route reply messages as the constraints.
QoS, radio and power requirements/constraints, e.g., maximum delay and/or minimum bandwidth requirements and/or minimum battery power requirement for a data flow can be carried in the optional fields of an extended RREQ message.
To propagate or respond to a RREQ with QoS extensions, a mesh point must be able to satisfy the QoS, radio and battery power 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, radio and power parameters
Sends a route error message to the originator.
The RERR message may also carry the currently measured bandwidth, delay, and battery power parameters.

34. Interaction between ARP and Route Establishment
July 2005
Interaction between ARP and Route Establishment
We are dealing with layer-2 routing
The mapping between the IP address and MAC address must be known before a data frame can be generated and layer-2 route discovery occurs
Two steps: (1) ARP, (2) layer-2 route discovery
Use the proposed route announcement (RANN) to simplify and speed up the process: two steps => one step
Before sending an ARP request, a source MP may optionally send a RANN so that the route to it is established.
Route announcement information may be optionally piggybacked with ARP request broadcast
Before sending an ARP reply, a target MP may optionally send a gratuitous RREP so that the route to the target MP is established.
A mesh AP can proxy the ARP request for its associated STAs.