Universidade Federal Fluminense
Escola de Engenharia
Curso de Graduação em Engenharia de
Telecomunicações
Lucas Mendes Barboza
Aprovisionamento de banda sob demanda usando
redes definidas por software
Niterói – RJ
2019
1 Lucas Mendes Barboza
Aprovisionamento de banda sobre demanda usando redes definidas por software
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia de Teleco-municações da Universidade Federal Fluminense, como requisito parcial para obtenção do Grau de Engenheiro de Telecomunicações.
Orientador: Prof. Dra. Natália Castro Fernandes
Niterói – RJ 2019
ii .
iii Lucas Mendes Barboza
Aprovisionamento de banda sob demanda usando redes definidas por software
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia de Teleco-municações da Universidade Federal Fluminense, como requisito parcial para obtenção do Grau de Engenheiro de Telecomunicações.
Aprovada em 25 de Novembro de 2019.
BANCA EXAMINADORA
Prof. Dra. Natália Castro Fernandes - Orientador Universidade Federal Fluminese - UFF
Prof. René Pestre Filho
Universidade Federal Fluminese - UFF
Prof. Dr. Ricardo Campanha Carrano Universidade Federal Fluminese - UFF
Niterói – RJ 2019
iv
Resumo
O número de usuários e aplicações que fazem uso das redes de computadores vem crescendo e, em consequência, o número de dispositivos conectados também, tornando a tarefa de construir e manter essas redes cada vez mais difícil. Por sua vez, cada cliente tem necessidades específicas, as quais são difíceis de atender com um único tipo de serviço de acesso à Internet. Alguns clientes necessitam de mais ou menos banda do que a ofertada, levando ao super aprovisionamento ou, então, a má qualidade do serviço.
Para outros clientes, essa necessidade pode variar ao longo do dia, mês ou ano, sendo necessário uma modalidade de contratação que permita a variação da taxa de transmissão sobre demanda. Se do ponto de vista do usuário esse serviço é o ideal, para os Internet Service Provider (ISP) é um desafio. Dessa forma, seria necessário modificar a configuração dos equipamentos de rede com frequência. Em um cenário tradicional esse tipo de rotina não é recomendado por diversos motivos.
O surgimento das Software Defined Network (SDN) trouxe uma nova perspectiva sobre essa questão. As SDN tornam mais fácil a configuração e o gerenciamento das redes através de um plano de controle que centraliza a inteligência das mesmas.
Neste trabalho foi desenvolvida uma aplicação em redes definidas por software, com o foco em ISPs, que visa facilitar a interação entre o usuário e o provedor, permitindo o aprovisionamento de banda sobre demanda por parte do usuário.
Para tornar simples a interação entre usuário e a rede foi proposta e desenvolvida uma aplicação Web, que torna automática e transparente qualquer configuração de rede necessária para ajustes sob demanda de banda para clientes do provedor de serviço. Do ponto de vista da rede, foi desenvolvido uma aplicação SDN para controlador RYU que faz uso das tabelas de meter para controlar a banda do usuário, além de uma interface REST que permite a troca de informações entre a plataforma Web e controlador de rede. Palavras-chave: Redes defindas por Software, Aprovisionamento de Banda, RYU.
v
Abstract
The number of users and applications that make use of computers is growing, and as a result, the number of connected devices, creating a design task and keeping these networks ever more difficult. In turn, each customer has specific requirements and which are difficult to meet with a single type of Internet access service. Some customers use more or less service bandwidth, leading to over-provisioning or poor service quality.
For other customers, this need may vary throughout the day, month, or year. It is necessary a form of contracting that allows a variation of the transmission rates on the demand. You see the user point of view that is the ideal service for ISPs is a challenge. This would require changing the configuration of network equipment frequently in a traditional setting that is not recommended for a variety of reasons.
The emergence of SDN has brought a new perspective on this issue. Like SDN, network configuration and management is made easier through a control plan that cen-tralizes network intelligence.
In this work, an application in software-applied networks, focusing on ISPs, was developed, which facilitates the interaction between users and providers, allowing the provision of bandwidth on demand by the user.
To make user-network interaction simple, a Web application has been proposed and developed that automatically and transparently makes any network configuration required for bandwidth on-demand adjustments to service provider customers. From a network standpoint, an SDN application for the RYU driver was developed, which uses meter tables to control a user’s bandwidth, as well as a REST interface that allows information exchange between the web platform and the network control
vi
A minha avó Dona Vera. Vó, você vai ser sempre a mulher da minha vida.
vii
Agradecimentos
Muitas pessoas contribuíram para que eu chegasse até aqui, mas se não citasse algumas, em particular, essa seção não teria sentido. Em primeiro lugar, agradeço aos meus pais, Joana e Clovis. Gostaria de agradecer também a minha esposa Camila e aos meus colegas de curso, Caroline Portela, Vitor Martins, Orlando Marques, Raiane Lima, que sempre me ajudaram nos momentos difíceis. Minha gratidão, em especial, a minha avó, Dona Vera, por tudo. Por último, agradeço a minha orientadora, Professora Doutora Natália Castro Fernandes.
Lista de Figuras
2.1 Arquitetura SDN baseado em [1]. . . 5
2.2 Processo de matching em um switch OpenFlow versão 1.3 baseado em [12] 8 2.3 Principais Mensagens do protocolo OpenFlow baseado em [12]. . . 9
2.4 Visão geral das funcionalidades do RYU baseado em [8]. . . 10
3.1 Arquitetura da aplicação. . . 14
3.2 Fluxograma da aplicação. . . 15
3.3 Página de Boas Vindas. . . 15
3.4 Página de Login. . . 16
3.5 Página de Cadastro. . . 16
3.6 Portal de Administração. . . 17
3.7 Portal de Usuário. . . 17
3.8 Amostra do código da aplicação. . . 20
3.9 Amostra do código instalação de meter. . . 21
3.10 Pipeline de tabelas. . . 21
3.11 Inserção de fluxo. . . 22
3.12 Funcionamento dos meter s no controle de banda. . . 22
4.1 Funcionamento do Mininet [9]. . . 25
4.2 Topologia do ambiente de testes. . . 26
4.3 Gráficos testes de carga computacional. . . 27
4.4 Topologias Mininet. . . 28
4.5 Análise perda de pacotes na topologia linear. . . 29
4.6 Amostra do código usado para os testes. . . 30
4.7 Entradas de meter para os switches da rede. . . 31
4.8 Fluxo de dados Iperf. . . 31
ix
4.9 Análise taxa de transmissão do host-1. . . 32
4.10 Comparação entre banda contratada pelo host-1 e a banda entregue. . . 33
4.11 Tabela de fluxo - cenário inicial. . . 33
4.12 Usuários cadastrados inicialmente. . . 34
4.13 Tabela de fluxo após a inserção dos usuários. . . 34
4.14 Lista de usuários após a inserção. . . 35
4.15 Tabela de fluxo do switch. . . 36
4.16 Comparação entre o número de fluxos instalados na aplicação desenvolvida e aplicação simple_switch . . . 37
4.17 Topologia do Teste de carga. . . 37
4.18 Comparação entre banda entregue e contratada em um cenário com multi-plos usuários. . . 38
x
Lista de Tabelas
3.1 Tabela de usuários. . . 18 3.2 Tabela de switch. . . 19 3.3 Tabela de regras. . . 19 3.4 Tabela de templates. . . 19xi QoS Quality of Service
SDN Software Defined Network BoD Bandwidth of Demand ISP Internet Service Provider
API Application Programming Interface ONF Open Network Foudantion
CPqD Centro de Pesquisa e Desenvolvimento em Telecomunicações WSGI Web Server Gateway Interface
Conteúdo
Resumo iv Abstract v Agradecimentos vii Lista de Figuras ix Lista de Tabelas x Acrónimos xi 1 Introdução 1 1.0.1 Motivação . . . 1 1.1 Objetivos . . . 2 1.2 Contribuições . . . 2 1.3 Organização do Trabalho . . . 32 Redes definidas por software 4 2.0.1 Arquitetura SDN . . . 5 2.1 Protocolo OpenFlow . . . 6 2.1.1 Tabela de Fluxos . . . 7 2.1.2 Canal Seguro . . . 8 2.2 Meter . . . 9 2.3 Controlador Ryu . . . 9 2.4 API REST . . . 10 2.5 Framework Web . . . 12 2.5.1 Flask . . . 12 xii
xiii 3 Proposta do trabalho 13 3.1 Arquitetura da Aplicação . . . 13 3.1.1 Servidor Web . . . 14 3.1.2 Interface Web . . . 15 3.1.3 Banco de dados . . . 18 3.1.4 Aplicação SDN . . . 20
4 Avaliação da Plataforma Proposta 23 4.1 Objetivos dos testes . . . 23
4.2 Ambientes de testes . . . 23
4.2.1 Ambiente Físico e virtualização . . . 23
4.2.2 Implementação do Switch OpenFlow . . . 24
4.2.3 Emulador Mininet . . . 24
4.2.4 Topologia dos testes . . . 26
4.3 Testes e resultados . . . 26
4.3.1 Teste de carga computacional . . . 26
4.3.2 Teste da plataforma . . . 29
4.3.3 Número de entradas de Fluxo . . . 35
4.3.4 Teste com múltiplos usuários . . . 37 5 Conclusão e Trabalhos Futuros 39
Capítulo 1
Introdução
O número de usuários e aplicações que exigem acesso à Internet vem crescendo nos últimos anos. Com isso, a complexidade das redes de computadores vem aumentando, seja no número de dispositivos ou na quantidade de regras de Quality of Service (QoS). Nesse contexto, cada nova aplicação tem sua particularidade. Por exemplo, no começo dos anos 2000, tivemos o surgimento das redes Peer-to-Peer [14], nos anos seguintes, as plataformas de streaming [14] e, no cenário atual, diversas aplicações como games de realidade virtual que exigem cada vez mais banda.
Se do ponto vista das tecnologias de acesso é possível chegar em taxas de dados cada vez maiores usando tecnologias baseadas em transmissão via fibra, manter e configurar essas redes não é uma tarefa tão simples.
1.0.1
Motivação
No contexto dos ISP, ao mesmo tempo que se tem redes cada vez mais complexas, a popu-lação de usuários é cada vez mais heterogênea. Cada grupo de usuários têm necessidades diferentes dos outros [4] [2]. Assim, uma das principais dificuldades de um ISP é criar planos apropriados para todos os seus clientes, ao passo que evolui o seu núcleo para dar suporte a todos os planos oferecidos.
Um exemplo são os condomínios. Muitos deles oferecem acesso à Internet incluso na taxa de condomínio. Contratar o plano ideal para um conjunto de usuários é uma tarefa difícil. Além do mais, o número de usuários pode variar com o tempo. Outro exemplo são os centros de conveções. Na maior parte do tempo, a banda necessária não passa de alguns megabits por segundo, enquanto durante um evento essa necessidade
2 aumenta exponencialmente.
Já outros clientes, como universidades e corporações, precisam de aprovisionamento rápido. Suas demandas podem variar não apenas pelo número de usuários, mas também pelo tipo de aplicação que é consumida. Centros de pesquisas e data center corporativos podem precisar de taxas altas, enquanto os escritórios não têm tal demanda.
A possibilidade de controlar a banda contratada de acordo com a necessidade é interessante para uma variedade de usuários. Alguns trabalhos acadêmicos propõem soluções diferentes para esse problema, como em [17] e [11]. Com isso, é possível reduzir os custos, ao mesmo tempo em que se preza pela qualidade do serviço entregue ao usuário.
1.1
Objetivos
Do ponto de vista do ISPs o aprovisionamento sob demanda se mostra um desafio, pois para modificar um único serviço muitas vezes é necessário reconfigurar muitos dispositivos. Ocasionalmente, erros de configuração podem levar à indisponibilidade da rede ou parte dela. Além disso, é necessário um investimento em atendimento ao cliente, contratando serviços de Call Center.
Com as Software Defined Network (SDN) configurar e gerenciar equipamentos se torna uma tarefa mais simples. Via plano de controle é possível configurar diversos equipa-mentos de forma centralizada, evitando erros de configuração. As SDN também permitem uma interação de aplicações via programabilidade possibilitando o uso de bancos de dados e plataformas Web [17].
Esse trabalho tem como objetivo desenvolver uma aplicação SDN para aprovisio-namento de banda sob demanda de forma automática. Será desenvolvido uma plataforma self-service, onde o usuário a qualquer momento poderá solicitar uma alteração no serviço contratado.
1.2
Contribuições
Visando atender ao maior número de usuários possível, neste trabalho, é desenvolvida uma plataforma que permite a mudança da banda contratada a qualquer momento. Isso pode ser feito de forma automática, sem necessidade do envolvimento de nenhum membro do corpo técnico do ISP.
3
1.3
Organização do Trabalho
Esse trabalho é constituído de cinco capítulos. O primeiro capítulo traz a introdução, motivação e organização.
O Capítulo 2 apresenta uma introdução teórica sobre as rede definidas por software. Explica-se brevemente o protocolo OpenFlow, dando foco em conceitos como tabela de fluxos e tabela de meter. Também é discutido o processo de Matching.
O Capítulo 3 apresenta a aplicação desenvolvida, mostrando em detalhes cada um de seus módulos e componentes. Já o Capítulo 4 traz uma avaliação da aplicação por meio de testes e os resultados obtidos são discutidos.
Por fim, o Capítulo 5 apresenta as conclusões sobre o trabalho, assim como algumas sugestões sobre pesquisas futuras.
Capítulo 2
Redes definidas por software
Redes definidas por software ou, no inglês, Software Defined Network (SDN), é uma tecnologia que se tornou popular nos últimos anos por se aplicar a diversas áreas das redes de computadores, tais como, data centers, backbones e backhauls de operadoras. Essa abordagem tem como objetivo resolver alguns problemas das redes tradicionais, possibilitando maior automação da rede, maior resiliência e adaptabilidade a cenários que exigem mudanças constantes. Em suma, as SDNs simplificam e automatizam a gerência das redes de grande porte e grande complexidade. O conceito de SDN, como é conhecido hoje, surgiu na Universidade de Stanford, Califórnia (US) [7]. A abordagem se baseia na separação das funções de rede em dois planos: plano de controle e plano de dados. Um responsável por toda inteligência da rede e outro, mais simples, cuja a função é o encaminhamento de pacotes. A seguir pode-se ver uma definição mais detalhada desses dois planos.
• Plano de Controle: É responsável pelas tomadas de decisão, ou seja, define as re-gras que serão seguidas pelos equipamentos que fazem o encaminhamento. Como é baseado em software desenvolvido para computadores de uso geral, facilita o de-senvolvimento de novos protocolos ou aplicações para redes de computadores [7]. Opõe-se, nesse sentido, aos planos de controle dos equipamentos tradicionais , que desenvolvidos sob a plataforma de hardware do roteador ou comutador, o que torna mais difícil o desenvolvimento de novas aplicações de controle.
• Plano de Dados: É responsável pela entrega dos dados aos seus destinatários, fa-zendo apenas a comutação de pacotes de acordo com regras pré-estabelecidas.
5 Nas redes tradicionais as funções de rede estão integradas em um mesmo equipa-mento. Esse equipamento é responsável tanto por encaminhar quanto tomar as decisões sobre encaminhamento. A integração, por exemplo, torna tarefas como implementar no-vos protocolos mais difíceis devido a problemas de compatibilidade, exigindo trocas no software ou hardware ou as vezes do equipamento inteiro [7].
2.0.1
Arquitetura SDN
Motivados pelos benefícios que as redes definidas por software poderiam trazer para os seus negócios, empresas como Google, Facebook e outras se uniram para fundar a Open Network Foundation (ONF) [7]. A ONF tem como objetivo difundir as redes definidas por software na indústria, sendo responsável por criar e manter padrões de arquitetura e protocolos, como o OpenFlow.
Figura 2.1: Arquitetura SDN baseado em [1].
Nesse trabalho, utilizou-se a arquitetura de referência da ONF para redes SDN, Figura 2.1. Ela se baseia em um modelo de três camadas: Camada de infraestrutura, Camada de controle e Camada de Aplicação [1].
• Camada de Infraestrutura: Essa camada é composta pelos equipamentos respon-sáveis pelo encaminhamento de pacotes. Em redes tradicionais, existem diversos
6 tipos de dispositivos, cada um com sua função específica na rede, como Firewalls, IPS e roteadores. Já em redes definidas por software, é possível ter um único tipo de equipamento, pois todas as decisões de encaminhamento são tomadas pelo plano de controle. Para que isso funcione bem, é necessária uma interface que permita a comunicação entre a camada de infraestrutura e a de controle. Essa interface recebe o nome de southbound. Dentre os protocolos disponíveis para fazer comunicação via southbound, o OpenFlow é o mais utilizado [1].
• Camada de Controle: Nessa camada, é onde reside a inteligência da rede e são tomadas as decisões de encaminhamento. Em redes tradicionais, cada equipamento roda um sistema operacional especializado para a função destinada ao mesmo. Já em SDN, o controle é feito de forma centralizada, ou seja, existe um único sistema operacional para toda a rede. Às vezes, esse sistema operacional é chamado de controlador de rede [1].
• Camada de Aplicação: Nesta camada, encontram-se as aplicações de rede, que são códigos interpretados pelo controlador, os quais definem as regras que serão seguidas para o encaminhamento de pacotes. Entre essa camada e a camada de controle, existe uma interface software bem definida chamada de interface Northbound [1].
2.1
Protocolo OpenFlow
A arquitetura definida pelas SDN resolve uma série de problemas das redes tradicionais. No entanto, para implementá-las, são necessários protocolos que permitam o interface-amento entre o hardware e software de controle, a chamada interface southbound. É necessário que essa interface seja padrão, tornando possível a comunicação de equipamen-tos de fabricantes diferentes com o mesmo controlador. Existem alguns protocolos que visam desempenhar essa função. Dentre eles, o OpenFlow é o que mais se destaca. Ele desenvolvido na universidade de Stanford. Atualmente é mantido pela Open Network Foundation(ONF), o OpenFlow estabelece um canal seguro permitindo comunicação en-tre os elementos de rede e o controlador, definindo as mensagens e estruturas de dados básicas que os equipamentos devem usar no controle da rede. Os equipamentos que usam o protocolo OpenFlow são chamados de switches OpenFlow.
7 Os switches OpenFlow são compostos basicamente de tabelas de fluxos e um canal seguro para comunicação do elemento de rede com o controlador [12]. As tabelas de fluxos são usadas no encaminhamento dos pacotes. Nelas, residem as ações que devem ser tomadas para um conjunto de pacotes definido como fluxo. Enquanto isso, o canal seguro é usado para gerenciar o elemento de rede e as tabelas de fluxo. Os switches OpenFlow podem ter várias tabelas de fluxos. Os pacotes podem ser movidos de uma para outra de acordo com as regras estabelecidas pelo controlador.
2.1.1
Tabela de Fluxos
Uma tabela de fluxos é composta de diversas entradas de fluxo. Cada entrada é formada por um campo de cabeçalho, contadores, instruções, temporizadores e cookies [12]:
• Campo de cabeçalho: Usado para identificar se um pacote pertence ou não ao fluxo; • Contadores: Medidas relacionadas aos fluxos;
• Instruções: Ações tomadas para determinado fluxo;
• Temporizadores: Determinam o tempo máximo ou tempo de inatividade para que um fluxo expire no switch e seja removido da tabela.
• cookie: Valor definido pelo controlador utilizado para realizar coletas de dados de conjuntos de fluxos e também para mudanças de estado na entrada de fluxo.
Uma vez que o pacote é recebido por um Switch OpenFlow, o equipamento percorre sua tabela de fluxo para identificar a ação que deve ser tomada com relação àquele pacote. Esse processo é chamado matching [12]. Um pacote é identificado a um fluxo caso seus cabeçalhos sejam compatíveis aos do campo de cabeçalho de um entrada de fluxo. Caso o pacote não seja compatível com nenhuma linha da tabela, pode ser enviado para o controlador via canal seguro ou descartado, dependendo da instrução table miss da tabela em questão [12]. A Figura 2.2 mostra o algoritmo completo para processamento de pacotes em um switch OpenFlow versão 1.3.
8
Figura 2.2: Processo de matching em um switch OpenFlow versão 1.3 baseado em [12]
2.1.2
Canal Seguro
O canal seguro é interface que liga o controlador ao switch OpenFlow [12]. Por essa interface, são realizadas todas as funções de controle e consultas do switch ao controlador. O protocolo OpenFlow define as mensagens que são trocadas pelo canal seguro. A Figura 2.3 mostra algumas dessas mensagens. Elas podem ser classificadas de três formas: Síncronas, assíncronas e controlador-para-switch. Esses três tipos, por sua vez, podem ter diversos subtipos [12].
9
Figura 2.3: Principais Mensagens do protocolo OpenFlow baseado em [12].
2.2
Meter
O meter é um componente do switch OpenFlow que pode mensurar e controlar taxas de pacotes [10]. Assim como os fluxos, as entradas de meter estão associadas a uma tabela, a tabela de meters. Cada meter corresponde a um ou mais fluxos, ou seja, com os meters é possível fazer Quality of Service (QoS) baseado em fluxos. Os meters podem ser especificados pelos fluxos através de suas instruções. As entradas desta tabela são [12]:
• Identificador de meter : Identificador de 32 bits usado para identificar o meter. • Bandas de meter : Uma lista não ordenada de bandas, cada qual especificando uma
taxa e o tratamento que cada meter deve dar aos pacotes .
• Contadores: Medidas relacionadas aos pacotes processados pela entrada de meter.
2.3
Controlador Ryu
O Ryu é um framework baseado em componentes que fornece bibliotecas e ferramentas para o desenvolvimento de aplicações em SDN. Uma aplicação SDN é um programa
de-10 senvolvido usando a Application Programming Interface (API) de algum controlador [8]. O Ryu é composto de vários módulos ou funções, que estão listados abaixo com uma breve descrição:
• Função Controlador OpenFlow: Implementação de controlador OpenFlow compatí-vel com as versões 1.0, 1.2, 1.3, 1.4 e 1.5.
• Função para cooperação com redes existentes: Essa função prevê a interoperabi-lidade entre equipamentos OpenFlow e tradicionais, possibilitando coletar dados, implementar configurações e divulgar informações de roteamento de equipamentos OpenFlow e tradicionais .
• Amostras de código: São exemplos de aplicações simples usando as bibliotecas e ferramentas do Ryu para auxiliar no desenvolvimento de aplicações em SDN.
Figura 2.4: Visão geral das funcionalidades do RYU baseado em [8].
2.4
API REST
O Representational State Transfer (REST), é um modelo para implementação de serviços web, que usa métodos HTTP para interagir com serviços web, possibilitando consultas aos recursos disponíveis pela aplicação, alocação dos recursos, modificação, criação e remoção dos mesmos. A seguir uma lista dos métodos HTTP mais utilizados no modelo REST [16]:
11 • POST: Utilizado para criar novos recursos;
• PUT: Utilizado para modificar recursos; • DELETE: Utilizado para apagar recursos.
Chama-se de REST API as interfaces de software que utilizam esse modelo para interação com o usuário e outros softwares. Geralmente, essa interação usa padrões como JavaScript Object Notation (JSON) e Extensible Markup Language (XML) para troca de mensagens via REST.
O OFCTL_REST é uma API REST desenvolvida em Python no Ryu que permite consultar configurações, contadores e instalar configurações em switches OpenFlow. A seguir, é apresentada a lista de métodos dessa API que foram utilizados neste trabalho [13]:
• Lista switches
– Método HTTP: GET
– URL: <Ip controlador>/stats/switches • Adicionar meter
– Método HTTP: POST
– URL: <Ip controlador>/stats/meterentry/add • Adicionar Fluxo
– Método HTTP: POST
– URL: <Ip controlador>/stats/flowentry/add • Modificar meter
– Método HTTP: POST
12
2.5
Framework Web
Frameworks Web são um conjunto de pacotes ou módulos que permitem desenvolvedores escreverem aplicações web ou serviços sem terem que se preocupar com detalhes, como protocolos e gerenciamento de sockets ou processos [5]. Podem ser classificados em dois grupos: full-stack e No full-stack. Os frameworks que disponibilizam todas as abstrações necessárias para uma aplicação web são ditos Full Stack. Já o frameworks que dependem de pacotes auxiliares são ditos no Full stack.
2.5.1
Flask
Flask é um micro framework web ou não full stack, escrito em Python. A premissa principal é a customização. Já o núcleo do framework é bem enxuto, permitindo ao desenvolvedor escolher as extensões que deseja para construir sua própria aplicação. O Flask é baseado em Web Server Gateway Interface (WSGI) [5] e utiliza Jinja2 e Werkzeug. O Werkzeug é o conjunto de ferramentas para servidores WSGI. O Jinja2 é um engine baseado em Python que, entre outras coisas, permite a execução de códigos em Python dentro de páginas HTML.
Capítulo 3
Proposta do trabalho
O número de aplicações que exigem o acesso à Internet vem crescendo nos últimos anos. Nesse cenário, um serviço que é essencial para o usuário hoje, amanhã pode cair em desuso devido ao surgimento de um nova aplicação com novos requisitos de rede, tornando necessária, muitas vezes, uma maior banda. Essa obsolescência acelerada da tecnologia gera dificuldades para usuários e provedores de acesso preverem qual banda atende as necessidades do usuário no ato da contratação.
Esse trabalho propõe e desenvolve uma aplicação baseada em SDN, que tem como objetivo facilitar o aprovisionamento de banda automático pelos usuários, ao mesmo tempo em que reduz os custos associados ao atendimento ao cliente por parte do pro-vedor, sendo possível fornecer automação de configuração de outros critérios de QoS. As seções a apresentam a arquitetura.
3.1
Arquitetura da Aplicação
Em uma rede convencional, com um grande número de equipamentos, inserir e remo-ver configurações pode ser um trabalho árduo, que se torna mais crítico num cenário onde aplicações que exigem recursos da rede surgem a todo tempo. As redes definidas por software emergem como uma solução para esse panorama, por possuírem controle centralizado, sendo muito mais simples propagar configurações.
Nesse trabalho, é desenvolvida uma aplicação com uma interface web, utilizando o micro framework Flask e as APIs do Ryu. A Figura 3.1 mostra os componentes principais da aplicação proposta, sendo eles:
14
Figura 3.1: Arquitetura da aplicação.
• Servidor Web: Responsável por receber as requisições dos usuários, modificar o banco de dados, disparar novas configurações para o controlador e fazer consultas; • Interface Web: Interface entre usuário e a SDN. Seu objetivo é tornar o processo de
requisição de banda o mais simples possível para o usuário;
• Banco de dados: Responsável por armazenar os dados dos usuários, assim como as configurações dos switches OpenFlow;
• Aplicações SDN : O objetivo das aplicações é tratar as mensagens OpenFlow rece-bidas pelo controlador e responder aos switches de acordo com as configurações do usuário;
• Controlador: Responsável por receber e enviar as mensagens OpenFlow.
3.1.1
Servidor Web
O servidor web usado no trabalho é uma versão leve do Web Server Gateway Interface (WSGI) usado no framework Flask. Esse servidor desempenha uma função essencial na aplicação, pois ele é responsável por lidar com as solicitações HTTP dos usuários, assim como fazer requisição HTTP ao controlador e aplicação SDN. A Figura 3.2 mostra um fluxograma com o funcionamento da aplicação.
15
Figura 3.2: Fluxograma da aplicação.
3.1.2
Interface Web
Um dos principais objetivos da aplicação é tornar simples e transparente o processo de alocação automática de banda. Para isso, a interface entre usuário e a rede deve ser o mais amigável possível. Uma interface web possibilita naturalmente essa interação, além de ser simples de manter, usar e customizar, independentemente do dispositivo. Da mesma forma, em [17] mostra uma plataforma Web para facilitar o aprovisionamento de banda. No entanto, em [17] foi usado o framework DyNPAC para controlar a entrega de banda. O controlador usado foi o ONOS em um ambiente híbrido, com equipamentos SDN e não SDN.
A seguir, é apresentada uma breve descrição da interface web desenvolvida: Página de boas vindas: Nessa página há uma breve descrição do projeto. Em sua aba superior, o link para área de login.
16 Login: Nessa página, o usuário deve fazer sua autenticação na plataforma. Após o login, o menu principal, na parte superior, se modifica de acordo com o nível de permissão do usuário. Somente usuários pertencentes ao corpo técnico podem fazer inserção e visuali-zação dos elementos na rede, usuários e templates.
Figura 3.4: Página de Login.
Cadastro: Página restrita aos técnicos, onde é possível cadastrar novos usuários. Para isso, é exigido o endereço IP, o switch no qual ele será conectado e a taxa inicial que o usuário utilizará, podendo ser modificada pelo usuários posteriormente.
Figura 3.5: Página de Cadastro.
Portal de Administração: Nessa página, é possível ver informações dos dispositivos e usuários, inserir e modificar equipamentos e templates. Também é possível ver algumas medidas da rede como tráfego em bytes por porta e disponibilidade do controlador e de outros dispositivos de rede.
17
Figura 3.6: Portal de Administração.
Portal de Usuário: Nessa página, o usuário tem visibilidade de seu histórico de con-tratação de banda e pode requisitar concon-tratação de mais ou menos banda. Caso a banda desejeda exceda o limite definido pelo administrador da rede, para o equipamento onde o usuário está conectado, o usuário recebe uma mensagem informando que a operação não poderá ser realizada.
Figura 3.7: Portal de Usuário.
Interface REST API: Essa interface permite interação com a plataforma para testes simples e também a criação de scripts para automatização. Abaixo, alguns métodos implementados na API.
• /sync/clientes: Usado pela aplicação SDN para carregar as informações de usuário durante a inicialização do controlador.
18 • /sync/meter: Usado pela aplicação SDN para carregar as informações de meter. • /add/user: Permite a inserção de usuário no banco de dados sem a necessidade de
navegar pela interface web.
• /add/rule: Permite a requisição de banda para um usuário sem necessidade de navegar pela interface web.
3.1.3
Banco de dados
Dando suporte a interface Web e ao servidor Web, existe um banco de dados que armazena as informações dos usuários e da rede. Há quatro tabelas no banco de dados: tabela de usuário, tabela de switch, tabela de regras e tabela de template.
1. Tabela de usuário: Nessa tabela, são armazenadas as informações de usuário, que são usadas para identificá-los e endereçar corretamente suas solicitações.
Campos Descrição
Identificador de usuário (id) Identificador numérico de usuário adi-cionado pelo banco de dados que refe-rencia o objeto no banco de dados. Nome de usuário ( username) Nome usado pelo usuário para acessar
a plataforma
Hash da Senha (password) Hash da senha usada pelo usuário para acessar a plataforma.
Identificador de Switch (sw_id) Identificador numérico do switch em que usuário está Conectado.
Endereço IP (ip) Endereço IP do usuário.
Banda Contratada (banda) Banda contratada pelo usuário.
Grupo (grupo) Divide a usuários da plataforma em dois grupos: adm e usu.
Tabela 3.1: Tabela de usuários.
2. Tabela de switch: Identifica todos switches OpenFlow da rede e os seus usuários conectados.
19
Campos Descrição
Identificador de switch (sw_id) Identificador numérico de switch Usuários conectados ( users) Lista de usuários de rede conectados
àquele switch Identificador de template
(tem-plate_id)
Identificador numérico de template usado pelo switch.
Tabela 3.2: Tabela de switch.
3. Tabela de regras: Lista de todas as solicitações feitas pelos usuários;
Campos Descrição
Modificação (post) Banda que o usuário contratou.
Usuário Solicitante (users) Lista de usuários conectados àquele switch.
Marcador de Tempo (timestamp) Identifica o momento em que a solicita-ção foi feita.
Tabela 3.3: Tabela de regras.
4. Tabela de template: Essa lista delimita a banda máxima que um usuário pode ter em um determinado equipamento. Essa tabela é uma abstração na aplicação web, não sendo usada pelos switches para modificar sua configuração.
Campos Descrição
Identificador de template ( tem-plate_id)
Banda que o usuário contratou.
Lista de Switches ( switches ) Lista de switches que utilizam àquele template
Banda Máxima ( bw_mx) Banda máxima do link com a rede. Tabela 3.4: Tabela de templates.
20
3.1.4
Aplicação SDN
Nesse trabalho, foram utilizadas duas aplicações SDN. Essas aplicações serão usadas para o aprovisionamento automático, por meio delas as configurações necessárias para atender as necessidades dos cliente serão instaladas na rede. A primeira aplicação usada, foi desenvolvida usando as APIs do RYU, tem como função instalar os fluxos e entradas de meters que serão utilizados para fazer o encaminhamento dos pacotes gerados pelos usuários. A segunda, a ofctl_Rest, é um de códigos referência do RYU, sua função nesse trabalho é inserir configurações de forma assíncrona na rede. Foram utilizados como referência o código simple_switch_13 [13] e o código de [6]. Nessa seção, será discutido a aplicação desenvolvida. A Figura 3.8 mostra as primeiras linhas do código.
Figura 3.8: Amostra do código da aplicação.
No código desenvolvido há dois dicionários, linhas 37 e 38 da Figura 3.8, que são preenchidos via REST pelo servidor web. O primeiro dicionário tem as informações de cliente como switch, IP e identificador de meter. O segundo tem as informações que serão usadas para iniciar a tabela de meter, ou seja, identificador de meter e as ações associadas a ele. Também pode ser observado que as variáveis globais TABLE FILTER e TABLE FORWARD são iniciadas, linhas 28 e 29 Figura 3.8. Elas são usadas mais a frente para iniciar as tabelas 10 e 20.
21
Figura 3.9: Amostra do código instalação de meter.
No trecho do código mostrado na Figura 3.9, pode-se ver a instalação das carac-terísticas dos switches. As informações do dicionário de meter são usadas instalar os meter s na tabela correspondente, no seu respectivo switch. As linhas 53 a 58 da Figura 3.9, mostram como o dicionário é usado. Nas linhas 60 a 62 pode-se ver a criação de duas novas tabelas: a 10 na linha 61 e 20 na linha 62. Como em [6], é usado um pipeline de tabelas para processamento dos fluxos.
Figura 3.10: Pipeline de tabelas.
A Figura 3.10 mostra o processo de pipeline de tabelas usado nesse trabalho, ele nos permite aplicar instruções sucessivas a conjuntos de pacotes. Todos os pacotes são encaminhados da tabela 0 para a tabela 10. Caso haja correspondência com algum fluxo nessa tabela, os pacotes passam pelo meter associado a esse fluxo e, então, são encaminhados para a Tabela 20, onde são entregues. Nesse ponto, foi usado o dicionário de clientes para criar as entradas de fluxo para cada cliente no seu respectivo switch, usando um match baseado no IP do cliente. Cada cliente é associado a uma entrada de meter. Antes que o tráfego prossiga para a Tabela 20, ele passa pelo respectivo meter. A Figura 3.11 mostra o trecho de código usado para instalar os fluxos usando as infromações
22 recebidas pelo servidor Web.
Figura 3.11: Inserção de fluxo.
Assim como em [6], também é usado o match baseado em IP. Na Figura 3.12, vemos o funcionamento do controle de banda do ponto vista do switch.
Figura 3.12: Funcionamento dos meter s no controle de banda.
A aplicação instala um par de fluxos (entrada e saída) associado ao endereço IP de cada usuário. Uma vez que os pacotes que chegam ou saem do switch são identificados como pertencentes a um desses fluxos, eles são enviados para o meter do usuário. Só é possível o controle de banda de pacotes que saem de uma interface do switch.
Capítulo 4
Avaliação da Plataforma Proposta
4.1
Objetivos dos testes
Neste capítulo serão apresentados testes que têm como objetivo avaliar o desempenho e definir a viabilidade desse projeto. A seção 4.2 deste capítulo descreve o ambiente onde os testes foram realizados tanto físico, quanto o lógico. Na seção 4.3, são descritos os testes realizados, seus objetivos e resultados.
4.2
Ambientes de testes
4.2.1
Ambiente Físico e virtualização
Para a realização dos testes, foi utilizado um notebook para emulação de uma rede, cujas especificações são:
• Notebook Dell Latitude E6230 – Memória RAM: 8 GigaBytes
– Processador: Interl I5vPro 3320M 2.6 Ghz – Núcleos: 2
– Núcleos Lógicos: 4
– Hard Disk: 150 Gigabytes
24 A aplicação e o ambiente de emulação foram executados em máquinas virtuais. Assim, as máquinas virtuais criadas para o teste têm as seguintes configurações:
• Máquina Virtual 1 ( Servidor Web) – Hypervisor: Oracle VirtualBox – Memória RAM: 4 Gigabytes – Núcleos Lógicos: 2
– Hard Disk: 30 Gigabytes
– Sistema Operacional: Ubuntu 18.04 LTS • Máquina Virtual 2(Mininet e Ryu)
– Hypervisor: Oracle VirtualBox – Memória RAM: 2 Gigabytes – Núcleos Lógicos: 2
– Hard Disk: 30 Gigabytes
– Sistema Operacional: Ubuntu 16.04 LTS
4.2.2
Implementação do Switch OpenFlow
Existe uma variedade de implementações de Switch OpenFlow, mas muitas delas não im-plementam o padrão OpenFlow completo. BOFUSS (Basic Open Flow Software Switch) é uma implementação de switch OpenFlow criada pelo Centro de Pesquisa e Desenvol-vimento em Telecomunicações (CPqD), que implementa todo o padrão OpenFlow 1.3, incluindo funcionalidades como a tabela de meters, que é fundamental para essa imple-mentação [3].
4.2.3
Emulador Mininet
O Mininet é um emulador de redes que utiliza virtualização a nível de processo, o que exige menos desempenho da máquina onde é executado, podendo ser utilizado em laptops domésticos. Usando o Mininet, é possível emular uma rede inteira, incluindo enlaces, hosts e switches. Abaixo, estão listadas algumas das vantagens do Mininet [9]:
25 • Agilidade na implementação de ambientes de emulação;
• Flexibilidade para criar diferentes topologias;
• Possibilidade de executar programas naturais de ambientes Linux/Unix;
• Desempenho, o emulador pode ser usado em laptops, máquinas virtuais e servidores. O Mininet também possui uma API em Python que permite automatizar a criação de ambientes de emulação e testes redes [15]. Essa API foi utilizada para o desenvolvi-mento dos testes da aplicação desenvolvida.
Figura 4.1: Funcionamento do Mininet [9].
Abaixo é listado os métodos da API mininet utilizados neste trabalho [15]: • addSwitch() - Adiciona um switch a topologia;
• addHost () - Adiciona um host a topologia; • addLink() - Adiciona um link bidirecional; • start() - Inicia a rede;
• stop() - Para a rede;
• get() - Retorna o host emulado;
26
4.2.4
Topologia dos testes
Pode-se dividir a topologia do teste em duas partes: a topologia de controle e a topologia da rede de dados. A topologia de controle descreve como os elementos de controle da rede (Controlador e Aplicação) se conectam, enquanto a topologia da rede descreve a rede que foi emulada no mininet. No Mininet o trafégo da rede emulada fica restrito aos processos que o Mininet cria durante a emulação, ou seja, há uma separação entre trafégo de dados ou emulado e os de controle. Para a realização dos testes foram utilizadas as topologias fornecidos pelo Mininet.
Figura 4.2: Topologia do ambiente de testes.
4.3
Testes e resultados
O primeiro teste dessa seção tem como objetivo avaliar o ambiente de teste descobrindo suas limitações. O segundo e terceiro testes visam verificar o funcionamento da plata-forma. Já o quarto teste visa verificar o funcionamento da plataforma em um ambiente com múltiplos usuários.
4.3.1
Teste de carga computacional
Nesse primeiro teste, foi avaliada a capacidade do hardware onde a aplicação SDN é executada. O consumo de memória RAM (Figura 4.3.1) e CPU (Figura 4.3.1) é coletado com máquina executando a emulação em topologias diferentes. Essa avaliação de hardware é importante, pois problemas de desempenho do ambiente poderiam prejudicar os dados medidos nos próximos testes, fazendo por exemplo, a taxa de transmissão variar muito. Outro critério usado para avaliar o ambiente de teses foi a perda de pacotes (Figura 4.3.1).
27 Para isso foi usado o comando ping entre os host para cada uma das topologias da Figura 4.4.
Os gráficos descrevem os resultados. Para essa primeira avaliação foi utilizado a aplicação simple_switch_13 descrito em [8], devido a sua confiabilidade. Foi usado um número par de host para possibilitar o ping dois a dois. O desvio padrão para algumas medidas teve um valor muito pequeno e, portanto, não aparece devido à escala.
(a) Perda de pacotes
(b) Consumo de mémoria RAM. (c) Consumo de CPU
Figura 4.3: Gráficos testes de carga computacional.
A partir da análise do gráfico acima, pode-se ver que, para topologia linear, a perda de pacotes é maior do que para outras topologias. Também é possível notar que a perda de pacote cresce na topologia linear a partir desse ponto. Isso ocorre porque o consume de memória cresce, como pode ser visto na Figura 4.3.1. Nesse ponto deve-se fazer uma breve pausa para discutir as topologias do Mininet. Na topologia linear, 4.4(a),
28
(a) Topologia Linear-2 (b) Topologia Tree-2 (c) Topologia Single-2
Figura 4.4: Topologias Mininet.
cada switch está diretamente conectado ao switch mais a direita, o número de hosts por switch pode variar. Na tree, existem camadas que se conectam como em uma árvore, na 4.4(b) temos uma rede de duas camadas. Pode-se definir o número de camadas e hosts da rede. Já na single existe um único switch e o número de hosts varia.
Topologia Hosts Link Switches
Linear 16 31 16
Tree 16 20 5
Single 16 16 1
Tabela 4.1: Características das topologias padrão do Mininet.
Na Tabela 4.3.1, é possível perceber que, para a topologia linear, o número de switches emulados é maior, o que demanda mais recursos da máquina. Para cada host emulado temos um switch. Essa topologia pode ser usada para descobrir a limitação em número de switches do ambiente de emulação. A Figura 4.5 mostra a perda de pacotes na topologia linear em diferentes configurações.
29
Figura 4.5: Análise perda de pacotes na topologia linear.
Como é possível ver, a partir de 11 host, há perda de pacotes. Como na topologia linear há uma razão de 1 switch para cada host, podemos usar o número de hosts para determinar o número máximo de switches. Sabe-se que o processo que emula os switches consomem mais recursos do que os usados para os hosts, de fato o número de switches é um fator limitante na topologia. Então, pode-se dizer que o limite do ambiente de simulação são 10 switches dadas as configurações do hardware e da máquina virtual com o Mininet.
4.3.2
Teste da plataforma
Nesta seção, foi verificado se os componentes da plataforma funcionam de forma satisfa-tória. Primeiro, foi testada a capacidade de controle de banda por usuários já cadastrados e, em seguida, foi analisada a capacidade de aprovisionamento para novos usuários.
Nessa primeira análise, foi verificada a capacidade da plataforma de realizar o controle de banda sob demanda. Para realização desses testes, foi desenvolvido um código em Python usando a API do Mininet. Esse código cria a topologia no Mininet usada nos testes e inicia o iperf. O iperf é uma aplicação disponível para vários sistemas operacionais, muito utilizada para testes em redes de computadores. Com ele, é possível mensurar a banda, o jitter e a latência na comunicação entre dois computadores. A seguir,
apresenta-30 se uma breve descrição sobre os paramêtros do iperf utilizados no código:
• iperf : Inicia o aplicativo iperf.
• c: Indica que o aplicativo irá se conectar a um servidor, ou seja, será cliente. • s: Indica que o aplicativo deverá aceitar conexões, ou seja, atuará como servidor. • u: Indica que o aplicativo deverá usar o protocolo UDP.
• b: Indica que o aplicativo deverá usar a banda indicada.
• t: Indica que o aplicativo deverá permanecer na seção durante o tempo indicado.
31 Assim que o código Python da Figura 4.6 inicia o Mininet e o Iperf, a aplicação SDN começa agir. Ela faz uma consulta ao banco de dados via REST API e cria as entradas de fluxo e meter. Na Figura 4.7, inicialmente, o Host-1 contratou uma banda de 1Mbps e o Host-2 de 10Mbps. Isso pode ser observado olhando as entradas de meter 2, correspondente ao Host-1, e 4, correspondente ao host-2.
Figura 4.7: Entradas de meter para os switches da rede.
A Figura 4.8 mostra o diagrama do fluxo de dados gerado pelo iperf. É esperado que, entre o trafego injetado pelo Host-2 na porta do switch s2, exceda o contratado, porque o meter é aplicado no switch e não no usuário. Todo tráfego excedente o contratado pelo usuário é, então, descartado pelo switch antes do envio para o próximo dispositivo na rede.
Figura 4.8: Fluxo de dados Iperf.
O gráfico da Figura 4.9 mostra a taxa de transmissão do usuário durante o primeiro teste. Nesse caso, o usuário contratou uma banda de 1 Mpbs e o iperf injeta dados a uma taxa de 10 Mbps constante, o que pode ser visto nas últimas linhas do código da Figura 4.6. Observa-se que há uma diferença entre a banda contratada e a entregue. Isso ocorre
32 porque o meter é aplicado sobre o quadro Ethernet, limitando a banda, levando em consideração os cabeçalhos de quadro, pacote e segmento. Já o Iperf usa o payload do segmento para calcular a banda, por isso a diferença.
Figura 4.9: Análise taxa de transmissão do host-1.
A Figura 4.10 mostra a taxa de transmissão do Host-1 em um cenário onde a banda contratada é alterada via interface web.
33
Figura 4.10: Comparação entre banda contratada pelo host-1 e a banda entregue. Asssim, foi possível provar a capacidade da plataforma de aprovisionar banda em redes SDN.
No próximo teste, é avaliada a capacidade da plataforma atuar em ambiente mul-tiusuários. Assim, foi verificada a capacidade da plataforma de inserir as modificações no banco de dados e configurar a rede, simultaneamente. O cenário teste inicial terá 2 Hosts e 1 switch. As Figuras 4.11 e 4.12 mostram o cenário inicial. Nele, não há nenhum usuário cadastrado na plataforma, além do usuário de administração. Em consequência, não há nenhuma entrada específica nas tabelas de fluxo do Mininet.
34
Figura 4.12: Usuários cadastrados inicialmente.
Ao adicionar os usuários referentes aos dois hosts no banco, via plataforma, as regras associadas a eles são inseridas na tabela de fluxo do switch emulada pelo Mininet. Com isso, é provada a capacidade da plataforma atuar sobre a rede emulada pelo Mininet adicionando fluxos. A Figura 4.14 mostra o portal de administração após adição dos dois usuários.
35
Figura 4.14: Lista de usuários após a inserção.
4.3.3
Número de entradas de Fluxo
Nessa seção, é avaliada a quantidade de entradas de fluxo que são adicionados pelo pro-cesso de pipeline de tabelas e comparado com as entradas do simple_switch_13. Para isso, será usado a topologia linear no Mininet. O comando ping será usado para gerar o tráfego responsável pela instalação dos fluxos. Ao final, será comparado o número de fluxos por switch da rede na aplicação desenvolvida neste trabalho com a aplicação sim-ple_switch_13. Essa avaliação é importante, pois há uma limitação na quantidade de entradas de fluxo por tabela. Caso o número de entradas exceda o número máximo, 250 entradas, a aplicação não funcionará.
A Figura 4.15(a) mostra as entradas de fluxo da tabela de um switch com dois hosts, onde está sendo usado a aplicação simple_switch_13. Foi usado o comando ping para gerar tráfego entre os dois hosts. Pode-se ver que o primeiro fluxo corresponde à troca de dados entre o primeiro e o segundo host, partindo do primeiro host. O segundo fluxo corresponde à comunicação entre o primeiro e o segundo host, partindo do segundo host. O terceiro fluxo corresponde à entrada de table Miss Matching, que é a ação tomada caso não se obtenha o matching com nenhuma das entradas fluxo. A Figura 4.15(b) mostra tabela de fluxos para a mesma topologia usando a aplicação desenvolvida neste trabalho.
Como explicado anteriormente, foi utilizado o pipeline de tabelas para fazer o controle de banda dos usuários. Na primeira linha da Figura 4.15(b), pode-se ver a entrada de Miss Matching da tabela zero. Diferentemente da tabela da Figura 4.15(a), a
36
(a) simple_switch_13.
(b) Aplicação desenvolvida.
Figura 4.15: Tabela de fluxo do switch.
ação tomada aqui é o encaminhamento do tráfego de entrada nessa tabela para a tabela 10. Na tabela 10, são vistos quatro entradas de fluxos, duas para cada host. Cada uma delas é referente a um sentido da conexão, permitindo que seja feito o controle de banda simétrico. Já na tabela 20, há três entradas de fluxo, similares às do simple_switch_13, porque foi usado o mesmo processo de encaminhamento. A fórmula abaixo descreve o comportamento esperado para o número de entradas de fluxo.
E(h) = 2 ∗ h + E0+ 2 (4.1)
Onde é E(h)o número de fluxos, h é o número de hosts no switch e E0 é o número
de entradas de fluxos no simple_switch para a mesma quantidade de fluxos iniciados, a constate dois está ligado as instruções de table miss para as tabelaas 10 e 20. O gráfico da Figura 4.16 mostra o resultado obtido a partir dos testes na topologia linear. O número de hosts e switches variaram de 2 host e 2 switches (topologia linear-2) até 10 hosts e 10 switches (topologia linear-10).
37
Figura 4.16: Comparação entre o número de fluxos instalados na aplicação desenvolvida e aplicação simple_switch
4.3.4
Teste com múltiplos usuários
Nessa etapa, é testado a capacidade da plataforma de responder à solicitação de vários usuários ao mesmo tempo. Para isso, será usado a interface API desenvolvida no Flask. O objetivo é criar solicitações simultâneas e analisar a resposta da rede emulada no Mininet e do banco de dados. A Figura 4.17 mostra a topologia usada neste teste.
Figura 4.17: Topologia do Teste de carga.
Uma vez que o fluxo entre cliente e servidor esteja estabelecido, a taxa contratada será alterada. O objetivo é observar a variação na taxa de transmissão efetivada. Com essa finalidade, foi desenvolvido um código em Python que gera solicitações simultâneas. Para isso, o código usa as chamadas da API Rest desenvolvida em um loop, criando,
38 assim, solicitações para a plataforma simultaneamente.
O gráfico da Figura 4.18 mostra os resultados obtidos.
Figura 4.18: Comparação entre banda entregue e contratada em um cenário com multiplos usuários.
É possível observar uma variação entre a banda contratada e a entregue. Nestes pontos a banda entregue foi menor do que a contratada. Isso ocorreu devido a perda de pacotes, o que esperado devido às limitações do ambiente de testes. Os erros associados a essas medidas foi maior que as demais, o que prova que ocorreram retransmissões e perdas de pacotes.
Capítulo 5
Conclusão e Trabalhos Futuros
Neste trabalho, foi desenvolvido uma aplicação em redes definidas por software visando o aprovisionamento de banda sobre demanda do usuário. Foram introduzidos conceitos teóricos essenciais para o entendimento da solução que foi desenvolvida e apresentada a plataforma e sua proposta. Na sequência, foram realizados testes provando a viabilidade técnica da aplicação.
Como pôde ser visto com os resultados, a plataforma é capaz de aprovisionar a banda como desejado. Ao mesmo tempo, foi possível ver que a plataforma não introduz uma quantidade excessiva de regras nas tabelas de fluxo. Também foi possível ver que o uso de meters para esse tipo de aplicação se mostra uma solução interessante.
Em última análise, esse tipo de aplicação se mostra ideal para ambientes onde os clientes têm uma certa sazonalidade como universidades, centros de convenções e condo-mínios de prédios empresariais. A necessidade de banda nesses casos varia de acordo com a época do ano. O controle da banda contratada se reflete em economia, evitando o super aprovisionamento em épocas onde o número de usuários é pequeno. Já do ponto de vista do provedor de acesso, com o uso das redes definidas por software, a tarefa de manter redes cada vez maiores se torna mais simples.
Esse trabalho abordou o controle de banda. Entretanto, não foi proposto nenhum mecanismo que garanta a entrega da banda contratada. Pesquisas futuras podem usar esse trabalho como ponto de partida e propor esse tipo de mecanismo.
Bibliografia
[1] Brief, O. S. Openflow-enabled sdn and network functions virtualization. Open Netw. Found 17 (2014), 1–12.
[2] Doverspike, R., Clapp, G., Douyon, P., Freimuth, D. M., Gullapalli, K., Han, B., Hartley, J., Mahimkar, A., Mavrogiorgis, E., O’Connor, J., et al. Using sdn technology to enable cost-effective bandwidth-on-demand for cloud services. Journal of Optical Communications and Networking 7, 2 (2015), A326–A334.
[3] Fernandes, E. L., Rojas, E., Alvarez-Horcajo, J., Kis, Z. L., Sanvito, D., Bonelli, N., Cascone, C., and Rothenberg, C. E. The road to bofuss: The basic openflow user-space software switch. arXiv preprint arXiv:1901.06699 (2019). [4] Fulp, E. W., and Reeves, D. S. Optimal provisioning and pricing of inter-net differentiated services in hierarchical markets. In International Conference on Networking (2001), Springer, pp. 409–418.
[5] Grinberg, M. Flask web development: developing web applications with python. "O’Reilly Media, Inc.", 2018.
[6] Knetsolutions. Github ryu-exercises, 2018.
[7] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C. E., Azodolmolky, S., and Uhlig, S. Software-defined networking: A comprehensive survey. arXiv preprint arXiv:1406.0440 (2014).
[8] Kubo, R., Fujita, T., Agawa, Y., and Suzuki, H. Ryu sdn framework: Open-source sdn platform software. NTT Tech. Rev 12, 8 (2014), 1–5.
41 [9] Lantz, B., Heller, B., and McKeown, N. A network in a laptop: rapid pro-totyping for software-defined networks. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks (2010), ACM, p. 19.
[10] Mendiola, A., Astorga, J., Jacob, E., and Higuero, M. A survey on the contributions of software-defined networking to traffic engineering. IEEE Communi-cations Surveys & Tutorials 19, 2 (2016), 918–953.
[11] Mendiola, A., Astorga, J., Jacob, E., Stamos, K., Juszczyk, A., Dombek, K., Vuleta-Radoičić, J., and Ortiz, J. Multi-domain bandwidth on demand service provisioning using sdn. In 2016 IEEE NetSoft Conference and Workshops (NetSoft) (2016), IEEE, pp. 353–354.
[12] Pfaff, B., Lantz, B., Heller, B., et al. Openflow switch specification, version 1.3. 0. Open Networking Foundation (2012).
[13] Ryu, P. Ryu sdn framework using openflow 1.3, 2014.
[14] Tanenbaum, A. S. Redes de computadores quinta edição. Editora Pearson (2011). [15] Team, M. Mininet python api reference manual, 2016.
[16] Tilkov, S. A brief introduction to rest. InfoQ, Dec 10 (2007).
[17] Ventre, P. L., Ortiz, J., Mendiola, A., Fernández, C., Pavlidis, A., Sharma, P., Buscaglione, S., Stamos, K., Sevasti, A., and Whittaker, D. Deploying sdn in geant production network. In 2017 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN) (2017), IEEE, pp. 1–2.
