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. Plus get notified when important blogs are published.

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. Plus get notified when important blogs are published.

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.

35 thoughts on “Things, Transport SDN vendors may not tell you, but you must ask them!”

  1. 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 .

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

    1. Thanks Jon for commenting. Unfortunately, the SDN for transport networks deal with analog optical signals. Which is a total different than the digital world. Therefore it would not be easy, at least in foreseeable future to replace the optical equipment with x86 server type machines

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

  4. 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!

    1. Hi Carlo,

      Thanks for very useful comments.

      1. SDN for Network analytics.
      As you know that such analytics are already available with operators and can do WHAT IF Scenarios. Perhaps SDN will be able to do this across multi layers compared to single layers todays
      2. SDN for virtualized network.
      Also, here an operator can commit on the latency and e2e encrypted service without making the service/network virtualized( Possible by keeping the traffic on lowest possible layers). Having said so, with the virtualized network, the end customer will have more control over the network as it belongs to him. So, if the end goal is that the end user would keep all the control over provisioning and O&M, then yes it is a great use case. However I have seen here that many customers are only interested in service but would not like to take control over their virtualized network completely.

  5. 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?

    1. Thanks Tom Clarke,

      I can talk from our region point of view ( MEA), the operators have started taken interest but it is too early for implementation , especially considering that the Multi Layer is still immature.

  6. 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!

    1. Thanks Feranando,

      for interesting comments.

      You hit the nail. Yes SDN is all about the programmability and flexibility. The use cases will differ from one to the other. That’s the beauty of the SDN itself. What I brought to the limelight was considering my experience as an operator and the pain points I see today with our network.

      I see today a lot room for optimization in the areas of multi layers where the layers work discreetly with no information sharing between them. This is really adding to the OPEX and CAPEX today. Its time SDN solved this issue.



    1. Hi Roland,

      Thanks for getting in touch.

      Don’t know of any ISV with respect to multli layer SDN controller. Recommend to get touch with the main transport vendors that are developing multi layer SDN controllers.



    1. Thanks Fernando for the share,

      Interesting to see vendor’s perspective here.

      So are you focusing on any particular use case with your first release of SDN ?



      1. 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.

    1. Thanks Dai,

      Good question. However hard to answer. It would NOT be very easy to change all networks to SDN because it will be too much disruptive. What might happen is that an SDN overlay is added above, keeping legacy network still running. For new deployments, it would be NOT be difficult to go straight to SDN.


    1. what is not physical can be called virtual or logical. I have updated the table to remove this confusion. Thanks for pointing out

  7. 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!

    1. Thanks Ali for Million dollar question 🙂

      I will make it simple. The goal is to have one team that will look after both IP and Transport so I don’t see any conflict here.

      Who will set the rules ? The multi layer controller will be intelligent enough to decide on which layer the restoration should happen and on which layer should be used to carry the traffic making the layers more optimized for bandwidth. So it will not need any human intervention here that might lead to confusion between IP and transport folks as you mentioned.

      Hope it makes sense.

  8. 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.

  9. Hi Ali,

    Not necessarily the way you are thinking. The intelligence can be some established rules ( the tool pre-programmed that way ) like in case of fiber cut, the system should look for optical resources first to restore traffic, if it does not find them it should go to higher layers. I dont see a conflict here.

    You raised a valid point about security. The originators of SDN thought already about such issues. Centralized controller does not necessarily mean that there is one controller, it could be a logically centralized controller but distributed geographically to avoid SPOFs.

  10. Hi Faisal,

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



  11. 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.


    1. Thanks Eric,

      For commenting on article. You are right the T-SDN Architecture should evolve around important use cases of which the ip+OPTICAL and bandwidth on demand aree the two most important ones.



  12. 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 ?

    1. Thanks Abdul Rauf,

      T-SDN ( all use cases ) as a whole is not implemented in any network. one may find some use cases in basic form, here and there, but not really mature. It is still a work going on and some pilot projects are being tested.


  13. 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

    1. AbduLRauf,

      There is no need for SDN specific router as long as the software can run on any commodity server or switch. The cost of hardware automatically goes down.


Leave a Comment

Your email address will not be published. Required fields are marked *