These are the technologies that look promising but could go either way for Network Architecture 2020. Time (and research) will tell if they are really winners or losers.
Though not a complete list, let's take a look at some key technologies.
Cloud Radio Access Network (C-RAN)
With Network Architecture 2020 putting mobile first, Radio Access Networks (RAN) are vital. These are the access layer radio networks which connect the end user's device to the network.
For the case of cellular networks, the RAN can be thought of as a remote radio head (RRH), which sends and receives the wireless data transmissions, and a baseband unit (BBU) which handles complicated signal processing and other tasks.
Historically deployed using expensive, proprietary hardware, in the C-RAN approach the RAN moves to a large-scale centralised deployment model, using open hardware and software to create a 'BBU hotel', a centralised location where the expensive computing resources are housed.
Each RRH traditionally has had its own BBU, connected at first directly and then via data networks, such as fibre or high-capacity wireless networks. C-RAN differs here by offering a pool of virtualised BBU resources, allowing load balancing and better utilisation of resources at any given time. Each RRH connects back to this pool using a high-capacity data network.
Potentially, this enables not just resource optimisation but cognitive or collaborative radio operation, where every RRH and BBU can co-ordinate across the RAN with its counterparts to optimise network performance.
Whilst C-RAN certainly shows much potential, changing computing resource placement in the network may yield a competing architecture where each RRH once again has significant compute capability.
Further time and research will determine if C-RAN is a winner, but it looks good.
Software Defined Wide Area Network (SD-WAN)
For a business to obtain a dedicated, private connection, the option for many years has been a Multiprotocol Label Switching (MPLS) circuit, which service providers have been more than happy to sell at considerable cost to the end user.
However, the assumption that a given business needs rock-solid connectivity and that a private line is the only way to achieve that is being challenged by the emergence of SD-WAN technologies.
These technologies form a private, encrypted tunnel across the public internet, favouring the opportunistic bandwidth and lower costs available compared with a dedicated connection.
With an SD-WAN gateway at each end of the connection, the private link is established; the gateway devices also handle traffic steering, failover and the other expected capabilities for a business internet connection today.
Whilst there is a lot of talk and enthusiasm around the technology, the long-term impact of it on the business models of service providers is not clear. Some have taken to providing their own SD-WAN services; others have stuck to their MPLS or Ethernet Private Line (EPL) guns, eager to hold onto those high-paying users.
If SD-WAN does mount a fundamental challenge to the service provider business model, which it certainly has the capability to do, then it has the potential to become a winner. If this happens, network architecture will have to account for it.
If it doesn't, the technology with all of its potential will likely wither on the vine.
The OpenFlow protocol was going to change it all - it was to be the first building block of true Software Defined Networking (SDN), the crucial interface between the forwarding plane of network devices and the SDN controller in the network, letting software easily reconfigure the very guts of a switch on the fly.
LAN, WAN and data centre would fall at it's feet.
Unfortunately, it didn't play out as planned. Version 1.0 of the protocol was limited, but did receive some decent support in switching hardware. By the time version 1.3 rolled around with some improved capabilities, many of said capabilities were optional - and many vendors didn't implement them.
As the protocol was a mechanism to add forwarding rules directly into the memory of a switch, it was bound to result in a greater number of rules than existed previously - otherwise, the benefits of greater control can be hard to see.
But, many switches weren't built for this - Ternary Content Addressable Memory (TCAM), the specialised memory used for storing forwarding rules for quick search and matching, is expensive, big and runs hot.
Adding extra for little perceived benefit was not attractive to white-box manufacturers, already struggling with the profit margins on their hardware. Incumbent vendors also saw it as a threat to their own product lines, and many introduced competing protocols and APIs.
After a while, SDN and OpenFlow began to drift apart, the former an umbrella term for the separation of the control and data forwarding planes of the network, the latter mentioned less as enthusiasm began to drop off.
SDN continues apace - though the term is criminally overused, often applied to things unrelated to the core concept of SDN - but OpenFlow won't be joining it as originally envisioned, a tightly-coupled motorcycle and sidecar, outside of some specific use cases and deployments.
Much potential remains, but SDN and OpenFlow are no longer synonymous.
What else will be a contender?
Many more are certain to join this list as Network Architecture 2020 research continues. Exciting times are upon us as innovative technologies emerge.
What are the losers?
Okay, so we've seen some promising contenders.
How about some winners?