1. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 1 Mesh QoS: Multiple Simultaneous Routes Authors:

2. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 2 Motivation It may not be desirable to route all data between two end points using the same route Voice should be carried along a route which minimizes latency –Bandwidth is not critical Data should be carried on a route which maximizes overall bandwidth utilization –Latency is not critical

3. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 3 Example 1 A: needs to send voice to G B: needs to send data to G C D F E G Best route to send data Best route to send voice In this case, C has two possible routes to reach G Voice traffic prefers one of those routes while data traffic prefers the other one

4. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 4 Example 2 A: needs to send both voice and data to G B C D F E G Best route to send data Best route to send voice Same as previous example, except that both data and voice originate from the same node

5. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 5 Defining the problem Current routing framework allows a unique route between any two given mesh nodes –Forwarding table at each node has a single entry mapping a given DA to the Next hop MAC address This prevents use of different routes based on QoS considerations –All traffic destined to the same destination is bound to follow the same path regardless of traffic requirements A single metric cannot capture the requirements for a diverse mesh –Different types of traffic need to use different metrics

6. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 6 Proposal Allow multiple simultaneous routes between any given pair of mesh nodes Introduce the notion of a “route attribute” The next hop is determined based on the combination of DA and route attribute –Forwarding table needs to maintain the mapping from (DA, route attribute) to Next hop MAC address

7. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 7 Route attribute signaling Route attribute is carried in the PREQ messages –Recommend at least 2 bits long, reserved bits can be used Each route attribute corresponds to a different route metric –The route attribute value in PREQ determines how the route metric value is computed and forwarded –Current notion of a unique metric per mesh is transformed into a unique “set of metrics” per mesh Final Destination selects best route based on route attribute Route attribute is echoed back in PREP –Allows the forwarding tables to be correctly populated along the path

8. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 8 Data forwarding Define a default mapping of route attribute to traffic type –For example 0 -> BE 1 -> BK 2 -> VI 3 -> VO –This mapping need not be 1-1, could be 1-many Actions at data forwarding node –maps TID in data frame to the route attribute using above mapping –uses the route corresponding to the resulting attribute –if a route for that attribute doesn’t exist, uses the next lower route attribute available

9. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 9 Override default mapping If application requires forwarding behavior different from the default TID mapping, it can override it by explicitly including route attribute value in each data frame Route attribute can be carried in the mesh header of the data frame –Optional, recommend one bit to indicate whether present or not –Reserved bits in mesh header can be used

10. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 10 Spec changes Define route attribute field in –PREQ, PREP, PERR frames –Mesh header for data frames Define route attribute enumeration Define route metric to be used for each route attribute –Ideas and proposals welcome Define mapping from TID to route attribute Normative text on how route attribute is used

11. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 11 Implementation considerations Potentially more routes maintained by each node –Larger forwarding table –If same routes result for different route attributes, then forwarding table entries can be coalesced Additional step in data forwarding –A few more instructions –Insignificant compared to overall forwarding latency Reasonable cost to pay for QoS?

12. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 12 Conclusion The change to allow multiple simultaneous routes can allow improved QoS in a mesh The changes needed to the spec are quite modest and do not significantly alter the overall framework

13. doc.: IEEE 802.11-08/0849r0 Submission July 2008 Sandesh Goel, Marvell et alSlide 13 Straw Poll Would you support enhanced QoS in a mesh by allowing multiple simultaneous routes between two mesh nodes? –Yes / No /Abstain