Otimização de tráfego broadcast em redes Openflow

(1)

RICARDO ANÍSIO DA SILVA

OTIMIZAÇÃO DE TRÁFEGO BROADCAST EM REDES OPENFLOW

Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao

Recife

2017

(2)

RICARDO ANÍSIO DA SILVA

OTIMIZAÇÃO DE TRÁFEGO BROADCAST EM REDES OPENFLOW

Dissertação apresentada ao Programa de Pós-graduação em Ciências da Computa-ção, do Centro de Informática da Universi-dade Federal de Pernambuco, como parte dos requisitos necessários à obtenção do tí-tulo de Mestre em Ciência da Computação. Orientador: Djamel Fawzi Hadj Sadok

Recife

2017

(3)

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

S586o Silva, Ricardo Anísio da

Otimização de tráfego broadcast em redes Openflow / Ricardo Anísio da Silva. – 2017.

67 f.: il., fig., tab.

Orientador: Djamel Fawzi Hadj Sadok.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.

Inclui referências e apêndice.

1. Redes de computadores. 2. Redes definidas por software. I. Sadok, Djamel Fawzi Hadj (orientador). II. Título.

004.6 CDD (23. ed.) UFPE- MEI 2017-249

(4)

Ricardo Anísio da Silva

Otimização de Tráfego Broadcast em Redes Openflow

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 14 de junho de 2017.

Aprovado em: 14/06/2017.

BANCA EXAMINADORA

__________________________________________ Prof. Djamel Fawzi Hadj Sadok

Centro de Informática / UFPE (Orientador)

__________________________________________ Prof. Rafael Roque Aschoff

Instituto Federal de Pernambuco

__________________________________________

Profª. Patrícia Takako Endo

(5)

Dedico esse trabalho a minha mãe “Dinha”, com todo meu amor e gratidão, por tudo que fez ao longo de minha vida. Desejo poder ter sido merecedor do esforço dedicado por você em todos os aspectos, especialmente quanto à minha formação. Dedico também a minha esposa Mônica, pelo amor, apoio, confiança e motivação incondicional que sempre me impulsionou em direção às vitórias dos meus desafios.

(6)

AGRADECIMENTOS

Gostaria de agradecer primeiramente a Deus que permitiu que tudo isso acon-tecesse, ao longo de minha vida, e não somente nestes anos como aluno de pós-graduação, mas que em todos os momentos é o maior mestre que alguém pode conhecer.

A toda minha família, em especial minha mãe Raimunda que foi a principal in-centivadora dos meus estudos, minha esposa Mônica que me incentivou nos momentos mais difíceis, dando total apoio moral.

Agradeço a todos os professores do Centro de Informática da Universidade Federal de Pernambuco (CIN), por me proporcionarem o conhecimento, não apenas racional, mas a manifestação do caráter e afetividade da educação no processo de formação profissional.

Em especial ao meu orientador professor Doutor Djamel Sadok, pela oportu-nidade dada, pelas trocas de ideias, pela cobrança, por me ensinar a ter uma visão crítica dos resultados, e pelos caminhos que foram indicados.

Aos meus amigos da turma de mestrado profissional, por me darem todo apoio e incentivo necessário aos estudos das disciplinas cursadas, e ainda por prestarem todo apoio moral na semana de estudos em Recife.

Ao Instituto Federal Paraibano e seus diretores, por me apoiarem durante o mestrado.

Finalmente, gostaria de agradecer a todos que contribuíram de alguma forma direta ou indiretamente à realização de mais uma etapa na minha vida.

(7)

“O Aprendizado é o significado mais límpido da vida, pois jamais se termina uma existência sem que se aprenda algo.”

(8)

RESUMO

O paradigma das Redes Definidas por Software (SDN) vem mudando a forma de gerenciar e operar redes de computadores através da sua principal idéia, a separação dos planos de dados e de conotrole. O protocolo Openflow implementa este conceito e, devido às vantagens de menor custo de operação e maior facilidade de adaptação a projetos de comutadores já existentes, é encontrado hoje em diversos equipamentos de rede comercializados por muitos fabricantes. Com o uso do paradigma SDN e do protocolo Openflow, a inovação e evolução da rede são facilitadas. Dessa forma, muitos serviços típicos de rede podem ser repensados, de forma a torná-los mais flexíveis. Ao projetar uma rede SDN deve-se levar em consideração algumas particularidades de desempenho, como por exemplo: tabela de fluxos e comunicação com controlador. Estas características tornam as métricas tradicionais de desempenho como vazão, latência, jitter e perda de pacotes insuficientes para avaliar o desempenho de uma rede SDN. O foco principal desta dissertação, esta no controle da tabela de fluxo proveniente de requisições ARP. Desta forma, esta proposta visa a diminuição e o controle do tráfego broadcast através da Arquitetura SDN. A partir da criação de um novo módulo, desenvolvido para determinar o uso de múltiplos caminhos no encaminhamento de tráfego referente a um fluxo, demonstrando neste trabalho que algumas métricas de controle de requisições broadcast, podem ser atendidas. O módulo foi implementado e avaliado através de um simulador. Os resultados de avaliações referentes a diversos aspectos da solução proposta, são apresentados nesta dissertação, demonstrando que os ganhos na utilização do controle da tabela de fluxo e na quantidade de mensagens flow-mod do Openflow, geram uma dimunição na quantidade de dados transmitidas entre o controlador e o comutador.

(9)

ABSTRACT

The paradigm of Software Defined Networking (SDN) has been changing the way in which to manage and operate computer networks through its main idea, the separation of data plans and control. The Openflow protocol implements this concept and, due to the advantages of lower cost of operation and greater ease of adaptation to designs of existing switches, is found today in several network equipment marketed by many manufacturers. With the use of the SDN paradigm and the Openflow protocol, network innovation and evolution are facilitated. In this way, many typical network services can be rethought in order to make them more flexible. When designing an SDN network one must take into account some particularities of performance, as for example: table of flows and communication with controller. These characteristics make traditional performance metrics such as flow, latency, jitter, and packet loss insufficient to evaluate the performance of an SDN network. The main focus of this dissertation is to control the flow table from ARP requests. In this way, this proposal aims at reducing and controlling broadcast traffic through the use and extension of the SDN Architecture. From the creation of a new module, developed to determine the use of multiple paths in the traffic routing referring to a flow, demonstrating in this work that some control metrics of broadcast requests can be met. The module was implemented and evaluated through a simulator. The results of evaluations regarding several aspects of the proposed solution are presented in this dissertation, demonstrating that the gains in the use of the flow table control and in the number of flow-mod messages of Openflow, generate a decrease in the amount of data transmitted between the Controller and the switch. Keywords: Software defined networks (SDN). OpenFlow. Broadcast.

(10)

LISTA DE FIGURAS

Figura 1 – Camadas de uma Rede SDN . . . 22

Figura 2 – Arquitetura Openflow . . . 24

Figura 3 – Mininet Topologia . . . 28

Figura 4 – Open vSwitch . . . 29

Figura 5 – TCPdump . . . 32

Figura 6 – Wireshark . . . 32

Figura 7 – Requisições arp geram novos fluxos . . . 34

Figura 8 – Respostas arp geram mais fluxos . . . 35

Figura 9 – Modelo Openflow . . . 36

Figura 10 – Controlador responde requisições ARP . . . 39

Figura 11 – Topologia Linear . . . 40

Figura 12 – Topologia Tree . . . 41

Figura 13 – FITS autonomous island interconnection architecture . . . 43

Figura 14 – Gráfico Topologia Linear Padrão . . . 45

Figura 15 – Gráfico Topologia Linear Proposta . . . 46

Figura 16 – Grafico comparativo Topologia Linear . . . 47

Figura 17 – Gráfico Topologia Tree Padrão . . . 48

Figura 18 – Gráfico Topologia Tree Proposta . . . 49

Figura 19 – Grafico comparativo Topologia Tree . . . 50

Figura 20 – Gráfico Topologia Linear Padrão (flow-mod) . . . 51

Figura 21 – Gráfico Topologia Linear Proposta (flow-mod) . . . 52

Figura 22 – Gráfico Topologia Linear Comparativo (flow-mod) . . . 53

Figura 23 – Gráfico Topologia Tree Padrão (flow-mod) . . . 54

Figura 24 – Gráfico Topologia Tree Proposta (flow-mod) . . . 55

(11)

LISTA DE TABELAS

Tabela 1 – Topologia Linear Padrão . . . 44

Tabela 2 – Topologia Linear Proposta . . . 45

Tabela 3 – Topologia Linear Comparativo . . . 46

Tabela 4 – Topologia Tree Padrão . . . 47

Tabela 5 – Topologia Tree Proposta . . . 48

Tabela 6 – opologia Tree Comparativo (flow-mod) . . . 49

Tabela 7 – Topologia Linear Padrão (flow-mod) . . . 50

Tabela 8 – Topologia Linear Proposta (fow-mod) . . . 51

Tabela 9 – Topologia Linear Comparativo . . . 52

Tabela 10 – Topologia Tree Padrão (flow-mod) . . . 53

Tabela 11 – Topologia tree Proposta (flow-mod) . . . 54

(12)

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface ARP Address Resolution Protocol

CPU Central Processing Unit - Unidade Central de Processamento DAS Documento de Arrecadação do Simples Nacional

DE Diagnóstico de Enfermagem

DOS Disk Operating System (Sistema Operacional em Disco) FITS Future Internet Testbed with Security

GNU General Public License

GPL General Public License

HP Health Points

IBM International Business Machines

IP Internet Protocol

JSON JavaScript Object Notation KVM Kernel-based Virtual Machine

MAC Media Access Control

NEC National Eletrical Code

ONF Open Network Foudation

OSI Open Systems Interconnection

(13)

RFC Request for Comments

SDN Software Defined Networks

TI Tecnologia da Informação

UNESP Universidade Estadual Paulista

W3C World Wide Web Consortioum, entidade que regulamenta os padrões de internet

(14)

SUMÁRIO

1 INTRODUÇÃO . . . . 15 1.1 Motivação . . . . 16 1.2 Objetivos da Pesquisa . . . 18 1.2.1 Objetivo Geral . . . 18 1.2.2 Objetivos Específicos . . . 18 1.3 Organização . . . . 18 2 REVISÃO DA LITERATURA . . . . 20

2.1 Redes Definidas Por Softwares . . . . 20

2.2 Protocolo Openflow . . . . 23 2.3 Controladores . . . . 24 2.3.1 Controlador Nox . . . 25 2.3.2 Controlador Pox . . . 25 2.3.3 Controlador Ryu . . . 25 2.4 Mensagens Openflow . . . . 26

2.5 Soluções Open Source . . . . 26

2.5.1 Mininet . . . 27

2.5.2 Open Vswitch . . . 28

2.5.3 OpenWrt . . . 29

2.5.4 NetFPGA . . . 30

2.6 Soluções Proprietárias . . . . 30

2.7 Ferramentas de Analise de Tráfego . . . . 31

3 SOLUÇÃO PROPOSTA . . . . 33

3.1 Broadcast . . . . 34

3.2 Modelo Openflow . . . 35

(15)

4 AVALIAÇÃO DA PROPOSTA . . . . 40

4.1 Ambiente de Testes . . . . 40

4.2 Coleta de Dados . . . . 42

5 ANÁLISE DOS RESULTADOS . . . . 44

6 CONCLUSÃO E TRABALHOS FUTUROS . . . . 57

REFERÊNCIAS . . . . 60

APÊNDICES 63 APÊNDICE A – CÓDIGO DE OBTENÇÃO DAS ESTATÍSTICAS DOS FLUXOS OPENFLOW . . . . 64

(16)

15

1 INTRODUÇÃO

As redes de telecomunicações tornaram-se uma das principais fontes de infor-mação a nível mundial. Em consequência do sucesso e popularização, surgiram vários problemas para manter a qualidade nos diferentes tipos de tráfego, o que encarece a entrega dos serviços das redes corporativas, tais como: a transmissão de tráfego de voz, dados e streaming de vídeos.

De acordo com o grupo pioneiro em tecnologias inovadoras Furukawa, as re-des de telecomunicações estão sendo aperfeiçoadas para suportar a transmissão de informações com a introdução de novas tecnologias, tanto do lado dos equipa-mentos da rede (eleequipa-mentos de rede), quanto dos meios de transmissão (redes de transporte) e dos sistemas de operações para o gerenciamento (Gerência de Redes de Telecomunicações). (SAKATO; O’DONNELL; HINGORANI, 2012).

Um grupo de pesquisadores de rede da Universidade de Stanford e da Califórnia em Berkeley desenvolveu uma solução programável, nomeada de Rede Definida por Software (SDN). A SDN é um novo paradigma, criada com o intuito de ser utilizada em redes de computadores em produção, permite que administradores e pesquisadores possam testar novos protocolos e tecnologias independentes das aplicações proprietá-rias, provendo a interoperabilidade entre diferentes fabricantes que antes não existia. (FALSARELLA, 2012).

Baseado no contexto de crescimento, os administradores de redes corporativas se veem com a responsabilidade de manter a qualidade e a segurança da informação que trafega na rede da empresa. Considerando que aplicações e funcionalidades são adicionadas diariamente, é necessário criar um ponto concentrador de gerenciamento para facilitar a administração dessas tecnologias. Nesse ambiente, surgem as redes programáveis, junto ao protocolo OpenFlow, que possui padrão aberto, com uma pro-posta tecnológica que se baseia em um modelo de controle de rede centralizado, sendo assim, entrega um modo para que o administrador consiga melhorar o gerenciamento

(17)

Capítulo 1. Introdução 16

dos diferentes tipos de tráfego na sua rede.

Diante dessa gama de cenários voltados para a Internet do futuro, há uma série de possibilidades a serem exploradas. Uma delas é o desmembramento das funções atribuídas á rede tradicional, normalmente prejudicada pela maior demanda de dados que pode ocasionar uma lentidão em seu funcionamento. Com o advento da SDN, o serviço prestado pela rede será melhor gerenciado, potencializando o tráfego e adequando-a ás novas tecnologias. Uma vez que a internet, normalmente não garante essa qualidade essencial em aplicações sensíveis, como por exemplo, a tecnologia de Voz sobre IP (VoIP).

1.1 Motivação

Nos últimos anos a velocidade e a quantidade das informações que trafegam pela Rede têm experimentado um crescimento que não tende mais a regredir. O mesmo ocorre, em escala menor, na rede de uma organização, se não corretamente gerenciado pode ocasionar lentidão ou até mesmo a indisponibilidade de um ou mais serviços.

O controle de tráfego do broadcast, tem a intenção de segmentar uma rede lógica afim de aumentar o controle de tráfego da rede, diminuir o alcance de disseminação de pacotes de difusão (broadcast) e de pragas virtuais, melhorado assim o desempenho e a segurança de uma determinada rede.

Atualmente é cada vez mais comum o uso de soluções virtuais, disponíveis a um clique, para substituir ações que, eram efetuadas fisicamente, demandando deslocamentos e disponibilidade de tempo, como por exemplo, em livrarias online onde podem se adquirir livros, físicos ou virtuais, em pouco tempo sem a necessidade de sair de sua residência. Em uma organização esta tendência segue o mesmo caminho afim de agilizar processos, diminuir custos e aumentar lucros.

Este aumento de aplicações e, consequentemente, de informações trafegando pela rede trouxe uma nova preocupação para a equipe de TI (Tecnologia da Informação) que é o congestionamento dos links. O crescimento desenfreado do tráfego de rede

(18)

cria gargalos em determinados pontos da estrutura, podendo gerar lentidão ou até tornar alguns serviços indisponíveis temporariamente. Esta situação pode ser agravada pela propagação de pacotes de difusão (broadcast) que em muitos casos consomem fatia considerável da banda de um enlace de dados.

Outra questão importante a se considerar é a segurança. Com o aumento de informações confidenciais circulando pela rede cresce também o interesse de pessoas mal intencionadas buscando capturar dados para fins diversos por meio da disseminação de pragas virtuais (vírus, worms, malwares, etc) ou através de sniffers, capturando pacotes e extraindo dados que lhe pareçam interessantes para uso futuro. ça da (MARCO AURÉLIO MAIA, 2013)

Uma rede possui vários dispositivos: computadores, impressoras e outros, co-nectados, que disseminam uma grande quantidade de pacotes de difusão, seja por falhas na conexão, mau funcionamento de placas de redes, ou até mesmo por protoco-los e aplicações que geram este tipo de tráfego, podendo causar atraso no tempo de resposta e lentidão na rede

. (RIBEIRO et al., 2011) No modelo a ser proposto, existe um controle lógico de difusão por onde os pacotes de broadcast são contidos e não se propagam a outras redes. A proposta se faz através do endereço físico das interfaces de rede dos dispositivos (endereço MAC). Neste método, o administrador de redes associa um endereço MAC de um dispositivo a uma tabela no controlador. (MUSSI et al., 2011)

Um dos maiores inconvenientes desta modalidade de agrupamento é o fato de que, antes de se colocar em operação, devem se cadastrar todos os endereços MAC dos dispositivos que serão conectados na rede, o que, dependendo do tamanho da rede, pode dispender bastante tempo de trabalho. Outra limitação desta solução refere-se a impossibilidade de associar mais de uma rede para cada endereço MAC.

(19)

1.2 Objetivos da Pesquisa

Nesta seção serão descritos os objetivos gerais e específicos que se buscam alcançar por meio deste trabalho.

1.2.1 Objetivo Geral

O objetivo principal deste trabalho é melhorar o desempenho de sistemas e serviços em redes Openflow. Um modulo para auxiliar o controlador neste tipo de ambi-ente precisa ser desenvolvido levando em consideração todas as suas especificidades para, assim, adequar-se ao máximo a infraestrutura existente nas organizações.

1.2.2 Objetivos Específicos

Para atender ao objetivo geral deste trabalho, foram definidos os seguintes objetivos específicos:

• Alterar o controlador, para que possa diminuir o número de mensagens broadcast em uma rede;

• Diminuir o processamento no controlador, reduzindo a carga de trabalho; • Criar um modulo auxiliar para manter o mapeamento da tabela ARP no

controla-dor;

• Reduzir o número de mensagens flow-mod em uma rede.

1.3 Organização

A sequência desta dissertação está organizada como indicado a seguir.

No Capítulo 2 é feita uma revisão da literatura, descrevendo as redes definidas por software e suas tecnologias, além de ferramentas e soluções para uso nessas redes.

No Capítulo 3 é apresentado o problema de dominio de colisão em redes openflow e a solução proposta para reduzir este probrema.

(20)

No Capítulo 4 é feito a avaliação da proposta, onde é realizado os testes em ambiente emulado, onde é feito a avaliação da proposta em topologias de redes distintas, também é coletado os dados que serão analisados no capítulo 5 desta dissertação.

Já no Capítulo 5 é apresentado o detalhamento e a validação das simulações empreendidas neste estudo. Neste mesmo capítulo, são detalhados os parâmetros das simulações e apresentados os resultados dos experimentos, juntamente com a avaliação de desempenho da proposta, comparando o desempenho por cenários e comparando seus desempenhos entre si.

(21)

20

2 REVISÃO DA LITERATURA

A globalização inclui um processo de integração econômica, cultural, social e política e com isso abriu diversas portas ao mundo empresarial, quebrando barreiras como distância e limites de fronteiras, trazendo ao mundo as grandes multinacionais. Essas empresas, com ajuda da tecnologia, movimentam o mercado financeiro, cada vez mais expandindo, não se importando com a distância física entre matriz e filiais. Para manter esse cenário conectado em um ambiente de redes convergentes com diversos tipos de aplicações, os administradores de redes se veem cada vez mais condicionados a automatizar processos, facilitar a sua vida e abstrair a complexidade dos processos internos para o usuário, e é nesse cenário que surge o conceito das redes definidas por software, permitindo ao administrador gerir seus equipamentos de rede remotamente, programar roteadores, switches através de software e integrar aplicações, serviços e funcionalidades aos usuários de maneira transparente.

David Cearley, vice-presidente do Instituto Gartner, líder mundial em pesquisa e aconselhamento sobre tecnologia, destacou uma das vantagens das redes SDN:

O ambiente de rede nos próximos cinco anos não será mais controlado por roteadores e switches ou por outros tipos de hardware, mas sim por software. A grande vantagem dessa mudança é uma melhoria do monitoramento e também aumento de desempenho da infraestrutura de TI, que passará a ser controlada de forma centralizada. As configurações serão feitas em um único ponto da rede e não mais por devices individuais. (CEARLEY, 2014).

2.1 Redes Definidas Por Softwares

O SDN oferece um controle centralizado da rede, com base em seu principal conceito de abstração dos planos de dados e o plano de controle, isto é, abstraindo as complexidades da rede. Sendo assim, assumindo tarefas que antes eram realizadas pelo hardware, de forma que permita o gerenciamento da rede através de uma Interface

(22)

Capítulo 2. Revisão da Literatura 21

de Programação de Aplicações ou API, (do inglês, Application Programming Interface). As tecnologias atuais de rede não estão dando conta de todas as exigências dos usuários devido a complexidade e a quantidade de protocolos usados. Geralmente são desenvolvidas e definidas de forma isolada e, para dificultar ainda mais, alguns fabricantes desenvolvem protocolos proprietários. Esses problemas vêm causando transtorno aos usuários, já que a grande parte utiliza a Internet para alguma forma de comunicação. (RODRÍGUEZ, 2014).

Atualmente, existe a necessidade das corporações se alinharem ao crescimento do mercado tecnológico e se atualizarem diante das novas tecnologias e tendências. O avanço trazido pelo SDN extrapola o modelo tradicional de um conjunto de “caixas pretas” deixando de tratar o hardware das redes de forma independente e passando a mesclar suas funções cada vez mais com os softwares, trazendo inúmeras possibilida-des de flexibilidade para usuário e administrador.

A comunicação entre a camada de controle e a camada de infraestrutura é feita através de um protocolo padronizado. Deste modo, tanto o controlador como os dispositivos de rede precisam interpretar este protocolo, modelo esse que pode ser visualizado na Figura 2.1, onde existe a separação das camadas em detalhes de uma rede definida por software. Em equipamentos ativos de rede como switch e roteadores, o plano de controle e o plano de dado são gerenciados pelo mesmo equipamento, no caso de uma rede definida por software o plano de controle fica externo ao dispositivo de rede, no qual pode ser alocada externamente em uma máquina física ou virtual.

(23)

Figura 1 – Camadas de uma Rede SDN

Duque, 2012.

A arquitetura SDN é inerente aos saltos na evolução das redes, dado que o legado tradicional se encontra em seu limite, pois novos protocolos e tecnologias já cita-das não são suportados mediante a arquitetura atual. SDN é um novo paradigma criado com o intuito de ser utilizada em redes de computadores em produção, permitindo que administradores e pesquisadores possam testar novos protocolos e tecnologias inde-pendentes das aplicações proprietárias, provendo a interoperabilidade entre diferentes fabricantes que antes não existiam. (FALSARELLA, 2012).

O parque tecnológico de empresas com diversas filiais e backbones de opera-doras de telecomunicações possui geralmente certa quantidade de equipamentos com fabricantes distintos, o que exige a contratação de vários profissionais especializados em cada fabricante, gerando um custo relativamente maior. No ambiente controlado por software, um único gestor pode se especializar na tecnologia SDN e formular o tráfego centralizado, controlando a interoperabilidade da rede, a partir de uma única interface. Alterando configurações e regras de qualquer ativo da rede quando necessário, fazendo

(24)

com que o administrador gerencie as cargas de tráfego distintas de uma forma flexível e mais eficiente.

2.2 Protocolo Openflow

O paradigma SDN é considerado a nova evolução das redes modernas. Mas para que o funcionamento da nova tendência tecnológica (SDN) se torne possível, será preciso habilitar um protocolo aberto de comunicação entre os diferentes comutadores de rede e o controlador. O protocolo a ser utilizado é o OpenFlow, já que tem como principal característica proporcionar uma interface aberta para que a comunicação entre os equipamentos da rede e o controlador em uma rede definida por software seja possível. (COSTA, 2013).

O OpenFlow é um protocolo que permite modificar o comportamento dos disposi-tivos de rede através de um conjunto de instruções definidos por um controlador remoto. Vários fabricantes estão incluindo o protocolo OpenFlow em seus equipamentos como roteadores, switches e access points. (ARAÚJO, 2013).

Desde então, o OpenFlow foi desenvolvido a partir da versão (OpenFlow 1.0 Standards) desde março de 2008, quando foi proposto pelo grupo constituído de pesquisadores da Universidade de Stanford. No entanto o principal objetivo desses pesquisadores era criar uma rede programável com o propósito de torná-la uma rede de computadores com tecnologia SDN baseada em OpenFlow. (MCKEOWN, 2008).

De acordo com Lopes (MCKEOWN, 2008), “A plataforma OpenFlow é o principal exemplo de aplicação do conceito SDN. Atendendo a demanda de validação de novas propostas de arquiteturas e protocolos de rede sobre equipamentos com sistema proprietários comerciais diferentes”.

Conforme ilustrado na Figura 2.2, o Controlador OpenFlow se comunica com o plano de controle do switch através da rede utilizando o protocolo de comunicação OpenFlow, possibilitando assim que todos os pacatos trafeguem na rede de forma gerenciada.

(25)

Figura 2 – Arquitetura Openflow

Sheffer, 2014.

2.3 Controladores

O controlador OpenFlow atua como um sistema operacional de rede para centralizar a comunicação com os elementos programáveis, agindo como um plano de controle em uma rede definida por software. Desta forma permite adicionar e remover as entradas de dados em uma tabela de fluxo, uma vez que o controlador pode trabalhar de forma distribuída.

Segundo Rodríguez (RODRÍGUEZ, 2014). “O controlador consiste em um modo de controle centralizado, seja fisicamente ou logicamente, que executa aplicações sobre a rede OpenFlow, configurando e gerenciando as tabelas de fluxo dos elementos encaminhadores.” Existem vários controladores desenvolvidos em linguagens de pro-gramação variadas como NOX, baseado em C++; FLOODLIGHT, OPENDAYLIGHT, em Java, POX e Ryu em Python.

(26)

2.3.1 Controlador Nox

O NOX é um controlador de referência que acompanha o OpenFlow, ele surgiu da Interface de Programação de Aplicações (APIs) desenvolvida em C ++. O NOX atua como uma camada de abstração, que desenvolve as aplicações e os serviços que controla as entradas de fluxo nos comutadores OpenFlow. (RODRÍGUEZ, 2014).

Conforme abordado por Costa (COSTA, 2013), o NOX é uma plataforma de controle de rede OpenFlow, com o propósito de prover uma interface de programação de alto nível em que as aplicações de gerenciamento da rede possam ser construídas.

2.3.2 Controlador Pox

O POX é uma versão baseada no modelo do NOX, é o principal controlador OpenFlow de código aberto escrito em Python. O controlador surgiu das APIs de Python do controlador NOX, é um dos controladores mais utilizados atualmente. Segundo Junior (AMILTON JUNIOR, 2010), “O controlador POX é bastante recomendado para experimentos e fins educacionais. Comparado com o NOX, que é desenvolvido em programação C++, ele possui um desempenho inferior, já que o desenvolvimento de aplicações nele é mais rápido e fácil de ser utilizado.” (CHARPINEL JUNIOR, 2012).

2.3.3 Controlador Ryu

Conforme explanado por Rodríguez (RODRÍGUEZ, 2014), “o controlador Ryu é um componente criado para o contexto das redes definidas por software. Todo seu código está disponível gratuitamente com a licença de Apache 2.0 e está completa-mente escrito na linguagem de programação Python, facilitando assim a criação de novas aplicações de controle.”.

O Ryu fornece componentes de software com APIs muito bem definidas, que facilitam aos desenvolvedores a criação de novas formas de gerenciamento de redes e aplicações de controle, ou seja, o controlador dá suporte a vários protocolos para o gerenciamento dos equipamentos de rede como Net Conf, OF-com, OpenFlow. (RODRÍGUEZ, 2014).

(27)

2.4 Mensagens Openflow

O protocolo Openflow possui uma série de mensagens. As mais comuns são:

• Flow-mod - Sentido Controlador –> Switch. São as mensagens utilizadas na

gerencia da tabela de fluxos do switch. São usadas para adicionar, alterar ou remover uma entrada da tabela.

• packetIn - Sentido Switch –> Controlador. O switch enviar mensagens

Packet-In, para o controlador definir o que deverá ser feito com aquele tipo de pacote. São usadas em requisições ao controlador.

• Flow-out - Sentido Controlador –> Switch. O controlador é capaz de enviar

pacotes para a rede através do switch. O controlador encapsula o pacote a ser enviado em uma mensagem flow-out. Na mensagem flow-out é especificada a porta do switch pela o pacote será enviado para a rede.

• Flow-stats - São mensagens usadas na coleta de estatísticas do switch.

Po-dem ser request, do controlador para o switch. Ou response, do switch para o controlador.

2.5 Soluções Open Source

A tradução do termo em inglês “open source” é código aberto. Um software com o código aberto pode ser executado, copiado, distribuído, modificado e aperfeiçoado por todos seus usuários, segundo conceitos encontrados no site do Projeto Software Livre Brasil.projeto softwareeto software.projeto open source. (COSTA et al., 2013).

O software open source é também conhecido como “free software”. Neste caso, a palavra “free” não indica gratuidade, mas sim, liberdade. A liberdade é um dos valores defendidos pelo movimento open source, além da colaboração e o compartilhamento

(28)

do conhecimento. Devido à ambigüidade do significado do termo “free software”, foi cria da a expressão “open source”.

Estes softwares são desenvolvidos por pessoas espalhadas em todo o mundo, em função do acesso ao código fonte.

Em torno de um software, os colaboradores formam uma comunidade. Atual-mente, existem comunidades open source no mundo todo, em torno de diversos tipos de software. (CESTAROLLI, 2015)

2.5.1 Mininet

O Mininet é uma ferramenta de emulação de rede que possibilita criar uma rede virtualizada, com switch, roteadores, controladores e hosts, baseado na arquitetura SDN. O Emulador é executado em um único núcleo (kernel) real e tem como base o protocolo OpenFlow, possibilitando aos pesquisadores criar protótipos de rede através de uma forma simples e barata, antes de programá-lo na rede atual. O emulador foi utilizado para realização de testes para afirmar a viabilidade na implementação do novo paradigma em nosso trabalho. Por se tratar de um ambiente virtualizado, utilizando um único (kernel) do Linux, possui suas limitações. As redes virtualizadas podem exceder os limites de CPU do hardware e a largura de banda disponível no servidor. (KAUR; SINGH; GHUMMAN, 2014).

O Mininet possui algumas topologias pré-definidas, como: single, linear, tree, etc figura 2.3. Além dessas topologias pré-definidas, o Mininet possui suporte a topologias customizadas. (SISWANTO; KARIMAH, 2014)

(29)

Figura 3 – Mininet Topologia

SISWANTO; KARIMAH, 2014

2.5.2 Open Vswitch

O modelo OpenFlow é um comutador em software executado em uma máquina Linux, com o princípio de separação do plano de dados e plano de controle. Esse modelo vem sendo utilizado por pesquisadores em vários estudos técnicos, contudo o modelo carece em desempenho. Perante essa lacuna, foi desenvolvido um comutador virtual adequado à arquitetura OpenFlow nomeado de Open vSwitch (OVS). (OPEN VSWITCH, 2014).

O OVS é um switch virtual de multicamada, em conformidade com uma licença de código aberto Apache 2.0, executado em um (kernel) Linux compatível com as mais variadas distribuições, tais como: Debian, Fedora, Ubuntu e CentOS. Vale ressaltar que a quantidade de portas é relacionada com o limite de portas disponíveis no Desktop e Notebook, incluindo portas sem fio. Figura 2.4. (RODRÍGUEZ; CAMPELO, 2014).

(30)

Figura 4 – Open vSwitch

RODRÍGUES; SOUSA CAMPELO, 2014

Em princípio, seu desenvolvimento foi para uso como um comutador virtual em ambientes virtualizados, mas apesar da sua capacidade de comutação de pacotes L2/L3, o OVS dá suporte a vários servidores físicos, e sua arquitetura suporta várias tecnologias de virtualização, como Xen, KVM e outras. (OPENWRT, 2015).

2.5.3 OpenWrt

OpenWrt é descrito como uma distribuição baseada no kernel do Linux, utilizado em dispositivos embarcados. É um projeto gratuito de código aberto licenciado sob uma licença GPL. A distribuição é de fácil acesso, hospedado por meio do seu site oficial, possui uma interface gráfica conhecida como Luci, de simples administração, porém é possível administrar por meio de linha de comando conhecida como (ash).

Vale ressaltar que o projeto não está limitado apenas a dispositivos embuti-dos, de outro modo, dispositivos como roteadores, computadores portáteis, MikroTik e computadores pessoais baseados em arquitetura x86, também possui suporte ao

(31)

projeto. Como não é destinado apenas a um único dispositivo, o sistema possui suporte integrado às necessidades dos usuários, ou seja, o sistema operacional fornece funcio-nalidades mais completas de acordo com a experiência do usuário final. (PEREIRA, 2011).

2.5.4 NetFPGA

A plataforma NetFPGA’s é um hardware programável de código aberto, com módulo OpenFlow habilitado, projetada para pesquisadores e estudantes construírem protótipos de redes em alta velocidade, além de desenvolver protótipos de comutadores para a Internet do futuro utilizando o protocolo OpenFlow. O projeto consiste em placas PCI-e, com portas gigabit, conectadas a um PC baseado em Linux, possibilitando o desenvolvimento de novas funcionalidades. (LOPES, 2015).

2.6 Soluções Proprietárias

O SDN está deixando de ser solução de laboratório e tornando-se realidade em escala corporativa. Esta revolução na indústria de redes é em consequência à expansão de ambientes altamente virtualizados. Alinhando a este campo tecnológico, é fundamental a utilização de protocolo aberto, como por exemplo, o protocolo OpenFlow, permitindo assim a criação de aplicações voltadas a problemas específicos de rede, assim como controle de acesso, entre outros.

Grandes empresas como IBM, HP, NEC, já desenvolvem aplicações que se utilizam dessa tecnologia, que cada vez mais vem ganhando destaque dentro deste cenário de Redes Definidas por Software. Apesar de ser uma tecnologia de rede ainda muito recente, algumas pesquisas revelam que em alguns anos será um negócio de bilhões de dólares. O SDN é uma das coisas mais relevantes da última década em se tratando de infraestrutura de redes, e vem chamando a atenção por sua simplicidade e facilidade de gerenciar e programar as redes. (DUQUE, 2012).

A gigante do mercado de soluções em tecnologia da informação, HP, possui a maior base de infraestrutura instalada com suporte ao OpenFlow. Membro e um

(32)

dos fundadores do grupo ONF, investe pesado em soluções SDN desde 2008. A HP desenvolveu uma solução corporativa de controlador de rede chamado VAN (Virtual Applications Network ), o controlador, além de prover um ponto unificado e centralizado para gerenciamento da rede, provê soluções de automação da rede de ponta a ponta, ou seja, do datacenter ao campus. (HP COMPANY, 2015).

A companhia multinacional do mercado de redes de computadores a Cisco, en-trou estrategicamente no conceito SDN, desenvolvendo um conceito chave denominado de ONE (Open network Enviroment), uma serie de APIs e SDKs para desenvolvedores. A solução fornece uma visão ampla do conceito, dividindo em camadas, dentre elas, a camada de infraestrutura consiste em fazer com que dispositivos físicos e virtuais trabalhem em conjunto em uma rede com capacidade de programação. (CISCO, 2015).

À medida que o SDN amadurece no mercado de soluções estratégicas, novos olhares se abrem no meio corporativo, onde grande parte dos fabricantes está se movendo e oferecendo produtos e soluções no mercado. Suas aplicações criam um ambiente propício para a competitividade, que antes dessa evolução estava restrito para um único fabricante, sendo assim a visão é oferecer a melhor solução para cada caso de negócio.

2.7 Ferramentas de Analise de Tráfego

• Tcpdump: Desenvolvido em 1987 é um analisador de pacotes de código aberto

usado em linha de comando desenvolvido para auxiliar os gestores de rede. A ferramenta exibe as informações contidas no pacote capturado em uma ou mais interfaces de rede. (QUINTERO, 2014). Figura 2.5. (ROSANTE; BREGA, 2011)

(33)

Figura 5 – TCPdump

ROSANTE; BREGA, 2011

• Wireshark: É uma das ferramentas mais conhecidas no mundo, serve para

aná-lise de pacotes que trafegam na rede. Foi desenvolvida em 1998 e é compatível com qualquer sistema operacional, possuindo uma interface gráfica, Figura 2.6. (NDATINYA et al., 2015)

Figura 6 – Wireshark

(34)

33

3 SOLUÇÃO PROPOSTA

Com a evolução das redes e a necessidade de topologias mais flexíveis e escalá-veis, foram desenvolvidos equipamentos como bridges e switches. Estes equipamentos comutadores eliminam o domínio único de colisão isolando suas portas, formando assim, um domínio de colisão para cada interface. Para isso, o quadro recebido será processado pelo equipamento e encaminhado à porta na qual o host de destino se encontra, conforme sua tabela de comutação que é formada de forma automática e dinâmica. Então, se um endereço de destino não consta na tabela de comutação, o Switch repassa o quadro em todas as suas interfaces, dessa forma, para cada quadro recebido será armazenado na tabela de comutação a porta em que o endereço físico do remetente se encontra. (SCHWARZ et al., 2014)

Comutadores se tornaram muito importantes para desempenho da rede, sendo eles a conexão central da rede local. Notamos então, que em redes de médio a grande porte se faz necessário a utilização de muitos switches. Nestes casos é possível orga-nizar estes equipamentos em diferentes topologias, afim de ter caminhos redundantes para evitar falhas, expandir a rede, ter alta disponibilidade, realizar isolamentos na rede e fazendo tudo isso sempre com auto desempenho. Porém, ao formar caminhos re-dundantes irá formar loops entre switches, que são indesejados pois geram problemas como alocação de todos os enlaces e o travamento da rede.

Estes problemas ocorrem pelo próprio funcionamento padrão dos equipamentos e dos protocolos de rede, que mandam mensagens em broadcast gerando encaminha-mentos das cópias do frame, passando de um switch para outro em um loop. Dessa forma, os quadros percorrerão os switches de forma cíclica, multiplicando-se de forma exponencial.

(35)

Capítulo 3. Solução Proposta 34

3.1 Broadcast

O broadcast causa processamento extra em uma rede. Em uma rede definida por software o broadcast causa mais danos, um deles é gerar processamento no controlador. Quando um pacote é enviado em broadcast, o controlador precisa criar fluxos no switch para encaminhar esses pacotes. O ideal é minimizar a criação de fluxos, para reduzir a carga de processamento no controlador. A Figura 3.1 e Figura 3.2 demonstram o funcionamento de uma conexão ARP em uma rede definida por software. Cada requisição ARP gera o mesmo processo mostrado acima.

Figura 7 – Requisições arp geram novos fluxos

(36)

Figura 8 – Respostas arp geram mais fluxos

Próprio Autor

3.2 Modelo Openflow

Um modelo para SDN é o Openflow, que foi proposto na Universidade de Stanford nos Estados Unidos (MCKEOWN, 2008). Ele foi a primeira proposta de interface de comunicação entre as camadas de controle e de hardware.

Openflow usa informações contidas em cabeçalhos de protocolos de pacotes recebidos para identificar fluxos de pacotes, e assim aplicar regras de encaminhamento definidas estaticamente ou dinamicamente por um controlador. Figura 3.3.

(37)

Figura 9 – Modelo Openflow

O controlador pode residir em um outro equipamento, possibilitando o controle centralizado da rede. Com isso o administrador de rede pode definir como os determi-nados fluxos de pacotes devem ser encaminhados pelos equipamentos de rede. Esse modelo possibilita realizar balanceamento de tráfego e tratar o problema com enlaces redundantes de uma só vez. (ALVES JUNIOR; ALBINI; INFORMÁTICA, 2012).

Para isso, precisam-se identificar os determinados fluxos de pacotes e assumir diferentes caminhos pelos switches, de forma a utilizar todos os recursos disponíveis e evitar encaminhamentos cíclicos.

Atualmente, com o crescimento das redes, necessita-se de um controle da rede muito mais eficaz e seguro. Portanto, nos cenários de médio a grande porte, a realização de controle de tráfego é imprescindível. Dessa forma, tirando os gargalos da rede e aproveitando os recursos físicos, com certeza resulta em um impacto muito positivo para o desempenho da rede e consequentemente na produtividade da instituição.

De fato, o que nos impulsiona a tratar estas questões é ter acesso a um protocolo que nos possibilita programar o funcionamento dos Switches. Sendo que, sem essa possibilidade estamos limitados aos mecanismos disponibilizados pelos fabricantes

(38)

dos equipamentos, não havendo muito poder de controle e customização. Sendo assim, Openflow/SDN possibilita desenvolver uma implementação de controle de rede para fazer o devido controle de tráfego e otimização de recursos físicos. (COSTA, 2013).

Algumas topologias de nível de enlace são formadas com intenções de tornar a rede tolerante a falhas, realizar balanceamento de carga, e evitar gargalos. No entanto, ao configurar essas topologias com switches geralmente se formarão caminhos fechados (loops), necessitando a utilização de mecanismos que evitam os problemas de broadcast resultantes dos loops entre switches e bridges.

Em uma rede local, esse protocolo ARP tem por finalidade identificar o endereço MAC da interface de rede de um equipamento que possui um determinado endereço IP. Ele é necessário para que um host em uma rede local descubra o endereço MAC de outro host com que precisa se comunicar e cujo endereço IP é conhecido. Assim, o host de origem transmite uma mensagem ARP em broadcast, perguntando qual é o endereço MAC do host que possui o endereço IP em questão. (OLIVEIRA; SHINODA; SCHWEITZER, 2015)

3.3 Otimização do Broadcast

A proposta é modificar o controlador para manter uma tabela ARP com o mape-amento do emderço IP com o MAC dos hosts. Populamos a tabela com informações extraídas dos pacotes da camada de rede que passam pelo controlador. Os pacotes da camada de rede contêm endereços IP de origem/destino, usados para formar a tabela. A tabela é criada utilizando a estrutura de dados conhecida como dicionário, da linguagem Python.

O funcionamento do módulo proposto é bem simples. Ao chegar um pacote ARP request, o módulo verifica se o endereço IP de destino se encontra em sua tabela. Caso o endereço IP se encontre na tabela, significa que o MAC corresponde ao IP que

(39)

também está na tabela, então uma função responsável por gerar uma mensagem ARP response é chamada.

O controlador é responsável por tomar decisões e adicionar e/ou remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. Exerce a função de uma camada de abstração da infraestrutura física, permitindo de forma mais fácil a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. A programação do controlador permite a evolução das tecnologias nos planos de dados e as inovações na lógica das aplicações de controle.

O controlador possui métodos para criação de pacotes ARP. O pacote ARP response criado possui o MAC de destino extraído da tabela. O índice do dicionário é o endereço IP e, o valor é o endereço MAC.

Quando a requisição é para um endereço inexistente na tabela, ocorre broadcast na rede. Uma entrada do tipo flood é criada na tabela do switch, para permitir que o ARP request seja enviado para todos na rede, com exceção do host de origem.

Sem a proposta, uma requisição ARP sempre gera no mínimo duas mensagens flowmod. Uma mensagem adiciona um fluxo para o ARP request, e outra adiciona um fluxo para o ARP response.

Com a solução proposta serão geradas mensagens flow-mod apenas quando o MAC de destino não estiver na tabela ARP mantida pelo controlador. Quando a tabela ARP do controlador contiver o MAC requisitado, não será necessário adicionar entradas na tabela do switch. O controlador receberá a requisição ARP e, responderá usando uma mensagem flowout, sem precisar manipular a tabela do switch. Reduzindo o número de mensagens flow-mod.

(40)

Figura 10 – Controlador responde requisições ARP

(41)

40

4 AVALIAÇÃO DA PROPOSTA

4.1 Ambiente de Testes

Para o ambiente emulado da solução proposta utilizou-se o Mininet (MORLING; CAIN, 1975). Para realizar a avaliação do funcionamento da aplicação, emulou-se utilizando duas topologias, uma Linear e outra em árvore, ambas conforme descritas em detalhes adiante.

• Topologia Linear com 2 Switches: Como avaliação inicial, utiliza-se a topologia mais simples disponível no emulador com dois switches. Os switches são co-nectados diretamente e dois hosts são coco-nectados cada um a um dos switches Figura 4.1.

Figura 11 – Topologia Linear

Próprio Autor

• Topologia tree com três Níveis e Sete Switches: A topologia tree é um tipo de topologia voltada para data centers. Realizou-se a avaliação de funcionamento em uma topologia de três níveis com sete switches e oito hosts conectados de acordo com a Figura 4.2.

(42)

Capítulo 4. Avaliação da Proposta 41

Figura 12 – Topologia Tree

Próprio Autor

Foi utilizado o controlador POX, por ser um sistema simples e normalmente usado na academia. Podendo ser obtido em seu repositório oficial (POXREPO, 2013) no github.

Neste trabalho foi usada a versão 2.0.0 em uma máquina virtual com 4GB de memória RAM e suporte a virtualização por hardware.

Depois de estudar a estrutura interna do controlador, pode-se iniciar a realização de modificações. Inicialmente apenas mudanças pequenas foram realizadas, mudanças como alterar o conteúdo de mensagens exibidas na tela.

Um software bastante útil é o Wireshark (OREBAUGH; RAMIREZ; BEALE, 2006), com ele pode-se visualizar as mensagens do protocolo Openflow em tempo de execução.

(43)

4.2 Coleta de Dados

Switches Openflow possuem um campo em sua tabela para armazenar estatísti-cas sobre fluxos. O controlador é capaz de enviar requisições para o switch, solicitando estatísticas dos fluxos.

Durante os experimentos foi utilizado um módulo POX responsável pela captura de estatísticas. Algumas modificações no módulo de estatísticas foram necessárias, para adequá-lo aos experimentos. Há ferramentas como o dpctl, que permitem visualizar a tabela do switch.

Com o dpctl daria para capturar os fluxos apenas no final dos experimentos. A Tabela é atualizada constantemente, o que motivou o uso do flow-stats, por possibilitar intervalos entre execuções, permitindo executar o flow-stats seguidas vezes durante o experimento. Quanto as mensagens flow-mod, o software usado foi o Wireshark (OREBAUGH; RAMIREZ; BEALE, 2006). O TCPdump (FUENTES; KAR, 2005) foi utilizado para capturar os pacotes, e o Wireshark para analisa-los.

Durante a execução desta pesquisa, a falta de hardware com Openflow habilitado representou um grande desafio. Para contornar a falta de switch Openflow, foram levantadas algumas alternativas. A melhor opção seria realizar os experimentos no Future Internet Testbed with Security (FITS)(NUNES; PONTES; GUEDES, ). No FITS seria possível realizar os testes com máquinas geograficamente distantes, como ilustra a Figura 4.3. (BIAłEK, 2011). Devido as circunstâncias, não foi possível realizar esta verificação.

(44)

Figura 13 – FITS autonomous island interconnection architecture

(45)

44

5 ANÁLISE DOS RESULTADOS

As primeiras amostras de um experimento geralmente configuram a fase de estabilização, enquanto as últimas são a fase de desestabilização. Foram descartados as 5 primeiras e últimas medições de cada experimento, foi usado esse valor após a observação de que os primeiros resultados eram bastante dispersos. Foi calculada a média aritmética de cada experimento, a fim de encontrar a tendência central de cada experimento, para compara-los. O desvio padrão foi calculado para estipular o quanto as medidas se distanciaram da média. A margem de erro e intervalo de confiança foram calculados para identificar quais valores poderiam ser considerados corretos. Um nível de confiança de 95% foi estipulado.

Primeiramente foi realizado o levantamento dos dados utilizando a topologia Linear do Mininet, utilizando 2 switches e 4 hosts Figura 4.1, sem uso do modulo proposto, onde foi calculado a média de entradas de fluxos na tabela.

Tabela 1 – Topologia Linear Padrão

Topologia Linear Padrão (quantidade)

Média 16,388

Desvio-Padrão 1,603

Margem-de-erro 0,388

(46)

Capítulo 5. Análise dos Resultados 45

Figura 14 – Gráfico Topologia Linear Padrão

Realizamos o mesmo levantamento dos dados utilizando a topologia Linear do Mininet com o uso do modulo proposto, onde foi calculado a média de entradas de fluxos na tabela.

Tabela 2 – Topologia Linear Proposta

Topologia Linear Proposta

(Quantidade)

Média 14,388

(47)

Figura 15 – Gráfico Topologia Linear Proposta

Por fim, comparamos os gráficos da topologia Linear padrão com a Topologia Linear utilizando o modulo proposto. No gráfico da Figura 5.3, podemos observar que fazendo uso da proposta deste trabalho, podemos diminuir consideralvelmente a quantidade de entradas na tabela de fluxo.

Tabela 3 – Topologia Linear Comparativo

Topologia Linear Padrão (quantidade Proposta (quantidade)

Média 16,388 14,388

Desvio-Padrão 1,603 1,603

Margem-de-erro 0,388 0,388

(48)

Figura 16 – Grafico comparativo Topologia Linear

Os mesmos experimentos foram realizados utilizando a topologia em Árvore, utilizando 7 switches e 8 hosts Figura 4.2. Os testes foram realizados nessa topologia sem uso do modulo proposto, onde foi calculado a média de entradas de fluxos na tabela.

Tabela 4 – Topologia Tree Padrão

Topologia Tree Padrão (quantidade)

Média 25,187

(49)

Figura 17 – Gráfico Topologia Tree Padrão

Quando utilizamos o modulo proposto, principalmente nesta topologia, notamos uma grande redução no número de entradas de fluxo na tabela em compração ao uso da topologia padrão sem os recurso do modulo proposto.

Tabela 5 – Topologia Tree Proposta

Topologia Tree Proposta (quantidade)

Média 17,125

(50)

Figura 18 – Gráfico Topologia Tree Proposta

Comparando os gráficos da topologia Tree padrão com a Topologia Tree utili-zando o modulo proposto, podemos verificar uma grande diferença na quantidade de fluxo de entrada na tabela entre as duas propostas.

Tabela 6 – opologia Tree Comparativo (flow-mod)

Topologia Tree Padrão (quantidade) Proposta (quantidade)

Média 25,187 17,125

Desvio-Padrão 1,703 1,111

Margem-de-erro 0,439 0,286

(51)

Figura 19 – Grafico comparativo Topologia Tree

Na execução dos experimentos foi usada uma opção do emulador especifica para realização de testes. Com o parâmetro –test o Mininet cria uma rede, executa o experimento, e “para” a rede.

O parâmetro –test pode receber como valor iperf, pingall, etc. O valor do pa-râmetro –test define qual teste será realizado na rede. Testes usando pingall foram usados na construção das tabelas dos switches e para gerar mensagens flow-mod. Mensagens do tipo flow-mod são utilizadas para gerenciar a tabela do switch. Com uma mensagem flow-mod o controlador pode adicionar, alterar ou remover uma entrada na tabela. Com o pingall as máquinas pingarão umas às outras.

Tabela 7 – Topologia Linear Padrão (flow-mod)

Topologia Linear Padrão (quantidade)

(52)

Figura 20 – Gráfico Topologia Linear Padrão (flow-mod)

Tabela 8 – Topologia Linear Proposta (fow-mod)

Topologia Linear Proposta (quantidade)

(53)

Figura 21 – Gráfico Topologia Linear Proposta (flow-mod)

As metas são a redução do número de entradas na tabela do switch e o número de mensagens flow-mod geradas. Com a redução de entradas na tabela do switch, um número maior de entradas poderão ser criadas, sem haver necessidade de adicionar mais memória.

Tabela 9 – Topologia Linear Comparativo

Topologia Linear Padrão

(quantidade)

Proposta (quantidade)

(54)

Figura 22 – Gráfico Topologia Linear Comparativo (flow-mod)

Reduzindo o número de mensagens flow-mod, há uma redução da carga de trabalho do controlador. Reduzindo a carga de trabalho do controlador, abre-se espaço para adição de mais máquinas a rede.

Tabela 10 – Topologia Tree Padrão (flow-mod)

Topologia Tree Padrão (quantidade)

(55)

Figura 23 – Gráfico Topologia Tree Padrão (flow-mod)

Tabela 11 – Topologia tree Proposta (flow-mod)

Topologia Tree Proposta (quantidade

(56)

Figura 24 – Gráfico Topologia Tree Proposta (flow-mod)

Na construção da tabela do switch os dois módulos apresentam variação nos valores obtidos. O módulo padrão gera uma quantidade superior. Mesmo considerando o valor mais alto do módulo proposto com o mais baixo do módulo padrão, o proposto obtêm valores menores.

Tabela 12 – Topologia tree Comparativo (flow-mod)

Topologia Tree Padrão (quantidade) Proposta (quantidade)

(57)

Figura 25 – Gráfico Topologia Tree Comparativo (flow-mod)

Não há variação quanto a quantidade de mensagens flow-mod, em ambos os módulos.

(58)

57

6 CONCLUSÃO E TRABALHOS FUTUROS

A consolidação do paradigma de Redes Definidas por Software vem mudando a forma de gerenciar e projetar as redes de computadores, permitindo que elas possam evoluir e melhorar mais rapidamente em relação ao que ocorre atualmente. Dessa forma, com SDN foi possível criar um ambiente de teste para estudar temas com importante papel nas redes de computadores.

Em SDN o controlador pode se tornar o gargalo da rede. Com o barateamento e aumento do poder computacional dos switches, o hardware normalmente não repre-senta um grande problema. Nas redes tradicionais o broadcast é um problema, e se estende a SDN.

O OpenFlow tem a capacidade de fornecer aos pesquisadores um ambiente de testes em uma rede como a rede local de nossas Universidades. Assim ele abre as portas para que os pesquisadores possam testar suas inovações e garantir que seus experimentos sejam testados em um ambiente suficientemente semelhante ao de uma rede real qualquer, conseguindo assim, ganhar a confiança para uma implantação generalizada.

Através deste trabalho buscou-se apresentar inicialmente um breve contexto das redes de computadores, ficando evidenciado que a atual arquitetura das Redes é pouco flexível, pois mesmo que tenha sofrido algumas modificações nos últimos anos, estas não foram suficientes para atender as demandas de novas aplicações que cada vez mais vem sendo inseridas no contexto tecnológico.

Ainda, o presente trabalho buscou apresentar os principais conceitos sobre Redes Definidas por Software, como por exemplo, os vários aspectos que envolvem o protocolo OpenFlow, o controlador da rede, sendo utilizado o POX, o qual foi especial-mente desenvolvido para o ensino e pesquisa das SDNs.

(59)

Capítulo 6. Conclusão e Trabalhos Futuros 58

recursos oferecidos pelo controlador POX, foi realizada a implementação e a simulação dos cenários.

Com a redução do broadcast gerado por mensagens ARP request, foram alcan-çadas redução nas mensagens geradas pelo controlador e redução da quantidade de entradas na tabela do switch. Com a utilização do módulo proposto houve uma redução de mensagens flow-mod e das entradas na tabela de fluxos. A redução do broadcast ARP em rede SDN auxilia na redução da carga de mensagens geradas no plano de controle.

Em suma, apesar do paradigma ser recente, considerando o presente sucesso das SDNs, acredita-se que esta nova tecnologia realmente irá trazer muitos avanços para o desenvolvimento de novos serviços, aplicações e soluções para a área de redes de computadores como um todo.

Muitos são os desafios de pesquisa. Como sugestão para trabalhos futuros sugerimos:

• Adicionar um modulo automatizado para entrada de fluxo gerada nas tabelas, não sendo necessário a inclusão manual dod dados na tabela ARP;

• Adicionar um timeout a cada entrada da tabela ARP: Adicionar um tempo de permanência de cada entrada na tabela. Após o esgotamento desse tempo, a entrada deve ser removida da tabela.

• Testar a solução em ambiente real de produção, para verificar as métricas alcançadas;

• Procurar explorar melhor a visão global da rede, oferecida pelo controlador. Conhecer a rede como um todo, provavelmente ajudará na manutenção da tabela. Implementar características que tornem a solução inteligente.

Como sugestão de trabalhos futuros, pode-se citar o desenvolvimento e a imple-mentação de mais cenários, a integração com Ambientes Virtuais de Aprendizagem,

(60)

Capítulo 6. Conclusão e Trabalhos Futuros 59

a realização de testes em equipamentos físicos em uma rede real sem afetar o trá-fego em produção, a utilização e o estudo dessa nova tecnologia em cursos de redes de computadores, expandindo o paradigma SDN, dessa maneira agregando novos conhecimentos, contribuindo tanto na formação técnica quanto na científica de seus entusiastas.

Em suma, apesar do paradigma ser recente, considerando o presente sucesso das SDNs, acredita-se que esta nova tecnologia realmente irá trazer muitos avanços para o desenvolvimento de novos serviços, aplicações e soluções para a área de redes de computadores como um todo.

(61)

60

REFERÊNCIAS

ALVES JUNIOR, J.; ALBINI, L. C. P.; INFORMÁTICA, U. F. do Paraná. Setor de Ciencias Exatas. Programa de Pós-Graduaçao em. Um protocolo de roteamento resistente a ataques Blackhole sem detecção de nós maliciosos. 2012. Dissertação (Mestrado). Disponível em: <http://dspace.c3sl.ufpr.br:8080/dspace/handle/1884/27759>.

AMILTON JUNIOR. Sniffer – Entenda como funciona. 2010. Disponível em:

<http://dicasemgeral.xpg.uol.com.br/dicas-em-geral/12471/sniffer-entenda-como-funciona/>. Acesso em: 14/08/2016.

ARAÚJO, M. Uma Abordagem para Aprovisionamento de QoS em Redes Definidas por Software baseadas em OpenFlow. 2013. Disponível em: <https://onedrive.live.com/ view.aspx?cid=5AE8B415C3832C39&resid=5ae8b415c3832c39!354&app=WordPdf>. Acesso em: 06/07/2016.

BIAłEK, M. Conservative treatment of idiopathic scoliosis according to FITS concept: presentation of the method and preliminary, short term radiological and clinical results based on SOSORT and SRS criteria. Scoliosis, BioMed Central, v. 6, p. 25 – None, 2011. ISSN 1748-7161. Disponível em: <https: //www.ncbi.nlm.nih.gov/pmc/articles/PMC3286410/>.

CEARLEY, D. SDN é uma das 4 tendências que transformarão a TI em 5 Anos, Afirma Gartner. 2014. Disponível em: <http://www.dbserver.com.br/DbOnline_Details.aspx/ 3240/sdn--uma-das-4-tendncias-que-transformaro-a-ti-em-5-anos-afirma-gartner>. Acesso em: 04/07/2016.

CESTAROLLI, M. Soluções de ERP open source para 2015. 2015. Disponível em: <http://erp1.com.br/2015/03/solucoes-de-erp-open-source-para-2015/>.

CHARPINEL JUNIOR, S. R. Alocação Dinâmica de Circuitos Virtuais usando DRAGON: Uma Proposta de Interoperabilidade com Comutadores OpenFlow. 2012. 59 p. Monografia (Ciência da Computação) — UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO.

CISCO. Evolved Programmable Network. 2015. Disponível em: <http://www.cisco.com/ web/BR/solucoes/sp/network_infrastructure/index.html>. Acesso em: 18/08/2016. COSTA, D. A. da et al. Avaliação da contribuição de desenvolvedores para projetos de software usando mineração de repositórios de software e mineração de processos. 2013. Dissertação (Mestrado) — Universidade Federal do Rio Grande do Norte. Disponível em: <http://repositorio.ufrn.br:8080/jspui/handle/123456789/18082>.

COSTA, L. R. OpenFlow e o paradigma de redes definidas por software. 2013. 143 p. Monografia ((Licenciatura em Ciência da Computação)) — Universidade de Brasília. DUQUE, D. H. Redes Definidas por Software. 2012. Disponível em: <http: //br.monografias.com/trabalhos3/redes-definidas-software/redes-definidas-software2.shtml>. Acesso em: 26/08/2016.

(62)

Referências 61

FALSARELLA, D. SDN (Software Defined Networking) e o futuro das redes. 2012. Disponível em: <http://imasters.com.br/tecnologia/redes-e-servidores/sdn-software-defined-networking-e-o-futuro-das-redes/>. Acesso em: 22/08/2016.

HP COMPANY. OpenFlow : tecnologia de capacitação para redes definidas por software. 2015. Disponível em: <http://h17007.www1.hp.com/br/pt/solutions/technology/openflow/ index.aspx>. Acesso em: 17/08/2016.

KAUR, K.; SINGH, J.; GHUMMAN, N. S. Mininet as Software Defined Networking Testing Platform. International Conference on Communication, Computin g & Systems (ICCCS–2014), n. 4, 2014.

LOPES, Y. Tecnologia SDN promove o fim da escuridão na Rede de Comunicação. 2015. Disponível em: <http://www3.selinc.com.br/news/?p=1259>. Acesso em: 17/08/2016.

MARCO AURÉLIO MAIA. O que é Segurança da informação. 2013. Disponível em: <http://segurancadainformacao.modulo.com.br/seguranca-da-informacao>.

MCKEOWN, N. OpenFlow: Enabling Innovation in Campus Networks. Março 2008. MUSSI, S. S. et al. Diferenciação de fluxos sem manutenção de estados em roteadores. 2011. Dissertação (Mestrado) — Universidade Federal do Espírito Santo. Disponível em: <http://www.bdtd.ufes.br/tedesimplificado/tde_busca/arquivo.php?codArquivo=1603>.

NDATINYA, V. et al. Network forensics analysis using Wireshark. IJSN, v. 10, n. 2, p. 91 – 106, 2015. Disponível em: <http://dx.doi.org/10.1504/IJSN.2015.070421>.

OLIVEIRA, R. L. S. de U.; SHINODA, A. A. U.; SCHWEITZER, C. M. U. L3arpsec -módulo seguro para controle e proteção do protocolo de resolução de endereços em redes definidas por software. 2015. Dissertação (Mestrado) — Universidade Estadual Paulista (UNESP). Disponível em: <http://hdl.handle.net/11449/128103>.

OPEN VSWITCH. Production Quality, Multilayer Open Virtual Switch. 2014. Disponível em: <http://www.openvswitch.org/>. Acesso em: 17/08/2016.

OPENWRT. OpenWrt Wireless Freedom. 2015. Disponível em: <https://openwrt.org>. Acesso em: 17/08/2016.

PEREIRA, P. Como usar o TCPDump. 2011. Disponível em: <http://www.pedropereira. net/como-usar-o-tcpdump/>. Acesso em: 17/08/2016.

QUINTERO, D. SDN (Software Defined Networking) e o futuro das redes. 2014. Disponível em: <https://www.ibm.com/developerworks/community/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/sdn_software_defined_networkingeofuturo_ das_redes?lang=en>. Acesso em: 18/08/2016.

RIBEIRO, V. P. de A. et al. Classificação de tráfego online baseada em sub-fluxos. 2011. Dissertação (Mestrado) — Universidade de Fortaleza. Disponível em: <https://uolp. unifor.br/oul/ObraBdtdSiteTrazer.do?method=trazer&ns=true&obraCodigo=88170>. RODRÍGUEZ, F. L. Arquitetura e Protótipo uma Rede SDN-Openflow para Provedor de Serviço. 2014. Disponível em: <http://repositorio.unb.br/bitstream/10482/16030/1/ 2014_FernandoLopezRodrigues.pdf>. Acesso em: 06/07/2016.

(63)

Referências 62

RODRÍGUEZ, F. L.; CAMPELO, D. R. de S. Arquitetura e protótipo de uma rede SDN-OpenFlow para provedor de serviço. 2014. Dissertação (Mestrado). Disponível em: <http://repositorio.unb.br/handle/10482/16030>.

ROSANTE, J. C. U.; BREGA, J. R. F. U. Proposta de uma ferramenta de visualização e realidade virtual para o monitoramento de tráfego de redes de computadores. 2011. Dissertação (Mestrado) — Universidade Estadual Paulista (UNESP). Disponível em: <http://hdl.handle.net/11449/98695>.

SAKATO, M.; O’DONNELL, M.; HINGORANI, M. M. A Central Swivel Point in the RFC Clamp Loader Controls PCNA Opening and Loading on DNA. Journal of Molecular Biology, v. 416, n. 2, p. 163 – 175, 2 2012. ISSN 0022-2836. Disponível em: <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3269524/>.

SCHWARZ, M. F. et al. Mecanismo para integração de comutadores openflow na infraestrutura do testbed emulab. 2014. Dissertação (Mestrado) — Universidade de São Paulo. Disponível em: <http://www.teses.usp.br/teses/disponiveis/3/3141/tde-19032015-164205/>.

SISWANTO, D. F.; KARIMAH, S. A. Experiment with custom Mininet Topology to simulate network topology. 1st SDNRG ITB Meetup, Novembro 2014. Acesso em: 26/08/2016.

(64)

63

(65)

64

APÊNDICE A – CÓDIGO DE OBTENÇÃO DAS ESTATÍSTICAS

DOS FLUXOS OPENFLOW

# This file is part of POX. #

# POX is free software: you can redistribute it and/or modify

# it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version.

#

# POX is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details.

#

# You should have received a copy of the GNU General Public License # along with POX. If not, see <http://www.gnu.org/licenses/>.