{"id":675,"date":"2014-10-01T09:16:00","date_gmt":"2014-10-01T06:16:00","guid":{"rendered":"https:\/\/telcocloudbridge.com\/?p=675"},"modified":"2014-10-01T09:16:00","modified_gmt":"2014-10-01T06:16:00","slug":"things-transport-sdn-vendors-may-not-tell-you-but-you-must-ask-them","status":"publish","type":"post","link":"https:\/\/telecomlighthouse.com\/?p=675","title":{"rendered":"Things, Transport SDN vendors may not tell you, but you must ask them!"},"content":{"rendered":"<p>&nbsp;<\/p>\n<p>So you have your next appointment with a Transport\/optics vendor for a presentation on its Transport SDN roadmap.<\/p>\n<p>And you are all set to explore the rosy picture the vendor wants to present about its\u00a0 Transport SDN\u2019s roadmap.<\/p>\n<p>Therefore, it\u2019s time to do some homework, so you can ask right questions from the <a href=\"https:\/\/telecomlighthouse.com\/blog\/naas-as-step-towards-sdn\/\">vendor about its SDN strategy<\/a>.<\/p>\n<p>Be with me, as I take you through\u00a0a list of use cases of Transport SDN. Then tell you what the TWO important <b>\u201cKiller use cases\u201d<\/b> are for Transport SDN. ( and give you reason why I shortlisted two)<\/p>\n<p>So, here are <span style=\"text-decoration: underline;\"><strong>two goals of my blog<\/strong>:<!--more--><\/span><\/p>\n<p>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.<\/p>\n<p>b) If you are a vendor, you get to know an operator\u2019s perspective about Transport SDN\u2019s priorities.<\/p>\n<p>But before we proceed I intend to tell you why this whole discussion is so important, in the first place.<\/p>\n<p>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\u00a0 dubbed as \u201cSDN\u201d, after all.<\/p>\n<p>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.<\/p>\n<p>So someone ought to separate wheat from chaff.<\/p>\n<p>And that is you &#8211;\u00a0the operator!<\/p>\n<p>And if you know what the important applications for Transport SDN are, you can easily engage with\u00a0 SDN vendors and drive\u00a0them rather than vice versa.<\/p>\n<p>Before that, you should understand <span style=\"text-decoration: underline;\"><strong>one important thing<\/strong><\/span>!<\/p>\n<p>Transport world is already SDN like when it comes to concepts.<\/p>\n<p>How ?<\/p>\n<p>Control and forwarding plane are well separated and networks controlled and\u00a0 driven by central network management systems (two important attributes for SDN).<\/p>\n<p>Add to these, features of\u00a0openness\u00a0\u00a0for the interfaces and\u00a0 Open APIs (ongoing work by vendors) and you are well on the path of full-fledged SDN.<\/p>\n<p>So SDN in the transport world should not be as big of a paradigm shift as it is for the data center world.<\/p>\n<p>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.<\/p>\n<p>Therefore!<\/p>\n<h5><span style=\"text-decoration: underline;\">Top Transport SDN use cases should solve real issues!<\/span><\/h5>\n<p>&nbsp;<\/p>\n<p>So what are these issues and how do they relate to the use cases?<\/p>\n<p>To answer this question we proceed as following:<\/p>\n<ul>\n<li>We list the fours use cases as listed in the original white paper of Transport SDN by ONF ( Open Networking foundation)<\/li>\n<li>Then I discuss on why I think two of the use cases are more important and what issues they can solve for operators.<\/li>\n<\/ul>\n<p>My Benchmark for the Killer Transport SDN Use case is following<\/p>\n<p>1. It should solve pressing issues of an operator.<\/p>\n<p>2. It should reduce both CAPEX and OPEX<\/p>\n<p>Now lets move to the use cases.<\/p>\n<p>The four Use Cases from ONF are following:<\/p>\n<table style=\"width: 805px; height: 305px;\" border=\"4\" width=\"805\" cellspacing=\"0\" cellpadding=\"2\">\n<tbody>\n<tr>\n<td valign=\"top\" width=\"74\">Use Case<\/td>\n<td valign=\"top\" width=\"206\">Name<\/td>\n<td valign=\"top\" width=\"319\">Description<\/td>\n<td valign=\"top\" width=\"212\">Application<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"74\">1<\/td>\n<td valign=\"top\" width=\"206\">Bandwidth on Demand<\/td>\n<td valign=\"top\" width=\"319\">Increasing or decreasing, dynamically, the optical\u00a0 bandwidth between data centers automatically or on demand.<\/td>\n<td valign=\"top\" width=\"212\">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.<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"74\">2<\/td>\n<td valign=\"top\" width=\"206\">Private Optical Networks for Enterprises<\/td>\n<td valign=\"top\" width=\"319\">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.<\/td>\n<td valign=\"top\" width=\"212\">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<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"74\">3<\/td>\n<td valign=\"top\" width=\"206\">Virtualized Network<\/td>\n<td valign=\"top\" width=\"319\">Slicing\u00a0 physical network in a way that different virtual networks can be run on the same physical network.<\/td>\n<td valign=\"top\" width=\"212\">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.<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"74\">4<\/td>\n<td valign=\"top\" width=\"206\">IP \/ Optics Multilayer Optimization<\/td>\n<td valign=\"top\" width=\"319\"><a href=\"https:\/\/telecomlighthouse.com\/blog\/need-quick-recipe-sdn-wan-mix-bgp-ls-pce\/\">Common SDN Controller controlling Optical<\/a> and IP Network making it easy to provision, maintain, route and optimize the bandwidth at each layer.<\/td>\n<td valign=\"top\" width=\"212\">Results in\u00a0 significant bandwidth saving and efficient management of both IP and Optical networks.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<h4><\/h4>\n<h3>Killer Use Case#1 for Transport SDN: Multilayer IP plus Transport Optimization<\/h3>\n<p>&nbsp;<\/p>\n<h5>What issues this use case is targeting?<\/h5>\n<p>IP and transport run as two separate layers, today, with no coordination between them. IP is considered a client for transport layer.<\/p>\n<p>This leads to something called \u201cdumb pipe\u201d strategy.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>So what is the optimization of IP and Transport that we often talk?<\/p>\n<p>Actually optimization results when we have definite answers to questions like<\/p>\n<p>a. Are bytes travelling at the optimal layer (IP, Optics, and OTN)?<\/p>\n<p>b. Is traffic protected and rerouted on the optimal layers?<\/p>\n<p>If we don\u2019t have answers, then certainly the network needs optimization from layer zero to layer three.<\/p>\n<h5><\/h5>\n<h5>How this\u00a0Use Case \u00a0solves the issue?<\/h5>\n<p>Let\u2019s look at one of the architectural diagram of this use case for Transport SDN.<\/p>\n<p><a href=\"https:\/\/telecomlighthouse.com\/wp-content\/uploads\/2014\/09\/clip_image0011.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;\" title=\"clip_image001\" src=\"https:\/\/telecomlighthouse.com\/wp-content\/uploads\/2014\/09\/clip_image001_thumb1.png\" alt=\"clip_image001\" width=\"388\" height=\"356\" border=\"0\" \/><\/a><\/p>\n<p>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.<\/p>\n<p>In this topology each domain controller gives sufficient topology, latency and performance information to Multi-layer SDN controller.<\/p>\n<p>The Multi-layer controller would then do optimized decision on path computation and restoration management.<\/p>\n<p>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.<\/p>\n<h5><\/h5>\n<h5>Benefits:<\/h5>\n<p>1.\u00a0 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.<\/p>\n<p>2. CAPEX reduction as no need to overbuild routers and optical network as resources are highly optimized at these layers.<\/p>\n<p>2. OPEX reduction through automating processes that will reduce manual configuration errors.<\/p>\n<h5>\u00a0Next steps for operators:<\/h5>\n<p>This feature is needed, mandatory and would\u00a0result in\u00a0reducing OPEX and CAPEX tremendously as listed in benefits section. Ask for this feature \/use case to be implemented by\u00a0your vendors.<\/p>\n<h5>Next steps for vendors:<\/h5>\n<p>Expedite the\u00a0Transport SDN\u00a0roadmaps. Prioritize this feature if it is in the roadmap. Listen to operators! \u00a0here.<\/p>\n<h3><\/h3>\n<h3><\/h3>\n<h3><\/h3>\n<h3><b>Killer Use Case#2 for Transport SDN: Bandwidth on Demand<\/b><\/h3>\n<p>&nbsp;<\/p>\n<h5>What issues this use case is targeting?<\/h5>\n<p>The bandwidth as provided today is static and not dynamic.<\/p>\n<p>Worst still, networks today are not optimized for bursty traffic (For example data centers traffic). To cope with\u00a0 bursty traffic, links are overprovisioned which are not utilized efficiently most of the time.<\/p>\n<p>For end customers, it means paying more cost for the links which remain under-utilized, most of the time.<\/p>\n<p>For operators, it results in two issues<\/p>\n<p>a.\u00a0Operators\u00a0CANNOT \u00a0address the mass market that would like to purchase\u00a0 bandwidth in small granularities but CANNOT because of the only option of buying max pipes to meet their bandwidth requirements.<\/p>\n<p>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.<\/p>\n<h5><\/h5>\n<h5>How this Use Case \u00a0solves this issue?<\/h5>\n<p>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 \u00a0App that can check the contract of customers and if the contract allows, it can automatically increase the bandwidth when traffic bursts come.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<h5><\/h5>\n<h5>Benefits<\/h5>\n<p>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.<\/p>\n<p>2. CAPEX reduction for customers as they don\u2019t need to buy peak rates contracts.<\/p>\n<p>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.<\/p>\n<h5><\/h5>\n<h5>Next steps for Operators<\/h5>\n<p>&#8220;Bandwidth on Demand&#8221; 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.<\/p>\n<h5>Next Steps for Vendors:<\/h5>\n<p>Bandwidth on Demand is a genuine need of operators. This feature should be prioritized, compared to any other <a href=\"https:\/\/telecomlighthouse.com\/blog\/faq-about-software-defined-networking-sdn\/\">feature of the Transport SDN<\/a> on your roadmap.<\/p>\n<h3><\/h3>\n<h3><\/h3>\n<h3>Other Use Cases and Conclusion:<\/h3>\n<p>&nbsp;<\/p>\n<p>What describes above are the \u201cKiller use cases\u201d for Transport SDN, in my perspective. There are other use cases as described in the above table.<\/p>\n<p>Out of these \u201cVirtualized network\u201d 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.<\/p>\n<p>However in my perspective such applications fall more under monetization opportunities \u00a0for an operator rather than solving some pressing needs of operators.<\/p>\n<p>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.<\/p>\n<p>Further, the \u201cPrivate Optical Network\u201d uses <a href=\"https:\/\/telecomlighthouse.com\/blog\/sdn-project-onos-challenges-optical-vendors-business-model\/\">case talks about transferring administration of optical network<\/a> 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.<\/p>\n<p>SDN is still immature in terms of Transport and <a href=\"https:\/\/telecomlighthouse.com\/blog\/autonomous-sd-wan-by-cloudgenix-my-analysis\/\">WAN applications<\/a>.<\/p>\n<p>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 \u201cKiller use cases\u201d.<\/p>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&nbsp; 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\u00a0 Transport SDN\u2019s roadmap. Therefore, it\u2019s time to do some homework, so you can ask right questions from the vendor [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":683,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-675","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sdn"],"_links":{"self":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/675","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=675"}],"version-history":[{"count":0,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/posts\/675\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=\/wp\/v2\/media\/683"}],"wp:attachment":[{"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomlighthouse.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}