Software-defined networking will herald a new era in computing networks. A report from the cutting edge of research.
Network research is severely restricted by the commercially available network hardware today, such as routers and switches. Researchers want networks to be more open and better geared to their specific needs. For example, they would like to use network applications they have developed themselves to influence the way the network behaves. The reality, however, is that network components are hierarchically structured. The control or management plane and the data forwarding plane are contained in a single box. Vendors offer complete packages that allow little scope for adjustment to meet special requirements.
Stanford University in California started in 2008 to seek new ways of breaking out beyond the limitations caused by the monolithic structure of network elements. The concept became known as software-defined networking (SDN). Its characteristic feature is that the control and forwarding layers are physically separated. The network intelligence (control layer) is decoupled from the box using an open interface (e.g. OpenFlow), abstracted and centrally managed from a logical point of view. This separation means that commodity hardware available in the marketplace can be used. The greater flexibility researchers are looking for with regard to the configurability and programmability of networks can thus be delivered.
However, this also means that more attention must be paid to security as the separation of layers creates vulnerabilities – the connection to the controllers being one example.
SDN is often mentioned in the same breath as network function virtualisation (NFV), which came about through Internet service providers. The idea of virtualising network functions is increasingly coming under discussion as a solution for data centres. Like NFV, SDN is also about virtualising network functions, but the focus with NFV is on minimising capital expenditure and operating costs. The aim is to virtualise the right network functions and simplify the network design by replacing specific pieces of hardware – firewalls, for example – with software, thus cutting down on the hardware inventory. At the same time, however, NFV needs to allow for the scalability, both up and down of business applications and short time to market, meaning that new services are quickly developed to the point where they are ready for consumers to use.
We at SWITCH see a lot of potential for the future in both SDN and NFV. This is why we are organising workshops and making a commitment to knowledge transfer. Discussions have shown that SDN/OpenFlow is still heavily biased towards research rather than the operating needs of a campus network. That said, it is very much in demand for data centre solutions. The OpenFlow protocol is a southbound API (see illustration) and as such the only protocol standardised by the Open Networking Foundation (ONF) for SDN implementation. The northbound API (NBI), on the other hand, is often proprietary or defined by manufacturers due to the absence of standards. In view of this fact, various standard development organisations (SDOs) are working to standardise SDN and NFV or to provide recommendations. The ONF, for instance, published an SDN reference architecture in June 2014. The Software-Defined Networking Research Group (SDNRG) of the Internet Research Task Force (IRTF) (IRTF) has published its SDN Layers and Architecture Terminology, and the European Telecommunications Standards Institute (ETSI) has issued a definition of NFV.
It is clear that research and industry are only able to profit from each other in individual cases at the moment. However, the gap between the two is getting ever smaller.
The trend is pointing towards operative SDN frameworks in the near future based on a mix of legacy equipment (network components that already exist) and OpenFlow capacity. Traditional networking will operate in the same network environment with the SDN components. This is known as hybrid SDN. As regards the control layer, the question arises as to what is the most suitable technology or form of implementation. A shared interest in harmonising research and industrial technologies would be desirable here. An agreement should be reached on which control platform is to be regarded as the standard going forward.
As far as NFV is concerned, binding standards are essential to efficient progress. The development of SDN applications and their embedding in an SDN/NFV architecture will be successful if the NBI is open, which would make it possible to define standards. In principle, the subject of open source versus open systems needs to be debated.
More input on experience with SDN/NFV is also sought from the operating side. It would make sense in this respect to provide access to test environments with real, physically limiting influence such as those in the European OFELIA project and the GÉANT project GOFF.
In summary, no one will want to forego the network flexibility afforded by SDN and NFV in future. However, it remains to be seen whether and how commercial and academic circles can agree and which technology standards will become established. It is, at any rate, important to exchange experiences in workshops and make them available to the SWITCH community.