Thursday, May 30, 2013

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 3rd 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...