diseño e implementación de un bloque funcional para el

DISEÑO E IMPLEMENTACIÓN DE UN BLOQUE FUNCIONAL
PARA EL DESPLIEGUE DE LA SFC DESDE UN ORQUESTADOR
NFV HACIA UN CONTROLADOR SDN.
Autor: María Gil Cárdenas.
Director: Giuseppe Carella.
Entidad colaboradora: FOKUS | Fraunhofer-Institut für Offene Kommunikationssysteme
RESUMEN
Este proyecto consiste en diseñar e implementar un bloque funcional que colabore
con la integración del paradigma SFC (Cadena de Funciones de Servicios) dentro de una
plataforma de orquestación NFV (Virtualización de Funciones en Red), en conformidad
con el estándar NFV-MANO, de gestión y orquestación. Las primeras tareas incluyen
documentación acerca de las posibilidades para tal integración, seguido del diseño y la
implementación de la solución software final. El proyecto ha incluido programación en
java y adquirir conocimientos sobre OpenStack.
Palabras clave: NFV (Virtualización de Funciones en Red), SDN (Redes Definidas por
Software), capa de orquestación, SFC (Cadena de Funciones de Servicios), SF (Función
Servicio), NS (Servicio en Red).
1. Introducción.
Actualmente, proveedores de servicios en red y operadores de telecomunicaciones
ofrecen servicios finales compuestos por SFs (Funciones Servicio). Algunos ejemplos de
estas funciones son cortafuegos o balanceadores de carga. La combinación de múltiples
SFs compone lo conocido como NS (Servicios en Red). Paralelamente, la idea de SFC
emergió de la posibilidad de hacer fluir tipos específicos de tráfico a través de un
determinado NS.
Sin embargo, los NS de hoy en día presentan varios problemas relacionados con
las características de las redes de comunicaciones actuales. Ejemplos son la rígida
topología de red, el despliegue estático, los flujos bidireccionales o la necesidad de
integrar SFs de diferentes vendedores. Actualmente, los servicios ofrecidos son altamente
elásticos, y requieren una muy rápida creación, modificación y destrucción de las SFs.
Por ello, las nuevas tecnologías NFV y SDN (Redes Definidas por Software) son cruciales
para que los proveedores de servicios puedan desplegar servicios innovadores y superar
las restricciones propias de las redes tradicionales. NFV consiste en el despliegue de
VNFs (Funciones de Red Virtuales) en lugar de la típica infraestructura física. SDN se
caracteriza por desacoplar las capas de datos y de control, para conseguir gestión software
centralizada. Al integrar ambas tecnologías se hace más fácil la gestión, el control, y la
programación de cualquier red.
Actualmente, algunas organizaciones han intentado integrar el paradigma SFC
dentro de controladores SDN. La mayoría son plataformas de código abierto como
OpenDaylight u ONOS. Sin embargo, ninguno de ellos incluye un componente de
coordinación entre la capa de orquestación y los controladores a cargo del despliegue de
la SFC. La mayoría de los controladores necesitan ser instruidos manualmente sobre la
infraestructura que tienen que desplegar, pero no hay bloques funcionales que operen en
una capa superior y que incluyan el proceso de orquestación de la SFC. El instituto
Fraunhofer FOKUS trabaja actualmente en un proyecto colaborativo con el objetivo de
integrar la orquestación SFC en una plataforma NFV desarrollada por ellos, llamada
OpenBaton.
El objetivo del proyecto llevado a cabo en el Fraunhofer FOKUS consiste en
añadir un componente de orquestación, llamado ‘SFC Orchestrator’, encima de la capa
de control SDN, permitiendo el despliegue de NSs desde un nivel superior. Mi
contribución al proyecto consistirá en desarrollar un bloque funcional dentro del ‘SFC
Orchestrator’, llamado ‘SFC Manager’.
La funcionalidad principal de este bloque será recoger información sobre un NS
previamente desplegado por el orquestador NFV, e instruir un controlador SDN externo
sobre las SFs, los caminos que deben seguir los paquetes dentro de la SFC, las reglas de
clasificación, y el comportamiento general de la SFC. El correcto funcionamiento será
testado mediante la integración con el controlador SDN OpenDaylight. El gestor de
recursos que será utilizado para gestionar la infraestructura virtual será OpenStack.
2. Tecnologías: SFC y especificación estándar NFV-MANO.
El paradigma SFC está basado en el concepto de ‘superposición en red’, que
consiste en crear NSs sobre nodos de red que a su vez forman parte de la infraestructura
de otro NS. Esto implica construir una red punto a punto encima de otra red ya existente.
Este hecho permite a los operadores crear diferentes NS utilizando las mismas SFs, y
ubicarlas en la red según se necesite.
La figura 1 representa la arquitectura del paradigma SFC. Como se puede
observar, está compuesta por varias SFs; el switch/router, llamado SFF (Service Function
Forwarder); y un clasificador de tráfico. Esta arquitectura representa la capa de datos,
encima de la cual operaría el controlador SDN, en la capa de control, y encima a su vez,
el orquestador NFV, en la capa de orquestación.
Figura 1
La capa de orquestación para arquitecturas NFV está definida en la especificación
estándar NFV-MANO. Este estándar será la base para el bloque funcional desarrollado
en este proyecto. En la figura 2 se muestra el marco de arquitectura propuesto por la NFVMANO. Está compuesto por tres bloques principales: EL NFVO (Orquestador NFV), el
VNFM (Mánager VNF), y el VIM (Gestor de Recursos Virtuales)
Figura 2
3. Contextualización del proyecto: ‘SFC Orchestrator’.
Como la plataforma OpenBaton está diseñada acorde con los requisitos del
estándar NFV-MANO, parte de la arquitectura del proyecto del Fraunhofer FOKUS será
similar a la presentada en la especificación NFV-MANO: (el NFVO, el VNFM y el VIM).
Esos tres bloques junto con el nuevo componente, el ‘SFC Orchestrator’, representan la
capa de orquestación.
En la figura 3 se muestra la arquitectura del proyecto global, cuyo objetivo es la
completa orquestación del despliegue y la gestión de la SFC en la plataforma OpenBaton.
Figura 3
El ‘SFC Orchestrator’ estará compuesto por tantos bloques como sean necesarios
para satisfacer todas las tareas de orquestación y gestión. Uno de esos bloques, el ‘SFC
Manager’, será diseñado, desarrollado e implementado en este proyecto.
4. Definición del componente funcional ‘SFC Manager’.
La funcionalidad desarrollada en el curso de este proyecto incluye principalmente
el interfaz REST entre el ‘SFC Orchestrator’ y el controlador SDN subyacente. El módulo
software programado deberá subscribirse a eventos específicos generados por OpenBaton
cuando la infrastructura del NS esté desplegada en red. Esto significa que otros
componentes dentro del ‘SFC Orchestrator’ serán responsable de dicho despliegue de
infraestructura virtual. Cuando el NFVO genera el evento de instanciación finalizada,
también lanzará una petición REST con un archivo llamado NSR (Network Service
Record). Este archivo contiene datos acerca del NS que se acaba de crear: VNFs e
infraestructura virtual. Posteriormente, el servicio web que crearemos y que estará
suscrito a los eventos, recibirá también el archivo NSR, extraerá la información necesaria
y ejecutará la lógica de negocio necesaria para realizar las llamadas REST al controlador
SDN, y enviarle las instrucciones para implementar la SFC.
La arquitectura de la solución software final implementada se muestra en la
siguiente figura 4:
Figura 4
5. Implementación del componente ‘SFC Manager’.
El módulo ‘SFC Manager’ desarrollado es una aplicación web REST, para la cual
se ha hecho uso de la herramienta Spring. Como y ase ha mencionado, el principal
propósito de este componente es escuchar los eventos lanzados por el NFVO y capturar
el archivo NSR publicado.
Después de recibir y procesar el archive NSR, la lógica de negocio funcional
consiste en construir diccionarios con la información extraída del NSR, y requerida para
construir los archivos con formato json necesarios para enviar las peticiones REST al
controlador SDN. Algunos datos pueden ser extraídos directamente de los nodos
virtualizados que forman parte de la infraestructura desplegada por OpenStack. Por ello,
conexiones con los nodos OpenStack son también necesarias.
La funcionalidad del ‘SFC Manager’ también incluye las peticiones REST a
OpenDaylight. Estas conexiones vía http al controlador SDN consisten en especificar
exactamente los elementos necesarios para ejecutar la SFC. Estos elementos se
especifican a continuación, y deben ser enviados a OpenDaylight en este mismo orden:
creación de las SFs, creación del SFF, creación de la SFC, creación del SF Path (SFP),
creación del Rendered Service Path (RSP), y creación de las ACLs (Listas de Acceso).
Para llevar a cabo la creación de los elementos mencionados, la primera tarea
consiste en construir las plantillas con formato json. Estas plantillas deben encajar con
los requisitos del controlador, de manera que pueda entender correctamente el
funcionamiento de la SFC.
El código fuente de la aplicación se programará en lenguaje java.
6. Resultados del proyecto.
Para validar los resultados finales conseguidos después de programar la aplicación
‘SFC Manager’, primero se debe configurar un entorno de ejecución. Esta tarea consiste
en lanzar una instancia de NFVO, un servidor OpenDaylight y un nodo OpenStack. Una
vez que todo se está ejecutando correctamente, la aplicación puede ser también lanzada.
Como el componente ‘SFC Manager’ comienza su funcionamiento después de
que el NS ha sido desplegado virtualmente, lo primero que se debe hacer es lanzar
manualmente y desde la dashboard de OpenBaton, los elementos necesarios para
configurar un NS. Para conseguir tal propósito, se han preparado algunas plantillas json
para configurar dos SFs, y una SFC.
Una vez que el NS ha sido creado y su infraestructura virtual ha sido desplegada
por OpenStack, el NFVO creará el archivo NSR y generará el evento de instanciación
finalizada. Después de esto, se ha podido comprobar que la aplicación ‘SFC Manager’
es capaz de recibir tanto el evento como el NSR. Posteriormente, el componente procesa
la información contenida, construye los diccionarios necesarios, configura las plantillas
json para cada uno de los elementos de la SFC y ejecuta las REST requests en dirección
al controlador OpenDaylight.
En la figura 5 se muestra la ejecución de la aplicación ‘SFC Manager’
Figura 5
Al final, tal y como se muestra en la figura 6, el servidor OpenDaylight muestra
todos los elementos que se han creado satisfactoriamente. De la misma manera, en la
dashboard de OpenStack también se ven las SFs creadas.
Figura 6
7. Conclusiones finales.
Después de cerrar el presente proyecto, se puede decir que se han adquirido
conocimientos de alto nivel acerca del paradigma SFC, especialmente sobre su
arquitectura, capas de datos y control, componentes e interfaces. Al principio, se hizo un
estudio profundo sobre las plataformas actuales de controladores SDN, y sobre conceptos
y estándares NFV. Especial hincapié se hizo en los proyectos OpenDaylight y en
OpenBaton. Además, se han ampliado los conocimientos previos sobre virtualización,
OpenStack, programación java, y cómo usar repositorios Github.
EL producto software conseguido después de la consecución del proyecto es una
solución software, programada en java, que sirve para orquestar el despliegue de un
servicio en red encadenado, desde una plataforma NFV, hacia un controlador SDN. El
componente creado es un Servicio Web RestFul que corre cerca de OpenBaton, cuya
único parámetro de entrada es el archivo NSR y cuyo output son todos los elementos SFC
(SFs, SFF, SFC, SFP, RSP y reglas ACL) implementados y ejecutándose correctamente
en el controlador OpenDaylight.
8. Bibliografía y Referencias.
[1] IETF. (Datatracker). Service Function Chaining.
Disponible: https://datatracker.ietf.org/wg/sfc/documents/
Último acceso: Enero 2016
[2] Github. OpenBaton Repository.
Disponible: https://github.com/openbaton
Último acceso: Junio 2016
[3] FOKUS Fraunhofer. (). OpenBaton.
Disponible: https://www.fokus.fraunhofer.de/en/fokus/news/openbaton_2015_10
Último acceso: Junio 2016
[4] OpenBaton. (). OpenBaton Github doc.
Disponible: http://openbaton.github.io/documentation
Último acceso: Junio 2016.
[5] Ahmed Mohamed. New ODL SFC Data Model.
Disponible: https://gist.github.com/mah88/40ff2ca33a115a974d2a7078c01b1ec3
Último acceso: Junio 2016
DESIGN AND IMPLEMENTATION OF A FUNCTIONAL BLOCK
FOR ‘SERVICE FUNCTION CHAINING’ DEPLOYMENT FROM A
NFV ORCHESTRATOR TO A SDN CONTROLLER.
Author: María Gil Cárdenas.
Supervisor: Giuseppe Carella.
Collaborating Entity: FOKUS | Fraunhofer-Institut für Offene Kommunikationssysteme.
ABSTRACT
This project consists in designing and implementing a functional block that helps
to the integration of Service Function Chaining (SFC) paradigm within a NFV
Orchestrator platform, compliant with the NFV-MANO specification. First tasks include
research about the possibilities of such integration, then design and implement a final
software solution. It has involved java programming and learning knowledge about
OpenStack.
Keywords: Network Function Virtualization, Software Designed Networking,
Orchestration layer, Service Function Chaining, Service Function, Network Service.
1. Introduction.
Nowadays, network providers and telecommunication operators are used to
deliver end-to-end services composed of Service Functions (SFs). Examples of these are
firewalls or load balancers. A combination of multiple SFs is what is called Network
Services (NSs). At the same time, the idea of Service Function Chaining (SFC) emerged
from the possibility of matching specific types of traffic to flow through a determined
NS.
However, current instances of NS often present different problems related to rigid
network infrastructure topology, static deployment, bidirectional flows or the integration
of multivendor SFs. Nowadays the elastic service environments require rapid creation,
modification and destruction of SFs. That is why the combination of the newcomer
technologies Network Function Virtualization (NFV) and Software Defined Networking
(SDN), is crucial for service providers to deploy innovative services and overcome the
typical constraints of the traditional networks. NFV consists on deploying Virtual
Network Functions (VNFs) instead of the traditional physical infrastructure. SDN is
characterised by decoupling control and data planes, to reach centralised and software
management. Integrating both technologies makes it easier to manage, control and
program any network.
Currently, some organizations have aimed to integrate the SFC paradigm within
their SDN controller platforms. Most of them are open source platforms, such as
OpenDaylight, or ONOS. However, there is a gap between the orchestration side and the
controllers in charge of deploying the SFC. Most controllers need to be instructed
manually about the infrastructure they must deploy, but there are no components
operating in an upper layer that include the whole orchestration process for the SFC. The
Fraunhofer FOKUS institute is working in a project aiming to integrate SFC orchestration
within their NFV orchestration platform, called OpenBaton.
The goal of the Fraunhofer FOKUS institute project consists in adding an NFV
orchestration component, called ‘SFC Orchestrator’ above the SDN control plane,
enabling from a higher level the deployment of NSs. My contribution will be to develop
one functional block within the ‘SFC Orchestrator’, called ‘SFC Manager’.
Its main functionality will be to gather information about the NS previously
deployed by the NFV Orchestrator, and to instruct an external SDN controller about the
SFs, the paths to follow, the classifier rules and SFC overall behaviour. Its correct
operating will be tested by integrating it with the SDN controller part of the OpenDaylight
open source project. The resource manager that will manage the virtual infrastructure will
be OpenStack
2. Technologies: SFC and NFV-MANO standard specification.
SFC paradigm is based on the concept of ‘network overlay’, which consists in
creating a specific NSs among service end-nodes, whose paths are built on top of an
existing network. This fact allows operators to create different orders between SFs
(different NSs) and to allocate them in the network as needed.
The following figure 1 presents the architecture of the SFC paradigm. As seen, it
is composed of several SFs; the switch/router, which is called Service Function
Forwarder (SFF); and a traffic classifier. This architecture would fit the data plane, and
on top of it would operate the SDN controller, in the control plane, and the NFV
orchestrator, in the orchestration plane.
Figure 1
The orchestration plane for NFV architectures is defined in the NFV-MANO
standard specification, which will be followed in the implementation of this project. Next
figure 2 shows the architectural framework proposed by the specification. It is composed
of three main blocks, the NFV Orchestrator (NFVO), the VNF Manager (VNFM) and the
Virtualized Resource Manager (VIM).
Figure 2
3. Project Context: ‘SFC Orchestrator’.
Since the OpenBaton platform is designed according to the NFVO-MANO
requirements, so part of the architecture of the FOKUS project will be similar to the one
presented in the NFV-MANO specification (the NFVO, the VNFM, and the VIM). Those
three blocks, together with the new component (the ‘SFC Orchestrator’) in charge of SFC
orchestration, resemble the orchestration layer.
Next figure 3 shows the architecture of the overall project of the Fraunhofer
FOKUS Institute, which aims to completely orchestrate the SFC deployment and
management in the OpenBaton platform.
Figure 3
The ‘SFC Orchestrator’ will be composed of as many blocks as needed in order
to fulfil all tasks required to orchestrate the SFC. One of those blocks is the ‘SFC
Manager’, which will be designed and implemented within this project.
4. Definition of the functional component ‘SFC Manager’.
The functionality developed within the course of this project includes basically
the REST interface between the ‘SFC Orchestrator’ and the SDN Controller. The
software module programmed is called ‘SFC Manager’, and will subscribe to specific
OpenBaton events that will be triggered when the NS is already deployed. This
means that other components within the ‘SFC Orchestrator’ will be in charge of the
deployment of the virtual infrastructure. By the time that the NFVO generates the
instantiation finish event, it will also ‘post’ via REST request a file called NS Record
(NSR). This file contains all information about the NS just created: VNFs and virtual
infrastructure part of it. After our RESTFul Web Service receives both the event and the
NSR file, the application would extract the necessary data from the NSR and will do all
the business logic to perform the REST calls to the SDN Controller, who will be
instructed about how the SFC should work.
The architecture of the final software solution implemented is shown in figure 4:
Figure 4
5. Implementation of the component ‘SFC Manager’.
The module ‘SFC Manager’ developed is a Spring REST web application
composed of a REST Controller, whose main aim is to be listening to events triggered by
the NFVO and catch the NSR posted by it.
After receiving and processing the NSR file, the business logic of the component
constructs dictionaries with the information extracted from the NSR, and required to
construct the json files that will be sent via REST requests to the SDN controller. Some
information must be extracted directly from the virtualised computing nodes part of the
OpenStack deployed infrastructure. So connections to the OpenStack node shall also be
needed.
The functionality includes instructing the OpenDaylight controller about all the
elements needed to perform the SFC. Those elements are specified following, and must
be sent in that order to the controller. They are: creation of the SFs, creation of the SFF,
creation of the SFC, creation of the SF Path (SFP), creation of the Rendered Service Path
(RSP), and creation of the Access Lists (ACL) rules.
To perform the creation of the previously mentioned elements, first task is to
construct a json template. Those json templates must fit the requirements of the controller,
in order to properly understand however the SFC works.
The application source code is programmed in java language.
6. Project Results.
To test the final results achieved out of the application programmed, an execution
environment must firstly be set up. This task consist in launching an operative NFVO, a
VNFM, an OpenDaylight server and an OpenStack node. After everything is properly
running, the ‘SFC Manager’ application can also be launched.
Since the ‘SFC Manager’ component starts its functioning after a NS has been
virtually deployed, the testing scenario shall start with the manual deployment of a test
NS. For that purpose, some json files have been prepared and can be manually launched
from the NFVO OpenBaton dashboard.
Once the NS have been created and the NFVO has deployed the virtual
infrastructure in the OpenStack computing nodes, the NFVO will create the NSR and
generate the instantiation finished event.
Afterwards, it is proven how the ‘SFC Manager’ application receives the event
notification and the NSR in json template formatting. After correctly processing the
information, it builds the json templates for each SFC elements and it properly sends the
REST requests to the OpenDaylight controller.
Figure 5 shows the execution of the ‘SFC Manager’ application.
Figure 5
At the end, as shown in figure 6, the OpenDaylight server shows that all instances
have been successfully created, as well as in OpenStack.
Figure 6
7. Final conclusions.
After closing the present project a high level of knowledge in SFC paradigm has
been gathered, especially about its architecture, data and control planes, components and
interfaces. At the beginning a deep study into SDN controller platforms and NFV
concepts was performed. Especially research into the open source OpenDaylight project
and in the OpenBaton NFVO platform. Besides, it has been required to broad the previous
knowledge in virtualization, the resource manager OpenStack, java programming skills,
and how to make use out of the Github repositories.
At the end of the project, the product achieved is a software solution programmed
in java, which is used to deploy an SFC from a NFVO platform to a SDN controller;
through REST requests. The component created is a RESTFul Web Service that runs near
OpenBaton, its unique input is the NSR of the NS deployed by the NFVO; and the output
are all SFC elements (SFs, SFF, SFC, SFP, RSP and ACL rules) implemented and
properly running in the OpenDaylight controller.
8. Bibliography and References.
[1] IETF. (Datatracker). Service Function Chaining.
Available: https://datatracker.ietf.org/wg/sfc/documents/
Last accessed January 2016
[2] Github. OpenBaton Repository.
Available: https://github.com/openbaton
Last accessed June 2016.
[3] Fokus Fraunhofer. (). OpenBaton.
Available: https://www.fokus.fraunhofer.de/en/fokus/news/openbaton_2015_10
Last accessed June 2016
[4] OpenBaton. (). OpenBaton Github doc.
Available: http://openbaton.github.io/documentation
Last accessed June 2016.
[5] Ahmed Mohamed. New ODL SFC Data Model.
Available: https://gist.github.com/mah88/40ff2ca33a115a974d2a7078c01b1ec3
Last accessed June 2016