Data communication networks are deeply interwoven into the fabrics of the information and digital economy. IP based computer networks are crucial to the smooth operation of the high value processes that translate into profits, customer and user satisfaction within large corporate enterprises today. Legacy network technologies and architectures are still coping with the data communication demands of businesses today. However, it is without doubt that difficulties encountered using this architecture and its associated technologies are at this point in time triggering innovation, evolution and probably some form of natural selection which aims to trim down the undesired innate features currently running on this form of computer networking.

Software-Defined Networks using OpenFlow has a lot to offer the enterprise campus. Shortest path first forwarding and load (flow) balancing at layer 2, optimal link utilization, using the feature rich NETCONF (OF-CONFIG) for configuration and  management on the campus, and so on. However, this might not be the time to adopt it; at least for those who are not building their network infrastructure from scratch. We have seen the adoption (few in my opinion) of this architecture across varied establishments with large campus networks. This shows that this paradigm shift is gaining some momentum. OpenFlow has its shortcomings (OpenFlow overhead, complexity and performance of hybrid switches, and the cost of commercial controllers), but its advantages could well overshadow these faults. OpenFlow is also actively revised and it would seem HP has more SDN based solutions for the enterprise campus than any other vendor at the moment. Most experts in the industry believe that SDN/OpenFlow is the future of data communication networks. However, we need to thread carefully within the enterprise campus.  

                                             Guidelines and Recommendations

Following a quantitative and qualitative analysis and comparison of network performance  and control data collected from legacy network architectures and its OpenFlow/SDN counterpart, the following guidelines and recommendations have been drawn up for enterprises intending to migrate or implement an OpenFlow Software-Defined Network solution on their existing network infrastructure, or an entirely new network infrastructure. The enterprise campus network in this regard could be made up of a data center, main campus, branch or regional offices and so on; and then analyze the potential benefits to these components of the campus network. The guidelines cover enterprises that belong to 3 identified categories. These categories include:

1.  Category A: Enterprises that run an existing infrastructure comprising network packet forwarding devices that do not support OpenFlow.

2.  Category B: Enterprises that run an existing infrastructure comprising network packet forwarding devices that can be upgraded to support OpenFlow via software updates (firmware upgrades).

3.  Category C: Enterprises that are just starting up and are undecided about what solution to implement for their communications network infrastructure.

                                                                          Category A

From a business and technology point of view, it is not advisable for an enterprise in this category to embark upon an OpenFlow/SDN implementation plan. “If it's not broken, don’t fix it!”  The cost implications when purchasing equipment and retraining staff could make a significant dent on the enterprise’s balance sheet if such a plan is carried out. Business or technical requirements could arise in campus networks in this category where SDN/OpenFlow could be a better proposition. These include:

1. A situation where enterprises in this category have to set up a new “future-proof” branch network. In this case, the recommendations for enterprises in Category C can be employed. The price difference in some cases between Hybrid OpenFlow switches and their much conventional counterpart could be negligible. The stackable HP 2920 switch which supports OpenFlow is cheaper on the market than the Cisco 3750 switch which does not implement OpenFlow.
2. Implementation of a new high performance and future proof data center for an expanding campus network. OpenFlow offers a highly scalable, flexible and programmable offering in this department. However, this would come at the cost of training, commercial controllers and switch licensing. If OpenFlow is going to evolve into a niche as some experts predict, it would be the data center and service provider niche, where operational and management features or procedures on current network infrastructure have been stretched thin.

                                                                           Category B

An enterprise in this category can embark on an implementation plan for an OpenFlow/SDN solution. Some HP switch models running on current network architectures are upgradeable via software free of charge from HP. Potential additional expenses include costs for controllers, OpenFlow only switches, contracted application development and switch licensing. The guidelines and recommendations below could be employed for the migration process.

Stage 8 of the migration plan might require the implementation of OpenFlow only switches. The performance of hybrid switches is still under scrutiny at the moment, and a data center is a not a section of the network where we might want to be experiencing performance issues.

^*1IP network engineers who know the principles of software engineering can design systems that would optimize their enterprise’s network infrastructure. This design can now be handed to an actual programmer; in house or contractor to write the actual code.

^*2Floodlight OpenFlow controller and Mininet are recommended. Floodlight is recommended because it is open source and applications developed for use on it can be ported to Big Network Controller (its commercial counterpart). Mininet is for testing and prototyping purposes by emulating the actual network infrastructure within it.

                                                                  Category C

Enterprises in this category could implement a legacy network architecture using hardware from vendors who have adopted the standard. However, they should continue running the network in distributed control plane architecture mode until the OpenFlow/SDN ecosystem is fully mature, and competition and natural selection are regulating the prices and strengths of brand names. A personal preference of mine in the current market is the HP brand of OpenFlow capable switches. They seem to be showing strong commitment to the OpenFlow/SDN cause. However, other vendors are showing interest too.

Enterprises in this category could also opt for OpenFlow/SDN solutions on their network infrastructure if there is a strong business case for it.  Decisions could be made based on the following:

1.      Core business area: Higher education institutions, data centers, and local ISP start-ups, with the aim of having a fully-fledged and dedicated IT department could opt for this solution. A local hospital or law firm is not expected to implement this technology at the moment.

2.      Level of competition: Currently, a few vendors have been completely upfront about their SDN/OpenFlow solutions. Then again, most of the solutions offered are mainly for service provider, cloud and data center environments. This currently limits the options available to enterprises intending to adopt this solution.  As mentioned earlier, market forces have not been completely dictating the price and choice of brand names. When these forces come into full play, better judgement or justification can be made to implement this architecture.

Implementing OpenFlow/SDN with devices that support only OpenFlow for an enterprise campus (core, distribution and access) belonging to any of the aforementioned categories at the moment is not recommended, because there will be nothing to roll back too, coupled with the aforementioned additional costs. Currently, most, if not all OpenFlow only switches on the market are designed for high performance data centers, and they are quite pricey. 

Building OpenFlow switches from merchant silicon is  currently not a viable option in enterprise campus too. Additional skill sets which translate to cost would be required for this endeavor. This might be an option for enterprises in the western hemisphere. However, for those enterprises in emerging and third world economies, this is not an option; even if the funds are available. The level of penetration of this standard in these areas is very low as revealed by a survey conducted in Sub-Sahara Africa to quantify levels of trial, deployments and awareness amongst data network engineers  in relevant niches of the data communications industry. 

                                                                 Conclusion

SDN using OpenFlow are products of the aforementioned triggered processes, due to the limitations currently experienced on legacy network architectures. The main design aim of this paradigm shift is to simplify network management and configuration, accelerate innovation, provide a barrier free playing field for multi-vendor network implementations and drive new sources of revenue within the new ecosystem that has materialized because of this radical change from the status quo. However, as with every country that has undergone some form of internal revolution to change the status quo, some form of turbulence is experienced before full integration. The SDN/OpenFlow ecosystem is currently experiencing this turbulence, and it would seem the enterprise campus would be the last niche to experience full integration.

The business case for SDN/OPenFlow solutions in the enterprise campus is not strong enough at the moment despite its technical foothold; particularly in the enterprise data centre. However, future proofing a proposed new infrastructure should be included in its business proposal.

Software-Defined Networks using OpenFlow are bound to flourish considering the momentum they are gaining in other niches of the data communications network ecosystem, while it proffers outstanding solutions to some of the deficiencies current network architectures are lacking today. This paradigm shift is made up of recently developed technologies and frameworks that are currently undergoing constant research, development, testing and revision. This has made solutions in this ecosystem high on the cost side, but given time, more and better integrations, and finally competitive market forces, a cost friendly business case for a future proof technical   requirement within the new enterprise campus would materialize.