ricardo anÍsio da silva

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

RICARDO ANÍSIO DA SILVA

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

Dissertação apresentada ao Programa dePós-graduação em Ciências da Computa-ção, do Centro de Informática da Universi-dade Federal de Pernambuco, como partedos requisitos necessários à obtenção do tí-tulo de Mestre em Ciência da Computação.

Orientador: Djamel Fawzi Hadj Sadok

Recife

2017

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

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 daUniversidade Federal de Pernambuco, comorequisito parcial para a obtenção do título deMestre 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

Universidade de Pernambuco

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.

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.

Obrigado a todos!

“O Aprendizado é o significado mais límpido

da vida, pois jamais se termina uma existência

sem que se aprenda algo.”

Maria Clara Fraga Lopes

RESUMO

O paradigma das Redes Definidas por Software (SDN) vem mudando a forma degerenciar e operar redes de computadores através da sua principal idéia, a separaçãodos 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 aprojetos de comutadores já existentes, é encontrado hoje em diversos equipamentosde rede comercializados por muitos fabricantes. Com o uso do paradigma SDN e doprotocolo Openflow, a inovação e evolução da rede são facilitadas. Dessa forma, muitosserviç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 particularidadesde 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 redeSDN. O foco principal desta dissertação, esta no controle da tabela de fluxo provenientede requisições ARP. Desta forma, esta proposta visa a diminuição e o controle dotrá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 detráfego referente a um fluxo, demonstrando neste trabalho que algumas métricas decontrole de requisições broadcast, podem ser atendidas. O módulo foi implementado eavaliado através de um simulador. Os resultados de avaliações referentes a diversosaspectos da solução proposta, são apresentados nesta dissertação, demonstrando queos ganhos na utilização do controle da tabela de fluxo e na quantidade de mensagensflow-mod do Openflow, geram uma dimunição na quantidade de dados transmitidasentre o controlador e o comutador.

Palavras-chave: Redes Definidas por Software (SDN). OpenFlow. Broadcast.

ABSTRACT

The paradigm of Software Defined Networking (SDN) has been changing theway in which to manage and operate computer networks through its main idea, theseparation of data plans and control. The Openflow protocol implements this conceptand, due to the advantages of lower cost of operation and greater ease of adaptationto designs of existing switches, is found today in several network equipment marketedby many manufacturers. With the use of the SDN paradigm and the Openflow protocol,network innovation and evolution are facilitated. In this way, many typical networkservices can be rethought in order to make them more flexible. When designing anSDN network one must take into account some particularities of performance, as forexample: table of flows and communication with controller. These characteristics maketraditional performance metrics such as flow, latency, jitter, and packet loss insufficientto evaluate the performance of an SDN network. The main focus of this dissertation isto control the flow table from ARP requests. In this way, this proposal aims at reducingand 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 pathsin the traffic routing referring to a flow, demonstrating in this work that some controlmetrics of broadcast requests can be met. The module was implemented and evaluatedthrough a simulator. The results of evaluations regarding several aspects of the proposedsolution are presented in this dissertation, demonstrating that the gains in the use of theflow table control and in the number of flow-mod messages of Openflow, generate adecrease in the amount of data transmitted between the Controller and the switch.

Keywords: Software defined networks (SDN). OpenFlow. Broadcast.

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

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

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

Tabela 12 – Topologia tree Comparativo (flow-mod) . . . . . . . . . . . . . . . . 55

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

PC Passivo Circulante

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

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

3.3 Otimização do Broadcast . . . . . . . . . . . . . . . . . . . . . . . . 37

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

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 (elementos 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

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


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.


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.


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.

E por fim, as conclusões desta dissertação são apresentadas no Capítulo 6.

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

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.


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


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.


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.


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).


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


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)


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).


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


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


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)


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

NDATINYA et al., 2015

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.

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

Próprio Autor


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.


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


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


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.

A Figura 3.4 mostra o funcionamento da proposta.


Figura 10 – Controlador responde requisições ARP

Próprio Autor

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 conectados 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.

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.


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.


Figura 13 – FITS autonomous island interconnection architecture

FITS Project

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

Intervalo-de-confiança 16.000 e 16.776

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



Intervalo-de-Confiança 14.000 e 14.776


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

Intervalo-de-confiança 16.000 e 16.776 14.000 e 14.776


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



Intervalo-de-confiança 24.748 e 25.626


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



Intervalo-de-confiança 16.839 e 17,411


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

Intervalo-de-confiança 24.748 e 25.626 16.839 e 17,411


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)

Média 96


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

Tabela 8 – Topologia Linear Proposta (fow-mod)

Topologia Linear Proposta (quantidade)

Média 75


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)

Média 96 75


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)

Média 122


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

Tabela 11 – Topologia tree Proposta (flow-mod)

Topologia Tree Proposta (quantidade

Média 86


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)

Média 122 86


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.

Não há desvio padrão, margem de erro e intervalo de confiança.

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.

Por fim, através do simulador SDN MiniNet juntamente com a utilização dos

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,

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.

60

REFERÊNCIAS

ALVES JUNIOR, J.; ALBINI, L. C. P.; INFORMÁTICA, U. F. do Paraná. Setor de CienciasExatas. Programa de Pós-Graduaçao em. Um protocolo de roteamento resistente aataques 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 porSoftware 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 FITSconcept: presentation of the method and preliminary, short term radiologicaland clinical results based on SOSORT and SRS criteria. Scoliosis, BioMedCentral, 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, AfirmaGartner. 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ÍRITOSANTO.

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 desoftware 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.

http://dspace.c3sl.ufpr.br:8080/dspace/handle/1884/27759

http://dicasemgeral.xpg.uol.com.br/dicas-em-geral/12471/sniffer-entenda-como-funciona/

http://dicasemgeral.xpg.uol.com.br/dicas-em-geral/12471/sniffer-entenda-como-funciona/

https://onedrive.live.com/view.aspx?cid=5AE8B415C3832C39&resid=5ae8b415c3832c39!354&app=WordPdf

https://onedrive.live.com/view.aspx?cid=5AE8B415C3832C39&resid=5ae8b415c3832c39!354&app=WordPdf

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3286410/


http://www.dbserver.com.br/DbOnline_Details.aspx/3240/sdn--uma-das-4-tendncias-que-transformaro-a-ti-em-5-anos-afirma-gartner

http://www.dbserver.com.br/DbOnline_Details.aspx/3240/sdn--uma-das-4-tendncias-que-transformaro-a-ti-em-5-anos-afirma-gartner

http://erp1.com.br/2015/03/solucoes-de-erp-open-source-para-2015/

http://www.cisco.com/web/BR/solucoes/sp/network_infrastructure/index.html

http://www.cisco.com/web/BR/solucoes/sp/network_infrastructure/index.html

http://repositorio.ufrn.br:8080/jspui/handle/123456789/18082

http://br.monografias.com/trabalhos3/redes-definidas-software/redes-definidas-software2.shtml



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 NetworkingTesting 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. L3-arpsec -módulo seguro para controle e proteção do protocolo de resolução de endereços emredes definidas por software. 2015. Dissertação (Mestrado) — Universidade EstadualPaulista (UNESP). Disponível em: <http://hdl.handle.net/11449/128103>.

OPEN VSWITCH. Production Quality, Multilayer Open Virtual Switch. 2014. Disponívelem: <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 Provedorde Serviço. 2014. Disponível em: <http://repositorio.unb.br/bitstream/10482/16030/1/2014_FernandoLopezRodrigues.pdf>. Acesso em: 06/07/2016.

http://imasters.com.br/tecnologia/redes-e-servidores/sdn-software-defined-networking-e-o-futuro-das-redes/

http://imasters.com.br/tecnologia/redes-e-servidores/sdn-software-defined-networking-e-o-futuro-das-redes/

http://h17007.www1.hp.com/br/pt/solutions/technology/openflow/index.aspx

http://h17007.www1.hp.com/br/pt/solutions/technology/openflow/index.aspx

http://www3.selinc.com.br/news/?p=1259

http://segurancadainformacao.modulo.com.br/seguranca-da-informacao

http://www.bdtd.ufes.br/tedesimplificado/tde_busca/arquivo.php?codArquivo=1603

http://dx.doi.org/10.1504/IJSN.2015.070421

http://hdl.handle.net/11449/128103

http://www.openvswitch.org/

https://openwrt.org

http://www.pedropereira.net/como-usar-o-tcpdump/

http://www.pedropereira.net/como-usar-o-tcpdump/

https://www.ibm.com/developerworks/community/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/sdn_software_defined_networkingeofuturo_das_redes?lang=en



https://uolp.unifor.br/oul/ObraBdtdSiteTrazer.do?method=trazer&ns=true&obraCodigo=88170

https://uolp.unifor.br/oul/ObraBdtdSiteTrazer.do?method=trazer&ns=true&obraCodigo=88170

http://repositorio.unb.br/bitstream/10482/16030/1/2014_FernandoLopezRodrigues.pdf

http://repositorio.unb.br/bitstream/10482/16030/1/2014_FernandoLopezRodrigues.pdf

Referências 62

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

ROSANTE, J. C. U.; BREGA, J. R. F. U. Proposta de uma ferramenta de visualização erealidade 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 theRFC Clamp Loader Controls PCNA Opening and Loading on DNA. Journal ofMolecular 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 nainfraestrutura do testbed emulab. 2014. Dissertação (Mestrado) — Universidade deSã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 tosimulate network topology. 1st SDNRG ITB Meetup, Novembro 2014. Acesso em:26/08/2016.

http://repositorio.unb.br/handle/10482/16030

http://hdl.handle.net/11449/98695


http://www.teses.usp.br/teses/disponiveis/3/3141/tde-19032015-164205/

http://www.teses.usp.br/teses/disponiveis/3/3141/tde-19032015-164205/

63

APÊNDICES

64

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

DOS FLUXOS OPENFLOW

#

#

#!/usr/bin/python

# Copyright 2012 William Yu

# [email protected]

#

# 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/>.

#

APÊNDICE A. Código de Obtenção das Estatísticas dos Fluxos Openflow 65

“”“

This is a demonstration file created to show how to obtain flow

and port statistics from OpenFlow 1.0-enabled switches. The flow

statistics handler contains a summary of web-only traffic.

“”“

# standard includes

from pox.core import core

from pox.lib.util import dpidToStr

import pox.openflow.libopenflow_01 as of

#

# include as part of the betta branch

from pox.openflow.of_json import *

log = core.getLogger()

#

# handler for timer function that sends the requests to all the

# switches connected to the controller.

def _timer_func ():

for connection in core.openflow._connections.values():

connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request()))

connection.send(of.ofp_stats_request(body=of.ofp_port_stats_request()))

log.debug(“Sent %i flow/port stats request(s)”, len(core.openflow._connections))

#

# handler to display flow statistics received in JSON format

# structure of event.stats is defined by ofp_flow_stats()


def _handle_flowstats_received (event):

stats = flow_stats_to_list(event.stats)

log.debug(“FlowStatsReceived from %s: %s”,

dpidToStr(event.connection.dpid), stats)

#

# Get number of bytes/packets in flows for web traffic only

tbytes = 0

tflows = 0

tpacket = 0

for f in event.stats:

tbytes += f.byte_count

tpacket += f.packet_count

tflows += 1

print(“Bytes %s – Pacotes %s – Fluxos %s” %(tbytes, tpacket, tflows))

#

# handler to display port statistics received in JSON format

def _handle_portstats_received (event):

stats = flow_stats_to_list(event.stats)

log.debug(“PortStatsReceived from %s: %s”,

dpidToStr(event.connection.dpid), stats)

#

# main functiont to launch the module

def launch ():

from pox.lib.recoco import Timer


#

# attach handsers to listners

core.openflow.addListenerByName(“FlowStatsReceived”,

_handle_flowstats_received)

core.openflow.addListenerByName(“PortStatsReceived”,

_handle_portstats_received)

#

# timer set to execute every one seconds

Timer(1, _timer_func, recurring=True)

ricardo anÍsio da silva

Documents