Categories
Alan Weissberger Software Defined Network

HOTi Summary Part II. SDN & NFV Impact on Interconnects & Cloud Orchestration Lacking

Introduction:

This article summarizes the HOTi August 26th keynote presentation from SDx Central’s Roy Chua. The impact of SDN, NFV and other Software Defined WAN/ open networking schemes on Interconnects (for intra-Data Center (DC) communications) are described along with Roy’s conclusions. Mr. Chua described the emerging trends, hot topics and the impact SDe will have on interconnect technology. A postscript notes that Cloud Automation tools for infrastructure and apps are lacking and Roy comments on when SDN like methodologies might be able to help fix that huge problem.

Overview of Software-Defined Everything (SDe) and the Implications for Interconnects, by Roy Chua, SDx Central

Software-defined networking (SDN), software-defined storage, and the all-encompassing software-defined infrastructure have generated a tremendous amount of interest the past few years.

Roy first addressed the critical question of why interconnects matter. He said that performance improvements are needed in many areas within intra-Data Center communication and provided these examples:

  • Embedded memory performance gap vs CPU (getting worse)
  • CPU-to-CPU communications
  • VM-to-VM and container-to-container

It’s hoped and expected that SDx will help improve cost-performance in the above areas.


Note 1: In this context, “interconnects” are used to describe the connections between IT equipment (e.g. compute, storage, networking, management) within a Data Center (DC) or HPC center.  This is to be distinguished from DC Interconnect (DCI) which refers to the networking of two or more different DCs;

  • when the DC is operated by the same company, fiber is leased or purchased to interconnect the DCs in a private backbone network (e.g. Google).
  • when DCs operated by different companies (e.g. Cloud Service Provider DCs, Content Provider DCs or Enterprise DCs) need to be interconnected, a third party is used via ISP peering, collocation, cloud exchange (e.g. Equinix), or Content Delivery Networks (e.g. Akamai)

Note 2:  Containers were briefly defined in HOTi Part I. They are a solution to the problem of how to get software to run reliably when moved from one computing environment to another. This could be from a developer’s laptop to a test environment, from a staging environment into production and perhaps from a physical machine in a data center to a virtual machine in a private or public cloud.  Docker containers wrap a piece of software in a complete file system that contains everything needed to run: code, run time, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.


SDx Attributes and Hot Topics:

  • SDx provides: agility, mobility, scalability, flexibility (especially for configuration and turning up/down IT resources quickly).
  • Other SDx attributes include: visibility, availability, readability, security and manageability.
  • SDx hot topics include: SDN and NFV (Network Function Virtualization) in both DCs and WANs, policy driven networking, applications driven networking (well accepted API’s are urgently needed!)

Important NFV Projects:

  • Virtualization across a service providers network (via virtual appliances running on compute servers, instead of physical appliances/specialized network equipment)
  • CORD (Central Office Re-architected as a Data center)
  • 5G Infrastructure (does anyone really know what 5G is?)

Note: Roy didn’t mention the Virtualized Packet Core for LTE networks, which network equipment vendors like Ericsson, Cisco and Affirmed Networks are building for wireless network operators.


SDx for Cloud Service Providers may address:

  • Containers
  • Software Defined Storage
  • Software Defined Security
  • Converged Infrastructure

Other potential areas for use of SDx:

  • Server to server/ToR (Top of Rack) switch communications – orchestration, buffer management, convergence, service chaining
  • Inter DC WAN communications (mostly proprietary use cases and protocols by Google, Amazon, Facebook, Microsoft, Alibaba, Tencent, and other large cloud service providers)
  • Software Defined WAN [SD-WAN is a specific application of SDN technology applied to WAN connections, which are used to connect enterprise networks – including branch offices and data centers – over large geographic distances.]
  • Bandwidth on Demand in a WAN or Cloud computing service (XaaS)
  • Bandwidth calendering (changing bandwidth based on time of day)
  • XaaS (Anything as a Service, including Infrastructure, Platform, and Applications/Software)
  • 5G (much talk, but no formal definition or specs)
  • Internet of Things (IoT)

NFV Deployment and Issues:

Roy said, “There are a lot of unsolved problems with NFV which have to be worked out.” Contrary to a report by IHS Markit that claims most network operators would deploy NFV next year, Roy cautioned that there will be limited NFV deployments in 2017 with “different flavors of service chaining” and mostly via single vendor solutions.

–>This author strongly agrees with Roy!


Open Networking Specifications Noted:

  • Open Flow® v1.4 from the Open Network Foundation (ONF) is the “southbound” API from the Control plane to the Data Forwarding plane in classical SDN. Open Flow® allows direct access to and manipulation of the Data Forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based).

[Note that the very popular network virtualization/overlay model of SDN does not use Open Flow.]

  • P4 is an open source programming language designed to allow programming of packet forwarding dataplanes. In particular, P4 programs specify how a switch processes packets. P4 is suitable for describing everything from high-performance, packet forwarding ASICs to software switches. In contrast to a general purpose language such as C or Python, P4 is a domain-specific language with a number of constructs optimized around network data forwarding.
  • Switch Abstraction Interface (SAI) from the Open Compute Project: Microsoft, Dell, Facebook, Broadcom, Intel, Mellanox are the co-authors of the final spec (v2) which was accepted by the OCP in July 2015.

Roy’s Conclusions:

  • SDx is an important approach/mindset to the building of today’s and tomorrow’s IT infrastructure and business applications.
  • The requirement for agility, flexibility and scalability drives the need for higher-speed, higher-capacity, lower latency, lower cost, greater reliability interconnects at all scales (CPU-memory, CPU-CPU, CPU-network/storage, VM to VM, machine to machine, rack to rack, data center to data center).
  • Interconnect technology enables new architectures for SDx infrastructure and innovations at the interconnect level can impact or flip architectural designs (faster networks help drive cluster-based design, better multi-CPU approaches help vertical scalability on a server).
  • The next few years will see key SDx infrastructure themes play out in data centers as well as in the WAN, across enterprises and service providers (SDN and NFV are just the beginning).

Postscript:

I asked Roy to comment on an article titled: Lack of Automated Cloud Tools Hampers IT Teams. Here’s an excerpt from that surprising finding:

“While most organizations are likely to increase their investments in the cloud over the next five years, IT departments currently struggle with a lack of automated cloud apps and infrastructure tools, according to a recent survey from Logicworks. The resulting report, Roadblocks to Cloud Success, reveals that the vast majority of IT decision-makers are confident that their tech staffers are prepared to address the challenges of managing cloud resources. However, they also feel that their leadership underestimates the time and cost required to oversee cloud resources. Without more cloud automation, IT is devoting at least 17 hours a week on cloud maintenance. Currently, concerns about security and budget, along with a lack of expertise among staff members, is preventing more automation.”

Wasn’t SDN and other flavors of “open networking” suppose to solve the cloud automation problem for all cloud services (IaaS, PaaS, SaaS, etc)?  We’ve been led to believe that SDx, with its promise and potential to deliver all sorts of benefits (agility, flexibility, zero touch provisioning, seamless (re-)configuration, scalability, orchestration, etc.) could be effectively used to automate cloud infrastructure and apps. The big cloud providers, especially Microsoft and Google have described use of SDN concepts within their cloud network infrastructure. But where are the cloud automation tools and when might they be available?

Here’s an illustration of a Software Defined Cloud Data Center with “Automation” shown in the lower panel titled “Cloud Management Plane.”

The different tiers of Software Defined Infrastructure are shown in the above illustration, courtesy of
The different tiers of Software Defined Infrastructure are shown in the above illustration, courtesy of Vamsi Talks Tech

Roy replied via email:

“Interesting article—my short immediate reaction is that we’re going through a transitional period and managing the number of cloud resources can bring its own nightmares.  In addition, the management tools haven’t quite caught up yet to the rapid innovation across cloud infrastructures.”

Thanks Roy!

Author Alan Weissberger

By Alan Weissberger

Alan Weissberger is a renowned researcher in the telecommunications field. Having consulted for telcos, equipment manufacturers, semiconductor companies, large end users, venture capitalists and market research firms, we are fortunate to have his critical eye examining new technologies.

2 replies on “HOTi Summary Part II. SDN & NFV Impact on Interconnects & Cloud Orchestration Lacking”

Thanks for the part II article that complements Part I and is perfect for someone such as myself who is on the outside looking in as to what is going on with SDx.

Regarding the tools, it seems to be the same old story of operations being the last thing to be addressed when engineering a solution.

Having said that, I wonder if the lack of cloud automation tools is indicative of where things are in the market and that, over time, as repeatable pain points are identified and it becomes cheaper/more secure to automate, then the appropriate tools will be developed?

Also, I just found this article that does a good job of summarizing the concept behind CORD (eliminating disparate proprietary hardware at the CO and making turning up, faster and repairs easier (common hardware, instead of purpose-built).

https://www.linux.com/blog/how-cord-project-will-change-economics-broadband%20

Ken, Thanks for your comment. Please note that the CORD project, started by AT&T but now with many others including China Unicom, Ciena, Google, NEC, ON.Lab, ONF, The Linux Foundation, University of Arizona, and Verizon. It’s much more of a dis-aggregating & then virtualizing Network Access Equipment functions, starting with GPON OLT and then extending to G.Fast (high speed DSL) equipment. CORD project was only mentioned once by Roy Chua and by no other HOTi speakers. That’s probably because there were no other high level talks, other than Ariel Hendel’s which was summarized in HOTi Part I article.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.