Enterprise and university campus networks have enjoyed decades of architectural permanence. For years, these networks have been built with cookie cutter designs, with the only critical decision points being the number of ports and users. But with new challenges presented today – more devices (both in number and type), mobility, security, and diverse application traffic – the management of these networks is finally coming to the forefront. Software-defined networking (SDN) is an ideal methodology to push policies to campus networks in a systematic and automated way.
OpenFlow, one of the cornerstones of SDN, was built to facilitate the separation of control from forwarding within network devices. One aspect of this is that it also allows operators to centralize the control of these devices, thereby simplifying the task of managing the network. And the campus network needs management simplification. Between bring your own device (BYOD) and the Internet of Things (IoT), networks are becoming more complex every day. Gartner projects that 6.4 billion connected things will be in use worldwide in 2016 – up 30 percent from 2015 – and will reach 20.8 billion by 2020. In the IoT, everything from lighting to cameras to alarm, sprinkler and HVAC systems can be connected to a campus network, and these devices consume bandwidth and create traffic that must be managed. And employees, students, and staff now carry multiple devices connected via Wi-Fi, so it’s no longer a matter of managing a fixed number of physical ports.
As OpenFlow deployments have progressed through proofs of concept and data center deployments, we have recognized that it provides three fundamental advantages:
- It maps business logic to the network, enabling policy-driven networking
- It makes the network programmable, so policies can be applied automatically
- It enables the use of a packet broker so you can manage the network around visibility and analytics.
Let’s see how these apply to campus networks.
In a campus network, policy-driven networking is important because a lot of the configuration requirements are around policy: security policy, device access policies, and usage policies among others. OpenFlow allows you to map a policy into how you want the network to behave. For example, if a university wants to regulate the amount of bandwidth used for peer-to-peer applications or non-school activities, you could create a policy that examines traffic and regulates it accordingly. In an enterprise campus, you might want to have a policy that assigns more bandwidth resources to the data center for overnight backups, and then re-assigns the bandwidth to users during the day.
The second point is programmability. You want to be able to dictate what those policies are and you want to be able to automate them, typically through an application. For any kind of an SDN infrastructure you have a northbound API that allows the application layer to communicate with the network layer, so it’s possible to install applications that apply policies. Companies like HPE have pioneered the concept of an “SDN app store” where the applications are turnkey with the infrastructure components, making it easier to deploy campus management. An example of this would be the HPE Network Optimizer, which uses SDN and OpenFlow to automate the quality-of-service (QoS) policies for unified communications applications for enhanced user experience.
The third advantage of OpenFlow is being able to achieve greater visibility into the traffic flows within the campus. OpenFlow can be used to support a network packet broker.
Traditionally, campus networks have been managed through a combination of element management systems (EMS) and network management systems (NMS). These consoles provide fault management, monitoring, configuration, and provisioning functions, but are typically only used in a reactive way.
It’s one thing to manage the network in terms of fault detection or configuration changes, but another aspect of management is around visibility and analytics. Network packet brokers are now using OpenFlow as a means to mirror traffic for out-of-band monitoring of traffic flows. Feeding this data into an application is a better way to keep track of what apps are running through the campus network, which users are consuming a lot of bandwidth, and what are some of the bandwidth patterns.
We’re starting to see analytics applied to this data for more proactive management. For example, suppose you see a high level of congestion happening from 8 t0 10 a.m. on Monday through Friday, and it’s usually coming from certain hosts. What you might do with OpenFlow is to get that network visibility, and then apply a more proactive policy to move that traffic around, or bring in a load balancer app to aggregate multiple links to address the problem.
More applications are leveraging SDN and OpenFlow into their solutions. Traffic monitoring companies such as IXIA, Gigamon, and VSS and even traditional networking vendors like Cisco, Brocade, and HPE are using this approach to extract greater visibility from the network.
In the coming years, campus networks will become far more complex and difficult to manage through traditional EMS and NMS. We have already seen how OpenFlow is making data centers and edge networks more manageable (for example, AT&T stated that it expects to save 40 percent of its operations costs through the use of OpenFlow and SDN), and it can make campus networks more manageable and responsive as the number of devices, users, and applications grows.