1 / 13

Mesh QoS: Multiple Simultaneous Routes

Mesh QoS: Multiple Simultaneous Routes. Authors:. 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

boyland
Download Presentation

Mesh QoS: Multiple Simultaneous Routes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 Sandesh Goel, Marvell et al

  3. Example 1 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 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. 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. 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 • 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. 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 Sandesh Goel, Marvell et al

  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 Sandesh Goel, Marvell et al

  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 Sandesh Goel, Marvell et al

  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? Sandesh Goel, Marvell et al

  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 Sandesh Goel, Marvell et al

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

More Related