Orquestração de Funções de Rede Virtualizadas em Data Center Centrados em Servidores

Rodolfo Vieira Valentim
Orquestração de Funções de Rede Virtualizadas

em Data Centers Centrados em Servidores
Brasil
2017
Rodolfo Vieira Valentim
Orquestração de Funções de Rede Virtualizadas em Data

Centers Centrados em Servidores
Projeto de Graduação apresentado ao De-

partamento de Informática do Centro Tecno-
lógico da Universidade Federal do Espírito
Santo, como requisito parcial para obtenção
do grau de Bacharel em Engenharia de Com-
putação.
Universidade Federal do Espírito Santo

Centro Tecnológico
Departamento de Informática
Orientador: Prof. Msc. Cristina Dominicini

Coorientador: Prof. Dr. Eduardo Zambom
Brasil
2017
Agradecimentos
Se cheguei até aqui foi porque

fui na mochila de gigantes.
Autor desconhecido
Agradeço ao meu pai, pois as pausas para assistir aos jogos do Fluminense mantive-
ram minha sanidade mental durante os finais de semestre. Agradeço à minha mãe por ser
a melhor pessoa do mundo, mas talvez não a mais calma. Agradeço à minha irmã por ser
mais empolgada com minha profissão do que eu e, dessa forma, me deixar mais animado
com o meu futuro.
Obrigado Léo, Renan, Igor, Raissa, Janaina, Janaissa, Guigui, Labore, Lelp e Dabi.
Vocês são pessoas que estarão sempre no meu coração e seria impossível ter chegado
até aqui sem vocês. Obrigado, também, a Roberta (e aos seus bots que mandam e-mail
de madrugada) que foi uma tutora no melhor sentido da palavra. Agradeço ao pessoal
do NERDS por me ouvir reclamar várias vezes sobre várias coisas, mas quase nunca do
OpenStack.
Um agradecimento especial aos meus orientadores. Zambon, desculpa por tantas
páginas! Eu juro que foi sem querer. Obrigado por me emprestar uma parte do tempo e
por dar um norte ao meu trabalho. Cristina, muito obrigado pela paciência, pelo apoio
técnico, pelas horas escovando pacote de rede, pelas horas procurando arquivos de 800
GBs e, acima de tudo, por ter me dado uma luz quando eu tive dúvidas sobre o futuro. Te
desejo tudo de bom e menos reuniões!
Aos meus amigos mais antigos: Bruno, Letícia, Talles e Ianna. Obrigado pelas
conversas, churrascos e, principalmente, pela amizade que eu tenho a honra de ter. Agradeço,
também, à Natasha por ter me aguentado nesse período insano da minha vida. Quero que
saiba que eu admiro a sua força de vontade e resistência. Espero que possa estar ao seu
lado por muito mais tempo.
Finalmente, agradeço a Deus que todos os dias me dá forças para fazer o meu
melhor.
Resumo
A virtualização de funções de rede é uma tecnologia que tem se desenvolvido rapidamente e
tem mudado o cenário de comunicação de dados. Há o surgimento de diversas ferramentas
para gerência e orquestração de funções de rede virtualizadas. Orquestração de funções
de redes é a forma como se coordena os diversos recursos necessários para habilitar o uso
do paradigma NFV. Dentre as ferramentas de orquestração destacam-se: Tacker, Brocade
VNF Manager e OpenMANO. Entretanto, há pouco esforço empregado quando relacionado
à estrutura de redes centradas em servidores. Este projeto apresenta um orquestrador
que é capaz de coletar autonomamente informações de uma infraestrutura centrada em
servidores e disponibiliza meios de obtenção destes dados, tendo como foco, utilização
destes dados por um otimizador.
O encadeamento do tráfego é feito por meio da instalação de regras em um switch OpenFlow

e a gerência de recursos do data center é baseada em OpenStack. A construção deste
orquestrador é feita utilizando a arquitetura VirtPhy que é construída em compatibilidade
com a arquitetura proposta pela ETSI NFV para um protótipo de um data center centrado
em servidores com topologia de hipercubo. Como resultado, obteve-se um interface bem
definida pela qual se pode ter acesso às informações de recursos do data center e realizar
serviços de posicionamento e encadeamento de funções de rede virtualizadas.
Palavras-chave: NFV, Orquestrador, VNF, SDN, Open vSwitch, Otimizador, OpenStack,

Redes centradas em servidores, computação na nuvem.
Lista de ilustrações
Figura 1 – Visão da substituição de equipamento específico por funções de rede

baseadas em software em equipamento genérico habilitado para virtua-
lização. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 2 – Representação em alto nível da arquitetura proposta pela ETSI. Elabo-
rada pelo autor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 3 – Detalhamento do bloco NFV MANO. Elaborada pelo autor. . . . . . . 30
Figura 4 – Transição de uma tecnologia de rede tradicional para uma utilizando
SDN. (CHAYAPATHI SYED F. HASSAN, 2016) . . . . . . . . . . . . 32
Figura 5 – Exemplo de uma tabela de fluxo em switch Openflow. . . . . . . . . . . 33
Figura 6 – Arquitetura de aplicações usando controlador de rede Ryu. Elaborado
pelo autor.(CHAYAPATHI SYED F. HASSAN, 2016) . . . . . . . . . . 34
Figura 7 – Componentes do Open vSwitch. O primeiro pacote de um fluxo sobe
ao userspace devido à ocorrência de um miss. Em seguida, a decisão é
guardada para possíveis pacotes do mesmo fluxo.(FOUNDATION, 2017a) 36
Figura 8 – a) Exemplo do mecanismo de encaminhamento do KeyFlow; b) Saída
do controlador de rota; c) Cálculo do ID da rota (MARTINELLO et
al., 2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 9 – Fluxograma de processamento de pacotes para a especificação OpenFlow
1.0 e execução do protótipo KeyFlow. (MARTINELLO et al., 2014) . . 37
Figura 10 – Exemplo do encadeamento de tabelas do iptables. (RASH, 2007) . . . . 38
Figura 11 – Frame Ethernet seguindo o protocolo LLDP. Fonte: https://www.noction.com/blog/bgp-
lldp-peer-discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 12 – Arquitetura lógica do Openstack. (FOUNDATION, 2017b) . . . . . . . 41
Figura 13 – Arquitetura usada pelo Openstack usando o Open vSwitch. Elaborada
pelo autor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 14 – Comparação entre a implementação de um SFC de um data-center
usando uma topologia tradicional de rede com um topologia centrada
em servidor. Percebe-se a economia de saltos de uma abordagem para a
outra. Fonte: (DOMINICINI et al., 2016) . . . . . . . . . . . . . . . . . 43
Figura 15 – Relação entre o VirtPhy e a ETSI NFV Framework. Em vermelho o
foco da arquitetura proposta por (DOMINICINI et al., 2016). . . . . . 46
Figura 16 – Interação entre os componentes da arquitetura VirtPhy para a realização
da orquestração de VNFs. (DOMINICINI et al., 2016) . . . . . . . . . 48
Figura 17 – Comparação entre as abordagens de SFC utilizando regras a) SFC em
topologias centradas em rede; b) Nuvem centrada na rede: VNFs e SDN
software e switches em hardware para SFC; c) Nuvem centrada em
servidor: VNFs e SDN switches virtuais para SFC (DOMINICINI et al.,
2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 18 – Exemplo de uma topologia de rede centrada em servidor. . . . . . . . . 50
Figura 19 – Diagrama do protótipo com foco nas redes. . . . . . . . . . . . . . . . . 51
Figura 20 – Blocos da arquitetura que são o foco da implementação do orquestrador.
Fonte (DOMINICINI et al., 2016) - Com alterações. . . . . . . . . . . . 52
Figura 21 – Fluxo de trabalho desde o recebimento de uma demanda de serviço até
a sua operação. Elaborado pelo autor. . . . . . . . . . . . . . . . . . . 53
Figura 22 – Proposta de arquitetura final para a aplicação. . . . . . . . . . . . . . . 54
Figura 23 – Exemplo de tipos de serviços que podem ser implementados com funções
de rede disponíveis no catálogo. . . . . . . . . . . . . . . . . . . . . . . 55
Figura 24 – Fluxo de dados no módulo otimizador. Verifica-se que são fornecidas
requisições e infraestrutura e como resultado é dado um posicionamento
e encadeamentos otimizados. . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 25 – Fluxo de dados no módulo otimizador. As informações passam por
blocos que fazem a tradução de um formato padrão para um formato
específico da solução de otimização abordada. . . . . . . . . . . . . . . 57
Figura 26 – Proposta de arquitetura para o serviço de posicionamento de VNFIs. . 60
Figura 27 – Exemplo de um posicionamento de funções de rede virtualizada no
protótipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 28 – Encadeamento desejado para um pacote egresso da máquina virtual
"origem"que destina-se a máquina virtual "destino". Elaborada pelo autor 62
Figura 29 – Caminho percorrido pelo pacote visto pelo ponto de vista dos elementos
que formam a topologia. Elaborada pelo autor . . . . . . . . . . . . . . 63
Figura 30 – Proposta de arquitetura para o serviço de que executa o encadeamento.
Elaborada pelo autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 31 – Diagrama UML das tabelas do banco de dados. Elaborada pelo autor . 73
Figura 32 – Cenário 1 de teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 33 – Tela da interface gráfica do OpenStack onde são mostradas as instâncias
alocadas na VIM para realização do Cenário 1. . . . . . . . . . . . . . 92
Figura 34 – Gráfico Throughput X Tempo para o Cenário 1 utilizando o script
descrito na Seção 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figura 47 – Caso 1 na qual as duas máquinas virtuais são funções de rede. a) no
mesmo hospedeiro b) hospedeiros diferentes. . . . . . . . . . . . . . . . 113
Figura 48 – Caso 2 na qual a origem do salto é a origem do tráfego. a) no mesmo
hospedeiro b) hospedeiros diferentes. . . . . . . . . . . . . . . . . . . . 115
Figura 49 – Caso 3 na qual o destino do salto é o destino do tráfego. a) no mesmo
hospedeiro b) hospedeiros diferentes. . . . . . . . . . . . . . . . . . . . 118
Lista de códigos
Código 1 – JSON descritor de hospedeiro . . . . . . . . . . . . . . . . . . . . . . . 66

Código 2 – JSON descritor de enlace . . . . . . . . . . . . . . . . . . . . . . . . . 66
Código 3 – JSON descritor de VNFD . . . . . . . . . . . . . . . . . . . . . . . . . 68
Código 4 – JSON descritor de requisições . . . . . . . . . . . . . . . . . . . . . . . 69
Código 5 – JSON descritor de VNFI . . . . . . . . . . . . . . . . . . . . . . . . . 70
Código 6 – JSON descritor de um encadeamento de VNFs . . . . . . . . . . . . . 71
Código 7 – Comando para obtenção da infraestrutura pelo cliente CLI . . . . . . . 73
Código 8 – YAML descritor de infraestrutura disponível . . . . . . . . . . . . . . . 73
Código 9 – Comando para criação de descritores de funções de rede pelo cliente CLI 74
Código 10 – YAML descritor para criação de VNFD . . . . . . . . . . . . . . . . . 74
Código 11 – Comando para requisição da implantação de serviços na infraestrutura 74
Código 12 – YAML descritor de uma requisição de serviço . . . . . . . . . . . . . . 74
Código 13 – Comando para criação de VNFIs na infraestrutura . . . . . . . . . . . 75
Código 14 – YAML descritor de uma VNFI . . . . . . . . . . . . . . . . . . . . . . 75
Código 15 – Comando para requisição da implantação do encadeamento na infraes-
trutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Código 16 – YAML descritor de uma SFC . . . . . . . . . . . . . . . . . . . . . . . 75
Código 17 – Comando para limpar alterações na infraestrutura . . . . . . . . . . . 76
Código 18 – Comando para cadastro do controlador no switch virtual . . . . . . . . 77
Código 19 – JSON do retorno após consulta a aplicação de topologia . . . . . . . . 78
Código 20 – Código para implementação do controlador de topologia, são ocultos os
imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Código 21 – JSON do retorno após consulta ao controlador de topologia pelo rota
/hcube/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Código 22 – Comando para execução do controlador de SFC . . . . . . . . . . . . . 80
Código 23 – Código para implementação da classe . . . . . . . . . . . . . . . . . . 80
Código 24 – JSON do retorno após consulta ao Gerenciador de Topologia . . . . . 81
Código 25 – Formato do dado enviado ao hospedeiro para desabilitar proteção do
iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Código 26 – JSON do retorno após consulta Agente Remoto . . . . . . . . . . . . . 83
Código 27 – Código para implementação do construtor de topologia . . . . . . . . . 85
Código 28 – Código de implementação do posicionamento de VNF . . . . . . . . . 86
Código 29 – Conteúdo da requisição enviada para o otimizador pelo orquestrador
para implementar o serviço do Cenário 1 . . . . . . . . . . . . . . . . . . . . . 91
Código 30 – Conteúdo do resultado enviado pelo otimizador ao orquestrador para
posicionamento das VNFIs do Cenário 1 . . . . . . . . . . . . . . . . . . . . . 91
encadeamento do tráfego das VNFIs do Cenário 1 . . . . . . . . . . . . . . . . 91
para implementar o serviço do cenário 2 . . . . . . . . . . . . . . . . . . . . . 93
posicionamento das VNFIs do cenário 2 . . . . . . . . . . . . . . . . . . . . . 93
encadeamento do tráfego das VNFIs do cenário 2 . . . . . . . . . . . . . . . . 94
para implementar o serviço do Cenário 3 . . . . . . . . . . . . . . . . . . . . . 96
para implementar o Cenário 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
encadeamento do tráfego das VNFIs do cenário 4 . . . . . . . . . . . . . . . . 100
para implementar o serviço do cenário 5 . . . . . . . . . . . . . . . . . . . . . 101
Código 44 – Formato da regra adicionada para o Caso 1A . . . . . . . . . . . . . . 113
Código 45 – Formato da regra adicionada para o Caso 1B . . . . . . . . . . . . . . 114
Lista de tabelas
Tabela 1 – Responsabilidades de cada bloco funcional do bloco NFV MANO adap-

tado de (CHAYAPATHI SYED F. HASSAN, 2016) . . . . . . . . . . . 31
Tabela 2 – Regras instaladas no switch da Figura 17-a. Fonte: (DOMINICINI et
al., 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Tabela 3 – Campos de dados de um hospedeiro com tipos e descrições . . . . . . 66
Tabela 4 – Campos de dados de enlace de rede com tipos e descrições. . . . . . . . 67
Tabela 5 – Campos de dados de um descritor de função de rede (VNFD) com tipos
e descrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Tabela 6 – Campos de dados de uma requisição de serviço com tipos e descrições 69
Tabela 7 – Campos de dados de uma instância de função de rede com tipos e
descrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Tabela 8 – Campos de dados de um encadeamento de tráfego tipos e descrições . 72
Tabela 9 – Campos utilizados na regras para classificação do fluxo. . . . . . . . . . 121
Tabela 10 – Campos utilizados na regras para ações nos pacotes. . . . . . . . . . . 122
Tabela 11 – Informações do posicionamento das VNFIs Cenário 1 . . . . . . . . . . 122
Tabela 12 – Regras instaladas para implementação do SFC no Cenário 1 . . . . . . 123
Lista de abreviaturas e siglas
IoT Internet das coisas, do inglês Internet of Things
CAPEX Gastos de capital, do inglês Capital Expenditure
OPEX Gastos operacionais, do inglês Operational Expenditure
NFV Virtualização de Funções de Rede, do inglês Network Functions Virtua-

lization
NAT Tradução de Endereço de Rede, do inglês Network Address Translation
SDN Rede Definidas por Software, do inglês Software Defined Networks
TSP Provedor de Serviços de Rede, do inglês Telecommunication Service

Provider
VIM Gerenciador de Infraestrutura Virtualizada prevista no ETSI Framework,

do inglês Virtualized Infrastructure Manager
SFC Encadeamento de Funções de Serviço, do inglês Service Function Chai-

ning
NFV MANO Gerenciamento e Orquestração de Funções de Rede Virtualizadas, do

inglês NFV Management and Orquestration
VNFI Instância de Função de Rede Virtual, do inglês Virtual Network Function

Instance
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 Motivação e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Estrutura do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 27
2.1 Funções de rede virtualizadas . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1 Arquitetura de rede tradicional . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Virtualização de funções de rede . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.3 Arquitetura NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.4 Detalhes do bloco funcional NFV MANO . . . . . . . . . . . . . . . . . . 30
2.2 Redes definidas por software . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2 Controlador de Rede Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.3 Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 KeyFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Link Layer Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.1 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.2 OpenStack Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7 Redes centradas em servidores . . . . . . . . . . . . . . . . . . . . . . 42
3 VIRTPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 Arquitetura do VirtPhy . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 SFC usando SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 PROJETO DA ARQUITETURA . . . . . . . . . . . . . . . . . . . . 53
4.1 Etapa de Requisições . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Etapa de Otimização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1 Gerência de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1.1 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1.2 Catálogo de funções de rede . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Etapa de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 Posicionamento de Funções de Rede Virtualizadas . . . . . . . . . . . . . . 58
4.3.2 Encadeamento de Funções de Rede Virtualizadas . . . . . . . . . . . . . . 60
5 IMPLEMENTAÇÃO DA ARQUITETURA . . . . . . . . . . . . . . . 65
5.1 Otimizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Padrões de Comunicação entre Componentes . . . . . . . . . . . . . 65
5.2.1 Hospedeiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.2 Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.3 Descritor de Funções de Rede . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.4 Requisições de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.5 Instâncias de Funções de Rede . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.6 Encadeamento de Funções de Rede . . . . . . . . . . . . . . . . . . . . . 70
5.3 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.1 Infraestrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.2 Criação de Funções de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4.3 Cadastro de Requisições . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4.4 Execução do posicionamento . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4.5 Execução do encadeamento de funções de rede . . . . . . . . . . . . . . . 75
5.4.6 Reverter alterações na infraestrutura . . . . . . . . . . . . . . . . . . . . . 76
5.5 Infraestrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6 Controlador SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.1 Gerenciador de SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.2 Gerenciador de Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7 Agente Remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.8 Gerenciador de Infraestrutura Virtualizada . . . . . . . . . . . . . . . 83
5.9 Orquestrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.9.1 Recebimento de Requisições de Serviço . . . . . . . . . . . . . . . . . . . 84
5.9.2 Descoberta de Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.9.3 Posicionamento de VNFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.9.4 Encadeamento de VNFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6 CARACTERIZAÇÃO DE FUNCIONAMENTO . . . . . . . . . . . . 89
6.1 Script de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Cenário 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.4 Cenário 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.5 Cenário 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.6 Cenário 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . 105
7.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
APÊNDICES 111
APÊNDICE A – REGRAS PARA ENCADEAMENTO EM DIFE-

RENTES CASOS DE POSICIONAMENTO . . . . 113
A.1 Caso 1 - Origem e destino do salto são funções de rede . . . . . . . 113
A.2 Caso 2 - Origem do salto é a origem do tráfego . . . . . . . . . . . . 115
A.3 Caso 3 - Destino do salto é o destino do tráfego . . . . . . . . . . . 117
APÊNDICE B – REGRAS INSTALADAS PARA A REALIZAÇÃO

DO SFC NOS CENÁRIOS DE TESTES . . . . . . 121
B.1 Campos das regras instaladas . . . . . . . . . . . . . . . . . . . . . . . 121
B.2 Cenário 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
B.3 Cenário 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
B.4 Cenário 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
B.5 Cenário 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
B.6 Cenário 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
23
1 Introdução
As estruturas das redes tradicionais são baseadas em hardware proprietário e de uso

específico. Estas características apresentam-se como gargalo para os provedores de serviços
de rede devido ao aumento exponencial dos requisitos de serviços, impulsionados por vídeo,
voz e aplicações de IoT, implicando em elevados custos de aquisição de equipamentos e
operacionais (MIJUMBI et al., 2016).
A virtualização de funções de rede (NFV) estende a virtualização de recursos,
tecnologia que já encontra-se em estágio avançado de maturidade, para funções de rede. O
conceito de virtualização de funções de rede surge na própria indústria como uma tentativa
de reduzir custos e promover soluções para se ter um ambiente de serviços escalável. A
virtualização de recursos já é uma técnica bem difundida em data centers e NFV expande
o escopo de virtualização para funções de rede como: firewall, NAT, e gateway, para citar
algumas. Entre os principais benefícios da utilização de NFV está a redução do gastos de
capital (CAPEX) e operacionais (OPEX) (CHECKO et al., 2015).
Uma vez que NFV é um conceito relativamente recente, existem diversos desafios
ainda em aberto sendo estudados. Um dos mais importantes refere-se ao gerenciamento e
orquestração das funções de rede virtualizadas (VNFs) denominado NFV MANO. Este
trabalho apresenta uma solução de orquestração de funções de rede virtualizadas em um
data center centrado em servidores (VASSOLER, 2015). Redes centradas em servidores
são redes que, diferente de redes tradicionais, não necessitam de equipamentos de rede
para fazer o encaminhamento e roteamento de pacotes.
1.1 Motivação e Justificativa

No contexto do Núcleo de Estudos em Redes Definidas por Software (NERDS. . . , )
há diversas linhas de pesquisa com temas centrados em NFV como o VirtPhy. O VirtPhy
propõe uma arquitetura que integra NFV e Redes Definidas por Software (SDN) (KREUTZ
et al., 2015) para orquestração em data centers de borda que virtualiza tanto as funções
quanto os equipamentos de rede (DOMINICINI et al., 2016). O paradigma SDN, que
propõe a separação entre a lógica entre o plano de controle e o plano de dados, permite a
programabilidade de redes na arquitetura VirtPhy.
O VirtPhy já conta com um protótipo implementado, entretanto alguns dos serviços
de NFV MANO ainda não são automatizados. A arquitetura VirtPhy prevê a tarefa de
automatizar o processo de gerenciamento dos serviços de NFV e SDN da arquitetura.
Este projeto pretende desenvolver um módulo orquestrador, previsto na arquitetura
24 Capítulo 1. Introdução
do VirtPhy, segundo o padrão NFV da European Telecommunications Standards Institute

(ETSI) (ETSI, 2013), para um data center centrado em servidores. Este módulo é res-
ponsável por tomar decisões de como orquestrar os recursos de computação e redes no
data center (ex., onde provisionar as VNFs e como rotear o tráfego entre elas) com base
nas requisições dos usuários e nas demandas já existentes no data center. Dessa forma, o
orquestrador deve possuir um módulo otimizador e interfaces com os outros módulos da
arquitetura ETSI, como o gerenciador de infraestrutura física (VIM), o gerenciador de
VNFs e o controlador SDN.
1.2 Objetivos
O objetivo principal deste projeto é automatizar a orquestração de funções de
rede na arquitetura VirtPhy. O requisito principal é que esse processo de orquestração
seja autônomo e a sua tomada de decisões se baseie na comunicação com um módulo
de otimização com interfaces de entrada e saída bem definidas, de modo que diferentes
métodos de otimização possam ser aplicados de acordo com os requisitos de cada serviço
ou infraestrutura.
As duas principais tarefas da orquestração de funções de redes virtualizadas são o
posicionamento e o encaminhamento de VNFs. O posicionamento é a criação de instâncias
de funções de redes virtualizadas em um hospedeiro específico. O encadeamento é o
redirecionamento do fluxo passando por funções de redes virtualizadas em uma ordem
específica. Chama-se de Service Function Chaining (SFC).
De forma geral, será necessário: coletar as informações sobre a infraestrutura de
computação e redes, se comunicar com um processo de otimização que produz as decisões
de orquestração, e implementar os mecanismos que aplicam as decisões de orquestração
na infraestrutura. Assim, os objetivos específicos são:
1. Criar uma interface de comunicação que gerencia as requisições de serviço;
2. Automatizar a coleta de informações sobre infraestrutura de rede e computação em

um data center centrado em servidor.
3. Criar uma interface de comunicação com o módulo de otimização que envia as

informações sobre a infraestrutura e requisições e recebe as decisões de orquestração;
4. Automatizar a criação de instâncias de VNFs com base no resultado do processo de

otimização;
5. Automatizar o encadeamento de VNFs com base no resultado do processo de otimi-

zação.
1.3. Estrutura do Texto 25
1.3 Estrutura do Texto

No Capítulo 2 são explicados os principais conceitos utilizados ao longo do trabalho.
No Capítulo 3 é explicada a arquitetura VirtPhy na qual se pretende implementar
o módulo orquestrador.
No Capítulo 4, discute-se a arquitetura proposta para a aplicação de modo a
promover soluções para o problema de orquestrar funções de redes virtualizadas em uma
infraestrutura de data center centrada em servidor.
O Capítulo 5 discorre sobre o desenvolvimento do protótipo, explicando quais
considerações foram feitas e como o protótipo foi implementado integrando soluções de
posicionamento e encadeamento de VNFs em uma infraestrutura centrada em servidores
na plataforma Openstack (SHIMA; DANG, 2016).
No Capítulo 6 são apresentados os resultados dos testes que visam comprovar a
validade da solução para os problemas propostos.
No Capítulo 7 são feitas considerações finais sobre o projeto e sugestões para
trabalhos que serão desenvolvidos em sequência.
27
2 Fundamentação Teórica
Os conceitos apresentados a seguir são necessários para a melhor compreensão do

objeto de estudo.
2.1 Funções de rede virtualizadas

O conceito e a utilidade da virtualização das funções de rede é melhor compreendida
quando se observa o contexto em que é inserida e seus desafios.
2.1.1 Arquitetura de rede tradicional

Uma estrutura de rede tradicional é altamente dependente do uso de equipamentos
proprietários e especializados. Esta peculiaridade faz com que os provedores de serviços de
rede (Telecommunication Service Providers - TSP), para disponibilizar um novo serviço,
precisem adquirir novos equipamentos (CAPEX) e contratar mão-de-obra especializada,
que é cada vez mais escassa, para instalação e operação (OPEX)(MIJUMBI et al., 2016).
Outro fator a se levar em consideração é o fato de que as soluções de rede baseadas
em hardware encerram cada vez mais rápido seu ciclo de vida, necessitando que o processo
de compra e instalação seja realizado sem que haja relevantes ganhos em desempenho.
Outro agravante é que o ciclo de vida desses equipamentos tem diminuído, ao passo que
os requisitos exigidos pelos usuários, por novos serviços com taxas de dados mais elevadas
têm aumentado, em um mundo cada vez mais centrado em rede (VIRTUALISATION,
2012).
2.1.2 Virtualização de funções de rede

Com um crescimento exponencial de demanda por largura de banda, aplicações de
vídeo, mobile e IoT, os provedores de serviços estão constantemente procurando por novas
formas de escalar seus serviços, preferencialmente sem acarretar em maiores custos.
NFV é uma iniciativa que parte dos principais provedores de serviços de rede no
mundo para tentar resolver esse problema. Em outubro de 2012, estas empresas lançaram
uma chamada para pesquisa e em novembro do mesmo ano elegeram o Instituto Europeu de
Normas de Telecomunicações (European Telecommunications Standards Institute - ETSI)
como a sede do grupo de especificação para indústria em NFV (ETSI ISG NFV). A ideia
principal é separar o equipamento de rede físico das funções que executam (MIJUMBI et
28 Capítulo 2. Fundamentação Teórica
al., 2016) estendendo o conceito de virtualização de recursos, tecnologia que já encontra-se

em estágio avançado de maturidade, para funções de rede.
A mera separação permite que funções de rede baseadas em software possam ser
executadas em uma vasta gama de servidores desenvolvidos para venda no mercado comum
(Commercial Off The Shelf - COTS), permitindo que as funções possam ser movidas,
instanciadas ou escaladas dinamicamente em qualquer local que seja necessário, sem
aquisição de novos equipamentos, como pode ser observado na Figura 1.
Figura 1 – Visão da substituição de equipamento específico por funções de rede baseadas

em software em equipamento genérico habilitado para virtualização.
2.1.3 Arquitetura NFV

As funções de redes virtualizadas podem ser oferecidas por diversas organizações
que sintam a necessidade de implementar algum serviço de rede e distribuí-lo. Decorrente
da liberdade que as fornecedoras de serviços possuem, é preciso um esforço de padro-
nizar a forma como se comunicam e a gerência de recursos. Este esforço se traduz no
desenvolvimento de uma arquitetura NFV.
A Figura 2 é uma representação em alto nível da arquitetura proposta pela ETSI
ISG NFV, que visa (ETSI, 2013):
• Separação total entre hardware e software;
• Implantação automatizada e escalável das funções de rede;

2.1. Funções de rede virtualizadas 29
• Controle dos parâmetros operacionais das funções da rede através do controle granular
e monitoramento do estado da rede.
Figura 2 – Representação em alto nível da arquitetura proposta pela ETSI. Elaborada

pelo autor.
Os três componentes principais tem funções bem definidas em (ETSI, 2013):
• Funções de Rede Virtualizadas - VNFs, define como a implementação de

software de uma função de rede é capaz de executar sobre o NFVI.
• Infraestrutura NFV - NFVI, inclui a diversidade de recursos físicos e como estes

podem ser virtualizados. O NFVI suporta a execução das VNFs.
• Gerenciamento e orquestração NFV - NFV MANO, cobre o gerenciamento

de orquestração e ciclo de vida de recursos físicos e/ou de software que suportam
a virtualização da infraestrutura e o gerenciamento do ciclo de vida das VNFs.
O gerenciamento e a orquestração NFV se concentram em todas as tarefas de
gerenciamento específicas de virtualização necessárias na estrutura do NFV.
Neste ponto, é conveniente expor que o trabalho desenvolvido pela ETSI ISG NFV
não tem caráter regulador, mas tenta definir critérios mínimos para compatibilidade entre
implementações em NFV. O surgimento de novas tecnologias como computação na nuvem
e redes definidas por software, tem ajudado na evolução do paradigma NFV.
2.1.4 Detalhes do bloco funcional NFV MANO

Sendo o bloco da arquitetura que possui atribuições de gerência, é importante que
o bloco NFV MANO seja exposto com maior nível de detalhe. A Figura 3 detalha o bloco
MANO da Figura 2. As funções dos elementos adicionais são listados na Tabela 1.
Figura 3 – Detalhamento do bloco NFV MANO. Elaborada pelo autor.
Como pode ser visto na Figura 3 é previsto um banco de dados que armazena
informações relevantes para a orquestração. São estas (NFV, 2014):
• NVFI Recursos: Contém informações sobre os recursos NFVI disponíveis/reserva-

dos/alocados como abstraídos pelo gerenciador de infraestrutura virtualizada em
todo o domínio de infraestrutura do operador;
• Instâncias NFV: Contém informações de todas as instâncias de função de redes

virtualizadas e instâncias do serviço de rede;
• Catálogo de Serviços NFV: Representa o repositório de todos os Serviços de

Rede suportados, apoiando a criação e gerenciamento dos modelos de implementação
– Descritor de Serviço de Rede (NSD), Descritor de Link Virtual (VLD) e Descritor
de Grafo de Encaminhamento de VNF (VNFFGD);
2.2. Redes definidas por software 31
Tabela 1 – Responsabilidades de cada bloco funcional do bloco NFV MANO adaptado de

(CHAYAPATHI SYED F. HASSAN, 2016)
Bloco Funcional Responsabilidades
NFVO
• Orquestração de recursos;
• Orquestração de serviços;
• Trabalhando com outros blocos para orquestrar a rede e mantendo

uma visão fim-a-fim da rede.
VNFM
• Gerencia o ciclo de vida de VNFs
VIM
• Mantém repositório de hardware (armazenamento, computação e
rede);
• Mantém registro da alocação de recursos virtualizados;
• Interagir e gerenciar o hypervisor;
• Mantém registro da utilização hardware e estados;
• Trabalho com outros blocos funcionais para implementar a conexão

entre VNFs através de redes virtuais.
Repositório de dados MANO

• Armazena informações usadas para orquestrar, ambiente de ins-
tância em tempo de execução, bem como recursos que estão sendo
utilizados ou disponíveis.
• Catálogo VNF: repositório com todas as VNFs suportadas.
2.2 Redes definidas por software

As redes IP tradicionais, apesar de largamente utilizadas, podem ser extremante
complexas de configurar, pois possuem controle distribuído necessitando de configuração
usando software proprietário e interface de baixo-nível. Os mecanismos de reconfiguração e
resposta automática são praticamente inexistentes nas redes IP atuais. Aplicar as políticas
necessárias em um ambiente tão dinâmico como o cenário atual é altamente desafiador.
Redes Definidas por Software (SDN - Software-Defined Networking) surgem na
tentativa de acabar com as limitações das redes atuais. Para alcançar esse objetivo, como
pode ser observado na Figura 4, há uma separação entre a lógica de controle da rede (o
plano de controle) dos roteadores subjacentes e switches que encaminham o tráfego (o
plano de dados) (KREUTZ et al., 2015).
A separação é possível através de uma interface programável bem definida entre os
Figura 4 – Transição de uma tecnologia de rede tradicional para uma utilizando SDN.
(CHAYAPATHI SYED F. HASSAN, 2016)
switches e o controlador SDN. Este controlador executa controle direto sobre os switches
no plano de dados usando uma API. O exemplo mais notável de tal API é o OpenFlow
(MCKEOWN et al., 2008).
2.2.1 OpenFlow
OpenFlow foi o primeiro protocolo de código aberto para comunicação entre
controladores SDN e equipamentos do plano de dados. OpenFlow fornece um protocolo
para alteração da tabela de fluxo, a qual define o encaminhamento da mensagem. Esta
tabela está presente em switches que estão habilitados para trabalhar com o protocolo.
De acordo com (MCKEOWN et al., 2008), um OpenFlow Switch consiste de pelo
menos três partes:
1. Uma tabela de fluxo (flow table) com uma ação associada à cada entrada na tabela.
Assim, é informado ao switch como processar cada fluxo;
2. Um canal seguro entre o switch e o controlador permitindo o tráfego de pacotes e

comandos;
3. E o protocolo OpenFlow em si que contém o ferramental habilitador para comunicação

entre o controlador e o switch.
2.2. Redes definidas por software 33
Quando um pacote chega ao switch este procura no encadeamento de tabelas de

fluxo se há alguma regra em que o pacote se encaixa e executa a ação correspondente.
Caso o pacote não se encaixe em nenhuma regra, este é encaminhado para uma fila e um
evento é enviado para o Controlador SDN. O controlador responde com uma regra para
este determinado pacote.
Um exemplo de uso da tabela pode ser verificado na Figura 5. Percebe-se que cada
entrada da tabela possui uma regra, uma ação em caso de concordância com a regra e um
contador que registra a quantidade de pacotes recebidos que estão de acordo com tal regra.
Figura 5 – Exemplo de uma tabela de fluxo em switch Openflow.
Fonte: Redes Definidas por Software (SDN) UFRJ - Universidade Federal do Rio de Janeiro. Disponível
em: <gta.ufrj.br/ensino/eel879/trabalhos_vf_2015_2/SDN>
2.2.2 Controlador de Rede Ryu

Ryu é um controlador de rede baseado em componentes e possui uma série de com-
ponentes pré-definidos. Os componentes podem ser modificados, estendidos e customizados
de forma a criar aplicações de SDN (KHONDOKER et al., 2014).
Aplicações de SDN são criadas e se comunicam através da API Rest disponibilizadas
com a framework. A framework repassa as solicitações para os switches OpenFlow usando
o protocolo OpenFlow. Este esquema é mostrado na Figura 6.
Os principais componentes do controlador são:
• app_manager: principal componente. É responsável por iniciar a aplicação, prover

contexto às aplicações e rotear mensagens entre as aplicações;
Figura 6 – Arquitetura de aplicações usando controlador de rede Ryu. Elaborado pelo

autor.(CHAYAPATHI SYED F. HASSAN, 2016)
• controller: o principal componente do controlador OpenFlow. Responsável por

gerenciar conexões da aplicação com switches e por gerenciar e encaminhar os
eventos gerados pelas aplicações do Ryu.
• dpset: gerencia os switches virtuais atribuídos ao controlador. Em versões mais

novas foi substituído pelo componente topology.
• ofp_event: contém definição de eventos.
• ofp_handler: lida com a negociação de OpenFlow.
A framework contém também diversos componentes que fazem a codificação e

decodificação de mensagens OpenFlow nas suas diversas versões.
2.2.3 Open vSwitch

Open vSwitch é um switch virtual multicamada de código aberto, muito utilizado
para habilitação de rede para ambientes virtualizados onde as máquinas virtuais se
conectam através de portas em bridges permitindo que se comuniquem umas com as outras,
bem como, com a rede física.
O software é escrito, basicamente, na linguagem de programação C. Tem suporte
a múltiplas plataformas de virtualização como: Xen/XenServer(XENSERVER, 2017),
KVM(KVM, 2016), e VirtualBox(ORACLE, 2011).
2.3. KeyFlow 35
Os principais componentes são:
• ovs-vswitchd, um daemon que implementa a comutação baseada em fluxo do switch,

juntamente com um módulo de kernel Linux.
• servidor ovsdb, um servidor de banco de dados leve que o ovs-vswitchd consulta

para obter informações de configuração.
• ovs-dpct, uma ferramenta para configurar o módulo do kernel do switch.
• ovs-vsctl, um utilitário para consultar e atualizar a configuração de ovs-vswitchd.
• ovs-appctl, um utilitário que envia comandos para executar os daemons Open

vSwitch. (FOUNDATION, 2017a)
Na Figura 7 são identificados os componentes que fazem a comutação de pacotes do

switch virtual. Ao receber um novo fluxo e ocorrer de não haver nenhuma ação específica,
o pacote sobe ao nível de usuário (userspace) onde é consultada a regra mais específica
possível. Após essa etapa, a regra está em cache no nível de kernel.
Como Open vSwitch, geralmente, é utilizado em ambientes de SDN, pode-se inserir
um controlador que se comunica pelo protocolo Openflow (Seção 2.2.1). O controlador
pode adicionar, deletar, monitorar e obter estatísticas a cerca do fluxo nas instâncias de
Open vSwitch.
2.3 KeyFlow
OpenFlow é uma alternativa para flexibilizar o controle sobre o encaminhamento de
pacotes de rede. Entretanto, a forma como o encaminhamento é realizado, consultando um
controlador remoto, pode acarretar problemas de performance quando a implementação
precisa ser escalada. KeyFlow (MARTINELLO et al., 2014) é apresentado como uma
alternativa para a implementação de elementos que realizam encaminhamento de pacotes.
A ideia principal do KeyFlow é, em linhas gerais, usar RNS (Residual Number
System) (GARNER, 1959) que consiste em representar um número bem grande em
uma combinação de pequenos números obtidos pela operação de resto de divisão inteira
deste grande número por um conjunto de co-primos. Este número grande representa um
identificador de uma rota e os pequenos números são os identificadores das portas do
switch. Os co-primos são os identificadores dos próprios switches.
O KeyFlow permite a identificação explícita do caminho nas bordas e, simultanea-
mente, técnicas de encaminhamento sem dependência com o estado no núcleo da rede. Um
exemplo de execução é dado na Figura 8. Percebe-se que cada nó da rede é identificado por
Figura 7 – Componentes do Open vSwitch. O primeiro pacote de um fluxo sobe ao userspace

devido à ocorrência de um miss. Em seguida, a decisão é guardada para possíveis
pacotes do mesmo fluxo.(FOUNDATION, 2017a)
um co-primo. Antes de ingressar no data center o pacote recebe um número, previamente

chamado de número grande. Quando passa por um switch, é executada uma operação de
divisão inteiro e o resto da divisão corresponde ao ID da porta (número pequeno) ao qual
o pacote será encaminhado.
Figura 8 – a) Exemplo do mecanismo de encaminhamento do KeyFlow; b) Saída do

controlador de rota; c) Cálculo do ID da rota (MARTINELLO et al., 2014)
2.4. Iptables 37
O identificador do pacote é calculado com base no caminho desejado e não precisa

haver comunicação com os switches em nenhum momento. Já o protocolo OpenFlow faria
uma consulta ao controlador quando houvesse ingresso de um fluxo desconhecido. Não
precisar se comunicar com o controlador apresenta-se com uma vantagem do KeyFlow em
relação ao OpenFlow. A diferença entre os dois protocolos é ilustrada na Figura 9
Figura 9 – Fluxograma de processamento de pacotes para a especificação OpenFlow 1.0 e

execução do protótipo KeyFlow. (MARTINELLO et al., 2014)
2.4 Iptables
Iptables é um utilitário para configuração do firewall do kernel do Linux. Foi
desenvolvido no contexto do projeto Netfilter (WELTE, 2000). Foi projetado para trabalhar
tanto com protocolo IPv4 e IPv6.
A ferramenta trabalha com os conceitos básicos de inspecionar, modificar, encami-
nhar, redirecionar ou descartar um pacote. A implementação do iptables é feita no nível
do kernel e funciona como uma série de tabelas, cada uma com uma função específica. As
tabelas são, basicamente, uma lista de regras (chain) que são seguidas ordenadamente e
são estas regras definem o destino do pacote. As tabelas disponíveis no iptables são:
• Filter: usada para definir se deixa o pacote continuar até o destino pretendido ou se
o pacote é descartado;
• NAT: As regras nessa tabela definem como modificar tanto origem quanto o destino
do pacote de modo a modificar a forma como o pacote é roteado;
• Mangle: utilizado para modificar os cabeçalhos IP dos pacotes de várias formas;
• Raw: seu protódito é de excluir qualquer rastro de sessão que possa haver no pacote,
para que possa ser analisado livre de estado;
• Security: utilizado para fazer marcações SELinux no pacote.
A medida que um pacote vai percorrendo a pilha vai desencadeando alguns eventos.
Os eventos estão associados a tabelas e, desta forma, quando acontece um evento, uma
tabela é consultada e uma ação é tomada. Os eventos diponíveis são:
• PREROUTING: este evento acontece assim que o pacote entra na pilha, antes de
qualquer decisão de roteamento ser feita;
• INPUT: acontece assim que o pacote é roteado e se o destino dele for o sistema local;
• FORWARD: acontece se o pacote é encaminhado para outro hospedeiro;
• OUTPUT: acontece assim que qualquer fluxo de rede de saída é criado localmente;
• POSTROUTING: acontece assim que qualquer fluxo de saída é roteado e está a

ponto ser colocado no meio de transmissão.
Na Figura 10 encontra-se uma representação gráfica dos eventos que são desenca-
deados a medida que o pacote vai caminhando pela pilha:
Figura 10 – Exemplo do encadeamento de tabelas do iptables. (RASH, 2007)
2.5 Link Layer Discovery Protocol

Link Layer Discovery Protocol (LLDP)(LINK. . . , 2015) é um protocolo aberto a
qualquer fornecedor que é usado para equipamentos em rede divulgarem sua identidade e
capacidades a seus vizinhos em uma LAN. É especificado pela LACP (Link Agregation
2.6. Computação em nuvem 39
Control Protocol) em IEEE 802.1. Um equipamento usando este protocolo publica suas
informações periodicamente usando todas as suas interfaces de rede.
Um quadros no protocolo LLDP tem o formato mostrado na Figura 11 e é do
tipo Ethernet. Este quadro é enviado para todas as interfaces de rede do equipamento em
intervalos fixos de tempo. O pacote Ethernet tem o campo EthernetType que é preenchido
com 0x88cc, sendo este um valor específico para o protocolo.
Figura 11 – Frame Ethernet seguindo o protocolo LLDP. Fonte:

https://www.noction.com/blog/bgp-lldp-peer-discovery
LLDP Data Units (LLDPDUs) é o nome dado a quadros ethernet do protocolo

LLDP. Os quadros são enviados para o endereço MAC de destino 01:80:c2:00:00:0e e
é definido como "LLDP Multicast". Este endereço é definido dentro de um intervalo
reservado pelo IEEE para protocolos que devem ser restritos a uma LAN individual. Um
LLDPDU não será encaminhado por pontes MAC (por exemplo, switches) que estejam
em conformidade com IEEE Std 802.1D-2004.
Quando utilizado em conjunto com um switch OpenFlow (ver Seção 2.2.1) e um
controlador SDN (ver Seção 2.2.2), é possível obter a topologia da rede. Os LLDPDU,
assim que chegam a um switch OpenFlow, é encaminhado ao controlador. De posse desse
quadro, infere-se que o switch que encaminhou o pacote está conectado ao elemento de
rede de origem do pacote.
2.6 Computação em nuvem

De acordo com (ZHANG; CHENG; BOUTABA, 2010), computação na nuvem é um
novo modelo no qual os recursos (por exemplo, CPU e armazenamento) são de propósito
geral e podem ser alocados ou liberados sob demanda através da Internet.
Se a virtualização de recursos oferece ganho em eficiência ao compartilhar recursos
de máquina entre múltiplas aplicações, a virtualização baseada em nuvem expande o
conceito ao disponibilizar recursos de hardware (locais ou remotos) como um única
unidade. No excelente, porém breve, documento (MELL; GRANCE et al., 2011) são
listadas as características desejadas em uma infraestrutura de nuvem.
• Serviços sob demanda: um usuário deve ser capaz de alocar e liberar recursos ou
serviços sem que haja a intervenção direta de humanos;
• Amplo acesso pela rede: é importante que um ambiente de rede seja acessível
pela rede. Não necessariamente rede pública, como uma intranet por exemplo, mas é
importante que usuários tenham acesso ao ambiente;
• Repositório de recursos: Os recursos são alocados para diferentes usuários com

diversos recursos físicos e virtuais sendo alocados e desalocados dinamicamente;
• Rápida elasticidade: deve ser permitida a uma aplicação de nuvem aumentar a

quantidade de recursos alocados, algumas vezes automaticamente, baseadas em uma
demanda;
• Medição de serviços: uma nuvem deve sempre monitorar os serviços de modo a

registrar a utilização dos recursos.
2.6.1 OpenStack
O OpenStack é um sistema operacional em nuvem que controla grandes conjuntos de
recursos de computação, armazenamento e rede em todo um data center, todos gerenciados
através de um painel de controle que dá aos administradores o controle ao capacitar seus
usuários a fornecer recursos através de uma interface web (FOUNDATION, 2017b).
O software OpenStack roda sobre ambientes Linux (Ubuntu, OpenSUSE e CentOS)
e adota uma abordagem modular onde cada módulo possui funções bem definidas. Cada
módulo precisa ser instalado separadamente e se comunica com outros usando a especifica-
ção WSGI. WSGI (Web Server Gateway Interface) é uma especificação para comunicação
entre servidores web e aplicações.
Cada componente pode ser do tipo:
• Deamon: serviços que rodam em background;
• Script: executam tarefas com criação de ambientes virtuais;
• Command Line Interface - CLI : interface do usuário com os serviços. Através

deste são executadas ações no ambiente de nuvem.
A Figura 12 mostra como os serviços interagem entre si. É possível observar a

complexidade envolvida. Há uma preocupação com segurança evidente e por isso todos
2.6. Computação em nuvem 41
os serviços se autenticam através de um serviço de identidade (Identity) e os serviços

individuais interagem uns com os outros através de APIs públicas, exceto quando são
necessários comandos de administrador privilegiados.
Figura 12 – Arquitetura lógica do Openstack. (FOUNDATION, 2017b)
2.6.2 OpenStack Networking

OpenStack pode habilitar o acesso à rede física por meio de Open vSwitch e
Linux Bridges. A Figura 13 mostra como é o esquema de switches virtuais em um nó de
computação.
Máquinas virtuais possuem interfaces de redes virtuais (vNIC) que agem da mesma
forma que interfaces físicas. Como são simulações de interfaces físicas, as interfaces virtuais
são capazes de receber apenas quadros ethernet. Uma tap é um software que diz a Linux
Bridge que encaminhe a elas quadros ethernet da forma como foram recebidos. Uma tap é
a forma que hypervisors, como KVM e Xen, implementam uma vNIC. Um quadro Ethernet
destinada a vNIC é recebido pelo sistema operacional do hospedeiro.
O veth pair qvb-qvo é um par diretamente conectado onde tudo que um recebe o
outro também recebe. Um veth pair é a virtualização de um cabo de rede.
Figura 13 – Arquitetura usada pelo Openstack usando o Open vSwitch. Elaborada pelo
autor.
A Linux Bridge age com um switch de camada 2. É possível conectar várias

interfaces a Linux Brigde e a bridge usará uma tabela de MACs para comutar os pacotes,
assim como um switch físico.
O Open vSwitch também se comporta como um switch. Entretanto, há uma
diferença crucial com a Linux Bridge e que justifica seu uso. É possível redirecionar o
tráfego baseado em regras que podem tanto ser instaladas localmente quanto remotamente
com a utilização de um controlador de rede. Em um nó de computação, tem-se dois Open
vSwitches instalados e cada um tem uma função específica na tarefa de encaminhamento.
Brevemente explicados a seguir:
• br-int: bridge de integração, onde todas as máquinas virtuais alocadas em um nó

estão conectadas. Responsável por dar isolamento entre as vNICs das máquinas
virtuais e as interfaces físicas do hospedeiro.
• br-eth: responsável por dar acesso à rede física.
2.7 Redes centradas em servidores

Redes centradas em servidores como: DCell (GUO et al., 2008), BCube (GUO et al.,
2009a), Hypercube (OSTROUCHOV, 1987), são redes que, diferente de redes tradicionais,
2.7. Redes centradas em servidores 43
não necessitam de equipamentos de rede para fazer o encaminhamento e roteamento de

pacotes.
São topologias que necessitam que os servidores possuam mais de uma interface de
rede e que cada interface do nó esteja conectado a uma interface de outro nó. Podem ser
usados mini-switches para expandir o número de portas de um hospedeiro.
A escolha por topologias como esta pode gerar economia na aquisição de equipa-
mentos de rede, uma vez que o custo de interfaces adicionais é menor do que a aquisição
de novos equipamentos de rede. Esta economia pode chegar a até 15% do valor que seria
gasto em uma topologia tradicional, conforme mostrado em (GUO et al., 2009b).
O uso de redes centradas em servidores é especialmente atraente para uso em
conjunto com NFV (DOMINICINI et al., 2016), podendo diminuir o número de saltos
necessários para a implementação de um serviço, como pode ser visto na Figura 14, e levar
a uma economia de largura de banda nos enlaces que formam o data center.
Figura 14 – Comparação entre a implementação de um SFC de um data-center usando

uma topologia tradicional de rede com um topologia centrada em servidor.
Percebe-se a economia de saltos de uma abordagem para a outra. Fonte:
(DOMINICINI et al., 2016)
45
3 VirtPhy
VirtPhy é uma proposta de arquitetura totalmente programável para orquestração

de VNFs em data centers centrados em servidores que virtualizam tanto as funções quanto
os equipamentos de rede (DOMINICINI et al., 2016).
A arquitetura se apresenta como uma opção às atuais soluções de orquestração de
VNFs em estruturas de rede tradicionais propondo que redes centradas em servidores em
data centers de borda podem trazer benefícios à virtualização de funções de rede. Pode-se
destacar quatro principais características dessa abordagem:
1. Única unidade de processamento: os servidores reunem as funções de controle

tanto de rede quanto de processamento.
2. Orquestração de VNFs consciente da topologia: os serviços em NFV envolvem

o encadeamento do fluxo entre diferentes instâncias que podem ou não se encontrar
em diferentes nós. Em uma estrutura de rede tradicional, um salto no grafo de
encaminhamento pode requerer passagem por vários switches. Em uma estrutura
centrada em servidor, o orquestrador pode otimizar o posicionamento das VNFs
baseado na topologia e nos serviços requisitados.
3. Desacoplamento entre SFC e encaminhamento: o encaminhamento é explo-

rado usando a própria infraestrutura do data center centrado em servidor e utilizando
as tabelas de fluxo apenas para SFC. Isso leva à redução das tabelas de fluxo, que
diminuí o custo do encaminhamento, por meio de menores consultas.
4. SFC distribuído: outro fator que leva à redução das tabelas de fluxo é a distribuição
das regras de SFC em cada servidor, ao invés de sua centralização em apenas um
switch.
Neste capítulo serão discutidos os principais aspectos da arquitetura VirtPhy

(Seção 3.1), aspectos do protótipo implementado (Seção 3.2) e por fim o escopo deste
trabalho será contextualizado dentro da arquitetura utilizada (Seção 3.3).
3.1 Arquitetura do VirtPhy

A arquitetura VirtPhy foi desenvolvida para habilitar o uso de funções de redes
virtualizadas em data centers centrados em servidores, utilizando SDN para SFC.
Os autores, em (DOMINICINI et al., 2016), enfatizam que o foco da arquitetura
está nos blocos NFVI e NFV MANO, como pode ser vista na Figura 15 que mostra os
46 Capítulo 3. VirtPhy
blocos previstos em uma arquitetura NFV. As principais funções dos blocos previstos na
arquitetura são listadas a seguir:
Figura 15 – Relação entre o VirtPhy e a ETSI NFV Framework. Em vermelho o foco da

arquitetura proposta por (DOMINICINI et al., 2016).
• VIM
– Gerência da interação entre as VNFs com o hardware, bem como sua virtualiza-
ção através do hypervisor. Hypervisor é o software responsável pela criação e
execução das máquinas virtuais;
– Gerência de redes virtuais;
– Configuração dos endereços das VNFs no momento da criação, de acordo com
o hospedeiro em que é instanciada.
• NFV Orchestrator (NFVO)
– Centraliza a criação de instâncias NFV (NFVI) e a criação e gerência de serviços

de rede (Network Service - NS);
– Compartilha com os outros componentes informações acerca das NFVIs e NSs.
• VNF Manager
3.1. Arquitetura do VirtPhy 47
– Responsável pela gerência de ciclo de vida das VNFIs (Virtual Network Function
Instance).
• Controlador SDN
– Configura os switches nos nós físicos;
– Reconecta dinamicamente links físicos usando switches de circuito programáveis;
– Instala regras de fluxo relacionadas ao SFC.
• Banco de Dados
– Armazena dados sobre solicitações de serviço (VNF-FGs e usuários), VNFs

(endereço MAC Ethernet, endereço IP e hospedeiros), carga de trabalho de
hospedeiros físicos (CPU e memória), tráfego de rede e topologia.
A Figura 16 mostra a interação entre os componentes de arquitetura. Quando

uma requisição chega ao orquestrador, o orquestrador consulta o banco de dados que
possui informações sobre os recursos disponíveis e encaminha ao otimizador. O otimizador
informa as decisões de posicionamento e encadeamento. As requisições podem ser feitas
através de uma REST API.
O orquestrador encaminha as decisões de posicionamento ao VIM, que é o res-
ponsável por virtualizar os servidores e o acesso a rede. Após finalizado o processo de
posicionamento, o orquestrador envia as decisões de SFC para o controlador de SDN.
O controlador SDN é responsável por gerenciar os switches virtuais. O controlador,
ao ser acionado pelo orquestrador, adiciona regras de fluxos aos switches de forma a
estabelecer critérios para redirecionamento do tráfego caso o tráfego seja compatível com
alguma das regras instaladas. Desta forma, o redirecionamento do tráfego é invisível para
a origem e destino.
3.1.1 SFC usando SDN

Já foi exposto que a arquitetura utiliza-se de SDN para realização de SFC. Esta
seção explica um pouco do funcionamento e expande o conceito para topologias centradas
em servidores.
Em (DOMINICINI et al., 2016), é explicada a ideia por trás do SFC: o enca-
minhamento é baseado no campo MAC do pacote. A cada salto de SFC, o MAC do
pacote é substituído por um vMAC que representa aquele salto. Desta forma, pode-se
criar uma regra que verifica o campo MAC do pacote e faz o redirecionamento baseado
nesta informação.
Figura 16 – Interação entre os componentes da arquitetura VirtPhy para a realização da

orquestração de VNFs. (DOMINICINI et al., 2016)
Utilizando-se desta solução, não é necessário que nem origem, nem destino e nem
as funções de rede envolvidas estejam cientes do processo de encaminhamento.
Por exemplo, para Figura 17-a, pode-se instalar no switch as seguintes regras da
Tabela 2 de forma a habilitar o encaminhamento. A função de rede utilizada é uma SFF
que encaminha um pacote para a mesma interface da qual recebeu.
Tabela 2 – Regras instaladas no switch da Figura 17-a. Fonte: (DOMINICINI et al., 2016)
Regra Classificador Ação
1 IP_Origem=IP1 Modifica MAC_Dest para VMAC1;
Encaminha para porta 2.
2 MAC_Dest=VMAC1 Modifica MAC_Dest para to MAC2;
Encaminha para porta 3.
A Figura 17-b, mostra a abordagem utilizando uma nuvem e utilizando regras para
encadeamento. O número de tabelas e regras aumenta em relação à primeira abordagem,
mas também aumenta a capacidade de alocação de VNFs. Entretanto, ao se utilizar uma
nuvem centrada em servidor em conjunto com SFC por regras (Figura 17-c) , percebe-se
3.2. Protótipo 49
Figura 17 – Comparação entre as abordagens de SFC utilizando regras a) SFC em topolo-

gias centradas em rede; b) Nuvem centrada na rede: VNFs e SDN software
e switches em hardware para SFC; c) Nuvem centrada em servidor: VNFs e
SDN switches virtuais para SFC (DOMINICINI et al., 2016)
.
que o número de tabelas diminui, mas o poder de alocação de recursos permanece o mesmo.
A natureza das regras instaladas é a mesma da utilizadas na Tabela 2.
3.2 Protótipo
A TRIIIAD (TRIple-Layered Intelligent and Integrated Architecture for Datacen-
ters), foca no acoplamento entre a orquestração da nuvem e o controle da rede. A TRIIIAD
é composta por três camadas horizontais e um plano vertical de controle, gerência e
orquestração (VASSOLER, 2015).
A implementação da TRIIAD é um data center de pequena escala. Utiliza uma
topologia centrada em servidor onde cada nó da rede está conectado a outros três nós
formando um cubo (Topologia Hypercube), conforme mostra a Figura 18. Uma visão geral
sobre o protótipo será dada nessa seção.
A princípio, a TRIIIAD foi projetada para utilização como um data center para
fornecer infraestrutura como serviço. Entretanto, ficaram claras as vantagens de se utilizar
a proposta em conjunto com o paradigma NFV (ver Seção 2.7). Desta forma, o protótipo
foi adaptado e expandido para implementação da arquitetura VirtPhy, conforme proposta
descrita em (VASSOLER; RIBEIRO, 2017).
A implementação foi construída sobre uma versão modificada do OpenStack Icehouse.
Para o OpenStack, cada nó físico na rede tem uma ou mais funções que são determinadas
pelos serviços instalados no servidor. Um nó pode ser um nó de rede, um nó de computação,
um nó controlador ou um nó de armazenamento.
O mecanismo original de encaminhamento no hipercubo é baseado em um Source
Routing Protocol, no qual um servidor usa uma única operação XOR sobre seus vizinhos
Figura 18 – Exemplo de uma topologia de rede centrada em servidor.
para encontrar o próximo salto. Este esquema é simples, eficiente e livre de pesquisas em
tabelas de rota.
Cada vértice do cubo, mostrado na Figura 18, é um nó de computação que executam
um hypervisor (KVM, ESX, Hyper-V ou XenServer). O nó de computação lida com o
serviço de computação (nova) e um agente Open vSwitch (neutron)(KTENZER, 2015).
Conforme mostra a Figura 19, as arestas do cubo são enlaces. Cada nó tem cinco
interfaces de rede, sendo três delas conectadas a um outro nó, uma quarta interface conec-
tada ao controlador de rede e a quinta interface é conectada a uma Rede de Gerenciamento.
Em uma topologia tradicional centrada em rede, todos os nós de computação estariam
conectados na mesma hierarquia em uma rede de dados. Já no protótipo, a rede se dá
pela interconexão entre os nós formando uma topologia de cubo.
A rede de gerência é usada pelo próprio OpenStack para outras configurações
como acesso à Internet do hospedeiro, acesso SSH e comunicação entre os serviços. Já a
comunicação entre máquinas virtuais se dá pela rede de dados que foi alterada e passa a
ser necessária configuração adicional para que uma máquina virtual se comunique com
outras.
O protótipo utiliza o OpenStack utilizando Open vSwitch para habilitar o acesso à
rede. Portanto tem-se dois switches virtuais presentes em cada nó. Estes dois switches são
dois importantes pontos de tomada de decisão para a realização do SFC.
Conforme descrito em (DOMINICINI et al., 2016), as regras OpenFlow para
3.3. Escopo 51
Figura 19 – Diagrama do protótipo com foco nas redes.
habilitar o SFC são instaladas na br-int e o encaminhamento entre os hospedeiros é

feito usando um mecanismo de encaminhamento baseado na origem (source routing).
Neste trabalho, estamos utilizando a versão estendida do protótipo do VirtPhy em que o
mecanismo de encaminhamento XOR foi substituído pelo KeyFlow.
O protocolo de encaminhamento KeyFlow não depende da topologia como o
protocolo XOR, que só pode ser utilizado em topologias do tipo cubo. Além disso, a
utilização do XOR trás um elemento a mais de dificuldade para a etapa de otimização,
visto que há pouco controle sobre o caminho utilizado para ir de um hospedeiro a outro
na topologia de rede. Já o protocolo KeyFlow permite total controle sobre o caminho
percorrido no salto dado por meio da criação de um identificador de salto.
3.3 Escopo
A implementação do orquestrador proposto por este trabalho é feita sobre a arqui-
tetura VirtPhy em protótipo já existente e funcional. Este trabalho foca na automatização
das ações de alguns dos elementos da arquitetura, conforme pode ser visto na Figura 20.
Os principais pontos são:
• Interação com o módulo otimizador;
• Decisões de posicionamento;
• Decisões de encadeamento;
• Recebimento de requisições de serviços;
• Alimentação do banco de dados com informações topológicas e de recursos.
Figura 20 – Blocos da arquitetura que são o foco da implementação do orquestrador. Fonte

(DOMINICINI et al., 2016) - Com alterações.
53
4 Projeto da Arquitetura
Uma vez estabelecidos os benefícios de se adotar um paradigma de funções de rede

virtualizadas (NFV) em conjunto com uma topologia de rede centrada em servidores, é
preciso desenvolver soluções para habilitar uma infraestrutura de data center a utilizar o
paradigma NFV.
Os objetivos deste projeto são o de realizar a tarefa de posicionamento de funções de
rede em uma infra-estrutura e o direcionamento do tráfego de rede de uma máquina virtual
de origem a uma máquina virtual de destino passando ordenadamente por um sequência de
funções de rede (Service Function Chaining - SFC). Estas tarefas encontram-se dentro do
bloco funcional NFVO (NFV Orchestration) do modelo proposto pela ETSI (ver seção 2.1).
Como trata-se de uma solução de NFV focada em redes centradas em servidor,
utiliza-se a arquitetura VirtPhy, que propõe uma etapa de otimização da orquestração
NFV. Os serviços a serem implementados são especificados pelo usuário.
Propõe-se um fluxo de tarefas mostrado na Figura 21. Cada etapa contém uma
série de subtarefas que precisam ser executadas em uma topologia e juntas habilitam o
uso de NFV em uma infraestrutura de data center centrada em servidor. O restante do
capítulo faz uma análise dos processos e das soluções previstas. A etapa de contratação de
um serviço, presente na Figura 21, não é objeto de estudo.
Figura 21 – Fluxo de trabalho desde o recebimento de uma demanda de serviço até a sua
operação. Elaborado pelo autor.
A arquitetura desenvolvida para a aplicação é mostrada na Figura 22. Verifica-se

diversos elementos que interagem entre si.
54 Capítulo 4. Projeto da Arquitetura
O cliente é uma aplicação CLI que faz solicitações para o orquestrador. É útil para
facilitar o acesso às funcionalidades do orquestrador, pois abstrai alguns pontos relativos à
comunicação. A entrada e saída de dados do cliente é por meio do formato YAML que é
um formato mais compacto que o formato JSON utilizado para a comunicação entre os
componentes.
Toda a comunicação com o orquestrador pode se dar por requisições HTTP.
Entretanto, em um ambiente de testes o uso do cliente pode ser mais produtivo.
Figura 22 – Proposta de arquitetura final para a aplicação.
A etapa de recebimento de requisições é tratada na Seção 4.1. A Seção 4.2 trata

da aquisição e manutenção dos dados utilizados na etapa de otimização. Na Seção 4.3
são discutidos os métodos para a realização do posicionamento e da implementação do
encadeamento do fluxo de rede.
4.1 Etapa de Requisições

Tendo em vista uma topologia e um catálogo de funções de rede disponíveis. Um
utilizador de uma infraestrutura manifesta a intenção de implementar um certo serviço
que requer que o tráfego de rede passe por uma certa sequência de funções de rede. As
requisições são parte da informação necessária para a etapa de otimização.
Por exemplo, na Figura 23, é determinado que um certo tipo de tráfego (Tráfego 1)
deve passar sequencialmente por um firewall e em seguida um serviço de NAT e após isso
4.1. Etapa de Requisições 55
seguir seu caminho natural. Tráfego 2 deve passar pelo firewall antes de entrar em um
serviço de detecção de intrusão (intrusion detection system - IDS ). Já o tipo de Tráfego 3,
deve ser redirecionado para serviços de NAT e caching, nessa ordem.
Um serviço pode ser especificado pelas seguintes informações:
• protocolo (ex: ICMP, UDP, TCP);
• porta de origem;
• porta de destino;
• máquina de origem (ex: IP de origem ou MAC de origem);
• máquina de destino (ex: IP de destino ou MAC de destino);
• ou qualquer outro elemento que possa ser detectado pelo responsável pelo direciona-
mento do tráfego.
Figura 23 – Exemplo de tipos de serviços que podem ser implementados com funções de
rede disponíveis no catálogo.
Caso um utilizador deseje implementar um tipo de serviço, deve formalmente

manifestar a intenção através de uma requisição de serviço. Entre outras informações, essa
requisição deve conter: um classificador de tráfego e uma sequência de funções de rede
ao qual deseja redirecionar o tráfego (Virtualized Network Function Forwarding Graph -
VNFFG).
4.2 Etapa de Otimização
Uma parte central do funcionamento do orquestrador é o processo de otimização.

Desta etapa partem exigências de dados acerca da topologia e recursos disponíveis e o
resultado tem consequência direta sobre implementação de serviços.
O processo de otimização é importante para que se possa utilizar eficientemente a
infraestrutura. É uma etapa prevista na arquitetura VirtPhy e fica a cargo do Orquestrador
NFV gerenciar.
Para realizar o processo de otimização precisa-se, basicamente, dos recursos dispo-
níveis na infraestrutura, da topologia e das requisições a serem instaladas. Como resultado
da otimização, espera-se que sejam fornecidos o posicionamento das funções de rede nos
hospedeiros e o encaminhamento que deve ser feito para realização do SFC. O fluxo de
dados é mostrado na Figura 24.
Figura 24 – Fluxo de dados no módulo otimizador. Verifica-se que são fornecidas requisições
e infraestrutura e como resultado é dado um posicionamento e encadeamentos
otimizados.
Deseja-se que o otimizador seja uma caixa-preta que possa ser substituída de acordo
com a necessidade. Entretanto, cada otimizador utiliza uma padrão diferente de entrada e
saída de dados decorrente de um contexto de escassez de padrões universalmente aceitos.
Essa falta de padrões de comunicação implica na incapacidade de se trocar o módulo
sem que isso represente mudanças significativas na implementação. Uma abordagem seria
estabelecer um padrão de entrada e saída de informações e prever a existência de um módulo
tradutor que englobaria o otimizador, conforme Figura 25. Desta forma, o administrador
da nuvem pode implementar qualquer solução de otimização bastando ter em vista que
precisa traduzir as entradas e saídas.
Uma vez estabelecida essa abordagem, é preciso um esforço para estabelecer padrões
de entrada e saída que possam ser traduzidos para um formato que o otimizador utilizado
é capaz de utilizar.
4.2. Etapa de Otimização 57
Figura 25 – Fluxo de dados no módulo otimizador. As informações passam por blocos

que fazem a tradução de um formato padrão para um formato específico da
solução de otimização abordada.
4.2.1 Gerência de Recursos

Para que ocorra o processo de otimização são necessárias informações acerca dos
recursos disponíveis para utilização. A gerência dos recursos da infraestrutura do data
center é concentrada na VIM (Virtual Infrastructure Manager).
São denominados recursos: hospedeiros, enlaces e as funções de redes disponíveis
para utilização (catálogo de funções de rede).
4.2.1.1 Topologia
Denomina-se topologia o conhecimento dos hospedeiros de um data center e como

eles se conectam entre si. É importante lembrar que se trata de uma abordagem centrada
em servidor. O conceito de topologia pode ser aplicado para qualquer arquitetura de rede,
principalmente quando centrada em servidor.
De um hospedeiro, são necessárias as seguinte informações:
• número de CPU’s virtuais, espaço de armazenamento e memória virtual disponíveis;
• o nome e IP do hospedeiro.
E as seguintes informações são necessárias para a execução de funções de roteamento:
• identificadores dos switches virtuais do hospedeiro;
• identificador KeyFlow do hospedeiro;
• mapa de portas que informa qual NIC está conectada a qual hospedeiro vizinho;
• conhecimento sobre a capacidade das conexões entre os hospedeiros.

Através do protocolo LLDP (ver Seção 2.5) é possível fazer uma inferência da
topologia. Entretanto, os dados obtidos pelo protocolo são guardados em uma tabela
armazenada localmente no servidor. Para se obter esta informações, basta redirecionar
pacotes do tipo LLDP para o controlador SDN. Esta regra é adicionada no switch virtual
do qual deseja-se obter informações topológicas. Desta forma, toda a informação sobre a
topologia do data center é centralizada no controlador SDN.
4.2.1.2 Catálogo de funções de rede
Outra informação requerida da infraestrutura é o catálogo de funções de rede

disponíveis. Para isso é preciso definir quais informações são necessárias para se caracterizar
completamente uma função de rede. Desta forma, uma função de rede é definida por:
• imagem da máquina virtual;
• tamanho de disco virtual necessário;
• quantidade de memória virtual necessária;
• quantidade de CPUs virtuais necessárias;
• tipo de função de rede;
• nome da função de rede para critérios de utilização;
• largura de banda requerida para correto funcionamento;
• e capacidade de processamento.
4.3 Etapa de Implementação

4.3.1 Posicionamento de Funções de Rede Virtualizadas
Tanto a Seção 4.2.1 quanto a Seção 4.1 tratam de processos que ocorrem previamente
à manipulação de infraestrutura. São processos de coleta de informação e recebimento de
solicitações.
Na Seção 4.2 são tomadas decisões referentes ao posicionamento e ao roteamento
de forma que ambos sejam otimizados com relação à alocação de recursos. Esta seção,
trata do processo de posicionamento de funções de rede.
O posicionamento de funções de rede virtualizadas é o processo de criação de
uma máquina virtual usando uma imagem de um sistema operacional, disponibilizando
quantidades específicas de armazenamento, memória e CPUs virtuais. A máquina virtual é
alocada em algum nó de computação seguindo um critério de escolha específico ou genérico.
4.3. Etapa de Implementação 59
No caso da arquitetura VirtPhy usada, o posicionamento é otimizado seguindo os critérios

intrínsecos do módulo otimizador.
Sendo assim, o problema de posicionamento envolve as seguintes etapas:
• determinar o tamanho do disco virtual necessário;
• determinar a quantidade de memória virtual necessária;
• determinar a quantidade de CPUs virtuais necessárias;
• escolher uma imagem de máquina virtual;
• escolher um hospedeiro;
• escolher uma rede e endereço IP, caso seja necessário.
Após a criação, é necessária a coleta de alguns dados adicionais para complementa-

ção do conhecimento da topologia:
• obtenção da porta ao qual se conecta ao switch virtual;
• obtenção do endereço IP atribuído a máquina virtual.
A Figura 26 mostra os elementos responsáveis pela criação de uma VNFI e como

interagem. Observa-se a interação do Orquestrador com o Módulo Otimizador e também
a presença de um bloco tradutor. O tradutor traduz tanto do padrão a ser estabelecido
neste trabalho para o formato de entrada estabelecido pelo desenvolvedor quanto para o
caminho inverso.
Neste ponto, toda a interação com o hardware é mediada pela VIM. Após a criação
de uma VNFI, as informações obtidas são armazenadas no banco de dados e são elas:
• Tupla de três elementos que corresponde a um identificador da máquina virtual. Esse

identificador informa o hospedeiro da VM, o tipo de função de rede e um índice que
representa quantas VNFs do mesmo tipo estão no mesmo hospedeiro;
• IP da máquina virtual atribuída no momento da criação;
• Identificador da porta ao qual a VM se conecta no switch virtual estabelecida no

momento da instanciação e anexada a VM.
A critério de ilustração, na Figura 27 verifica-se um possível posicionamento das

requisições da Figura 23. O posicionamento foi escolhido pelo otimizador.
Figura 26 – Proposta de arquitetura para o serviço de posicionamento de VNFIs.
4.3.2 Encadeamento de Funções de Rede Virtualizadas
Nesta seção são identificados pontos-chave para a realização do SFC e as soluções

a serem usadas. Serão abordados conceitos de SDN e controladores SDN, mecanismos de
firewall e de switches virtuais.
O encadeamento de funções de rede é uma etapa mais complexa que o posicio-
namento e envolve a utilização de diversos mecanismos distintos de modo a atingir o
resultado esperado. O processo de encaminhamento precisa ser abstraído pelas partes
envolvidas, de modo que nem uma função de rede, nem a origem nem o destino do tráfego,
tenham conhecimento da mudança pela qual o fluxo de rede é submetido.
Dado o posicionamento da Figura 27, suponha que a origem e o destino do tráfego
também sejam máquinas virtuais instanciadas nos nós H1 e H2, respectivamente. O cenário
é ilustrado na Figura 28.
Ao sair da máquina de origem, os pacotes são endereçados para a máquina destino,
mas no meio do caminho precisam ser capturados e endereçados a uma função de rede
conforme especificada na requisição. Percebe-se que há diversos caminhos que podem
ser escolhidos para ir de um nó a outro. A tomada de decisão quanto ao encadeamento
escolhido é tomada no momento da otimização.
Um exemplo de caminho escolhido é mostrada na Figura 28. Na imagem são
identificados 3 saltos. Chama-se salto o caminho entre duas máquinas virtuais.
Figura 27 – Exemplo de um posicionamento de funções de rede virtualizada no protótipo.
Da otimização, precisa-se que se tenha dados completos sobre cada salto na topologia.
Para a Figura 28 o resultado esperado da otimização seria:
• 1º Salto - H1:SOURCE -> H1:FW
• 2º Salto - H1:FW -> H4:NAT
• 3º Salto - H4:NAT -> H3 -> H2:DESTINATION
Os switches virtuais tem papel fundamental na execução desta tarefa. A Figura 29

mostra todo o caminho que o pacote percorre. É possível que mesmo o pacote não sendo
destinado a um hospedeiro, ou a uma máquina virtual alocada em um hospedeiro, mesmo
assim o pacote é processado pelo switch virtual br-eth que encaminha o pacote para a
interface correta, de acordo com o protocolo de encaminhamento (KeyFlow).
Outro ponto a se observar é que um salto é iniciado sempre que o pacote vai acima
de uma switch br-int. Ou seja, sempre que um pacote sobe ao nível de máquinas virtuais.
Um pacote egresso de uma máquina virtual tem a chave do próximo salto escrita no pacote
quando este pacote chega ao gerenciador de SFC.
O cadastro das regras que fazem a classificação do fluxo e por consequência
a alteração do pacote é feita no momento da implementação do encadeamento pelo
controlador SDN.
Figura 28 – Encadeamento desejado para um pacote egresso da máquina virtual "ori-

gem"que destina-se a máquina virtual "destino". Elaborada pelo autor
Tendo em vista todo o processo descrito, pode-se elaborar uma arquitetura para o
serviço de implementação do encadeamento de funções de rede conforme na Figura 30. Os
blocos chamados de Gerenciador de Topologia e Gerenciador de SFC são os controladores
associados aos switches virtuais br-eth e br-int, respectivamente.
O Orquestrador recebe uma solicitação de serviço, otimiza o encadeamento que
implementa o serviço e por meio do controlador SDN, faz o cadastro das regras de fluxo.
Os dados referentes as regras instaladas são armazenadas no banco de dados da aplicação.
Algumas das ações descritas são paralelas ao processo descrito na etapa de posicio-
namento e outras são depois do posicionamento. Não há nenhuma ação executada antes
da tarefa de posicionamento.
O Agente Remoto é um serviço distribuído que roda em todos os nós na rede que
executa tarefas que precisam ser executadas localmente. A arquitetura VirtPhy prevê um
elemento deste tipo e chama de monitor. A comunicação com este módulo precisa seguir
padrões bem estabelecidos.
Figura 29 – Caminho percorrido pelo pacote visto pelo ponto de vista dos elementos que
formam a topologia. Elaborada pelo autor
Figura 30 – Proposta de arquitetura para o serviço de que executa o encadeamento.

Elaborada pelo autor
65
5 Implementação da Arquitetura
A implementação é baseada na arquitetura apresentada no Capítulo 4. A imple-

mentação é motivada pela necessidade de automatizar todos as etapas necessárias para se
ter a efetivação de um serviço.
5.1 Otimizador
A implementação do Módulo Otimizador não é parte do escopo deste trabalho. O
esforço empreendido no desenvolvimento do Orquestrador é de forma a criar uma interface
que permita a utilização do Otimizador como se fosse uma caixa-preta. Por isso a existência
do módulo tradutor que atua na arquitetura fazendo a tradução da entrada e saída do
otimizador de forma o seja possível a tarefa de otimização.
A implementação feita para testes é um otimizador fictício que recebe requisições
de serviços e dados da infraestrutura, providos pelo orquestrador, e retorna dados do
posicionamento e encadeamento de VNFs desenvolvidos para melhor caracterização da
operação.
5.2 Padrões de Comunicação entre Componentes

Conforme adiantado, a comunicação entre os diversos elementos que compõem a
aplicação é feita por requisições HTTP. A comunicação utiliza o formato JSON que pode
ser facilmente interpretado pela linguagem Python como um dicionário.
A entrada de dados e saída de dados pode ocorrer também pelo Client CLI. O
client CLI aceita entrada de dados utilizando o formato de arquivo YAML, sendo este
mais amigável para leitura por um humano.
A seguir serão listados os caminhos para se requisitar dados ou funcionalidades
do Orquestrador, bem como o padrão de entrada e saída. As requisições são realizadas
utilizando o endereço IP e a porta no qual o serviço de orquestração está executando. Para
cada recurso, é informado o formato e a URL pela qual se pode fazer a consulta o envio
de informação, bem como o método HTTP associado a requisição.
5.2.1 Hospedeiros
Hospedeiros (hosts) são informações acerca dos nós da topologia. São de interesse,
principalmente, do otimizador, que pode utilizar os dados para obter um hospedeiro
66 Capítulo 5. Implementação da Arquitetura
compatível com suas necessidades. O Código 1 exemplifica como seria a representação de

um hospedeiro no formato utilizado pelo orquestrador.
• URL: /wheke/api/v1.0/host
• Método HTTP: GET

1 {
2 " nfv -010 " : {
3 " id " : 2 ,
4 " type " : " host " ,
5 " properties " : {
6 " cpu " : 16 ,
7 " hd " : 909 ,
8 " mem " : 7185
9 }
10 }
11 }
Código 1 – JSON descritor de hospedeiro
Tabela 3 – Campos de dados de um hospedeiro com tipos e descrições

Item Tipo Descrição
"nfv-010" String Nome do Hospedeiro
id Inteiro Identificador do Hospedeiro
type String Tipo do Recurso
properties Seção de propriedades do recurso
cpu Inteiro Cores da CPU
hd Inteiro Espaço disponível no HD em GB
mem Inteiro Memoria RAM disponível em MB
5.2.2 Enlace
Enlaces (links) são as conexões entre hospedeiros (hosts). São importantes para o
roteamento escolhido pelo otimizador, por exemplo. Há apenas o método de GET, uma
vez que a informação é dada pela infraestrutura instalada e pelo usuário. O Código 2
exemplifica como seria a representação de um enlace no formato utilizado pelo orquestrador.
• URL: /wheke/api/v1.0/link

1 {
2 " nfv -011 < - > nfv -010 " : {
3 " id " : 3 ,
5.2. Padrões de Comunicação entre Componentes 67
4 " type " : " link " ,

6 " src_id " : 3 ,
7 " dst_id " : 2 ,
8 " bandwidth " : 1024
9 }
10 }
11 }
Código 2 – JSON descritor de enlace
Tabela 4 – Campos de dados de enlace de rede com tipos e descrições.

"nfv-011<->nfv-010" String Nome do Enlace
id Inteiro Identificador do Enlace
src_id e dst_id Inteiros Um link é conexão bidirecional e a identificação da
origem e destino esta relacionada ao ID do hospedeiro
bandwidth Inteiro Capacidade do enlace em MB
5.2.3 Descritor de Funções de Rede

Como a VIM utilizada é o OpenStack que não é diretamente habilitado a NFV,
é preciso criar uma representação para VNFDs utilizando dados do próprio OpenStack.
Pode-se utilizar flavors para descrever as capacidades e uma imagem como o tipo da
função.
O serviço de computação do OpenStack possui um recurso denominado flavor. Os
flavors definem a capacidade de computação, armazenamento e memória de uma máquina
virtual. Ao se instanciar uma máquina virtual, é preciso também especificar uma imagem.
O serviço de imagens do OpenStack é o Glance.
Ao se informar um flavor e uma imagem, já é possível criar uma função de rede,
mas o módulo otimizador necessita de informações como capacidade de processamento,
banda e o tipo de função de rede.
O serviço de imagem fornece um serviço onde os usuários podem carregar e descobrir
recursos de dados que devem ser usados com outros serviços. Isso, atualmente, inclui
imagens e definições de metadados (GLANCE’S. . . , 2017).
Quando um utilizador desejar obter o catálogo de funções de rede disponíveis, basta
fazer uma requisição HTTP GET para o orquestrador e receberá uma lista de VNFDs. O
Código 3 exemplifica como seria a representação de uma função de rede virtualizada no
formato utilizado pelo orquestrador.
• URL: /wheke/api/v1.0/vnfd
• Método HTTP: POST, GET

1 {
2 " type_01 " : {
3 " id " : 1 ,
4 " type " : " vnfd " ,
6 " cpu " : 4 ,
7 " nf_type " : " proxy " ,
8 " pr_capacity " : 900 ,
9 " bandwidth " : 10 ,
10 " image " : " ubuntu_SFC " ,
11 " flavor " : " m1 . small "
12 }
13 }
14 }
Código 3 – JSON descritor de VNFD
Tabela 5 – Campos de dados de um descritor de função de rede (VNFD) com tipos e

descrições
Item Tipo
Descrição
"type_01" String
Nome do Tipo de Função de Rede
id Inteiro
Identificador da VNFD
type String
Tipo do Recurso
cpu Inteiro Cores da CPU necessários para correto funcionamento
da VNF
nf_type Inteiro Tipo de função de rede
pr_capacity Inteiro Capacidade de processamento de rede da VNF em kbps
bandwidth Inteiro Largura de banda necessária para correto funcionamento
da VNF
image String (POST) Nome da imagem que será usada para criação da função
de rede
flavor String (POST) Nome do flavor usado para a criação da função de rede
5.2.4 Requisições de Serviços

Para informar ao orquestrador qual serviço implementar, é preciso registrar um
serviço via HTTP POST. O formato da informação é dado no Código 4. Caso o usuário
deseje saber quais serviços estão implementados, basta fazer um HTTP GET e receberá
uma lista de requisições.
• URL: /wheke/api/v1.0/register

1 {
2 " req0 " : {
3 " id " : 0 ,
4 " type " : " request " ,
6 " source_ip " : " 10.10.1.110 " ,
7 " source_port " : 80 ,
8 " source_host " : 0 ,
9 " destination_ip " : " 10.10.1.111 " ,
10 " destination_port " : 80 ,
11 " destination_host " : 1 ,
12 " protocol " : " udp " ,
13 " bandwidth " : 100 ,
14 " vnffg " : [ 4 , 2 , 3 ]
15 }
16 }
17 }
Código 4 – JSON descritor de requisições
Tabela 6 – Campos de dados de uma requisição de serviço com tipos e descrições

"req0" String Nome da requisição de serviço
id Inteiro Identificador da Requisição
source_ip String VM fonte de tráfego
source_port Inteiro Porta de origem de tráfego
source_host Inteiro ID do hospedeiro onde a VM de origem e criada
destination_ip String VM destino do tráfego
destination_port Inteiro Porta de destino de tráfego
destination_host Inteiro ID do hospedeiro onde a VM de destino e criada
protocol String Protocolo de rede. (UDP, TCP, ICMP)
bandwidth Inteiro Requisição de largura de banda
vnffg Lista Sequência de identificadores de VNFD
5.2.5 Instâncias de Funções de Rede

Ao receber uma solicitação do tipo VNFI o orquestrador executará a ação de criar
a instância. A aplicação não faz juízo da origem da informação. Em um ambiente com
otimizador, a solicitação virá do processo de otimização e em um ambiente de prototipagem
o utilizador pode enviar informações estáticas com intenção de criar um ambiente de testes.
É possível obter todas as VNFIs instanciadas na infraestrutura ao realizar uma

requisição HTTP GET e recebendo uma lista de instâncias. O Código 5 exemplifica como
seria a representação de uma instância de função de rede virtualizada no formato utilizado
pelo orquestrador.
• URL: /wheke/api/v1.0/vnfi

1 {
2 " instancia3 " : {
3 " type " : " vnfi " ,
5 " host_id " : 1 ,
6 " node_instance " : 0 ,
7 " type_id " : 3
8 }
9 }
10 }
Código 5 – JSON descritor de VNFI
Tabela 7 – Campos de dados de uma instância de função de rede com tipos e descrições
"instancia3" String Nome da VNFI
host_id Inteiro Identificador da VM fonte de tráfego
node_instance Inteiro Identificador incremental da VNF desse tipo dentro de hospe-
deiro
type_id Inteiro NF tipo de acordo com o arquivo de infra-estrutura
5.2.6 Encadeamento de Funções de Rede

Da mesma forma que a VNFI, o encadeamento é implementado no momento em que
é recebido um HTTP POST com informações do SFC. O formado do dado é especificado
no Código 6. O ponto mais crítico da estrutura é a propriedade "graph". Esta propriedade
descreve o caminho do pacote desde a origem até o destino. Desta forma, é preciso que
seja dado exatamente como é o caminho, ou seja, ordenado e incluir nós que não tenham
funções de rede.
• URL: /wheke/api/v1.0/sfc

1 {
2 " req0 " : {
3 " request_id " : 0 ,
4 " type " : " vnffg " ,
6 " graph " : [
7 {
8 " node " : 0 ,
9 " vnfs " : [
10 {
12 " vnf_type " : 4
13 },
14 {
16 " vnf_type " : 2
17 }
18 ]
19 },
20 {
21 " node " : 2 ,
22 " vnfs " : []
23 },
24 {
25 " node " : 3 ,
26 " vnfs " : []
27 },
28 {
29 " node " : 1 ,
30 " vnfs " : [
31 {
33 " vnf_type " : 3
34 }
35 ]
36 }
37 ]
38 }
39 }
40 }
Código 6 – JSON descritor de um encadeamento de VNFs

Tabela 8 – Campos de dados de um encadeamento de tráfego tipos e descrições

"req0" String Nome da Requisição ao qual implementa
request_id Inteiro Identificador da requisição ao qual implementa
graph Lista Grafo ordenado indicando o caminho do pacote no nível dos
hospedeiros no formato [(Nó: <id do nó>, vnfs: [<Lista ordenada
do caminho do pacote dentro do hospedeiro>], ...]
5.3 Banco de Dados
O funcionamento da aplicação depende de informações obtidas em outras seções de

uso e para tanto ocorre a necessidade de armazenar estas informações. Utilizou-se o banco
de dados SQLite, por ser uma versão mais leve de uma plataforma de banco de dados e
que pode ser armazenado em um simples arquivo.
Para integrar o banco de dados com a aplicação, foi usada a biblioteca Flask-
SQLAlchemy que relaciona objetos com tabelas. Ou seja, cada classe criada representa
uma tabela no banco de dados e cada instância da classe é representada por uma linha.
São suportadas funções como: commit, rollback, add, delete, update e outras funções de
sistemas de banco de dados completos. O uso da biblioteca com objeto relacional abstraiu
do programador a escrita de consultas SQL e portanto agilizou a implementação.
Na Figura 31 verifica-se o diagrama UML do banco de dados implementado.
Observa-se que um enlace (link) está relacionado a enlace. Uma VNFI (instância de função
de rede) está relacionada a um hospedeiro e a um VNFD. Uma requisição está relacionada
a hospedeiros e VNFD’s, nos termos de origem e destino de fluxo e nas funções de rede de
compõem o serviço.
Apesar de uma regra (Rule), de certa forma, atender a uma requisição, não há
necessidade de relacioná-las no banco de dados.
5.4 Cliente
O cliente é uma ferramenta CLI que tem por objetivo facilitar a utilização da apli-
cação. Utilizando o cliente é possível fazer solicitação de dados em relação a infraestrutura,
assim como fazer o posicionamento e o encadeamento de tráfego.
A entrada e saída de dados é feita por meio de arquivos no formato YAML. Os
campos presentes são os mesmos já explicados na Seção 5.2
5.4. Cliente 73
Figura 31 – Diagrama UML das tabelas do banco de dados. Elaborada pelo autor
5.4.1 Infraestrutura
Para obtenção da infraestrutura execute o comando dado no Código 7.
1 python client . py infra --f " caminho / para / arquivo / de / saida . yaml "
Código 7 – Comando para obtenção da infraestrutura pelo cliente CLI
A saída será um arquivo no formato YAML como mostrado no Código 8:

1 # # Descritor de Hospedeiros
2 nfv -010:
3 id : 2
4 type : host
5 properties :
6 cpu : 16
7 hd : 909
8 mem : 7185
9
10 # # Descritor de enlaces
11 nfv -011 < - > nfv -010:
12 id : 3
13 type : link
14 properties :
15 src_id : 3
16 dst_id : 2
17 bandwidth : 1024
18
19 # # Descritor de VNF
20 type_01 :
21 id : 1
22 type : vnfd
23 properties :
24 cpu : 4
25 nf_type : proxy
26 pr_capacity : 900
27 bandwidth : 10
Código 8 – YAML descritor de infraestrutura disponível
5.4.2 Criação de Funções de Rede

Para criação de funções de rede, execute o Código 9.
1 python client . py create_vnfd --f " caminho / para / arquivo / de / entrada . yaml "
Código 9 – Comando para criação de descritores de funções de rede pelo cliente CLI
O arquivo de entrada dever ser no formato YAML como mostrado no Código 10.
1 type_01 :
2 type : VNFD
3 properties :
4 nf_type : proxy
5 image : ubuntu_SFC
6 flavor : m1 . small
7 bandwidth : 10
8 cpu : 8
9 pr_capacity : 600
Código 10 – YAML descritor para criação de VNFD
5.4.3 Cadastro de Requisições

Para cadastro de requisições que serão otimizadas, execute o Código 11.
1 python client . py register --f " caminho / para / arquivo / de / entrada . yaml "
Código 11 – Comando para requisição da implantação de serviços na infraestrutura
O arquivo de entrada no formato YAML é mostrado no Código 12.

1 req0 :
2 id : 0
3 type : request
4 properties :
5 source_ip : 10.10.1.110
6 source_port : 80
5.4. Cliente 75
7 source_host : 0
8 destination_ip : 10.10.1.111
9 destination_port : 80
10 destination_host : 1
11 protocol : udp
12 bandwidth : 100
13 vnffg : [4 , 2 , 3]
Código 12 – YAML descritor de uma requisição de serviço
5.4.4 Execução do posicionamento

Para fazer um posicionamento de funções de rede, execute o Código 13.
1 python client . py placement --f " caminho / para / arquivo / de / entrada . yaml "
Código 13 – Comando para criação de VNFIs na infraestrutura
O arquivo de entrada dever ser no formato YAML como no Código 14.

1 instancia3 :
2 type : vnfi
3 properties :
4 host_id : 1
5 node_instance : 0
6 type_id : 3
Código 14 – YAML descritor de uma VNFI
5.4.5 Execução do encadeamento de funções de rede

Para fazer um encadeamento de funções de rede, execute o Código 15.
1 python client . py routing --f " caminho / para / arquivo / de / entrada . yaml "
Código 15 – Comando para requisição da implantação do encadeamento na infraestrutura
O arquivo de entrada dever ser no formato YAML como mostrado no Código 16.
1 req0 :
2 request_id : 0
3 type : vnffg
4 properties :
5 vnffg : [4 , 2 , 3]
6 graph :
7 - node : 0
8 vnfs :
9 - node_instance : 4
10 vnf_type : 4
12 vnf_type : 2
13 - node : 2
14 vnfs : []
15 - node : 3
16 vnfs : []
17 - node : 1
18 vnfs :
20 vnf_type : 3
Código 16 – YAML descritor de uma SFC
5.4.6 Reverter alterações na infraestrutura

Uma vez que deseje remover todas as alterações feitas, execute:
1 python client . py clean
Código 17 – Comando para limpar alterações na infraestrutura
Este comando removerá as instâncias de funções de rede e limpará as regras

instaladas nos switches virtuais.
5.5 Infraestrutura
A infraestrutura utilizada durante a implementação foi explicada na Seção 3.2.
Conforme já foi dito, o protótipo utiliza uma versão modificada do OpenStack na versão
IceHouse. Cada vértice do cubo é um nó de computação que executam um KVM hypervisor.
O nó de computação lida com o serviço de computação (nova) e um agente Open vSwitch
(neutron).
O mecanismo de encaminhamento utilizado é o KeyFlow (ver Seção 2.3) que realiza
o encaminhamento baseado em um identificador presente no campo MAC de destino no
cabeçalho Ethernet.
5.6 Controlador SDN

O controlador de rede escolhido foi o Ryu. Para a realização das tarefas envolvidas
no encadeamento são criadas duas instâncias do controlador que funcionam separadamente.
As duas instancias são explicitadas na arquitetura da Figura 30 e realizam as seguintes
funções:
• Gerenciador de SFC: que está conectado ao switch virtual br-int dos hospedeiros
e é responsável pela instalação das regras OpenFlow.
5.6. Controlador SDN 77
• Gerenciador de Topologia: conectado ao switch virtual br-eth dos hospedeiros e

informa como os hospedeiros estão conectados. A obtenção de topologia é por meio
do protocolo LLDP usando em conjunto com o controlador SDN.
O Gerenciador de SFC e o Gerenciador de Topologia serão discutidos nas Seções

5.6.1 e 5.6.2, respectivamente.
5.6.1 Gerenciador de SFC

O gerenciador de SFC é responsável por gerenciar as regras instaladas no switch
virtual (Open vSwitch). Para que seja possível o controle sobre este switch, é preciso
utilizar um controlador SDN. O controlador SDN escolhido para a implementação será
o Ryu. Para adicionar o controlador ao Open vSwitch executa-se o comando dado no
Código 18.
1 sudo ovs - vsctl set - controller br - int 19 2. 16 8. 1. 23 5: 66 34
Código 18 – Comando para cadastro do controlador no switch virtual
O IP e a porta são referentes ao IP do servidor que está rodando o controlador e a

porta é escolhida no momento da execução. O padrão é 6633, mas foi utilizado o 6634,
pois a porta padrão já é alocada pelo outro controlador.
Após instalado o controlador, é preciso implementá-lo utilizando a framework
disponibilizado pelo controlador Ryu. Como é um controlador modular, é possível executar
várias aplicações simultâneas que possuem diferentes funções. As aplicações executadas
são:
• ofctl_rest;
• rest_topology;
• br_int_controller.
A aplicação ofctl_rest é uma aplicação disponibilizada pelos desenvolvedores do

controlador Ryu que gerencia as regras instaladas nos Open vSwitch através de uma interface
RESTful, ou seja, requisições HTTP. A utilização é documentada em (TELEGRAPH;
CORPORATION, 2017) e um exemplo é dado no Código 19.
• URL: http://192.168.1.235:8081/v1.0/topology/switches

1 [
2 {
3 " ports " : [
4 {
5 " hw_addr " : " 9 a : d2 : c0 :5 b :81:01 " ,
6 " name " : " int - br - eth " ,
7 " port_no " : " 00000002 " ,
8 " dpid " : " 000046 baa11ebd48 "
9 }
10 ],
11 " dpid " : " 000046 baa11ebd48 "
12 },
13 {
14 " ports " : [
15 {
16 " hw_addr " : " 96:81: ea :2 e : e5 : c1 " ,
17 " name " : " int - br - eth " ,
18 " port_no " : " 00000004 " ,
19 " dpid " : " 00000 eca0a523f4c "
20 }
21 ],
22 " dpid " : " 00000 eca0a523f4c "
23 }
24 ]
Código 19 – JSON do retorno após consulta a aplicação de topologia
Assim como ofctl_rest, a rest_topology também é uma aplicação disponibilizada

que é responsável por divulgar a topologia dos switches. Este módulo informa os switches
conectados ao controlador, dando informações sobre suas interfaces. Disponibiliza as
conexões entre os switches e para o caso do switch de integração mostra a conexão do
switch com as máquinas virtuais.
Já a aplicação br_int_controller foi desenvolvida para fazer a tradução IP para
identificador do Open vSwitch, chamado de DPID. Desta forma é possível relacionar um
switch virtual com um hospedeiro em uma relação um para um.
Para isso é preciso adicionar um contexto WSGI a classe principal do controlador.
Quem realmente implementa a funcionalidade REST é a classe RestController que herda
da ControllerBase. A implementação é dada em Código 20.
1 br in t _ in s t an c e _n a m e = ' brint_api_app '
2
3 class BrIntController ( app_manager . RyuApp ) :
4 _CONTEXTS = {
5 ' wsgi ': WSGIApplication
6 }
7
8 OFP_VERSIONS = [ ofproto_v1_0 . OFP_VERSION ]
9
10 def __init__ ( self , * args , ** kwargs ) :
11 super ( BrIntController , self ) . __init__ (* args , ** kwargs )
12 self . bridges = []
13
14 wsgi = kwargs [ ' wsgi ']
15 wsgi . register ( RestController , { b ri n t _ in s t an c e _n a m e : self })
16
17
18 class RestController ( ControllerBase ) :
19 def __init__ ( self , req , link , data , ** config ) :
20 super ( RestController , self ) . __init__ ( req , link , data , ** config )
21 self . brint_app = data [ b ri n t _i n s ta n c e_ n a m e ]
22
23 @route ( ' hcube ' , '/ hcube / hosts ' , methods =[ ' GET ' ])
24 def get_nodes ( self , req , ** kwargs ) :
25 return self . _switches ()
26
27 def _switches ( self ) :
28 dpid = None
29 switches = get_switch ( self . brint_app , dpid )
30 body = json . dumps ([{ ' dpid ': hex ( switch . dp . id ) [2:]. zfill (16) , ' ip
': switch . dp . socket . getpeername () [0]} for switch in switches ])
31 return Response ( content_type = ' application / json ' , body = body )
Código 20 – Código para implementação do controlador de topologia, são ocultos os

imports
É criada uma rota na /hcube/hosts (Código 20 - linha 23) que ao ser requisitada
retorna o mapeamento IP-Hospedeiro. Um exemplo é dado no Código 21.
1 [
2 {
3 " ip " : " 192.168.1.243 " ,
4 " dpid " : " 000046 baa11ebd48 "
5 },
6 {
7 " ip " : " 192.168.1.244 " ,
8 " dpid " : " 00000 eca0a523f4c "
9 },
10 {
11 " ip " : " 192.168.1.241 " ,
12 " dpid " : " 0000 aeaf9cc07545 "
13 },
14 {
15 " ip " : " 192.168.1.242 " ,
16 " dpid " : " 0000 e2336c6df445 "

17 }
18 ]
Código 21 – JSON do retorno após consulta ao controlador de topologia pelo rota

/hcube/hosts
Ao final, a execução da aplicação é feita no controlador de rede através do comando dado

no Código 22.
1 ryu - manager -- observe - links hcubecontroller / br_int _contr oller . py ryu . app
. rest_topology ryu . app . ofctl_rest -- ofp - tcp - listen - port 6634 -- wsapi -
port 8081
Código 22 – Comando para execução do controlador de SFC
O campo –ofp-tcp-listen-port especifica a porta usada para comunicação com os

switches virtuais e o campo –wsapi-port é para especificar a porta referente as requisições
HTTP.
5.6.2 Gerenciador de Topologia

Em (VASSOLER, 2015) é descrita a implementação do controlador SDN que
habilita o funcionamento do protótipo. Esta implementação do controlador é aproveitada
neste trabalho com alterações. É adicionada uma classe que cria uma interface HTTP e
por meio desta é possível obter dados sobre os nós presentes na infraestrutura. Os dados
são:
• Identificador do switch OpenFlow responsável pela integração com a topologia;
• Nome do hospedeiro;
• Endereço IP do hospedeiro;
• Identificador KeyFlow do hospedeiro.
A classe que implementa é dada no Código 23.

1 class RestController ( ControllerBase ) :
2 def __init__ ( self , req , link , data , ** config ) :
3 super ( RestController , self ) . __init__ ( req , link , data , ** config )
4 self . hcube_app = data [ h cu b e _i n s t an c e _n a m e ]
5
6 @route ( ' hcube ' , '/ hcube / hosts ' , methods =[ ' GET ' ])
7 def get_nodes ( self , req , ** kwargs ) :
8 hcube = self . hcube_app
9 nodes = list ()
10 for n in hcube . hypercube . nodes . itervalues () :

11 nodes . append ({ ' dpid ': hex ( n . dpid ) [2:]. zfill (16) , ' name ': " nfv -
" + bin ( n . host ) [2:]. zfill (3) , ' ip ': n . ip , ' keyflow ': n . local_key })
12
13 body = json . dumps ( nodes )
14 return Response ( content_type = ' application / json ' , body = body )
Código 23 – Código para implementação da classe
Para se obter os dados, basta fazer uma requisição à rota /hcube/hosts e o serviço
roda no controlador de SDN na porta 8080. O formato da requisição e um exemplo de
resultado é dada como abaixo:
• URL: http://192.168.1.235:8080/hcube/hosts
1 [
2 {
3 " ip " : " 192.168.1.244 " ,
4 " name " : " nfv -011 " ,
5 " keyflow " :13 ,
6 " dpid " : " 000014187730 fb50 "
7 },
8 {
9 " ip " : " 192.168.1.243 " ,
10 " name " : " nfv -010 " ,
11 " keyflow " :17 ,
12 " dpid " : " 000014187730 fb7c "
13 },
14 {
15 " ip " : " 192.168.1.242 " ,
16 " name " : " nfv -001 " ,
17 " keyflow " :11 ,
18 " dpid " : " 0000141877310 a14 "
19 },
20 {
21 " ip " : " 192.168.1.241 " ,
22 " name " : " nfv -000 " ,
23 " keyflow " :19 ,
24 " dpid " : " 0000141877310 e5f "
25 }
26 ]
Código 24 – JSON do retorno após consulta ao Gerenciador de Topologia

5.7 Agente Remoto

O Agente Remoto é um serviço que roda em todos os nós da rede e faz configurações
e aquisição de dados que só podem ser obtidas localmente.
O OpenStack utiliza o iptables para implementar grupos de segurança que habilitam
certos tipos de tráfego de rede para suas VMs, como exemplo: SSH, ICMP e TCP. Por
consequência, quando uma máquina virtual é instanciada, é adicionada uma regra no
iptables do hospedeiro que não permite que pacotes com MAC destino diferente da
máquina virtual ingressem na VM. Este é o mecanismo de segurança contra ARP Spoofing
no OpenStack (ML2 Port Security). Acontece que o mecanismo de roteamento utilizado é
baseado na alteração do MAC dos pacotes para um VMAC que corresponde a um salto
definido. Esta alteração provoca a exclusão do pacote ao passar pelo fluxo de tabelas do
iptables.
O Agente Remoto é um serviço distribuído que roda em todos os nós na rede que
faz a exclusão destas regras, ou seja, desabilitam a proteção a ARP Spoofing. O serviço
precisa ser distribuído, pois não há controladores de iptables, da mesma forma como há
para o Open vSwitch, que permitam serem realizadas remotamente. Entretanto, versões
mais novas do OpenStack já implementaram formas de desabilitar esse mecanismo de
segurança, fazendo com que este módulo não seja mais necessário. A remoção da proteção
é feita após envio do IP da máquina virtual ao qual se deseja remover a proteção via
HTTP POST o IP da máquina virtual ao qual deseja-se remover a regra, como mostrado
no Código 25.
• URL: <ip_hospedeiro>:8083
• Método HTTP: POST

1 {
2 " ip " : " 192.168.1.234 "
3 }
4
Código 25 – Formato do dado enviado ao hospedeiro para desabilitar proteção do iptables
Outra tarefa executada pelo agente remoto é a de disponibilizar para o orquestrador

os identificadores OVS das interfaces físicas do hospedeiro. Esta informação não é capturada
pelo controlador de rede e nem disponibilizada por nenhum outro agente. Estas portas são
muito importantes para gerar os identificadores KeyFlow dos saltos. Outras informações
também são obtidas, mas têm apenas critério de verificação tais como nome do hospedeiro
e identificadores dos switches virtuais.
De forma resumida, as tarefas dos agentes remotos são:
5.8. Gerenciador de Infraestrutura Virtualizada 83
1. Obtenção do nome do hospedeiro (hostname);
2. Obtenção do identificador dos switches virtuais do hospedeiro;
3. Obtenção do identificadores das interfaces do switch virtual;
4. Gerenciamento de regras do firewall do hospedeiro.
A interface com o agente é feita por requisições HTTP. O método GET retorna os
dados relativos e o formato é dados como exemplificado no Código 26.
• URL: <ip_hospedeiro>:8083

1 {
2 " host " : " nfv -010 " ,
3 " brint " : " 000046 baa11ebd48 " ,
4 " breth " : " 000046 baa11ebd48 " ,
5 " ovs " :{
6 " br - int " :{
7 " br - int " : " 7 " ,
8 " int - br - eth " : " 6 "
9 },
10 " br - eth " :{
11 " br - eth " : " 1 " ,
12 " phy - br - eth " : " 8 " ,
13 " eth4 " : " 3 " ,
14 " eth2 " : " 5 " ,
15 " eth1 " : " 4 " ,
16 " eth0 " : " 2 "
17 }
18 }
19 }
20
Código 26 – JSON do retorno após consulta Agente Remoto
5.8 Gerenciador de Infraestrutura Virtualizada

Na arquitetura da Figura 22 é possível perceber que toda a interação do orquestrador
com a infraestrutura é mediada pela Gerenciador de Infraestrutura Virtualizada (VIM). A
VIM é, no contexto desta aplicação o OpenStack.
Conforme já explicado na Seção 2.6.1, o OpenStack é um sistema operacional em
nuvem que controla grandes conjuntos de recursos de computação, armazenamento e rede
em todo um data center.
A interação do Orquestrador com o OpenStack é feita por meio de uma API

Python chamada openstacksdk. A biblioteca openstacksdk é útil para a construção de
aplicativos para trabalhar com nuvens OpenStack. A API visa fornecer um conjunto
consistente e completo de interações com os muitos serviços do OpenStack, juntamente
com documentação completa, exemplos e ferramentas (FOUNDATION, 2017b).
5.9 Orquestrador
O módulo do orquestrador presenta na arquitetura da Figura 22 é o responsável
pela inteligência da aplicação. O Orquestrador media a interação entre os demais módulos.
As principais tarefas executadas por este módulo são:
• Faz o recebimento de requisições de serviço e aciona o otimizador;
• Realiza a descoberta de topologia interagindo com o Gerenciador de Topologia;
• Realiza o posicionamento de VNFs interagindo com a VIM;
• Realiza o encadeamento de VNFs interagindo com o Gerenciador de SFC.
5.9.1 Recebimento de Requisições de Serviço

O recebimento de requisições de serviço é o passo da execução da aplicação onde
um usuário do orquestrador informa o tipo de serviço que quer implementar. A solicitação
é enviada conforme já explicada na Seção 5.2.4.
O orquestrador ao receber a solicitação executa a função register_requisitions que
cria uma entrada no banco dados da requisição e as máquinas de origem e destino, se
não existirem. Após este processo, a requisição estará disponível para consulta do módulo
otimizador. Não são inseridos registros no banco de dados sobre as máquinas virtuais de
origem e destino, pois não são parte do domínio do orquestrador.
5.9.2 Descoberta de Topologia

A Descoberta de Topologia é um importante passo para a realização do encami-
nhamento do tráfego de rede de modo a realizar o SFC. É preciso conhecer não apenas
quais nós compõem a topologia, mas também como estão inseridos. Em termos práticos,
qual interface está conectada a qual hospedeiro e qual o ID OVS da interface. Estes dados
são usados no cálculo do identificador do salto KeyFlow, conforme explicado na Seção 2.3.
A descoberta de topologia é possível devido ao protocolo LLDP (ver Seção 2.5).
Cada nó divulga a seus vizinhos suas informações. Entretanto, o protocolo LLDP é utilizado
5.9. Orquestrador 85
em conjunto com o controlador SDN, de forma que as informações de conectividade são

centralizadas no controlador, ao invés de estarem distribuídas nos diversos nós da topologia.
Para que ocorra a centralização dos dados, é preciso que os LLDPDU sejam encaminhados
ao controlador uma vez que alcançam um switch OpenFlow.
A função _build_topology (Código 27) realiza este trabalho. O primeiro passo é a
aquisição dos enlaces da rede. Os enlaces obtidos do Gerenciador de Topologia, informam
como os servidores do data center estão se conectando e por qual interface. Entretanto, é
preciso saber não apenas o nome da interface, mas do identificador da interface no Open
vSwitch. Esta informação não é obtida pelo controlador de rede e por isso precisa ser obtida
localmente através do Agente Remoto.
Após a coleta de dados, é gerada para cada nó uma lista que relaciona um vizi-
nho a uma de suas interfaces. Desta forma, sabe-se para qual interface deve se fazer o
encaminhamento.
1 def _build_topology ( host ) :
2 links = make_rest_call ( endpoint = ryu_controller_breth , resource = Endpoint
. OPF_LINKS , method = ' GET ')
3 host_ovs_ports = simple_get ( host . host_ip , ovs_port ) [ ' ovs ' ][ 'br - eth ']
4
5 for link in links :
6 if link [ " src " ][ " dpid " ] == host . opf_dpip_breth :
7 neighbor_dpid = link [ " dst " ][ " dpid " ]
8 neighbor = Host . query . filter_by ( opf_dpip_breth = neighbor_dpid
) . first ()
9
10 if host . port_map is None :
11 host . port_map = json . dumps ({ str ( host . id ) : int (
host_ovs_ports [ 'phy - br - eth ' ]) })
12
13 port_map = json . loads ( host . port_map )
14 port_name = link [ " src " ][ " name " ]
15 port_map [ str ( neighbor . id ) ] = int ( host_ovs_ports [ port_name ])
16 host . port_map = json . dumps ( port_map )
Código 27 – Código para implementação do construtor de topologia
5.9.3 Posicionamento de VNFs

Após receber uma requisição de implementação de serviço (ver Seção 5.9.1), o
orquestrador consulta o módulo otimizador que responderá com o posicionamento otimizado
da função de rede virtualizada. As informações necessárias para a instanciação da VNFI
são:
• nome da instância;
• hospedeiro que deve ser criado;
• VNFD ao qual a criação deve se basear;
• o índice que corresponde a quantidade de funções de rede do mesmo tipo no hospe-

deiro.
Com estes dados é gerada uma entrada no banco de dados do orquestrador e criada
a máquina virtual. O processo de criação é de responsabilidade da VIM. No contexto desta
aplicação a VIM utilizada foi o OpenStack.
A criação é realizada pela função launch_instance na linha 21 do Código 28. Esta
função é implementada usando a API Python do OpenStack. É um método bloqueante e
portanto a execução do programa só continua após sua conclusão.
1 def e xecute _plac ement ( data ) :
2 network = " provider "
3
4 for name in data :
5 value = data [ name ]
6 if value [ ' type '] == ' vnfi ':
7 host = Host . query . get ( value [ ' properties ' ][ ' host_id ' ])
8 vnfd = VNFD . query . get ( value [ ' properties ' ][ ' type_id ' ])
9
10 if host is None :
11 print ( " Host not found " )
12 continue
13
14 if vnfd is None :
15 print ( " VNFD not found " )
16 continue
17
18 vnfi = VNFI ( name = name , host_id = host . id , vnfd_id = vnfd . id ,
19 node_instance = value [ ' properties ' ][ ' node_instance ' ])
20
21 vnfi_ip = openstack . launch_instance ( image_name = vnfd . image ,
22 image_flavor = vnfd . flavor ,
23 instance_name = vnfi . name ,
24 avai labil ity_zo ne = host . av ailabi lity_z one )
25
26 port = openstack . get_port_details ( ip = vnfi_ip )
27
28 vnfi . ip = port [ " ipv4 " ]
29 vnfi . mac = port [ " mac " ]
30 vnfi . openflow_port = _ ge t _ op f _ v m_ d e ta i l s ( tap = port [ " tap " ])
31
32 firewall_handler ( host . host_ip , vnfi . ip )
5.9. Orquestrador 87
33
34 db . session . add ( vnfi )
35 db . session . commit ()
Código 28 – Código de implementação do posicionamento de VNF
Ao final da criação de uma VNFI, coletam-se o endereço IP atribuído pelo serviço

de DHCP da VIM, o MAC da interface de rede virtual (vNIC) e o ID OpenFlow atribuído a
vNIC. Este último é utilizado para encaminhamento de pacotes utilizando regras OpenFlow.
O endereço de IP é utilizado para desabilitar a regra do firewall. Este IP é enviado
ao Agente Remoto por meio da função handle_firewall (na linha 31 Código 28).
Após estes passos, a VNFI criada está pronta para ser utilizada por algum fluxo de
tráfego.
5.9.4 Encadeamento de VNFs

Uma vez que as VNFIs estão posicionadas, é preciso redirecionar o tráfego descrito
na requisição de modo a passar pelas VNFIs que compõem o serviço. O encaminha-
mento vem da etapa de otimização e enviado ao orquestrador da forma como descrita na
Seção 5.4.3.
Os dados recebidos pelo orquestrador são repassados a função execute_routes. A
primeira tarefa realiza é obter a requisição correspondente ao qual o encadeamento recebido.
Da requisição são extraídas informações da origem e destino do tráfego, não informadas
pelo otimizador.
Em seguida, é preciso processar o encadeamento recebido de forma a se obter os
saltos (hops). O encadeamento recebido pelo otimizador vem como uma sequência ordenada
de hospedeiros e as funções de rede, alocadas nestes hospedeiros, pelo qual a tráfego deve
ser redirecionado. A informação do encadeamento vinda do otimizador desconsidera a
origem e o destino do tráfego.
Depois de processar o encadeamento tem-se os saltos que implementam o serviço e
então são criadas as regras para cada salto. As regras são enviadas ao controlador SDN, que
faz a gerência de SFC, utilizando o endereço <ip_controlador_sdn>:8081/stats/flowentry/add.
Conforme já explicado na Seção 4.3.2, um salto é o caminho percorrido pelo fluxo
de rede quando sai de uma máquina virtual até entrar em outra. Durante a criação das
regras, é preciso verificar se: 1) Origem e destino do salto são funções de rede; 2) Origem do
salto é a origem do tráfego; 3) Destino do salto é o destino do tráfego. De forma resumida,
tem-se os seguintes casos que devem ser levados em conta durante a criação das regras de
encadeamento:
1. Origem e destino do salto são funções de rede.

a) Máquinas virtuais no mesmo hospedeiro;

b) Origem e destino do salto estão em hospedeiros diferentes.
2. Origem do salto é a origem do tráfego;

3. Destino do salto é o destino do tráfego.

Como é possível perceber, é importante verificar se as duas máquinas virtuais

envolvidas no salto então no mesmo hospedeiro ou não. Quando as duas máquinas virtuais
estão em hospedeiros diferentes é preciso gerar um identificador de salto. O identificador
de salto é gerado utilizando o protocolo de encaminhamento Keyflow (ver Seção 2.3) e,
portanto, criam-se as regras levando em conta este identificador.
Caso as máquinas estejam no mesmo hospedeiro, a classificação do fluxo é, de
modo geral, dado pela porta de entrada no switch virtual e pelo identificador de salto. O
identificador de salto é o mesmo do salto anterior.
As regras utilizadas para realizar o encadeamento do tráfego para cada caso de
estudo são detalhadas no Apêndice A.
89
6 Caracterização de Funcionamento
Para verificar o funcionamento da aplicação, é preciso primeiro demostrar que o

orquestrador é capaz de fazer o posicionamento e encadeamento de tráfego. Desta forma,
foram elaborados testes que visam demostrar a capacidade da aplicação de redirecionar
o tráfego de forma a se obter um serviço de rede. A função de rede utilizada para a
demonstração é uma Service Function Forwarder (SFF). Está função de rede recebe um
pacote de rede e o reenvia pela mesma interface recebida.
A segunda validação que precisa ser feita, é demonstrar que o orquestrador é capaz
de trabalhar em conjunto com o módulo otimizador, uma vez que um grande esforço foi
feito na tentativa de criar uma interface bem definida para utilização do orquestrador.
Para fazer as duas verificações foi criado um módulo otimizador fictício conforma
explicado na Seção 5.1. Os dados do posicionamento são relativos a cenários de testes
elaborados que visam explorar todos os tipos de casos possíveis discutidos no Capítulo 5.
Para comprovar a funcionalidade, é exibido o posicionamento das VNFIs de acordo
com o posicionamento pedido e para comprovar o SFC são gerados gráficos que resumem
o tráfego na interface de rede de cada elemento do SFC.
Na Seção 6.1 será explicado o script de teste utilizado para comprovar o SFC e nas
Seções 6.2 - 6.6 são descritos os cenários de teste e os resultados obtidos.
6.1 Script de Teste

O script de teste utiliza a ferramenta de iperf que cria um tráfego UDP de 1 Mbps
com utilizando a porta 5000 da VM. O tráfego é gerado na origem do serviço e destinado
a VM de destino, passando por todas as funções de rede no caminho.
O funcionamento do script é da seguinte forma:
1. No interfalo de 0 a 10 segundos, espera-se todas as máquinas virtuais se preparem

para o teste e por isso não há tráfego em nenhuma interface;
2. No intervalo de 10 a 20 segundos, todas as funções de rede estão realizando o

redirecionamento do tráfego. Desta forma, o tráfego nas interfaces das VNFIs é o
dobro do tráfego gerado na VM de origem, já que a VM recebe e envia o pacote pela
mesma interface;
3. No intervalo de 20 a 30 segundos, o serviço da primeira VNFI do SFC é suspenso. O

tráfego previsto na interface da VNFI desligada é esperado que seja de 1 Mbps, uma
90 Capítulo 6. Caracterização de Funcionamento
vez que recebe o fluxo mais não o encaminha. O tráfego nas máquinas virtuais nos
saltos seguintes do SFC é esperado que seja nulo, por consequência do desligamento
da VNFI;
4. No intervalo 30 e 40 segundos, a função da VNFI desligada é reestabelecida e a

situação é a mesma do Item 2;
5. Caso haja mais funções de rede no SFC, é realizado o mesmo procedimento do Item
3, com a diferença que a VNFI desligada é a próxima no salto do SFC. O teste segue
esse procedimento até que todas as VNFIs do SFC sejam testadas.
Os gráficos gerados do experimento contém médias dos valores dos testes que
foram executados 3 vezes. O resultado esperado é que o tráfego na VM de destino cesse
por um número de vezes exatamente igual ao número de VNFI no SFC. Para facilitar a
visualização dos casos, em todos os cenários, a origem e do destino do tráfego encontram-se,
respectivamente, nos hospedeiros NFV-000 e NFV-001 (Figura 32).
6.2 Cenário 1
O Cenário 1 é descrito na Figura 32. Neste cenário, tem-se a necessidade de
implementar um serviço que seja do tipo SRC -> SFF2 -> SFF4 -> DST. Então, é enviada
uma requisição, como mostrado no Código 29, ao otimizador.
Figura 32 – Cenário 1 de teste.

6.2. Cenário 1 91
1 cenario -1 - ida :
2 type : request
3 properties :
4 source_ip : 10.0.101.17
5 source_port : 80
6 source_host : 3
10 protocol : udp
11 bandwidth : 100
12 vnffg : [2 , 4]
Código 29 – Conteúdo da requisição enviada para o otimizador pelo orquestrador para

implementar o serviço do Cenário 1
O módulo otimizador escolhe os hospedeiros NFV-010 para SFF2 e NFV-011 para

SFF4, bem como define a rota para a realização do SFC. O resultado da otimização é
repassado ao orquestrador por meio de HTTP POST. O posicionamento é descrito em
Código 30 e a rota escolhida é descrita em Código 31.
1 sff2 :
2 properties :
3 host_id : 5
4 node_instance : 0
5 type_id : 1
6 ip : 10.0.101.22
7 type : vnfi
8
9 sff4 :
10 properties :
11 host_id : 6
12 node_instance : 0
13 type_id : 1
14 ip : 10.0.101.24
15 type : vnfi

posicionamento das VNFIs do Cenário 1
1 # SRC -> SFF2 -> SFF4 -> DST

3 type : route
4 properties :
5 graph :
6 - node : 3
7 vnfs : []
8 - node : 5
9 vnfs :
10 - { node_instance : 0 , vnf_type : 1}
11 - node : 6
12 vnfs :
14 - node : 4
15 vnfs : []

encadeamento do tráfego das VNFIs do Cenário 1
A tarefa de posicionar é repassada ao OpenStack. O posicionamento pode ser

comprovado ao se verificar na interface gráfica do OpenStack a presença não só da VNFI
como também das VM SRC e VM DST, na Figura 33.

alocadas na VIM para realização do Cenário 1.
As regras então são geradas e instaladas nos switches virtuais. As regras instaladas
para este cenário são detalhadas no Apêndice B na Tabela 12.
Após o posicionamento ser completo e executado o cadastro das regras nos switches,
o script de teste é executado. O funcionamento do encadeamento, conforme descrito na
Seção 6.1, pode ser verificado no gráfico da Figura 34.
6.3 Cenário 2
O Cenário 2 foi elaborado de forma a mostrar a execução do SFC quando o tráfego
precisa passar por um hospedeiro sem subir a nível das VMs. O cenário é descrito na
Figura 35. Neste cenário, tem-se a necessidade de implementar um serviço que seja do tipo
SRC -> SFF2 -> DST. Então, é enviada uma requisição, como mostrado no Código 32,
ao otimizador.
6.3. Cenário 2 93
Figura 34 – Gráfico Throughput X Tempo para o Cenário 1 utilizando o script descrito

na Seção 6.1 .
2 type : request
3 properties :
4 source_ip : 10.0.101.17
5 source_port : 80
6 source_host : 3
10 protocol : udp
11 bandwidth : 100
12 vnffg : [2]

implementar o serviço do cenário 2
O módulo otimizador escolhe os hospedeiros NFV-010 para SFF2, bem como define
a rota para a realização do SFC. O resultado da otimização é repassado ao orquestrador
por meio de HTTP POST. O posicionamento é descrito em Código 33 e a rota escolhida é
descrita em Código 34.
1 sff2 :
2 properties :
3 host_id : 5
4 node_instance : 0
5 type_id : 1
6 ip : 10.0.101.22
7 type : vnfi

posicionamento das VNFIs do cenário 2
1 # SRC -> SFF2 -> DST

3 type : route
4 properties :
5 graph :
6 - node : 3
7 vnfs : []
8 - node : 5
9 vnfs :
11 - node : 6
12 vnfs : []
13 - node : 4
14 vnfs : []

encadeamento do tráfego das VNFIs do cenário 2

6.3. Cenário 2 95


na Seção 6.1 .
6.4 Cenário 3
O Cenário 3 foi elaborado para exemplificar o funcionamento da solução de SFC
quando existem duas máquinas virtuais que fazem parte do encadeamento no mesmo
hospedeiro, e uma destas é a origem do tráfego. Quando uma das máquinas virtuais do
salto é a origem do tráfego é um caso especial que deve ser tratado. O cenário é descrito na
Figura 38. Neste cenário, tem-se a necessidade de implementar um serviço que seja do tipo
SRC -> SFF1 -> DST. Então, é enviada uma requisição, como mostrado no Código 35,
ao otimizador.
2 type : request
3 properties :
4 source_ip : 10.0.101.17
5 source_port : 80
6 source_host : 3
10 protocol : udp
11 bandwidth : 100
12 vnffg : [1]

implementar o serviço do Cenário 3
6.4. Cenário 3 97
1 sff1 :
2 properties :
3 host_id : 3
4 node_instance : 0
5 type_id : 1
6 ip : 10.0.101.21
7 type : vnfi
8


3 type : route
4 properties :
5 graph :
6 - node : 3
7 vnfs :
9 - node : 5
10 vnfs : []
11 - node : 6
12 vnfs : []
13 - node : 4
14 vnfs : []




na Seção 6.1 .
6.5 Cenário 4
O Cenário 4 foi criado para exemplificar o funcionamento da solução de SFC quando
existem duas máquinas virtuais que fazem parte do encadeamento no mesmo hospedeiro,
e uma destas é o destino do tráfego. O cenário é descrito na Figura 41. Neste cenário,
tem-se a necessidade de implementar um serviço que seja do tipo SRC -> SFF5 -> DST.
Então, é enviada uma requisição, como mostrado no Código 38, ao otimizador.
2 type : request
3 properties :
6.5. Cenário 4 99
4 source_ip : 10.0.101.17
5 source_port : 80
6 source_host : 3
10 protocol : udp
11 bandwidth : 100
12 vnffg : [5]

implementar o Cenário 4
1 sff5 :
2 properties :
3 host_id : 4
4 node_instance : 0
5 type_id : 1
6 ip : 10.0.101.25
7 type : vnfi


3 type : route
4 properties :
5 graph :
6 - node : 3
7 vnfs : []
8 - node : 5
9 vnfs : []
10 - node : 6
11 vnfs : []
12 - node : 4
13 vnfs :

encadeamento do tráfego das VNFIs do cenário 4
A tarefa de posicionar é repassada ao OpenStack. O posicionamento é comprovado

ao se verificar na interface gráfica do OpenStack a presença não só da VNFI como também
das VM SRC e VM DST, na Figura 42.

6.6. Cenário 5 101

na Seção 6.1 .
6.6 Cenário 5
O Cenário 5 foi elaborado para exemplificar o funcionamento da solução de SFC
quando existem duas máquinas virtuais que fazem parte do encadeamento no mesmo
hospedeiro, e ambas são VNFIs. O cenário é descrito na Figura 44. Neste cenário, tem-se a
necessidade de implementar um serviço que seja do tipo SRC -> SFF2 -> SFF3 -> DST.
Então, é enviada uma requisição, como mostrado no Código 41, ao otimizador.
2 type : request
3 properties :
4 source_ip : 10.0.101.17
5 source_port : 80
6 source_host : 3
10 protocol : udp
11 bandwidth : 100
12 vnffg : [2 , 3]

implementar o serviço do cenário 5
O módulo otimizador escolhe os hospedeiros NFV-010 para SFF2 e SFF3, bem

como define a rota para a realização do SFC. O resultado da otimização é repassado ao
orquestrador por meio de HTTP POST. O posicionamento é descrito em Código 42 e a

rota escolhida é descrita em Código 43.
1 sff2 :
2 properties :
3 host_id : 5
4 node_instance : 0
5 type_id : 1
6 ip : 10.0.101.22
7 type : vnfi
8
9 sff3 :
10 properties :
11 host_id : 5
12 node_instance : 1
13 type_id : 1
14 ip : 10.0.101.23
15 type : vnfi

1 # SRC -> SFF2 -> SFF3 -> DST

3 type : route
4 properties :
5 graph :
6.6. Cenário 5 103
6 - node : 3
7 vnfs : []
8 - node : 5
9 vnfs :
12 - node : 6
13 vnfs : []
14 - node : 4
15 vnfs : []

A tarefa de posicionar é repassada ao OpenStack. O posicionamento é comprovado

ao se verificar na interface gráfica do OpenStack a presença não só das VNFIs como
também das VM SRC e VM DST, na Figura 45.


na Seção 6.1 .
105
7 Conclusões e Trabalhos Futuros
Este capítulo apresenta as conclusões do trabalho realizado, mostrando suas contri-

buições. Por fim, são apresentadas suas limitações e perspectivas de trabalhos futuros.
7.1 Conclusões
No contexto do Núcleo de Estudos em Redes Definidas por Software, há diversos

estudos no campo NFV. A proposta de arquitetura VirtPhy e o protótipo utilizado para
a implementação e realização de testes do orquestrador são importantes ferramentas de
pesquisa. Neste contexto, houve a necessidade de se implementar a orquestração de forma
autônoma visando acelerar a pesquisa utilizando estas ferramentas.
Espera-se que o trabalho de desenvolvimento do orquestrador seja continuado por
outras pesquisas e que haja um esforço para desenvolver novas funcionalidades e novas
soluções de otimização que trabalhem em conjunto com o orquestrador utilizando-se da
API desenvolvida.
Os objetivos fixados no Capítulo 1 foram todos alcançados: (i) foi criada uma
interface de comunicação que gerencia as requisições de serviço; (ii) foi automatizada a
coleta de informação sobre a infraestrutura de rede e computação em um data center
centrado em servidor; (iii) criou-se uma interface de comunicação bem definida com o
módulo otimizador por meio da qual pode-se enviar e receber informações e requisições,
bem como o envio de decisões de otimização; e (iv) automatizou-se o posicionamento e
encadeamento de funções de rede virtualizadas resultantes do processo de otimização.
Foram encontradas diversas dificuldades devido ao fato da solução envolver tanto
software quanto hardware. Ao iniciar o trabalho, houve uma curva de aprendizado longa
na utilização do controlador de rede Ryu, do protocolo OpenFlow, do switch virtual Open
vSwitch, e da plataforma de nuvem OpenStack. A definição da linguagem de programação
representou mais um desafio; escolheu-se Python por ser a linguagem mais utilizada por
aplicações de mesma natureza e, apesar do tempo requerido para aprender uma nova
linguagem, a escolha se mostrou muito acertada devido à flexibilidade alcançada.
Por fim, tirando alguns imprevistos pontuais em relação à infraestrutura, foi possível
realizar a tarefa pretendida com o suporte dos membros do NERDS, que possuem um
imenso conhecimento sobre as ferramentas e técnicas utilizadas.
106 Capítulo 7. Conclusões e Trabalhos Futuros
7.2 Trabalhos Futuros

Sendo esta a primeira versão de uma aplicação que está integrada com tantos outros
recursos, é natural que haja um processo de evolução do software no sentido de fazer uma
aplicação mais robusta. Neste sentido, além das funcionalidades implementadas para a
prova de conceito, pode-se listar as seguintes funcionalidades que seriam importantes para
uma versão adequada à operação:
• Implementar e comparar diversos tipos de otimizadores baseados em heurísticas ou

programação linear que possam ser acoplados de forma automática ao orquestrador;
• Implementar uma realimentação na otimização, de forma que, ao chegar novas

requisições, o otimizador considere tanto os recursos disponíveis quanto os serviços
já implementados;
• Implementar a orquestração de outras topologias centradas em servidores e também

topologias centradas em rede;
• Implementar uma interface gráfica de administração para o orquestrador, que inclua,

por exemplo, cadastro e monitoramento de requisições.
107
Referências
CHAYAPATHI SYED F. HASSAN, P. S. R. Network Functions Virtualization (NFV)

with a Touch of SDN. [S.l.]: Person, 2016. Citado 5 vezes nas páginas 9, 15, 31, 32 e 34.
CHECKO, A. et al. Cloud ran for mobile networks—a technology overview. IEEE
Communications surveys & tutorials, IEEE, v. 17, n. 1, p. 405–426, 2015. Citado na
página 23.
DOMINICINI, C. K. et al. Virtphy: A fully programmable infrastructure for efficient nfv

in small data centers. In: IEEE. Network Function Virtualization and Software Defined
Networks (NFV-SDN), IEEE Conference on. [S.l.], 2016. p. 81–86. Citado 12 vezes nas
páginas 9, 10, 15, 23, 43, 45, 46, 47, 48, 49, 50 e 52.
ETSI, N. Etsi gs nfv 002 v1. 1.1 network functions virtualization (nfv). Architectural
Framework. sl: ETSI, 2013. Citado 3 vezes nas páginas 24, 28 e 29.
FOUNDATION, L. What Is Open vSwitch? 2017. <http://docs.openvswitch.org/en/

latest/intro/what-is-ovs/>. Citado 3 vezes nas páginas 9, 35 e 36.
FOUNDATION, O. OpenStack Documentation. 2017. <https://docs.openstack.org/ocata/

>. Citado 4 vezes nas páginas 9, 40, 41 e 84.
GARNER, H. L. The residue number system. IRE Transactions on Electronic Computers,

IEEE, n. 2, p. 140–147, 1959. Citado na página 35.
GLANCE’S documentation. 2017. Disponível em: <https://docs.openstack.org/glance/

pike/>. Citado na página 67.
GUO, C. et al. Bcube: a high performance, server-centric network architecture for modular
data centers. ACM SIGCOMM Computer Communication Review, ACM, v. 39, n. 4, p.
63–74, 2009. Citado na página 42.
GUO, C. et al. Bcube: A high performance, server-centric network architecture for

modular data centers. In: ACM SIGCOMM. Association for Computing Machinery,
Inc., 2009. Disponível em: <https://www.microsoft.com/en-us/research/publication/
bcube-a-high-performance-server-centric-network-architecture-for-modular-data-centers/
>. Citado na página 43.
GUO, C. et al. Dcell: a scalable and fault-tolerant network structure for data centers. In:
ACM. ACM SIGCOMM Computer Communication Review. [S.l.], 2008. v. 38, n. 4, p.
75–86. Citado na página 42.
KHONDOKER, R. et al. Feature-based comparison and selection of software defined

networking (sdn) controllers. In: IEEE. Computer Applications and Information Systems
(WCCAIS), 2014 World Congress on. [S.l.], 2014. p. 1–7. Citado na página 33.
KREUTZ, D. et al. Software-defined networking: A comprehensive survey. Proceedings of

the IEEE, IEEE, v. 103, n. 1, p. 14–76, 2015. Citado 2 vezes nas páginas 23 e 31.
108 Referências
KTENZER, P. b. OpenStack Multiple Node Configurations. 2015. Disponível em:

<https://keithtenzer.com/2015/01/26/openstack-multiple-node-configurations/>. Citado
na página 50.
KVM. Kernel-based Virtual Machine. 2016. [Online; accessed 14-November-2017].
Disponível em: <https://www.linux-kvm.org/index.php?title=Main_Page&oldid=
173792>. Citado na página 34.
LINK Layer Discovery Protocol (LLDP). 2015. Disponível em: <https://learningnetwork.
cisco.com/docs/DOC-26851>. Citado na página 38.
MARTINELLO, M. et al. Keyflow: a prototype for evolving sdn toward core network
fabrics. IEEE Network, IEEE, v. 28, n. 2, p. 12–19, 2014. Citado 4 vezes nas páginas 9,
35, 36 e 37.
MCKEOWN, N. et al. Openflow: enabling innovation in campus networks. ACM
SIGCOMM Computer Communication Review, ACM, v. 38, n. 2, p. 69–74, 2008. Citado
na página 32.
MELL, P.; GRANCE, T. et al. The nist definition of cloud computing. Computer Security
Division, Information Technology Laboratory, National Institute of Standards and
Technology Gaithersburg, 2011. Citado na página 40.
MIJUMBI, R. et al. Management and orchestration challenges in network functions
virtualization. IEEE Communications Magazine, IEEE, v. 54, n. 1, p. 98–105, 2016.
Citado 3 vezes nas páginas 23, 27 e 28.
NERDS - Núcleo de Estudos em Redes Definidas por Software. Disponível em:
<http://nerds.ufes.br/>. Acesso em: 03-01-2018. Citado na página 23.
NFV, N. F. V. Etsi gs nfv-swa 001 v1. 1.1 (2014-12). 2014. Citado na página 30.
ORACLE, V. Virtualbox user manual. URL: http://www.virtualbox.org/manual/:
2016-05-01), 2011. Citado na página 34.
OSTROUCHOV, G. Parallel computing on a hypercube: an overview of the architecture
and some applications. In: Computer Science and Statistics, Proceedings of the 19th
Symposium on the Interface. [S.l.: s.n.], 1987. p. 27–32. Citado na página 42.
RASH, M. Linux Firewalls: Attack Detection and Response with iptables, psad, and
fwsnort. [S.l.]: No Starch Press, 2007. Citado 2 vezes nas páginas 9 e 38.
SHIMA, K.; DANG, N. Openstack documentation,”. Administration Guides–Defining Sto-
rage Policies”, OpenStack, URL: http://docs. openstack. org/developer/swift/admin_guide.
html Publicerad, p. 07–20, 2016. Citado na página 25.
TELEGRAPH, N.; CORPORATION, T. Docs ryu.app.ofctlrest. 2017. Disponível em:
<http://ryu.readthedocs.io/en/latest/app/ofctlrest.html>. Citado na página 77.
VASSOLER, G.; RIBEIRO, M. An intelligent and integrated architecture for data centers
with distributed photonic switching. In: . [S.l.: s.n.], 2017. p. 1–5. Citado na página 49.
VASSOLER, G. L. TRIIIAD: Uma Arquitetura Para Orquestração Autonômica de Redes
de Data Center Centrado em Servidor. Tese (PhD dissertation) — Universidade Federal
do Espírito Santo, 2015. Citado 3 vezes nas páginas 23, 49 e 80.
Referências 109
VIRTUALISATION, N. F. Introductory white paper. In: SDN and OpenFlow World

Congress, Darmstadt, Germany. [S.l.: s.n.], 2012. Citado na página 27.
WELTE, H. The netfilter framework in linux 2.4. In: Proceedings of Linux Kongress. [S.l.:
s.n.], 2000. Citado na página 37.
XENSERVER. 2017. Disponível em: <https://xenserver.org/>. Citado na página 34.
ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art and research
challenges. Journal of internet services and applications, Springer, v. 1, n. 1, p. 7–18, 2010.
Citado na página 39.
Apêndices
113
APÊNDICE A – Regras para encadeamento

em diferentes casos de posicionamento
Neste apêndice são detalhadas as regras instaladas nos switches virtuais para a
realização do encaminhamento do tráfego de rede de modo a implementação de um serviço.
São analisados todos os casos descritos na Seção 5.9.4
A.1 Caso 1 - Origem e destino do salto são funções de rede

O Caso 1 é quando tanto a origem e quanto o destino do salto são VNFIs. Neste
contexto, são criadas regras para realização do redirecionamento do tráfego de uma função
de rede para a outra.
Figura 47 – Caso 1 na qual as duas máquinas virtuais são funções de rede. a) no mesmo
hospedeiro b) hospedeiros diferentes.
Quando as duas máquinas virtuais estão no mesmo hospedeiro (Figura 47-a) cria-se
apenas uma regra para encaminhar o fluxo de uma VM para a outra. Utiliza-se a regra do
Código 44, onde verifica-se se o MAC de destino do pacote corresponde ao identificador
do salto anterior e se a porta de ingresso no switch virtual é a porta da máquina virtual
origem do salto. Em conformidade com o classificador o pacote é encaminhado a porta da
máquina virtual destino do salto sem alterações.
1 {
2 " dpid " : < dpid do switch do hospedeiro > ,
3 " priority " : < id flow + 101 > ,
4 " match " :{
114 APÊNDICE A. Regras para encadeamento em diferentes casos de posicionamento
5 " dl_dst " : < identificador do salto atual > ,

6 " in_port " : < porta da vm de origem do salto >
7 },
8 " actions " :[
9 {
10 " type " : " OUTPUT " ,
11 " port " : < porta da vm de destino do salto >
12 }
13 ]
14 }
Código 44 – Formato da regra adicionada para o Caso 1A
Quando em máquinas diferentes, instala-se duas regras Código 45. A primeira regra
classifica o fluxo egresso da máquina virtual de origem. A classificação é feita verificando
se o MAC de destino corresponde ao identificador da rota anterior e se a porta de ingresso
no switch é a porta da VM de origem do salto. Em caso positivo, o MAC de destino é
alterado para o identificador do salto atual e o pacote é encaminhado para a saída normal
do switch.
A segunda regra (Código 45 - linha 17) verifica se o MAC de destino do pacote
corresponde ao identificador da rota atual. Em caso positivo, o pacote é encaminhado a
porta da VM de destino sem alterações.
Quando em hospedeiros diferentes (Figura 47-b), são criadas duas regras que são
instaladas nos dois switches virtuais dos dois hospedeiros envolvidos no salto. A primeira
regra é instalada no switch virtual no hospedeiro de origem do salto. A outra regra é
instalada no switch virtual do hospedeiro onde a máquina virtual de destino do salto se
encontra alocada.
1 {
2 {
3 " dpid " : < dpid do switch do hospedeiro da VM origem > ,
4 " priority " : < id flow + 101 > ,
5 " match " :{
6 " dl_dst " : < identificador do salto anterior > ,
8 },
9 " actions " :[
10 {
11 " type " : " OUTPUT " ,
12 " port " : < porta int - br - eth do switch OVS >
13 }
14 ]
15 },
16 {
17 " dpid " : < dpid do switch do hospedeiro da VM Destino > ,
A.2. Caso 2 - Origem do salto é a origem do tráfego 115
18 " priority " : < id flow + 101 > ,

19 " match " :{
21 },
22 " actions " :[
23 {
24 " type " : " OUTPUT " ,
26 }
27 ]
28 }
29 }
Código 45 – Formato da regra adicionada para o Caso 1B
A.2 Caso 2 - Origem do salto é a origem do tráfego

Quando a origem do salto é a origem do tráfego há a necessidade de se adicionar
mais campos à regra, diferente do primeiro caso estudado, quando a verificação do tráfego
egresso da máquina virtual era classificado baseado no MAC de destino que corresponde
ao identificador do salto anterior. Esta verificação não é possível no Caso 2, uma vez que
não existem saltos anteriores.
Figura 48 – Caso 2 na qual a origem do salto é a origem do tráfego. a) no mesmo hospedeiro

b) hospedeiros diferentes.
Portanto, a classificação do fluxo na origem do salto é feita utilizando o IP de

origem e destino do pacote, bem como o protocolo. Se estas informações corresponderem
as informações do serviço, o redirecionamento é realizado.
Da mesma forma como no Caso 1, há uma diferença no tratamento quando as
máquinas estão em hospedeiros diferentes ou quando no mesmo hospedeiro.
Se as duas máquinas estão no mesmo hospedeiro (Figura 48-a), é criada apenas

uma regra que é instalada no switch virtual do hospedeiro. Esta regra (Código 46) classifica
o fluxo utilizando IP de origem, IP de destino e protocolo. Neste caso, modifica-se o MAC
de destino para um MAC especial para este caso e encaminha para a porta da máquina
virtual de destino do salto.
1 {
2 " dpid " : < dpid do switch do hospedeiro > ,
3 " priority " : < id flow + 101 > ,
4 " match " :{
5 " nw_src " : < ip da origem > ,
6 " nw_dst " : < ip do destino > ,
7 " dl_type " : 2048 ,
8 " nw_proto " : < id do protocolo >
9 },
10 " actions " :[
11 {
12 " type " : " SET_DL_DST " ,
13 " dl_dst " : " aa : bb : cc :11:22:33 "
14 },
15 {
16 " type " : " OUTPUT " ,
17 " port " : < porta da m á quina virtual de destino do salto >
18 }
19 ]
20 }
Quando em hospedeiros diferentes (Figura 48-b), a classificação do tráfego egresso

é a mesma do Caso 2a, entretanto, gera-se um identificador de salto KeyFlow que é escrito
no MAC de destino do pacote. Esta regra (Código 47) é instalada no hospedeiro de origem
do salto. A segunda regra é instalada no switch virtual do hospedeiro de destino do salto.
Esta regra verifica o MAC de destino do pacote que deve ser o identificador do salto e, em
caso positivo, encaminha a porta da VM de destino do tráfego.
1 {
2 {
3 " dpid " : < dpid do switch do hospedeiro da VM Origem > ,
4 " priority " : < id flow + 101 > ,
5 " match " :{
6 " nw_src " : < ip da origem > ,
7 " nw_dst " : < ip do destino > ,
8 " dl_type " : 2048 ,
9 " nw_proto " : < id do protocolo >
10 },
11 " actions " :[
A.3. Caso 3 - Destino do salto é o destino do tráfego 117
12 {
14 " dl_dst " : < identificador do salto atual >
15 },
16 {
17 " type " : " OUTPUT " ,
19 }
20 ]
21 },
22 {
24 " priority " : < id flow + 101 > ,
25 " match " :{
27 },
28 " actions " :[
29 {
30 " type " : " OUTPUT " ,
32 }
33 ]
34 }
35 }
A.3 Caso 3 - Destino do salto é o destino do tráfego

Quando o destino do salto também é a VM de destino do tráfego, é preciso restaurar
o MAC de destino do pacote para o MAC da VM de destino. Uma vez que utiliza-se este
campo para a identificação do salto.
Mais uma vez há duas abordagens para este cenário. Quando as duas máquinas do
salto são alocadas no mesmo hospedeiro (Figura 49-a), apenas uma regra é instalada no
switch virtual. Esta regra (Código 48) verifica se a porta de ingresso no switch corresponde
a VM de origem do salto e se o MAC de destino é o identificador da rota anterior. Se este
for o caso, o pacote tem o MAC de destino restaurado e então é encaminhado a porta da
VM de destino.
1 {
3 " priority " : < id flow + 101 > ,
4 " match " :{
6 " in_port " : < porta da VM de origem do salto >
Figura 49 – Caso 3 na qual o destino do salto é o destino do tráfego. a) no mesmo

hospedeiro b) hospedeiros diferentes.
7 },
8 " actions " :[
9 {
11 " dl_dst " : < MAC VM de destino >
12 },
13 {
14 " type " : " OUTPUT " ,
15 " port " : < porta da VM de destino >
16 }
17 ]
18 }
Quando em hospedeiros diferentes (Figura 49-b), são elaboradas duas regras (Có-
digo 49). A regra que classifica o tráfego da máquina de origem do salto verifica se o fluxo
tem origem na porta da máquina de origem do salto e se o MAC de destino corresponde
ao ID da salto anterior. Quando o pacote é capturado pela regra, o MAC de destino é
reescrito com o identificador do salto atual e segue o fluxo normal.
1 {
2 {
4 " priority " : < id flow + 101 > ,
5 " match " :{
6 " dl_dst " : < identificador do salto anterior > ,
8 },
9 " actions " :[
A.3. Caso 3 - Destino do salto é o destino do tráfego 119
10 {
11 " type " : " OUTPUT " ,
13 }
14 ]
15 },
16 {
18 " priority " : < id flow + 101 > ,
19 " match " :{
21 },
22 " actions " :[
23 {
25 " dl_dst " : < MAC VM de destino >
26 },
27 {
28 " type " : " OUTPUT " ,
29 " port " : < porta da VM de destino >
30 }
31 ]
32 }
33 }
Ao chegar ao hospedeiro da máquina virtual de destino, a regra instalada verificará

se o MAC de destino corresponde ao identificador do salto atual. Em caso positivo, o MAC
de destino é reescrito com o MAC da máquina virtual de destino e então é encaminhado a
porta da VM destino.
121
APÊNDICE B – Regras instaladas para a

realização do SFC nos cenários de testes
É necessária a instalação de diversas regras para a realização do encaminhamento de

tráfego. Estas regras são baseadas em informações topológicas que precisam ser gerenciadas
pelo orquestrador. Na Seção B.1 explica-se os campos utilizados para classificação e
redirecionamento do pacote e nas Seções B.2 a B.6 são dadas partes das informações
utilizadas para a construções das regras e as próprias regras utilizadas nos cinco cenários
de testes propostos.
B.1 Campos das regras instaladas
Para a realização do encadeamento de tráfego necessário para estes testes, são

instaladas algumas regras nos switches virtuais. É preciso ter conhecimento do significado
de cada campo para ter compreensão do que as regras fazem. Como já foi explicado na
Seção 2.2.1, uma regra é composta de um classificador e uma ação para os pacotes em
conformidade com a classificação. Na Tabela 9 são explicadas as regras de match utilizadas
para classificar o fluxo e na Tabela 10 são descritas as regras utilizadas para realização do
encaminhamento do fluxo.
Tabela 9 – Campos utilizados na regras para classificação do fluxo.

Classificador Descrição Exemplo
in_port Porta de Entrada no {"in_port": 7}
switch (int)
dl_dst Endereço de destino {"dl_dst": "aa:bb:cc:11:22:33"}
Ethernet (string)
nw_proto Especificação do pro- {"nw_proto": 5, "dl_type": 2048}
tocolo
nw_src Endereço IPv4 de {"nw_src": "192.168.0.1", "dl_type": 2048}
origem (string)
nw_dst Endereço IPv4 de {"nw_dst": "192.168.0.1/24", "dl_type": 2048}
destino (string)
tp_dst Porta de destino {"tp_dst": 2, "nw_proto": 6, "dl_type": 2048}
TCP/UDP (int)
122 APÊNDICE B. Regras instaladas para a realização do SFC nos cenários de testes
Tabela 10 – Campos utilizados na regras para ações nos pacotes.

Ação Descrição Exemplo
STRIP_VLAN Remove cabeçalho {"type": "STRIP_VLAN"}
802.1Q
SET_DL_DST Modifica o endereço {"type": "SET_DL_DST",
de destino Ethernet "dl_dst": "aa:bb:cc:11:22"}
OUTPUT Envia o pacote para {"type": "OUTPUT", "port": 3}
a porta
B.2 Cenário 1
Após provisionadas, obtém-se os seguintes dados sobre as VNFIs, dados na Tabela
11. Estas informações serão usadas para a construção das regras para o Cenário 1.
Tabela 11 – Informações do posicionamento das VNFIs Cenário 1

id vnfd host node name MAC IP openflow
id id instance port
1 1 6 0 sff4 00:00:00:03:61:81 10.0.101.24 4
2 1 5 0 sff2 00:00:00:02:2c:6d 10.0.101.22 4
As regras que realizam o encadeamento do tráfego UDP destino a porta 5000 da

máquina destino passando pelas máquinas virtuais SRC -> SFF2-> SFF4 -> DST são
dadas na Tabela 12.
B.2. Cenário 1 123
Tabela 12 – Regras instaladas para implementação do SFC no Cenário 1

Regra Nó Match Action
1 NFV-000 {nw_proto: 17, tp_dst: 5000, [{type: SET_DL_DST,
nw_src: 10.0.101.17, dl_type: dl_dst: 90:00:00:19:00:00},
2048} {port: 65530, type: OUTPUT}
2 NFV-000 {nw_proto: 1, nw_src: [{type: SET_DL_DST,
10.0.101.17, dl_type: 2048} dl_dst: 90:00:00:19:00:00},
{port: 65530, type: OUTPUT}
3 NFV-010 {dl_dst: 90:00:00:19:00:00} [{type: STRIP_VLAN}, {port:
4, type: OUTPUT}
4 NFV-010 {in_port: 4, dl_dst: [{type: SET_DL_DST,
90:00:00:19:00:00} dl_dst: 90:00:00:15:00:00},
4, type: OUTPUT}
6 NFV-011 {in_port: 4, dl_dst: [{type: SET_DL_DST,
90:00:00:15:00:00} dl_dst: 90:00:00:60:00:00},
7 NFV-001 {dl_dst: 90:00:00:60:00:00} [{type: STRIP_VLAN},
{type: SET_DL_DST, dl_dst:
00:00:00:01:d6:c7}, {port: 4,
type: OUTPUT}
B.3 Cenário 2

id id instance port
1 1 5 0 sff2 00:00:00:02:a8:7d 10.0.101.22 4

máquina destino passando pelas máquinas virtuais SRC -> SFF2-> DST são dadas na
Tabela 14.

1 NFV-000 {nw_proto: 17, tp_dst: 5000, [{type: SET_DL_DST,
dl_type: 2048, nw_src: dl_dst: 90:00:07:12:00:00},
10.0.101.15} {port: 3, type: OUTPUT}]
2 NFV-000 {nw_proto: 1, dl_type: 2048, [{type: SET_DL_DST,
nw_src: 10.0.101.15} dl_dst: 90:00:07:12:00:00},
{port: 3, type: OUTPUT}]
4, type: OUTPUT}]
4 NFV-010 {dl_dst: 90:00:07:12:00:00, [{type: SET_DL_DST,
in_port: 4} dl_dst: 90:00:01:38:00:00},
{port: 3, type: OUTPUT}]
00:00:00:00:d1:d4}, {port: 4,
type: OUTPUT}]
B.4. Cenário 3 125
B.4 Cenário 3

id id instance port
1 1 3 0 sff1 00:00:00:00:18:5b 10.0.101.21 5

máquina destino passando pelas máquinas virtuais SRC -> SFF1 -> DST são dadas na
Tabela 16.

1 NFV-000 {tp_dst: 5000, dl_type: 2048, [{dl_dst: 90:0A:0B:0C:00:00,
nw_dst: 10.0.101.15, nw_src: type: SET_DL_DST}, {port:
10.0.101.17, nw_proto: 17} 5, type: OUTPUT}]
2 NFV-000 {nw_dst: 10.0.101.15, [{type: STRIP_VLAN},
nw_proto: 1, nw_src: {dl_dst: 90:0A:0B:0C:00:00,
10.0.101.17, dl_type: 2048} type: SET_DL_DST}, {port:
5, type: OUTPUT}]
3 NFV-000 {nw_dst: 10.0.101.15, tp_dst: [{dl_dst: 90:00:64:5d:00:00,
5000, in_port: 5, dl_type: type: SET_DL_DST}, {port:
2048, nw_src: 10.0.101.17, 3, type: OUTPUT}]
nw_proto: 17}
4 NFV-000 {nw_dst: 10.0.101.15, dl_type: [{dl_dst: 90:00:64:5d:00:00,
2048, in_port: 5, nw_src: type: SET_DL_DST}, {port:
10.0.101.17, nw_proto: 1} 3, type: OUTPUT}]
5 NFV-001 {dl_dst: 90:00:64:5d:00:00} [{type: STRIP_VLAN},
{dl_dst: 00:00:00:01:dd:e8,
type: SET_DL_DST}, {port:
4, type: OUTPUT}]
B.5 Cenário 4

id id instance port
1 1 4 0 sff5 00:00:00:01:51:6b 192.168.1.25 5

máquina destino passando pelas máquinas virtuais SRC -> SFF5 -> DST são dadas na
Tabela 18.

1 NFV-000 {nw_proto: 17, nw_src: [{dl_dst: 90:00:4f:70:00:00,
10.0.101.17, dl_type: 2048, type: SET_DL_DST}, {type:
tp_dst: 5000, nw_dst: OUTPUT, port: 3}]
10.0.101.15}
2 NFV-000 {nw_proto: 1, nw_src: [{dl_dst: 90:00:4f:70:00:00,
10.0.101.17, dl_type: 2048, type: SET_DL_DST}, {type:
nw_dst: 10.0.101.15} OUTPUT, port: 3}]
3 NFV-001 {dl_dst: 90:00:4f:70:00:00} [{type: STRIP_VLAN},
{type: OUTPUT, port: 5}]
4 NFV-001 {dl_dst: 90:00:4f:70:00:00, [{dl_dst: 00:00:00:01:d7:d4,
in_port: 5} type: SET_DL_DST}, {type:
OUTPUT, port: 4}]
B.6. Cenário 5 127
B.6 Cenário 5

id id instance port
1 1 5 1 sff3 00:00:00:02:a4:fb 10.0.101.23 4
2 1 5 0 sff2 00:00:00:02:1a:c1" 10.0.101.22 5

máquina destino passando pelas máquinas virtuais SRC -> SFF2 -> SFF3 -> DST são
dadas na Tabela 20.

1 NFV-000 {dl_type: 2048, nw_dst: [{type: SET_DL_DST,
10.0.101.15, nw_proto: 17, dl_dst: 90:00:00:2a:00:00},
nw_src: 10.0.101.17, tp_dst: {type: OUTPUT, port: 3}]
5000}
2 NFV-000 {dl_type: 2048, nw_dst: [{type: SET_DL_DST,
10.0.101.15, nw_proto: 1, dl_dst: 90:00:00:2a:00:00},
nw_src: 10.0.101.17} {type: OUTPUT, port: 3}]
3 NFV-010 {dl_dst: 90:00:00:2a:00:00} [{type: STRIP_VLAN},
4 NFV-010 {dl_dst: 90:00:00:2a:00:00, [{type: STRIP_VLAN},
in_port: 5} {type: OUTPUT, port: 4}]
5 NFV-010 {dl_dst: 90:00:00:2a:00:00, [{type: SET_DL_DST,
in_port: 4} dl_dst: 90:00:05:67:00:00},
00:00:00:01:17:ff}, {type:
OUTPUT, port: 4}]

Orquestração de Funções de Rede Virtualizadas em Data Center Centrados em Servidores

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Orquestração de Funções de Rede Virtualizadas em Data Center Centrados em Servidores

Transféré par

Droits d'auteur :

Formats disponibles

Rodolfo Vieira Valentim

Orquestração de Funções de Rede Virtualizadas

Orquestração de Funções de Rede Virtualizadas em Data

Projeto de Graduação apresentado ao De-

Universidade Federal do Espírito Santo

Orientador: Prof. Msc. Cristina Dominicini

Se cheguei até aqui foi porque

O encadeamento do tráfego é feito por meio da instalação de regras em um switch OpenFlow

Palavras-chave: NFV, Orquestrador, VNF, SDN, Open vSwitch, Otimizador, OpenStack,

Figura 1 – Visão da substituição de equipamento específico por funções de rede

Código 1 – JSON descritor de hospedeiro . . . . . . . . . . . . . . . . . . . . . . . 66

Tabela 1 – Responsabilidades de cada bloco funcional do bloco NFV MANO adap-

IoT Internet das coisas, do inglês Internet of Things

CAPEX Gastos de capital, do inglês Capital Expenditure

OPEX Gastos operacionais, do inglês Operational Expenditure

NFV Virtualização de Funções de Rede, do inglês Network Functions Virtua-

NAT Tradução de Endereço de Rede, do inglês Network Address Translation

SDN Rede Definidas por Software, do inglês Software Defined Networks

TSP Provedor de Serviços de Rede, do inglês Telecommunication Service

VIM Gerenciador de Infraestrutura Virtualizada prevista no ETSI Framework,

SFC Encadeamento de Funções de Serviço, do inglês Service Function Chai-

NFV MANO Gerenciamento e Orquestração de Funções de Rede Virtualizadas, do

VNFI Instância de Função de Rede Virtual, do inglês Virtual Network Function

APÊNDICE A – REGRAS PARA ENCADEAMENTO EM DIFE-

APÊNDICE B – REGRAS INSTALADAS PARA A REALIZAÇÃO

As estruturas das redes tradicionais são baseadas em hardware proprietário e de uso

1.1 Motivação e Justificativa

do VirtPhy, segundo o padrão NFV da European Telecommunications Standards Institute

1. Criar uma interface de comunicação que gerencia as requisições de serviço;

2. Automatizar a coleta de informações sobre infraestrutura de rede e computação em

3. Criar uma interface de comunicação com o módulo de otimização que envia as

4. Automatizar a criação de instâncias de VNFs com base no resultado do processo de

5. Automatizar o encadeamento de VNFs com base no resultado do processo de otimi-

1.3 Estrutura do Texto

Os conceitos apresentados a seguir são necessários para a melhor compreensão do

2.1 Funções de rede virtualizadas

2.1.1 Arquitetura de rede tradicional

2.1.2 Virtualização de funções de rede

al., 2016) estendendo o conceito de virtualização de recursos, tecnologia que já encontra-se

Figura 1 – Visão da substituição de equipamento específico por funções de rede baseadas

2.1.3 Arquitetura NFV

• Separação total entre hardware e software;

• Implantação automatizada e escalável das funções de rede;

Figura 2 – Representação em alto nível da arquitetura proposta pela ETSI. Elaborada

Os três componentes principais tem funções bem definidas em (ETSI, 2013):

• Funções de Rede Virtualizadas - VNFs, define como a implementação de

• Infraestrutura NFV - NFVI, inclui a diversidade de recursos físicos e como estes

• Gerenciamento e orquestração NFV - NFV MANO, cobre o gerenciamento

2.1.4 Detalhes do bloco funcional NFV MANO

Figura 3 – Detalhamento do bloco NFV MANO. Elaborada pelo autor.

• NVFI Recursos: Contém informações sobre os recursos NFVI disponíveis/reserva-

• Instâncias NFV: Contém informações de todas as instâncias de função de redes

• Catálogo de Serviços NFV: Representa o repositório de todos os Serviços de

Tabela 1 – Responsabilidades de cada bloco funcional do bloco NFV MANO adaptado de

• Trabalhando com outros blocos para orquestrar a rede e mantendo

• Mantém registro da alocação de recursos virtualizados;

• Interagir e gerenciar o hypervisor;

• Mantém registro da utilização hardware e estados;

• Trabalho com outros blocos funcionais para implementar a conexão

Repositório de dados MANO

• Catálogo VNF: repositório com todas as VNFs suportadas.

2.2 Redes definidas por software

2. Um canal seguro entre o switch e o controlador permitindo o tráfego de pacotes e

3. E o protocolo OpenFlow em si que contém o ferramental habilitador para comunicação