For more discussions and topics around Service Providers, please visit our SP Community: http://cisco.com/go/serviceprovidercommunity To view this blog post (with hyperlinks): https://communities.cisco.com/community/solutions/sp/blog/2013/12/09/5-points-of-openness-for-service-provider-sdn-solutions

1. 5 Points of Openness for Service Provider SDN Solutions
Posted by Paul Parker-Johnson
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 endto-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.

2. 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 westbound 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

3. 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.
For more discussions and topics around Service Providers, please visit our SP Community:
http://cisco.com/go/serviceprovidercommunity