In this post I will discuss three of these design principles: logically centralized implementation of network services, data structure representations of services and network resources, and the use of data modelling.
- Centralization. The implementation of network services is logically centralized in the sense that there is an API for creating, modifying and deleting services without the need to resort to distributed programming. The actual realization of the services, beneath the API, can exploit distribution techniques such as clustering, but this is not visible to service developers or to network engineers.
- Data structure representations. Through the API the programmer has access to configuration and state information for services and for network resources. Crucially, this information is provided in the form of conventional programming data structures, such as trees and graphs, that do not require distributed programming. These data structures are stored in a logically centralized repository or database (in our NCS product they are stored in a special-purpose database that is an integral part of the NCS application).
These are two key ideas of software-defined networking that makes the implementation of network services much easier. I highly recommend this excellent talk by Scott Shenker, from the 2011 Open Networking Summit, for more information and inspiration on these and related concepts.
- Data models. Our third design principle is to use YANG (RFC 6020) data models to provide semantically rich descriptions of the data structures representing network services and resources. These data models form enforceable contracts between the SDN control system and the management applications above it, such as policy engines, cloud orchestration systems, workflow engines, self-service portals, and user interfaces for network engineers. The YANG data models describing network resources in addition form enforceable contracts between the SDN control system and the network devices.
One of the key benefits of data models is that an SDN control system can auto-render north-bound APIs and user interfaces, internal database schemas, and south-bound command sequences from them. Thus, having data models describing network services and resources enables a data model-driven SDN controller design.
If you want an overview of this entire series of blog posts already now, check out this 26 minute presentation.