------------------------------------------------------------------------------------------ A Thought Excercise: SDN Architectures. ------------------------------------------------------------------------------------------ As a relatively new subject, SDNs are a setting for many case studies in terms of system design. At the most basic level, SDNs utilize a client-server model, where network elements are the clients that handle traffic according to instructions, in the form of /flow entries/ pushed to them by a centralized controller. Several configurations that diverge from this "classic" setup have emerged, including multi- controller networks. So far, these controllers are either standbys or load distribution mechanisms (as stated by the most recent v1.3 specifications), or "guest" controllers in virtual network slices where each slice takes the form of the distributed or "classic" configuration. Here we focus on the multi-controller configuration, but not as a redundancy mechanism. We try to build a hierarchy of controllers; each level of controller takes on different roles (services), with more local functions being controlled by the lowest level, and global services (inter-network handoffs, global services e.g. binding resolution) by the higher levels. The desired net effects are: 1. the collaborative building of rule sets by multiple, specialized controllers. 2. scalability and redundancy - performance gains from: * having controllers for base functions (basic forwarding) near the switches that need them * reducing the amount of control traffic handled per controller * ease of expansion, by simply adding more controllers 3. a flexible platform suited for testing experimental network stacks ------------------------------------------------------------------------------------------ Considerations. ------------------------------------------------------------------------------------------ .:Testing:. We will eventually need methods to evaluate the effeciveness of this configuration. The baseline is the single controller network, with TCP/IP. Several existing tools can be used for improvised comparison/simulation : * network slicer : create hierarchy of controllers. Delays produced by having many levels of controllers in a hierachy can be observed. The worst case of "flow rule found at root controller" can possibly be simulated by having a single true controller attached to the root slicer, as so: c1--root---sl1---sl2--sw where c1 is the controller, sw is the switch, and root, cl1 and cl2 are slicers found at different levels of the controller hierachy (slicers are specialized controllers with simple rule set building mechanisms - sequentially re-write flow rule contents to fit slice rules, and add them one at a time to a switch) * single controller : a single controller with influence over all switches in the network. The base case where one controller must keep account of both local and global nework traffic. Is likely efficient for small networks, where distance between controller and switch are very short, so spikes in delay from packetIns are small. * software switch : click router, a baseline experimental network stack. In theory, slow due to limitation of a pure software switch. * OVS : software switch, capable of SDN support. * mininet : network prototyping tool for SDNs. Assumes short distance between controller and all switches in a topology, therefore is good as a best-case simulation for single controller setups. * sliced controller : simulation of 'controller-per-switch' scenario, or best-case two- level hierarchy, observation of effects of separating various control paths. .:Inter-controller interaction:. In a hierarchical control plane, the leaf of the hierarchy (leaf controllers) connect to one or just a few switches, with controllers in the higher levels connecting the leaf controllers together. The control topology need not look like a tree, but be a logical hierarchy; as long as controllers can pass messages amongst themselves it is ok. In a simple case, each type of controller will have disjoint roles, meaning flow rules will not interact, unless they are explicitly configured to do so. An example of this case is where each controller resides in different layers of the stack, placing their influence over different switches (e.g. controllers implementing routing algorithms are attached to a different set of switches from the ones implementing learning switches). More complex cases come about when flow rules from different controllers start being pushed to the same switches, or network features become dynamic. The basic behaviors that can be defined for a multi-controller network are : * "If a leaf controller does not know what to do with a packetin pass it to the next level above." This allows a particular controller to focus on a specific task without worry about other things. This probably requires some careful planning of the logical hierarchy so that the packetin is inspected properly by all controllers that can potentially process it (which is not unlike thinking about rules for TCP wrappers and firewalls). * "If a packetin is representative of a service request, send it to the controller in charge of handling it." This is likely a subset of the above, but with the caveat that there must be some mechanism to finding and routing the packetin to the correct controller/location. This can potentially happen in several ways. 1. A routing mechanism between controllers 2. Fully connected controllers 3. leaf controller instructs switch to direct request to service location 1 and 2 relies on the control plane itself as part of the network stack. 3 either imples a need to send the message back to the switch so it can be handled, as well as possibly having to proactively push flows into the switches leading to the service location. Again this approach has the possibility of pulling the control plane into the network stack as a necessary component. * "Take care of local actions at the leaf, global actions at higher levels." Actions that only require a local view of the network (e.g. switching) can occur without a global view of the whole network, while services that need to track large- scale network states (e.g. host movement) should be dealt with by a controller with a wider view of its world. A protocol stack with different scopes can potentially be represented as a hierarchy of controllers. In any case, it is favorable to avoid having the message being treated as packetins at switches further down the path, but probably bad for the SDN aspects of the network to become visible to the network stack since it will prevent a stack reliant on SDNs from running on anything not implementing it as part of its protocol suite. .:Building Rule Sets:. The overall goal of the controller is to provide a minimally intelligent network element with rules on how to manipulate traffic according to packet header. The rules are stored in a table of limited size within the element, so one thing of concern is the number of rules that make up the behaviors required to implement a given network stack. Something to really consider is the coordination between multiple controllers. Bad coordination can lead to undesirable effects, such as: * contradicting flow entries that cause swtches to throw errors * incorrect processing of traffic e.g. bad interactions * redundant flow entires that waste flow table space These are things that need to be avoided. One almost existing solution is to use slicing. Slicing can be viewed as a coordination scheme, if the network hypervisor is thought of as a central coordinator that modifies each controller's flow entries so that they do not clash. Therefore a modified network hypervisor - which aggregates flows from all of the controllers and consistency checks the rules - is one possibly feasible scheme. Another, possibly less explored method, is to have a list that gets passed around amongst the controllers. Each controller contributs flow rules to this list. Consistency checking can happen anywhere - two hipshot places are at each controller adding to the list, and at the "last" controller that receives the list before it is pushed to the switch. The latter seems to make more sense, since the leaf controller is always the "gate-keeper" to the switches it is charged with and cannot avoid the role of pushing rules to the switch. What seems like the most 'natural' is a case where the leaf controller behaves as the coordinator of the flow rules that are to be pushed to the switches that it controls. To summarize, the points that need to be evaluated are: * how to incrementally build up rule sets * where and how the flow rule consitency checks occur * how to keep the SDN out of the protocols being tested (how to get true-to-life behavior) * how tasks divide up between different controllers * how this setup affects performance * how can a protocol stack be implemented and added to a controller sensibly And to keep in mind: * A controller implements an algorithm, but also manages SDN protocols (separate tasks). This means these should be separated so one doesn't affect the other. * Any consistency checking/rule aggregation is part of SDN, not the experiment. * Rules that are pushed to the switch should be the same as what the actual protocols implemented on-device apply to the TCAMs of a device. * There are proactive and reactively added rules. Protocol control headers are probably ok to add proactively, whereas dynamic behavior (port-host bindings) are reactive. * corollary: there are two ways to implement a protocol - with/sans static entries. ------------------------------------------------------------------------------------------ An Example. ------------------------------------------------------------------------------------------