OpenStack uses the concept of flavors to define compute/storage configurations that vary in terms of resource consumption. When we start to consume the network as a resource pool, we need a similar concept. This post explains how this is achieved in the context of the Flavors application in the OpenDaylight project
Fallacies of Distributed Computing
If you haven't read the Fallacies of Distributed Computing you should. Specifically points 2 and 3.
- Latency is Zero
- Bandwidth is Infinite
The truth is that not all networks are created equally. We may have some pools of 2:1, 4:1, 8:1 oversubscribed fabric. We may links between data centers at varying bandwidths and costs to the business.
In a cloud network, we can increase our ROI by charging out portions of the network based on their actual cost to the business, but to do this we need to model the network appropriately. Applications also need to consume networking in an abstract way, and the concept of using Flavors as this abstraction is an interesting prospect.
Problem Statement
The problem is that todays cloud networking solutions (OpenDaylight included) are based on "Overlay Networks". The Overlay Network solution only assumes L3 reachability between tunnel endpoints and it makes no demands on the underlying network. As we described above bandwidth is NOT infinite, and latency is NOT zero, so to use our network effectively we need to find a way of allowing tenants to consume the right type of network for their application.
Building Blocks of the Flavor App
The Flavor App that was developed for the OpenDaylight project by @MadhuVenugopal, @networkstatic and myself is very simple. It has three main data structures:
- Forwarding Classes
- These define the way that traffic is forwarded across the network
- This could be Shortest Path, Longest Path, Lowest $-cost path etc...
- Flavors
- A flavor is a description of a service type (e.g "Bronze", "Silver", "Gold")
- A flavor is associated with a Forwarding Class
- Policy
- The policy is a binding between a "flavor" and a "tenant"
- This could be between "flavor" and "tenant network"
How does it work?
The implementation that was shown at the ONS SDN Idol works as follows...
The forwarding classes, contain an "Application Policy" element which are hard-coded in the application today. This field specifies the type of path to be taken across the underlay network. This path is dynamically generated by applying a rich metric to links in the topology which include things like "dollar cost", "latency" and "bandwidth".
Depending on the forwarding class assigned, we mark the DSCP field in the IP ToS header. This is important as not all devices in the underlay will be OpenFlow capable. In the cases of a OpenFlow-only network we could actually use the DSCP field to implement hierarchical policies (e.g a QoS policy within a network flavor).
The Flavor application programs flow entries on the Underlay network based on the "Policy".
Can I use it?
Not just yet. It's very much a beta application right now that needs a lot more work, but if you are interested in contributing please reach out to us! The code for the front-end in the DLUX project is already available on GitHub and the code for the Flavor Application should be making its way online soon.
@dave_tucker