SDN: which approach, network or IT?

Introduction

After many SDN presentations about SDN by different type of vendors, I arrived to the conclusion that there are two distinct approaches on SDN: the network and the IT approach. Interestingly the two approaches lead to the same results from the network perspective, but completely differ on what is the implementation roadmap and the impact on the position of network operators in the ecosystem of digital service providers.

Approaches

Network

The network approach generally explains that by using SDN, costs (CAPEX and OPEX) will be reduced for the following reasons:

• commodetization of the hardware thru virtualization = CAPEX reduction
• automation of tasks by having widespread control of the forwarding plane by the software = OPEX reduction

When asking what equipments are included in the SDN , the vendors taking the network approach give the classic list of all the existing network elements like routers, switches, firewalls, load balancers, protocol converters, base stations etc... etc.. However they consider the data center resources and the devices are attached to the network, and therefore not part of the SDN story.

These vendors are also very quick to indicate the flaws of the approaches taken by the non-network people or vendors who have an SDN story:

• the controller will not scale,
• the forwarding plane to controller round-trip is too slow if applied to each packet.

and therefore they are very convincing in introducing a new layer and new equipments (hopefully on commodetized hardware) in order to cope with these flaws.

IT

The IT approach looks at SDN to solve a data center problem associated with the fact that if a quick availability of a new IT resources (computing, storage...) is needed, the network has to be agile and quick to configure. The network must also be very cheap to build and maintain since for IT the network is a cost, meaning that OPEX and CAPEX have to be as low as possible. And since the dynamic allocation of the IT resources is done by the software, it makes complete sense to actually let the software control the network.

The equipments included in the SDN story are of course the network elements, but also includes the IT resource themselves.

The IT approach generally considers approaching SDN by creating/implementing an overaly network with a distributed controller, controller to controller connections and controllers linked with the already existing distributed brokers (acting as controllers) of IT resources in cloud or hybrid cloud solutions. Implemented in this overlay network is the ability to cache forwarding logic which is a familiar pattern already being used in many other places (the web will never work if caching didn't exist...).

The vendors taking the IT approach generally don't have much opinion on the network approach or see it as an opportunity since once SDN is implemented in the network, it will be possible to expand the overlay network.

Implementation results 

What are then the different results of implementing SDN using the two approaches:

• From a network perspective, there is not much difference since it is clear that the network will be cheaper to implement and maintain and will be more agile and quick to configure no matter which approach is taken.

• From a roadmap perspective the IT approach is clearly pushing an outside-in roadmap (creation of an overlay -> to the core network) while the network approach is generally pushing to address first to expensive components hence an inside-out roadmap. However the network approach also implies the implementation of a new layer of distributed controllers. The two approaches lead to two different roadmaps but it may be possible to create hybrid roadmap to mitigate the risks.

• From a provider perspective, the nature of the provider and the existence of the two approaches lead to a dramatic difference of positioning:

• An OTT (Over The Top) provider will always consider the IT approach with a top-down view including the IT resources, the network and the devices (home/enterprise gateways, terminal) since it addresses key IT problems and opportunities (cost, agility, distribution of the load, distributed software....) and because the network group generally is either non existent or a minority within the IT organization. Since an OTT will generally create an overlay network, it is always possible to opportunistically expand it on top of the SDN network operator will implement,
• A network operator will generally consider both approaches from a bottom-up view, unfortunately in separate groups: two groups (network and IT) or even three groups (core network, access and IT) and will generally not include the attached terminals anyway. Most likely the network approach will be picked since it addresses the current problems of doing more with less and because the network vendors are delivering a comfortable message with acceptable disruption.

This situation is actually very similar to the one delivered by the same network vendors few year ago with IMS but instead of cost reduction (the new problem "du jour"), it was about innovative services (the old problem "du jour").  However once implemented these technologies have left and will leave the network operators in the same bad spot witnessing a continuously expanding ecosystem of high value OTT services (including the innovative services IMS was promising) while only seeing an ever increasing traffic of low level packets.

In the SDN case network operators may be able to save costs (the constant increase of traffic may offset the savings)  but will not be able to be part of the IT supply chain and therefore will miss  the massively distributed cloud movement and its related solutions.

Call to action

As described in my previous blog, implementing SDN will give to the network operators an opportunity  to change the game and be part of the IT supply chain. However this means:

1. eliminating silos (IT, network, access, terminal) within the network operator,
2. while keeping a bottom-up view, network operators need to understand and embrace the top-down view which includes the distributed software part. Today software solutions are more distributed and dynamic/elastic than the network itself (in the 7 layer OSI model, the layer 7 has sub-layers that define a logical network where the nodes are software elements implementing API, the links are the relationships between these elements and the packets are the messages/events passed between these elements),
3. making sure that the vendors (including the software only vendors) who have an IT approach of SDN are considered and evaluated in network environment,
4. pushing the vendors who have a network approach of SDN to embrace the IT approach by:
• treating any network element as IT resource (may be we should have more memory and computing pre-installed in network elements):
• be capable of running multiple workloads (network workloads and IT/software solution workloads),
• must be linked to the IT resource broker (cloud or hybrid cloud),
• treating any IT resource (within data centers or on premise (home, enterprise)) as active SDN network element therefore must be linked to the distributed controllers either to provide or receive control information, 
5. being more prescriptive on the solutions vendors/SI need to provide,
6. considering any gateway or box installed on premise (home, enterprise) by the network operator as an active SDN network element and an IT resource,
7. working with the device manufacturers to treat any subsidized devices as an active SDN network element and an IT resource with specific constraints, 
8. partnering with IT resource providers to expand the type of IT resources available for the software solution developers and providers.

SDN and Network abstraction take 2

Ok a while ago wearing a network hat and arrived with that view of network abstraction on top of the network virtualization as a consequence of SDN (see previous blog). Some of the results looked more like a classic approach on exposing network assets as APIs and can actually be done without using SDN. But looking at the first category of abstraction, I said to myself that there must be something disruptive and game changing by implementing SDN, so wearing a IT hat I arrived with a more complete thinking about network abstraction :

Major internet service providers like Google already have very distributed core network of IT resources (based on commoditized blades) and they have realized that this network had to be very dynamic, programmable, and low cost and therefore using SDN/Openflow or equivalent is a way to handle these problems.

They also are spending a lot of efforts in expand this core network with remote IT resources by:

• giving SDN racks to be installed in other networks, (viewed as a CDN solution for Youtube)
• providing home/enterprise gateways to be attached to operator networks or within enterprise networks (viewed as a TV solution (GoogleTV) or as a search optimization solution (Google Appliance)
• providing downloadable code to end user devices viewed as a browser/device bases service platform (chrome) or as search expansion (google desktop)
• and adding openflow like functionality in android which means that any android devices can be viewed as an IT resource....

Each of these activities provide a service to the user/enterprise (TV, CDN, optimization etc…)  and at the same time drastically expand their core network of IT resources.  This pushes the network providers to become a forwarding plane managing opaque tunnels (I will prefer canals term see why later) carrying high level/value signalling/payload between the remote IT resources and their core network.

While this situation is basically unavoidable and could appear as yet another form of disintermediation, network operators can also change the game as a consequence of implementing SDN. Network operators are implementing SDN to reduce cost by performing two actives:

1. Virtualize the hardware of each network element (base stations, firewalls, routers, switches etc…)
2. Create distributed controllers to make the network easy to configure (ultimately software based), cheap to manage.

The second activity is core since there is a need to quickly and dynamically establish paths (route, vpn etc..) in the network but this will be completely hidden to developers. The virtualization activity can be used to create IT resources (using a de facto abstraction standard like AWS specs) that can be used by developers to run their machine images or implement storage buckets. The abstraction  is implemented as an extra workload on the network element virtualized hardware and a broker (similar to the brokers for hybrid cloud implementations) is needed to find the IT resources either in an explicit way of based on rules/policies or even analytics.  A cloud watch equivalent must also be implemented as part of the abstraction to give IT resource feedback to the broker.

This means that the network abstraction result for using SDN is a massively distributed data center with very interesting IT resources called: edge IT resources.  Of course the network based IT resources will have constraints and therefor will makes them different from the data centre based IT resources, but having different IT resources is not a problem for developers (e.g. AWS has more than 17 EC2 instance types).

The network based IT resources and more specifically the edge IT resources are game changing because: 

• Only a network operator can implement this type of edge IT resources.
• We are dealing now with IT resources that are 1ms away for the devices hence reducing the need of running workloads in the device while still  maintaining a very responsive user experience hence avoiding unnecessary power and bandwidth consumption.
• Offload the core network of IT blades of the small workloads that are created to pre-empt activities performed on mobile devices (these small workloads have similar size of overhead than the large workloads and with the proliferation of mobile devices (e.g.: Kindle for Amazon) there is an important increase of the ratio "total overhead"/"total effective workload" thus reducing the value generated by the core network of IT resources. This is a similar problem known by the network providers with the header versus payload ratio.
• Network operators are not just canals handler, but a part of the IT supply chain which increases their visibility of the high value activities at the software service level.

In this situation network operators are not just canals handler, but a part of the IT supply chain which increase their visibility of the high value activities at the software service level.

From an infrastructure perspective, the developers will see a continuum of IT resources from the back end to the device including the network instead of having to deal with the network as an IT no man’s land which today has a great negative impact in particular on mobile or M2M solutions.

The way software services need to be developed in order to fully benefit of the continuum of IT resources should actually not be a problem for cloud developer since they are already handling the following:

• API: developers are already familiar with consuming API (internal or 3^rd parties) in order to develop their solutions and therefore they know how to develop solution based on loosely coupled software elements.
• Elasticity: cloud developers are already aware of the complexity/benefits when dealing with a cloud infrastructure by using elasticity. It appears that there are different sophistication levels on elasticity:
• Level 1: request or release of IT resources to match the load (available services)
•  Level 2: use of elasticity to handle IT resource failures while still coping with the load  (resilient services)
• Level 3: broadening the criteria to trigger elasticity process (dynamic services)
• Level 4: depending on a hybrid cloud broker to get IT resources in different part of the accessible continuum of IT resources (nomadic services)
•  Level 5: analytic based criteria to trigger the elasticity process and analytic based broker to get the IT resource (liquid service),
• Many cloud developers are already pass beyond level 3.
• API discovery: when software elements move (e.g. software element following roaming devices), an explicit or implicit “DNS” like system pattern may be needed to discover where the new API endpoint. This  is similar to what has been developed and deployed by Apigee API Exchange.
• Resource discovery: data access also needs to be handled appropriately in order to make sure that the data can follow the software elements. XRD based index can be used for that. This may not solve completely the consistency problem of the data but developers are already familiar with dealing with inconsistent or almost consistent data by the time the level of consistency is known.

Today because of the IT no man’s land, canals have to be built thru the network in order to let the liquid services move closer to the devices. Making the network (operator/enterprise)  a massively distributed data center as an abstraction consequence of implementing SDN, will be like opening levies and letting the existing and future liquid services expand up to an edge that is very close (1ms) to the devices and therefore to the user providing human touch like user experiences which are advertised by 5G networks. This may imply that 5G will actually not be solved only by improving the radio/network but also by a completely different IT approach and a maturity in distributed software towards liquid services.

SDN and Network abstraction

SDN and network abstraction is a very interesting topic since it will have the same effect than amazon web services had on IT virtualization. 

I believe that network virtualization is clearly on its way and is getting the maturity needed for more widespread expansion; the acquisition of Nicira by VMware is a good example of that.

For the network abstraction it will be tricky to define what is the equivalent of the AWS specifications for cloud computing, but we can try by first decomposing the different resources the network virtualization implements. Three different aspects of the network can help this decomposition:.

• Network as a set of computing resources will be about the same resources as the one exposed by amazon specifications: computing, storage, queuing ... however the attributes of these resources are different: more distributed, lower latency, limited quotas, etc. Using base station computing to recreate a massively distributed EC2 implementation will have a clear effect on latency to mobile devices..
• Network as a facilitator of accessing/supporting cloud computing resources will be about how the current cloud solutions can use the network to work better: E2E QoS (including control of the bandwidth and latency), connection (a mix of network and OTT approach on how to handle push/pull events to and from devices)... are the type of resources that need to be exposed. Better cloud service to cloud service interactions on one side and better power management on devices will two aspects that will be impacted by the availability of such resources.
• Network as specific resources will be about the more classic view the network has to offer: communication intent (between entities: users/devices...), identity, metering/rating are the type of resources the network we agree used or should be used to see. I am mentioning communication intent instead of messaging or call control (see previous posts...). 

The combination of these three aspects will finally allow us to really implement device as a service and this not only for user to service via device interactions (mobile or not), but also device to device or device to service interactions (two different forms of M2M).

Now what we need to avoid is the confusion between network virtualization and network abstraction (cloud) since both are two different approaches of the situation. Virtualization is generally a bottom up approach while abstraction (cloud) is a top down approach. Both needs to work together to achieve the same goal...