Cloud Native Infographic

Don't Miss the "Cloud Native Infographic" !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this "FREE" one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand.

Things, Transport SDN vendors may not tell you, but you must ask them!


So you have your next appointment with a Transport/optics vendor for a presentation on its Transport SDN roadmap.

And you are all set to explore the rosy picture the vendor wants to present about its  Transport SDN’s roadmap.

Therefore, it’s time to do some homework, so you can ask right questions from the vendor about its SDN strategy.

Be with me, as I take you through a list of use cases of Transport SDN. Then tell you what the TWO important “Killer use cases” are for Transport SDN. ( and give you reason why I shortlisted two)

So, here are two goals of my blog:

a) If you are an operator, you will get an insight about the important use cases of Transport SDN. So that you can engage with vendors fruitfully; ask right questions and perhaps influence their roadmap.

b) If you are a vendor, you get to know an operator’s perspective about Transport SDN’s priorities.

But before we proceed I intend to tell you why this whole discussion is so important, in the first place.

As SDN is still immature, vendors have taken advantage of associating SDN with any feature and product they want to market. It is so easy to sell anything if  dubbed as “SDN”, after all.

It is NOT uncommon for a vendor to come and present ten use cases for SDN and then tell you what would be the right fit for you; which will of course match its roadmap.

So someone ought to separate wheat from chaff.

And that is you – the operator!

And if you know what the important applications for Transport SDN are, you can easily engage with  SDN vendors and drive them rather than vice versa.

Before that, you should understand one important thing!

Transport world is already SDN like when it comes to concepts.

How ?

Control and forwarding plane are well separated and networks controlled and  driven by central network management systems (two important attributes for SDN).

Add to these, features of openness  for the interfaces and  Open APIs (ongoing work by vendors) and you are well on the path of full-fledged SDN.

So SDN in the transport world should not be as big of a paradigm shift as it is for the data center world.

Bottom line! The vendors should take time and evolve their transport SDN roadmaps to solve real transport world issues. Instead I see some transport vendors try to emulate all the data center use cases which might lead to putting square pegs in round holes.


Top Transport SDN use cases should solve real issues!


So what are these issues and how do they relate to the use cases?

To answer this question we proceed as following:

  • We list the fours use cases as listed in the original white paper of Transport SDN by ONF ( Open Networking foundation)
  • Then I discuss on why I think two of the use cases are more important and what issues they can solve for operators.

My Benchmark for the Killer Transport SDN Use case is following

1. It should solve pressing issues of an operator.

2. It should reduce both CAPEX and OPEX

Now lets move to the use cases.

The four Use Cases from ONF are following:

Use Case Name Description Application
1 Bandwidth on Demand Increasing or decreasing, dynamically, the optical  bandwidth between data centers automatically or on demand. Data Center links are overprovisioned to cope for worst case bandwidths.Making the links more dynamic and elastic would eliminate the cost of overprovisioning the links.
2 Private Optical Networks for Enterprises Making the optical equipment open, flexible and easy to operate so that enterprises can run their own optical equipment; bringing up, tearing down and routing wavelengths would become an easy job for enterprises because of SDN. Enterprises do no need to depend on service provider to provide them optical service as they can lease fiber and run their own equipment easily
3 Virtualized Network Slicing  physical network in a way that different virtual networks can be run on the same physical network. One common example given is Optical Virtualized Network. The optical virtualized network would give a more predictable SLA compared to IP based VPN. This presents monetization opportunity for operators/service providers.
4 IP / Optics Multilayer Optimization Common SDN Controller controlling Optical and IP Network making it easy to provision, maintain, route and optimize the bandwidth at each layer. Results in  significant bandwidth saving and efficient management of both IP and Optical networks.


Killer Use Case#1 for Transport SDN: Multilayer IP plus Transport Optimization


What issues this use case is targeting?

IP and transport run as two separate layers, today, with no coordination between them. IP is considered a client for transport layer.

This leads to something called “dumb pipe” strategy.

Dumb pipe strategy means putting IP over a dumb transport pipe. The transport pipe has no understanding of the client layer. All it is doing is providing a dumb pipe. It does not participate in any routing or restoration / protection of traffic. When fiber cut happens, the IP layer acts and protects the traffic.

The absence of optimization of IP and Transport layers leads to an overbuild of both core routers and transport layers, resulting in huge CAPEX and OPEX spending.

So what is the optimization of IP and Transport that we often talk?

Actually optimization results when we have definite answers to questions like

a. Are bytes travelling at the optimal layer (IP, Optics, and OTN)?

b. Is traffic protected and rerouted on the optimal layers?

If we don’t have answers, then certainly the network needs optimization from layer zero to layer three.

How this Use Case  solves the issue?

Let’s look at one of the architectural diagram of this use case for Transport SDN.


There is a Multi-layer SDN controller that interacts with both IP SDN controller and Transport SDN controller through a standard open flow protocol or any other open API.

In this topology each domain controller gives sufficient topology, latency and performance information to Multi-layer SDN controller.

The Multi-layer controller would then do optimized decision on path computation and restoration management.

When bandwidth shortfall or a failure occurs, the Multi-layer controller would coordinate with both domain controllers to provision or restore traffic at the most efficient layer by allocating or re-allocating router ports or transport paths and sometimes do the express routes saving expensive router ports.


1.  Tight integration between IP and Optics layers will result in optimization. The Multi-layer controller with its intelligence can now put bytes at the proper layer, saving bandwidth in different parts of the network and restore traffic at the most optimized layer.

2. CAPEX reduction as no need to overbuild routers and optical network as resources are highly optimized at these layers.

2. OPEX reduction through automating processes that will reduce manual configuration errors.

 Next steps for operators:

This feature is needed, mandatory and would result in reducing OPEX and CAPEX tremendously as listed in benefits section. Ask for this feature /use case to be implemented by your vendors.

Next steps for vendors:

Expedite the Transport SDN roadmaps. Prioritize this feature if it is in the roadmap. Listen to operators!  here.

Killer Use Case#2 for Transport SDN: Bandwidth on Demand


What issues this use case is targeting?

The bandwidth as provided today is static and not dynamic.

Worst still, networks today are not optimized for bursty traffic (For example data centers traffic). To cope with  bursty traffic, links are overprovisioned which are not utilized efficiently most of the time.

For end customers, it means paying more cost for the links which remain under-utilized, most of the time.

For operators, it results in two issues

a. Operators CANNOT  address the mass market that would like to purchase  bandwidth in small granularities but CANNOT because of the only option of buying max pipes to meet their bandwidth requirements.

b. Operators CANNOT upscale their customer contracts quickly and efficiently. If end customers ask for more bandwidths, there is a time delay on part of the providers because of many factors like settling contractual issues, Circuit work order issues and other technical issues like bandwidth bottlenecks, changing routes, lambdas, latency and restoration studies etc.

How this Use Case  solves this issue?

SDN solves this issue by making bandwidth dynamic, flexible and inflated only at certain part of the day when the customer needs it. This is possible by using bandwidth scheduler tied to specific  App that can check the contract of customers and if the contract allows, it can automatically increase the bandwidth when traffic bursts come.

Some vendors are developing portals for Bandwidth on Demand (BWoD), whereby customers can send requests for bandwidth. The provisioning of service could be instantaneous or scheduled.

Secondly Transport SDN allows having service provisioning process automated and networking resources visible.Therefore changing routes, wavelengths or ODUs become a matter of point of click, thus expediting the whole process of service provisioning so customers can be served very quickly.


1. CAPEX reduction for operators as networks do not need to be planned for peak rates. OPEX reduction as the provisioning cycle is much simple and shorter.

2. CAPEX reduction for customers as they don’t need to buy peak rates contracts.

3. More revenue generating opportunities for operators as it can bring to net those customers who were not otherwise buying the bandwidth because of cost.

Next steps for Operators

“Bandwidth on Demand” is a killer use case for SDN. This must be available on the roadmap of a vendor. If not, ask for this feature. If yes, ask for expediting the feature.

Next Steps for Vendors:

Bandwidth on Demand is a genuine need of operators. This feature should be prioritized, compared to any other feature of the Transport SDN on your roadmap.

Other Use Cases and Conclusion:


What describes above are the “Killer use cases” for Transport SDN, in my perspective. There are other use cases as described in the above table.

Out of these “Virtualized network” is interesting use case. Virtualization does exist for some commercial solutions already in the market, for example on the physical layer, there are Optical virtualized network solutions available.

However in my perspective such applications fall more under monetization opportunities  for an operator rather than solving some pressing needs of operators.

Perhaps the recent move of the MEF to go for NaaS (Network as a Service) could open up more space at the layer 2 level for virtualized networks. This initiative is aimed at providing more global end to end connectivity with orchestration layer for carrier Ethernet services passing through multiple operators around the globe.

Further, the “Private Optical Network” uses case talks about transferring administration of optical network to enterprises while making the service providers as only leased fiber providers for such customers. I am not sure, how many enterprises would like to deal with the optical issues no matter how much SDN makes it easy for them.

SDN is still immature in terms of Transport and WAN applications.

Transport SDN is evolving. There might be more use cases in near future. However the two cases I listed above are the ones, I consider the “Killer use cases”.

Now it is your turn to tell me if you agree with me or not. And what would you add to this list that can solve the pressing needs of operators.

Notify of
Newest Most Voted
Inline Feedbacks
View all comments
6 years ago

Very well written blog . simply I will say worth reading .
I totally agree with you on the 2 use cases I mean “Killer use cases”.
and thanks for such a nice blog .this blog make me more interested to do research on SDN .

6 years ago

This SDN theory defines the communication hardware and software device separation that is x86 server hardware can also be used as a switch or router, because the NFV(Network Functions Virtualization) can building virtual environment for any device with virtualization technologies.

6 years ago

Exquisite and professional post, worth reading. Definitely, SDN will impact the whole ICT industry, but is SDN the future ? we do not know, let’s see what will happen

Carlo Corti
Carlo Corti
6 years ago

Hi Faisal,
excellent paper on SDN!
You have mentioned the most important uses cases.
In my view an additional one is related to the Network Analytics. Thru SDN, the service providers can collect data from the network and make the “What IF analysis “ via planning tool. This allows to plan the investment in network resources and thus to minimize the Capex.
Also , with reference to the “virtualized network” use case, it is true that it falls more under the “monetization” opportunities for operators , but it is also solving some pressing needs of the end users . For instance, I am referring to the need for an e2e committed latency per service or e2e encrypted services.
Congratulation for your blog!

Tom Clarke
Tom Clarke
6 years ago

Hi Faisal,
Enjoyed your article. Clear and descriptive. I know the U.S. carriers are jumping into the BOD arena. Any feedback on how widespread BOD, and Multi-Layer Optimization, in other parts of the world?

Fernando Silva
6 years ago

Hi Faisal,
Very nice blog, I agree with you about the Killer cases, but I want to comment something. The real Killer case will be whatever is needed by the operator. Of course some common or similar cases will be available for anyone (as bandwidth/QoS/Growth on demand, but the amazing thing with SDN&NVF is that the operator con manage the network as he wants. so for different operators we will see different applications according to their needs, for instance in some cases where OpEx is a hot topic Miltylayer self provisioning will be a must, or network capacity optimization (L0/1/2/3/4), or network adaptation according to some criteria (as time, BW utilization, sporadic events, mobility, etc).
I think that the real killer case is any case and the added value of SDN is the programability and flexibility offered by SDN. We also need to take in consideration the huge challenges that the operators should face for SDN implementation, it´s a complete change in their minds and in the company culture.
Nobody will implement SDN to offer the same service as today. (changing to not change at all).
It´s nice to read interesting thoughts as yours! See you!

Roland Leners
Roland Leners
6 years ago

Hi Faisal,
Are there any ISVs that come to your mind wrt to multi-layer SDN controllers?

Fernando Silva
6 years ago

I recommend you this White Paper about SDN transformation. Multilayer approach for transport SDN.

Fernando Silva
6 years ago
Reply to  Faisal Khan

I´m seeing big attraction for XoD (Anything on Demand, as Bandwidth, QoS, Recovery, Temporary Circuits, etc). Also Multilayer is a main concern so several operators are looking for a seamless technology solution to manage their network, and SDN looks to be the solution that G-MPLS couldn’t solve in the past.

6 years ago

Very good comments for SDN.
One question: when all the network will change to SDN?

6 years ago

Faisal, what is a virtual logical network??

6 years ago

Hi Faisal

Million dollar question.

Multi-layer SDN controller : It will not be put to efficient use, implemented, accepted, scripted, owned if IP & Transport end up divorcing

I mean who will set the tone, the rules & regulations that will define the ability of the multi-layer SDN controller if IP & Transport departments are at confrontation with each other?

Its a recipe for disaster unless IP & Transport don’t take a step forward and handshake.

Wasted investment if its not put to use rather put to the sword!

6 years ago

Hi Faisal

But there has to be some human intervention at some point, the controller needs to be programmed to do something, it won’t have a human brain inside it. I understand in the event IP & transport folks join hands, then its a synergetic collaboration that would work wonders, but in many tier-1 operators worldwide, still IP & transport people have all their guns pointing towards each other.

It would be interesting too, who will get the authorization / responsibility, if its a transport guy he will comission the controller with a bias to favour transport nodes, while an IP guy will do otherwise.

Secondly, what security protocols / processes have been put in place to protect external / internal intruders from hacking the SDN controller(s), which will pose a massive threat to multi-layer network security, not a nice breach to experience.

6 years ago

Are data plane & forwarding plane synonymous terms?

David Bianchi
David Bianchi
6 years ago

Hi Faisal,

very well written, congrats! Finally a practical, operator viewpoint, article on SDN, with real use cases and useful discussion points.



6 years ago

Hi, Faisal,
This is wonderful article for T-SDN.
I think you did a lot of homework in studying SDN, it is a evidence of the your viewpoint:
“Transport world is already SDN like when it comes to concepts.
How ?
Control and forwarding plane are well separated and networks controlled and driven by central network management systems (two important attributes for SDN).

I think nobody can’t offer this point if he don’t study SDN deeply.
For this point, I want to make a supplement:
Actually, the technology and protocol for implement T-SDN architecture are mature and old, they are arisen some years ago. Like the PCE for south-bound protocol, GMPLS-UNI for signaling between IP-SDN and T-SDN. Of cause, there are still some protocol need standardization, like north-bound protocol and open-flow extend for TXM.
I totally agree with your perspective of two killer user case (Multilayer IP plus Transport Optimization and Bandwidth on Demand), it also is Huawei’s viewpoint for T-SDN, these two user cases are first step on the way to SDN; it is reason why Huawei provided these two function in SDN innovation with Spanish Telefonica, also we establish a SDN for IP+OPTICAL lab in Beijing China, and provide the SDN IP+OPTOACAL demonstrate for all operator in global.
Look forward reading your excellent article again.


Abdul Rauf
Abdul Rauf
6 years ago

Faisal, Masha Allah…This article is simply great. Clear understanding of SDN in Transport network.
I would say that, if we are working in Multi Vendor Environments I am sure this is more use ful. And offcourse “Killer use cases” to be taken care during implementation of this .

Is T-SDN implemented by any network ? Or still pilot projects are ongoing ?

Abdul Rauf
Abdul Rauf
6 years ago

Well , All the software features embedded on SDN Controller. So is there any vendor came up with SDN specific Routers/ Switches or Transport . Because, if the software features are moved to SDN Controllers, then obviously the Routers/ Switches or Transport equipment’s cost would come down. Suppose, let us say if we are payilng $25000 for Core Rotuer. The cost would come down to $12000 in SDN enabled router. What I mean is that, these equipments can be used only on SDN environment. Plus ,these Equipment’s are inter operable with current installed routers in Network

Would love your thoughts, please comment.x