SDN for Universities: Campus Slicing 101

June 27, 2012 - 2 Comments

In the wake of our Open Network Environment (Cisco ONE) announcements, we are continuing our series on software defined networking (SDN) use cases, this time focusing on the primary use case for OpenFlow and universities, campus network slicing. If interested, a more detailed solution brief on this scenario and the Cisco SDN OpenFlow controller can be found here. And check out our demo video below.

Campus Slicing diagramUniversity campus networks offer an increasingly wide array of networking services to one of the broadest user bases of any “enterprise.” Some universities have medical or high-security facilities and must maintain regulatory compliance accordingly. Student networking services vary depending on whether they are on or off campus, and in almost all cases students and faculty bring their own devices. Administration offices must also be able to manage the day-to-day activities of the university. Often event management must include the rapid provisioning of point-of-sale terminal support and back-end payment reconciliation. And faculty must have both data and video access within the university campus, across campuses, and further out to other universities.

As a result, the ability to partition networks (called “slicing”) based on SDN has risen in popularity. Although slicing is being performed today on isolated networks, the need to perform it on production networks is now becoming a priority. Cisco controllers and agents, as part of the Cisco Open Network Environment for network programmability, are aimed at addressing this need.

Much of the early research and collaboration between universities on OpenFlow and SDN has been driven by the adoption of National Science Foundation (NSF) projects such as GENI, an open, collaborative research environment to explore networking at scale.

One of the basic premises of SDN is that the abstraction of control plane management, out of each network device and into a centralized “controller,” can create high business agility through automation with relatively lower OpEx and low risk. SDN is a natural fit for the class of requests universities need to service.

One of the primary components to the emergence of SDN on campuses has been the ability to create logically isolated networks and allow them to be partitioned and programmed using slicing. In SDN, this is facilitated with an abstraction layer in the network device called a flowvisor. Today, many universities use flowvisors within their isolated networks in conjunction with SDN controllers to manage their slicing requirements. In many cases these slicing activities are still performed off the campus backbone, as the software used to implement both the operating systems and slicing functions does not provide the policy management consistency required for production network applications.

Cisco adds value to the campus slicing use case in several ways:

  • The Cisco SDN controller has been designed to eventually transition SDN to production networks (available today for pre-production/test environments). Connectivity to policy creation and security tools used to manage the conventional network is transparent. Additionally, Cisco has created Topology-Independent Forwarding (TIF), which enables flowspec-level policy management to be enforced for each of the slices issued by IT.
  • Cisco has integrated the flowvisor functionality. This eliminates the need for a flowvisor. It enables IT managers to take advantage of TIF for each slice, allowing the sandbox to conform to conventional policies yet also allowing slice owners to manage their networks as needed (for example, quality of service [QoS] and bandwidth management).
  • The Cisco SDN controller offers Java and REST language-based northbound interface support, assuring that a wide range of sources can integrate their applications into the Cisco infrastructure. This is an important piece to harmonize the use of SDN within the major aspects of network provisioning on campus, that being the service, the administration, user and faculty access needs, and the research requirements, all from the same architecture.
  • The ability for the Cisco SDN controller to access the vast amount of intelligence present in Cisco network devices allows a richer set of analytic data to be presented to applications to improve the results of fusing applications and network behavior. Cisco offers these as extensions that are presented as extended analytics to the applications using the controller.

Universities now have the opportunity to mature their SDN use cases to include proper production network management and control while these networks expand to meet the wide use of requirements through higher automation and dynamic reconfiguration. Cisco is starting out by working with a limited number of universities in 2012 with a proof-of-concept SDN controller and OpenFlow 1.0 agents supported on a limited number of platforms, notably the Catalyst 3560-X and 3750-X switches, to start. Two Big 10 Universities, Indiana and Wisconsin, helped participate in our Cisco ONE launch at Cisco live two weeks ago and have been enthusiastic supporters of our SDN efforts so far.

And, finally, here’s the demo:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Thanks for sharing Gary,

    Can I attach any controller (Nox, Beacon etc.) out of the box to a provisioned sliver on the controller? Just curious if that needs to be rolled via onePK by us or is is the controller exposing a northbound OF API . Obvious reason would be for a researcher, or in the real world a tenant, to attach to their provisioned sliver. The self-provisioning potential of slicing is always a fun use case to imagine or dream, cut a sliver of a global SP network, OpEx is software, interconnects and power. Simplifying it obviously, but fun nonetheless!

    Guessing, v1.0 agent support implies agnostic switch vendor support?


    • Brent,
      My understanding is that the OF-enabled switches work with other controllers, which I take to be the essence of your question. And, yes, conversely, our controller should be able to work with other compliant devices. Whether that needs explicit validation on a controller by controller basis to know what can eventually be supported, or if neutral controller support is available initially or sometime down the road, I’m a little fuzzy on the explicit product road map details. I will see if we can get a more detailed answer from the product team as we get into the week. – GK