In the past two to three years we have analyzed and experimented with new designs and service innovations that can be created using SDN and related virtualization models. Early evidence of the types of benefits that can be achieved has emerged in the data center and cloud computing domains as virtual networks and SDN architectures of various types have created new offerings in XaaS and other application areas.


However as we dig deeper into the implications of SDN throughout the SP landscape, we are starting to wrestle more deeply with the fact that SP services are delivered across a range of domains and a broad menu of services, and that SDN solutions – while following certain fundamentals in every case – are destined for use in unique end-to-end combinations.  SDN is sure to be deployed in metro, edge, and core network areas, in addition to the data center environment.  Yet solutions will need to integrate well end-to-end to deliver on the model’s benefits.


Thinking about this end-to-end service environment has caused me to conclude that, to be maximally effective, SDN solutions will need to support 5 key points of openness for the benefit of their developers and customers.  These include 4 points of direction on an architectural compass and a 5th dimension of internal modular design.  Let’s look at this in the context of a specific SP use case, and take general lessons from there.


Let’s look outside the data center (where SDN deployments are today more fully understood) and consider an operator’s metropolitan area network in relation to its full suite of services.  For many operators (often called converged SPs) this metro will include support for fixed residential, fixed business, and mobile network services, and a connection to the operator’s IP edge/core domains.


For SDN to deliver meaningful benefits in this metro (such as simplification, agility, and scale) it will work best if it is open and modular on the 5 dimensions I mentioned – the 4 ‘compass points’ of northbound, southbound, eastbound and westbound, and the 5th internal area. 


In the northbound direction the SDN control tier has to support open interfaces to orchestration and service management systems to simplify deployment and accelerate time to revenue.  This could be done with well defined object models and an open northbound interface such as a suite of RESTful APIs.  This would make communication with, say, the OpenStack platform (or other service management systems) simple, robust and perhaps most important, extensible.


Looking southbound toward the mixture of network elements that will be supporting the SP services in the metro (such as optical multiplexers, Ethernet switches, access multiplexers, and others) interpreting the higher layer service requirements consistently, and translating them into the protocol best suited for managing each class of device is the key to flexibility in managing the underlying infrastructure.  Southbound communication could be done using OpenFlow, NetConf, PCEP or other open, extensible protocols.  But the key to sustainable benefits is integration of the protocols with an abstraction layer in the SDN controller that allows higher layer services to be deployed efficiently across a diverse set of elements.


Simultaneously, controllers have eastbound and westbound integration requirements to support flexibility in choice of network elements and end-to-end integration of services.  In the metro the SDN platform needs to provide support for business VPN, residential broadband, and mobile network services.  And it needs to manage functions like bandwidth allocation, CoS settings, and failover behaviors consistently for the service and with each element type.  In ‘westbound’ connections functions need to align with CPE, access, and mobile network interfaces.  And in the ‘eastbound’ direction (IP edge/backbone network sites) similar integrations are required. 


Since SDN is supplying consolidated network control for the metro, employing a modular, extensible, and standards-based suite of protocol implementations is as critical to success as achieving the right logical abstractions in the northbound and southbound directions.  This can include BGP, MPLS, Ethernet, optical and other protocol modules, depending on the case.  It is analagous to the requirement in individual element classes (such as switches, routers, and multiplexers) to support an appropriate mix of interfaces and protocols for the services they are supporting.   In an SDN control tier, however, the range of supported elements and control plane protocols is likely to be greater than those supported in a typical current-day network element.  This is so customers can achieve the simplification, agility, innovation and scale they are seeking. Thus the special requirement in the SDN case is for a suitably broad range of east- and west-bound modules that can be maintained and extended moving forward as functionalities change.


The final dimension is openness internal to the SDN controller platform itself.  Aside from supporting ease of extension by its own developers, an open internal system design helps partners and customers add value to the platform with their own innovations.  Whether this is done using an approach like Java OSGi (as is done in the Open Daylight SDN system) or by other methods, the point is, extending functionality within the controller is as valid an enhancement path as adding applications that interact with the controller using its northbound APIs. Both methods accelerate innovation and deployment of operator services on as many dimensions as possible.


From this metro SDN case it’s easy to see how these 5 points of openness in adjacent network domains will contribute to SPs being able to assemble the most flexible, efficient and scalable SDN platform that they can.  If the SDN tier that’s deployed across all of the domains can communicate consistently with northbound orchestration to manage services cohesively, it will make introducing new services that much easier and faster to achieve.  And if the controllers at the same time are open and modular for managing a broad mixture of network elements in each domain, then they are achieving the efficiency, flexibility and scale so crucial to their operating needs.  If any of the controllers they deploy is implemented with significant limitations on any of the 5 target dimensions, then the range of opportunities available to them will be constrained to some degree.  This is not to say that early stage or domain-specific solutions may not achieve some success as suppliers and customers test out the technologies and gain experience with the model.  Instead it’s to say that the long-term benefits of the abstracted and extensible model of SDN for SPs are most likely to be maximized if the design approach embodied in the 5 points of open controller system architecture are used. A proof point for this perspective can be found in the initial Open Daylight SDN controller release (called ‘Hydrogen’).  However that is just one reference point that is likely to coexist in the market with multiple other offerings.  Thus in the big picture, the greater the number of solutions embracing the 5 open points model, the broader the overall benefit stream is likely to be.