Network Planning

Typical production network in a building (or a campus) consists of a set of switches that are connected together and run multiple VLANs. Here are the list of things you need to plan before adding OpenFlow network to the existing network.

• OpenFlow Control Channel Connectivity
• OpenFlow Controller Location
• OpenFlow Network Connectivity

OpenFlow Control Channel Connectivity

Because OpenFlow switch needs to talk to the controller via TCP, we have to provide IP reachability between the control port of OpenFlow switch and the controller. One obvious way to achieve this is to alloacte physically separated network, but it requires a dedicated cabling and switches/routers, which may not be feasible. Because commercial OpenFlow switches can accomodate non-OpenFlow VLANs as well as OpenFlow VLANs, we can create a non-OpenFlow VLAN for the control channel connectivity. Using VLAN tagging, we can even eliminate the additional cabling between switches. If there exists a management VLAN that spans all the switches, it would be a good idea to piggy back the OpenFlow control channel on that VLAN.

Stanford's software reference design switch is able to talk to the controller through OpenFlow VLAN (we call it "in-band control"). Current commercial switches are not able to do this.

In the Example Network, we allocate one non-OpenFlow VLAN ( VLAN999) that spans all the switches for the control channel connectivity.

OpenFlow Controller Location

Controller can be located anywhere as long as it is IP reachable from all the control port of the OpenFlow switch. In the OpenFlow, the first packet of flows typicall goes through the controller. Thus it would be better to locate the controller close to the OpenFlow switches.

In the Example Network, the controller is located outside of the OpenFlow network that is reachable to the OpenFlow switches via non-OpenFlow VLAN ( VLAN999).

OpenFlow Datapath Connectivity

In the production setup, the number of inter-switch cabling is limited. Most of the current OpenFlow commercial switch can accommodate multiple OpenFlow VLANs on the same physical port by VLAN tagging. Most of the current OpenFlow commercial switch can even accommodate non-OpenFlow VLANs and OpenFlow VLANs on the same physical port by VLAN tagging. These eliminate or reduce the additional cabling. If there is no bandwidth separation between VLANs, use it with care (OpenFlow v1.0 defines bandwidth separation).

Currently available OpenFlow controllers (NOX, SNAC and the reference controller) cannot handle the loop topology by default. If you plan to use these controllers without modification, eliminate the loop topolology in OpenFlow VLAN.

In the Example Network, we use VLAN tagged link between HP and NEC switches that accommodate all the non-OpenFlow and OpenFlow VLANs. Between HP and Toroki switch, we used dedicated physical cabling for each VLAN, becuase Toroki switch currently cannot accommodate multiple VLANs on the same physical port.

Recommended practice

DO NOT turn on OpenFlow as soon as you procure the switch. We recommend to start with non-OpenFlow VLANs only and verify that they work fine. When adding OpenFlow VLAN, we would recommend to take two steps; First, create a VLAN (for OpenFlow) and conduct reachability tests (using ping, wget, etc.). Then turn on OpenFlow feature on that VLAN. The current available OpenFlow switches allow you to take these steps in configuration.

It is also recommended that you adopt a staged deployment procedure. In this, you will create one OpenFlow instance, verify it, and then move on to creating the next instance.