If industry chatter is any indication, software-defined networking (SDN) is well on its way to broad adoption. But before SDN can become the new normal in networking, the workforce -- including everyone from architects to admins -- must have a solid understanding of the technology. That'll take the development of SDN course work. But who should be responsible for developing that training?
For now, networking pros are learning about SDN from a combination of vendors driving products, journalists and bloggers who are clarifying technology, and the individuals in their companies who are leading the effort. But what happens after the initial push for understanding? How does the next crop of people get indoctrinated?
The responsibility here is much narrower. Today, networking professionals learn their craft through a few primary ways: studying networking in a college or university, taking vocational classes at a technical institute, teaching themselves, or learning on the job. Those who learn on the job will be fine; they can rely on tribal knowledge and documented procedures within whatever company they join. But the vast majority of people pick up at least the foundation of their knowledge through more traditional means.
So are our universities, technical institutes and even technical libraries prepared for the shift to SDN?
The answer is decidedly "Meh." A small number of universities have been introducing SDN into their coursework. Virtually no technical institutes have the curriculum, largely because they are dependent on solutions existing in the wild. With no vocation to promote students into, these vocational schools suffer. Technical libraries exist, but a cursory search on Amazon.com yields only three books with "SDN" in the title (one of which is not published) and two cloud computing books.
This isn't surprising -- the technology is still emerging. But are we even on the right path? On this, I am uncertain.
SDN courses must expand beyond OpenFlow
SDN's roots can be traced pretty directly back to OpenFlow, which was born out of the academic community. Although it is true that OpenFlow is an SDN protocol, it is by no means the only SDN protocol.
Nevertheless, early SDN course work tends to focus disproportionately on OpenFlow. Although there is almost always a description of SDN principles, the dialogue generally evolves to specific technologies, and OpenFlow has an early lead in terms of both development and mind share.
As SDN continues to emerge, these courses will need to include other technologies like Path Computation Element Protocol, or PCEP; Border Gateway Protocol traffic engineering extensions (BGP-TE); and Application Layer Traffic Optimization, or ALTO. There will undoubtedly also be new protocols and technologies, and these too must work their way into classes around the globe. Courses must not only include the other technologies but also give them equal billing, and given the strong ties between academia and OpenFlow, I am less convinced this is likely.
Beyond protocols, courses will also need to better cover supporting technologies that make SDN more powerful. Network virtualization, DevOps, and big data all intersect with SDN at one or more places. The reason OpenFlow dominates in conversation and the classroom is because it is at least real and in deployment. It's difficult to teach technologies that are not yet tangible.
The burden of SDN course creation must be shared
Even if universities create these courses, practical architectures must also be developed through vocational institutes. But before these schools pick up the architecture, there will need to be a pool of jobs for these soon-to-be SDN engineers. That means there will also need to be training and certification programs similar to today's Cisco Certified Internetwork Expert, or CCIE, and Juniper Networks' JNCIE programs. Yet, if the promise of SDN is mixed-vendor environments, training can't be offered solely in the form of one-vendor certification. This all suggests a role gap in the current industry, one that could be filled by a vendor-agnostic, commercially friendly organization, such as the Open Networking Foundation or SDNCentral.
Ultimately, what we need is not one SDN course but a larger SDN curriculum -- and one that will stretch across many camps.
This was first published in August 2013