At the last VMworld conference, VMware introduced NSX, its Software-Defined Networking (SDN) platform. There are a lot of highly technical posts on SDN, so before digging in to NSX in particular, I’d like to outline (in a minimally technical way) the definition of SDN for those of us who aren’t network engineers.
SDN is, according to the Open Networking Foundation (ONF), “The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.” Or, in less technical terms, separating network management from the underlying hardware. For example – rather than configuring a firewall rule directly on a network device using a command line interface, you would define the firewall in an SDN application, and an SDN server would configure the underlying network devices for you.
A YouTube video by Professor Scott Shenkar provides a “Gentle Introduction to Software-Defined Networking”, and is a very good basic grounding in the concepts, terminology and benefits of SDN. One analogy from the video that resonated for me was comparing how SDN works to how programming works: in programming, the user creates a program in a high level, user friendly language, and the compiler converts that to a machine code that will work on specific underlying hardware. In SDN, the user creates a network configuration with a management application, and the SDN network controller converts that to configuration commands for the underlying hardware.
In order to create the “network compiler” needed to make SDN work, a standardized protocol is needed to define the communication between the overlying network management application and the underlying hardware infrastructure. ONF has developed the OpenFlow standard to provide a vendor neutral protocol for communications between the control and infrastructure layers in the SDN model.
The SDN model divides network management into three layers:
This layer presents an abstracted view of the network, and provides configuration tools to administrators. Configuration commands are transmitted to the underlying Control Layer through vendor created APIs, and the abstracted network view is updated by the Control Layer.
The Control Layer presents an abstracted network view to the Application Layer, and then translates commands from the Application Layer into configuration commands for the underlying Infrastructure Layer (using a protocol such as OpenFlow). Communication in the Control Layer is bidirectional, so any changes in the Infrastructure are communicated back and displayed as changes in the Application Layer’s abstracted network view.
Infrastructure Layer (some models call this the Data Layer):
This is the underlying network fabric of switches, routers, firewalls, etc. It is configured by the Control Layer, and sends back status updates to the Control Layer.
Now that everything is clear...in part 2 of this blog, we'll look at how VMware's NSX fits in to the SDN model.