Welcome to the first post of "my blog," which will keep you up-to-date on the execution of Cisco's Evolved Programmable Network, or EPN strategy. This blog will help you understand EPN and its associated Evolved Services Platform, or ESP, and how they will change your network and its operation. As an introduction, it is simplest to think of EPN as the physical and virtual network components, and ESP as the collection of management software used to operate the network.

People are fundamentally changing the way they think about networks due to industry interest in Software Defined Networking (SDN) and Network Function Virtualization (NFV). These terms mean many different things to different people, so we need to define them along with how they are integrated for useful purposes within EPN and ESP.

SDN is possibly the most overused term in the networking industry at this time. The acronym originated inacademic networks where low function routers or switches have their forwarding plane programmed by a remote controller, typically using the OpenFlow protocol. This model enables researchers to experiment with network behavior under the control of programs they write themselves. This is of limited interest in commercial applications, as existing network protocols come with equipment and there is little value in dedicating expensive development resources to maintain something that already exists. What is of interest is more accurately termed Software Driven Networking, where the network router or switch performs its duties as it always has, but will also accept customization commands from a programmatic source. This allows users to customize the device's behavior to their needs, without having to re-create and maintain functionality that already exists in today's devices.

So, what protocols are used for this type of functionality? Over 20 years ago, I was working with a combination of Perl scripts, UNIX crontab and SNMP strings to operate devices remotely under the control of a central computer. That is certainly a case of software control and fits with the goals of SDN proponents. The reason that would probably not be an accepted SDN case is that the protocols are old and not in vogue.

Figure one position these legacy and newer protocols into a handy reference for where protocols fit within the new SDN landscape. The key issue to take away from looking at this figure is that SDN is not one protocol; it only really has value as a set of APIs. The first set of APIs provide a uniform way of accessing the network elements (the abstraction APIs). The second set provide standard ways for applications to orchestrate configuration of devices to deliver services across the network (Application APIs). The value of SDN is realized when a use case is defined that brings value to the network operation, and a set of APIs is selected and leveraged by programmatic means to deliver something that was not possible before. My next posts will start to explore ways in which that can be achieved.

Tweet us @CiscoSP360 if you'd like to schedule a meeting about SDN.