Openness, from the top down: SDN for service providers

Chris Janz is VP of Market Development at Ciena, and an industry-recognized authority on software-defined networking and cloud computing.  In this first post in a two-part series, Chris explains why service providers will need SDN that embraces full openness – both “north” and “south”.

Software-Defined Networking (SDN) looks certain to reshape the networking industry landscape. However, despite a couple of years at the forefront of the industry’s attention, just what SDN will mean in different contexts remains unclear.  Amidst the confusion, a couple of key points have had a tendency to come out of focus.

First: SDN is not a one-size-fits-all proposition. The considerable differences among networking “spaces”—including data center, research and education, enterprise campus, and service provider WANs—in fact are brought into sharp relief by SDN. In particular, the data center space has dominated the SDN conversation. However, service provider WAN SDN is now moving to center stage; once there, it is likely to remain for some time. What SDN will look like in the service provider world remains relatively unclear.

Second: openness is a critical attribute – arguably, the most critical attribute – of SDN.  The point of SDN is to unleash productive innovation by making network behaviors more determined by software.  Software is relatively malleable, accessible, and quick to change as needed to deliver something new.   

But for these properties to be exploited, openness is essential.  There is little point in moving to software that remains as closed and locked as hardware-based systems today. 

SDN Layers & Interfaces: through the Service Provider Lens

The Open Networking Foundation’s (ONF) seminal SDN white paper established that the canonical SDN architecture consists of three horizontal “layers” (see below). The control and application layers are software layers. The diagram shows APIs between the application and control layers, and between the control and equipment layers. The intent is that these APIs should be open.

The canonical SDN architectural diagram:
three layers, two levels of open interfaces

There is no real consensus on what defines the application and control layers. In fact – we assert - the appropriate, best, or suggested meaning of these terms is space-dependent.

Consider the very different circumstances of data center networks and service provider WANs.

In the data center case, the control layer is naturally seen as something thin and functionally limited, providing just enough abstraction/translation to allow software developers to program network functions free of equipment layer vendor and box specificities and restrictions. The application layer is naturally seen as the home of such network functions - responsible for creating path and flow connections on the physical network.

In the service provider WAN context, “applications” more naturally means customer-facing, revenue-generating service applications. Such applications use network connection services, but at best are only partly defined by them.  SDN should make the software that creates such customer service-oriented applications fully portable from one network system platform to another.  Additionally, the equipment layer is relatively complex, usually comprising multiple networks, layers and domains.  All this suggests a control layer that is functionally expansive - assuming complete responsibility for path and flow connection control, management and related functions.  This in turn makes the complete network system a true platform for application layer software that delivers revenue-generating customer services.

Service providers need full openness – both “north” and “south”

The service provider SDN control layer – thick and completely encompassing of network control functionality – is as much the potential home of differentiating business value as is the application layer. For example, network optimization functions, which seek to constrain capital costs by consistently satisfying the greatest volume of service application needs from the smallest set of equipment layer resources, should be open to innovation by individual service providers. Service providers want expanded access to such innovation-driven control of the path to their own business bottom line.

However, such innovation is only possible when the service provider can innovate within the control layer. This imposes – among other things - an absolute requirement on openness between the control and equipment layers: without such openness, the control and equipment layers cannot be changed independently of each other. Software “driven” networking paradigms, which glue control layer systems to physical networks, neglect this point entirely when positioned as final-form architectures - ultimately serving the interests of vendors better than those of service providers.

As we show in the SDN architecture diagram above, while OpenFlow to date is a good start at openness “south”, it remains incomplete.  Multi-layer networks are, and will continue to be, a reality in the service provider world. The ONF’s recently formed New Transport working group will close this gap. Open transport control, when combined with open packet control, will open the door to new and powerful provider business-impacting capabilities.  As just one example, control layer systems will be able to drive multi-layer resource optimization processes – powerfully improving on network cost-at-scale containment.

As we have seen though, openness “north” – optimally reflecting application and control layer realities in the service provider WAN space – is equally important, and has received insufficient attention from the industry so far. 

In my next post, I will drill in on this question: given what is “right and natural” in the service provider WAN space, what is the correct form and format of the interface – API – between application and control layers?  I’ll show how Ciena already has reflected this optimal  interface in product now being embraced by our customers.  And I’ll describe how both packet and transport aspects of “openness south” will be reflected in delivered Ciena technologies, delivering on  Ciena’s OPn architectural vision, in the months to come.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.