Explanation: OpenFlow promotion and Software Defined Network

Although the OpenFlow network has been a hot topic in recent months, and even enjoys star-studded popularity in Las Vegas's Interop 2011, but it is a protocol concept-a software-defined network-that can make real changes to virtualization and cloud networks.

In a software-defined network, switches and routers adopt some form of centralized software management elements. In the OpenFlow environment, the control platform is separated from the data forwarding platform. A centralized controller maintains the network in real time. The network path is defined as a "stream" and the data stream is distributed to vswitches and routers. Through these streams, the controller can coordinate data transmission between all network devices, so as to achieve the required automation and Dynamic Allocation Management in the virtual environment and cloud network.

"OpenFlow is an example of a software-defined network," said Mark Fabbi, Vice President and famous analyst at Gartner Inc. "This concept has been put forward for more than 10 years. If you know the QFabric of Juniper, it is also an instance of the software-defined network, because its core network also has vswitches and Structure-based functions. Then, all the devices communicate with a controller, and the Controller determines the path and the service it uses ."

This method is in stark contrast to the current distributed and non-classified control platform network. Both vswitches and vrouters maintain some route tables or MAC address tables, including data related to network factors, and they can make transmission decisions based on the data. This method is effective to some extent. However, due to the emergence of virtualization, the IT infrastructure is more dynamic than in the past, and the network needs to adapt to this situation.

OpenFlowAnd software-defined network: Integrating the OSI protocol layer

One of the main goals of OpenFlow and Software Defined networks is to make the network better respond and adapt to other IT infrastructure. The current network is static. Although they focus on the Layer 2 and Layer 3 protocols in OSI Mode, this mode does not support server virtualization.

"Previously, people on the Internet were always concerned about data packets. Is this really related to data packets? The network only considers Layer 2 and Layer 3 protocols, but in fact all OSI protocol layers must be better integrated to understand the network situation, "Forrester Research Senior Research analyst Andre Kindness said.

Virtualization has made the IT infrastructure more dynamic, so the network must respond to this change. When the server administrator migrates a virtual machine on a server to another server, the network must be able to automatically adjust the VLAN, QoS policy, and ACL.

"Currently, migrating a virtual machine usually takes two days because it is not automated," Kindness said. "It can be automated on the server, but once the network is involved, if you need to modify the network, the network engineer must modify the network before the VM migration ."

Basically, the network is still isolated from the application, and the network is limited to managing data packets, said Kindness. A Software Defined network is to "improve the efficiency of servers and networks and try to integrate them together. It observes the workload of various types of hardware and then determines the flow of data packets. It focuses on overall efficiency and makes the best possible use of resources, "he said.

Software Defined Network: how to implement it?

OpenFlow is not the only way to implement a Software Defined network. Arista Networks works with VMware to create a software-defined network in its own style, which is better at responding to changes in the virtualization server infrastructure. By enabling its firmware exchange to VMware, the Arista switch can automatically adapt to the initialization of new virtual machines or migrate virtual machines in the infrastructure.

"We have been working on internal development dedicated to integrating Open vSwitch with our swap OS," said Doug Gourlay, vice president of Arista's market. "What we do is to turn devices such as vSphere into network controllers. When you use vSphere, it can control VLANs, QoS policies, and ACLs. All these operations must be performed on virtual machines. We convinced ourselves that we will adopt vSphere for some parts of our network devices. When you create a virtual machine in vCenter and when you need to migrate the virtual machine, everything you need to do for the network, we can all implement it automatically through an API defined and defined between our switch and vSphere."

As mentioned earlier, the QFabric architecture of Juniper is a software-defined network to some extent, but this architecture has not yet been implemented. Juniper has released QFabric's data forwarding device, namely QFX3500. However, QF/Interconnect core devices and management devices similar to software-defined network controllers will only be released by the end of this year.

Although the product market based on OpenFlow is in its infancy, the open mode of OpenFlow architecture is the opposite of Juniper architecture. To use QFabric to build a Software Defined network, all QFabric products are required. To use OpenFlow to create a Software Defined network, you only need to use an OpenFlow controller and switch that supports OpenFlow from any vendor.

Currently, no mainstream network vendors have released vswitches that support OpenFlow, although many vendors have demonstrated this technology on Interop this year. NEC Corp. Is the first vendor to publish such products. NEC is a network vendor mainly focused on the Japanese market. It has been working with university researchers for five years in OpenFlow support R & D. This work peaked with the release of NEC's programmable stream ProgrammableFlow) Production Line on Interop. This product won the Best Interop product title during the exhibition.

NEC's programmable flow ProgrammableFlow) is currently composed of two main products. The first is the open flow support switch PF5240, which has 48 Gigabit Ethernet (GbE) ports and 4 10-gbe uplink ports. The second is the programmable Flow Controller ProgrammableFlow Controller PFC)-This is an OpenFlow Controller software that can determine the forwarding path for the PF5240 switch and any third-party switch that supports OpenFlow in the future.

Several emerging companies are secretly developing OpenFlow controllers and establishing partnerships with switch vendors. These include Big Switch Networks and Nicira Networks.

Is the OpenFlow architecture an alternative to the Spanning Tree?

According to the comments of Big Switch Networks co-founder and vice general manager of marketing and sales department Kyle Forster, the software-defined network based on OpenFlow can not only adapt to the changes brought about by virtualization. By transferring the control of vswitches and vrouters to a centralized controller, OpenFlow also supports advanced multi-path forwarding technology. This means that enterprises can define multi-Path runoff on the OpenFlow controller without the need to use TRILL or Shortest Path Bridging) to avoid the constraints imposed by the Spanning Tree Protocol. Since the controller has a complete network structure, it can prevent loops.

Forster said that the OpenFlow controller is still programmable on the network. By opening APIs on the controller, a third party can develop software that uses the OpenFlow controller to run advanced network functions and services on the network. For example, some researchers have developed a Server Load balancer on the OpenFlow controller. Forster says security vendors can develop virtual distributed firewalls or intrusion defense software that apply security policies to each vswitch and vro by defining the stream on the OpenFlow controller.

Big Switch Networks is developing a software program that allows network engineers to build a multi-Tenancy software on top of their infrastructure, which is especially suitable for cloud computing environments. Engineers can use the Big Switch controller to create a virtual Switch that uses multiple physical Switch ports and present it as a fixed network serving servers and applications to the system administrator.

"Our Interop demonstration shows this architecture view. You can use ports from different switches, such as two ports for one switch and five ports for the other, the third server has seven ports and all ports are integrated into a large vswitch, "Forster said. "The administrator can log on to this vswitch, and what they see is a vswitch with port 14. But they do not know that these ports are from multiple different devices in the data center. On the one hand, administrators will feel that they have a complete physical switch, but in fact we put the switch on different physical hardware and isolate them, in this way, if the Administrator does something to destroy the vswitch, the hardware on which the virtual machine depends can still work normally."

Gartner's Fabbi said that although OpenFlow has great prospects, the agreement was actually just a "research project" before these vendors began to release and sell products ". There have been few new products on the market for several years, not to mention the complete ecosystem. Currently, OpenFlow vendors are focusing on cloud computing vendors because they most need software-defined network functions. However, scalability is still a problem.

Like a controller that is very important in a wireless LAN architecture, OpenFlow Controllers may encounter bottlenecks because vswitches and routers decide to authorize forwarding to a controller running on the server.

"Honestly, I don't think this is feasible," Arista's Gourlay said. "Stanford's largest product, OpenFlow, is designed to provide 500 network traffic per second. We have to process the network of millions of streams in a few seconds. I'm not sure whether it can be expanded to this level ."

However, OpenFlow vendors are well aware of the importance of scalability. Forster indicates that BigSwitch is developing cluster technology for its controller. It is not developing a large controller that can handle all traffic on a large network. Instead, it is developing controllers that can manage networks collaboratively.

The OpenFlow controller will also be determined by the vswitch and vro themselves. In fact, they should be responsible for this part of the work. Forster indicates that switches in the OpenFlow architecture are not non-smart devices. Instead, they must be more robust and better able to run a large number of OpenFlow rules and support other OpenFlow applications. He pointed out how the access end of the controller-based wireless LAN architecture can become more robust and support applications such as rogue software detection and band management.

In addition, many OpenFlow vswitches are responsible for a large number of forwarding decisions. They only need to find commands on the controller when unexpected packet traffic is received.

"The switch can forward data packets based on the stream-based rules on the OpenFlow controller," said Don Clark, Business Development Director of NEC Corp. "When we face a lot of Virtual Machine mobility and many network changes, we will handle them accordingly. When a data packet that does not comply with the existing rules of the Local Switch arrives, the first data packet is forwarded to the Controller. It will be processed by logic, and then the Controller will set new rules in the stream table ."