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.

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 NFV-

MANO. Está compuesto por tres bloques principales: EL NFVO (Orquestador NFV), el

VNFM (Mánager VNF), y el VIM (Gestor de Recursos Virtuales)

Figura 1

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.

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,

Figura 2

Figura 3

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:

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.

Figura 4

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’

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 5

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.

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 1

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.

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.

Figure 2

Figure 3

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:

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.

Figure 4

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.

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 5

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