A Hybrid Mesh Routing Protocol June 2005 A Hybrid Mesh Routing Protocol Date: 2005-06-14 Authors: 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 <http:// 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 <stuart.kerry@philips.com> 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 <patcom@ieee.org>.

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.).

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

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

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

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

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

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

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

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)

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

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

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

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.

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.

Mesh Point with Multiple 802.11 Interfaces/Mesh Links June 2005 Mesh Point with Multiple 802.11 Interfaces/Mesh Links A mesh point may have multiple IEEE 802.11 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.

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.

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.

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.

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.

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

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

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).

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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.

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.

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