The schematic on the right depicts, in a symbolic manner, the entire software stack contained on a single controller appliance.
Shown are the principal interfaces and their roles in connecting components within each tier, the tiers to each other and the entire system to the external world. The approach aims to achieve connectivity in a controlled manner and without creating undue dependencies on specifics of component implementations.
The separate tiers are expected to interact over well-defined mutual interfaces, with decreasing coarseness from top to bottom. This means that on the way down, high-level policy communicated as part of the deployment interaction over the external APIs is digested and broken down by the upper tier into something akin to a specific plan, which gets in turn communicated over the inter-tier API to the lower controller tier. The controller then turns this plan into detailed instructions which are either pre-emptively disseminated to the network infrastructure or are used to prime the RADIUS or OpenFlow controllers so that they are able to answer future switch (other other network infrastructure device) queries. Similarly, on the way up, the various data sensed by the controller from the network infrastructure, regarding its state, health and performance, gets aggregated at administrator tier.
Only the administrator tier interfaces with the user or other
external applications. Conversely, only the controller tier interfaces
with the network infrastructure devices and other supporting
controller entities, e.g. RADIUS, OpenFlow, MSM controller software,
etc.