SDN and NFV Turned Inside-Out, Upside-Down

I just returned from speaking at an ETSI-arranged workshop on Future Networks, with 150 participants. As expected these days, most of the presentations and discussions were around SDN and NFV.

My take on the SDN part of the event was that there are two dominant SDN definitions

  1. The bottom-up definition, which is OpenFlow focused: separation of control-plane from forwarding plane
  2. The top-down definition: a centralized API towards the network services

The majority of the conference attendees concluded that number 2 is the definition of SDN that makes most sense and will provide the greatest value for the service providers.

So what are the major differences between this centralized API towards network services and the bare-bones OpenFlow switches?

  1. All legacy devices and virtual devices must be included in the SDN picture.
  2. There needs to be an abstraction layer which defines the specifications for the network services and the network devices (physical and virtual).
  3. Users and programmers should only deal with these well-defined abstractions.

Now it becomes a matter of defining an API towards an SDN controller. The SDN controller needs to manage a mix of traditional devices and OpenFlow switches and provide service-lifecycle management functions. I was relieved that the discussions did not go into the endless topic of which RPC mechanism to use; rather, the focus was on how to define concrete data models for the relevant abstractions.

What is the difference between C in FCAPS and F in FAB? Is it only a new term for a good service management solution?

There is a big difference. In traditional OSS/NMS solutions, the write part of the service lifecycle is weak to non-existent. In many cases the C and F are passive components that upload the configuration with an endless reconciliation processes as a result. In the case of traditional NMS/OSS solutions which do write, these are fragile non-transactional engines which result in inconsistencies and manual distributed activities. SDN is a strong design principle where you manipulate a centralized abstraction of a network service. The service instance is in the SDN controller. The SDN controller calculates all state changes and underlying protocol operations.

It was great to see the ETSI community coming together to agree on a SDN model that will provide service providers with the most value for their networks.