1. A Hybrid Mesh Routing Protocol
June 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. Additional Supporting Material
June 2005
Additional Supporting Material
Number
Name
Definition
Coverage
(Yes/No)
Notes
References
AD1
Reference submissions
A list of IEEE 802 submissions related to the proposal, both documents and presentations. No
AD2
Simulation and/or experimental methodology
Any proposal submission that includes simulation results must include a description of the simulation methodology used for mesh simulations. The simulation methodology documentation should provide enough information to, in principle, reproduce the simulation (e.g., including node positions, traffic and propagation model (including PHY assumptions), packet sizes, etc.).

3. Coverage of Minimum Functional Requirements
June 2005
Coverage of Minimum Functional Requirements
Number
Category
Name
Coverage
(Complete /Partial/ None)
Notes
References
FR1
TOPO_RT_FWD
Mesh Topology Discovery
Complete
FR2
Mesh Routing Protocol
FR3
Extensible Mesh Routing Architecture
FR4
Mesh Broadcast Data Delivery
None
FR5
Mesh Unicast Data Delivery
FR6
Support for Single and Multiple Radios
FR7
Mesh Network Size 32
FR8
SECURITY
Mesh Security
FR9
MEAS
Radio-Aware Routing Metrics
FR10
SERV_CMP
Backwards compatibility with legacy BSS and STA
FR11
Use of WDS 4-Addr Frame or Extension
FR12
DISC_ASSOC
Discovery and Association with a WLAN Mesh
FR13
MMAC
Amendment to MAC with no PHY changes required
FR14
INTRWRK
Compatibility with higher-layer protocols

4. Coverage of In-Scope Functions (Informative)
June 2005
Coverage of In-Scope Functions (Informative)
Number
Name
Coverage
Yes / No / N/A
Notes
References
Mesh Topology Learning, Routing, and Forwarding (TOPO_RT_FWD)
TOPO_RT_FWD_SCP1
Mesh topology discovery, including Mesh Point neighbor discovery within a WLAN Mesh
Yes
TOPO_RT_FWD_SCP2
MAC address-based mesh routing protocols and algorithms
yes
TOPO_RT_FWD_SCP3
MAC-layer mesh broadcast/multicast and unicast data delivery
TOPO_RT_FWD_SCP4
Architecture to support alternative routing protocols and metrics
TOPO_RT_FWD_SCP5
Mesh routing with single-radio devices
TOPO_RT_FWD_SCP6
Mesh routing with multiple-radio devices
TOPO_RT_FWD_SCP7
Use of radio-aware route selection metrics
TOPO_RT_FWD_SCP8
QoS-based route selection
TOPO_RT_FWD_SCP9
Proactive routing no
TOPO_RT_FWD_SCP10
On-demand routing
TOPO_RT_FWD_SCP11
Hybrid routing
TOPO_RT_FWD_SCP12
Mesh Point neighbor discovery within a WLAN Mesh via passive scanning

5. Coverage of In-Scope Functions (Informative) (Cont.)
June 2005
Coverage of In-Scope Functions (Informative) (Cont.)
Number
Name
Coverage
Yes / No / N/A
Notes
References
TOPO_RT_FWD_SCP13
Mesh Point neighbor discovery within a WLAN Mesh via active scanning no
TOPO_RT_FWD_SCP14
Mesh routing in the presence of low-power (e.g. battery-powered) Mesh Points
yes
TOPO_RT_FWD_SCP15
Support for WLAN Mesh network configurations with more than 32 Mesh Points.
TOPO_RT_FWD_SCP16
Ability to recognize changes in the topology within a bounded time
TOPO_RT_FWD_SCP17
Ability to reconfigure the routing scheme within a bounded time in response to detected changes
TOPO_RT_FWD_SCP18
SAP interfaces and management primitives to provide support to enable higher-layer (e.g., Layer 2.5 and Layer 3) routing protocols
TOPO_RT_FWD_SCP_Other

6. June 2005
Abstract
This propose describes an extensible mesh routing architecture and a hybrid mesh routing protocol.
Support on-demand routing and proactive routing
Support unicast and multicast

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

8. Extensible Mesh Routing Architecture
June 2005
Extensible Mesh Routing Architecture
Flexible and extensible protocol architecture to allow for alternative path selection metrics and/or routing protocols to meet different application requirements and optimize the performance.
One protocol is operated in a specific mesh network for interoperability
In beacon and probe response messages, advertise
Routing capability IE
The routing protocols and metrics supported by the MP
The protocol and metric that the current mesh network chooses to use (chosen routing protocol and metrics).
Forwarding capability IE
Whether this MP is capable of forwarding the frames of a traffic class initiated by the other MPs.
Used for MPs at network edge that do not support forwarding
Used for battery power-aware MPs that are not willing to perform forwarding
Whether this MP is capable of forwarding the multicast/broadcast traffic

9. On-demand Routing vs. Proactive Routing
June 2005
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 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

10. Introducing the Hybrid Mesh Routing Protocol (HMRP)
June 2005
Introducing the Hybrid Mesh Routing Protocol (HMRP)
Simultaneously support on-demand and proactive routing
On-demand establishment of the route from one MP to another MP
Based on the well-studied Ad Hoc On-Demand Distance-Vector (AODV) protocol and modified for MAC address-based routing
Proactively establish and maintain the route to mesh portals or other special MPs (optional)

11. On-demand Route Establishment for Unicast
June 2005
On-demand Route Establishment for Unicast
On-demand routing based on Route Request/Route Reply messages, similar to AODV (RFC 3561)
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, optional layer 3 info
Message ID
Hop count
Metric
Time-to-Live (TTL)
Flags

12. On-demand Route Discovery
June 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

13. Forward Path Setup in On-demand Routing
June 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

14. June 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.

15. On-demand Unicast Route Establishment
June 2005
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.

16. Mesh Point with Multiple 802.11 Interfaces/Mesh Links
June 2005
Mesh Point with Multiple Interfaces/Mesh Links
A mesh point may have multiple IEEE wireless interfaces/mesh links.
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 MP broadcasts the RREQ message, it may broadcast the RREQ message on all its interfaces.
When a multi-interface MP 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.

17. Routing table Routing table contains an entry for a destination.
June 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 (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)
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.

18. Proactive Route Establishment to Mesh Portal
June 2005
Proactive Route Establishment to Mesh Portal
Reduce the route discovery delay.
Reduce the routing control overhead for many to one communications
A mesh portal 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.

19. June 2005
Proactive Routing
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 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.

20. Proactive Routing (Cont.)
June 2005
Proactive Routing (Cont.)
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 to the Source
A mesh point unicasts a gratuitous route reply (RREP) to the originator of
the RANN (the destination) for establishing a reverse route to it.

21. June 2005
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

22. Local Connectivity Management
June 2005
Local Connectivity Management
Send beacons (Hello message) periodically
Update the route lifetime associated with the neighbor in the route table after receiving a beacon or other frames from it.
If a mesh point fails to receive any frame from a neighbor for a given lifetime.
Link to this neighbor broken.
Updates the route information for this neighbor.
Each MP includes the Neighbor Info IE in the beacon to discover the neighbors of a neighbor
Local neighbor list
Sequence number of last hello from this neighbor
Metric to each neighbor

23. Non-forwarding Mesh Points
June 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 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).

24. Mesh AP with Multiple Associated Stations
June 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.

25. Mesh AP with Multiple Associated Stations (Cont.)
June 2005
Mesh AP with Multiple Associated Stations (Cont.)
Mesh AP
with
Proxy
Infrastructure
Based WLAN
Station
WLAN Mesh Network

26. Multicast Routing The same protocol supports unicast and multicast
June 2005
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.

27. Multicast Route Discovery
June 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

28. Multicast Forward Path Establish
June 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.

29. Multicast Route Activation
June 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.

30. Join the Multicast Group
June 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

31. Leave a Multicast Group
June 2005
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
Group Leader F A B C
Group Leader F
Unicast the MACT with prune flag
set to leave the group
Multicast tree after pruning

32. Broken Tree Branch Repair
June 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. Repair of Broken Tree Link
June 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 links with MACT
Repaired multicast tree

34. QoS, Radio and Battery Power Aware Metric Support
June 2005
QoS, Radio and Battery Power Aware Metric Support
The proposed routing protocol allows using/optimizing QoS, radio and battery power/energy aware metric
Metrics used by the mesh network is advertised in beacon and probe response.
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.

35. QoS and Power Aware Path Selection
June 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.

36. Interaction between ARP and Route Establishment
June 2005
Interaction between ARP and Route Establishment
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.

37. Summary Extensible mesh routing architecture
June 2005
Summary
Extensible mesh routing architecture
Allow for alternative path selection metrics and/or routing protocols based on deployment scenarios and application requirements.
Hybrid mesh routing protocol
Support on-demand routing and proactive routing
On demand routing is based on the well-studied AODV
Support unicast and multicast