Virtualization technologies, Cloud (private or public), “Software-defined whatever” not only bring simplicity and flexibility to systems and communications management, but also require the full automation of company IT systems.
Today, software-defined network technologies (SDN) can be applied to many more situations than initially thought (i.e., data processing centers) and are being used in the field of WAN to bring, over and above virtualization, resource optimization, flexibility and dynamism to the connectivity services for customers.
During the past two years, a lot has been discussed about SDN/NFV technologies which promise major changes in the current communication scenarios. Many have pointed out that the current network status does not allow a quick evolution, new protocols or facilitate the implementation of new services.
We can consider the evolution of existing protocols or creating new ones that meet current needs, but introducing changes onto the network is very risky and no one wants to take these risks. The network has its shortcomings, but it works. This lack of interest in the evolution make some people say that the current Internet is ossified.
The implementation of new network services require operators to create overlays over the current IP network. These overlays (tunnels, VLAN…) are a first step towards the network virtualization.
Another problem operators are facing is that the life cycle of devices is becoming shorter as technology evolves very quickly. Hence operators are hard-pressed both from a technical and economical (CAPEX/OPEX) point of view.
SDN and NFV technologies are presented as a solution to the above problems.
SDN is the acronym for Software Defined Networking. The idea behind this acronym is to manage data networks by separating the control plane from the data plane. Current networks are based on the use of black boxes (routers) in which the control plane (routing protocols, Access lists, policies,…) and the data plane (switching, routing) cannot be separated. This would require the operator to adapt the functional features of each manufacturer.
The SDN approach consists in centralizing the control plane, so that from this, the network operational logic made up by switches/routers (white boxes or bare-metal) can be established. From the central part (SDN controller) the switching/routing (Flow tables) will be implemented into the devices through protocols such as OpenFlow. The switching/routing operations are made based on the stored rules in the flow tables in the switches/routes.
1.When the SDN software controller is placed in a centralized location. It will have a global vision of the network status and may take global decisions, allowing it to act simultaneously on all the devices’ flow tables. This is an advantage versus current dynamic routing protocols, in which any network status modification takes a finite time to spread and during which the network is in an unstable routing status.
2. Via the OpenFlow interface (southband API) the control and data planes become independent. This allows an easier integration of new devices to the network.
3.SDN allows part of the transport network for working traffic and another part of the transport network for testing. This permits new features and services innovation. It’s an advantage of network virtualization that allows different types of traffic transportation without affecting each other.
4.Most of the SDN controllers on the market (OpendayLight, FloodLight,…) have an interface (northbound API) with Orchestration Software (OpenStack) from where the network policies are defined.
5. The SDN controller currently in production are written in Java, which reduces the slope of the learning curve.
NFV is the acronym for Network Function Virtualization. The idea behind this acronym is as follows: As in a data center (DC), from orchestrators such as OpenStack, virtual machines (VM) can run when requested on any physical DC server, from which network features could work on any accessible server via IP. Virtualized Network Features/Functionalities (VNF) run within virtual machines or dockers. The set of servers on which VNFs run, make up the NFVI (NFV Infrastructure) network. These servers may be located at any point of the operator network.
Initially it is not necessary that NFV and SDN go together, even if they complement each other. In fact many of the objectives and advantages of both technologies are shared.
WAN accelerators, firewalls, security, balancers, etc are examples of VNFs i.e all applications that until now were performed through the appliances. Moreover, typical routing features such as IPsec, tunnels, dynamic routing can be added.
There are shared NFV benefits which are obtained with SDN.
1.The necessary time to have a network feature up and running is considerably less, as a specific hardware is not essential. It is a software issue.
2.The VNFs run on off-the shell servers.
3.Reduce network “ossification” by allowing innovation and quick implementation.
4.It becomes independent from the hardware by being able to run on off-the-shell servers.
5.The network operations are simplified as they can be carried from a central point.
Cloud is the first scenario for the use of these technologies. Through orchestrators such as OpenStack VMs are managed for computing and virtual storage operations. VMs, located on different servers, have access to a level 2 network through solutions such as Open Virtual Switch (OVS). OVS is able to look beyond the limits of a server and ensure access to VMs that run on different servers to the same virtual switch. OVS can be managed through SDN controllers such as OpenDayLight.
As with the computing VMs, VNFs can be instantiated within the DC’s limits.
The success of the cloud architecture based on orchestrators + controllers + OVS is extended to the WAN. From OpenStack it should be possible to instantiate VNFs within the NFVI servers. These servers can be located in severals parts of the operator network, for example, in the operator point of presence (PoP).
This solution leads to the vCPE concept (Virtual CPE): The network features now located in the client installations are partly shifted to the servers located in the PoP or on the cloud, depending on the latency needs of the involved protocols.
VNFs will not prevent the operators from having a network as at present in the sense of IP connectivity between all the network positions. NFVI infrastructure needs all the servers to be interconnected and accessible from the cloud.
SDN/NFV are a challenge for router manufacturers, as they introduce radical changes to the current network architecture. Teldat is not indifferent to this change and aims to adapt to the new scenario. The ability to run applications (VNFs) over our router has been a first step, allowing to split transmission services provided by the router from the network services implemented by applications that run within the router.
NFV (Network Functions Virtualization) is a new network architecture that proposes to extend the virtualization technology used in the traditional IT environment to the different network elements, to create more flexible networks and services, easier to deploy and operate, for a reduced cost. While RAID and virtualization meant a revolution on the storage technology and on the computing and operating systems technologies respectively, SDN and NFV propose an equivalent transformation on the communications networks. Cloud Computing would not have been possible without the former technologies and SDN and NFV, in turn, rely on Cloud Computing technologies to deliver their promise.
SDN (Software Defined Networking) is also an emerging network architecture that centralizes the view and control of the network, separating the forwarding decisions (control plane) from the network elements that in fact forward the packets of information (data plane), moving, in this way, the intelligence to the “center” of the network from the previously remotely distributed networks elements, like switches or routers.
SDN and NFV can exist independently of each other, but they are, in fact, complementary technologies that reinforce themselves when used simultaneously.
NFV is being pushed and promoted mainly by network operators, in the fight with the “Over-the-Top” service providers, which use network operators’ networks as “dumb pipes” to offer value added services and applications to the end users. With NFV, network operators seek to reduce the time to market of new services generation and provisioning, lower the required investment (CAPEX) and the operating and maintenance cost (OPEX) and expedite the innovation by favoring open-source initiatives.
NFV (and SDN) can theoretically be applied to any network element, network part, or function. For instance, it could be applied to the Mobile Core Network of a mobile operator or to the load balancer gear of a data center.
In more or less degree, part of the functionality of these network elements is subject to be virtualized and offered, for a lower cost, in a central location, using traditional low-cost COTS (Commercial Off-The-Shelf) servers running open-source based software, instead of proprietary hardware and software from established vendors. Or at least this is what many network operators are chasing, promoting and starting to test or even trial in the real world.
But, how does all this apply to the enterprise branch office access router, that is the main network element or “function” that Teldat provides? Does this specific network element have any peculiarity or characteristic that could influence or condition the way it can benefit from the NFV and SDN technologies?
A rigorous analysis falls out of the scope of this post and one will find both advantages and disadvantages when virtualizing a network element such as the access router or CPE. But regardless of the amount of functionality that might be virtualized, let us first say that we see tough to create “smarter networks” by using “dumber routers”. This does not mean that NFV does not apply to the enterprise branch office access router, but that from all the potential benefits of the NFV and SDN technologies, the CAPEX reduction is probably the less interesting one, or in other words, the toughest to obtain.
Some market initiatives, like the HGI (Home Gateway Initiative), founded in 2004, promote a model that increases the functionality of the CPE by embedding on it a “Software Execution Environment”, able to locally execute several applications or functions. This is the opposite of the NFV model regarding where to put the “intelligence”. Both architectures will probably coexist in the foreseeable future, since both have advantages and drawbacks depending on the specific use case.
SDN benefits are rarely questioned on the datacenter and specifically on the datacenter switches. Nevertheless, the access network and in particular the “last mile” is a much more heterogeneous environment and the bandwidth, in roughly all the cases, cannot be considered “unlimited”, as you could “model” in a Terabit/s datacenter infrastructure. Clearly this has strong implications on the NFV possibilities for a CPE.
The more complex the network element or function, the more potential NFV has to introduce benefits for the network operator. But also, the more heterogeneous the network element environment, the more complicated is to provide an equivalent “homogeneous” virtualized scenario. The last mile is a quite complex element, with non-trivial requirements such as security, quality of service, redundancy and resilience, different media adaptation, etc. On the other side, the last mile is also a quite heterogeneous scenario, especially for integrated or converged network operators that offer a broad range of access technologies.
Before a widespread adoption of SDN and NFV can occur, a crucial issue must be solved: Interoperability must be guaranteed, so that network operators do not find themselves locked into a specific vendor solution. Carriers should be warned by their experience in the GPON world with the OMCI “proprietary” management, just one fraction of the complexity NFV can imply. The open-source oriented path the network operators are proposing can be very beneficial for them, but it will not solve this interoperability problem per-se and an “integrator” figure is needed. And “integrator” or “vendor” in this regard is pretty much the same thing.
At Teldat we follow the SDN and NFV trends with interest and we think they will definitely change the networks for good. Being a vendor that focuses on the customer premises side of the communications, we have always needed to interoperate with the network and use and promote the use of standard-based communications. Our coming devices and many of the existing ones are future proof and SDN/NFV-ready. We do this by designing smarter devices that can create smarter networks. Although some network functions can be virtualized, the enterprise branch office network in the cloud-computing era is complex enough to benefit from a powerful future-proof access router.