Las tecnologías de virtualización Cloud (privada o pública), “Software defined lo que sea”, no solo traen consigo la flexibilidad y facilidad en la gestión de los sistemas y sus comunicaciones, sino que también tienen que plantear una automatización completa de los sistemas IT de la empresa.
Hoy en día, las tecnologías de software o “redes definidas de software” han superado las fronteras del centro de proceso de datos, y se han extendido al mundo WAN. Hablamos de SD-WAN, una solución muy interesante para oficinas remotas.
SDN y NFV plantean soluciones nuevas a varios problemas relacionados con las comunicaciones. Hablamos de las ventajas de estas tecnologías y el papel que desempeñarán en la evolución del sector.
Durante los últimos 2 años se habla mucho sobre la tecnologías SDN/NFV, que prometen cambios importantes en el actual escenario de las comunicaciones. Son muchas las voces que han señalado que el actual estatus de la red no permite la evolución rápida, la aparición de nuevos protocolos, ni facilita la puesta en práctica de nuevos servicios.
Podemos plantearnos la evolución de los protocolos existentes o crear nuevos protocolos que se ajusten a las necesidades actuales, pero introducir cambios en la red implica riesgos que no se quiere asumir. La red tiene sus deficiencias, pero funciona. Esta falta de interés en la evolución hace que algunos proclamen que la actual Internet está osificada.
La puesta en marcha de nuevos servicios de red obliga a los operadores a la creación de overlays por encima de la actual red IP. Estos overlays (túneles, VLAN, etc.) es un primer paso para la virtualización de la red.
Otro problema al que se enfrentan los operadores es que el ciclo de vida de un equipo es cada vez más corto, debido a la evolución muy rápida de la tecnología. Esto pone en aprietos a los operadores tanto desde el punto de vista técnico como económico (CAPEX/OPEX).
La tecnologías SDN y NFV se presentan como una solución para paliar los problemas anteriores.
SDN son las siglas de Software Defined Networking. La idea detrás de este concepto consiste en gestionar las redes de datos separando el plano de control del plano de datos. Las redes actuales se basan en el uso de cajas negras (routers) en las cuales el plano de control (protocolos de routing, listas de acceso, políticas…) y el plano de datos (switching, routing) no se pueden separar. Esto obliga a una adaptación por parte del operador a las características funcionales de cada fabricante.
El enfoque SDN consiste en centralizar el plano de control para, desde él, establecer la lógica de funcionamiento de la red formada por switches/routes (cajas blancas o bare-metal). Desde la parte central (SDN controller) se aplicará la lógica de switching/routing (flow tables) a los equipos por medio de protocolos como OpenFlow. Las operaciones de switching/routing se realizan basándose en las reglas almacenadas en las flow tables en los switches/routes.
1. Al ubicarse el software del controlador SDN en un lugar centralizado tendrá una visión global del estado de la red y podrá tomar decisiones globales, pudiendo actuar a la vez sobre todas las flow tables de los equipos. Esto es una ventaja frente a los actuales protocolos de routing dinámico, donde cualquier modificación del estado de la red tarda un tiempo finito en propagarse y durante el cual la red está en un estado de routing no estable.
2. A través de la interfaz OpenFlow (southbound API) se independiza el plano de control del plano de datos. Esto permite una integración más fácil de nuevos equipos a la red.
3. SDN permite que una parte de la red transporte tráfico en producción y otra parte tráfico para pruebas, que permita la innovación de funcionalidades y servicios. Es una suerte de virtualización de la red que permite el transporte de diferentes tipos de tráfico sin que se afecten entre ellos.
4. La mayoría de los controladores SDN del mercado (OpendayLight, FloodLight,…) tienen un interfaz (northbound API) con software de orquestación (OpenStack) desde donde se definen las políticas de la red.
5. Los controladores SDN actualmente en producción están escritos en lenguaje Java, lo cual reduce la pendiente de la curva de aprendizaje.
NFV son las siglas de Network Function Virtualization. La idea detrás de estas siglas consiste en lo siguiente: igual que en un Data Center (DC), desde orquestadores como OpenStack, se puede iniciar máquinas virtuales (VM) bajo demanda y que corran sobre cualquier servidor físico del DC. También se podrían iniciar funcionalidades de red en cualquier servidor accesible vía IP. Las funcionalidades de red virtualizadas (VNF) corren dentro de máquinas virtuales o en dockers. El conjunto de servidores sobre los que corren las VNFs, constituyen la red NFVI (NFV Infraestructure). Dichos servidores podrán estar situados en cualquier punto de la red del operador.
En principio no es necesario que NFV y SDN vayan de la mano, aunque sí se complementan. De hecho muchos de los objetivos y de las ventajas de ambas tecnologías son comunes.
Ejemplos de VNFs son los aceleradores de WAN, firewalls, seguridad, balanceadores, etc., es decir, todas las aplicaciones que hasta ahora se realizaban por medio de appliances. Además, se pueden añadir funciones típicas de routing como IPsec, túneles, routing dinámico, etc.
Hay ventajas de NFV que son comunes a las que se obtienen con SDN.
1. El tiempo necesario para tener operativa una funcionalidad de red se reduce considerablemente al no ser imprescindible un hardware específico. Es una cuestión de software.
2. Las VNFs corren sobre servidores off-the-shell.
3. Reduce la «osificación» de la red al permitir la innovación y su implantación de forma rápida.
4. Se independiza del hardware al poder ejecutarse sobre servidores off-the-shell.
5. Las operaciones de red se simplifican al poder realizarse de forma centralizada.
Este es el primer escenario de uso de estas tecnologías. Mediante orquestadores como OpenStack se gestionan las VMs para las operaciones de computación y el almacenamiento virtual. Las VMs, localizadas en distintos servidores, acceden a una red de nivel 2 por medio de soluciones como Open Virtual Switch (OVS). OVS tiene la característica de traspasar los límites de un servidor y garantizar el acceso al mismo switch virtual a VMs, que corren sobre servidores distintos. OVS puede ser gestionado por medio de controladores SDN como OpenDayLight.
Igual que las VMs de computación se pueden instanciar VNFs dentro de los límites del DC.
El éxito de la arquitectura de cloud basada en orquestadores + controladores + OVS se extiende a la WAN. Desde OpenStack se debe poder instanciar VNFs en los servidores de NFVI. Estos servidores pueden estar localizados en distintos puntos de la red del operador, por ejemplo, en los puntos de presencia del operador (POP).
Este esquema da lugar al concepto de vCPE (Virtual CPE): las funcionalidades de red ahora localizadas en las instalaciones del cliente pasan en parte a los servidores localizados en el POP o al propio cloud, dependiendo de las necesidades de latencia de los protocolos involucrados.
Las VNFs no evitan a los operadores depender de una red como la actual, con conectividad IP entre todos los puntos de la red. La infraestructura NFVI necesita que todos los servidores estén interconectados y accesibles desde el cloud.
SDN/NFV constituyen un desafío para los fabricantes de routers al presentar cambios tan radicales en la arquitectura actual de la red. Teldat no es ajena a este cambio y tiene como objetivo adaptarse al nuevo escenario. Un primer paso ha sido la posibilidad de ejecutar aplicaciones VNFs sobre nuestros routers, pudiendo separar los servicios de transmisión facilitados por el router, de los servicios de red puestos en práctica por las aplicaciones que corren en el 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.