1. Mesh QoS: Multiple Simultaneous Routes
July 2008
Mesh QoS: Multiple Simultaneous Routes
Authors:
Sandesh Goel, Marvell et al

2. July 2008
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 along a route which maximizes overall bandwidth utilization
Latency is not critical
Sandesh Goel, Marvell et al

3. Example 1 July 2008 Best route to send data E D
A: needs to send voice to G G C F
Best route to send voice
B: needs to send data to G
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
Sandesh Goel, Marvell et al

4. Example 2 July 2008 Best route to send data E D A: needs to send both
voice and data to G G C F
Best route to send voice B
Same as previous example, except that both data and voice originate from the same node
Sandesh Goel, Marvell et al

5. July 2008
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
Sandesh Goel, Marvell et al

6. July 2008
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
Sandesh Goel, Marvell et al

7. Route attribute signaling
July 2008
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
Sandesh Goel, Marvell et al

8. July 2008
Data forwarding
Define a default mapping of traffic type (TID/AC) to route attribute
For example
Route attributes 0, 1, 2, 3
Default Mapping
BE -> 0
BK -> 1
VI -> 2
VO -> 3
This mapping need not be 1-1, could be many-1
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 lowest route attribute available for the same DA
Sandesh Goel, Marvell et al

9. Override default mapping
July 2008
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
Sandesh Goel, Marvell et al

10. Spec changes Define route attribute field in
July 2008
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
Sandesh Goel, Marvell et al

11. Implementation considerations
July 2008
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?
Sandesh Goel, Marvell et al

12. July 2008
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
Sandesh Goel, Marvell et al

13. July 2008
Straw Poll
Would you support enhanced QoS in a mesh by allowing multiple simultaneous routes between two mesh nodes?
Yes / No /Abstain
Sandesh Goel, Marvell et al